Hi Fabrizio,
On Fri, Jan 26, 2018 at 12:52 PM, Fabrizio Castro
<fabrizio.castro@xxxxxxxxxxxxxx> wrote:
>> Subject: Re: [RFC 01/37] ARM: shmobile: Add watchdog support
>> On Thu, Jan 25, 2018 at 7:02 PM, Fabrizio Castro
>> <fabrizio.castro@xxxxxxxxxxxxxx> wrote:
>> > On R-Car Gen2 and RZ/G1 platforms, we use the SBAR registers to make non
>> > boot CPUs run a routine designed to bring up SMP and deal with hot plug.
>> > The value contained in the SBAR registers is not initialized by a WDT
>> > triggered reset, which means that after a WDT triggered reset we jump
>> > to the SMP bring up routine, preventing the system from executing the
>> > bootrom code.
>>
>> Thanks for your patch!
>
> Thank you for looking into this!
>
> I am not going to reply to your comments on the other patches for now, as we need to find a solution for this particular patch we are all happy with first.
> A change to this patch may impact the other patches as well.
>
>> > The purpose of this patch is to jump to the bootrom code in case of a
>> > WDT triggered reset, and keep the SMP functionality untouched.
>> > In order to tell if the code had been called due to the WDT overflowing
>> > we need to inspect flag WOVF from register RWTCSRA, however for this
>> > to work smoothly we need to make sure that RWDT clock is ON.
>> > Since it's not wise to interfere with the clock configuration from
>> > within this routine, a flag has been put in place
>> > (shmobile_wdt_clock_status) so that the watchdog driver can tell
>> > shmobile_boot_vector when the clock is ON, and therefore there is no
>> > need for shmobile_boot_vector to mess up with the clock registers.
>> >
>> > Bit WOVF survives a watchdog triggered reset, and it is usually cleared
>> > by the bootloader. Checking the MMU enable bit from register SCTLR
>> > allows us to make the code a little bit more robust (just in case the
>> > bit wasn't cleared up), as right after a reset the MMU is disabled,
>> > and when Linux is running the MMU is enabled. Also, accessing RWTCSRA
>> > physical address is safe when the MMU is down.
>>
>> Checking a hardware register is indeed a better solution than my original
>> idea to let SMP bringup set a flag in RAM, as the former is less racy.
>
> Also, such a flag would not be accessible after the reset gets triggered.
It would, if it's stored in e.g. ICRAM.
>> However, as you can probably imagine, I don't like the
>> shmobile_wdt_clock_status part ;-)
>
> Neither do I! :-D
Good ;-)
>> Isn't is sufficient to check the MMU enable bit?
>
> I am afraid it isn't, when bringing up SMP the cores will read the MMU flag as disabled, to make things worse at that precise point in time the rwdt clock is disabled.
> If the system just restarted due to the watchdog, then when you read WOVF chances are you are going to read '1', hence the system will fail to bring up SMP.
OK, so I was mislead by the MMU check.
>> However, that would precludes uClinux (do we care?).
>
> The MMU will be constantly disabled in this case, wouldn't it? Therefore the reset vector will always proceed with the testing of variable "shmobile_wdt_clock_status", and it'll finally test WOVF only when it's safe to do so. If WOVF is set, then we still jump to the bootrom code. if WOVF is not set, then we jump to shmobile_boot_fn. Could you please elaborate your thoughts a little bit more?
>
>> Is there any other register/bit that's reset when the watchdog is
>> triggered, and always set by Linux?
>
> Not that I know of, but you may know better ;-P
> Any suggestion?
Any chance WDTRSTCR.RWDT_RSTMSK is reinitialized to 1 on watchdog reset?
Probably not, as the Hardware User's Manual says the register is
initialized on power on reset caused by PRESET#.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
