Search the Community

Showing results for tags 'testers wanted'.

  • 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
    • Reviews, Tutorials, Hardware hacks
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker - supported boards only
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner A64, H5 and H6
    • Armada A388, A3700
    • Amlogic S905(x), S922X
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Rockchip 3399
    • Other supported boards
  • Development
    • Development
  • TV Boxes's General chat
  • TV Boxes's Support Armbian TV
  • TV Boxes's Reviews
  • Android fanboys's Forums
  • Gaming on ARM's Reviews
  • Gaming on ARM's Issues
  • Kobol Forum's Helios4
  • Kobol Forum's Helios64

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP


Skype


Github


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
  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 de
  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_
  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
  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
  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 desir