Linaro-uefi November 2013

linaro-uefi@lists.linaro.org

8 participants
10 discussions

Re: [Linaro-uefi] [PATCH v3 2/3] arm: Add [U]EFI runtime services support

by Leif Lindholm

Hi Will, Thanks for having a look. On Fri, Nov 29, 2013 at 04:10:16PM +0000, Will Deacon wrote: > > This patch implements basic support for UEFI runtime services in the > > ARM architecture - a requirement for using efibootmgr to read and update > > the system boot configuration. > > > > It uses the generic configuration table scanning to populate ACPI and > > SMBIOS pointers. > > I've got a bunch of implementation questions, so hopefully you can help me > to understand what this is doing! I can try :) > > diff --git a/arch/arm/kernel/uefi.c b/arch/arm/kernel/uefi.c > > new file mode 100644 > > index 0000000..f771026 > > --- /dev/null > > +++ b/arch/arm/kernel/uefi.c > > +/* > > + * Returns 1 if 'facility' is enabled, 0 otherwise. > > + */ > > +int efi_enabled(int facility) > > +{ > > + return test_bit(facility, &arm_uefi_facility) != 0; > > !test_bit(...) ? Could do. Cloned from the x86 implementation. Matt Fleming has indicated some rework coming in this area. > > +static int __init uefi_init(void) > > +{ > > + efi_char16_t *c16; > > + char vendor[100] = "unknown"; > > + int i, retval; > > + > > + efi.systab = early_memremap(uefi_system_table, > > + sizeof(efi_system_table_t)); > > + > > + /* > > + * Verify the UEFI System Table > > + */ > > + if (efi.systab == NULL) > > + panic("Whoa! Can't find UEFI system table.\n"); > > + if (efi.systab->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE) > > + panic("Whoa! UEFI system table signature incorrect\n"); > > + if ((efi.systab->hdr.revision >> 16) == 0) > > + pr_warn("Warning: UEFI system table version %d.%02d, expected 1.00 or greater\n", > > + efi.systab->hdr.revision >> 16, > > + efi.systab->hdr.revision & 0xffff); > > + > > + /* Show what we know for posterity */ > > + c16 = (efi_char16_t *)early_memremap(efi.systab->fw_vendor, > > + sizeof(vendor)); > > + if (c16) { > > + for (i = 0; i < (int) sizeof(vendor) - 1 && *c16; ++i) > > + vendor[i] = c16[i]; > > + vendor[i] = '\0'; > > + } > > + > > + pr_info("UEFI v%u.%.02u by %s\n", > > + efi.systab->hdr.revision >> 16, > > + efi.systab->hdr.revision & 0xffff, vendor); > > + > > + retval = efi_config_init(NULL); > > + if (retval == 0) > > + set_bit(EFI_CONFIG_TABLES, &arm_uefi_facility); > > Does this actually need to be atomic? Not necessarily, but it's neater than masking, and only called once. > > + > > + early_iounmap(c16, sizeof(vendor)); > > + early_iounmap(efi.systab, sizeof(efi_system_table_t)); > > + > > + return retval; > > +} > > + > > +static __init int is_discardable_region(efi_memory_desc_t *md) > > +{ > > +#ifdef KEEP_ALL_REGIONS > > + return 0; > > +#endif > > Maybe just have a dummy is_discardable_region in this case, like we usually > do instead of inlining the #ifdef? OK. > > + if (md->attribute & EFI_MEMORY_RUNTIME) > > + return 0; > > + > > + switch (md->type) { > > +#ifdef KEEP_BOOT_SERVICES_REGIONS > > + case EFI_BOOT_SERVICES_CODE: > > + case EFI_BOOT_SERVICES_DATA: > > +#endif > > + /* Keep tables around for any future kexec operations */ > > + case EFI_ACPI_RECLAIM_MEMORY: > > + return 0; > > + /* Preserve */ > > + case EFI_RESERVED_TYPE: > > + return 0; > > + } > > + > > + return 1; > > +} > > [...] > > > +int __init uefi_memblock_arm_reserve_range(void) > > +{ > > + if (!of_scan_flat_dt(fdt_find_uefi_params, NULL)) > > + return 0; > > + > > + set_bit(EFI_BOOT, &arm_uefi_facility); > > Similar comment wrt atomicity here (and in the rest of this patch). Similar response. > > + uefi_init(); > > + > > + remove_regions(); > > + > > + return 0; > > +} > > + > > +/* > > + * Disable instrrupts, enable idmap and disable caches. > > interrupts Yeah. > > + */ > > +static void __init phys_call_prologue(void) > > +{ > > + local_irq_disable(); > > + > > + /* Take out a flat memory mapping. */ > > + setup_mm_for_reboot(); > > + > > + /* Clean and invalidate caches */ > > + flush_cache_all(); > > + > > + /* Turn off caching */ > > + cpu_proc_fin(); > > + > > + /* Push out any further dirty data, and ensure cache is empty */ > > + flush_cache_all(); > > Do we care about outer caches here? I think we do. We jump into UEFI and make it relocate itself to the new virtual addresses, with MMU disabled (so all accesses NC). > This all looks suspiciously like > copy-paste from __soft_restart; Yeah, 'cause you told me to :) > perhaps some refactoring/reuse is in order? Could do. Turn this into a process.c:idcall_prepare(), or something less daftly named? > > +} > > + > > +/* > > + * Restore original memory map and re-enable interrupts. > > + */ > > +static void __init phys_call_epilogue(void) > > +{ > > + static struct mm_struct *mm = &init_mm; > > + > > + /* Restore original memory mapping */ > > + cpu_switch_mm(mm->pgd, mm); > > + > > + /* Flush branch predictor and TLBs */ > > + local_flush_bp_all(); > > +#ifdef CONFIG_CPU_HAS_ASID > > + local_flush_tlb_all(); > > +#endif > > ... and this looks like copy-paste from setup_mm_for_reboot. You told me that too! Only this goes the other way. Is the refactoring worth the extra code? > > + local_irq_enable(); > > +} > > + > > +static int __init remap_region(efi_memory_desc_t *md, efi_memory_desc_t *entry) > > +{ > > + u64 va; > > + u64 paddr; > > + u64 size; > > + > > + *entry = *md; > > + paddr = entry->phys_addr; > > + size = entry->num_pages << EFI_PAGE_SHIFT; > > + > > + /* > > + * Map everything writeback-capable as coherent memory, > > + * anything else as device. > > + */ > > + if (md->attribute & EFI_MEMORY_WB) > > + va = (u64)((u32)uefi_remap(paddr, size) & 0xffffffffUL); > > + else > > + va = (u64)((u32)uefi_ioremap(paddr, size) & 0xffffffffUL); > > Do you really need all those casts/masking? I didn't find a better way to avoid warnings when building this code for both LPAE/non-LPAE. We are guaranteed by the UEFI spec that all addresses will be <4GB, but the descriptor format is still 64-bit physical/virtual addresses, and we need to pass them back as such. > > + if (!va) > > + return 0; > > + entry->virt_addr = va; > > + > > + if (uefi_debug) > > + pr_info(" %016llx-%016llx => 0x%08x : (%s)\n", > > + paddr, paddr + size - 1, (u32)va, > > + md->attribute & EFI_MEMORY_WB ? "WB" : "I/O"); > > + > > + return 1; > > +} > > + > > +static int __init remap_regions(void) > > +{ > > + void *p, *next; > > + efi_memory_desc_t *md; > > + > > + memmap.phys_map = uefi_remap(uefi_boot_mmap, uefi_boot_mmap_size); > > + if (!memmap.phys_map) > > + return 0; > > + memmap.map_end = (void *)memmap.phys_map + uefi_boot_mmap_size; > > + memmap.desc_size = uefi_mmap_desc_size; > > + memmap.desc_version = uefi_mmap_desc_ver; > > + > > + /* Allocate space for the physical region map */ > > + memmap.map = kzalloc(memmap.nr_map * memmap.desc_size, GFP_KERNEL); > > + if (!memmap.map) > > + return 0; > > + > > + next = memmap.map; > > + for (p = memmap.phys_map; p < memmap.map_end; p += memmap.desc_size) { > > + md = p; > > + if (is_discardable_region(md) || md->type == EFI_RESERVED_TYPE) > > + continue; > > + > > + if (!remap_region(p, next)) > > + return 0; > > What about the kzalloc above, does that need freeing? In case of failure? Yes, good point. > > +/* > > + * This function switches the UEFI runtime services to virtual mode. > > + * This operation must be performed only once in the system's lifetime, > > + * including any kecec calls. > > + * > > + * This must be done with a 1:1 mapping. The current implementation > > + * resolves this by disabling the MMU. > > + */ > > +efi_status_t __init phys_set_virtual_address_map(u32 memory_map_size, > > + u32 descriptor_size, > > + u32 descriptor_version, > > + efi_memory_desc_t *dsc) > > +{ > > + uefi_phys_call_t *phys_set_map; > > + efi_status_t status; > > + > > + phys_call_prologue(); > > + > > + phys_set_map = (void *)(unsigned long)virt_to_phys(uefi_phys_call); > > + > > + /* Called with caches disabled, returns with caches enabled */ > > + status = phys_set_map(memory_map_size, descriptor_size, > > + descriptor_version, dsc, > > + efi.set_virtual_address_map) > > +; > > Guessing this relies on a physically-tagged cache? Wouldn't hurt to put > something in the epilogue code to deal with vivt caches if they're not > prohibited by construction (e.g. due to some build dependency magic). Sorry, I don't quite follow? How would it depend on a physically-tagged cache? > > + phys_call_epilogue(); > > + > > + return status; > > +} > > diff --git a/arch/arm/kernel/uefi_phys.S b/arch/arm/kernel/uefi_phys.S > > new file mode 100644 > > index 0000000..e9a1542 > > --- /dev/null > > +++ b/arch/arm/kernel/uefi_phys.S > > @@ -0,0 +1,59 @@ > > +/* > > + * arch/arm/kernel/uefi_phys.S > > + * > > + * Copyright (C) 2013 Linaro Ltd. > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License version 2 as > > + * published by the Free Software Foundation. > > + */ > > + > > +#include <linux/linkage.h> > > +#define PAR_MASK 0xfff > > + > > + .text > > +@ uefi_phys_call(a, b, c, d, *f) > > + .align 5 > > + .pushsection .idmap.text, "ax" > > +ENTRY(uefi_phys_call) > > + @ Save physical context > > + mov r12, sp > > + push {r4-r5, r12, lr} > > + > > + @ Extract function pointer (don't write r12 beyond this) > > + ldr r12, [sp, #16] > > + > > + @ Convert sp to 32-bit physical > > + mov lr, sp > > + ldr r4, =PAR_MASK > > + and r5, lr, r4 @ Extract lower 12 bits of sp > > + mcr p15, 0, lr, c7, c8, 1 @ Write VA -> ATS1CPW > > This is broken without an isb but, more to the point, why can't we just do > the standard lowmem virt_to_phys conversion here instead? I can't use that from within asm (right?). Are you suggesting that I should duplicate the mechanism of virt_to_phys here? > > + mrc p15, 0, lr, c7, c4, 0 @ Physical Address Register > > + mvn r4, r4 > > + and lr, lr, r4 @ Clear lower 12 bits of PA > > + add lr, lr, r5 @ Calculate phys sp > > + mov sp, lr @ Update > > + > > + @ Disable MMU > > + mrc p15, 0, lr, c1, c0, 0 @ ctrl register > > + bic lr, lr, #0x1 @ ...............m > > + mcr p15, 0, lr, c1, c0, 0 @ disable MMU > > + isb > > + > > + @ Make call > > + blx r12 > > This is basically a copy-paste of cpu_v7_reset. Perhaps using some assembler > macros would help here? Well, I explicitly don't want to touch SCTLR.TE. We could macro-ize it, but I think that would increase the amount of code. > > + > > + pop {r4-r5, r12, lr} > > + > > + @ Enable MMU + Caches > > + mrc p15, 0, r1, c1, c0, 0 @ ctrl register > > + orr r1, r1, #0x1000 @ ...i............ > > + orr r1, r1, #0x0005 @ .............c.m > > + mcr p15, 0, r1, c1, c0, 0 @ enable MMU > > + isb > > Why do we have to enable the caches so early? You'd prefer it being done back in phys_call_epilogue()? / Leif

