Re: [PATCH 6/6] bootwrapper: Add support for the sandpoint platform

[Matt Porter <mporter@embeddedalley.com>]

On Fri, Aug 18, 2006 at 01:19:22AM +0200, Guennadi Liakhovetski wrote:
> On Fri, 18 Aug 2006, Guennadi Liakhovetski wrote:
> 
> > On Thu, 17 Aug 2006, Mark A. Greer wrote:
> > 
> > > Depends on what you mean by "__boot__".  This is the code needed to
> > > prepare things--the flat dev tree in this case--so that the kernel
> > > can boot when running the DINK firmware on a sandpoint.
> > 
> > ...after getting some vitamins on irc and re-reading some emails, I 
> > finally realised what the stuff under boot is for. Expect more confusion 
> > from me:-)
> 
> Ok, I think, now I have an idea what all these wrappers are about:
> 
> we want to be able to boot linux from a number of different environments:
> 
> OF
> 
> various firmwares / boot ROMs / bootloaders with very different 
> capabilities of running foreign code and different calling conventions
> 
> "native" Linux bootloaders like u-Boot, etc.
> 
> kexec
> 
> ...
> 
> and the chosen approach is to have a kernel proper common to all these 
> possibilities, and "wrappers". These wrappers are boot-method and board 
> specific, are distributed with the kernel, located under 
> arch/powerpc/boot, get linked with the kernel proper, fdt, with various 
> compression possibilities...
> 
> Have I got it right now? One of the reasons of me having problems to 
> understand this is that on ARM we just say "to boot kernel you have to 
> have MMU switched off, registers must contain this and that, you have to 
> prepare a list of ATAGs, copy the kernel to a certain address, and jump to 
> it. If you don't do that you cannot run Linux on your system":-)

Sure, everybody that's familiar with ARM Linux is aware of that.
That's what the new fdt requirement in arch/powerpc/ does for
PPC as well.  arch/powerpc/boot/ wrapper code isn't technically
part of the kernel, it's merely distributed with the kernel source
for convenience. It's a boot shim to translate from "legacy"
firmwares (since they aren't easily replaced) to the standard
method. It is independent of the kernel proper.

-Matt