Linaro-uefi January 2016

linaro-uefi@lists.linaro.org

12 participants
15 discussions

by Daniel Samuelraj

We are able to compile CPP files for X64 using UDK2014 by using Visual Studio. How do we compile the same source for AARCH64? Appreciate the help! Thanks, Daniel

8 years, 10 months

[PATCH 0/3] add ARM and AArch64 support

by Ard Biesheuvel

These patches have been in my personal queue for about two years, and have already been incorporated into the Ubuntu packaged version of sbsigntool. Patch #1 and #2 fixes some generic issues, and patch #3 introduces the ARM and AArch64 magic values in the PE/COFF header check, which is all that is needed to get sbsign to sign ARM images. Ard Biesheuvel (3): sbsigntool: remove doubly defined IMAGE_FILE_MACHINE_AMD64 sbsigntool: fix handling of zero sized sections sbsigntool: add support for ARM and Aarch64 PE/COFF images src/coff/pe.h | 2 +- src/image.c | 48 +++++++++++--------- 2 files changed, 27 insertions(+), 23 deletions(-) -- 2.5.0

8 years, 10 months

[edk2] [PATCH v4 0/3] support multiple PL061 gpio controllers

by Haojian Zhuang

Changelog: v4: * Use 64-bit value on PL061 register base address. * Use fallback to be compatible with current PcdPL061GpioBase value when platform gpio driver isn't present. * Remove the dependancy on PL061. Move the dependancy to platform gpio driver instead. v3: * Remove GPIO_PIN_MASK_HIGH_8BIT() and GPIO_PIN_MASK_LOW_8BIT(). * Avoid to use MmioAnd8() on updating GPIO DATA register, since PL061 could access each bit by specified register offset. * Add PLATFORM_GPIO_CONTROLLER structure in embedded gpio. * Support multiple PL061 gpio controllers in one platform. v2: * Append the patch to fix gpio pin mask macro. Haojian Zhuang (3): ArmPlatformPkg: PL061: fix accessing GPIO DATA EmbeddedPkg: enhance for multiple gpio controllers ArmPlatformPkg: PL061: support multiple controller ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c | 137 +++++++++++++++------ .../Drivers/PL061GpioDxe/PL061GpioDxe.inf | 1 + ArmPlatformPkg/Include/Drivers/PL061Gpio.h | 51 ++++---- EmbeddedPkg/EmbeddedPkg.dec | 1 + EmbeddedPkg/Include/Protocol/EmbeddedGpio.h | 17 +++ 5 files changed, 143 insertions(+), 64 deletions(-) -- 2.1.4

8 years, 10 months

Secure UEFI on ARM: Queries and Latest sbsigntool broken?

by Bhupesh Sharma

