[U-Boot-Users] Re: FT u-boot shim

[Pantelis Antoniou]

On Friday 28 April 2006 01:55, Wolfgang Denk wrote:
> In message <200604280128.28841.pantelis at embeddedalley.com> you wrote:
> >
> > > > bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
> > > That would be an option, too, but I think my proposal  is  easier  to
> > > remember, especially when thinking of the multi-file image case.
> > 
> > It won't work.
> > 
> > The blob must contain the ethernet mac addresses for example...
> 
> Ummm... I'm not sure what you are referring to.
> 
> The current topic of the discussion  (which  format  to  use  for  an
> extended   "bootm"   command)  has  obviously  no  relation  to  your
> statement.
> 
> And that the static blob that comes with the  kernel  image  must  be
> "fixed  up"  (which  means that board specific parameters like memory
> size, clock frequencies and MAC addresses must be  added/inserted/ap-
> pended/whatever) has been discussed before.
> 
> So what exactly do you mean?
> 

You're going to carry around all the FT node building code & then patch an
external binary blob? Or are you going to poke at hardcoded positions in 
the blob?

And that with an extra binary blob that you have to carry around, at yet
another danger of screwing up. How many posts in the list we're going to
get from users that are trying to boot with a blob for their eval board,
or worse "something they found in the internet"?

IMHO all this talk about having shims is bunk. It is trivial for the running
kernel to detect that a valid BLOB was passed by the bootloader. It can then
proceed with using a preset compiled in tree for use with non OF firmware.

But the bootloader should pass & generate the tree, if the board maintainer
is willing to pay the cost. 

> Best regards,
> 
> Wolfgang Denk
> 

Regards

Pantelis