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

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

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

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.

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)

-- 
Ard.