[U-Boot-Users] Re: FT u-boot shim
pantelis at embeddedalley.com
Fri Apr 28 09:34:26 CEST 2006
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
> 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
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
More information about the U-Boot