Hi, I am trying to do some hands-on on qemu for aarch64 to boot a secure kernel image and running into the following two issues. I would appreciate any pointers on the same. 1. Not able to boot a signed kernel Image on qemu-2.5.0 built for aarch64: -------------------------------------------------------------------------- a) I am using the following OE image from Linaro for vexpress64: vexpress64-openembedded_minimal-armv8-gcc-4.9_20140823-686.img.gz b) I uncompress the same using the following command: # zcat vexpress64-openembedded_minimal-armv8-gcc-4.9_20140823-686.img.gz > vexpress64-oe.img c) I mount this on /mnt: # mount -o loop,offset=32256 vexpress64-oe.img /mnt d) # cd /mnt e) I have downloaded the latest efitools (git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git), which has the following commit as head: commit 613cf530f09fc1b27701b1be2538730539415db4 Author: James Bottomley <JBottomley(a)Parallels.com> Date: Wed Jan 14 22:57:41 2015 -0800 flash-var: new routine for manipulating variables in flash images f) I make the efitools using make and copy the PK, KEK and DB to /mnt: # cp -rf PK.auth /mnt/. ; cp -rf DB.auth /mnt/.; cp -rf KEK.auth /mnt/. ; cp -rf PK.crt /mnt/.; cp -rf DB.crt /mnt/. # cp -rf KEK.crt /mnt/. ; cp -rf DB.key /mnt/. g) Now I generate the corresponding .der files: # openssl x509 -in DB.crt -outform DER -out DB.der and so on.. h) Create a signed kernel Image using 'sbsigntools': # sbsign --key DB.key --cert DB.crt --output Image.signed Image i) # sync; umount /mnt j) Launch Qemu and provide the PK.der, KEK.der and DB.der files in the "User Mode": # qemu-system-aarch64 -m 1024 -cpu cortex-a57 -M virt -pflash flash0.img -pflash flash1.img -serial stdio -drive if=none,file=vexpress64-oe.img,id=hd0 -device virtio-blk-device,drive=hd0 k) Now, I enter the shell and provide the signed kernel Image as an input: Shell> Image.signed root=/dev/vda2 console=ttyAMA0,38400n8 earlycon=pl011,0x9000000 But I get the following error message: The image doesn't pass verification: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/HD(1,MBR,0x00000000,0x3F,0x21FC0)/\InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7ACDD640 Unloading driver at 0x00000000000 Command Error Status: Unsupported 2. Latest sbsigntool broken?: ----------------------------- I have downloaded the v0.7 sbsigntool from git://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git, which has the following commit as the head: commit ed53774c2f6b39ab63b312891ba7e98492f4d7e3 Author: James Bottomley <JBottomley(a)Parallels.com> Date: Fri Dec 19 16:44:54 2014 -0800 Version 0.7 Now, I see that when I use the DB.key and DB.crt to sign a kernel Image (Image) using this sbsigntool, I get a "Invalid PE header magic" error. # which sbsign /home/tools/sbsigntools/sbsigntools/src/sbsign # sbsign --version sbsign 0.7 # sbsign --key DB.key --cert DB.crt --output Image.signed Image Invalid PE header magic I use the following method to compile the sbsigntool: #./autogen.sh # ./configure # make Whereas, if I use the sbsign util (v0.6) available on by ubuntu 14.04 machine I can get the sbsigntool to sign the Image : # which sbsign /usr/bin/sbsign # sbsign --version sbsign 0.6 # sbsign --key DB.key --cert DB.crt --output Image.signed Image Regards, Bhupesh

8 years, 10 months

Quiry of EFI_EXT_SCSI_PASS_THRU_PROTOCOL, supporting sas disk for hisilicon hip06

by Zhangfei Gao

We are planning to support sas disk for hisilicon hip06. Want to double check whether using EFI_EXT_SCSI_PASS_THRU_PROTOCOL is right direction? Originally we would like directly use BLOCK IO, which need hack scsi cmd (cdb) and port lots of code. Happen to find the scsi protocol is somehow realized in ./MdePkg/Library/UefiScsiLib/UefiScsiLib.c, so switch to EFI_EXT_SCSI_PASS_THRU_PROTOCOL. By the way, I got one problem. The API of EFI_EXT_SCSI_PASS_THRU_PROTOCOL can not be called by MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c. While EFI_NOT_FOUND EFIERR (14) is returned. Status = ScsiBusDev->ExtScsiInterface->GetNextTargetLun (ScsiBusDev->ExtScsiInterface, &TargetId, &Lun); Any suggestion? Thanks Zhangfei

8 years, 10 months

[PATCH 1/2] ArmPkg: Bds: check path first for supporting fs

by Haojian Zhuang

BdsFileSystemSupport() checks Handle first before validating device path of file. There's the potential issue at here. BdsConnectAndUpdateDevicePath() will skip to locate handle if it's file or memory mapped. Then BdsFileSystemSupport() tries to use the invalid Handle when it's not file path in file system. Now check the device path first. If it's not file path in file system, return directly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Haojian Zhuang <haojian.zhuang(a)linaro.org> --- ArmPkg/Library/BdsLib/BdsFilePath.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/ArmPkg/Library/BdsLib/BdsFilePath.c b/ArmPkg/Library/BdsLib/BdsFilePath.c index aefeaed..42c6dc4 100644 --- a/ArmPkg/Library/BdsLib/BdsFilePath.c +++ b/ArmPkg/Library/BdsLib/BdsFilePath.c @@ -460,9 +460,11 @@ BdsFileSystemSupport ( EFI_STATUS Status; EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *FsProtocol; - Status = gBS->HandleProtocol (Handle, &gEfiSimpleFileSystemProtocolGuid, (VOID **)&FsProtocol); - - return (!EFI_ERROR (Status) && IS_DEVICE_PATH_NODE (RemainingDevicePath, MEDIA_DEVICE_PATH, MEDIA_FILEPATH_DP)); + if (IS_DEVICE_PATH_NODE (RemainingDevicePath, MEDIA_DEVICE_PATH, MEDIA_FILEPATH_DP)) { + Status = gBS->HandleProtocol (Handle, &gEfiSimpleFileSystemProtocolGuid, (VOID **)&FsProtocol); + return (!EFI_ERROR (Status)); + } + return FALSE; } EFI_STATUS -- 1.9.1

