eds branch fails to boot when rebased to Linux 5.4-rc1

[cklin]

I have been using the eds branch with my Intel Edison boards, manually rebasing your patches to newer Linux kernels. I have been successful in getting functioning kernel images for Linux 5.1, 5.2, and 5.3, but I am unable to get a working kernel image by rebasing your patches to Linux 5.4-rc1.

For starters, fa01aff97637a961041ef7e6279cbd32514622b6 conflicts with 7bd4227147c19860a915de6b0c775babb85c41c4, cause a build failure. I tried to resolve the problem by reverting fa01aff97637a961041ef7e6279cbd32514622b6, which allowed the build to succeed, but the kernel booted with no messages on the serial console, and after some time the watchdog kicked in automatically to reboot the device.

I understand that your attention may now be elsewhere, given that Edison had been discontinued over two years ago. Still, it would be nice to have the board working on Linux 5.4, which is going to be an LTS release.

Thank you!

[htot]

Have you tried eds-acpi branch? This is currently based on 5.4-rc1.

[cklin]

Oops! Never noticed the eds-acpi branch before. Thanks for the pointer!

[htot]

@cklin you may have closed this too soon. The eds-acpi branch uses U-Boot supplied acpi tables instead of the firmware supplied sfi tables to initialize the hardware (this might not be the exact way to describe the difference). In particular the eds branch does some hacks to make things work, and as a result user space (mraa pin naming) remains more or less compatible with the factory firmware.

But as patches from eds-acpi land upstream the hacks from eds may not apply anymore as you find.

Nevertheless I just tested eds-acpi 5.4-rc1 with the 2019.07 U-Boot and experience the same problem you report and wonder if that is related, caused by older U-Boot or by the few patches I apply on top.

[cklin]

Hmm.

I closed this bug because my original complaint, that the eds tree is not based on 5.4-rc1, is no longer relevant. I could not get the eds-acpi 5.4-rc1 kernel to work in a quick test, but it was only a quick test. I cannot say, with high confidence, that the problem is with the kernel itself (for example, I was still using a fairly old U-boot image), and I did not have much time to gather more information. And keeping the bug open with insufficient information just seemed ... rude, especially in light of all that andy-shev have done for us.

If you think there is a problem with eds-acpi 5.4-rc1 and has relevant information, then we probably should open a new bug.

[htot]

Alright. And there is always -rc2 coming up.

[andy-shev]

There is U-Boot v2019.10 out. And good news I found the root cause and had updated my branch to fix it. Should work now, please test.