Igor Posted March 27, 2018 Author Posted March 27, 2018 5 hours ago, jeanrhum said: I think it would be interesting to list the preferred boards that should be used for testing (maybe in a specific thread). Indeed. One year ago we started with first organized testing. We cover all boards except clones. We used project management application, set milestones from "feature freeze, beta testing, bug fixing, writing release information, launch". A new cycle starts with "feature development" and last for 3-4 months and we have 1-2month for freeze-fix-launch phase. We made this with 9 people involved and the first time it went fairly o.k., second time badly ... and third time we didn't try. There are many reasons why even the way and technology is set up perfectly. A tester is responsible for a single task (board) and he gets email: "We are testing, please check what works and what not, write comments". Like this: Spoiler 5 hours ago, jeanrhum said: I look at armbian website, documentation and forum, but this kind of information is not defined in a clear and unique place. In the first post of this thread, we can identify a few of them but that's all. If we want to help in testing and for instance buy a new board for that purpose, it could guide us. Exactly. We didn't get here in the first place since our first testing cycle went fine, while second failed. And since I am not sure what is the best way to conduct the testing its hard to pass on. 5 hours ago, jeanrhum said: I only chose 1 board for a given soc, but it is just an example and it is probably difficult to define this list with most people agreeing. This is good enough if testing process is done properly. At least as we did it the first time. Then it could be also divided into userspace - which should be hardware independent - testing and low-level stuff. IMO, we need a project manager for this testing which can't be me. Organizing testing means some communication but I am in general already up to two weeks behind with my email and other private comm. I can't lead this.
jeanrhum Posted March 27, 2018 Posted March 27, 2018 I agree with you and was a member of the project management platform that was used one year ago. Maybe this platform was too heavy and a bit rigid. IMO the forum is more dynamic and open to any people, but currently there is no clear rule/guide on how to conduct some tests. What I've done each time I test a build is (order is approximative): 1. burn an image to a sd card with etcher 2. check if it boots as expected (command line or desktop) 3. configure linux using armbian-config (timezone, keyboard, etc.) 4. check hardware support (ethernet, wireless, sound, gpu, vpu), 5. check some highlighted functionalities I'm able to test (eg: kernel switching, desktop install) 6. update and upgrade packages 7. report back to forum and post the result of send diagnostic item in armbian-config (I suppose it calls armbianmonitor -u). Is there something wrong/missing in this list to help you in a better way?
Igor Posted March 28, 2018 Author Posted March 28, 2018 10 hours ago, jeanrhum said: Is there something wrong/missing in this list to help you in a better way? I would propose to add this: start with oldest from download, switch to beta and upgrade. The rest is ok - special things, new features can go into highlighted.
jeanrhum Posted March 28, 2018 Posted March 28, 2018 Thanks, I forgot this point and will add this to my check list ;). If I have time, I will try again to upgrade my pine64 but this time starting from latest 5.37 instead of the old image I was using.
JMCC Posted March 28, 2018 Posted March 28, 2018 On 27/3/2018 at 1:29 PM, Igor said: - USB3 works - sound works - it boots Sound confirmed to work, as well as video acceleration. Also, the improper shutdown causing SD card corruption (and other problems, see below) is gone with this kernel. I also have two more suggestions to incorporate to the build script: There is a problem with HC1 not properly parking HDD heads on shutdown, and therefore shortening disk life, as described here: https://forum.odroid.com/viewtopic.php?f=97&t=29069. It can be solved with a custom script found in Harkernel's wiki wget https://dn.odroid.com/5422/script/odroid.shutdown sudo install -o root -g root -m 0755 ./odroid.shutdown /lib/systemd/system-shutdown/odroid.shutdown Regarding USB3, I have tried different images, including the ones that worked before, but it is dead. Plugging and unplugging different devices doesn't make any entry in system logs. I am suspecting some hardware fault: when I was unaware of the previous kernel's shutdown problem, I shut it down normally and left, but next day the unit was very hot. From then on, I always unplugged it after shutdown, but I am afraid it could have gotten damaged that day. I'm so sorry These are the logs (notice that there were two devices plugged in the USB ports:,but none of them shows up): http://ix.io/13PX
Igor Posted March 28, 2018 Author Posted March 28, 2018 35 minutes ago, JMCC said: I also have two more suggestions to incorporate to the build script: https://github.com/armbian/build/commit/b15bb76a35e6f94868dbc8539e52a5102670be42 36 minutes ago, JMCC said: Regarding USB3, I have tried different images, Have you tried powered USB hub? Plugged at boot time?
JMCC Posted March 28, 2018 Posted March 28, 2018 27 minutes ago, Igor said: Have you tried powered USB hub? Plugged at boot time? Yes, with no luck. I'll keep trying other options, if I come up with something. Prayer seems like the only one so far. I also forgot to put my second suggestion: Mali devfreq governor is set by default to performance. Setting it to simple_ondemand can save some power and reduce SoC temp. It can be done with one line in /etc/sysfs.conf: echo 'devices/platform/11800000.mali/devfreq/devfreq0/governor = simple_ondemand' >> /etc/sysfs.conf
TonyMac32 Posted March 29, 2018 Posted March 29, 2018 On 3/18/2018 at 10:53 AM, Igor said: I added it to config-default.conf ... and it works for me. Try that. I was so confused. Kids, take heed in the power of reading.
jeanrhum Posted March 29, 2018 Posted March 29, 2018 I test to upgrade a pine64 from 5.38 (xenial server 3.10.107) to nightly builds i got this output after the upgrade: http://ix.io/14cr I'm still on 3.10.107 kernel even after trying to swtiching to dev or next kernel (switch is very fast). Do you want me to test something particular? I don't know where to search since no error is reported.
Igor Posted March 29, 2018 Author Posted March 29, 2018 On 29. 3. 2018 at 9:50 PM, jeanrhum said: I test to upgrade a pine64 from 5.38 (xenial server 3.10.107) to nightly builds i got this output after the upgrade: http://ix.io/14cr I'm still on 3.10.107 kernel even after trying to swtiching to dev or next kernel (switch is very fast). Good. This is a bug ... we need to add yet another exception: https://github.com/armbian/config/blob/development/debian-config-submenu#L368-L383
TonyMac32 Posted March 30, 2018 Posted March 30, 2018 I fixed nanopi K2 image creation, when the board got renamed it broke the build, had to rename u-boot blob and bootscript. Meson64 default is now 4.14.y, next will become 4.16.y soon as the kernel enters stable.
Igor Posted March 31, 2018 Author Posted March 31, 2018 On 29. 3. 2018 at 11:01 PM, Igor said: I'm still on 3.10.107 kernel even after trying to swtiching to dev or next kernel (switch is very fast). I fixed one thing but ... kernel switch works, but the board does not boot. Boot scripts are different on the legacy "pine64" kernel vs. next "sunxi64". If we add boot.cmd and its creation to either boot loader package or BSP? @zador.blood.stained Any objections?
zador.blood.stained Posted March 31, 2018 Posted March 31, 2018 27 minutes ago, Igor said: If we add boot.cmd and its creation to either boot loader package or BSP? Then it will break a lot of legacy stuff - boot scripts modified by old versions of nand-sata-install or by users, etc.
Igor Posted March 31, 2018 Author Posted March 31, 2018 5 minutes ago, zador.blood.stained said: Then it will break a lot of legacy stuff - boot scripts modified by old versions of nand-sata-install or by users, etc. OK. Than some safer approach. Pack boot scripts separate and install them where it's needed?
zador.blood.stained Posted March 31, 2018 Posted March 31, 2018 3 minutes ago, Igor said: OK. Than some safer approach. Pack boot scripts separate and install them where it's needed? The boot script is already packed to the BSP, the question is how to write a 100% safe logic that will decide whether the boot script can be updated.
Igor Posted March 31, 2018 Author Posted March 31, 2018 41 minutes ago, zador.blood.stained said: The boot script is already packed to the BSP, the question is how to write a 100% safe logic that will decide whether the boot script can be updated. Then perhaps this way: https://github.com/armbian/config/commit/16c96c975b6d29bc80ca9d6184a3448c135b5689
TonyMac32 Posted April 5, 2018 Posted April 5, 2018 Amlogic meson64 kernels have been rearranged, default is 4.14.y, Next is 4.16.y, dev remains mainline/master. Anyone with boards, please test. 4.14 default is lowest risk, 4.16 is brand new and a new patchset from @Neil Armstrong, and new kernel config, etc etc etc.
Igor Posted April 5, 2018 Author Posted April 5, 2018 18 minutes ago, TonyMac32 said: Amlogic meson64 kernels have been rearranged, Great! I also pin sunxi-dev and sunxi64-dev to 4.16.y to have some reference point and possibly new next if it works better. Testing and/or help with leftovers is welcome.
Igor Posted April 9, 2018 Author Posted April 9, 2018 On 27. 3. 2018 at 12:21 AM, JMCC said: As a fix, I suggest checking for /var/lib/dpkg/lock before trying to install the packages. https://github.com/armbian/config/commit/2992430d263cad9ca18fb773127fb90d628e5ab8#diff-f31297ad208d45c13b6d3d24c66823cdR35 Ubuntu Bionic can be build ... but you need to kill man-db process which hangs during debootsrap process. I made a test image for Odroid XU4 but the network was not configured and probably other things need to be fixed. Addin Bionic remains a low priority and hidden under the expert switch. armbian-config, network management needs further testing and fixing. power management on wireless devices was enabled on some during my last test. IIRC brcmfmac / mainline / h3 1
JMCC Posted April 9, 2018 Posted April 9, 2018 @Igor I am working in creating a proper set of multimedia packages for the Tinker and XU4. Here are are some guidelines I'm trying to follow, I'd appreciate if you can confirm they are OK. And any opinion is also welcome: If I understand correctly, there is only one apt.armbian.com, so board-specific packages cannot have the same names as standard packages. For example, the tweaked Rockchip "xserver-xorg-core" needs to be renamed to something like "xserver-xorg-core-rockchip" (and, of course, take care of creating the proper package relationships: "conflicts", "provides", "replaces", etc. ) I'm trying to minimize the number of extra packages. I'm trying to find a way of getting rid of the custom Hardkernel's libpixman/libsdl, I think I almost got it. For the Tinker, I'd like to include the gstreamer plugin, since it is part of the BSP to make video acceleration work. But doing so in Xenial would mean installing a whole backported gstreamer, which seems to be excessive. So we need Stretch or Bionic. How mature is the Stretch image, is it ready to be used as default Tinkerboard Desktop? My idea would be to get all the set of packages ready and make a install script for each board. Then push them to beta.armbian.com ... and cross our fingers.
JMCC Posted April 9, 2018 Posted April 9, 2018 4 hours ago, Igor said: https://github.com/armbian/config/commit/2992430d263cad9ca18fb773127fb90d628e5ab8#diff-f31297ad208d45c13b6d3d24c66823cdR35 Confirmed to work.
km1kze Posted April 10, 2018 Posted April 10, 2018 Hi, I'm a bit of a newb, but I'm in search of a OS to make my board functional (Orange Pi Plus2 H5) I installed Armbian_5.42_Orangepizeroplus2-h5_Debian_stretch_dev_4.16.0.7z The problem with this version is that the CPU and temperature shows nothing in armbianmonitor , and the UART, I2C, etc options from armbian-config are missing. Wifi is working, desktop from armbian-config didn't install - but I could install xfce manually and seems to work Also the CPU seems capped to a low frequency (probably the classic 912Mhz), having 11s in sysbench compared to 8s in the previous Armbian version (which was clocked by default to 1152Mhz) However, is the first linux distro/version that successfully installed on eMMC
Igor Posted April 10, 2018 Author Posted April 10, 2018 13 hours ago, JMCC said: If I understand correctly, there is only one apt.armbian.com, so board-specific packages cannot have the same names as standard packages. For example, the tweaked Rockchip "xserver-xorg-core" needs to be renamed to something like "xserver-xorg-core-rockchip" (and, of course, take care of creating the proper package relationships: "conflicts", "provides", "replaces", etc. ) I'm trying to minimize the number of extra packages. I'm trying to find a way of getting rid of the custom Hardkernel's libpixman/libsdl, I think I almost got it. For the Tinker, I'd like to include the gstreamer plugin, since it is part of the BSP to make video acceleration work. But doing so in Xenial would mean installing a whole backported gstreamer, which seems to be excessive. So we need Stretch or Bionic. How mature is the Stretch image, is it ready to be used as default Tinkerboard Desktop? My idea would be to get all the set of packages ready and make a install script for each board. Then push them to beta.armbian.com ... and cross our fingers. We host only our packages in a repository with a few exceptions. So far we only did acceleration methods for Allwinner legacy kernel. For example, those are the packages we build for Ubuntu Xenial: Spoiler libcedrus1_1.0.1~armbian5.42.180409+1_arm64.deb libcedrus1_1.0.1~armbian5.42.180409+1_armhf.deb libcedrus1-dev_1.0.1~armbian5.42.180409+1_arm64.deb libcedrus1-dev_1.0.1~armbian5.42.180409+1_armhf.deb libglshim_0.9.2~armbian5.42.180409+1_armhf.deb libmali-sunxi-dev_1.0-1~armbian5.42.180409+1_armhf.deb libmali-sunxi-r3p0_1.0-1~armbian5.42.180409+1_armhf.deb libump_3.0-0sunxi1~armbian5.42.180409+1_armhf.deb libump-dev_3.0-0sunxi1~armbian5.42.180409+1_armhf.deb libvdpau1_1.1.1-10~armbian5.42.180409+1_arm64.deb libvdpau1_1.1.1-10~armbian5.42.180409+1_armhf.deb libvdpau-dev_1.1.1-10~armbian5.42.180409+1_arm64.deb libvdpau-dev_1.1.1-10~armbian5.42.180409+1_armhf.deb libvdpau-sunxi1_0.5.1~armbian5.42.180409+1_arm64.deb libvdpau-sunxi1_0.5.1~armbian5.42.180409+1_armhf.deb xserver-xorg-video-armsoc-sun4i_1.4.1~armbian5.42.180409+1_armhf.deb xserver-xorg-video-fbturbo_0.4.4~armbian5.42.180409+1_arm64.deb xserver-xorg-video-fbturbo_0.4.4~armbian5.42.180409+1_armhf.deb Debian Stretch is almost ready/testing & minor fixing and can be used as a default desktop.
JMCC Posted April 10, 2018 Posted April 10, 2018 1 hour ago, Igor said: We host only our packages in a repository with a few exceptions. Yes, that was my impression, and that's why I was doing all this multimedia stuff through scripts in separate forum threads. But you told me that those things should be packed in the build process istead, remember? (https://forum.armbian.com/topic/6751-v542-desktop-on-top-of-cli-xu4-next-upgrade/?do=findComment&comment=51650) So, how can you integrate it into the build process without pushing the packages to the repos? Having the packages installed in the release images but not present in the repos can lead to many inconsistencies between different systems, and make it very difficult to spot bugs and fix them (how do you release a fix in that case?).
Igor Posted April 10, 2018 Author Posted April 10, 2018 19 minutes ago, JMCC said: So, how can you integrate it into the build process without pushing the packages to the repos? Having the packages installed in the release images but not present in the repos can lead to many inconsistencies between different systems, and make it very difficult to spot bugs and fix them (how do you release a fix in that case?). Build script has a switch from where to install packages, install prebuild or build and install. By default, its prebuild since building takes some time and it is rarely needed to recompile things. At a release stage or for nightly repository I do build them so packages are getting updates. When they are built, they are installed from a local repository. If you manage to merge/add to the existing way of building, most of the problems are solved.Packages are built in chroot https://github.com/armbian/build/blob/development/lib/chroot-buildpackages.sh This part is not very well documented and was done by @zador.blood.stained ... in case I will be unable to provide proper guidance on this.
zador.blood.stained Posted April 10, 2018 Posted April 10, 2018 44 minutes ago, JMCC said: So, how can you integrate it into the build process without pushing the packages to the repos? Everything is pushed to the repos, but in the sunxi case these packages don't conflict with upstream (at least not in a way Rockchip xserver package replaces the upstream one if I understand this correctly)
JMCC Posted April 10, 2018 Posted April 10, 2018 57 minutes ago, zador.blood.stained said: these packages don't conflict with upstream Yes, that is why I said that some packages needed to be renamed, in order to avoid those packages replacing the upstream standard packages for the other boards: 16 hours ago, JMCC said: If I understand correctly, there is only one apt.armbian.com, so board-specific packages cannot have the same names as standard packages. For example, the tweaked Rockchip "xserver-xorg-core" needs to be renamed to something like "xserver-xorg-core-rockchip" (and, of course, take care of creating the proper package relationships: "conflicts", "provides", "replaces", etc. ) That happens not only with Rockchip, but also with some Hardkernel modified packages for XU4: 16 hours ago, JMCC said: I'm trying to minimize the number of extra packages. I'm trying to find a way of getting rid of the custom Hardkernel's libpixman/libsdl, I think I almost got it. (As a matter of fact, I already made a version of Exynos Xorg driver that doesn't need any extra packages outside the upstream Xenial repos, other than Hardkernel's libmali) But, hey, whatever you see fit guys, you're the ones who make those decisions. I don't want to push anything, I'm perfectly comfortable with keeping all that stuff in some forum thread and maintaining a script from that thread. It's only that I saw that you guys had pushed XU4's mali-x11 to the beta repo, and I thought you were interested in making that package structure for enabling multimedia out-of-the-box. You guys know a lot more than me, but as everyone, you only have two hands, two eyes and 24 hours a day. That's why I thought that you could use some help. But I'll just stay with my scripts in the forum, and if you need me to do any other thing, just let me know, OK? Just know I'm here to help.
raschid Posted April 10, 2018 Posted April 10, 2018 On 5.4.2018 at 3:51 PM, Igor said: Testing and/or help with leftovers is welcome. @IgorNot quite sure but several of these unresolved patches fail in compilation because they seem to expect an other (newer?) version of sunxi-h3-h5.dtsi - the current version lacks nodes thats pervious versions had (de, mixer0, tcon0, mmc2 hdmi amd hdmi-phy).
TonyMac32 Posted April 10, 2018 Posted April 10, 2018 Rockchip updated again, all incremental patches included upstream again. If they continue to update at this frequency I'd say we can just trust that they'll do it.
Igor Posted April 10, 2018 Author Posted April 10, 2018 Just now, raschid said: Not quite sure but several of these unresolved patches fail in compilation because they seem to expect an other (newer?) version of sunxi-h3-h5.dtsi - the current version lacks nodes thats pervious versions had (de, mixer0, tcon0, mmc2 hdmi amd hdmi-phy). I know but I haven't dug into how this is done now. HDMI works out of the box which means they are probably deprecated. @jernej ?
Recommended Posts