The first Linaro UEFI mini summit took place on 11th-13th December 2012 in Linaro offices in Cambridge (UK).



There is a video from the participants summarizing the experience and results: Youtube hangout video.

Attendees

  • Grant Likely
  • Andrea Gallo
  • Olivier Martin
  • Dan Handley
  • Rony Nandy
  • Ryan Harkin
  • Leif Lindholm

Summary

For three days from Dec 11 to 13 we met at the Linaro offices to discuss how best to develop UEFI on ARM to the point where it can be used in commercial hardware. Specifically we were looking at UEFI through the lens of LEG priorities, but we kept other users in mind too. The goals for this meeting were:

  1. Hammer out a road map for LEG directed development of UEFI,
  2. Establish a maintainership structure for all ARM UEFI activity, and
  3. Identify and solve existing UEFI problems

The following was accomplished during the week:

  • We drafted a new maintainership structure for ARM UEFI work. The new structure should better coordinate all UEFI ARM work, whether it is undertaken by ARM, Linaro, or other developers
  • We identified and solved some existing problems with the UEFI code base
    • Fixed self hosting for Arndale and Versatile Express platforms
    • Fix in progress for boot order issues - Currently UEFI hard codes a MMC card UUID. Need to instead search available media for UEFI boot applications.
    • Similarly, GRUB UEFI needs to retrieve from UEFI the location of the boot device.
    • Enabled the EFI Shell for Arndale.
  • We made a plan to get UEFI testing into LAVA. It’s in the CI loop now, but LAVA requires some engineering time to be able to actually test that UEFI can boot a board.

UEFI Priorities

Critical priorities

  • Grub2 -> Leif

  • PXE -> Reece

  • Net -> Reece

    • ARMv7 for starters then moving to v8 foundation model
    • Easily done on the VE with an ethernet driver from Olivier Martin
    • It is definitely more complex to add network support on the Arndale board, as it relies on a USB Ethernet dongle solution soldered on the mother board. Adding USB Host support and Ethernet over USB inside UEFI may be complex.
  • Serial (serial is assumed present)

other priorities

  • 1) eMMC -> Rony

  • 2) SATA -> Rony

  • 2) GUID partitioning -> Rony (SATA and GUID are strongly related)

  • 3) IPMI -> which features? asking steering committee

  • 4) PCIe / option ROM

USB Support

Optional for debugging to connect keyboard and mouse or other peripherals not available on the development boards: it is mainly needed to enable Ethernet on the Arndale or SATA drives on other platforms.

Which host controller drivers? OHCI UHCI EHCI xHCI (keyboard, etc)

Which SATA and Ethernet dongles?

It may not be worth anyway, as any real ARM server chip will have native Ethernet support without any USB bridge. Possibly a task for the landing teams.

Work areas

  • a) TC2 dropping characters on serial port -> Ryan

  • a) Hyper visor mode promotion -> Grant & Rony

    • on 32bit: propose a change to ARM bindings (needs a proposal)
    • on 64bit: need to confirm it works (can’t be done on 32bit)
  • a) 64-bit support -> tbd

  • a) initial boot sequence -> Leif

    • Samsung magic image in a block of disk - conflict w/ UEFI and kernel partitions (bug with the Arndale board) -> Rony

    • Non Volatile Storage of the UEFI configuration -> tbd

  • a) Support (releases & testing) -> Steven K.

  • a) Maintainership -> Ryan & Steven

  • b) Runtime services -> tbd

  • b) port of SCT to EDK2 -> Steven K.

    • including LAVA integration
  • c) Refactoring code structure -> tbd

  • c) firmware update mechanics
    • Fastboot

Debugger support - ?

Progress Updates from the sprint

Native hosting - done

Arndale board is now in the Linaro UEFI tree: http://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git

Arndale is also part of the CI jobs: https://ci.linaro.org/jenkins/job/uefi/

The binaries generated by CI can be found here: http://snapshots.linaro.org/components/kernel/uefi

