Hi Tony, we have observed that the OMAP5 isn't properly rebooting. I.e. if we boot and then type "reboot", everything works fine until:
## 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:
https://www.denx.de/wiki/DULG/LinuxPostMortemAnalysis
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 incomplete.
Then I remembered printascii() which is no longer available.
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, Nikolaus