Fix initrd booting

The device tree needs to be passed to Linux within CFG_BOOTMAPSZ. The current code places the device tree right before the initrd if it exists, and that will usually be closer to the end of memory. Instead, we should always put the device tree right before the bd_info structure, thus ensuring it is within CFG_BOOTMAPSZ.

We do, however, allow for FDTs in uImages to shoot themselves in the foot by requesting a location outside of CFG_BOOTMAPSZ.

Signed-off-by Andy Fleming <[email protected]>

---
 common/cmd_bootm.c |   20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)

common/cmd_bootm.c +0 -0

index a6499e8..d12ef76 100644

I'm not sure if you are aiming this at u-boot-fdt, which would be logical, or if you are aiming this at u-boot-testing (or other). Care to clarify?

As I read it, this causes the blob to be copied to RAM if it is in flash, which is necessary since we cannot add/rewrite nodes and properties in a flash copy.

Your change causes the blob to _always_ be relocated. Not necessarily

Hi Andy,

I'm not sure if you are aiming this at u-boot-fdt, which would be logical, or if you are aiming this at u-boot-testing (or other). Care to clarify?

common/cmd_bootm.c do_bootm_linux (cmd_tbl_t *cmdtp, int flag, · line 756

Quoted 8 lines

 #else
              if (*(ulong *)of_flat_tree == OF_DT_HEADER) {

#endif

common/cmd_bootm.c +1 -4

-#ifndef CFG_NO_FLASH
-                     if (addr2info((ulong)of_flat_tree) != NULL)
-                             of_data = (ulong)of_flat_tree;
-#endif
+                     of_data = (ulong)of_flat_tree;

Is this right? The logic in bootm *in general* and specifically here is hard to figure out, but the way I'm puzzling it out...
1) If of_data is *not* NULL, it is used as the indicator that the blob must be relocated.
2) The above is saying that, if there is flash (not defined CFG_NO_FLASH gaak) and if of_flat_tree points into flash (addr2info returns a pointer), then of_data is set which makes #1 true.

As I read it, this causes the blob to be copied to RAM if it is in flash, which is necessary since we cannot add/rewrite nodes and properties in a flash copy.

Your change causes the blob to _always_ be relocated. Not necessarily bad, but is it always good? I'm not a bootm expert by any means, and I suspect the complexity grew substantially over time, but in the mucking about I did, I did not dare to change the logic. :-/

On e500, the blob *must* be in the low 16M of memory. MUST. The low 16M is all that is mapped, and the kernel will not map more than that until it reads the blob. Certainly, it doesn't *always* need to be relocated. It's been a while since I created this patch, but I

I probably need to respin it, though. I haven't updated it since I first created it, and you may have changed the fdt code, since.

Dear Andy,

Quoted 4 lines · in message <[email protected]> you…

On e500, the blob *must* be in the low 16M of memory. MUST. The low 16M is all that is mapped, and the kernel will not map more than that until it reads the blob. Certainly, it doesn't *always* need to be relocated. It's been a while since I created this patch, but I

I think the blob should only be copied (to me "relocate" involves more complex operations than just copying) when necessary.

And I guess this restriction is also true for ramdisk images, or am I wrong?

In any case, I think it wouldbe a good idea if the 16M limit was not hard wired, but could be overwritten using the "initrd_high" variable like we can do for ramdisks.

What do you think?

Quoted 2 lines

I probably need to respin it, though. I haven't updated it since I first created it, and you may have changed the fdt code, since.

Thanks.

Best regards,

Wolfgang Denk