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


Forums

  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues
    • Peer to peer technical support
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner H5 & A64
    • Armada A388, A3700
    • Amlogic S905(x)
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Other supported boards
  • Development
    • Allwinner H6
    • Rockchip 3399
    • Development

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 6 results

  1. note: This is from a previous thread about testing, I accidentally moved it, and this was the only way to resume the conversation --- Just kicking off a thread here to talk about different ideas around testing. It would be great if the community could help test more.,,, but what would it look like.... maybe end users can burn a test image and run a test script. the script could do cool things like: * spi loopback test * check for healthy kernel modules * look for dmesg errors * test wifi * test ethernet * test audio? * even run a phoronix test of somesort to validate a particular feature. Are there any simple circuit diagrams people could design to make testing easier... i2c testing? bitbang something into the audio input? who knows. well, in a way they do via complaint. ;-) A lot of parts need some sort of script, amlogic BSP kernels (not Armbian) are tested in such a way (perform 1000 reboots, etc). That I can aid in, but the typical user probably won't have the sorts of things needed. https://github.com/armbian/testings That'd be awesome! I'm coming from the perspective of creating more opportunities and interest for the undiscovered non-typical users. was a nice starter, unfortunately nobody contributes to it and the testings there are really outdated.. I did some tests back then to automate testing (actually it was one of the use-cases I thought about for my BPi-R2 (using its serial from the pinheader to connect them to the serials of the tested boards) doing automated upgrades and check if network comes up, in case not it would try to log-in via serial.. automation has some issues.. e.g. properly filter dmesg issues is hard cause different drivers tend to float dmesg with different errors so it's hard to filter them properly.. You also need some way to powercycle the board (e.g. reboot and powercycle are different things in case of a proper reboot - BPi R2 boots up properly when you powercycle it from eMMC, whereas it doesn't with a simple reboot.. ). The idea is great, and we need more testing break due to bad testing is something we had to often... I'm willing to test new images on the boards I've got. Maybe you could make a checklist with all images that need to be tested. Once tested you check, and it's removed from the list and can be put on download page. You could also do a button at the download page to let users download the test image, and ask them to give test results. Just an idea. actually the basics to test are there.. cool so since this a brain storming thread. i wanna try to stay away from thinking about process. This is more about thinking of creative ways to do testing. I didn't see that page. I will use it for my next tests now! Hi, I tried to push my testing of pineh64-dev compiled from today, but have no access to armbian/testings.git Is there something I have done in the wrong way? As you can see I tried 3 times and even with '-f' it does nothing. I tried to push manually but got this error: If you are out to test the full functionality of a modern Linux distribution such as Ubuntu including multimedia capabilities, etc, it's quite difficult (I really mean it's rather impossible) to write a script to do it. There are quite simply too many possible use cases. Not even Ubuntu people do it for their x86-64 images. They rely on tens of thousands of users to report on possible bugs. Personally I test my Amlogic TV boxes running armbian / Ubuntu 18.04 by running a distributed kernel compilation on them. That tests the network functionality, roughly tests the kernel and memory for stability, roughly tests the ext4 filesystem on the SD cards, test the basic functionality of Ubuntu 18.04 on Aarch64 hardware, and... that's it. I am happy to report that for my use case, Armbian Ubuntu has shown exceptional stability on some of the cheapest hardware one can find on the planet. did you clone your fork when testing? Or did you follow this one? git clone https://github.com/armbian/testings cd testings ./createreport.sh createreport.sh was glued together relatively quickly (I know it cause I wrote it.. ) and its git remote handling is a bit hacky (e.g. upstream and origin).. If you clone from your fork things mess up quickly and then it tries to push directly into armbian/testings for which you don't have commit rights.. I didn't test it recently (just moved a few days ago and more or less all my SBCs are somewhere in boxes.. ).. Once I've a bit more time I'll hopefully clean it up a bit.. can you give me the output of: git remote -v? My angle more about any testing vs no testing. Ya i mostly care about like not seeing dmesg full of noise etc.... extra credit for spi and i2c and technically the gpu, and hardware encoding and decoding could be tested headless. Oh yes, any testing is way better than no testing. Perhaps document a systematic testing procedure and leave it to the hundreds of Armbian users to do the testing and report on results back here in the forum? I would suggest that would be the better approach to this. Right now most people only bother to report when they have a problem, not when everything works fine for their use case. Yes all your points are true, and there are at least some pieces floating around that could be tied together and documented. I was trying to keep this thread on the creative side and not on the process side. Ex: I have a 4 channel relay board and a bag of solder on USB A sockets and the allwinner H3 has like 4 uarts in it. If we tested images via usb booting its possible a test image could be mounted on another SBC and delivered via usb gadget mode from the OTG port. That's a little bit complicated, I guess. A much, much simpler approach to testing Armbian images is to network boot them. But then you are not testing an essential functionality that most Armbian users depend upon: the ability to boot from an $4 micro SD card. Yeah nfs root is would be way simpler. Main advantage to the theoretical usb boot would being able to test uboot on the image. Can you chainload uboot from uboot? I don't think that's officially supported because both u-boot's would want to load at the same address, so the second one would load on top of the first one and the boot process would crash. I see there has been some discussion of this in the u-boot mailing list, but you'd have to ask if there is any recent update on this issue. Also note that some SBC vendors are shipping their boards with u-boot pre-installed on SPI ROM (afaik, Khadas and Libre Computer). I follow these instructions, but when executing the script it creates a fork on my account. Here is the result of git remote -v: jeanrhum https://github.com/jeanrhum/testings.git (fetch) jeanrhum https://github.com/jeanrhum/testings.git (push) origin https://github.com/armbian/testings (fetch) origin https://github.com/armbian/testings (push)
  2. From Armbian documentation (https://docs.armbian.com/User-Guide_Allwinner_overlays/) 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: https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian
  3. I wish you all good health. Using the "Armbian" build system, I noticed two bad points: 1 - incomplete cleaning of the source code before starting a new compilation, seen when patches add new files to the tree. 2 - Debian kernel source package includes the git directory. 1) All I do I'm fixing the version kernel (KERNELBRANCH="tag:v4.14.40") and collect several variants for one Board, changing the patchset for each version, adding or removing some. Before each new compilation I'm doing a test of the purity of the source. clean_repo() { display_alert "clean_repo $PWD" #git status -s git reset --hard HEAD # First, return the modified files. git clean -df # Then delete all new, added files. #git status } compile_kernel() { # A simple check ensures that we start with a clean slate. cd $SRC/cache/sources/$LINUXSOURCEDIR if [ "X$(git status -s)" != "X" ]; then clean_repo fi # ... ... } 2) Manufacturer's code Debian package: (--exclude='./.git/') if [[ $BUILD_KSRC != no ]]; then display_alert "Compressing sources for the linux-source package" tar cp --directory="$kerneldir" --exclude='./.git/' --owner=root . \ | pv -p -b -r -s $(du -sb "$kerneldir" --exclude=='./.git/' | cut -f1) \ | pixz -4 > $sources_pkg_dir/usr/src/linux-source-${version}-${LINUXFAMILY}.tar.xz cp COPYING $sources_pkg_dir/usr/share/doc/linux-source-${version}-${LINUXFAMILY}/LICENSE fi can be changed to view: (--exclude="[.]git") if [[ $BUILD_KSRC != no ]]; then display_alert "Compressing sources for the linux-source package" tar cp --directory="$kerneldir" --exclude="[.]git" --exclude="[.]git[a-z]*" --owner=root . \ | pv -p -b -r -s $(du -sb "$kerneldir" --exclude="[.]git" --exclude="[.]git[a-z]*" | cut -f1) \ | pixz -4 > $sources_pkg_dir/usr/src/linux-source-${version}-${LINUXFAMILY}.tar.xz cp COPYING $sources_pkg_dir/usr/share/doc/linux-source-${version}-${LINUXFAMILY}/LICENSE fi
  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 (https://dl.armbian.com/odroidc2/nightly/ and https://dl.armbian.com/orangepiplus2e/nightly/) - 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: https://github.com/igorpecovnik/lib/blob/master/scripts/h3consumption 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 "https://raw.githubusercontent.com/igorpecovnik/lib/master/scripts/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 http://beta.armbian.com $(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.