Arndale is building and booting when built “native”, ie. you can build the Arndale UEFI binary using an Arndale board or another ARM platform.

Arndale now uses the EFI shell.

Day 1

Intro

Tianocore / EDK2 is available as public releases under SVN:

ARM start from a given version, branches out a private ARM UEFI tree adding ARM specific patches and then once it is stable on ARM Olivier tries to push the patches back into the Tianocore project.

Linaro (Ryan) has set up another branch from the public Tianocore project, not synch’ed with the ARM private one. Both ARM and Linaro are then sending patches to the Tianocore project.

Historically the OMAP Beagle board support is directly hosted in the main Tianocore project, ARM development boards are in the private ARM tree and then pushed into the main Tianocore project.

Samsung Origen, TI Panda and new ARM development platforms are currently hosted in the Linaro git.

Olivier / Ian running the UEFI SCT self Certification Test. There are two versions: public 2.0 and private to UEFI members as 2.3.1.

Linaro is a member, downloaded the code and looked into the license. It does not seem to be any issue with using it or even running SCT binaries inside LAVA. Linaro will review once again internally about the legal terms to publish the results on the Linaro web sites or make the SCT available also to Linaro members.

Boot process

Cold boot

SEC

PEI

DXE

BDS

OS

SEC = secure world

PEI = Pre-UEFI Initialisation

UEFI = DXE+BDS

BeagleBoard, ARM TC2, Origen and Arndale supported from PEI till OS.

MdeModulePkg|Core|PeiCore CpuPein PlatformPein MemoryPein

PeiCore → PEIPhase hardcoded

DXE

There is support for UEFI debug via gdb but that is not currently working for ARM, it has not been a priority either so far as in ARM they all use hw debuggers.

OHCI, UHCI, EHCI or xHCI USB support to be added to DXE too for keyboard and mouse at least.

Need Ethernet support as well for network boot.

LEG members request support for SATA, PCIe and eMMC.

Native hosting is a high priority as well, because currently UEFI does not build natively on ARM and cross-compilation is a must.

BaseTools is a separate project from Tianocore with different synchronisation timing, currently every six months and often breaking. The Tianocore community is already pushing the BaseTools project to release with a more frequent pace.

EDK2

Separate repo

Proposal to keep one single reference ARM platform in the Tianocore and move all other platform support in the Linaro git. Host also non-Linaro members in the Linaro git but do not run any non regression testing, support, fixes, etc. Need to protect value of Linaro members.

There are almost individual files for each Cortex-A5, A7, A9 and A15 CPU and all files are almost identical if not for minor changes here and there and some easily identified different sections. It may be wise to evaluate a possible refactoring towards one single common ARMv7 code base and one for ARMv8 and then reduce the individual CPU files as much as possible if not merging them into the same by CPU ID?

UUID issue

UEFI Device Path

SATA: PciRoot(0) | Pci (1|2) | Sata (2) | HD (uuid) | zImage

BeagleBoard: VerHw (uuid) | SD (1) | HD (uuid) | zImage

Currently the UUID is hard coded in some boards. We need one UUID for the removable devices and then the boot manager (eg GRUB) should have its EFI UUID as a EFI app:

VerHw (uuid) | SD(1) | EFI | BOOTARM.EFI

Currently on ARM platforms the uuid of the EFI partition is broken. For example, some Versatile Express boards use the SD card ID as UUID and when moving from a 4GB to a 8GB card the ID or the boot aligning may change and get broken if not rebuilt in the code itself...

On the BeagleBord there is a patch that searches for zImage in the file system. Samsung Origen and Arndale also use this patch.

For future, the Boot Device Selection component should be redesigned to scan all EFI System Partitions on connected storage devices. Attempts should be made to try to share code with the Intel module, potentially breaking it out into a separate top-level component.

LAVA and SCT

