No subject

the memory which the page tables live in, so we had to make the two
match - and it's not possible to change the TTB flags and the page
tables simultaneously, certainly not without turning the MMU off, doing
the modification and turning it back on again.

> We still have things like the SMP/nAMP mode which is Cortex-A9 and
> ARM11MPCore specific. There is also the TLB ops broadcasting bit in
> ACTLR which is also specific to ARM Ltd cores and some of these bits
> may not be accessible directly if you run in non-secure mode.

If you're running in non-secure mode and the parts of the system you
don't have access to haven't already been setup, you're running in a
crippled environment - so this isn't really an argument.

> > It strikes me that things are just becoming excessively complicated with
> > these seemingly "catch-22" issues.  Maybe a totally different approach is
> > needed - such as requiring some of this low level setup to be done by the
> > platform's boot loader?
> 
> Ideally, yes, it would be nice if these were done by the boot loader. We
> would have to define some clear requirements or at least saying that
> Linux only touches the architectured registers and not the
> implementation defined ones. But I'm not sure how feasible this would
> be.

Unless we do something like this, we're going to end up with lots of
bits of additional platform specific non-conditional assembly in the
early kernel boot path.

That stands in the way of having the kernel bootable on different
platforms, supporting the device tree code, and makes debugging harder
(the "why doesn't my kernel boot" problem.)

> There is also the CPU hotplug case where CPUs come back via the setup
> function and may need to touch bits like SMP/nAMP. This should work
> together with a boot monitor.

How does the CPU get back to the setup function?  Is the hardware aware
of the address of our setup function?  I don't think so, so I don't buy
this argument.

If the CPU is reset (eg, because power has been removed), it's going to
want to start executing from the reset vector - which means it will come
back to us via the boot loader.

The only case where it may not is when the power has not been removed and
we're doing something along the lines of the hotplug code in Realview,
where we just put the "unplugged" CPUs into a wait-loop, but maintaining
all of their context.  When the CPU is "re-plugged" we manually jump back
to the C entry point for secondary processors directly, resetting the
stack as we go.  We don't re-call the CPU specific initialization again.