On Friday 28 April 2006 10:43, Wolfgang Denk wrote:
In message 200604281034.26439.pantelis@embeddedalley.com you wrote:
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?
I think that binary patching of pre-defined addresses is a bad thing to do, as it would soon cause more trouble and incompatibilities than we have right now. So the only remaining option is ...
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"?
How many messages do we get today from user who misconfigured their system?
Too many. If there's a way to screw up, users will tend to find it. It's better to not have *any* way to screw up.
If the kernel make rules create a single file (a multi-file imagew with the kernel and the dts) then I don;t see much changes from the user's point of view.
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.
So you vote for keeping duplicated versions of the dts both in U-Boot and in Linux?
I vote for having it in u-boot only. The linux blob will be present only for kernels with a requirement to boot on non-OF firmware.
But the bootloader should pass & generate the tree, if the board maintainer is willing to pay the cost.
And what is your suggestion if he is not willing to do that?
Pay the cost in linux kernel size, for the Linux included blob size. Or use an earlier version of the kernel, with all that this entails.
Best regards,
Wolfgang Denk
Regards
Pantelis