ARM Versatile Express

  • Boot VE w/ UEFI in LAVA (OK)
  • Replace UEFI image from LAVA & boot (OPEN)

  • Test kernel booting (OK)
  • Run SCT from LAVA (OPEN)
  • what happens when it breaks...

Samsung Arndale

  • Boot Arndale w/ UEFI in LAVA (boot w/ UEFI OK, need to put into LAVA)
  • Replace UEFI image from LAVA & boot (need SDMux)

  • Test kernel booting (OPEN)
  • Run SCT from LAVA (OPEN)
  • what happens when it breaks...

Maintainership

EDK2

Current Status:

Trees:

  • UEFI mainline
  • ARM UEFI
    • stable
    • development
  • Linaro UEFI
  • UEFI SCT
  • Base Tools
  • Platform Tree

UEFI trees.png

ARM shall send patches against the latest public Linaro UEFI git and send a pull request. Then they can send also the very same patch against an older release, same patch but different commit number.

The private branches are for NDA work, e.g. done by the Landing Teams on platforms that have not been made public yet.

Important to align on timing, schedule and “merge” windows tentatively every three months. Look at Google repo to manage sub repositories.

After further discussion we decided that we still need a stable development tree for collecting board support which revises the plan described above. Therefore we will also create a uefi-platforms tree which will track mainline (without rebasing) and serve as a collection point for board support. Any platforms supported by Linaro will target the uefi-platform tree, and will be open to any developers who want to participate.

[We don’t want this to be a Linaro-only thing, or even ARM-only. The intent is to have a common tree for all UEFI platform development since nothing like that exists currently.]

uefi-platforms will serve as a common development tree for any code that we want to maintain over the long term, but cannot be pushed to mainline, such as platform support. Changes committed to this tree will not need to be continually rebased as in the uefi-next tree, and developers will be able to use it for cross-platform cleanups (ie. factoring out common code into a utility library)

Since uefi-platform will track mainline we need to be careful not to merge any patches into it that are expected to land in mainline. So, only board support changes will land in the uefi-platforms branch. Bug fixes and new features to mainline will instead be submitted to the main project, and will only show up in uefi-platforms when pulled in from mainline. Since mainline is tracked with subversion, but uefi-platforms will be tracked with git, there is no mechanism to push git commits back up to the mainline svn repository without causing duplicate commits.

The uefi-next [perhaps uefi-platform-next would be better; or uefi-staging] branch will still create a new branch every month to roll up platform support, but instead of having to carry full patch sets of all board support it will be able to use uefi-platforms as a stable base. That way only patches that haven’t yet been accepted into mainline or uefi-platforms need to be carried and rebased.

The revised tree structure will look like this:

UEFI trees 2.png

Workflow

  • Linaro’s regular monthly release happens (at the end of the month)
    • the tree gets tagged and marked as a release
  • Linaro creates release branch for the upcoming month (at the start of the month)
    • Linaro rebases to all the relevant upstreams
    • Linaro creates a new tracking branch for the month
    • Linaro creates a new tracking branch for the Linaro NDA tree for the month
      • rebase NDA topics
  • Every 3 months, ARM updates their tree to the “just released” tag
    • ARM develops for 3 months on this tree
    • When code is ready, ARM sends two pull requests:
      • 1) pull request to latest linaro branch
      • 2) followed by pull request for old branch
    • Some code will be pulled into the public Linaro tree
    • Some code will be pulled into the Linaro NDA tree
    • Branches will be named to reflect public/NDA nature

How does stuff go to mainline?

  • As we are working on, say branch 13.03, any patches from 13.02 that are “real patches”, go upstream, as in, posted to the Tianocore mailing list.
  • Maintainer does the push to Tianocore, not the developer

Mailing lists:

  • “arm-general” and “arm-private” lists
  • patches get posted to the relevant list

Any patches that go onto the trees get posted to the relevant email list. Urgent stuff destined for upstream can be cross posted to the Tianocore lists.

LEG/Events/UEFI_summit_201212 (last modified 2013-01-14 17:13:21)