Re: Boot hang on Origen with (!SMP && CPU_IDLE)

[Tomasz Figa <tomasz.figa@gmail.com>]

On Monday 06 of January 2014 16:30:56 Arnd Bergmann wrote:
> On Monday 06 January 2014, Tushar Behera wrote:
> > The device tree node for l2x0 device was missing. After adding a node
> > as below I can start booting Origen board.
> > 
> > diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
> > b/arch/arm/boot/dts/exynos4210-origen.dts
> > index 1a12fb2..675f323 100644
> > --- a/arch/arm/boot/dts/exynos4210-origen.dts
> > +++ b/arch/arm/boot/dts/exynos4210-origen.dts
> > @@ -32,6 +32,13 @@
> > 
> > +       l2-cache-controller@10502000 {
> > +               compatible = "arm,pl310-cache";
> > +               reg = <0x10502000 0x1000>;
> > +               cache-unified;
> > +               cache-level = <2>;
> > +       };
> > +
> 
> Ok, very good!
> 
> > >> be a good time to get rid of the L2_AUX_VAL and L2_AUX_MASK defines and
> > >> just read the respective settings from DT.
> > 
> > Ok.
> 
> Does the node you list above have the right settings for this?
> 
> > > 2) There is no L2 cache controller node in Exynos4*.dtsi.
> > >
> > > It should be added, but L2 cache can't be enabled on all boards yet,
> > > since on boards where secure firmware is enabled, special configuration
> > > involving SMC calls is required. Patches for this are queued on my work
> > > queue, but it's quite tricky due to 1), which needs to consider whether
> > > secure firmware is enabled or not.
> > >
> > 
> > In that case, would it be ok to add the node for Origen board only?

Better solution would be to add the node in SoC-level dtsi, keep it
disabled and override the status to okay at board level. Still...

> 
> Wouldn't that leave other systems still broken? I'm particularly worried
> about what patch to backport to linux-stable. We should definitely add
> the node for Origen, but we may also have to revert my broken patch
> in all affected kernel versions.

...Origen is not the only board that is affected by this, most likely any
Exynos4-based board not running under secure firmware is.

> 
> Are there any systems that may or may not have secure firmware enabled
> depending on the boot loader, or do we always know whether secure firmware
> is there or not?

It always depends on the boot loader, but fortunately it's unlikely to
happen that one board will have both secure-enabled and normal bootloaders
available and in use, at least for Exynos4-based boards, so it's quite
safe to assume presence of secure firmware on per board basis and so you
have the secure firmware device tree node only in dts files of boards
that are known to use secure firmware.

Aynway, from what I can see, support for the only two Exynos4 boards using
for secure firmware was added in 3.12. This means that we can revert the
offending patch for 3.11, but for 3.12 and newer we can't, because this
will break such boards with CONFIG_L2X0 enabled.

Instead, wouldn't it be better to fix the issue at its cause? This means
s5p-sleep.S re-enabling L2X0 only if it was really enabled before entering
low power mode. This could be achieved by checking if l2x0_regs_phys isn't
0 for example (which isn't a valid physical RAM address on Exynos).

What do you think?

Best regards,
Tomasz