8 years, 11 months

[PATCH v2 5/5] Platforms/ARM: Add optional GICv3 with v2 Legacy support

by Ryan Harkin

GICv3 with v2 legacy support was removed, but this patch adds it back in conditionally. The default continues to use GICv3 natively unless specifically requested at build time by defining "ARM_FVP_GICV3_WITH_V2_LEGACY". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> --- Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc b/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc index b14aeb0..8f7d4aa 100644 --- a/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc +++ b/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc @@ -77,6 +77,10 @@ # It could be set FALSE to save size. gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE +!ifdef ARM_FVP_GICV3_WITH_V2_LEGACY + gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy|TRUE +!endif + [PcdsFixedAtBuild.common] gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Fixed Virtual Platform" gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"ARM-FVP" -- 2.1.4

8 years, 11 months

[PATCH 0/5] Copy commits from EDK2

by Ryan Harkin

Before removing Juno and FVP from ArmPlatformPkg, it has been noted that we should copy latest developments from EDK2 to OpenPlatformPkg to make sure there is not functionalilty lost. With the patches I manually copied over, I tried to keep the original author using the "--author" param, hopefully this translates across git send-email. The following 4 patches are copied from EDK2: [PATCH 1/5] ArmPlatformPkg/FVP: use 'auto' alignment and FIXED [PATCH 2/5] ArmPlatformPkg: Link separated VarCheckUefiLib NULL class [PATCH 3/5] ArmPlatformPkg/FVP: unify support for Foundation and Base [PATCH 4/5] ArmVExpressPkg/ArmVExpress-FVP-AArch64: run GICv3 in v3 And this one it not copied from EDK2: [PATCH 5/5] Platforms/ARM: Add optional GICv3 with v2 Legacy support

8 years, 11 months

Shell BCFG command - adding option data

by Ryan Harkin

