[U-Boot-Users] Can U-boot Autodetect arch/ppcversusarch/powerpc from info in the uImage?
Joakim Tjernlund
joakim.tjernlund at transmode.se
Sun Dec 9 22:59:36 CET 2007
> -----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
More information about the U-Boot
mailing list