diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 2436581..580a9f0 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -21,6 +21,7 @@
- MA 02111-1307 USA
*/
+#define DEBUG
Oops. That was a stupid oversight.
of_len = be32_to_cpu(fdt_totalsize(of_data));
/* position on a 4K boundary before the initrd/kbd */if (initrd_start)of_start = initrd_start - of_len;elseof_start = (ulong)kbd - of_len;
/* position on a 4K boundary before the kbd */of_start = (ulong)kbd - of_len;Second, I asked you before to implement this similar like the initrd location can be controlled using the "initrd_high" environment variable (see my message Tue, 07 Aug 2007 21:21:19 +0200). AFAICT you never replied to this.
Sorry, I ended up replying more to gvb's comment. The initrd can go wherever it wants. The address of the ramdisk is contained in the blob, and the kernel will map memory using the blob. But the blob has to be accessed before the kernel maps that memory.
So we can add an environment variable to override the 16M limit for u-boot, but if anyone sets it above 16M (on 85xx), it'll screw things up. I don't have a fundamental issue with such a variable being added, but I don't think I have time to figure it out this week, and I don't think it solves the problem (though it would allow users to solve it).
In other words, I think we need both. BOOTMAPSZ is clearly meant to serve as a ceiling for things like the blob (the bd_t, for instance, is always put in that range if it exists). The environment variable would give everyone more flexibility. Sadly, though, I only have time to fix the obvious problem (leaving DEBUG defined). I'd be happy to implement the environment variable for the *next* merge window, but I'd really hate to let this bug sit in u-boot for another release.
Andy