Hello.
My Freescale TWR-MPC5125 board instantly reboots if I touch
any physical address on the LocalPlus Bus (LPB) for the first time
when Linux has already booted.
This effect is reproduced by using /dev/mem or loading a kernel module
which works with any peripherals on LPB.
It took me some time to find out that such crash is caused by
clk_disable_unused() in drivers/clk/clk.c, which disables
LocalPlus Controller (LPC) clock if I don't touch LPB addresses in the
previous initcalls. So starting Linux with clk_ignore_unused bootparam
or inserting dummy LPB reading to some initcall is a temporary fix.
Is it correct to gate LPC clock? If yes, how to avoid the mentioned
crashes properly?
There's a piece of code in arch/powerpc/platforms/512x/clock-commonclk.c
which is doubtful for me:
/*
* pre-enable those "internal" clock items which never get
* claimed by any peripheral driver, to not have the clock
* subsystem disable them late at startup
*/
clk_prepare_enable(clks[MPC512x_CLK_DUMMY]);
clk_prepare_enable(clks[MPC512x_CLK_E300]); /* PowerPC CPU */
clk_prepare_enable(clks[MPC512x_CLK_DDR]); /* DRAM */
clk_prepare_enable(clks[MPC512x_CLK_MEM]); /* SRAM */
clk_prepare_enable(clks[MPC512x_CLK_IPS]); /* SoC periph */
clk_prepare_enable(clks[MPC512x_CLK_LPC]); /* boot media */
Does it mean that these clocks should be registered with
CLK_IGNORE_UNUSED flag?
Thanks a lot.
Best regards,
Alexander
On 26/11/2014 12:49, Alexander Popov wrote:
> Hello.
>
Hi.
> My Freescale TWR-MPC5125 board instantly reboots if I touch
> any physical address on the LocalPlus Bus (LPB) for the first time
> when Linux has already booted.
>
> This effect is reproduced by using /dev/mem or loading a kernel module
> which works with any peripherals on LPB.
>
> It took me some time to find out that such crash is caused by
> clk_disable_unused() in drivers/clk/clk.c, which disables
> LocalPlus Controller (LPC) clock if I don't touch LPB addresses in the
> previous initcalls. So starting Linux with clk_ignore_unused bootparam
> or inserting dummy LPB reading to some initcall is a temporary fix.
>
> Is it correct to gate LPC clock?
For me yes, because it's physically present on SoC and could not be muxed.
> If yes, how to avoid the mentioned
> crashes properly?
>
> There's a piece of code in arch/powerpc/platforms/512x/clock-commonclk.c
> which is doubtful for me:
>
> /*
> * pre-enable those "internal" clock items which never get
> * claimed by any peripheral driver, to not have the clock
> * subsystem disable them late at startup
> */
> clk_prepare_enable(clks[MPC512x_CLK_DUMMY]);
> clk_prepare_enable(clks[MPC512x_CLK_E300]); /* PowerPC CPU */
> clk_prepare_enable(clks[MPC512x_CLK_DDR]); /* DRAM */
> clk_prepare_enable(clks[MPC512x_CLK_MEM]); /* SRAM */
> clk_prepare_enable(clks[MPC512x_CLK_IPS]); /* SoC periph */
> clk_prepare_enable(clks[MPC512x_CLK_LPC]); /* boot media */
>
> Does it mean that these clocks should be registered with
> CLK_IGNORE_UNUSED flag?
>
Yes, in my opinion this groups of clocks may be considered as "always on",
but I don't think that MPC512x_CLK_LPC is an "internal" clock and then
It could be enable if really used only.
In detail:
- may be good to enable MPC512x_CLK_LPC only when localbus is enabled
by the dts
- if enabled, MPC512x_CLK_LPC have to setup with CLK_IGNORE_UNUSED
flag because never get claimed by any driver.
I put in CC "Gerhard Sittig" also beacuse it might be interesting to
know his point of view as the author of mpc512x common clock driver.
Regards,
Matteo
> Thanks a lot.
> Best regards,
> Alexander
> _______________________________________________
> Linuxppc-dev mailing list
> [email protected]
> https://lists.ozlabs.org/listinfo/linuxppc-dev
02.12.2014 13:47, Matteo Facchinetti пишет:
> On 26/11/2014 12:49, Alexander Popov wrote:
>> Hello.
> Hi.
Thanks for your reply, Matteo.
I've looked deeper and have more information about the crash.
>> My Freescale TWR-MPC5125 board instantly reboots if I touch
>> any physical address on the LocalPlus Bus (LPB) for the first time
>> when Linux has already booted.
>>
>> This effect is reproduced by using /dev/mem or loading a kernel module
>> which works with any peripherals on LPB.
>>
>> It took me some time to find out that such crash is caused by
>> clk_disable_unused() in drivers/clk/clk.c, which disables
>> LocalPlus Controller (LPC) clock if I don't touch LPB addresses in the
>> previous initcalls.
My first diagnosis was not correct: clk_disable_unused() doesn't disable
LPC clock because in arch/powerpc/platforms/512x/clock-commonclk.c
we call:
clk_prepare_enable(clks[MPC512x_CLK_LPC]);
But clk_disable_unused() disables NFC clock as unused which seems to be
a real reason of board crash.
>> So starting Linux with clk_ignore_unused bootparam
>> or inserting dummy LPB reading to some initcall is a temporary fix.
In fact clk_ignore_unused bootparam helps to avoid disabling NFC clock.
The board crash is reproduced again if I perform the following steps:
1. disable NFC clock in uboot by clearing NFC_EN bit in SCCR1 register,
2. boot Linux with clk_ignore_unused,
3. touch any LPB address.
At the same time disabling NFC clock and reading from LPB certainly
in uboot doesn't make MPC5125 reset instantly. So I can't reproduce
the crash in uboot. It looks like we do something wrong in Linux.
> - may be good to enable MPC512x_CLK_LPC only when localbus is enabled
> by the dts
> - if enabled, MPC512x_CLK_LPC have to setup with CLK_IGNORE_UNUSED
> flag because never get claimed by any driver.
This approach didn't help to fix the crash because in fact
clk_disable_unused() doesn't disable LPC clock as I wrote above.
> I put in CC "Gerhard Sittig" also beacuse it might be interesting to
> know his point of view as the author of mpc512x common clock driver.
Surely. Thanks.
Best regards,
Alexander
On 16/12/2014 13:00, Alexander Popov wrote:
> 02.12.2014 13:47, Matteo Facchinetti пишет:
>> On 26/11/2014 12:49, Alexander Popov wrote:
>>> So starting Linux with clk_ignore_unused bootparam
>>> or inserting dummy LPB reading to some initcall is a temporary fix.
>
> In fact clk_ignore_unused bootparam helps to avoid disabling NFC clock.
> The board crash is reproduced again if I perform the following steps:
> 1. disable NFC clock in uboot by clearing NFC_EN bit in SCCR1 register,
> 2. boot Linux with clk_ignore_unused,
> 3. touch any LPB address.
>
Could you see the Reset Status Register (RSR) after board crash?
When boad reset, you may stop uboot in console and then print the value
of this register.
This could be help to see what happen internally to the microcontroller.
Hello Matteo,
sorry for such a long delay in replying, now I have my board back again.
19.12.2014 12:38, Matteo Facchinetti пишет:
> On 16/12/2014 13:00, Alexander Popov wrote:
>> In fact clk_ignore_unused bootparam helps to avoid disabling NFC clock.
>> The board crash is reproduced again if I perform the following steps:
>> 1. disable NFC clock in uboot by clearing NFC_EN bit in SCCR1 register,
>> 2. boot Linux with clk_ignore_unused,
>> 3. touch any LPB address.
>
> Could you see the Reset Status Register (RSR) after board crash?
> When boad reset, you may stop uboot in console and then print the value
> of this register.
>
> This could be help to see what happen internally to the microcontroller.
I've reproduced TWR-MPC5125 crash without Linux only in uboot.
This is the annotated procedure:
=> md.l 0x80000e10 /* Reset Status Register */
80000e10: 60000000 /* All flags are cleared (just powered on) */
=> md.l 0x80000f04 /* System Clock Control Register 1 */
80000f04: e404b600 /* NFC clock is enabled */
=> md.l 0xfff00000 /* Reading from MRAM living at LPB CS0 */
fff00000: cafea134 /* Works fine */
=> mw.l 0x80000f04 0xc404b600 1 /* Disable NFC clock */
=> md.l 0x80000f04
80000f04: c404b600 /* NFC clock is disabled now */
=> md.l 0xfff00000 /* Reading from MRAM again */
fff00000:
/* The board has just reset */
U-Boot 2009.03-00004-gd37ab38 (Apr 14 2010 - 10:48:22) MPC512X
CPU: MPC5125 rev. 1.0, Core e300c4 at 393.216 MHz, CSB at 196.608 MHz
...
=> md.l 0x80000e10 /* Read RSR */
80000e10: 60000040 /* Only external HRESET1 event has occurred */
But rising of EXT1HRS flag is not special for this crash.
EXT1HRS is similarly set if I execute 'reset' command in uboot
or call 'reboot' from Linux.
Thanks.
Best regards,
Alexander