Re: [PATCH 1/3] memblock, nobootmem: Add memblock_virt_alloc_low()

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Tue, Jan 28, 2014 at 11:43:02AM -0800, Yinghai Lu wrote:
> On Tue, Jan 28, 2014 at 9:18 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Jan 28, 2014 at 09:12:27AM -0800, Yinghai Lu wrote:
> >> On Tue, Jan 28, 2014 at 7:30 AM, Kevin Hilman <khilman@linaro.org> wrote:
> >> > Like Olof, I noticed multiple boot failures on various ARM boards.
> >> > I've confirmed that reverting the arch/arm part of this patch makes
> >> > them all happily booting again.
> >>
> >> please try attached patch.
> >
> > Maybe I'm missing something, but there is no ARCH_LOW_ADDRESS_LIMIT
> > defined in the ARM header files, so I don't see how adding that
> > additional include changes anything.
> 
> there is one for arm64 and s390.
> 
> arch/arm64/include/asm/processor.h:#define ARCH_LOW_ADDRESS_LIMIT       PHYS_MAS
> arch/s390/include/asm/processor.h:#define ARCH_LOW_ADDRESS_LIMIT        0x7fffff

Forgive me being difficult, but how exactly does your patch come anywhere
close to sortting out the reported regression by Kevin and Olof, and now
myself which is on ARM?

Your patch adds asm/processor.h to a header file, to allow architectures
to override ARCH_LOW_ADDRESS_LIMIT, but there is /no/ override for ARM,
so your patch has _zero_ effect there - we still end up with this being
0xffffffff, and we still end up with the thing being unable to boot.

Maybe you could describe what this ARCH_LOW_ADDRESS_LIMIT is, and what
it should be set to - I'm less than clear on how to set this given that
we have a multitude of different physical memory layouts - where memory
can start at almost any physical address.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".