Linaro-uefi January 2015

linaro-uefi@lists.linaro.org

18 participants
26 discussions

[PATCH 0/3] Improve Bds selectability on Arm

by Leif Lindholm

The Arm ports support running the IntelBds these days, but still depend on the ArmPkg BdsLib. Break this out into a separate library, and fix up some loose ends causing problems when that happens. Leif Lindholm (3): ArmPkg: break out common Bds functions ArmPkg/ArmPlatformPkg: remove components when using PlatformIntelBdsLib ArmVirtualizationPkg: use ArmBdsHelperLib with PlatformIntelBdsLib ArmPkg/ArmPkg.dsc | 4 + ArmPkg/Include/Library/ArmBdsHelperLib.h | 96 ++++ ArmPkg/Library/ArmBdsHelperLib/ArmBdsHelperLib.c | 487 +++++++++++++++++++++ ArmPkg/Library/ArmBdsHelperLib/ArmBdsHelperLib.inf | 44 ++ ArmPkg/Library/BdsLib/BdsFilePath.c | 364 +-------------- ArmPkg/Library/BdsLib/BdsHelper.c | 112 ----- ArmPkg/Library/BdsLib/BdsLib.inf | 1 + ArmPlatformPkg/ArmPlatformPkg.dsc | 2 + ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 4 + .../ArmVirtualizationPkg/ArmVirtualization.dsc.inc | 2 + .../ArmVirtualizationPkg/ArmVirtualizationQemu.dsc | 1 + .../PlatformIntelBdsLib/PlatformIntelBdsLib.inf | 2 +- .../Library/PlatformIntelBdsLib/IntelBdsPlatform.c | 1 + .../PlatformIntelBdsLib/PlatformIntelBdsLib.inf | 2 +- 14 files changed, 645 insertions(+), 477 deletions(-) create mode 100644 ArmPkg/Include/Library/ArmBdsHelperLib.h create mode 100644 ArmPkg/Library/ArmBdsHelperLib/ArmBdsHelperLib.c create mode 100644 ArmPkg/Library/ArmBdsHelperLib/ArmBdsHelperLib.inf -- 2.1.3

10 years, 5 months

question on reducing root file system size

by Ravi Chhabra

Hi Olivier, I hope you are doing good. Last few days, I had been trying to reduce the root fs size generated using buildroot. I was considering using uclibc library instead of glibc. I see that when I select Linaro AArch64 13.* toolchain, I don't have an option of selecting uclibc library. Please tell the right way to use uclibc library with Linaro toolchain package. Also, please share some ideas on reducing the root filesystem size. I have only 8MB of on-chip RAM which I plan to use to boot linux. Thanks, Ravi C

10 years, 5 months

ARM64 UEFI Shell TFTP command

by Ryan Harkin

I can't find a TFTP command in the shell on my ARM64 Juno platform. Did I miss something? (I think not) Considering TFTP is already supported via the ARM BDS menus, I'm thinking that a command can't be that hard to implement. Although maybe I'm being overly optimistic here! Google shows that many Intel platforms already have a TFTP command in their shell, so someone has certainly written one before, although I can't easily find any source for it. Cheers, Ryan.

10 years, 5 months

efibootmgr on Juno Board

by Sandeep Paulraj

Hi, Has anybody tried using efibootmgr on the Juno Board? I am using linaro-image-lamp-genericarmv8-20141212-729.rootfs.tar.gz <http://releases.linaro.org/latest/members/arm/openembedded/juno-lsk/linaro-…> from http://releases.linaro.org/latest/members/arm/openembedded/juno-lsk However, i see issues while using efibootmgr root@genericarmv8:~# efibootmgr -V version unknown (fix Makefile!) root@genericarmv8:~# efibootmgr -a Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables. Try 'modprobe efivars' as root. --Sandeep

10 years, 5 months

kernel memory allocation issue with uefi

by varadgautam＠gmail.com

