prepboot, head.S questions.

jlhagen at collins.rockwell.com jlhagen at collins.rockwell.com
Fri Dec 8 08:20:09 EST 2000


---------------------- 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 at iram.es>
cc:

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





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

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

Subject:  Re: prepboot, head.S questions.




On Wed, 6 Dec 2000 jlhagen at 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 at 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..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic23967.pcx
Type: application/octet-stream
Size: 4243 bytes
Desc: Paintbrush
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20001207/842c4874/attachment.obj>


More information about the Linuxppc-dev mailing list