On 13 August 2015 at 21:24, Stuart Yoder [off-list ref] wrote:

quoted

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
Sent: Saturday, August 08, 2015 3:21 AM
To: Yoder Stuart-B08248
Cc: Catalin Marinas; Mark Rutland; Marc Zyngier; Will Deacon; Newton Peter-RA3823; linux-arm-
kernel at lists.infradead.org; Sun York-R58495
Subject: Re: [RFC] arm64: defconfig: enable 48-bit VA by default

On 7 aug. 2015, at 21:01, Stuart Yoder [off-list ref] wrote:

quoted

quoted

Whether defconfig supports your platform optimally has nothing to do
with that. Of course, we should deal with the unexpected memory layout
gracefully, which is why Mark Rutland and myself proposed patches to
fix the panic you reported. But in a development context, I think it
is perfectly acceptable to simply load the kernel at 0x80_8000_0000,
and be able to run defconfig fine while losing just 2 GB of your 16 GB
at the low end.

I've done this experiment-- loading/running the kernel at 0x80_8000_0000
and losing the lower 2GB of memory.  And in fact I can see the kernel
ignoring the low memory:

  [    0.000000] Ignoring memory block 0x80000000 - 0x100000000

Yes that looks correct

quoted

However, this only works with 48-bit VA enabled.  With 39-bit VA
enabled the kernel crashes before the early console is working
and I see nothing.

That may well be a kernel bug: the changes to allow 39-bit VA kernels
to execute on systems whose memory is outside the 39-bit VA range was
developed and tested on AMD Seattle only, which has its RAM at
0x80_0000_0000. But it is hard to be sure, of course, with no output
at all ...

quoted

Does the linear mapping we've been talking about just need to cover
all of _RAM_, or does it need to cover all of I/O as well in
the same mapping.

In our case we have various SoC I/O devices, like the UART
in the space below 4 GB... at 0x0100_0000.

The linear mapping only covers system RAM, so that should not matter at all.

quoted

Before debugging further I want to check whether this should
work in theory.  I had the impression that the issue was
discontiguous RAM regions, and I/O was a separate issue.

Yes, it should work in theory. The linear region starts at the base of
the kernel Image, and extends all the way up to the end of DRAM (14 GB
in your case, IIRC)

An update on this... in my original test where the kernel did not run from
high memory I was using a 4.0.x kernel.  I re-tried with a 4.2-rc4 kernel
and it booted fine.  So, there is no kernel bug it in the latest kernel,
it appears.

OK, thanks for reporting back.

So we still need to decide how to fix the case where the linear region
is not of sufficient size to cover all of memory, considering that is
what got this discussion started in the first place.

RobH was not too happy about how I proposed to split off
early_init_dt_add_memory_arch () but there has been no movement on
this since.

-- 
Ard.