I get the following error while loading the LEG-UEFI kernel [1] on a BeagleBone Black (omap2plus_defconfig + efi stub support) when the kernel requests memory from UEFI.: Shell> zImage EFI stub: Booting Linux Kernel... ConvertPages: failed to find range 80800000 - 81FFFFFF EFI stub: ERROR: Unable to allocate memory for uncompressed kernel. EFI stub: ERROR: Failed to relocate kernel Error: Image at 0009A3F8000 start failed: Load Error Unloading driver at 0x0009A3F8000 Error reported: Load Error `memmap` shows the map to have a gap from 80800000 - 81FFFFFF (PcdFdBaseAddress for BBB UEFI is 0x80800000, so that's where I have UEFI loaded). Does this mean I should adjust the BBB memory map so that all external allocations are done *after* the UEFI region (possibly by reserving the lower addresses)? Is there an alternate way of getting the kernel up? Shell> memmap Type Start End #pages Attributes LoaderData 0000000080000000-00000000807FFFFF 0000000000000800 000000000000000F Available 0000000080A00000-000000009A6BBFFF 0000000000019CBC 000000000000000F LoaderCode 000000009A6BC000-000000009A779FFF 00000000000000BE 000000000000000F Reserved 000000009A77A000-000000009A77DFFF 0000000000000004 000000000000000F RT_Code 000000009A77E000-000000009A78AFFF 000000000000000D 800000000000000F Available 000000009A78B000-000000009EE54FFF 00000000000046CA 000000000000000F BS_Data 000000009EE55000-000000009EE79FFF 0000000000000025 000000000000000F Available 000000009EE7A000-000000009EE9EFFF 0000000000000025 000000000000000F BS_Data 000000009EE9F000-000000009EEABFFF 000000000000000D 000000000000000F Available 000000009EEAC000-000000009EEB2FFF 0000000000000007 000000000000000F BS_Data 000000009EEB3000-000000009F400FFF 000000000000054E 000000000000000F Available 000000009F401000-000000009F401FFF 0000000000000001 000000000000000F BS_Data 000000009F402000-000000009F5BEFFF 00000000000001BD 000000000000000F Available 000000009F5BF000-000000009F646FFF 0000000000000088 000000000000000F BS_Code 000000009F647000-000000009F74EFFF 0000000000000108 000000000000000F RT_Code 000000009F74F000-000000009F762FFF 0000000000000014 800000000000000F RT_Data 000000009F763000-000000009F794FFF 0000000000000032 800000000000000F BS_Data 000000009F795000-000000009F795FFF 0000000000000001 000000000000000F RT_Data 000000009F796000-000000009F796FFF 0000000000000001 800000000000000F BS_Data 000000009F797000-000000009F7ACFFF 0000000000000016 000000000000000F RT_Data 000000009F7AD000-000000009F7ADFFF 0000000000000001 800000000000000F BS_Data 000000009F7AE000-000000009FFFFFFF 0000000000000852 000000000000000F Reserved : 4 Pages (16,384) LoaderCode: 190 Pages (778,240) LoaderData: 2,048 Pages (8,388,608) BS_Code : 264 Pages (1,081,344) BS_Data : 4,006 Pages (16,408,576) RT_Code : 33 Pages (135,168) RT_Data : 52 Pages (212,992) ACPI Recl : 0 Pages (0) ACPI NVS : 0 Pages (0) MMIO : 0 Pages (0) Available : 123,963 Pages (507,752,448) Total Memory: 510 MB (534,773,760 Bytes) [1] https://git.linaro.org/people/leif.lindholm/linux.git/shortlog/refs/heads/t… Thanks, Varad

10 years, 6 months

[RFC PATCH 0/5] OvmfPkg/XenBusDxe: add ARM support

by Ard Biesheuvel

This series adds ARM support to the XenBusDxe driver. It consists of an implementation of the hypercall interface, changes to work around the lack of PCI, and a bugfix. Finally, patch #5 wires it up to the VirtFdtDxe driver that is used in the ARM VM port, and will also be used by the Xen/ARM targeted port. Note that this is build tested only, both on ARM and x86. I am struggling to get access to suitable ARM hardware, and running Xen on my Macbook has proven to be a discouraging experience, hence the 'RFC' status of this patches. If anyone feels adventurous and bored, it would be good to know that I did not break x86 support in this series, so any testing is highly appreciated. Ard Biesheuvel (5): Ovmf/Xen: move arch specific hypercall implementation to XenHypercallLib Ovmf/Xen: allow non-PCI usage of XenBusDxe Ovmf/Xen: add ARM and AArch64 support to XenBusDxe Ovmf/Xen: fix pointer to int cast in XenBusDxe ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to "xen,xen" DT node .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c | 33 ++ .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf | 1 + .../Include/IndustryStandard/Xen/arch-arm/xen.h | 436 +++++++++++++++++++++ OvmfPkg/Include/IndustryStandard/Xen/xen.h | 2 +- OvmfPkg/Include/Library/XenHypercallLib.h | 36 ++ OvmfPkg/Include/Protocol/XenIo.h | 48 +++ .../Library/XenHypercallLib/Aarch64/Hypercall.S | 26 ++ OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S | 25 ++ .../XenHypercallLib}/Ia32/hypercall.nasm | 6 +- .../XenHypercallLib}/X64/hypercall.nasm | 6 +- .../Library/XenHypercallLib/XenHypercallLibArm.inf | 37 ++ .../Library/XenHypercallLib/XenHypercallLibIntel.c | 77 ++++ .../XenHypercallLib/XenHypercallLibIntel.inf | 48 +++ OvmfPkg/OvmfPkg.dec | 5 + OvmfPkg/OvmfPkgIa32.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + OvmfPkg/XenBusDxe/AtomicsGcc.c | 44 +++ OvmfPkg/XenBusDxe/ComponentName.c | 2 +- OvmfPkg/XenBusDxe/GrantTable.c | 9 +- OvmfPkg/XenBusDxe/GrantTable.h | 3 +- OvmfPkg/XenBusDxe/XenBus.c | 6 +- OvmfPkg/XenBusDxe/XenBusDxe.c | 192 +++++++-- OvmfPkg/XenBusDxe/XenBusDxe.h | 3 +- OvmfPkg/XenBusDxe/XenBusDxe.inf | 13 +- OvmfPkg/XenBusDxe/XenHypercall.c | 30 +- OvmfPkg/XenBusDxe/XenHypercall.h | 31 -- 27 files changed, 1002 insertions(+), 120 deletions(-) create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h create mode 100644 OvmfPkg/Include/Library/XenHypercallLib.h create mode 100644 OvmfPkg/Include/Protocol/XenIo.h create mode 100644 OvmfPkg/Library/XenHypercallLib/Aarch64/Hypercall.S create mode 100644 OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S rename OvmfPkg/{XenBusDxe => Library/XenHypercallLib}/Ia32/hypercall.nasm (81%) rename OvmfPkg/{XenBusDxe => Library/XenHypercallLib}/X64/hypercall.nasm (78%) create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibArm.inf create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibIntel.c create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibIntel.inf create mode 100644 OvmfPkg/XenBusDxe/AtomicsGcc.c -- 1.8.3.2

10 years, 6 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi January 2015