On Thu, Jul 11, 2013 at 08:39:28AM -0400, Tom Rini wrote: > On Thu, Jul 11, 2013 at 11:46:19AM +0200, Wolfgang Denk wrote: > > Dear Thierry Reding, > > > > In message <1373500071-6476-1-git-send-email-thierry.red...@gmail.com> you > > wrote: > > > > > > The Linux kernel cannot unpack a ramdisk that's stored in high memory. > > > > Can you please be a bit more explicit? Which exact architecture are > > you talking about? Can you show a specific example of an error case > > for such a system? > > I'm pretty sure it's all architectures, and this is a problem for device > trees as well. The tricks done to deal with highmem mean it's not > suitable for certain tasks, if I recall things right (it's been a > while).
Yes, that's my understanding as well. The same changes were done for fdt_high a few months back and ramdisks aren't any different in this respect. I was a bit surprised that this hadn't been fixed yet, but maybe people just aren't using ramdisks anymore these days, or they worked around it by setting initrd_high explicitly. > > > - /* not set, no restrictions to load high */ > > > - initrd_high = ~0; > > > + /* make sure to put ramdisk in low memory */ > > > + initrd_high = getenv_bootm_low() + getenv_bootm_mapsize(); > > > > I don't like to have such a patch (which affects ALL systems) added > > unless we understand exactly why we should do that. > > > > Why do you not simply set initrd_high as needed? > > The problem is that setting initrd_high (and fdt_high) becomes one of > those things you have to on every new port, and you start to go "why do > I have to do this again?". Relocating to the top of memory is probably the wrong thing to do for a lot of boards these days. I know I've been using the old code without a problem on a number of boards, but more recent hardware tends to come equipped with 1 GiB or more RAM, which should always trigger this error. > In fact, a related problem is that folks set initrd_high/fdt_high to > 0xffffffff to just stop relocation Yeah, I wondered whether maybe not relocating the ramdisk (and the FDT) in the first place might even be a better default fallback. It makes the boot process slightly more brittle because it can go equally wrong if people load files to weird locations. It seems, though, that most boards use sensible default locations that are somewhere below the first 256 MiB of RAM. > (which may or may not be a time saver too) after hitting the sequence > of: > - Loaded ramdisk somewhere "good" in memory > - Tried booting the kernel, ramdisk not found > - Spend non-zero time cursing and debugging why the ramdisk wasn't seen > - Realize that U-Boot shoves it up to the top of memory and the kernel > doesn't like that. > - Curse U-Boot for moving things around on you. That's *exactly* what happened to me, only that instead of just not finding the ramdisk it would page fault and oops. The first thing I did was indeed to just set initrd_high to 0xffffffff but then decided to try and properly fix it in an attempt to save others the trouble. > > Also, when changing the behaviour, you should also update the > > comments. > > Agreed. I'm not sure which comments you are referring to. I updated the one immediately above the changed code and the one above the function doesn't contain anything relating to the default behaviour in case initrd_high is unset. Thierry
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
