[Letux-kernel] OMAP5: Debugging kernel not starting...

H. Nikolaus Schaller hns at goldelico.com
Sun Sep 9 10:42:26 CEST 2018

Hi Tony,
we have observed that the OMAP5 isn't properly rebooting.
I.e. if we boot and then type "reboot", everything works fine

## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-4.18.6-letux-lpae+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4863832 Bytes = 4.6 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Kernel Image ... OK
   Loading Device Tree to 8ffee000, end 8ffff88e ... OK

Starting kernel ...

Then the kernel hangs.

On some boards we can then boot with activating the
RESET but on some others we have to (force) poweroff
and power on again until the kernel starts. So I think
either some PLL or some SMPS or LDO is stuck or not
initialized the same with power-on or by reboot.

But it does not seem to be a Palmas issue since I have
added i2cdump to report all Palmas registers in U-Boot
and there is no (significant) difference between
poweroff+on and reboot. So I have not found a bit that
can be used to predict if the kernel will boot or not.

Next I have digged out an old technique I had used once
for OMAP3 to read out the kernel log *before* the UARTs
were initialized:


but it seems to no longer work. The log buffer isn't
at a fixed address any more. I hacked a logbuf scanner
into U-Boot and it reports randomly changing addresses
where it finds logbuf entries but they appear to be

Then I remembered printascii() which is no longer

So what is the canonical way to debug such issues
with modern kernels? Is it possible to get something
like printascii()? Or make the kernel log go to a
fixed address? Or should I hack printk() to write
a copy to a private buffer at a static address?

BR and thanks,

More information about the Letux-kernel mailing list