-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: den 9 december 2007 22:36 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 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...
I thought you disagreed with how I modified the bootm command, I can't image than all the above is easier to do by using env. variables/scripts? Especially the tftp idea.
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.
My bug or an u-boot bug?
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.
Yes, but I would have do make sure it is deleted BEFORE I downgrade.
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.
Yes, I realize that there was a reason for the new bootm syntax. I was hoping for an easy migration path for those who got caught in the middle.
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.
Me too, lets see if any of the OF tree experts has anything to add.
Regards Jocke
Best regards,
Wolfgang Denk