research Boot hang for LibreELEC 5.5.6 Kernel

Recommended Posts

Hi, Armbian gurus,


I'm trying to make the build system to build image with LibreELEC kernel tree for PineH64

I heard the kernel is patched for being better at hardware decoding

Here are what I have done in order:

1. Retrieve patched kernel tree from LibreELEC build system. Upload the patched kernel tree to my gitlab account.

2. Modify config/sources/families/include/sunxi64_common.inc to make KERNEL_SOURCE = my previous repo; KERNELBRACH = master. To make it fetchable during bilding.

3. Modify lib/compilation-prepare.sh: skip aufs patch.

4. Modify lib/compilation.sh: skip advanced_patch in compile_kernel()


After all these hassle, I can use compile.sh to build an Armbian 64 bit image with the 5.5.6 patched.

BUT unfortunately, I flash the image and found it cannot boot properly.


So here are my question:

1. How do you typically debug boot problem for PineH64.

2. Do you think anything could go wrong in those procedure?

3. Do I need to upgrade u-boot as well? It's using v2019.10 as far as I can tell.


Thank you.



Share this post

Link to post
Share on other sites

Hi, Werner


Thank you for the tip. You are certainly appreciated.

I will try to find whatever went wrong.


If anyone discover something wrong with those steps, please do not hesitate to share here.

Thank you.

Share this post

Link to post
Share on other sites

Hi, Armbian gurus,


These are the 2 copies of log I captured by USB-TTL.

Armbian + LibreELEC 5.5.6 kernel

Normal Bootable Armbian


The most critical difference I guess is this:

## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
116 bytes read in 2 ms (56.6 KiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
9791617 bytes read in 983 ms (9.5 MiB/s)
15812616 bytes read in 1585 ms (9.5 MiB/s)

May someone share more insight about what could be wrong with this header checking stuff?

For example: which part of building might trigger this misbehavior?

Thank you.

Share this post

Link to post
Share on other sites

Hi, Armbian gurus,


I discover that the boot.cmd contains many statements about this FDT, including

"fdt addr ${fdt_addr_r}" and "fdt resize 65536."


May I ask about what is the proper size for these value? How to calculate these value?

With DTB/DTS replacement happened along the replaced kernel tree, could that trigger this problem?


I have to confess that I have very limited knowledge about u-boot, please drop me some tip or recommended reading if you think it's going to help, while I'm doing my own reading document from u-boot at the same time.

Thank you.

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.