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

[Joakim Tjernlund]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Joakim Tjernlund
> Sent: den 17 december 2006 16:40
> To: 'Grant Likely'
> Cc: u-boot-users at lists.sourceforge.net; wd at denx.de
> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
> 
> > -----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.

Ahh, found it. It is the addr2info check that relocates the OF tree.
addr2info checks if an address is in flash, if so it will relocate it
to lower RAM. But since I got my OF tree in high RAM that won't
happen.
The same would happen if one loaded a OF tree via tftp and placed
it high up in RAM.
I think that the addr2info check should be replaced with something
else that will move the tree to a low enough address if needed.

What would be a good test?

A simple way to support an embedded tree would be:
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 7aae8a6..7b2d221 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -531,8 +531,12 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
        image_header_t *hdr = &header;
 #ifdef CONFIG_OF_FLAT_TREE
        char    *of_flat_tree = NULL;
+#ifdef CFG_EMBEDDED_FLAT_TREE
+       ulong   of_data = (ulong)oftree_dtb;
+#else
        ulong   of_data = 0;
 #endif
+#endif

 Jocke