Since we have a UEFI sprint in Cambridge next week, I have pushed next
month's first alpha a little bit early - so that we can start working
on that one directly.
I have set the upstream base commit to
f747c71 ShellPkg: fix display for map command with filtering
The release-prep branch has also been updated.
New for this month is the hisilicon-d01 platform, automatically pulled
in from hisilicon/uefi.git
/
Leif
Hello expert.
I'm working on enabling UEFI variable service.
I'd like to call UEFI's variable service on Kernel at runtime.
I'm using Kernel based on leg-kernel 3.14.0 which is in " http://git.linaro.org/leg/acpi/leg-kernel.git"
And I enabled EFI, ACPI features.
After UEFI-Kernel booting was done, I found some interface in sysfs on Kernel shell as below.
/sys/firmware/efi # ls
efivars systab vars
Referencing "http://uefidk.com/blog/accessing-uefi-variables-linux", I tried to mount using
"mount -t efivarfs none /sys/firmware/efi/efivars" command. But It didn't work showing below messages.
sys/firmware/efi/vars # mount -t efivarfs none /sys/firmware/efi/efivars
Unable to handle kernel paging request at virtual address 12c00018
pgd = ffffffc07ceee000
[12c00018] *pgd=00000000fcc97003, *pmd=0000000000000000
Internal error: Oops: 96000006 [#1] PREEMPT SMP
How can I call variable service on Kernel ?
Thanks.
Add smbios/dmi support on arm64 system, it depends on
EFI boot.
Signed-off-by: Yi Li <yi.li(a)linaro.org>
---
arch/arm64/Kconfig | 11 +++++++++++
arch/arm64/include/asm/dmi.h | 28 ++++++++++++++++++++++++++++
arch/arm64/kernel/setup.c | 2 ++
3 files changed, 41 insertions(+)
create mode 100644 arch/arm64/include/asm/dmi.h
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 385236f..0fd8ed8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -295,6 +295,17 @@ config EFI
allow the kernel to be booted as an EFI application. This
is only useful on systems that have UEFI firmware.
+config DMI
+ bool "Enable support for SMBIOS (DMI) tables"
+ depends on EFI
+ default y
+ help
+ This enables SMBIOS/DMI feature for systems.
+
+ This option is only useful on systems that have UEFI firmware.
+ However, even with this option, the resultant kernel should
+ continue to boot on existing non-UEFI platforms.
+ dmideocde tool can work which depends on STRICT_DEVMEM is false.
endmenu
menu "Userspace binary formats"
diff --git a/arch/arm64/include/asm/dmi.h b/arch/arm64/include/asm/dmi.h
new file mode 100644
index 0000000..f6e6004
--- /dev/null
+++ b/arch/arm64/include/asm/dmi.h
@@ -0,0 +1,28 @@
+/*
+ * arch/arm64/include/asm/dmi.h
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Written by: Yi Li (yi.li(a)linaro.org)
+ *
+ * based on arch/ia64/include/asm/dmi.h
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+
+#ifndef _ASM_DMI_H
+#define _ASM_DMI_H 1
+
+#include <linux/slab.h>
+#include <asm/io.h>
+
+/* Use normal IO mappings for DMI */
+#define dmi_early_remap(x, l) efi_lookup_mapped_addr(x)
+#define dmi_early_unmap(x, l)
+#define dmi_remap(x, l) efi_lookup_mapped_addr(x)
+#define dmi_unmap(x)
+#define dmi_alloc(l) kzalloc(l, GFP_ATOMIC)
+
+#endif
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 72a0c8e..7de9e96 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -43,6 +43,7 @@
#include <linux/of_platform.h>
#include <linux/efi.h>
#include <linux/acpi.h>
+#include <linux/dmi.h>
#include <asm/fixmap.h>
#include <asm/cputype.h>
@@ -405,6 +406,7 @@ void __init setup_arch(char **cmdline_p)
static int __init arm64_device_init(void)
{
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ dmi_scan_machine();
return 0;
}
arch_initcall(arm64_device_init);
--
1.7.9.5
Hi guys,
As SMBIOS/DMI patch depends on EFI support, when EFI patch is into
the mainline ,then it's ready for SMBIOS patch.
here, I make few changes base on
https://git.linaro.org/leg/acpi/leg-kernel.git/shortlog/refs/tags/leg-20140…
please help to review, and give the feedback.
thanks!
(it's tested on FVP model normally, with smbiosview, dmidecode, lshw )
I will send the patch again by git send-email.
Yi
Hi everyone,
I am working to port UEFI (EDKII) to the BeagleBone Black as a Google
Summer of Code intern
with Leif Lindolm of Linaro Enterprise Group. Over the past couple of weeks
I've been going
through the EDKII Module Writer's Guide, the build file specifications, the
SoC and board TRMs
and the edk2 repo bundled documentation and got my BBB running with ssh /
vnc / ftdi debugger
set up.
I have broken down the implementation into two parts, based on [1]:
* Create an Am335xPkg to support the ARM SoC, taking ArmPlatformPkg as base
and changing
the build spec files and library implementations.
* Use this to build BeagleBoneBlackPkg.
= Questions =
I am a little unclear about which Libraries and Drivers from the
ArmPlatformPkg and ArmPkg I will
require in the port, and which of these I can use as-provided from the
repo. How do I figure this out?
Also, is there any more documentation I should look into related to UEFI
porting?
I will be documenting my work at [2] (nothing relevant there yet) and will
soon set up a github repo.
I'll keep you posted about my progress.
Thanks,
Varad
[1]
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPlatform…
[2] varadgautam.wordpress.com
Hi, experts:
Linaro has released a 64bit kernel for ARMv8 FVP model.
So, how to compile it to Aarch32 bin?
I want to try to change boot wrapper code to switch to Aarch32 EL1
before jumping to kernel entrypoint.
So, I need to compile linux kernel to Aarch32 bin.
Best wishes,
Booting UEFI for our 64 bit models/platforms has become more complex due to
upstream changes.
You can build UEFI as per usual, however, before you can boot the .fd file,
you will have to wrap it into a Firmware Image Package (aka FIP).
You will not be able to mix "old " and "new" versions of UEFI and TF.
--------------------------------------------------------------------------------
- Get the UEFI build tools
--------------------------------------------------------------------------------
git clone git.linaro.org/arm/uefi/uefi-tools.git
PATH=$PATH:`pwd`/uefi-tools
You can also download a pre-built binary from a release or snapshot build
place such as:
http://releases.linaro.org/14.04/components/kernel/uefi-linarohttp://snapshots.linaro.org/components/kernel/linaro-edk2/latesthttp://snapshots.linaro.org/components/kernel/linaro-edk2-release-prep/late…http://snapshots.linaro.org/components/kernel/fvp-pre-boot/latest
--------------------------------------------------------------------------------
- Build UEFI for the FVP models
--------------------------------------------------------------------------------
git clone git://git.linaro.org/uefi/linaro-edk2.git
cd linaro-edk2
uefi-build fvp_minimal
This will give you a .fd file, such as:
./Build/ArmVExpress-FVP-AArch64/RELEASE_GCC48/FV/FVP_AARCH64_EFI.fd
You will then need to point the "BL33" environment variable to this file,
eg:
export
BL33=`pwd`/Build/ArmVExpress-FVP-AArch64/RELEASE_GCC48/FV/FVP_AARCH64_EFI.fd
--------------------------------------------------------------------------------
- Build the Trusted Firmware for FVP models
--------------------------------------------------------------------------------
git clone git://git.linaro.org/arm/arm-trusted-firmware.git
CROSS_COMPILE=aarch64-linux-gnu- make PLAT=fvp all fip
You will then have two important files:
./build/fvp/release/bl1.bin
./build/fvp/release/fip.bin
--------------------------------------------------------------------------------
- Boot the model
--------------------------------------------------------------------------------
Pass the bl1.bin and fip.bin files as parameters to the model. Eg, this is
how I booted my model:
/linaro/fastmodels/FVP_Base_AEMv8A-AEMv8A/models/Linux64_GCC-4.1/FVP_Base_AEMv8A-AEMv8A
-C pctl.startup=0.0.0.0 -C bp.secure_memory=0 -C cluster0.NUM_CORES=1 -C
cluster1.NUM_CORES=1 -C cache_state_modelled=0 -C
bp.pl011_uart0.untimed_fifos=1 -C
bp.secureflashloader.fname=./build/fvp/release/bl1.bin -C
bp.flashloader0.fname=./build/fvp/release/fip.bin -C
bp.virtioblockdevice.image_path=/linaro/releases/oe/14.04/fastmodel/sd.img
-C bp.hostbridge.interfaceName=ARMryan -C bp.smsc_91c111.enabled=true -C
bp.smsc_91c111.mac_address=00:02:f7:ef:67:e6
Of course, your installation path to the models and the location of your
disk image will vary.
Hope this all helps,
Regards,
Ryan.
Hi Roy,
[CC'd linaro-uefi as this is a recurring theme since the breakage]
Most likely, you are not building UEFI into a FIP any more. Upstream code
for FVP models changed, so now you build and run in a different way
altogether.
This email from me to linaro-uefi explained it:
http://lists.linaro.org/pipermail/linaro-uefi/2014-April/000237.html
Since then, I believe Fu Wei put together a wiki page to capture the info.
https://wiki.linaro.org/Internal/People/FuWei/Trusted_Firmware#How_to_make_…
... not sure if that was ever made "official"
Cheers,
Ryan.
On 16 May 2014 02:24, Roy Franz <roy.franz(a)linaro.org> wrote:
>
> I'm wondering what target I should use from uefi-build.sh to build the
> "uefi_fvp_base.bin" configuration
> that is available for download as part of the releases.
> http://releases.linaro.org/latest/openembedded/aarch64/uefi_fvp-base.bin
>
> The above binary boots, while a binary built with the "fvp minimal" target
> does not. The "fvp minimal" target
> produces a binary that is the same size, but I don't know if it is really
> what I should be using.
>
> Thanks,
> Roy
>
>
Hi, All
This is a 'request for comments' email. Thanks for your time and patience.
In our development of PXE boot and boot from SATA features, this question
jumps to us. In short, do you think it makes sense to save the PXE
downloaded binaries to local storage for future usage? Then how.
We think this is a common requirement, and the community should have a
common code to support this, instead of allowing each vendor to implement
their own private methods.
Here is what we thought, very basic. Welcome to share your opinion with us.
Appreciate:
During PXE boot, the zImage launching sequence is like this:
UEFI (PXE) → Grub2.efi → zImage + dtb → launch...
zImage and dtb are fetched from a local server to the target board. It
makes sense that to allow users to save these two files onto the board’s
local storage, so next time they don’t have to download them again through
the network.
So can we add a process in PXE boot to save kernel to a local permanent
storage such as a SATA drive, or a Flash memory?
Here is a suggestion, to add 3 steps into PXE:
1. provide a user interface, to ask whether to save the kernel to local
storage;
2. ask for a device path/folder name to save the files;
3. save the files.
UEFI BIOS to start download grub2.efi and run
|
grub to download kernel by using UEFI API
|
if user say Yes to save kernel to local storage
|
ask for a local storage device name and a full path name
|
writing to device
|
launch kernel
Thanks in advance.
Best regards,
Guodong Xu
Hi all,
I have now pushed a second alpha of 2014.05, but it will not be a
release candidate, since all of the software models are currently
lacking networking support.
All 15 platforms do build for both DEBUG and RELEASE targets, though -
at least on my local pc.
Expect -a3 and -rc1 next week.
/
Leif
