On Apr 27, 2006, at 2:40 PM, Wolfgang Denk wrote:
In message D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org you wrote:
The problem is that there are somethings that u-boot knows that needs to go into the blob (memory size, boot args, initrd info, frequencies, etc.)
Yes. Can we append auch variable data to the fixed part of the dts?
appending is not really how it works, but the runtime fixup is doable.
How would we distinguish the bootm command that takes a blob versus the ones we have today?
Arg count. For example:
OLD: bootm <kernel_addr> or bootm <kernel_addr> <ramdisk_addr>
NEW: bootm <kernel_addr> - <dts_addr> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
As stated before, the main issue is doing some runtime fix ups to the blob before its handed to the kernel.
Let's do exactly this: runtime fix ups.
We could hand bootm a memory location with a blob and do the fix ups at runtime, we would still have some coupling between the blob and u- boot build. At least the blob wouldn't be built into u-boot.
OK.
Let me play with this some now that I've got some direction.
- kumar