Search the Community

Showing results for tags 'testers wanted'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Technical support
    • Getting started
    • Allwinner A20
    • Allwinner H2 & H3
    • Amlogic S905(x)
    • Armada A388, A3700
    • Freescale imx6
    • Rockchip 3288 & 3328
    • Other supported boards
    • Common issues
  • Community forums
    • Peer to peer technical support
    • TV boxes
    • General chit chat
  • Development
    • Allwinner A64, H5 & H6
    • Rockchip 3399
    • Development


There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 6 results

  1. I was chatting with @tido about ways to help the Armbian community and I came up with the idea of a common C library to access the I2C, SPI and GPIOs of all supported boards. There are of course kernel drivers to communicate with these things, but there are differences between boards that this API could help smooth out. For example, different CPUs (and boards) map the GPIO pins very differently. Projects such as WiringOP and WiringNP try to copy the Raspberry Pi library, but this is also flawed because it's based on the BCM283x GPIO numbering. What I propose is to create a set of simple functions for accessing GPIO pins using the physical pin number as a reference. On all boards, the 5V pin will be considered pin 2 and the numbering goes from there. There are also sometimes pushbuttons present on the board which are mapped to GPIO inputs. These are also covered by my API. Much of the code is already written and I will release it shortly. I'm posting this topic to get feedback and to reach out to people who might make use of this. Here is a list of the functions so far: int AIOInit(void); void AIOShutdown(void); const char * AIOGetBoardName(void); int AIOOpenI2C(int iChannel, int iAddress); int AIOOpenSPI(int iChannel, int iSpeed); int AIOCloseI2C(int iHandle); int AIOCloseSPI(int iHandle); int AIOReadI2C(int iHandle, int iRegister, unsigned char *buf, int iCount); int AIOWriteI2C(int iHandle, int iRegister, unsigned char *buf, int iCount); int AIOReadSPI(int iHandle, unsigned char *buf, int iCount); int AIOWriteSPI(int iHandle, unsigned char *buf, int iCount); int AIOReadWriteSPI(int iHandle, unsigned char *inbuf, unsigned char *outbuf, int iCount); int AIOReadButton(void); int AIOAddPin(int iPin, int iDirection); int AIORemovePin(int iPin); int AIOReadPin(int iPin); int AIOWritePin(int iPin, int iValue);
  2. From Armbian documentation ( Most in-circuit and GPIO based interfaces (SPI, I2C, I2S, …) don’t have a mechanism for detecting and identifying devices connected to the bus, so Linux kernel has to be told explicitly about the device and its configuration details. While Device Tree is a way of describing hardware configuration to the kernel, Device Tree overlays are a way for modifying the DT in order to provide the kernel and kernel drivers with details about external devices or to activate interfaces disabled by default. What do we want? We want to add Device Tree overlays for the onboard interfaces and tested external devices so that they appear in future mainline Armbian images. This means that activating this type of hardware will not require recompiling the Device Tree or will require compiling just the overlay file which will be compatible with future kernel updates. What kind of help do we expect? We want people to participate in making and testing overlays for the hardware that they have. Participation requirements: An A10, A20 or H3 board that can boot the current mainline kernel Serial console adapter for getting the u-boot logs if they are needed Extra SD card to use for booting the nightly/beta images I2C, SPI or I2S (only A10 and A20 based boards since I2S driver is not present on H3 yet) device that you can connect to the board and that requires either generic driver (like SPIdev) or a special driver (available in the mainline kernel), with an exception of custom built boards that don't have commercially available compatible alternatives and devices that don't have in-tree kernel drivers. Some generic Linux knowledge (i.e. how to obtain a dmesg log, how to check file contents) At least a basic understanding of the hardware that you have and how does it integrate into Linux. For example I have no idea how to calibrate a resistive touch screen even if I can write a DT overlay for it. Please note that some hardware limitations (i.e. number of SPI chip selects, missing SPI DMA support) may affect possibility of supporting some devices What overlays are already available? Please check the README in the subdirectory for your SoC in the overlays repository:
  3. The pyA20 gpio library is quite famous when people start to play with gpios , spi or i2c on sunxi boards but mapping needs often adjustments to work on your own board. This situation is not really friendly for 'beginners'. pyGPIO should help to make armbian a little bit more 'IoT friendly'. I didn't touch the 'backbone' of pyA20, so the syntax should be similar to its original (except pinname when using port instead of connector). How can I use this library: Cause all of this boards have (more or less) the same pinheader (sometimes other pins are deployed on the pinheader) pyGPIO tries to unify the mappings, so that code can be shared and deployed on all boards without touching the code. The mapping follows the pin naming of the RaspberryPi (it's not because I think their naming is perfect, but it should be the easiest way to port code from the 'RPi world' to Armbian. What is done: -Initial support for: OrangePi Zero/PcPlus/Lite/Plus2E NanoPi Duo(with and without Minishield)/Neo Olimex Lime/Lime2/Micro (pins are not renamed PG10,PG11 etc. instead of GPIO2, GPIO3 etc. cause those boards doesn't have a 'RPi Pinheader' Templates for 24,26 and 40 'RPi compatible' pin header -Board detection (when using Armbian) to check if your board is supported -Manual assignment when your board is not supported (yet) or automatic board detection fails What is not done: Testing testing testing! Documentation Meaningful examples (still the originals from olimex which wouldn't work anymore) What do you need to test the Library: You need python-dev and the Library which you'll find on my GitHub page. The installation should be easy, just follow the instructions... sudo apt-get install python-dev git clone cd pyGPIO sudo python install Testing is the part where I need help. I don't have most of the boards which are supported (only OPi0 and OPi Pc Plus). I tested I2C and GPIO on the OPi0, for all the rest, I need you as testers, bug hunters, and feedback. Here are two short python snippets which should do the exact same thing (once with connector, you have to run them as root or with sudo otherwise it would not work!): import os, sys if not os.getegid() == 0: sys.exit('start script as root') from pyGPIO.gpio import gpio, connector from time import sleep gpio.init() gpio.setcfg(connector.GPIOp7, 1) #pin 7 as output n = 0 while n < 5: gpio.output(connector.GPIOp7, 1) sleep(1) gpio.output(connector.GPIOp7, 0) sleep(1) n +=1 sys.exit('finished ;-)') and once with port: import os, sys if not os.getegid() == 0: sys.exit('start script as root') from pyGPIO.gpio import gpio, port from time import sleep gpio.init() gpio.setcfg(port.GPIO4, 1) #gpio4 as output n = 0 while n < 5: gpio.output(port.GPIO4, 1) sleep(1) gpio.output(port.GPIO4, 0) sleep(1) n +=1 sys.exit('finished ;-)') Annotation: When using NanoPi Duo you've to possibilities with or without Minishield. Pin name is the same on both possibilities but when using port but pin numbering when using connector: Minishield: 3.3V |1·| 5V GPIO2 I2C0_SDA |3·| 5V GPIO3 I2C_SCL |5·| GND GPIO4 |··| GPIO14 UART1_TX GND |··| GPIO15 UART1_RX GPIO17 SPI1_MOSI |··| GPIO18 GPIO27 SPI1_MISO |··| GND GPIO22 SPI1_CLK |··| GPIO23 SPI1_CS 3.3V |··| NC (on mini shield) Without (e.g. connector.J1p7 or connector.J2p5) : J1 J2 (UART0_RX) |1| microUSB |1| 5V (UART0_TX) |2| |·| 5V GND |3| |·| 3.3V GPIO3 (TWI_SCL) |4| |·| GND GPIO2 (TWI_SDA) |5| |·| GPIO4 (IR_RX) GPIO23 (SPI1_CS) |6| |·| GPIO18 (IOG11) GPIO22 (SPI1_CLK) |7| |·| DM3 D- GPIO27 (SPI1_MISO) |·| |·| DM3 D+ GPIO17 (SPI1_MOSI) |·| |·| DM2 D- GPIO15(UART1_RX) |·| |·| DM2 D+ GPIO14 (UART1_TX) |·| |·| RDN (CVBS) |·| |·| RDP (LINEOUT_L) |·| |·| TXN (LINEOUT_R) |·| |·| TXP (MICP) |·| |·| LED-LINK (MICN) |·| microSD |·| LED-SPD Buttons (bigger orange pi boards) are mapped, but I didn't test if it works (mapping here, if somebody is interested in testing them, see mapping.h of your board): {"BUTTON", { { "BUTTON", SUNXI_GPL(4), 1 }, { { 0, 0, 0} }, } },
  4. On Which image can I test? Any How? Go to armbian-config -> System -> Nightly and proceed. If this option is not there, defreeze upgrading Restart and after your system is up, proceed to one of those areas: - desktop install from armbian-config on top of CLI (any board) - set first_run_network configuration, setting ip within /boot/armbian_first_run.txt (any board except Espressobin) - kernel switching or upgrade (any board, especially Odroid XU4 NEXT) - setting fixed/dhcp network with armbian-config (any board except Espressobin) - configure frame buffer within h3disp utility (any h3 board with a legacy kernel) - DTS sound on DEV kernel (miqi, Tinkerboard) - ROCK 64 default kernel - check effects of changing everything to Network Manager withing firstrun/armhwinfo and other scripty - check install from a blank image ( and - set AP mode (any board) All changes are reflected in a beta repository and are coming from the build script, branch "development". If you want to build this state, use LIB_TAG="development" while running the script. Make sure you are doing this on sine test install. In case you find a bug: - report it here - push a fix to the build script, branch development
  5. I added a script lurking around on my disk for some time to Armbian's repo to be hopefully included into future Armbian releases when testing looks good: Since it's just a script you can include it in your running Armbian installation simply by downloading it from Github -- try it this way please: sudo -s wget -q -O /usr/local/bin/h3consumption "" chmod 755 /usr/local/bin/h3consumption h3consumption -H h3consumption -p The last 2 calls will show the verbose help text along with current settings. This might then look like this: Mode of operation/test: Please read through the description (-H output) first and check also the referenced links Use -p to get currently used settings Use the other switches to modify settings Do not use -p now but instead do a reboot first and then check again -p You might also have a look at /etc/rc.local and /etc/defaults/cpufrequtils to get an idea where the script does things for a better understanding Two examples (will go into details later in different thread): On an Orange Pi Plus 2E 'h3consumption -c 1 -m 1296 -d 408 -g off -e fast' reduces default idle consumption from 1650 mW by 780 mW to just 870 mW On an Orange Pi Lite 'h3consumption -D 132 -c1 -g off -u off' reduces default idle consumption from 1060 mW by 660 mW to just 400 mW (same low consumption running identical settings possible with NanoPi M1, Orange Pi One/PC/PC Plus and maybe the larger boards too when GBit Ethernet PHY can be completely disabled) Please note: the -D switch allows to use DRAM clockspeeds that are way below Allwinner's defaults and what's expected to work ok (since DDR3 shouldn't be clocked lower than 300 MHz and Allwinner used 408 MHz clockspeed as lower limit). While clockspeeds as low as 132 MHz seemed to work reliably in my tests and it should be ok to test these out when having in mind that this is an experimental feature you won't be able to go lower than 408 MHz anyway without a kernel patch (available in post #14 here) with all available official Armbian releases. So you've to either use the kernel .deb I provide in the other thread or wait for a new round of Armbian images (no idea how Igor's plans look like)
  6. In order to make armbian better, we need your help with testing. Why? there are simply too many boards to handle, there are task which can't be automatized, there are bugs which are not seen from our perspective. What kind of tests? booting, user creation, updates, upgrades checking if basic supported functions work: video, audio, network, wireless, AP mode do nasty thing to your board and report. How to test? Download nightly images from here. You want to test image which is not there? Add those two parameters with desired targets to board's config and create a pull request. and / or change to our daily build developer repository: deb $(lsb_release -cs) main utils $(lsb_release -cs)-desktop Note: you are entering developer area and things will sometimes be completely broken. Don't use this repository in production! When bug is found? * Provide logs with armbianmonitor -u or type as much data as you can. Check if it's not already on the list and if not, add it there, [optional] Open a topic in issues support forum if you think we need to discuss it, [optional] Fix it.