Dear Thierry Reding, In message <20130711150014.ga2...@dhcp-172-17-186-34.nvidia.com> you wrote: > > > 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.
This depends a lot on a number of things. For example, you should be able to use a ramdisk in NOR flash directly, i. e. without loading it to RAM first - especially if it;s a comprtessed ramdis image, and the Kernel will copy/uncompress it anyway. Depending on your memory map the address range of the NOR flash may be way outside (and above) that of the system RAM. Are you sure your changes will not break any such usage? > 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 We want to avoid any copy of the ramdisk at all, if possible. > 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. What is a fix for you may be a breakage elsewhere. > > > 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. ...because default behaviour was do do nothing. Now you do something, so this should be documented. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only time the world beats a path to your door is when you are in the bathroom. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot