-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: den 9 december 2007 20:28 To: Joakim Tjernlund Cc: 'Jerry Van Baren'; u-boot-users@lists.sourceforge.net; 'Darcy Watkins' Subject: Re: [U-Boot-Users] Can U-boot Autodetect arch/ppcversusarch/powerpc from info in the uImage?
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?
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.
So there are a few interesting options with CFG_OF_TREE which is easier to do within a function than playing with env variables.
- 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.
You need to pass an extra arg to bootm. Our boards don't do that.
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-2006The 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.
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.
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.]
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. Maybe other boards will face the same problem in the future when they upgrade boards? I really have no idea.
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?
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.
Volunteers welcome...
Best regards,
Wolfgang Denk