[U-Boot-Users] Can U-boot Autodetect arch/ppcversusarch/powerpc from info in the uImage?

[Joakim Tjernlund]

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de] 
> Sent: den 9 december 2007 22:36
> To: Joakim Tjernlund
> Cc: 'Jerry Van Baren'; u-boot-users at 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 at 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