Jump to content

Next major upgrade v5.60


Igor

Recommended Posts

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

testing-task-lapotato.png

 

 

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.

 

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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:

  1. 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

Link to comment
Share on other sites

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 

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?).

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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. :)

 

 

 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines