[U-Boot-Users] builtin OF tree dtb gone

Pantelis Antoniou pantelis.antoniou at gmail.com
Sun Dec 17 17:50:53 CET 2006

On 17 Δεκ 2006, at 10:40 ΠΜ, Joakim Tjernlund wrote:

>> -----Original Message-----
>> From: glikely at gmail.com [mailto:glikely at gmail.com] On Behalf
>> Of Grant Likely
>> Sent: den 17 december 2006 16:11
>> To: Joakim Tjernlund
>> Cc: wd at denx.de; u-boot-users at lists.sourceforge.net
>> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
>> On 12/17/06, Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
>>> "in some setups", that's the point. Our setup works fine with
>>> an embedded OF tree in u-boot. If I am to adapt to this new
>>> method of supplying the OF tree, not only will I have to repartion
>>> the flash to fit the tree in there, I also need to make sure
>>> that some 15-20 people learns this new concept for no real gain.
>>> It is nothing wrong with having the ability provide a OF tree
>>> at boot time, but forcing everyone to do so is. The
>>> most flexible way is to have both.
>> This shouldn't be too big a deal.  Add the code back for linking the
>> .dtb into the image.  Look in common/boot.c and add a check for if  
>> the
>> third bootm parameter is '-'.  If it is, then use the builtin section
>> for the .dtb address.  Then you can either use the builtin  
>> version, or
>> pass a new one.  We're not talking a lot of code here.
> I am looking at this now. I have a DTB linked into uboot at address
> 0xffc9d90(near end of my 256MB RAM when u-boot has relocated itself).
> Passing this address to bootm $loadaddr - 0xffc9d90 makes the
> kernel SEGV because the kernel can't access data that high up in RAM
> early in the boot process.
> Seems to that the u-boot should copy the DTB to an address that
> the kernel can access before passing control the kernel. How
> else is one supposed to have a DTB in flash that is even higher up
> in the address space?
> Maybe I have misunderstood something, but I can't se what presently.

Yes, the DTB must be placed low-enough in the boot memory to be  
I'm pretty sure that the original implementation I did made this work.
In fact I'm surprised that the flash pointing thingy even works for  

Most of powerpc kernels need the initial OF tree to be under the 8MB.

The only way to guarantee that is to copy the OF tree to the stack
of the kernel we are about to boot.

I really don't understand the point of this discussion...
Let's see if I got this right.

OF's initial implementation worked well enough for it's users (Jocke  
& others).

There was a change to the OF implementation that makes those users  

There is no real technical reason to not accommodate those users.

I feel Jocke's complaints are reasonable. There should be a way to keep
him happy, since the old stuff used to work just fine; in fact I'd argue
it worked better.

That's my opinion anyway.



>> Alternately; your u-boot image does not totally fill the sectors you
>> have allocated for it.  Since your plan is to update u-boot and the
>> .dtb at the same time; modify your u-boot build procedure (I think by
>> using objcopy) to link your .dtb to a known address within the unused
>> part of the u-boot sectors (so that u-boot+dtb are in a single file)
>> and make sure the update procedure also changes the default bootm
>> command to include the known dtb address.
> This option does not really suit me, but thanks for the suggestion.
>  Jocke
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

More information about the U-Boot mailing list