It appears to me that while TianoCore ARMv8 support is in place, support for 64-bit memory maps is not. The ARM models have all memory (or at least first 2GB) and peripherals below 4GB. The ARM code is very much not 32/64 bit portable. I see lots of places where UINTN is used to cast addresses. This will need to be addressed for any "real" 64-bit platforms.
The things I've found and started fixing so far are:
- Flash base - System memory base - Global variable base
It's not clear to me how much more of this stuff there is. Any knowledge or input here would be helpful. I would guess the common code is 64-bit safe and this issue is only with the ARM code.
While I hope these are all restrictions of the ARM port, are there any general EFI requirements about having memory or peripherals below 4GB (on 64-bit systems)?
Rob
Hi Rob,
On Tue, Dec 17, 2013 at 02:42:52PM -0600, Rob Herring wrote:
It appears to me that while TianoCore ARMv8 support is in place, support for 64-bit memory maps is not. The ARM models have all memory (or at least first 2GB) and peripherals below 4GB. The ARM code is very much not 32/64 bit portable. I see lots of places where UINTN is used to cast addresses. This will need to be addressed for any "real" 64-bit platforms.
Indeed.
The things I've found and started fixing so far are:
- Flash base
- System memory base
- Global variable base
At least some of this has been recently addressed by Olivier. When did you last rebase? (The system memory base should have been fixed about two weeks ago.)
It's not clear to me how much more of this stuff there is. Any knowledge or input here would be helpful. I would guess the common code is 64-bit safe and this issue is only with the ARM code.
I believe the question when AArch32 support was implemented was common code was 32-bit safe :)
While I hope these are all restrictions of the ARM port, are there any general EFI requirements about having memory or peripherals below 4GB (on 64-bit systems)?
Not on 64-bit systems. (On 32-bit, only <4GB RAM can be used.) This is according to the specification.
Both ia64 and x86_64 seem to have various assumptions around this, which has triggered an issue or two in GRUB - so theoretically, there could be the occasional bug.
/ Leif
On 12/17/2013 03:40 PM, Leif Lindholm wrote:
Hi Rob,
On Tue, Dec 17, 2013 at 02:42:52PM -0600, Rob Herring wrote:
It appears to me that while TianoCore ARMv8 support is in place, support for 64-bit memory maps is not. The ARM models have all memory (or at least first 2GB) and peripherals below 4GB. The ARM code is very much not 32/64 bit portable. I see lots of places where UINTN is used to cast addresses. This will need to be addressed for any "real" 64-bit platforms.
Indeed.
Turns out UINTN is sized correctly, so things aren't quite so bad.
The things I've found and started fixing so far are:
- Flash base
- System memory base
- Global variable base
At least some of this has been recently addressed by Olivier. When did you last rebase? (The system memory base should have been fixed about two weeks ago.)
The only thing I found upstream that would affect me is this:
EmbeddedPkg/EmbeddedPkg.dec: Defined default values for PcdPrePiCpuMemorySize & PcdPrePiCpuIoSize
This change introduces default values for the PCDs PcdPrePiCpuMemorySize & PcdPrePiCpuIoSize. These values are for the architectures ARM, AARCH64, IA32 and X64.
The redefinition of these PCDs (with the same default values) have been removed from the DSC files.
Note: the default value for AARCH64 was 32. It was preventing to allocate buffer above the 32bit address space.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.martin@arm.com
That does not fix gArmTokenSpaceGuid.PcdSystemMemoryBase which is 32-bit. This either has to be expanded to 64-bit (for all), converted to KB/MB/PFN or needs a PcdGetXX that is variable size based on the arch size. It looks like "VOID *" is an allowed type.
It's not clear to me how much more of this stuff there is. Any knowledge or input here would be helpful. I would guess the common code is 64-bit safe and this issue is only with the ARM code.
I believe the question when AArch32 support was implemented was common code was 32-bit safe :)
While I hope these are all restrictions of the ARM port, are there any general EFI requirements about having memory or peripherals below 4GB (on 64-bit systems)?
Not on 64-bit systems. (On 32-bit, only <4GB RAM can be used.) This is according to the specification.
Good.
Both ia64 and x86_64 seem to have various assumptions around this, which has triggered an issue or two in GRUB - so theoretically, there could be the occasional bug.
Such as assumptions about RAM starting at 0 I suppose.
Rob
On Tue, Dec 17, 2013 at 05:17:28PM -0600, Rob Herring wrote:
It appears to me that while TianoCore ARMv8 support is in place, support for 64-bit memory maps is not. The ARM models have all memory (or at least first 2GB) and peripherals below 4GB. The ARM code is very much not 32/64 bit portable. I see lots of places where UINTN is used to cast addresses. This will need to be addressed for any "real" 64-bit platforms.
Indeed.
Turns out UINTN is sized correctly, so things aren't quite so bad.
UINTN is "native UINT", so yes. But I recall spotting places where things are cast to UINTN from UINT32.
The things I've found and started fixing so far are:
- Flash base
- System memory base
- Global variable base
At least some of this has been recently addressed by Olivier. When did you last rebase? (The system memory base should have been fixed about two weeks ago.)
The only thing I found upstream that would affect me is this:
EmbeddedPkg/EmbeddedPkg.dec: Defined default values for PcdPrePiCpuMemorySize & PcdPrePiCpuIoSize
This change introduces default values for the PCDs PcdPrePiCpuMemorySize & PcdPrePiCpuIoSize. These values are for the architectures ARM, AARCH64, IA32 and X64.
The redefinition of these PCDs (with the same default values) have been removed from the DSC files.
Note: the default value for AARCH64 was 32. It was preventing to allocate buffer above the 32bit address space.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.martin@arm.com
That does not fix gArmTokenSpaceGuid.PcdSystemMemoryBase which is 32-bit. This either has to be expanded to 64-bit (for all), converted to KB/MB/PFN or needs a PcdGetXX that is variable size based on the arch size. It looks like "VOID *" is an allowed type.
Apologies, I was a bit confused about that. The actual fix was postponed due to it breaking 32-bit without a synchronized fix in BaseTools. BaseTools is something of a glass jaw of Tianocore - since it is included in edk2, but maintained separately and only occasionally synchronized.
I've asked Olivier to send out the required patches anyway, so we have somewhere to point people.
It's not clear to me how much more of this stuff there is. Any knowledge or input here would be helpful. I would guess the common code is 64-bit safe and this issue is only with the ARM code.
I believe the question when AArch32 support was implemented was common code was 32-bit safe :)
While I hope these are all restrictions of the ARM port, are there any general EFI requirements about having memory or peripherals below 4GB (on 64-bit systems)?
Not on 64-bit systems. (On 32-bit, only <4GB RAM can be used.) This is according to the specification.
Good.
Both ia64 and x86_64 seem to have various assumptions around this, which has triggered an issue or two in GRUB - so theoretically, there could be the occasional bug.
Such as assumptions about RAM starting at 0 I suppose.
Well, apparently also some ports don't bother mapping memory > 4GB and suchlike.
/ Leif
-
Leif Lindholm -
Rob Herring