In message 011301c83aa8$84a60a50$02ac10ac@Jocke you wrote:
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?
No args can be passed but this function can have other criteria for selecting/constructing an OF tree, a time stamp, an env variable or perhaps just checking a CRC among two OF images and select one that has a vaild CRC. The selection of OF tree also takes place during bootm which makes it possible to have the CFG_OF_TREE function tftp an OF tree and pass that to the bootm command.
All that could be done using U-Boot commands / scripts, too.
So there are a few interesting options with CFG_OF_TREE which is easier to do within a function than playing with env variables.
I still diagree...
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.
You need to pass an extra arg to bootm. Our boards don't do that.
True. I consider this a bug that needed to be fixed.
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.
That would involve updating the bootcmd env. variable as part of the upgrade and I was hoping to avoid that. Futhermore if you downgrade I must reverse that change to bootcmd and the old code don't know anything about that so I need to invent some method to ensure this happens.
Well, I think you're seeing more complications than necessary.
Assume you change your bootcmd to something like this:
=> sete bootcmd "... ; ... ; bootm ${kernel} ${ramdisk} ${dtb}"
The all it takes to make this bootcmd compatible with your old version of U-Boot is deleting the "dtb" environment variable.
Computing the address isn't the problem, the problem is the new syntax of bootm. The CFG_OF_TREE was the best I could come up with.
Ah, I see. But that is exactly the reason why I reject your patch. The (documented) behaviour of the "bootm" command as is shall not be changed - a DTB shall be passed to the Linux kernel if and only if a third argument is present (again, not considering the addex compli- cations of multifile images). The state of the code you are referring to was an intermediate state, which was recognized to have problems, that were addressed and fixed later. I'm sorry if you relied too much on this behaviour. On the other hand, migration to the new scheme (and even back, if really necessary) seems not too difficult to me.
Wolgang, thanks for bearing with me for so long. If you still think CFG_OF_TREE(or some variation there of) is inappropriate for u-boot I will accept that and move on.
Thanks. I still would appreciate some independent comments - maybe I just fail to see the full scope of this.
Best regards,
Wolfgang Denk