On Friday 09 January 2015 10:33:07 Catalin Marinas wrote:
On Wed, Jan 07, 2015 at 07:48:48PM +0000, Arnd Bergmann wrote:
In other cases that's actually a good thing. One such example is the "Principles of ARM Memory Maps" document that tells hardware implementers to do a rather complex mapping "To support 36-bit x86 PAE compatible operating systems, such as Linux." but makes life much harder in the process than any of the random mappings we have seen in the wild.
Unfortunately, with any significant amount of RAM (say 16GB), this document becomes pretty useless. It basically forces you to have a very sparse physical address map from 0 to over 40-bit. I wouldn't apply the ARM memory maps doc to server systems.
Are you sure? I was under the impression that this document was targetted specifically at servers.
It's also not just the CPU core, other components also get easily replaced, like a GICv3 that is not a strict superset of GICv2.
That's not a problem for Linux, we can describe them in DT or ACPI and have drivers. GICv3 has an optional GICv2 compatible mode, though vendors may decide not to implement it.
I'm aware that we can deal with it after we have the drivers. My point was that we are unable to deal with this problem in general if we want to run existing kernels on new hardware that contains e.g. a GICv4/5/6 that requires a new driver which has to first be written and then backported into distro kernels.
Arnd