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

[Wolfgang Denk]

Dear Thierry Reding,

In message <20130711150014.GA2198 at 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: wd at denx.de
The only time the world beats a path to your door is when you are  in
the bathroom.