[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 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
>