Hi Steven,
In the following emails are the three patches that I'd like applied to the Linaro EDK2 tree for the 14.01 release:
[PATCH 1/3] ArmPlatformPkg/ArmVExpressPkg: add virtio to RTSM A15
[PATCH 2/3] ArmPlatformPkg/ArmVExpressPkg: add virtio to RTSM A15
[PATCH 3/3] ArmPlatformPkg/ArmVExpressPkg: add virtio to RTSM A9 BSP
They all add virtio mmio support to the A9/A15 BSPs.
Olivier,
Please also consider these for inclusion in the Tianocore tree.
Regards,
Ryan.
I'm trying to nail down what the proper Machine Type value in the
PE/COFF header should be for ARM linux images with the stub.
The PE/COFF specification lists two values that seem appropriate:
IMAGE_FILE_MACHINE_ARM 0x1c0 "ARM little endian"
IMAGE_FILE_MACHINE_THUMB 0x1c2 "ARM or Thumb ("interworking")"
Tianocore currently only supports the 0x1c2 value, but it seems that
the 0x1c0 should also be supported. Is there a specific reason only
0x1c2 is supported?
Thanks,
Roy
Hello all,
I've uploaded the latest FastModels for ARMv8 to fastmodel.linaro.org. You
can get it by following the instructions on the wiki:
https://collaborate.linaro.org/display/ITS/FlexLM+and+Fast+Models
Depending on whether you want an AEMv8 or Cortex model, the files you want
are:
FVP_Base_AEMv8A-AEMv8A_0.8_5311.tgz
FVP_Base_Cortex-A57-A53x14_0.8_5311.tgz
eg,
scp fastmodel.linaro.org:/home/resources/FVP_Base_AEMv8A-AEMv8A_0.8_5311.tgz
.
The downloads directory should be simpler now; I've moved older versions
into the new "archive" directory.
Cheers,
Ryan.
On Tue, Jan 14, 2014 at 10:09 AM, Olivier Martin <olivier.martin(a)arm.com> wrote:
>
>
>> -----Original Message-----
>> From: Roy Franz [mailto:roy.franz@linaro.org]
>> Sent: 14 January 2014 01:31
>> To: Olivier Martin
>> Cc: ryan.harkin(a)linaro.org; edk2-devel(a)lists.sourceforge.net; linaro-
>> uefi; Patch Tracking
>> Subject: Re: [PATCH V2] Move RTSM VExpress variable storage to 256k
>> flash blocks
>>
>> > I have to admit I prefer the solution 2) - but I am quite open to any
>> valid arguments. My argument is I would prefer to expose the correct
>> implementation when possible. And if qEmu adds support for the missing
>> VExpress IP block in the future then it will be easier to restore the
>> correct approach (ie: the default RTSM approach) for qEmu. I don't
>> think that the flash will every be fixed in QEMU, since accurate
>> modeling of flash writing is not all that valuable of a feature.
>>
>> I can add a compile option for the flash, as I have done for the
>> networking. The networking required this due to conflicting ethernet
>> devices. (And here QEMU matches real hardware, and it is RTSM that is
>> 'wrong'.) I think that the value of a common binary for a common case
>> is worth the cost of moving the variable storage to larger blocks, but
>> if you remain unconvinced I'll resubmit the patch with a build option
>> :) (and in that case I will also resubmit the networking patch so the
>> same build option is used for both QEMU related changes.)
>>
>
> Nice try! but I remain unconvinced :-)
> From what you said, we will need a compiler flag for the Ethernet driver anyway. So let's go for it :-)
> And it will quite easy to 'grep' for SUPPORT_QEMU to highlight the difference between the different models than to go through the git history to find out the workaround which has been made to use UEFI on qEmu.
>
>
>
OK :) I'll redo both changes into 1 series, both keying off the
SUPPORT_QEMU build define.
Thanks,
Roy
Hi Olivier,
On Mon, Jan 13, 2014 at 11:16 AM, Olivier Martin <olivier.martin(a)arm.com> wrote:
> Hi Roy,
>
> I need to think more about it. And I also need your point of view on some points.
>
> Here are few questions and thoughts:
> - Do you think the flash topology is the only difference between qEmu and RTSM? I believe it is not the only difference. I think the Cortex A15 used to not support the Security extension in qEmu. IS it still the case?
QEMU reports that it does implement security extensions, but only
partially does. As part of supporting UEFI VBAR register support was
added to QEMU. Other users had posted patches as they wanted this as
well, and these patches got merged since UEFI needed them as well. I
am sure that there are many remaining differences between RTSM and
QEMU, but only a few matter to UEFI, and I think I have addressed all
of them. (some by changing QEMU, and some by changing UEFI.)
> - The correct approach when you have flash with 2 regions (small and large block size regions) is to use the fine grain for the UEFI variables (faster accesses in NVM). Using the large grain when the fine grain is available would not be appropriate. But at least it would ease the support between qEmu and RTSM.
I agree that in general using the smaller blocks is preferable, but I
think moving them to the larger blocks supported by both models is a
reasonable compromise to allow a single binary to boot on both.
> - In the past the RTSM team told me that the goal of RTSM was to be able to run the same binary you would run on your HW onto the model (RTSM). But it is actually not the case with RTSM A15 (its HW equivalent should be the ARM Test Chip ver1 (TC1)) as the HW and RTSM memory map are different.
>
> There are two solutions:
> 1) either I accept your patch - that will ease the maintenance (no difference between qEmu and RTSM support)
> 2) or I reject your patch. And I ask you to submit a new version that would introduce a build flag (eg: SUPPORT_QEMU) to differentiate RTSM and qEmu settings in Tianocore.
>
> I have to admit I prefer the solution 2) - but I am quite open to any valid arguments. My argument is I would prefer to expose the correct implementation when possible. And if qEmu adds support for the missing VExpress IP block in the future then it will be easier to restore the correct approach (ie: the default RTSM approach) for qEmu. I don't think that the flash will every be fixed in QEMU, since accurate modeling of flash writing is not all that valuable of a feature.
I can add a compile option for the flash, as I have done for the
networking. The networking required this due to conflicting ethernet
devices. (And here QEMU matches real hardware, and it is RTSM that is
'wrong'.) I think that the value of a common binary for a common case
is worth the cost of moving the variable storage to larger blocks, but
if you remain unconvinced I'll resubmit the patch with a build option
:) (and in that case I will also resubmit the networking patch so the
same build option is used for both QEMU related changes.)
Roy
>
> Thanks,
> Olivier
>
>
>> -----Original Message-----
>> From: Roy Franz [mailto:roy.franz@linaro.org]
>> Sent: 10 January 2014 16:11
>> To: ryan.harkin(a)linaro.org; Olivier Martin
>> Cc: edk2-devel(a)lists.sourceforge.net; linaro-uefi; Patch Tracking
>> Subject: Re: [PATCH V2] Move RTSM VExpress variable storage to 256k
>> flash blocks
>>
>> Hi Olivier - Any thoughts on this?
>>
>> Thanks,
>> Roy
>>
>>
>> On Thu, Dec 19, 2013 at 7:40 AM, Ryan Harkin <ryan.harkin(a)linaro.org>
>> wrote:
>> > I just wanted to confirm that this works in the 13.12 release and in
>> my own
>> > builds from the latest tree.
>> >
>> > Thanks Roy!
>> >
>> >
>> > On 12 December 2013 22:08, Roy Franz <roy.franz(a)linaro.org> wrote:
>> >>
>> >> Change the addresses/sizes of the variable storage areas to use 256k
>> >> blocks so UEFI is compatible with both the RTSM models and QEMU.
>> >>
>> >> The VExpress flash has non-uniform block sizes, with most blocks
>> being
>> >> 256k and the top 4 blocks being 64k. UEFI has been using these top
>> 64k
>> >> blocks for persistent variable storage. The RTSM models the non-
>> uniform
>> >> sizes, while QEMU only supports emulating flash with uniform block
>> sizes
>> >> which results in the top 256k (the 4 64k blocks) of flash being
>> unusable
>> >> for writing in QEMU. The ARM UEFI NOR flash driver currently
>> requires
>> >> that firmware volumes start at the base of a flash region, so the
>> >> variables are now stored at the base the region that consists of
>> >> the 256k blocks. It was previously at the base of the region
>> >> of 64k blocks.
>> >>
>> >> Note that this change will require RTSM flash images to be updated,
>> as
>> >> the variable storage has moved. Currently only the A15 model is
>> supported
>> >> by QEMU RTSM VExpress configurations. This patch only changes
>> >> the A15 configurations.
>> >>
>> >> Signed-off-by: Roy Franz <roy.franz(a)linaro.org>
>> >> Contributed-under: TianoCore Contribution Agreement 1.0
>> >> ---
>> >> ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 12
>> >> ++++++------
>> >> .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 12
>> >> ++++++------
>> >> 2 files changed, 12 insertions(+), 12 deletions(-)
>> >>
>> >> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
>> >> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
>> >> index 2d12f4b..c0196d9 100644
>> >> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
>> >> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
>> >> @@ -77,12 +77,12 @@
>> >> #
>> >> # NV Storage PCDs. Use base of 0x0C000000 for NOR1
>> >> #
>> >> -
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0FFC0000
>> >> -
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x00010000
>> >> -
>> >>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0FFD00
>> 00
>> >> -
>> >>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x000100
>> 00
>> >> -
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0FFE0000
>> >> -
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x00010000
>> >> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0C000000
>> >> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x00040000
>> >> +
>> >>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0C0400
>> 00
>> >> +
>> >>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x000400
>> 00
>> >> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0C080000
>> >> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x00040000
>> >>
>> >> gArmTokenSpaceGuid.PcdVFPEnabled|1
>> >>
>> >> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-
>> A15_MPCore.dsc
>> >> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
>> >> index efd80ab..69088ff 100644
>> >> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
>> >> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
>> >> @@ -79,12 +79,12 @@
>> >> #
>> >> # NV Storage PCDs. Use base of 0x0C000000 for NOR1
>> >> #
>> >> -
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0FFC0000
>> >> -
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x00010000
>> >> -
>> >>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0FFD00
>> 00
>> >> -
>> >>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x000100
>> 00
>> >> -
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0FFE0000
>> >> -
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x00010000
>> >> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0C000000
>> >> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x00040000
>> >> +
>> >>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0C0400
>> 00
>> >> +
>> >>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x000400
>> 00
>> >> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0C080000
>> >> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x00040000
>> >>
>> >> gArmTokenSpaceGuid.PcdVFPEnabled|1
>> >>
>> >> --
>> >> 1.7.10.4
>> >>
>> >
>
>
>
>
Change the addresses/sizes of the variable storage areas to use 256k
blocks so UEFI is compatible with both the RTSM models and QEMU.
The VExpress flash has non-uniform block sizes, with most blocks being
256k and the top 4 blocks being 64k. UEFI has been using these top 64k
blocks for persistent variable storage. The RTSM models the non-uniform
sizes, while QEMU only supports emulating flash with uniform block sizes
which results in the top 256k (the 4 64k blocks) of flash being unusable
for writing in QEMU. The ARM UEFI NOR flash driver currently requires
that firmware volumes start at the base of a flash region, so the
variables are now stored at the base the region that consists of
the 256k blocks. It was previously at the base of the region
of 64k blocks.
Note that this change will require RTSM flash images to be updated, as
the variable storage has moved. Currently only the A15 model is supported
by QEMU RTSM VExpress configurations. This patch only changes
the A15 configurations.
Saving of UEFI variables has been tested on RTSM and QEMU.
changes since V1:
* Change addresses used to be at base of flash region, as this
is a restriction of the ARM NOR flash driver.
* Remove A9 changes. The A15 is the only CPU currently support
in QEMU, so I removed the A9 changes since they can't be tested.
Roy Franz (1):
Move RTSM VExpress variable storage to 256k flash blocks
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 12 ++++++------
.../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 12 ++++++------
2 files changed, 12 insertions(+), 12 deletions(-)
--
1.7.10.4
The RTSM VExpress model emulates a different networking controller (91C111)
than the VExpres board (9118). QEMU emulates the 9118 which matches the
real hardare. This is the only configuration difference for UEFI between
building for RTSM or UEFI.
This patch adds a EDK2_ARMVE_USE_9118 macro that can be defined at build time
that can be used to build an image that supports QEMU. The default build is
unchanged and builds the RTSM configuration.
Signed-off-by: Roy Franz <roy.franz(a)linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
---
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 12 +++++++++---
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf | 8 +++++++-
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
index 4dcdfae..5323efd 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
@@ -141,9 +141,15 @@
gArmTokenSpaceGuid.PcdGicDistributorBase|0x2C001000
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x2C002000
- # Ethernet (SMSC 91C111)
- gArmPlatformTokenSpaceGuid.PcdLan91xDxeBaseAddress|0x1A000000
-
+ # Select network device based on build time macro
+!if $(EDK2_ARMVE_USE_9118) == 1
+ # Ethernet (SMSC 9118, for QEMU, matches real hardware)
+ gArmPlatformTokenSpaceGuid.PcdLan9118DxeBaseAddress|0x1A000000
+!else
+ # Ethernet (SMSC 91C111, for RTSM)
+ gArmPlatformTokenSpaceGuid.PcdLan91xDxeBaseAddress|0x1A000000
+!endif
+
#
# ARM OS Loader
#
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf
index be79efd..146f6f4 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf
@@ -144,7 +144,13 @@ READ_LOCK_STATUS = TRUE
INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
- INF ArmPlatformPkg/Drivers/LAN91xDxe/LAN91xDxe.inf
+!if $(EDK2_ARMVE_USE_9118) == 1
+ # LAN9118Dxe.inf for QEMU (matches use of 9118 on real VExpress board)
+ INF ArmPlatformPkg/Drivers/LAN9118Dxe/LAN9118Dxe.inf
+!else
+ # LAN91xDxe.inf for RTSM
+ INF ArmPlatformPkg/Drivers/LAN91xDxe/LAN91xDxe.inf
+!endif
#
# Multiple Console IO support
--
1.7.10.4
I have gotten the UEFI networking problems sorted out on QEMU (patches
posted to the QEMU list), and have updated the wiki page describing
running UEFI on QEMU.
https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/VersatileExpress/QEMU
Please let me know if you have any questions or feedback on the documentation.
Thanks,
Roy
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
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
