On Fri, Mar 03, 2017 at 07:45:45PM +0100, H. Nikolaus Schaller wrote:
Am 03.03.2017 um 18:05 schrieb Tony Lindgren tony@atomide.com:
OK recall seeing igepv5 reboot not always work or the omap5-uevm reboot always not work depending on the u-boot version. Not sure if that is still happening but that hints to something not being properly re-initialized by the kernel for clocks.
I have just tried and my EVM seems now to properly "reboot" (with Linux-4.10.0 and SPL/U-Boot-2016.11) while I still remember this problem existed earlier.
Caution: the omap5-uevm has been wired to turn every warm reset into a full hwreset of palmas by default, which power cycles the omap5. This means that it has really very little excuse to fail to reboot (unless it's simply stochastic on every boot and not just reboot).
To allow palmas and omap5 to retain settings across warm reset (as they would in a mobile device), install 0 ohm resistor R195 (on bottom side, in the general neighbourhood of palmas' belly and power measurement connector J19). At your own risk, I have not tried this myself yet. :)
I have no idea what the IGEPv5 does, I don't have access to one nor its schematic. Check the device reset status register after warm reset: root:~# omapconf read 0x4ae07c04 00000001 This indicates a cold/power-on reset occurred.
So to me it looks as if some ABE clocks are not reset/restarted/locked.
Which is still strange... although ABE does seem to be somewhat special, you'd expect that either linux configures the clock source on each boot, or it never does but then it also doesn't matter whether that gets reset or not.
(Hmm, for some reason I'm suddenly thinking it's going to be fun when it's time to get device low power modes working...)
And this blocks logging for the first seconds (you notice the big delays for each attempt with dpll_abe_ck).
Note: to get real-time log output instead of a long delay after "Starting kernel", enable earlycon / early printk (is there a difference?). It's working on the uevm with my config: https://github.com/mvduin/linux/blob/work/merged/arch/arm/configs/my_omap5_d... relevant settings are probably among these: CONFIG_SERIAL_EARLYCON=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_OMAP=y CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_OMAP is not set CONFIG_DEBUG_LL=y CONFIG_DEBUG_OMAP4UART3=y CONFIG_DEBUG_OMAP2PLUS_UART=y CONFIG_EARLY_PRINTK=y
I wonder how this can be different from the OMAP5-EVM.
The uEVM took the lazy option by making every warm reset into a full palmas+omap5 hard reset instead of fixing warm reset issues.
Matthijs