Linaro-uefi

linaro-uefi@lists.linaro.org

811 discussions

by Ryan Harkin

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.

11 years, 5 months

PE/COFF machine type for ARM V7 binaries

by Roy Franz

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

11 years, 5 months

FastModels 0.8.3.5311 for ARMv8 now available

by Ryan Harkin

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.

11 years, 5 months

Re: [Linaro-uefi] [PATCH V2] Move RTSM VExpress variable storage to 256k flash blocks

by Roy Franz

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

11 years, 5 months

Re: [Linaro-uefi] [PATCH V2] Move RTSM VExpress variable storage to 256k flash blocks

by Roy Franz

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

11 years, 5 months

[PATCH V2] Move RTSM VExpress variable storage to 256k flash blocks

by Roy Franz

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

11 years, 5 months

[PATCH] Add build option to support QEMU VExpress networking

by Roy Franz

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

11 years, 5 months

UEFI working on QEMU A15 VExpress platform.

by Roy Franz

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

11 years, 6 months

64-bit memory map constraints

by Rob Herring

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

11 years, 6 months

64-bit memory map constraints

by Rob Herring

11 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi