8

I have enabled Secure Boot on an embedded device successfully. The problem is that when I am booting in this mode the process seems to get stuck right after the line:

Starting kernel ...

once U-boot has copied the kernel in memory and issued a bootm command.

In a debugger I am able to capture that the PC is stuck on a yield instruction followed by an assignment to pc = pc-4 -- so essentially a loop.

I have never brought up linux at this low of a level before so I am unsure where to begin looking. I did notice, though, that I was able to successfully boot the kernel image when not in secure mode, so this might be a more appropriate questions for the vendor.

1) In general, where can I find U-boot diagnostic information regarding the execution hand-off stage?

2) At what point is execution fully given to the kernel? i.e. when is U-boot defunct?

sherrellbc
  • 2,461
  • 7
  • 28
  • 41
  • The "Starting kernel ..." message is not from U-Boot but from the Linux Kernel provided "zImage" wrapper as it starts the kernel after decompression. If you have a debugger, have it start looking in as soon as that code begins execution (ie you start executing at wherever you've said the entry point is). – Tom Rini Jun 23 '16 at 18:37
  • Is this true on all platforms? The device is a rather obscure embedded system that boots a FIT image; the kernel, device tree bridge, and roofts are all bundled into this one "itb" binary that is loaded/executed by U-Boot. – sherrellbc Jun 23 '16 at 19:05
  • I misspoke, sorry. That is the last print from U-Boot. But still, my recommendation is to start by having your debugger halt at the entry point and work from there. – Tom Rini Jun 24 '16 at 20:00
  • When the zImage decompresses, both the compressed and decompressed kernel are in memory, for a period of time. I used to get the same problem when my kernel was to large to fit into memory. – jc__ Sep 21 '16 at 12:44

3 Answers3

3

May be you can dump the memory of the linux early prints using following procedure. The cause may be, kernel is booting but it hung before console init. Also put prints in kernel entry point of uboot and confirm control is hand over to kernel.

Find the System.map file. Use below command to identify the log_buf address:

grep __log_buf System.map

This will output something like

c0352d88 B __log_buf

Warm boot the board (Contents in RAM should not be erased).

In Uboot dump the memory of __log_buf (c0352d88). It will dump the Kernel console prints. So you can identify where the extact hung happens.

countermode
  • 7,373
  • 5
  • 31
  • 58
Rajeshkumar
  • 221
  • 1
  • 2
  • 6
3

I have had faced the same issue and have found a solution. The issue is in one of the u-boot structure field that stores the size of the uncompressed linux kernel. The u-boot is not populating this field with the uncompressed size, that the linux kernel uses later to resize its stack, thus putting the system into an undefined state.

Once u-boot prints the Starting kernel... message, the next message should be Uncompressing Linux... done, booting the kernel after u-boot transfers a SMM Handler for the kernel to take-over the execution, and maybe the kernel is looking for this field. If you are working on a x86 based system,the uncompression would be in the following file directories:

arch/x86/boot/uncompressed/head_32.S
arch/x86/boot/uncompressed/piggy.S

The solution is to use the latest u-boot foun in here: https://github.com/andy-shev/u-boot

However, if you are using a custom u-boot, you need to look for this field.

Sachin Mokashi
  • 171
  • 6
1

x86? Boot with earlycon=efifb or earlyprintk=vga. I am mentioning both since there was a change around the time of commit 69c1f396f25b805aeff08f06d2e992c315ee5b1e from earlyprintk to earlycon.

jjorge
  • 11
  • 1