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 <[email protected]> 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 > >
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
