On 04/05/2013 12:13 PM, Wolfgang Denk wrote: > Dear Rob, > > In message <515efe6f.1020...@gmail.com> you wrote: >> >>> In addition to commit 60d7d5a "env: fix potential stack overflow in >>> environment functions" discussed here, I think we should also revert >>> commit fcfa696 "ARM: increase lmb stack space reservation to 4KB" >>> because it is conceptually broken and just papers over the real >>> problems. >> >> Doing so will randomly break any system with a large command or print >> buffer. For extra fun, it is dependent on the initrd or dtb image size >> in terms of remainder of 4KB multiple. > > Well, yes, but that's because the LMB code makes unjustified > assumptions about the memory usage, so it needs to be fixed there. > >> It is exactly the same code as PPC. It you look at the git history, PPC >> made exactly the same change (1 to 4KB increase) around the same time >> all the FDT boot code got copied from PPC to ARM. So ARM missed this change. > > Thanks for pointing out. This adds commit 3882d7a "ppc: unused memory > region too close to current stack pointer" to the list of patches that > should bne reverted. > >> If the stack is all of RAM, then what address should the initrd and dtb >> be copied to? > > Why do they have to be copied at all? Why cannot they remain where > they have been loaded in the firtst place? The memcpy just costs time, > which is a precious resource. Leave it to the user to find a > reasonable location in RAM where he loads the data, and don't mess > with it.
I've got no freaking idea! I do turn that crap off in my environment with initrd_high=0xffffffff. But the default operation is to copy it. Rob _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
