[PATCH 3/3] First cut at PReP support for arch/powerpc

Milton Miller miltonm at bga.com
Wed Jun 27 21:22:27 EST 2007


On Wed Jun 27 17:10:08 EST 2007, David Gibson wrote:
> Here is an implementation to allow PReP systems to boot under the
> arch/powerpc codebase, one of the few remaining platforms supported in
> arch/ppc but not so far in arch/powerpc.
>
> This support is still fairly incomplete - it needs to obtain a lot
> more device information from the residual data and put it into the
> device tree, rather than relying on hardcoded values (both in the code
> and in prep.dts).  Likewise many peripherals will not be supported -
> in particular the RTC is not yet supported, so the time will generally
> be wrong.


Hi David.

A few things I noticed:

(1) Your cleaned up mkprep.c seems to always put on a floppy header, 
where as before that was optional with the -php flag.  Is that header 
right for a hard disk partition?  Or would that just have the 1-sector 
header?  The comments in the old mkprep impiled the raw elf contents 
are used for netboot.  What if the zImage does't fit on the 1.44MB disk 
given in the header?

(2) Uour wrapper rule can leave behind zImage.dts.prep.elf, but there 
is no clean rule for that

(3) Is this the right platform to create the device tree from scratch 
by traversing fw data?  A significiant number of the properties are to 
be filled in or say IBM, which is incorrect.

(4) Adding a 5th udbg_putc method that calls a byte read to 
udbg_comport->lsr masked with THRE until 0 and performs a byte write to 
->thr shows we have the wrong abstraction.   Please make the inb/outb a 
method with the comport.  It would seem the actual init_xx could be in 
the platforms, passing inb, outb, and comport to a helper in 
udbg_16550.c.   I'm fine with declaring all the early inits in udbg.h

(5) the printk PReP architecture is in the middle of prep_find_bridges?

(6) #if 0 prep_request_io will need platform check

(7) do you expect both the kernel and the boot code will continue to 
need residual.h?  If so, can we have the boot dir make a copy like the 
zlib headers?  Or is this only temporary, the kernel only needs a copy 
of the raw blob to export to userspace in the same spot and the 
include/asm-powerpc copy will go away?

milton




More information about the Linuxppc-dev mailing list