[SeaBIOS] [coreboot] UEFI project ideas

[Zoran Stojsavljevic]

Hello Laszlo,

> But claiming that tianocore/edk2 is only good for x86 in its current shape
and form...

Not good enough for various/zillions ARM derivatives, maybe some/lot of
different ARM projects want to be UEFI compatible.

> ...and implying that UEFI on ARM unconditionally needs a lower-level
"shim", are just preposterous.

OK. I got the message. I tried twice. It does not go with the community. I
had some more ideas why Tiano Core needs to be scaled to bare minimum, but
these ideas need different attitude and different (very strong) use cases
to confirm my thoughts.

I rest my slim Tiano Core case here.

Thank you,
Zoran
_______

On Tue, Jun 7, 2016 at 5:35 PM, Laszlo Ersek <lersek at redhat.com> wrote:

> On 06/07/16 16:35, Zoran Stojsavljevic wrote:
> >> Note that you can build seabios as CSM for tianocore already.
> >
> > These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS), while
> > Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and Tiano Core
> > exclude each other (should not be used together -> wrong architecture).
>
> SeaBIOS can be built and used as a CSM with UEFI firmware built from
> tianocore/edk2. The projects themselves are not "opposites".
>
> The resultant firmware binary can boot OSes in UEFI mode or in legacy
> mode. I guess those boot modes can be called opposites.
>
> >> What is the point? You can just run tianocore as coreboot playload.
> >
> > The point is to make minimal Tiano Core (minimum for making FAT32
> > partition/file system on HDD/SDD to create /boot/EFI/ directory, in
> > other words minimal UEFI compliant BIOS), Tiano Core as such is good to
> > be used/run for/on x86 architecture ONLY
>
> This is patently false. Several aarch64 platforms exist that run UEFI
> firmware based more or less directly on tianocore/edk2. In my living
> room I have an APM Mustang that has UEFI firmware, based on tianocore/edk2.
>
> The SBBR spec (Server Base Boot Requirements
> System Software on ARM ® Platforms) mandates UEFI. Of course, not all
> ARM platforms are required to conform to the SBBR, but the SBBR would be
> quite foolish to require a practically unfeasible thing. tianocore/edk2
> is the open source reference implementation of PI (Platform Init) and UEFI.
>
> It's a separate question wheter specific aarch64 platform code lives
> directly within the edk2 tree, or in some external tree (open source or
> proprietary).
>
> > (and side effect is the
> > extended time for booting, since all these DXE drivers must be
> > installed, which will be later mostly replaced/run over with OS drivers,
> > except run time services).
>
> DXE drivers are supposed to drive peripherals only in the exceptional
> case. Most devices that are not integrated in the platform are supposed
> to be driven by UEFI drivers that conform to the UEFI Driver Model.
>
> The point of that driver model is that no compliant driver, when
> initially launched, starts to drive any kind of hardware. Instead, it
> installs only three callbacks (member functions of its driver binding
> protocol instance): supported, start, and stop. The supported callback
> is used as a very quick check by the system to see if a driver supports
> a given piece of hardware. The start and stop functions instruct the
> driver to actually bind (and unbind) the specified piece of hardware.
>
> The calls to the supported and bind functions are initiated by Platform
> BDS (Boot Device Selection). In other words, it is a platform decision
> to automatically bind this or that set of devices. In OVMF and
> ArmVirtPkg (running in QEMU, Xen, and possibly other virtual machines),
> we choose to automatically bind all possible devices, because in virt,
> that's generally the best approach (and it is even necessary for some
> QEMU boot order quirks that I'm not going to go into now).
>
> But, auto-binding all devices is nowhere mandated by the UEFI spec, or
> any other related spec. In fact, on some x86 platforms the vendor seeks
> to speed up the boot by not connecting USB keyboards even.
>
> (And then, if you want to use the USB keyboard before the OS is booted,
> for example for modifying firmware settings, you have to set a
> non-volatile UEFI variable from within the OS, sometimes displayed as
> "change firmware settings" or some such.
>
> Then at the next boot, the firmware will drop you into the setup TUI,
> with the keyboard (and possibly other devices) connected. The user can
> massage firmware settings then; e.g., if the platform vendor wants it
> too, the user may be able to add the USB keyboard to the set of
> auto-connected devices.)
>
> Other schemes exist too. The Platform Init specification (separate from
> the UEFI specification) defines the Boot Mode HOB (hand-off block). The
> HOB-producer phase of the firmware (usually: PEI, Pre-EFI
> Initialization) can produce this HOB, so that later phases of the
> firmware can key off of it. For example, dependent on platform hardware
> support, this HOB can tell the Boot Device Selection phase *not* to
> connect any other devices than the last time around, because the chassis
> has not been opened since. Otherwise, BDS might want to auto-connect
> everything (perhaps the user installed a new SSD, etc).
>
> > As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be used
> > on ARM architectures too, thus making ARM HW platforms also
> > compatible/lookalike as x86 UEFI compliant BIOS.
>
> The UEFI specification already contains AArch32 and AArch64 bindings. It
> is already possible to implement UEFI on ARM platforms, and several
> vendors have. Boot performance, as far as it is affected by the set of
> devices automatically connected, is platform policy.
>
> > In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW platform,
>
> From last September, a blog post from one of my colleagues:
>
> https://marcin.juszkiewicz.com.pl/2015/09/21/aarch64-desktop-day-one/
>
> > having coreboot + minimal Tiano Core + WIN 10 Boot Loader + WIN10 on it
> > (since WIN10 BL does see UEFI compliance, not knowing what is really
> > under the hood). ;-)
>
> For the record, I am definitely not arguing against coreboot, or u-boot,
> or even a stripped down platform firmware built purely from
> tianocore/edk2. Still for the record, I'm also not arguing that people
> should move to UEFI *at all*, unless they have specific reasons.
>
> But claiming that tianocore/edk2 is only good for x86 in its current
> shape and form, and implying that UEFI on ARM unconditionally needs a
> lower-level "shim", are just preposterous.
>
> Laszlo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/seabios/attachments/20160608/94ef3153/attachment-0001.html>