On Mon, 2005-09-26 at 11:57 +1000, Michael Ellerman wrote:

Here's a version of my patch updated to apply on top of the merge tree.
It'll be a lot cleaner when ppc32 has a single cur_cpu_spec, as we'll
be able to remove a lot of the #ifdefs.

There is a small issue here: You turn identify_cpu into C code. However,
on ppc32, this is called with the kernel not yet relocated (before
prom_init even !). Same with the feature fixup. On ppc32, in order to
run C code that early, it needs to be in -mrelocatable bits of code
(like prom_init) or use RELOC macros (ugh !).

This puts some light on the fact that we do things quite differently
here between ppc32 and ppc64. On ppc64, the call to identify CPU is done
after kernel is relocated (after prom_init), and before early_setup,
though the call to fixup the feature sections is done later, after the
initial parsing of the flat device-tree, where we can "adjust" some
features based on firmware properties.

We might want to sync a bit what ppc32 and ppc64 do here, however, that
will/would require some changes in the way we manipulate some MMU bits.

On ppc32, we first create a temporary initial mapping, using BATs on
6xx, using other mecanisms on other CPUs, that covers kernel text & data
(not much more). This could be "equivalent" of the ppc64 bit that runs
in real mode. (Though we have to be careful there if we do something
like unpacking the device-tree, that has to be done -after- final
translation is turned on with full access to the linear mapping).

Also, the ppc64 bits calls indentify_cpu from asm on the primary CPU at
least. I don't think that is strictly necessary, at least not any more.
It could be done instead at the beginning of early_setup.

Ben.