Hi Fabrizio,

On Thu, Jan 25, 2018 at 7:02 PM, Fabrizio Castro
[off-list ref] 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!

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.
However, as you can probably imagine, I don't like the
shmobile_wdt_clock_status part ;-)

Isn't is sufficient to check the MMU enable bit?
However, that would precludes uClinux (do we care?).
Is there any other register/bit that's reset when the watchdog is
triggered, and always set by Linux?

SMP bringup, CPU hot plug, and suspend to RAM work as normal.

shmobile_boot_vector is not only used for R-Car Gen2 and RZ/G1 SoCs, but
also for EMMA Mobile, SH/R-Mobile, and R-Car H1.  Hence this breaks SMP
for the latter (and their build if ARCH_RENESAS=n, due to missing
shmobile_wdt_clock_status).

Since shmobile_boot_vector has become bigger, "reg" property of nodes
compatible with "renesas,smp-sram" now need to be set to "<0 0x64>".

This breaks backwards compatibility with old DTs declaring a too small
smp-sram area. If the area is too small, you should fallback to the old and
smaller code.

This should become e.g. rcar_gen2_boot_vector_wdt

+/*
+       if (SCTLR_MMU == 1)
+               goto shmobile_smp_continue;
+*/
+       mrc     p15, 0, r1, c1, c0, 0           @ r1 = SCTLR
+       and     r0, r1, #SCTLR_MMU
+       cmp     r0, #SCTLR_MMU
+       beq     shmobile_smp_continue
+/*
+       if (shmobile_wdt_clock_status != RWDT_CLOCK_ON)
+               goto shmobile_smp_continue;
+*/
+       ldr     r0, #shmobile_wdt_clock_status
+       ldr     r1, #clock_on
+       cmp     r0, r1
+       bne     shmobile_smp_continue
+
+/*
+       if (RWTCSRA_WOVF == 0)
+               goto shmobile_smp_continue;
+*/
+       ldr     r0, rwtcsra
+       mov     r1, #0
+       ldrb    r1, [r0]
+       and     r0, r1, #RWTCSRA_WOVF
+       cmp     r0, #RWTCSRA_WOVF
+       bne     shmobile_smp_continue
+
+/*
+       goto bootrom;
+*/
+       ldr     r0, bootrom
+       bx      r0
+
+shmobile_smp_continue:

This should become

    ENTRY(shmobile_boot_vector)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

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 linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html