On 15/11/18 10:33, Sai Prakash Ranjan wrote:
On 11/13/2018 3:14 PM, Srinivas Kandagatla wrote:
Hi Sai,
On 25/10/18 15:36, saiprakash.ranjan@xxxxxxxxxxxxxx wrote:
"If I disable dma node and LS-UART0, then I don't see any crash and
ftrace also works fine"
And one more observation is that even without ftrace cmdline, if I use
earlycon and disable dma, I face the same crash.
So basically this seems to be some kind of earlycon and dma issue and
not ftrace(I can be wrong).
So adding Srinivas for more info on this dma node.
Its Interesting that my old email conversations with SBoyd show that I
have investigated this issue in early 2016!
My analysis so far:
This reason for such behavior is due the common iface clock
(GCC_BLSP1_AHB_CLK) across multiple drivers(serial ports, bam dma
and other low speed devices).
The code flow in DB410C is bit different, as the uart0 is first
attempted to set as console and then uart1, this ordering triggers
pm state change uart_change_pm(state, UART_PM_STATE_OFF) from serial
core while setting up uart0, this would go and disable all the
clocks for uart0.
As uart1 is not setup Yet, and earlycon is still active, any
attempts by earlycon to write to registers would trigger a system
reboot as the clock was just disabled by uart0 change_pm code.
This can even be triggered with any drivers like spi which uses same
clock I guess.
Hope it helps,
Either earlycon needs to reference the clocks or those clocks needs to
be marked always-on (but only with earlycon).
Also just for a note: apq8096-db820c.dtsi shows UART0 is disabled
because
bootloader does not allow access to it. Could this also be the case
for db410c?
No, this is not the case with DB410c. DB820c has added restrictions in
TZ, I think new booloaders should have solved this issue.
Hi Srinivas,
Thanks a lot for pointing out the cause of crash.
I just tried setting GCC_BLSP1_AHB_CLK with flag CLK_IS_CRITICAL and the
crash disappears.
But I suppose setting CLK_IS_CRITICAL is not the solution?
Yes, this is not the solution, but it proves that the hand-off between
booloaders and kernel is the issue.
In general there is wider issue with resources hand-off between
bootloader and kernel.
There has been some proposal in the past by Viresh for a new framework
called boot-constriants (https://lkml.org/lkml/2017/12/14/440) which am
not sure if its still actively looked at. But something similar should
be the way to address such issues.
--srini
Thanks,
Sai
