Part of the challenge is finding/defining a good development model for Tianocore: how will support for various boards be maintained? Obviously Linaro will maintain support for all the boards it cares for in a common tree, but it's less clear how this will play with upstream's development model.

What version of the UEFI specification are you focusing this work against?

Maintaining a UEFI tree: who will be the users of this tree and what will they be using it for? You need to have these questions answered and clear otherwise you will not know whether properly validated, released regularly and well documented requirement is satisfied.

Validation: there is a certification suit - SCT. Should we be validating any development against this?

Member Platforms: We should include ARM models in this since this is what we will have in 64-bit for quite a while.

Alignment: What is the requirement to keep code aligned with Tianocore?

I can see a lot of common patterns with we are trying to achieve in the ARM Ltd UEFI team in term of QA (nightly build & testing, testing framework).

As Roger said SCT is the UEFI Self Certification Test. The UEFI SCT covers few cases of your test requirements (actually almost all the test cases expect the Linux loading test cases).
That's why I extended the SCT Test Framework to accept some ARM specific test cases (including some tests for booting Linux and I/O benchmarking). It is still rudimentary because I have not had so much time to spend on it.
I am not sure if I can redistribute this framework - need to check with Legal people if we want to follow this direction.

DHCP and TFTP support already exists in UEFI. What it misses is the hardware support (in your case the UEFI ethernet driver for the Origen board).
FYI, I have a got a Summer Student who is working on writing a UEFI Ethernet driver for ARM Versatile Express. Once completed this driver will be pushed upstream (I would say in the next 2 months).

For the SD/MMC support, I wrote the initial support from scratch. Some Partners have been complaining about the incomplete support (but no one send patches to fix it). Again, I have not got time to work on it. There is a risk this SD/MMC support might be incomplete for you too.

I do not know if this 'card' is the right channel to discuss how Linaro should align itself with the Tianocore development model.
But the ARM UEFI Open Source community does not exist yet. There is no central point to pull a repository that contains UEFI support for all the supported ARM platforms. UEFI projects exist all over the Internet. The only location is the wikipages on Tianocore Sourceforge project where I try to write up-to-date instructions to enable UEFI on some ARM boards.

A question Linaro needs to answer is how far do you want to push your UEFI development? Does Linaro want to provide a basic implementation 'just enough to boot' ? Or does Linaro want to push its development to provide a UEFI compliant firmware with a full driver support (eg: MMC/Ethernet/USB/Display) for all the Linaro's supported boards.
The answer to this question could be a politically correct answer because of the different roles of ARM Partners in the UEFI ecosystem (Silicon Vendor / BIOS Vendor / OEMs / OS Vendor).

Moving to LEG

Hi,
Just a heads up that this card is now PUBLIC; it was kept private before LEG launched, but that's now done!
Cheers,

Proposed Engineering target/platform is "linux-linaro Ubuntu" (for Panda) as well as "linux-linaro Android" (for origen and VE). Those engineering build currently comee with a headless experience that includes kernel development and debugging tools as well as small common test suites included in the images.

"linux-linaro Ubuntu" (for Panda) isn't an option. We don't have an owner to make it work on Panda, even if we build it as part of Linaro Tianocore. We should switch to Origen for linux-linaro Ubuntu engineering build.

I think I made a typo when suggesting "panda" and meant Origen. Anyway, let's reset the platform discussion a bit.

Can the card ownerdrafter please be more specific on the acceptance criteria:

• Linaro Tianocore binaries for member platforms are boot-tested in LAVA on real hardware, under Fast Models for the Versatile Express images and under QEMU for the Origen images

I would like to see this broken up in concrete (priority ordered) platforms for "real hardware" and I would also like to see a confirm that "QEMU for the Origen images" is not a typo...

I personally don't recall where the Origen on QEMU idea came from; this is probably technically possible in QEMU since it has support for Exynos 4210, but in the light of current LAVA support and engineering builds:

• it seems superfluous to do both Fast Models and QEMU based tests in LAVA
• QEMU is probably not well supported in LAVA ATM
• validating on real boards would be useful anyway, but does require something like SDmux

There's a strong advantage in using Fast Models in that it provides advanced features to simulate / check for a lot of hardware behaviors and help validate the firmware, but this isn't spec-ed in this card. I think it would be good to have simple daily builds + boot tests of UEFI on real hardware and Fast Models.

Removing bootstrap as the card with sub-tasks do more than boot-strap.The card with sub-tasks implements all features on UEFI.

Card targeted for 2013.06 as the scope of the card has expanded to include
complete enablement of UEFI on the Arndale and work on multiple core areas
of UEFI.

Carried forward as per the discussion in https://wiki.linaro.org/TSC/2012-12-12 - Back to engineering for more work.

At the request of Anmar, this card should be in drafting and should be resubmitted to LEG-SC for approval so moving it back to drafting.

Regarding "DR4.1 Mechanism for kernel to obtain control over hypervisor mode (via a hypervisor call; UEFI passes control to the kernel in supervisor mode. Hypervisor mode must be ‘parked’ in a safe state before booting OS)"

The DR is OK but the text in brackets is not an accurate description of the mechanism. UEFI passes control to the kernel in hypervisor mode. To achieve this, the UEFI kernel loader calls a firmware interface to escalate from supervisor to hypervisor mode. The firmware interface is currently an SMC but that detail should not be specified in the DR.