Build: [ mvebu ] Move mvebu-legacy to lk 4.19, current to lk5.4

[heisath]

Hi,

I was talking with Igor about dropping Linux Kernel 4.14 for mvebu, now that all features are supported (and stable) in 4.19.

This would mean that mvebu-legacy became lk4.19, mvebu-current lk5.4 and mvebu-dev would be attached to kernel.org / stable (currently 5.5 then some lts release).

I think we could achieve this until the next release, 20.05 (so not the upcoming one).

I made a branch with the changes and tested it on all mvebu boards. I could not find anything againgst it. But we have enough time and should discuss it.

@aprayoga @g-provost

(Changes are on : https://github.com/armbian/build/tree/mvebu-kernel-update)

Regards,
count-doku

[heisath]

I closed the PR for stretch and moved the changes here. Then we agree on waiting for 20.05 (around May) release to see if Debian Buster is working with OMV5.

[aprayoga]

I think we need to test whether XOR engine and mv_cesa still working on LK 5.4

[heisath]

I tested mv_cesa by creating a LUKS volume on some SATA drive and checking /proc/interrupts to make sure it is using CESA:

root@helios4:~# cryptsetup -v -y -c aes-cbc-essiv:sha256 luksFormat /dev/sda1
[...]
root@helios4:~# cat /proc/interrupts
           CPU0       CPU1
 17:     180325     175647     GIC-0  29 Edge      twd
 18:          0          0      MPIC   5 Level     armada_370_xp_per_cpu_tick
 19:          0          0      MPIC   3 Level     arm-pmu
 20:         54          0     GIC-0  34 Level     mv64xxx_i2c
 21:          0          0     GIC-0  35 Level     mv64xxx_i2c
 22:        876          0     GIC-0  44 Level     ttyS0
 32:          0          0     GIC-0  41 Level     f1020300.watchdog
 36:          0          0     GIC-0  96 Level     f1020300.watchdog
 37:       5387        953      MPIC   8 Level     eth0
 38:          0          0     GIC-0  50 Level     ehci_hcd:usb1
 39:     211943          0     GIC-0  51 Level     f1090000.crypto
 40:     194470          0     GIC-0  52 Level     f1090000.crypto
 41:          0          0     GIC-0  53 Level     f10a3800.rtc
 42:      42149          0     GIC-0  58 Level     ahci-mvebu[f10a8000.sata]
 43:          0          0     GIC-0  60 Level     ahci-mvebu[f10e0000.sata]
 44:      23190          0     GIC-0  57 Level     mmc0
 45:          0          0     GIC-0  48 Level     xhci-hcd:usb2
 46:       1294          0     GIC-0  49 Level     xhci-hcd:usb4
 47:          2          0     GIC-0  54 Level     f1060800.xor
 48:          2          0     GIC-0  97 Level     f1060900.xor
 49:          0          0  f1018100.gpio  23 Level     0-0020
 50:          0          0  f1018100.gpio  20 Edge      f10d8000.sdhci cd
 51:          3          0  f1018100.gpio  18 Edge      Wake-On-LAN
IPI0:          0          1  CPU wakeup interrupts
IPI1:          0          0  Timer broadcast interrupts
IPI2:     221524     286595  Rescheduling interrupts
IPI3:        420        511  Function call interrupts
IPI4:          0          0  CPU stop interrupts
IPI5:       1413        843  IRQ work interrupts
IPI6:          0          0  completion interrupts
Err:          0

I am unsure how to test XOR, probably by creating a RAID5 or 6 set, but I don't have enough spare disks lying around to test that.

[aprayoga]

I will test the XOR.

Should we remove the fake-hwclock and make use of hardware RTC ?
There was a case on old kernel (i think lk4.4 from marvell) that if rtc has invalid register value and causing the system failed to boot. Systemd emit error time has been changed (something like https://github.com/systemd/systemd/issues/1143). To solve the problem, user need to do "date reset" twice in u-boot.
It seems the patch on #1715 already handle the problem. on my side i haven't tested it with invalid register value.

[g-provost]

@aprayoga Yes we should take the opportunity to ensure Helios4 use RTC clock and not fake-hwclock. Linking the project card here.

BTW let's not forget to keep the github project page for mvebu up to date.

[heisath]

I think I added every issue / pr to the mvebu project.

Does one of you have access to jira? Or hangs out in our irc sometimes?

[g-provost]

@count-doku Yeah it was just a reminder to all including myself ;-)

Does one of you have access to jira? Or hangs out in our irc sometimes?

Do you want some kind of direct communication pipe with Aditya and me ? If yes we can add you to our slack workspace, I mean if it works for you ?

[heisath]

Regarding Jira, it is for release planning etc. I added some major PRs there for the release notes, if you want something else on there just let me know.https://armbian.atlassian.net/projects/AR/versions/10001/tab/release-report-all-issues (unsure if you can look at the link without account)

Regarding direct communication, I guess forum messages are good enough? Was asking for irc just to hang out and talk about long term ideas. I also use slack with my company, so if you want you can invite me there.

[g-provost]

Yeah we have experience with Jira ;-) I actually didn't know (or I forgot) that Armbian used Jira. Yes we can see the issue page. Are you guys only using Jira for Issue or more ?

