boot methods

Wolfgang Denk wd at
Tue Oct 16 08:04:24 EST 2001

Dear Ben,

in message <20011015213734.24146 at> you wrote:
> No, I want to get rid of bt_t. There will be a bi_rec for clocks,
> one for cmd line, etc... and possibly all sort of custom bi_recs
> you want for your boards.
> Any bit of kernel can then do a find_birec(type) type call to get
> the bi_rec it wants at any time.

OK. Sounds fine to me.

> Ok, time to write things down ;) I'm not sure we even all have the
> same ideas in mind as the bi_rec scheme constructed on the result of
> numerous discussions on mailing lists and irc.

Thanks - I apologize that I'm insisting on some "formal" description,
but I feel it's important enough to make sure everybody  has  exactly
the same understanding.

> But we don't want kernels & bootloader to rely on it. The bootloader
> must behave as if it was talking to a wrapper (which does the unzip
> operation in most cases) so that any interface chance we may want
> to add can go to that wrapper.

I would like to ask to make the unzip part optional.

> non native ways (that is a firmware not doing bi_recs). The goal is
> to have the code for converting the firmware interface to bi_recs
> be kept in the wrapper and not in the kernel.


> >- which functions are _required_ in all cases by the wrapper?
> Any knowledge specific to the low level firmware interface should stay
> there. We eventually wanted to have the unzipping function there as
> well, which also implies the relocating in cases the kernel can be
> loaded at a different address than 0.

Please do NOT make  the  unzip  part  a  required  operation  in  the
wrapper!  This  may  be  a  convenient thing to do in many cases, but
there are other  situations;  in  some  embedded  systems  which  are
optimized  for  minimal  boot time after power-on I don't have enough
time to uncompress an image - I must be able to boot an  uncompressed
kernel as well.

And if the firmware knows how to uncompress an image - why  should  I
duplicate the code in the wrapper?

Also, the design should NOT require that the wrapper and  the  kernel
are linked against each other in any way.

> I think the point isn't clear for everybody about the embedded case
> as we mostly deal with evil firmwares ;) The above is my view of it,
> and what I intend to code in the 2.5 timeframe. Other people may have
> other views I didn't understood or didn't agree with ;) Ultimately,
> Paulus will decide what will get in.

Well, you can count on my vote for your  proposal  if  it  should  be
asked for. It makes sense to me.

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at
      Bugs are by far the largest and  most successful class of
      entity, with nearly a million known species. In this res-
      pect they outnumber all the other  known  creatures about
      four to one.  -- Professor Snope's Encyclopedia of Animal

** Sent via the linuxppc-dev mail list. See

More information about the Linuxppc-dev mailing list