N2 kernel issue

  • Hi,

    i also have boot problems from SD, but with Odroid N2+:

    This is with a manual built with LE13/VDRSternELEC. But the problem is the same with a downloadable LE12 from the SD Creator.

    I will test with an older LE image and a most recent again. Not sure, what went wrong here.

  • I've moved the post into its own thread as the UART log shared shows the system boot from SD card without any errors (and thus whatever the issue is, it's not the same thing the C2 thread is about). Something goes wrong when it boots the kernel. The splat suggests something with the HDMI driver (so something in the display chain).

    Can you successfully boot from an eMMC module to prove it really is SD related (which it almost certainly isn't)?

    Can you successfully boot this image? https://chewitt.libreelec.tv/testing/LibreE…droid-n2.img.gz

  • Thanks for moving the post.

    I do not own an eMMC module, so i need to try SD. For a long time i used an arm-ARCH image which worked and yesterday i tried to boot the aarch64 one. I will try the linked image and give feedback. I have seen, there was some activity on drm/meson in the kernel, maybe it's one of those....

  • There's a drip-feed of bindings changes and other unimportant things to DRM code; nothing of any real meaning was changed in aeons. I also have an N2+ running here for boot testing LE changes and I'd notice kernel splats (none seen).

  • Edited 3 times, last by rellla (June 20, 2024 at 6:00 PM).

  • So, i did a manual bisect with the nightly builds and this is the result:

    Code
    LibreELEC-AMLGX.aarch64-12.0-nightly-20231210-e521363-odroid-n2.img.gz (sha256) ok
    LibreELEC-AMLGX.aarch64-12.0-nightly-20240228-c542431-odroid-n2.img.gz (sha256) ok
    LibreELEC-AMLGX.aarch64-12.0-nightly-20240321-1972ad8-odroid-n2.img.gz (sha256) ok
    LibreELEC-AMLGX.aarch64-12.0-nightly-20240322-5d8c60d-odroid-n2.img.gz (sha256) ok
    LibreELEC-AMLGX.aarch64-12.0-nightly-20240323-353213e-odroid-n2.img.gz (sha256) ok
    LibreELEC-AMLGX.aarch64-12.0-nightly-20240326-968e285-odroid-n2.img.gz (sha256) not ok
    LibreELEC-AMLGX.aarch64-12.0-nightly-20240403-90a58fa-odroid-n2.img.gz (sha256) not ok
    LibreELEC-AMLGX.aarch64-12.0-nightly-20240416-8b61557-odroid-n2.img.gz (sha256) not ok
    LibreELEC-AMLGX.aarch64-12.0-nightly-20240617-6b04385-odroid-n2.img.gz (sha256) not ok

    The issue was introduced somewhere between 353213e and 968e285. I didn't have a look into the commit history but will do so.

    I'm still wondering, why it seems to be me the only one having this issue...

    Edited once, last by rellla (June 23, 2024 at 2:22 PM).

  • Code
    for i in $(git rev-list --ancestry-path 353213e..968e285); do git show $i; done

    That ^ diffed the commits between the good/bad change and I don't see anything major in the list, but there are a load of u-boot and boot config changes. I know the bulk of them are good and really the single difference between N2 and other boards is the use of FDTDIR instead of normal FDT in extlinux.conf. So on a hunch, if you remove the trailing / from the FDTDIR line so it reads "FDTDIR /amlogic" not "FDTDIR /amlogic/" does it boot properly now?

  • That makes no sense to me because the default u-boot behaviour (without the patch) is to search for dtb files in /amlogic/ and that's where the files exist (image below shows the layout on the SD card). In older LE images the files are placed in the root folder, hence needing the patch.

    I'm wondering if the paths are being appended. If you create /amlogic/amlogic/meson-g12b-odroid-n2-plus.dtb on the default image (without the patch) does the board boot?

  • Urgh.. I didn't see that the first time (need new eyeballs). So my guess about needing /amlogic/amlogic/*.dtb is correct. That patch fixes another variant of the issue but is only relevant for u-boot 2024.07 (we are on 2024.04).

  • Urgh.. I didn't see that the first time (need new eyeballs).

    Me too ;)

    Afaics label_boot() in pxe_utils.c composes a new fdtfile from ftdir and ftdfile, so if fdtdir is "amlogic" and fdtfile has the "amlogic" prepend, we get a doubled amlogic in the end.

  • Thanks for confirming. I'll push some changes out.

    EDIT, fix merged to master now. Separate fix will go to LE12 in a couple of days I'd guess.