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