Pantelis Antoniou wrote:
On 17 Δεκ 2006, at 10:40 ΠΜ, Joakim Tjernlund wrote:
-----Original Message----- From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant Likely Sent: den 17 december 2006 16:11 To: Joakim Tjernlund Cc: wd@denx.de; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
On 12/17/06, Joakim Tjernlund joakim.tjernlund@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 accessed. 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 anyone.
Most of powerpc kernels need the initial OF tree to be under the 8MB.
Really? The current code puts the OF tree right before the initrd, which is located at the top of RAM:
Booting using flat device tree at 0xfe250000 Loading Ramdisk to 0fda2000, end 0ff752ef ... OK Loading Device Tree to 0fd9e000, end 0fd9f48a ...
Address 0fd9e000 is passed to the kernel.
Now granted, I have another bug where function ft_setup() doesn't work at all, but I don't think that's related.