11 years

Re: [Linaro-uefi] [PATCH v3 0/3] (U)EFI runtime services for arm

by Leif Lindholm

On Fri, Nov 29, 2013 at 11:53:19AM +0000, Matt Fleming wrote: > On Thu, 28 Nov, at 04:41:20PM, Leif Lindholm wrote: > > In systems based on [U]EFI-conformant firmware, runtime services provide > > a standardised way for the kernel to update firmware environment > > variables. This is used for example by efibootmgr to update which image > > should be loaded on next boot. > > > > This patchset implements basic support for UEFI runtime services on ARM > > platforms, as well as the basic underlying EFI support. It also defines > > a mechanism by which the required information is passed from the > > bootloader (the EFI stub submitted separately) to the kernel via FDT > > entries. > > This all looks pretty good to me. Is this series going through the ARM > trees? Thanks. That's the plan. / Leif

11 years

[PATCH 0/3] *** Support SMBIOS/DMI on arm32/64 ***

by Yi Li

The patches support SMBIOS/DMI on arm system, it tested by dmidecode and lshw tools. The first patch is wrapping remap/unmap methond for general archs, and has been posted for review to x86 and ia64, waiting the ack. The last two patches depend on booting from UEFI and SMBIOS data reported as Runtime Services Data type. Ard Biesheuvel (1): firmware/dmi_scan: generalize for use by other archs Yi Li (2): ARM64:DMI: Add smbios/dmi support on arm64 ARM32:DMI: Add smbios/dmi support on arm32 arch/arm/Kconfig | 13 +++++++++++++ arch/arm/include/asm/dmi.h | 28 ++++++++++++++++++++++++++++ arch/arm/kernel/setup.c | 2 ++ arch/arm64/Kconfig | 10 ++++++++++ arch/arm64/include/asm/dmi.h | 28 ++++++++++++++++++++++++++++ arch/arm64/kernel/setup.c | 2 ++ arch/ia64/include/asm/dmi.h | 10 +++++++--- arch/x86/include/asm/dmi.h | 8 ++++++-- drivers/firmware/dmi_scan.c | 20 +++++++++++--------- 9 files changed, 107 insertions(+), 14 deletions(-) create mode 100644 arch/arm/include/asm/dmi.h create mode 100644 arch/arm64/include/asm/dmi.h -- 1.7.9.5