Hello all, I'm using Shell.efi, a magic binary that is included in my aarch64 FVP binary. I'm trying to manipulate boot options using the BCFG command. And I've failed to work out how to set optional data. Before I clone ShellPkg and trawl through the code, I thought I'd post here and see if someone can tell me what's going wrong. First step, I created a boot option to run Shell.efi using the Intel BDS menu system. Thanks to Lazlo fixing cursor key support ;-) I added some simple optional data, "1 2 3 4". Next, I deleted all the other boot entries that were created by default, leaving only my new boot option. I created the option again, without optional data, giving it the description "xxxxxxxx" instead of "Shell.efi" (they're the same length) and here's what I see: Then I started the first new Shell.efi option. It gives an error that is hardly unexpected: '2' is not recognized as an internal or external command, operable program, or script file. So I ask bcfg to list my boot options and it says: Shell> bcfg boot dump Option: 00. Variable: Boot0006 Desc - Shell.efi DevPath - Fv(87940482-FC81-41C3-87E6-399CF85AC8A0)/\Shell.efi Optional- N Option: 01. Variable: Boot0000 Desc - xxxxxxxxx DevPath - Fv(87940482-FC81-41C3-87E6-399CF85AC8A0)/\Shell.efi Optional- N It claims there is no optional data. Hmmmm. So I dumped the value of variables Boot0006 and Boot0000 and I can see the optional data in there: Shell> setvar Boot0006 8BE4DF61-93CA-11D2-AA0D-00E098032B8C - Boot0006 - 005C Bytes 01 00 00 00 32 00 53 00 68 00 65 00 6C 00 6C 00 2E 00 65 00 66 00 69 00 00 00 04 07 14 00 82 04 94 87 81 FC C3 41 87 E6 39 9C F8 5A C8 A0 04 04 1A 00 5C 00 53 00 68 00 65 00 6C 00 6C 00 2E 00 65 00 66 00 69 00 00 00 7F FF 04 00 31 00 20 00 32 00 20 00 33 00 20 00 34 00 00 00 Shell> setvar Boot0000 8BE4DF61-93CA-11D2-AA0D-00E098032B8C - Boot0000 - 004C Bytes 01 00 00 00 32 00 78 00 78 00 78 00 78 00 78 00 78 00 78 00 78 00 78 00 00 00 04 07 14 00 82 04 94 87 81 FC C3 41 87 E6 39 9C F8 5A C8 A0 04 04 1A 00 5C 00 53 00 68 00 65 00 6C 00 6C 00 2E 00 65 00 66 00 69 00 00 00 7F FF 04 00 Shell> I started out this investigation because I was trying to add a boot option from the Shell command line and I can't work out how to add optional data: Shell> bcfg boot add 0 fs0:\Shell.efi "zzzzzzzzz" Target = 0001. bcfg: Add Boot0001 as 0 Shell> bcfg boot dump Option: 00. Variable: Boot0001 Desc - zzzzzzzzz DevPath - Fv(87940482-FC81-41C3-87E6-399CF85AC8A0)/\Shell.efi Optional- N Option: 01. Variable: Boot0006 Desc - Shell.efi DevPath - Fv(87940482-FC81-41C3-87E6-399CF85AC8A0)/\Shell.efi Optional- N Option: 02. Variable: Boot0000 Desc - xxxxxxxxx DevPath - Fv(87940482-FC81-41C3-87E6-399CF85AC8A0)/\Shell.efi Optional- N Shell> setvar Boot0001 8BE4DF61-93CA-11D2-AA0D-00E098032B8C - Boot0001 - 004C Bytes 01 00 00 00 32 00 7A 00 7A 00 7A 00 7A 00 7A 00 7A 00 7A 00 7A 00 7A 00 00 00 04 07 14 00 82 04 94 87 81 FC C3 41 87 E6 39 9C F8 5A C8 A0 04 04 1A 00 5C 00 53 00 68 00 65 00 6C 00 6C 00 2E 00 65 00 66 00 69 00 00 00 7F FF 04 00 Shell> bcfg boot -opt 0 1 2 3 4 Shell> setvar Boot0001 8BE4DF61-93CA-11D2-AA0D-00E098032B8C - Boot0001 - 004C Bytes 01 00 00 00 32 00 7A 00 7A 00 7A 00 7A 00 7A 00 7A 00 7A 00 7A 00 7A 00 00 00 04 07 14 00 82 04 94 87 81 FC C3 41 87 E6 39 9C F8 5A C8 A0 04 04 1A 00 5C 00 53 00 68 00 65 00 6C 00 6C 00 2E 00 65 00 66 00 69 00 00 00 7F FF 04 00 And after setting the optional data, the output of bcfg and setvar remain the same. I also tried setting the optional data at the same time as creating the boot option, but that fails in the same way: Shell> bcfg boot add 0 fs0:\Shell.efi "Shell" -opt 0 1 2 3 So, am I doing something wrong or is BCFG buggy?? I'm off to look at the code, because I think there's at least one bug... Regards, Ryan.

8 years, 11 months

[PATCH 0/2] ArmPlatformPkg: Remove FVP and Juno

by Ryan Harkin

ARM Ltd Platform support is migrating to use OpenPlatformPkg [1]. Currently, Juno and FVP exist both in EDK2's ArmPlatformPkg and in OpenPlatformPkg. And they are starting to diverge, with OpenPlatformPkg being the most up-to-date with current developments. To prevent this divergence, remove the .dsc and .fdf files from ArmPlatformPkg and leave OpenPlatformPkg as the master. We can't remove ArmJuno.dec yet because ACPI still uses it to set the include path to ArmPlatform.h. [PATCH 1/2] ArmPlatformPkg: remove ArmVExpress-FVP-AArch64 [PATCH 2/2] ArmPlatformPkg: remove ArmJuno.dsc/fdf ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 291 ----------------------------------------------------------------------- ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 365 ----------------------------------------------------------------------------------------- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 317 ----------------------------------------------------------------------------- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 401 -------------------------------------------------------------------------------------------------- [1] https://git.linaro.org/uefi/OpenPlatformPkg.git

8 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi January 2016