Please send me by email your slack account in we had you, this way I stop polluting this thread.

[igorpecovnik]

Are you guys only using Jira for Issue or more ?

Jira is currently under testing and developing a general project overview. Summing only things which can be covered, limited write/add access, used mainly as a release management and making tool. ATM.

A document how-to and for what will follow.

[g-provost]

I was discussing a while back with @count-doku about what LK version should be legacy. If we refer to the Linux Kernel official LTS calendar https://www.kernel.org/category/releases.html I'm not sure 4.19 is the right choice.

As you can see in the LTS release table the EOL is very variable between one LTS release and another ( e.g 4.19 only got 2+ years of support, while 4.14 has 6+ years of support ). So the question is do we want legacy to become 4.19 or to remain 4.14 since 4.19 will be EOL this December, while 4.14 only in January 2024 ?

@igorpecovnik @lanefu what's your opinion about this guys ? And I guess this is not only about mvebu family.

[igorpecovnik]

It depends on this particular hardware support. I would not stick strongly to that table.

If 4.19.y is in (much) better shape else 4.14.y ... Legacy kernel is here to cover odd corner cases.

[heisath]

If this can be decided per hardware I think we should keep 4.14 as legacy. There's now difference in hardware support between 4.14 and 4.19 so leaving the older one + adding 5.4 as new current would be the best option imho.

[igorpecovnik]

There's now difference in hardware support between 4.14 and 4.19 so leaving the older one + adding 5.4 as new current would be the best option imho.

OK, fine for me. We are sticking to 4.14.y here.

[g-provost]

After digging a bit more on why some LTS has longer support than other. I found this interesting thread answered by Greg Kroah-Hartman which linked back to his on blog post What Stable Kernel Should I Use?

In a nutshell, the reason why some LTS have longer support :

These releases have traditionally been supported by the community for 2 years, sometimes longer for when a major distribution relies on this (like Debian or SLES). However in the past year, thanks to a lot of suport and investment in testing and infrastructure from Google, Linaro, Linaro member companies, kernelci.org, and others, these kernels are starting to be supported for much longer.

Should we choose 4.14 because it has longer support than 4.19 :

[...] only use older LTS releases in a device that you fully control, or lock down with a very strong security model (like Android enforces using SELinux and application isolation). Never use these releases on a server with untrusted users, programs, or virtual machines.

So I answer my own question, we should actually move to 4.19.

@count-doku Wasn't 4.19 solving some issue on the mPCIe ? So better we don't create exception and switch to 4.19 for the whole mvebu family.

[heisath]

Nice find. Good point on security implications.

After my recent work before 20.02 4.14 and 4.19 are the same for clearfog, so it does not matter.

I will edit the mvebu-kernel-update branch today and create a PR to master. Then we have lots of time to test things out before next release.