On Friday 28 April 2006 01:55, Wolfgang Denk wrote:
In message 200604280128.28841.pantelis@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