BDS technique for launching LinuxBoot

[Trammell Hudson]

I think the technique that we've been using for launching the LinuxBoot
kernel by trying to masquarade as BDS is not the right approach. The
two main problems are that the CONFIG_EFI_STUB wants to make an EFI
application, not a DXE driver, and that there other other things that
need to run prior to the kernel on many mainboards.

On the r630 the PEI phase sets up enough stuff so that we can jump
pretty much straight into bzImage from DxeCore. But on the s2600
(and from what it sounds like, the Winterfell nodes, too), there are
other DXE drivers that have to setup up stuff.

So let's revisit how BdsDxe is supposed to behave --

It is executed by DxeCore fairly early in the DXE phase, but
BdsInitialize() only registers the BDS protocol and returns to the
dispatcher. DxeCore continues to load all the other DXE drivers and
execute them until it runs out of work, then it checks to see if certain
required ones are present, and if so it calls the one method in the BDS
protocol to jump back into BdsEntry().

(Note that this is a problem with the Linux kernel being an EFI
application. All of its memory will be memset(0xAF) after it returns
the first time, leading to a strange crash when DxeCore tries to
jump back into it)

BdsEntry() tries to figure out what additional drivers are necessary
and asks most of them to connect to their devices so that it can build
a proper device tree. This is important for filling in the ACPI tables.
On the s2600 it also triggers loading the chipset specific drivers.

To figure out what the next stage is, BdsDxe looks at the Boot0000
and Recovery0000 nvram variables to get the device paths for the
next executables. These can either be on disk or in firmware
volumes.

Finally BdsDxe will issue a "ready to boot" event, which will cause some
of the DXE drivers to return their hardware to a clean state. It
then jumps into the next executable.

I've configured it to jump to the Linux kernel (stored in firmware)
and it almost works. Something is messed up with the serial ports;
they are fine when the same kernel is invoked from the UEFI shell,
and I spent most of today trying unsuccessfuly to figure out WTF.

Ideally we don't need BdsDxe -- it is a large chunk of (open source)
code that is unnecessary in the LinuxBoot world -- so I've also worked
on fixing up the kernel's EFI stub to support acting as a proper BDS.
It works, but there is still the serial port problem.

--
Trammell

[Ron Minnich]

I think we go with the open source BdsDxe for now and your really good approach for now!

thanks

ron

--
You received this message because you are subscribed to the Google Groups "linuxboot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linuxboot+...@googlegroups.com.
To post to this group, send email to linu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/20171201014659.GY20002%40chishio.swcp.com.
For more options, visit https://groups.google.com/d/optout.

[Trammell Hudson]

I just realized that I committed the cardinal sin that I've been railing
against UEFI for -- I never spelled out some of the acronyms...

BDS is "Boot Device Selector" and is one of the last phases of DXE
prior to launching the boot loader.

Digging through BdsDxe in the s2600wf recovery image I find that it has
far more code than the edk2 version. Strings indicate that it sets up
compatibility mode BIOS, the TPM physical presence, the STM (for
controlling VM access to SMM), TXT, VTD, etc, etc, etc. It is also
responsible for launching the setup application (LightUiApp.efi?).

That explains why my attempt to replace BdsDxe might not have worked...
(and that's also quite a few new acronyms to add to the glossary)

--
Trammell

> To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/CAPAv03Pzppp%3D1qAmVePVEYcoNvFYDeg_ih1adDDcHAkesMMZRA%40mail.gmail.com.

[ron minnich]

This does not surprise. Your BdsDxe seems to have lots of junk in it that, at least according to UEFI docs, should be in separate Dxe's that get run before Bds. 

So why would this happen? 

The following reasons, all of which I've seen, might apply, in whole or in part.

1. The people who did the S2600 port were in a hurry and just jammed whatever they had to in Bds to get it to work

1.5 ... and may not even have been Intel employees

1.6 ... and/or may have been 12 timezones away from the UEFI group

1.7 ... and hated the build system every bit as much as we do

1.8 ... and the time to build UEFI may have been slowing them down too much, as opposed to just building BdsDxe

2. ... and they did not really understand UEFI anyway

3. ... and strongly dislike what they do understand (no shock there)

4. ... and had they followed the standard way of doing things, with lots of little DXEs for each thing, not in the Bds, it would have been even slower to boot

4. ... from what I've seen the UEFI group tends to throw the canonical UEFI over the transom to the ODMs. ODMs understand UEFI even less than most of intel and, critically, probably struggle to get answers on doing UEFI correctly. (which is one reason, I bet, for all those SMM callout exploits).

So, yeah, I'm not shocked that your BdsDxe is such a grab bag of junk not seen in EDKII. The motto of EDKII should really be " ... strongly resembles the standard, not any real world hardware ..." because it sure doesn't match reality of real hardware. Too bad. As awful as UEFI is, were the ODMs/Intel to actually follow the rules, the Bds we see might actually be just doing Bds, not platform bringup, simplifying our life. 

This may explain the big difference we're seeing with winterfell vs. your intel board: just where things get done may be very different on the two platforms. Since AMI probably wants their AMITSE to work on almost anything, they may not lock as much UEFI junk into that stage as Intel did your on s2600. 

Did you try linux in place of LightUiApp? In your case, LightUiApp might be the equivalent of AMITSE on winterfell?

ron

To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/20171201200655.GA31543%40chishio.swcp.com.