I was not totally correct. gunzip/inflate has nothing to do with this problem.
the problem is this: - do_bootm->bootm_start->arch_lmb_reserve reserves "unused" memory as in cur_sp-1k upto end-of-mem in my case this is 0x0fb0cb28 - 0x10000000 - do_bootm->do_bootm_linux->boot_body_linux->boot_ramdisk_high places ramdisk as close to (and below) the "unused" memory reservation (0x1000 aligned) in my case ramdisk is copied to 0x0f8c0000 - 0x0fb0ca24 - the end of the ramdisk is overwritten while printing "Loading Device Tree to 00ffa000, end 00fff593 ... OK" this happens from: do_bootm->do_bootm_linux->boot_relocate_fdt->printf->vsprintf->number bootm_start and arch_lmb_reserve together use 40 + 32 = 72 bytes stack. The assumption that u-boots' stack usage will not exceed arch_lmb_reserve stack pointer - 1k is simply incorrect. The "do_bootm_linux->boot_relocate_fdt->printf->vsprintf->number" call chain (called from that same do_bootm) uses 56 + 40 + 1112 + 56 + 104 = 1368 bytes This problem will only occur with CONFIG_OF_LIBFDT #defined and it depends on how the 0x1000 alignment of the ramdisk image turns out. Btw. It looks like latest u-boot also has this problem. I'll send a patch later making it 4k. I do wonder why it was set so tight in the first place. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
