prepboot, head.S questions.

prepboot, head.S questions.

[jlhagen]

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/

Re: prepboot, head.S questions.

[Gabriel Paubert]

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/

Re: prepboot, head.S questions.

[Dan Malek]

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/

Re: prepboot, head.S questions.

[jlhagen]

[-- Attachment #1: Type: text/plain, Size: 4994 bytes --]


---------------------- Forwarded by John L
Hagen/CedarRapids/Collins/Rockwell on 12/07/2000 03:15 PM
---------------------------
(Embedded image moved to file: pic23967.pcx)

John L Hagen
12/07/2000 03:19 PM

To:   Gabriel Paubert <paubert@iram.es>
cc:

Subject:  Re: prepboot, head.S questions.  (Document link: John L Hagen)





Gabriel Paubert <paubert@iram.es> on 12/07/2000 05:04:41 AM

To:   jlhagen@collins.rockwell.com
cc:   linuxppc-dev@lists.linuxppc.org

Subject:  Re: prepboot, head.S questions.




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.



Yes, kernel/head.S is messy. I'm trying to learn this and the first time
you read through it it's amusing. Let's here it for funky firmware :)
Anyway, a better version, hmm, this one is pretty sharp as is. For our mvme
boards your diffs against 2.2.12 work for me using both nfs and initrd
(which is pretty cool) file systems. I can get the 2.4.0-test5 diff to work
for nfs but not initrd. See below for a side note on my initrd problems
with the test5 diff. It's the initrd stuff that I'm really interested in
getting working.

Ok, I understand the kernel/head.S stuff now. Bear with me as I'm just
beginning my work so I'll ask a lot of stupid questions. Why do you touch
the files in ppc/boot in your prepboot patch?? The changes look pretty
benign until the vreset.c (vga). Do I miss understand the ppc/boot purpose?
Isn't this a generic ppc boot 'loader'? This isn't really needed or built
when I'm using the PREPBOOT right?? I image since these are diffs from your
kernel sources there is other stuff included that might not necessarily be
needed specifically for the prepboot functionality. I'm trying to muscle
only the prepboot stuff into the test1 kernel source ( I have the naive
notion that I would learn the particulars by doing this ). So I'm trying to
eliminate as many things as possible at this time.

     John,



SIDE NOTE: here is some console information on the initrd problems I'm
having with 2.4.0-test5 if you would like them. I actually have all the
messages I just thought these might be usefull.

Now booting...
Kernel at 0x00000000, size=0x172204
Initrd at 0x01e3eb4c, size=0x12fb7a
Boot info 0x00173000, size=0x70
Residual data at 0x00174000
PReP architecture
mem_pieces_remove: [41e3e000,41f6db7a) not in any region
Total memory = 32MB; using 128kB for hash table (at c0180000)
Linux version 2.4.0-test5-rtl (vista@mac.vista.com) (gcc version 2.95.2 19991024 (release/franzo)) #8 Thu Dec 7
10:18:58 CST 2000
Boot arguments: console=ttyS0  root = /dev/ram0
Kernel command line: console=ttyS0  root = /dev/ram0

/snip/

RAMDISK: Couldn't find valid RAM disk image starting at 0.
Freeing initrd memory: 4194302k freed

/snip/

Sending BOOTP requests....
IP-Config: Got BOOTP answer from 192.168.1.3, my address is 192.168.1.5
kmem_create: Forcing size word alignment - nfs_fh
request_module[block-major-8]: Root fs not mounted
VFS: Cannot open root device "" or 08:01
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 08:01
Rebooting in 180 seconds..


[-- Attachment #2: Paintbrush --]
[-- Type: application/octet-stream, Size: 4243 bytes --]

Re: prepboot, head.S questions.

[Benjamin Herrenschmidt]

>
>> 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/