Hi all,
I drafted a quick wikipage to explain how to port EDK2 (UEFI Open Source
implementation) on a new ARM Platform :
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPlatformP
kg
I am aware this wikipage could require some EDK2 knowledge but I will try to
fill these gaps in the future by creating or referring to wikipages that
explains some of the key EDK2 concepts.
Feel free to directly send me an email if you want more explanations about a
specific concept. That would help to define priorities.
Olivier
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-09-29
Please note the wiki page for the next meeting is set :
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-06
Summary of the action points:
- [CARRIEDOVER] Grant to followup the status of Linaro UEFI membership
- [CARRIEDOVER] David Rusling: - Linaro UEFI membership - target Linaro
Connect
- [CARRIEDOVER] Grant to draft a position on secure boot, from the
Linaro perspective, which can be reviewed by Linaro TSC
- [CARRIEDOVER] <tba> Interact with Microsoft on ARM boot interface -
there is some discussion more to say say by around mid October
- [CARRIEDOVER] Grant: Draft DTB recommended practices and getting the
recommended practices document out and merged into a public tree by
Linaro Connect (actually means the week before - as there are other
events before the Connect) INPROGRESS,
- [CARRIEDOVER] Grant: Select date & time for the next f2f meeting (Next
F2F in ELCE in Prague (OCT 26-28) ?)
Option 1: half-day meeting during ELCE, some folks won't make it - this
is the plan to go for Final confirmation
- [CARRIEDOVER] Will: Define SMP boot requirements - spin tables? Target
Linaro Connect. No updates.
- [ACTION] Olivier to send the wiki link with the documentation on how
to port UEFI to new platforms
- [ACTION] Jean-Christophe to send a RFC to the list regarding the
kernel image format and entry protocol
- [ACTION] Jean-Christophe to send some more details the list regarding
the question : is it possible to put the initrd in the DT directly
(similar to putting some firmware in the DT)? Proposal (JC) is to have 2
device trees, one very minimal with the boot arguments and another with
the HW description.
- [ACTION] Jean-Christophe to put an example of the boot sequence to the
mailing list
Best,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Hi folks
Etherpad: http://etherpad.osuosl.org/arm-boot-architecture-meeting-notes
I have updated this etherpad with the action points and agenda for
today. Grant, since you will be unable to join, I hope you could give an
update for the actions under your name, I have grouped the action points
under your name at the top of the AP list.
Agenda for today:
* Action items review
* Status updates on DT and UEFI work
* Implementation on other bootloader than the ARM one
* HW platform status
* Android + UEFI status
Anything else to add?
(PLEASE NOTE: As usual, I will be using the etherpad to update the wiki
meeting minutes which is your best reference location to check what was
discussed during any of the meetings.)
Cheers!
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Is there already support for UEFI Runtime Services in the kernel? If not is this already planned for Linaro?
UEFI Runtime Services are necessary for exchanging NVRAM values with the UEFI environment. These NVRAM values provide the foundation for UEFI spec'ed functionality ranging from boot entry management to key management for secure boot.
Thanks,
Eugene
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-09-22
Please note the new action points at the bottom of the page. Send your
status updates to the list regarding:
- DT and UEFI work
- Implementation on other bootloader than the ARM one
- HW platform status
In addition there was no time to discuss during the last meeting the
Android + UEFI status. Could someone summarize the status there for
the rest of the list?
Thanks,
*************************************
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris
*************************************
Hey
As discussed again in today's call, I've pushed a git mirror of edk2's
and edk2-fatdriver2's SVN modules to git.linaro.org.
This is temporary in that:
* the whole history of edk2-fatdriver2 was imported, but only the last
revision of edk2 was imported (a full import is running, but that
will take a while)
* git.linaro.org lacks git-svn and has outbound traffic firewalled; I'm
working with IS to resolve this
These can be used right now, with the caveats that the branches might
be rebased or might move to another host; I'm happy to assist if you
need help moving your patches around when that happens.
The repos are:
git://git.linaro.org/mirror/edk2/edk2.gitgit://git.linaro.org/mirror/edk2/edk2-fatdriver2.git
These were created with:
git svn clone -s \
https://edk2-fatdriver2.svn.sourceforge.net/svnroot/edk2-fatdriver2
edk2-fatdriver2
git svn clone -r 12354 -s \
https://edk2-fatdriver2.svn.sourceforge.net/svnroot/edk2
edk2
Would you need any other SVN module mirrored, or if you have
suggestions about a different set of git-svn options, please get in
touch with me.
Cheers
--
Loïc Minier
Hi everyone,
I'd like to get the date and time sorted out for the next two boot
architecture face-to-face meetings. For the next one, I propose
scheduling it as a 1/2 day summit during LinuxCon & ELC-E in Prague,
Oct 26-28th, or possibly the day before in parallel with kernel
summit. ELC-E I think is an excellent venue since there will be
representatives from a large number of ARM vendors in attendance, as
well as core Linux developers. I believe we'll be able to get a
larger cross-section of the ecosystem there than will be attending
LInaro Connect the week after in Orlando. Does anybody have any
issues with that date? Is there a specific day that works best? I
haven't talked with the Linux Foundation folks yet or looked at the
schedule, but I'll try to choose a time that doesn't conflict with
related presentations.
For the meeting after that, there are two options; either at Linaro
Connect Q1.12, February 6-10, in San Diego (?), or I *think* ELC the
week after and also in San Diego. I need confirmation from the LF
though about the scheduling. I'm leaning toward ELC for this meeting
also for the same reasons as above, but it might be a good strategy to
alternate between Linaro and non-Linaro gatherings. Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[sorry if this is the wrong list, please direct me to the right one as needed]
I'm trying to get my head wrapped around FDT to understand how UEFI firmware can produce this (and possibly use it internally) and pass it to the OS.
I've been trying to find the authoritative specification describing DT and FDT. My experience searching resulted in a lot of dead links. Is the spec the ePAPR specification? How does this specification get updated to provide compatibility or enhancements that the current spec does not address like ARM architecture additions?
Also is there a central registry, if any, of strings for vendors or compatible hardware? For example if I have a property 'compatible = "hp,widget123";' who determines whether 'hp' standard for Hewlett-Packard or Henry's Pickles? Along the same lines if there is a standard interface like a "gic" where is the spec/document describing what a "gic" is and how is it updated?
Sorry for the newbie DT questions... I guess I've been spoiled by the UEFI spec providing all the information I've needed in the past in once place. :)
Thanks,
Eugene
Dear Grant Likely,
In the boot architecture meeting held in Linaro connect
Q3, we discussed regarding a separate git repository for vendors supporting
the Uefi boot loader.
I am responsible for the supporting Uefi for samsung platform. Can you
please let me know when the git repository will be available to upstream the
UEFI.
Regards
Girish K S
We're looking into porting Xen to the ARM A15 architecture. In this
context, it's necessary to arrange for the Xen hypervisor to be
entered from the boot loader in an appropriate processor mode.
KVM needs to deal with the same problem, of course. And any future
Linux kernel feature which uses the Secure State does too.
We are currently working with ARM's "Fast Model" of the Cortex A15, a
software emulator. We're using it in the mode where you feed it an
ELF and it loads it into simulated RAM and starts executing at the
ELF entrypoint. It does this in the CPU's defined startup mode, which
is Kernel mode in the Secure state.
It seems that this environment is what the nascent KVM-on-A15
developers [1] are using too. There is modified version of the tiny
boot wrapper (the normal version of which just emulates the proper
calling API for the kernel); it sets up a trampoline security monitor.
We need to define a correct calling convention for the kernel which is
compatible with old systems, but which also allows the booted kernel
(Linux, perhaps KVM-enabled, or indeed a hypervisor like Xen) use of
all the available facilities. The correct approach does seem to be to
have Linux set itself up a trivial trampoline which allows the kernel
to later regain the elevated privilege.
There are a couple of things with the existing KVM ARM approach with
the trivial boot wrapper which need to be fixed, though: firstly,
there should be separate trampolines for hypervisor mode and for
secure state. That allows the two features to be used independently.
Secondly, the trivial trampolines should be part of the kernel proper
and their lifetime should not extend across the bootloader interface.
At first I thought that the best thing to do would be to boot the
kernel in any suitable mode, and have the kernel automatically detect
the starting mode. I started writing code in linux's head.S to do
this. However, detecting whether we are in secure state is very
difficult: it involves deliberately risking an undefined instruction
trap. The code for this was getting rather long and involved.
Also, unconditionally starting a kernel in hypervisor mode seems
rather unfriendly. At the moment we unconditionally start it in the
secure state and indeed in the current setup it seems to run entirely
in secure state. It seems to me that the kernel should mostly run in
non-secure state.
So I propose the following approach:
1. The kernel will advertise via ELF notes what modes it may be
started in. The possible modes will be:
(i) secure monitor mode
(ii) non-secure hypervisor mode
(iii) non-secure kernel mode
2. The bootloader will select the first mode from the three listed
above which is supported by both the processor and the kernel to
be loaded, and transition the processor to that mode. If this
involves dropping out of secure or hypervisor mode, it will put
those modes permanently beyond use.
3. The kernel will examine CPSR to determine which of the three
possibilities above has happened, and:
(a) If started in monitor mode:
* Grant access to everything to non-secure state
* Set the non-secure copies of the various CP15 registers
which don't have a sane value on cpu reset
* Install a trivial monitor vector which unconditionally
copies r0 to MVBAR and returns
* Switch to non-secure Hyp mode (if available) and do (b),
or non-secure Kernel mode (if Hyp mode not supported).
(b) If started in Hyp mode:
* Install a trivial hypervisor vector which unconditionally
copies r0 to HVBAR and returns
(c) Rest of startup.
Questions:
1. What do people think ? If this seems plausible I will prepare
an RFC patch for Linux and the boot-wrapper.git.
2. This cpu startup process must happen very early - before paging
is enabled, in any case, so before RAM is really available.
However, it produces two bits of information: 1. does the
kernel own secure state; 2. does the kernel own hyp mode.
Where should this information be stored ?
3. Is Linux allowed to assume that the secondary CPUs have the
same properties as the boot CPU ? If not, where do I store the
availability of the secure/hyp modes for the secondary cpus ?
Perhaps that ought to be in the device tree.
4. I'm not very familiar with the KVM on ARM code. How much would
have to be changed to existing KVM on ARM to make it conform to
the above scheme ? In particular it would have to not use SMC to
adjust the HVBAR; instead, it would have to take control of HVBAR
once per CPU.
Opinions welcome.
Thanks,
Ian.
[1] http://wiki.ncl.cs.columbia.edu/wiki/KVMARM:Guides:Development_Environment
