Hello all,
does a FAQ exist for this list?? I have an obvious newbie question. Could
someone quickly explain the structure of arch/ppc, I'm really looking at
the different head.S files. It looks like the arch/ppc/kernel/head.S
contains low-level code for all architectures and the arch/ppc/[boot
coffboot etc..] are the different bootloaders. Is this correct??
Also from reading the list archives it sounded like the prepboot code from
Gabriel, or code based on his work, was to eventually make it into the ppc
source tree. I believe this discussion was quite a while ago, 1999
sometime. Is this still the plan? Or maybe items from prepboot are being
merged into arch/ppc/boot ( If I understand the structure correctly )?
Some enlightenment would be greatly appreciated.
Thanks, John
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, 6 Dec 2000 jlhagen@collins.rockwell.com wrote:
Hello all,
does a FAQ exist for this list?? I have an obvious newbie question. Could
someone quickly explain the structure of arch/ppc, I'm really looking at
the different head.S files. It looks like the arch/ppc/kernel/head.S
contains low-level code for all architectures and the arch/ppc/[boot
coffboot etc..] are the different bootloaders. Is this correct??
Also from reading the list archives it sounded like the prepboot code from
Gabriel, or code based on his work, was to eventually make it into the ppc
source tree. I believe this discussion was quite a while ago, 1999
sometime. Is this still the plan? Or maybe items from prepboot are being
merged into arch/ppc/boot ( If I understand the structure correctly )?
I hope to build a better version of my prepboot code early next year. This
has nothing to do with arch/ppc/kernel/head.S which runs after and
is the true early kernel boot but is too much of a mess.
Actually I would like to see a lot of the functionality of kernel/head.S
moved to the bootloader. I have a version of "prepboot" which is able to
read OF device tree and put it in some place for late use by the kernel,
instantiating RTAS would also be easy if I could test it but my OF machine
does not have RTAS.
This is much cleaner that the whole mess of running code at an address it
has not been foreseen to run. prepboot is compliled with -mrelocatable and
will run anywhere it is loaded even by funky firmware like PPCBUG (the
load address depends on whether I boot from disk or network) and move
itself to make room to uncompress the kernel if necessary. There is no
built-in fixed address in prepboot, absolutely none except for the
exception handlers (determined by hardware). It could be used on machines
which do not have RAM at 0 with very minor modifications affecting only
the installation of the exception handlers.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Gabriel Paubert wrote:
Actually I would like to see a lot of the functionality of kernel/head.S
moved to the bootloader.
I disagree (and you knew I would :-). I think we currently have the
proper separation here. The code in kernel/head.S is entered with
everything properly located in memory (usually), MMUs and caches
disabled (or at least in a consistent state). The code in kernel/head.S
initializes the system as the rest of the Linux kernel requires.
The code in the "boot" directories should do things that are unique
to the different platform environments.
...... I have a version of "prepboot" which is able to
read OF device tree and put it in some place for late use by the kernel,
OK....but that doesn't require changes to kernel/head.S. The OF/RTAS
is used by other kernel functions, the code in head.S doesn't care.
Just allocate a register or memory location and pass the information.
We need to clean up the parameter passing stuff between the boot loader
and the Linux kernel, and you could just pass it in there.
This is much cleaner that the whole mess of running code at an address it
has not been foreseen to run. prepboot is compliled with -mrelocatable and
will run anywhere
I think all of the boot loaders do this (at least any I have used).
They determine where they are, move things around in memory and set up
parameter blocks so the kernel and initrd (or whatever) can run in
their proper places.
..... It could be used on machines
which do not have RAM at 0 with very minor modifications affecting only
the installation of the exception handlers.
I already have minor modifications from folks at MontaVista to allow
the kernel to run from masked rom at a relatively arbitrary location.
I am trying to make these more generic and will be checking them into
the sources pretty soon. It is based upon the structure of the
software as it is today, which seems to work pretty well.
-- Dan
--
I like MMUs because I don't have a real life.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
quoted
Actually I would like to see a lot of the functionality of kernel/head.S
moved to the bootloader.
I disagree (and you knew I would :-). I think we currently have the
proper separation here. The code in kernel/head.S is entered with
everything properly located in memory (usually), MMUs and caches
disabled (or at least in a consistent state). The code in kernel/head.S
initializes the system as the rest of the Linux kernel requires.
The code in the "boot" directories should do things that are unique
to the different platform environments.
Well, I beleive Gabriel rants are more about what's in prom.c and called
from head.S.
Cort and I want to move that to the bootloader too and have a cleaner
and more "common" way to enter the kernel and pass it informations
(OF tree, residual datas, whatever...). I have various ideas in mind
and that's already more or less what happens with BootX (the OF tree
is passed by BootX already in the format the kernel expect it, the code
in prom.c does very few things in this case, but it's still a "special case").
All that is "real 2.5" work. Let's get 2.4 working and stable on all boxes
out there first ;)
OK....but that doesn't require changes to kernel/head.S. The OF/RTAS
is used by other kernel functions, the code in head.S doesn't care.
Just allocate a register or memory location and pass the information.
We need to clean up the parameter passing stuff between the boot loader
and the Linux kernel, and you could just pass it in there.
Definitely. My position is to use a tagged structure (the bootinfo stuff
Cort added recently is nice, but I don't like the way it's "found" by
the kernel). Then, we could enter the kernel with something like
r3 = magic value (just to be able to have a clean transition of
old & new booting style)
r4 = physical pointer to the boot infos (which are
supposed to be appended after the kernel image).
The kernel would be required to be entered with MMU off (or MMU on with
a 1:1 mapping, but I'd like to avoid handling all those nasty cases in
head.S). It could be located anywhere, but the bootinfos would have to
be appended to the kernel image to avoid some nasty overlap issues when
the kernel moves itself down to 0. We can eventually add more restrictions
to the location of the kernel & bootinfos on entry if we want to avoid
all cases of overlap.
The bootinfos would contain no absolute pointers. If pointers are needed,
they must be relative to the beginning of the boot-infos (well, except
for things like pointer to the framebuffer). We can stuff there anything
we want. The OF tree can be a single tag, the initrd too, etc...
I think all of the boot loaders do this (at least any I have used).
They determine where they are, move things around in memory and set up
parameter blocks so the kernel and initrd (or whatever) can run in
their proper places.
Right now, they all do it differently, and for OF machines, most of the
job is done by the kernel in the infamous prom.c ;)
I already have minor modifications from folks at MontaVista to allow
the kernel to run from masked rom at a relatively arbitrary location.
I am trying to make these more generic and will be checking them into
the sources pretty soon. It is based upon the structure of the
software as it is today, which seems to work pretty well.
In your case, the kernel could be in ROM, and the boot infos just after
it. The only thing is that the first few instructions of the kernel should
be to load the value of the bootinfos. A way to acheive that would be
to have the kernel begin with a few nops, and have a post-processing pass
of the kernel image that adds the lis/ori pair, append the boot infos,
and generates the flash-able image.
For all other cases (like gemini, etc..), I'd like to avoid special cases
in head.S, and replace those by board-specific piggy-back bootloaders
(arch/ppc/geminiboot for example).
Of course, I'm open to comments & suggestions as I don't intend to hack this
before we have a real 2.5 tree ;)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/