[U-Boot] [PATCH] image: Don't relocate ramdisk to highmem

[Thierry Reding]

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.reding at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130711/a83f334c/attachment.pgp>