11 years

[PATCH 1/5] DMI: Enhance for multi archs

by Yi Li

This patch makes a couple of changes to the SMBIOS/DMI scanning code so it can be used on other archs (such as ARM and arm64): (a) wrap the calls to ioremap()/iounmap(), this allows the use of a flavor of ioremap() more suitable for random unaligned access; (b) allow the non-EFI fallback probe into hardcoded physical address 0xF0000 to be disabled. Signed-off-by: Yi Li <yi.li(a)linaro.org> --- drivers/firmware/dmi_scan.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c index fa0affb..92d7ce0 100644 --- a/drivers/firmware/dmi_scan.c +++ b/drivers/firmware/dmi_scan.c @@ -108,7 +108,7 @@ static int __init dmi_walk_early(void (*decode)(const struct dmi_header *, { u8 *buf; - buf = dmi_ioremap(dmi_base, dmi_len); + buf = dmi_early_remap(dmi_base, dmi_len); if (buf == NULL) return -1; @@ -116,7 +116,7 @@ static int __init dmi_walk_early(void (*decode)(const struct dmi_header *, add_device_randomness(buf, dmi_len); - dmi_iounmap(buf, dmi_len); + dmi_early_unmap(buf, dmi_len); return 0; } @@ -483,18 +483,19 @@ void __init dmi_scan_machine(void) * needed during early boot. This also means we can * iounmap the space when we're done with it. */ - p = dmi_ioremap(efi.smbios, 32); + p = dmi_early_remap(efi.smbios, 32); if (p == NULL) goto error; memcpy_fromio(buf, p, 32); - dmi_iounmap(p, 32); + dmi_early_unmap(p, 32); if (!dmi_present(buf)) { dmi_available = 1; goto out; } } else { - p = dmi_ioremap(0xF0000, 0x10000); +#ifdef DMI_SCAN_MACHINE_NON_EFI_FALLBACK + p = dmi_early_ioremap(0xF0000, 0x10000); if (p == NULL) goto error; @@ -510,12 +511,13 @@ void __init dmi_scan_machine(void) memcpy_fromio(buf + 16, q, 16); if (!dmi_present(buf)) { dmi_available = 1; - dmi_iounmap(p, 0x10000); + dmi_early_unmap(p, 0x10000); goto out; } memcpy(buf, buf + 16, 16); } - dmi_iounmap(p, 0x10000); + dmi_early_unmap(p, 0x10000); +#endif } error: pr_info("DMI not present or invalid.\n"); @@ -787,13 +789,13 @@ int dmi_walk(void (*decode)(const struct dmi_header *, void *), if (!dmi_available) return -1; - buf = ioremap(dmi_base, dmi_len); + buf = dmi_remap(dmi_base, dmi_len); if (buf == NULL) return -1; dmi_table(buf, dmi_len, dmi_num, decode, private_data); - iounmap(buf); + dmi_unmap(buf, dmi_len); return 0; } EXPORT_SYMBOL_GPL(dmi_walk); -- 1.7.9.5

11 years

Re: [Linaro-uefi] UEFI build failure

by Roy Franz

resending to right list address... On Wed, Nov 20, 2013 at 12:35 PM, Roy Franz <roy.franz(a)linaro.org> wrote: > Hi Steven, > > I'm getting the following failure when building for V7 VExpress > RTSM. This failure starts in rev > e0cec187231a1bf8fc12caa0c4f734771cf6fe42, which is the merge of the > ACPI topic branch. > > Do I need to change something in my build environment in order to support ACPI? > > Thanks, > Roy > > > > "arm-linux-gnueabihf-ld" -o > /home/rfranz/cavium/linaro/trees/uefi-next/Build/ArmVExpress-RTSM-A15/RELEASE_ARMLINUXGCC/ARM/ArmPkg/Drivers/AcpiTables/rtsm_ve-v7/AcpiTables/OUTPUT/./Oem0.dll > -nostdlib --pie --entry _ReferenceAcpiTable > /home/rfranz/cavium/linaro/trees/uefi-next/Build/ArmVExpress-RTSM-A15/RELEASE_ARMLINUXGCC/ARM/ArmPkg/Drivers/AcpiTables/rtsm_ve-v7/AcpiTables/OUTPUT/./Oem0.obj > arm-linux-gnueabihf-ld: warning: cannot find entry symbol > _ReferenceAcpiTable; defaulting to 00000228 > "GenFw" -o /home/rfranz/cavium/linaro/trees/uefi-next/Build/ArmVExpress-RTSM-A15/RELEASE_ARMLINUXGCC/ARM/ArmPkg/Drivers/AcpiTables/rtsm_ve-v7/AcpiTables/OUTPUT/./Oem0.acpi > -c /home/rfranz/cavium/linaro/trees/uefi-next/Build/ArmVExpress-RTSM-A15/RELEASE_ARMLINUXGCC/ARM/ArmPkg/Drivers/AcpiTables/rtsm_ve-v7/AcpiTables/OUTPUT/./Oem0.dll > GenFw: ERROR 3000: Invalid > /home/rfranz/cavium/linaro/trees/uefi-next/Build/ArmVExpress-RTSM-A15/RELEASE_ARMLINUXGCC/ARM/ArmPkg/Drivers/AcpiTables/rtsm_ve-v7/AcpiTables/OUTPUT/./Oem0.dll > bad ARM dynamic relocations, unkown type 23. > make: *** [/home/rfranz/cavium/linaro/trees/uefi-next/Build/ArmVExpress-RTSM-A15/RELEASE_ARMLINUXGCC/ARM/ArmPkg/Drivers/AcpiTables/rtsm_ve-v7/AcpiTables/OUTPUT/Oem0.acpi] > Error 2 > > > build.py... > : error 7000: Failed to execute command > make --no-print-directory tbuild > [/home/rfranz/cavium/linaro/trees/uefi-next/Build/ArmVExpress-RTSM-A15/RELEASE_ARMLINUXGCC/ARM/ArmPkg/Drivers/AcpiTables/rtsm_ve-v7/AcpiTables]

11 years, 1 month

[PATCH] FVP: use fdt.dtb in default config

by Ryan Harkin

This single UEFI binary now supports multiple versions of the FVP Base Models. As they all use a different DTB file, load "fdt.dtb" and ask the user to make sure it is linked to the correct file in the user instructions. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> --- .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc index c325721..194be40 100755 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc @@ -168,7 +168,7 @@ gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/Image" gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"console=ttyAMA0 earlyprintk=pl011,0x1c090000 debug user_debug=31 loglevel=9 root=/dev/vda2" !endif - gArmPlatformTokenSpaceGuid.PcdDefaultFdtLocalDevicePath|L"VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/fvp-base-gicv2-psci.dtb" + gArmPlatformTokenSpaceGuid.PcdDefaultFdtLocalDevicePath|L"VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/fdt.dtb" gArmPlatformTokenSpaceGuid.PcdDefaultBootType|3 gArmPlatformTokenSpaceGuid.PcdFdtDevicePath|L"VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/fdt.dtb" -- 1.7.9.5

11 years, 1 month

[PATCH 0/1] ArmPkg/PL390Gic: Fixed setting of the Interrupt

by Ryan Harkin

The patch that follows would be good to add to our tree. It isn't critical, but it fixes an issue that Roy was seeing with single core models. The patch is taken directly from upstream and I tested it here locally, although only on the newer FVP models. It applied cleanly to our tree, so I don't see any problems taking it and adding it to linaro-topic-misc or somewhere suitable like that. You could even create a new topic for upstream fixes that will be removed next cycle if you wanted to be ultra-organised.

11 years, 1 month

[PATCH] FVP: add support for new FVP Foundation model

by Ryan Harkin

The FVP Foundation Model is very similar to the existing FVP models, except it has no video or MMC devices. This patch, along with commit ID 15f829f: "FVP: Add DSC and FDF files for the FVP platform", should be removed whenever uefi-next catches up to upstream Tianocore. They are duplicates of commit ID 75f6303, "ArmPlatformPkg: Added initial support for the FVP Base and Foundation Models". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> --- .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 15 ++++++++++++++- .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 4 ++++ 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc index 0970752..c325721 100755 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc @@ -40,7 +40,9 @@ ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf +!ifndef ARM_FOUNDATION_FVP LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf +!endif TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf @@ -131,18 +133,25 @@ ## PL031 RealTimeClock gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C170000 +!ifndef ARM_FOUNDATION_FVP ## PL111 Versatile Express Motherboard controller gArmPlatformTokenSpaceGuid.PcdPL111LcdBase|0x1C1F0000 ## PL180 MMC/SD card controller gArmPlatformTokenSpaceGuid.PcdPL180SysMciRegAddress|0x1C010048 gArmPlatformTokenSpaceGuid.PcdPL180MciBaseAddress|0x1C050000 +!endif # - # ARM PL390 General Interrupt Controller + # ARM General Interrupt Controller # +!ifdef ARM_FVP_LEGACY_GICV2_LOCATION + gArmTokenSpaceGuid.PcdGicDistributorBase|0x2C001000 + gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x2C002000 +!else gArmTokenSpaceGuid.PcdGicDistributorBase|0x2f000000 gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x2C000000 +!endif # Ethernet (SMSC 91C111) gArmPlatformTokenSpaceGuid.PcdLan91xDxeBaseAddress|0x1A000000 @@ -253,7 +262,9 @@ ArmPkg/Drivers/PL390Gic/PL390GicDxe.inf ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf ArmPkg/Drivers/TimerDxe/TimerDxe.inf +!ifndef ARM_FOUNDATION_FVP ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf +!endif ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf # @@ -261,11 +272,13 @@ # ArmPkg/Filesystem/SemihostFs/SemihostFs.inf +!ifndef ARM_FOUNDATION_FVP # # Multimedia Card Interface # EmbeddedPkg/Universal/MmcDxe/MmcDxe.inf ArmPlatformPkg/Drivers/PL180MciDxe/PL180MciDxe.inf +!endif # # FAT filesystem + GPT/MBR partitioning diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf index 4f2d457..b35a4da 100755 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf @@ -174,7 +174,9 @@ READ_LOCK_STATUS = TRUE INF ArmPkg/Drivers/PL390Gic/PL390GicDxe.inf INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf +!ifndef ARM_FOUNDATION_FVP INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf +!endif INF ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf # @@ -190,11 +192,13 @@ READ_LOCK_STATUS = TRUE INF FatBinPkg/EnhancedFatDxe/Fat.inf INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf +!ifndef ARM_FOUNDATION_FVP # # Multimedia Card Interface # INF EmbeddedPkg/Universal/MmcDxe/MmcDxe.inf INF ArmPlatformPkg/Drivers/PL180MciDxe/PL180MciDxe.inf +!endif # # UEFI application (Shell Embedded Boot Loader) -- 1.7.9.5

11 years, 1 month

[PATCH v2] VEA5: Fix boot failure

by Ryan Harkin

This patch fixes a failure of the Versatile Express A5 to boot due to the ROM not starting at address zero. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> --- .../ArmVExpressPkg/ArmVExpress-CTA5s.fdf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA5s.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA5s.fdf index 74934e6..dc54a3b 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA5s.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA5s.fdf @@ -74,6 +74,8 @@ FV = FVMAIN_COMPACT ################################################################################ [FV.FVMAIN_SEC] +FvBaseAddress = 0x0 +FvForceRebase = TRUE FvAlignment = 8 ERASE_POLARITY = 1 MEMORY_MAPPED = TRUE -- 1.7.9.5

11 years, 1 month

[PATCH] VEA5: Fix boot failure

by Ryan Harkin

This patch fixes a failure of the Versatile Express A5 to boot due to the ROM not starting at address zero. Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> --- .../ArmVExpressPkg/ArmVExpress-CTA5s.fdf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA5s.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA5s.fdf index 74934e6..dc54a3b 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA5s.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA5s.fdf @@ -74,6 +74,8 @@ FV = FVMAIN_COMPACT ################################################################################ [FV.FVMAIN_SEC] +FvBaseAddress = 0x0 +FvForceRebase = TRUE FvAlignment = 8 ERASE_POLARITY = 1 MEMORY_MAPPED = TRUE -- 1.7.9.5

11 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi November 2013