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

From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] image: Don't relocate ramdisk to highmem
Date: Thu, 11 Jul 2013 08:39:28 -0400	[thread overview]
Message-ID: <20130711123928.GA13531@bill-the-cat> (raw)
In-Reply-To: <20130711094619.E6D2B383003@gemini.denx.de>

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@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).

> > -		/* 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?".  In fact, a related problem is that folks set
initrd_high/fdt_high to 0xffffffff to just stop relocation (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.

> Also, when changing the behaviour, you should also update the
> comments.

Agreed.

> 
> 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: wd at denx.de
> The trouble with our times is that the future is not what it used  to
> be.                                                     - Paul Valery
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

-- 
Tom
-------------- 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/442ea53c/attachment.pgp>