I am new to UEFI and trying to understand working of UEFI on ARM platform.
On building UEFI, there are different binaries generated for each phase and
also for drivers
eg: platformSec.efi, platformBds.efi and UsbDxe.efi,etc
Q1. Is UEFI flashed as single binary i.e., PlatformPkg.fd or different
efi's?
Q1. As the code is in ROM (flash), I understand that it must be copied to
RAM for execution.
Will complete UEFI be copied to RAM or some phase or section wise?
Q3. How does operating sysetm invoke the UEFI Runtime services?
Q4. I read in one of the internet link that other than Timer, there are no
hardware interrupts.
Without hardware interrupt how will the USB kind of device be
recognized?
Kindly clarify my doubts to help me in understanding UEFI better. Thanks in
advance.
Regards,
Asha R
Hi Guys ,
I am working on a samsung sp5v310 development kit.
I wanted to read a peripheral register (battery charger) in u-boot.
This device is interfaced on i2c0. I am working with the u-boot in
git://git.linaro.org/boot/u-boot-linaro-stable.git
I wanted to do i2c_read in the code, but as i understand the i2c
support is not there in u-boot for s5pv310 SOCs. Please confirm, if this
is correct or i am wrong.
If there is support to do i2c operations on s5pv310 SOCs, please point
me to the right file, where i can find i2c configurations for s5pv310 SOCs.
thanks,
- Avinash
PS:
1. There are no i2c macros in include/configs/smdkv310.h.
2. After adding,below macros to enable i2c support for smdkv310,
/* I1C */
#define CONFIG_HARD_I2C 1
#define CONFIG_SYS_I2C_SPEED 100000
#define CONFIG_SYS_I2C_SLAVE 1
#define CONFIG_SYS_I2C_BUS 0
#define CONFIG_SYS_I2C_BUS_SELECT 1
#define CONFIG_I2C_MULTI_BUS 1
i get below error:
/media/data/avinash/c.labs/
git.clones/bootloader/uboot/arch/arm/lib/board.c:189: undefined reference
to `i2c_init'
common/libcommon.o: In function `stdio_init':
/media/data/avinash/c.labs/git.clones/bootloader/uboot/common/stdio.c:215:
undefined reference to `i2c_init'
And there are no i2c related support inside the u-boot for samsung smdkv310.
avinash@avinash-desktop:/media/data/avinash/c.labs/git.clones/bootloader-new/uboot$
grep -inlr 'v310' . > v310.files.txt
avinash@avinash-desktop:/media/data/avinash/c.labs/git.clones/bootloader-new/uboot$
cat v310.files.txt | xargs grep -inr 'i2c_init'
Binary file ./uboot.PS matches
avinash@avinash-desktop:/media/data/avinash/c.labs/git.clones/bootloader-new/uboot$
Update: Linaro has signed the paperwork, and as soon as everything is
resolved, I will be joining the ARM bindings sub-team
> - [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
Kristen Eisenberg
Billige Flüge
Marketing GmbH
Emanuelstr. 3,
10317 Berlin
Deutschland
Telefon: +49 (33)
5310967
Email:
utebachmeier at
gmail.com
Site:
http://flug.airego.de
- Billige Flüge vergleichen
Hi all,
I have just created a page on the Tianocore wikipage to explain the steps to
build EDK2 for the Samsung Origen low cost development board:
https://sourceforge.net/apps/mediawiki/tianocore/index.php?title=SamsungPlat
formPkg
These instructions are based on the Samsung Origen EDK2 support written by
Girish K S (Samsung / Linaro) and target the Linaro Linux 'distribution'
(Linux kernel + file system provided by Linaro).
Please find the attached patches to fix the current head of the Samsung
Origen EDK2 port (ed456b2d64f3 (22/11/2011)).
Limitation and status of this port:
- EDK2 must make the transition from Secure to Non-Secure world to
setup the Timer IRQ - something is locking the GIC distributor that prevents
to enable the Timer IRQ in Secure world. I have not investigated this issue.
- Cannot start the Linaro's kernel - I have not investigated this
issue yet.
- Display support (not tested).
- Can start a EFI Shell or an EFI application.
Kind Regards,
Olivier
Hello
yes that is correct, I have now cancelled the meeting and sent you all a notification.
I was talking to Grant yesterday about how to proceed with the meeting, and there will be more information communicated once we have finished Connect. In short, the meetings should resume once we have enough progress in the porting of grub for uboot at least.
In the meantime we could use the mailing list for any comments or news.
Are there any serious objections on this? I fear that without progress on the code side the meetings would merely discuss what we have read, we can do that on the mailing list.
Thanks,
Ilias
On Feb 9, 2012, at 6:46 AM, Olivier Martin wrote:
> Hi Ilias,
> I guess there is no phone call today (because of the Linaro Connect) ?
> Cheers,
> Olivier
>
>
> -----Original Message-----
> From: boot-architecture-bounces(a)lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Ilias Biris
> Sent: 03 February 2012 08:11
> To: boot-architecture(a)lists.linaro.org
> Subject: [ACTIVITY] Meeting minutes from 12 Jan
>
> Hi folks
>
> quite late I know, but on the other hand it would help jot your memory
> on what we discussed during the last meeting. Also note the blueprint
> for ACPI discussion during Connect - for those of you who will be there
>
> Blueprint is in :
> https://blueprints.launchpad.net/linaro/+spec/linaro-general-q112-acpi-disc…
>
>
> The meeting minutes are in:
> https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2012-01-12
>
> 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
>
> _______________________________________________
> boot-architecture mailing list
> boot-architecture(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/boot-architecture
>
>
>
Hi folks
quite late I know, but on the other hand it would help jot your memory
on what we discussed during the last meeting. Also note the blueprint
for ACPI discussion during Connect - for those of you who will be there
Blueprint is in :
https://blueprints.launchpad.net/linaro/+spec/linaro-general-q112-acpi-disc…
The meeting minutes are in:
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2012-01-12
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
Hello folks
with apologies for sending this late here are the meeting notes from the
latest boot architecture meeting:
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-12-08
There was only 1 action recorded and that is
ACTION: Jean-Christophe to look at boot-cycle from the DT side
Also JC asked what would be the wishlist in terms of HW and IO for a
reference platform. Please send your ideas straight to the list or if
you prefer to JC directly.
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
Hi,
I'm wondering if folks in the boot architecture team have any input on this?
~Deepak
---------- Forwarded message ----------
From: Venkatraman S <venkat(a)linaro.org>
Date: 25 November 2011 04:19
Subject: eMMC4.5 Boot partition support -expectations
To: Deepak Saxena <dsaxena(a)linaro.org>, Saugata Das <saugata.das(a)linaro.org>
Cc: Arnd Bergmann <arnd.bergmann(a)linaro.org>, Yejin.moon(a)samsung.com
Hi Deepak, all,
According to this cycle's eMMC4.5 requirements in [1], there is no
need to provide any specific support in the boot loader for Boot
partition, right ?
As of 3.1, the Kernel recognizes the boot partitions and exposes
them as read-only. Any user space tool can update the data in the boot
partition by overriding the sysfs entry, and writing the appropriate
data.
Let me know if there are any specific expectations on this.
Thanks and regards,
Venkat.
[1] https://linaro-public.papyrs.com/public/4086/KWG2011-EMMC-4.5-SUPPORT/
Hi folks
After discussing with Grant, I have sent new invitations out - the new
meeting is set to happen once a month starting Thursday 08 December. The
timeslot remains the same.
I hope this arrangement is good for you. Please let me know if you have any
issue with the time.
Best regards,
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
On 17 Nov 2011 11:20, "Jean-Christophe PLAGNIOL-VILLARD" <
plagnioj(a)jcrosoft.com> wrote:
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-20
Please take note on the following:
- there could be no call this week. Grant will confirm (as many are on
ELCE this week)
- Jean Christophe was to send to the list a proposal on what could be
the reference platforms for the work related to server - in the meeting
Jean Christophe mentioned ST and Marvel, but it would be best to have
specific reference to any boards
- Other actions are in the link:
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-20#action-poin…
Best regards
--
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
Hey
These are the minutes for the meeting we had today at
ELC-Europe/LinuxCon Europe. Please fix/amend as you see fit!
Cheers,
== Attendees ==
* Sascha Hauer
* Olof Johansson
* Grant Likely
* Jean-Christophe
* Deepak Saxena
* Nicolas Pitre
* Loïc Minier
* Michael Frysinger
== Random topics/agenda ==
* Barebox
* Support in Linaro tools
* Runtime configuration via DeviceTree
* Boot menu
* U-Boot
* zload on ARM
* runtime configuration via DeviceTree
* UEFI
* Tianocore
* Support in Linaro tools
* PXE implementation
* Intel builds
* pxelinux compatibility app
* U-Boot (Barebox?) UEFI compatibility app
* grub-efi porting
* ACPI
* Intel opensource implementation
* ARM support in linux
* Compiler
* Specs
* entry point protocol (Jean-Christophe)
* kernel image format (Jean-Christophe)
* secure boot (Grant)
== Minutes ==
* Recent decision to focus on server rather than doing boot architecture at large
* Constraints of supporting older OS on newer hardware
* Calxeda focusing entirely on server, with A9
* Apple and Windows 8 expecting the same boot interface on all supported hardware
* Apple not interesting case because vertically integrated
* Short-term + long-term approach
* Short-term: U-Boot
* Long-term: Tianocore
* Short-term pain points
* uImage solved: use -1 as load address to use the default address
* userspace should have nothing board specific, but should pass:
* kernel
* initrd
* dtb -- actually that's board specific :-/
* ship all device trees
* install one as the firmware during install
* if we need to update the dt, install the one corresponding to the currently used device-tree compatible property (from /proc)
* Replacing the DTB in the firmware might break the signature
* Eventually want NOT to load DTB from userspace but only rely on the firmware one; DTB updates are provided via firmware upgrades
* Can't demonstrate this easily with boards without flash in Linaro, but that's ok
* u-boot would gain an eliloboot command which reads an elilo config file and runs it
* Could have a GRUB backend for U-Boot before we get the EFI one
* Should we target a single config file format for all bootloaders?
* Too hard and so many concrete short-terms problems to solve
* Can boot with GPT/EFI conventions on things which look like disks (e.g. SD/MMC)
* Doesn't support MTD
* GRUB ARM port
* Direct port or on top of U-Boot
* Need block access and console access
* Probably larger work to port GRUB to U-Boot/Barebox than parsing grub.cfg from U-Boot
* But would miss LVM/RAID/filesystems from grub
* Why isn't GRUB logic in a library?
* Wouldn't help anyway as U-Boot is GPLv2 only and GRUB is v3+
* U-Boot ABI is stable, Barebox has a POSIX ABI
* Plan:
* Add grubcfg command to parse grub.cfg
* Port GRUB to Barebox or U-Boot
* Move to grub-efi
* ACPI
* Is it going to open up?
* How does Tianocore support ACPI today? What would it take to support on ARM
* Enabling as many ACPI related pieces on ARM: ACPI BIOS, compiler, linux implementation
--
Loïc Minier
Hi all,
For those of you attending ELC-E, I've got the "Quadrant" room booked
from 1:30-5:00pm on Thursday Oct 27, 2011 for a face to face boot
architecture meeting.
g.
Hello
Two questions to rebound on last meeting minutes and "Working with ACPI and UEFI on ARM" message from Grant:
- Since both ACPI and UEFI topics are joined in those recent discussions, does that mean that you don't want to consider one of them (UEFI) without the other one (ACPI) now ? There was some begin of discussion earlier this year and recent activities on UEFI so I am wondering if this will go on as this or be necessarily combined with ACPI.
- About UEFI implementation: Tianocore (http://sourceforge.net/projects/tianocore/) seems to be the de facto open source UEFI implementation, as far as I understand. This one is delivered under BSD license (2-clause version, right ?) that would make many OEM happy, compare to the GPL license (U-Boot / Barebox) that they usually don't like for their bootloader. Can you confirm this and/or make it clear in the list started by Grant above ?
Best regards,
Gérald
Hi folks
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-13 has the
meeting minutes from yesterday's discussion. I have summarised below the
highlights and Actions recorded in the etherpad.
-----
= Highlights =
We discussed the short term pain points, which should be possible to
address via some engineering work - priorities were discussed here is
where the discussion was left at the end of the meeting
RANKING
- Rob's top two: 1) zImage support in u-boot. 2) How does the OS change
which kernel gets booted.
- Olivier: 1) Get grub working with u-boot - get booting from a GPT
partition 2) zImage update process 3) GPT support
- Jean-Christophe: 1) Investigate and begin using FIT image format 2)
multiplatform kernel images 3) signed images - kernel, initrd, dtb
- Grant: 1) grub or grub config file on u-boot 2) Start using GPT support
-----
= Actions from the meeting =
- [CARRIEDOVER] Grant to followup the status of Linaro UEFI membership
- INPROGRESS
- [CARRIEDOVER] Grant: Interact with Microsoft on ARM boot interface -
there is some discussion more to say say by around mid October
- [CARRIEDOVER] Grant to draft a position on secure boot, from the
Linaro perspective, which can be reviewed by Linaro TSC: TODO
- [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 27) ?) - 1/2 day in the afternoon.
TODO: send out public announcement.
+ 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.
- [CARRIEDOVER] Jean-Christophe to send a RFC to the list regarding the
kernel image format and entry protocol: INPROGRESS - target this weekend.
+ Related to these previous APs:
o [CARRIEDOVER] Jean Christophe: Investigate entry point protocol -
related to multi-image support. Proposal needed.
o [CARRIEDOVER] Jean-Christophe: Investigate kernel image format -
Target Linaro Connect. The proposal here is similar to the one handling
the previous action point (entry point protocol).
- [CARRIEDOVER] 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. Issue: it is a requirement to be able
to sign images passed in to the kernel; including the device tree. That
makes it forbidden to modify the boot loader. - must support static DT.
- TODO: sent proposal for how to sign device tree images.
- [ACTION] Jean-Christophe to put an example of the boot sequence to
the mailing list - Under review - waiting for approval to release.
- [ACTION] Grant to post request for feedback for ACPI and UEFI - wants
to have this checked from ACPI pov
Best regards,
--
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 everyone,
We Linux developers seem to have a bit of a love-hate relationship
with ACPI. On the plus side it provides the "standard platform" that
we rely on to support the huge amount of hardware in the x86 ecosystem
It is also the source of much pain due to firmware and DSDT tables
that are either buggy or perform poorly. In the embedded space we've
avoided ACPI entirely by standardizing on the Flattened Device Tree
for hardware discovery. However there are some market segments and use
cases where FDT doesn't solve the problems faced by OEMs, particularly
when the hardware needs to support existing, unmodified OS images.
Some OEMs are looking to implement ACPI on ARM since it is a solution
they are already familiar with. It's becoming clear to me that in the
near future, independent of whether or not we as the Linux community
like it, we are going to start seeing ARM systems that are based on
UEFI and ACPI.
But, to quote h2g2, "Don't Panic." While there are many reasons as to
why ACPI has been the source of pain, at least one of those factors is
under our control. Historically, we as the Linux community have not
been very good at participating or providing leadership as to what the
future of the commodity hardware industry should look like, and the
result is decisions that don't reflect our best interest, sheerly by
omission. (There is an argument that standards setting hasn't been
inclusive either, but I have reason to hope that is neither permanent
nor insurmountable).
So, given that we know that ARM ACPI machines will exist, and given
that we still want to support Linux on these machines, I think it is
absolutely appropriate to start getting involved with both the ACPI
and UEFI standardization processes. I (on behalf of Linaro) will soon
be joining the UEFI ARM Binding Sub Team (ABST), and we already have
representatives from Canonical and Red Hat involved there. I'm also
investigating the possibility of getting involved when the post-ACPI 5
process begins, probably sometime early next year.
In the mean time, I want to start getting prepared by collecting
feedback about the state of ACPI and UEFI now, and what changes we
need to have for ACPI and UEFI to meet our needs in the Linux
ecosystem. Reply to this email with your comments, and I'll start
collating a list that I can discuss with the ACPI and UEFI folks.
For your reference, the current versions of the ACPI and UEFI specs
can be found here[1][2]. The ACPI spec is freely downloadable, but
the UEFI spec requires a click-through license to read.
[1] http://www.acpi.info/DOWNLOADS/ACPIspec40a.pdf
[2] http://www.uefi.org/specs/
I'll kick things off with a few items from my personal list. This list
will grow as I collect feedback and input from all of you.
1) Open Process - Currently the ACPI definition process is entirely
confidential between the 5 APCI member companies (Microsoft, Intel,
Toshiba, HP and Phoenix Technologies), and it remains so until the
Final Draft is proposed to "Contributing Adopters" which is very late
in the process. The current version of the spec is v4.0a[1]. ACPI 5
is currently under final review and will be released sometime late
2011, early 2012.
For us to participate in the ACPI definition, we need to have an open
processes so that open source Linux engineers can participate.
2) Improvements to compliance testing - Several Linux developers have
been doing good work on BIOS/UEFI/ACPI testing and are able to
identify many common bugs in firmware. This is of course valueable to
the Linux ecosystem, but since it is discovering firmware bugs, it is
most likely of high value to all HW and OS vendors. I would like to
see much of the test work that we're currently doing to start
filtering back into the tools that are routinely used by HW vendors as
part of QA testing. Maybe even pushing for an industry wide suite of
compliance tests.
3) Better rules (and testing) on SMM interrupts (or the ARM
equivalent). HW vendors are using SMM to work around hardware bugs or
perform system management tasks independently and transparently from
the operating system. However, poorly implemented firmware will take
the processor away from the OS for unbounded periods of time which is
a deal breaker for any kind of real-time response in the OS. For ARM
systems I would like to see an alternative to compete interruption of
the OS when firmware needs to perform system management tasks.
Cheers,
g.
Hi
Just to confirm what Jean-Christophe said on today's meeting: U-Boot
has disk/part_efi.c added in September 2008:
Add support for CONFIG_EFI_PARTITION (GUID Partition Table)
so it's indeed GPT support.
It's currently being turned on for two NVIDIA Tegra2 boards: Harmony
and Seaboard.
(I didn't try it out.)
One open question we had from last week's meeting is whether we can
have backwards-compatible entries for e.g. boot ROMs in current SoCs as
to use GPT for UEFI compatibility but with the relevant "PC" partitions
entries as to allow booting.
Cheers,
--
Loïc Minier
Meeting minutes are in:
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-06
In particular note
- the decision for the focus in a two-pronged approach for short and
long term goals ( see
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-06#Minutes
for details, below is just a summary)
+ SHORT TERM pain points are summarized below - the list needs
priorization and to be shown to the TSC so that suitable resources are
assigned to do the work
- support for Uboot
- kernel update process/method
- making every uboot behave the same way
- how does uboot decide what kernel to load - does not have to be
uboot specific fix, could be a script for uboot
- single zImage able to boot on multiple SOCs
- support for grub on uboot.
- Port tianocore as a uboot app
- uboot should understand which is the active partition - or should
have a mechanism to tell the user which is the active partition
+ LONG TERM goals (strategic and design issues): there is a vendors'
interest in standards process - which the Linux community has not been
extremely involved with in the past. So we should work with the
standards - get familiar with the existing standards
For next week - ALL should download and get familiar with ACPI/UEFI
specs (and open firmware ones - if not already familiar with those).
Let me know if there is something missing or wrong in the minutes, I can
update as indicated.
Best regards,
--
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 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
*************************************