[U-Boot-Users] Can U-boot Autodetect arch/ppcversusarch/powerpc from info in the uImage?
joakim.tjernlund at transmode.se
Sun Dec 9 22:14:43 CET 2007
> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: den 9 december 2007 20:28
> 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 <010601c83a89$8b22bfa0$02ac10ac at Jocke> you wrote:
> > > I hereby NAK this patch for 3 reasons:
> > >
> > > 1) 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.
> > > 3) 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 at freescale.com> 2006-06-28 17:41:37
> Committer: Jon Loeliger <jdl at 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-2006
> > The 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
More information about the U-Boot