In message 010601c83a89$8b22bfa0$02ac10ac@Jocke you wrote:
I hereby NAK this patch for 3 reasons:
- The patch does not solve a problem. Instead of harwiring the address, you can just pass it as argument to the bootm command which seems more straightforward to me
It is not a hardwired address, it is a function call which returns an address to the OF tree of your choise. You can define it to an address too if you like.
Thanks for the correction. But actually it makes little difference; it's a static thingy as we can't pass (varying) arguments to it. Or am I missing something?
- With the patch applied and CFG_OF_TREE defined, there is no way to boot a non-OF kernel, thus breaking backward compatibility.
hmm, backwards compatibility. Current u-boot breaks backwards compatibility with older u-boots that didn't require an OF tree to be passed as an argument to bootm. Dunno when that happened but 1.1.4 has
In which way? We use OF-enabled versions of U-Boot on several boards that are in use both with old (2.4.25) and new (2.6.23.X) non-OF kernels, and with OF-enabled kernels as well. There are problems, indeed, in certain constellations using multi-file images, but as long as you use separate kernel, ramdisk and/or dtb images it works fine.
extern const unsigned char oftree_dtb[]; extern const unsigned int oftree_dtb_len; That needs to be defined in board code and holds the OF tree.
These lines were removed by this commit:
Author: Matthew McClintock msm@freescale.com 2006-06-28 17:41:37 Committer: Jon Loeliger jdl@freescale.com 2006-08-09 20:50:11 Parent: d87080b721e4f8dca977af7571c5338ae7bb8db7 (GCC-4.x fixes: clean up global data pointer initialization for all boards.) Child: 5498d90312aad9f6bdbf047986027c35b03cd163 (* Patch to modify ft_build.c to update flat device trees in place Patch by Matthew McClintock 26-June-2006) Follows: NIOS2-5_0_0 Precedes: U-Boot-1_1_6
* Modify bootm command to support booting with flat device trees Patch by Matthew McClintock 26-June-2006
The CFG_OF_TREE(or some variation there of) is the only way I can think of to support uppgrade of the older boards in the field in a easy and non error prone way.
Sorry, but I don't get you.
You started this discussion by mentioning that you want to embed the DTB into the U-Boot image (and I commented you could just append it). If you upgrade an old board by installing a new U-Boot image, you will also overwrite the old embedded DTB and install a new one with the new image, and this new address is well known to you so you can easily pass it on the bootm command line.
Assuming the DTB image was NOT part of the U-Boot image it's address would be known, too, so the same method could be used.
Finally, you could even compute the address by some code (although I have to admit that I cannot image how that could be needed, but my imagination is definitely limited) - nothing prevents you to add some board specific code that is run automatically (for example, as part of your misc_init_r() or last_stage_init() code) or manually (by defining a board-specific command). This code could define or modify an environment variable which then in turn gets used as third argument to the bootm call. [Yes, this sounds complicated, and I agree that it's probably never needed, but it would implement the same what you want to do in a board-specific way, i. e. without impact on other boards.]
I feel we are pretty much stuck here. You insist you need this, and I fail to see any such need.
Could please somebody else (probaly with a deeper understanding of DTB magic than me) try to moderate this discussion so we can come to a decision that is based on mutual understanding?
Volunteers welcome...
Best regards,
Wolfgang Denk