Hi Naresh,
I looked through the git logs, and didn't see any specific mention
of which revision of PSCI is currently
supported in the Linaro EDK2. I'm posting to the linaro-uefi list, as
someone on here should be familiar with
the PSCI status.
Roy
On Mon, Sep 8, 2014 at 11:36 AM, Naresh Bhat <naresh.bhat(a)linaro.org> wrote:
> Hi Roy,
>
> The ACPI patches supports only PSCI v0.2+ but the HARDWARE-Xen
> hypervisor does not have the support for PSCI 0.2+. Now before I
> start the porting activity I just want to clarify the following stuff
>
> 1. Does the UEFI (i.e. linaro-edk2 latest tag) support PSCI version 0.2+ ?
>
> My understanding is yes, it should be supported. The reason is that
> we have already tested the ACPI on different platforms with UEFI :)
> and we are using the same UEFI on Xen is't it ?
>
> Can you please double check and confirm the PSCI v0.2+ support in UEFI ?
>
> Thanks and Regards
> -Naresh
Adding Linaro-UEFI list as Leif is on sabbatical.
I've also applied ShellR64.patch into the EDK Shell source dir.
[cid:image002.png@01CFC139.48278580]
Thanks,
MELVIN DIONIO [Description: Description: Description: red]
MTS Product Development Engineer | System Level Test
7171 Southwest Parkway, Austin, TX 78735 USA
O +(1) 512-602-0414
[Description: Description: Description: image004] facebook<https://www.facebook.com/AMD> | amd.com<http://www.amd.com/>
From: Dionio, Melvin
Sent: Monday, August 25, 2014 4:58 PM
To: 'leif.lindholm(a)linaro.org'
Subject: EFI Shell via PXEboot
Importance: High
Hi Leif,
I'm Melvin Dionio from AMD and is currently working on our ARMv8 SOC. I'm trying to PXEBoot an EFI Shell with a hard coded path for the EFI boot loader. This is to negate having to run startup.nsh.
I tried to use the following EDK2 and Shell project to generate the Shell.efi but kept on getting an issue. Not sure what I'm still missing. I'm using this commandline:
[cid:image010.png@01CFC139.48278580]
I've tried to use the EFI Shell Project below but kept on getting an error. Is there a way to hardcode the EFI path without having to use this EFI Shell project?
Linaro EDK2
http://git.linaro.org/git/uefi/linaro-edk2.git
EFI Shell Project
https://svn.code.sf.net/p/efi-shell/code/trunk/Shell/
[cid:image011.png@01CFC139.48278580]
Error:
[cid:image012.png@01CFC139.48278580]
Regards,
MELVIN DIONIO [Description: Description: Description: red]
MTS Product Development Engineer | System Level Test
7171 Southwest Parkway, Austin, TX 78735 USA
O +(1) 512-602-0414
[Description: Description: Description: image004] facebook<https://www.facebook.com/AMD> | amd.com<http://www.amd.com/>
I think this patchset is in good shape, with the exception of the usage of
the EFI memory map, which I am looking for some suggestions on. The current
implementation populates the bootinfo memory bank list from the EFI memory map,
rather than from the device tree, and doesn't use any reserved ranges. This
works, however the EFI memory map can contain a lot of entries, many of which
are small. Depending on the layout, this could trigger the code that sets
up the frametable to discard most of memory. Also, as a side effect of some
memory being ignored to manage the frametable size, the EFI stub needs to
ensure that it loads modules into memory that XEN is going to map. The
FVP model has 2GBytes of DRAM at 0x80000000 and another 2 at 0x800000000,
so the disjoint case is common.
It seems that both these problems go largely away if sparse frametable mappings are
supported, but I'm not sure how much effort that would be. I think most
of the work done to handle things robustly with the non-sparse frametable
would not apply once a sparse frametable is supported. Does adding support
for a sparse frametable mapping seem like a reasonable way forward on this?
This patch series adds EFI support for arm64 in the form of a EFI stub in
similar fashion to the linux kernel EFI support. A PE/COFF header is created
in head.S, as there is no toolchain support for PE/COFF on arm64. This also
has the advantage that the file is both an "Image" file and a PE/COFF
executable - the same binary can be loaded and run either way. The EFI 'stub'
code is a shim layer that serves as the loader for the XEN kernel in the EFI
environment. The stub loads the dom0 kernel and initrd if required, and adds
entries for them as well as for the EFI data structures into the device tree
passed to XEN. Once the device tree is constructed, EFI boot services are
exited, and the stub transfers control to the normal XEN entry point. The only
indication XEN has that it was loaded via the stub is that the device tree
contains EFI properties. This is all very similar to the arm/arm64 Linux
kernel EFI stubs.
This patchset is based on the staging branch to get Ian's multiboot/device
tree patches.
This series is also available at:
git://git.linaro.org/people/roy.franz/xen.git arm64-efi-stub-v2
Changes since v1:
(I have tried to address all feedback on v1)
* Added common/efi directory for shared EFI code, and arch/arm/efi for
arm-specfic code. Global build hacking of -fshort-wchar removed.
arm32, arm64, and x86 with/without EFI enabled toolchain all build.
The x86 build previously autodetected whether the EFI version should
be built or not based on toolchain support. I couldn't get this working
nicely with the common code, so for x86 I have the common code always
build, and the EFI autodection works as normal for building the EFI
version.
* Basic use of the EFI memory map instead of FDT based memory description.
More work needed to resolve differences between FDT description of
a small number of large memory banks with reserved regions, and EFI's
potentially long list of available regions, which can be long.
* More refactoring of common EFI code to not directly exit using blexit(),
as this broke the pre-linking targets. All shared code returns status,
and it is up to the caller to exit and clean up.
* Reduced the number of patches. Refactoring of x86 code first, then moving
all code to efi-shared.c in one patch.
* Fixed formatting/tab issues in new files, added Emacs footer.
* Fixed efi_get_memory_map to return NULL map pointer on error in addition
to failed status.
* Added comments in head.S regarding PE/COFF specification, and 1:1
mapping used by EFI code.
* Updated device tree bindings to use new multiboot bindings. Since the stub
is always built into XEN, we don't have to support older bindings.
Roy Franz (12):
Create efi-shared.[ch], and move string functions
rename printErrMsg to PrintErrMesgExit
Refactor get_parent_handle for sharing
Refactor read_file() so it can be shared.
replace split_value() with truncate_string()
add read_config_file() function for XEN EFI config file
create handle_cmdline() function
Refactor get_argv() for sharing
Move shared EFI functions to efi-shared.c
add arm64 cache flushing code from linux
Add fdt_create_empty_tree() function.
Add EFI stub for arm64
xen/arch/arm/Makefile | 5 +
xen/arch/arm/Rules.mk | 1 +
xen/arch/arm/arm64/Makefile | 1 +
xen/arch/arm/arm64/cache.S | 100 +++++
xen/arch/arm/arm64/head.S | 185 +++++++++-
xen/arch/arm/efi/Makefile | 2 +
xen/arch/arm/efi/efi.c | 714 ++++++++++++++++++++++++++++++++++++
xen/arch/arm/xen.lds.S | 1 +
xen/arch/x86/Rules.mk | 1 +
xen/arch/x86/efi/boot.c | 625 ++++---------------------------
xen/common/Makefile | 2 +
xen/common/efi/Makefile | 3 +
xen/common/efi/efi-shared.c | 648 ++++++++++++++++++++++++++++++++
xen/common/libfdt/Makefile.libfdt | 2 +-
xen/common/libfdt/fdt_empty_tree.c | 84 +++++
xen/include/asm-arm/arm64/efibind.h | 216 +++++++++++
xen/include/asm-arm/efibind.h | 2 +
xen/include/asm-arm/setup.h | 2 +-
xen/include/efi/efi-shared.h | 72 ++++
xen/include/xen/libfdt/libfdt.h | 1 +
20 files changed, 2101 insertions(+), 566 deletions(-)
create mode 100644 xen/arch/arm/arm64/cache.S
create mode 100644 xen/arch/arm/efi/Makefile
create mode 100644 xen/arch/arm/efi/efi.c
create mode 100644 xen/common/efi/Makefile
create mode 100644 xen/common/efi/efi-shared.c
create mode 100644 xen/common/libfdt/fdt_empty_tree.c
create mode 100644 xen/include/asm-arm/arm64/efibind.h
create mode 100644 xen/include/asm-arm/efibind.h
create mode 100644 xen/include/efi/efi-shared.h
--
2.0.0
Hi Olivier,
Yes it is. Here is that part of fdf.
Thanx.
#
# Networking stack
#
INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
INF MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
From: olivier.martin(a)arm.com
To: nd6969(a)hotmail.com; linaro-uefi(a)lists.linaro.org
Subject: RE: [Linaro-uefi] UEFI Shell Command "ifconfig" Error
Date: Mon, 4 Aug 2014 09:57:51 +0100
Hello Chris,For general questions, I would suggest to send emails to edk2-devel(a)lists.sourceforge.net. Do you confirm the driver ‘MdeModulePkg/Universal/Network/Ip4Dxe’ is within your FDF file? Thanks,Olivier From: linaro-uefi-bounces(a)lists.linaro.org [mailto:linaro-uefi-bounces@lists.linaro.org] On Behalf Of Chris Cuthbert
Sent: 02 August 2014 23:50
To: linaro-uefi(a)lists.linaro.org
Subject: [Linaro-uefi] UEFI Shell Command "ifconfig" Error Hello,I am trying to add an ethernet driver to UEFI. It is using PCI IO protocol and producing SNP. When I issue "ifconfig -l eth0" command in UEFI shell, I get an error:
Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found (3B95AA31-3793-434B-8667-C8070892E05E).I have copied the networking stack set up from ArmVExpress.dsc.inc and ArmVExpress-networking.fdf.inc that includes the Ip4ConfigDxe.inf module. What am I missing ?Thanx,
Hello,
I am trying to add an ethernet driver to UEFI. It is using PCI IO protocol and producing SNP. When I issue "ifconfig -l eth0" command in UEFI shell, I get an error:
Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found (3B95AA31-3793-434B-8667-C8070892E05E).
I have copied the networking stack set up from ArmVExpress.dsc.inc and ArmVExpress-networking.fdf.inc that includes the Ip4ConfigDxe.inf module. What am I missing ?
Thanx,
On Tue, Jul 29, 2014 at 3:34 PM, Olivier Martin <olivier.martin(a)arm.com>
wrote:
> $
/work/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-objdump
-S -D
Build/BeagleBoard/DEBUG_GCC48/ARM/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll
>
>
>
> FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet32(PcdFdBaseAddress) +
(EFI_PHYSICAL_ADDRESS)PcdGet32(PcdFdSize);
>
> 705c: 4b90 ldr r3, [pc, #576] ;
(72a0 <MemoryPeim+0x2a4>)
>
> 705e: 681b ldr r3, [r3, #0]
>
> 7060: 4618 mov r0, r3
>
> 7062: f04f 0100 mov.w r1, #0
>
> 7066: 4b8f ldr r3, [pc, #572] ; (72a4
<MemoryPeim+0x2a8>)
>
> 7068: 681b ldr r3, [r3, #0]
>
> 706a: 461a mov r2, r3
>
> 706c: f04f 0300 mov.w r3, #0
>
> (...)
>
> 72a0: 0000b4ec andeq fp, r0, ip, ror #9
>
> 72a4: 0000b4f0 strdeq fp, [r0], -r0
>
> (...)
>
> 0000b4ec <_gPcd_FixedAtBuild_PcdFdBaseAddress>:
>
> b4ec: 80008000 andhi r8, r0, r0
>
> 0000b4f0 <_gPcd_FixedAtBuild_PcdFdSize>:
>
> b4f0: 000b0000 andeq r0, fp, r0
>
> I noticed in an earlier email you mentioned ArmPlatformPrePiUniCore.lib.
If you want to look at the final ELF file, you should have a look at
‘.dll’. I know the name is confusing... But ‘.dll’ is actually a ELF file!
Thanks Olivier! The '.dll' dump looks similar to ^ and contains proper PCD
values
at the right address. The '.lib' however shows all the PCDs to be at
00000000:
Disassembly of section .rodata._gPcd_FixedAtBuild_PcdFvBaseAddress:
00000000 <_gPcd_FixedAtBuild_PcdFvBaseAddress>:
0: 80008000 andhi r8, r0, r0
Is it all right that these two addresses are different? If so, what else
sould I check
to trace the fault?
Thanks,
Varad
Hello,
I am trying to add an ethernet driver to UEFI. It is using PCI IO protocol
and producing SNP. When I issue "ifconfig -l eth0" command in UEFI shell, I
get an error:
Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found
(3B95AA31-3793-434B-8667-C8070892E05E).
I have copied the networking stack set up from ArmVExpress.dsc.inc and
ArmVExpress-networking.fdf.inc that includes the Ip4ConfigDxe.inf module.
What am I missing ?
Thanx,
Narinder
Hi, I am working on the BeagleBoneBlack port for EDK2 and am facing an
issue with
PcdGet(): it always returns `0` no matter what the PCD is set to. However,
FixedPcdGet() works fine (I've had to patch edk2 to replace all PcdGet
calls with
FixedPcdGet to get PrePi working which is a bad idea).
The build report too shows the PCDs being set to their proper values,
and so do the
AutoGen.i file macros like `const UINT32 _gPcd_FixedAtBuild_PcdFvBaseAddress
= 0x80008000U;`
I've come up with two reasons to this,
* Is there a build flag I'm missing to enable PcdGet support?
* `_gPcd_FixedAtBuild_PcdFvBaseAddress` is declared with
`GLOBAL_REMOVE_IF_UNREFERENCED` in AutoGen.c and gets removed before
I can use it. This also explains why FixedPcdGet would work, since
`_PCD_VALUE_PcdFvBaseAddress` is correctly #defined to be 0x80008000U.
This happens for all fixed-at-build type PCDs. Also, I'm linked to
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf for the buid. What could
I try to fix it?
Thanks,
Varad
