The Linux kernel patch for CONFIG_EFI_BDS deliberately doesn't lock SMM so that it is possible for the boot kernel to install custom SMM modules. However, there needs to be a utility that will do this.

The current code of the Makefile git clone the edk2 repo.
Why not having a submodule to point a particular release ?
If you agree, I can offer the PR.

When we kexec into the OS installed on an nvme card the system startup hangs at some point if we have SMP enabled (SMP soft lockup detected).

With nosmp we make it all the way into user space and slowly make progress, but at exactly 30 seconds intervals:

[2018-03-22 19:56:51.068] [  120.689536] systemd[1]: Set hostname to <ubuntu>.
[2018-03-22 19:56:51.137] [  120.758112] systemd[1]: Reached target User and Group Name Lookups.
[2018-03-22 19:57:21.147] [  150.770964] systemd[1]: Started Forward Password Requests to Wall Directory Watch
[2018-03-22 19:57:51.159] [  180.784612] systemd[1]: Created slice User and Session Slice.
[2018-03-22 19:58:21.167] [  210.794080] systemd[1]: Reached target Encrypted Volumes.
[2018-03-22 19:58:51.176] [  240.803785] systemd[1]: Listening on Journal Audit Socket.
[2018-03-22 19:59:21.184] [  270.813379] systemd[1]: Created slice System Slice.
[2018-03-22 19:59:51.192] [  300.822980] systemd[1]: Created slice system-serial\x2dgetty.slice.
[2018-03-22 20:00:21.204] [  330.836524] systemd[1]: Listening on Journal Socket.
[2018-03-22 20:00:51.212] [  360.846660] systemd[1]: Mounting Debug File System...
[2018-03-22 20:01:21.221] [  390.856353] systemd[1]: Starting Create list of required static device nodes for the current kernel...

Using the HowTo instructions from the front page:

mkdir -p dev
cd dev
mkdir -p linuxboot-result
test -d linuxboot || git clone https://github.com/linuxboot/linuxboot
cd linuxboot
make \
	     BOARD=qemu \
	     KERNEL=~/dev/linuxboot-result/bzImage \
	     INITRD=~/dev/linuxboot-result/initrd.cpio.xz \
	     config
make

Is there a recommended build OS?
I'm getting errors building on several versions:

Centos6.10

Build stops at:

$ make
( cd edk2/OvmfPkg ; ./build.sh )
Initializing workspace
linuxboot/edk2/BaseTools
Loading previous configuration from linuxboot/edk2/Conf/BuildEnv.sh
WORKSPACE: linuxboot/edk2
EDK_TOOLS_PATH: linuxboot/edk2/BaseTools
CONF_PATH: linuxboot/edk2/Conf
using prebuilt tools
Running edk2 build for OvmfPkgX64
Traceback (most recent call last):
  File "linuxboot/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 34, in <module>
    from Common import Misc as Utils
  File "linuxboot/edk2/BaseTools/Source/Python/Common/Misc.py", line 2183
    storeidset = {storeid for storeid, storename in self.DefaultStores.values() if storename in DefaultSIdList}
                            ^
SyntaxError: invalid syntax
make: *** [boards/qemu/qemu.rom] Error 1

Centos7.8.2003

First I got:

cp edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd boards/qemu/qemu.rom
cp: cannot stat ‘edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd’: No such file or directory
make: *** [boards/qemu/qemu.rom] Error 1 

Fixed with a symlink:
edk2/Build/OvmfX64/DEBUG_GCC5 -> DEBUG_GCC48/

now I get:

$ make
make: *** No rule to make target `~/dev/linuxboot-result/bzImage', needed by `build/qemu/Linux.ffs'.  Stop.

Centos8.2.2004 & Ubuntu 20.04 & Fedora28

make[3]: Entering directory 'linuxboot/edk2/BaseTools/Source/C/Common'
gcc  -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-unused-result -nostdlib -c -g  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/  -O2 EfiUtilityMsgs.c -o EfiUtilityMsgs.o
EfiUtilityMsgs.c: In function ‘PrintMessage’:
EfiUtilityMsgs.c:484:9: error: ‘strncat’ output may be truncated copying between 0 and 511 bytes from a string of length 511 [-Werror=stringop-truncation]
         strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EfiUtilityMsgs.c:469:9: error: ‘strncat’ output may be truncated copying between 0 and 511 bytes from a string of length 511 [-Werror=stringop-truncation]
         strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EfiUtilityMsgs.c:511:5: error: ‘strncat’ output may be truncated copying between 0 and 511 bytes from a string of length 511 [-Werror=stringop-truncation]
     strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[3]: *** [../Makefiles/footer.makefile:27: EfiUtilityMsgs.o] Error 1
make[3]: Leaving directory 'linuxboot/edk2/BaseTools/Source/C/Common'
make[2]: *** [GNUmakefile:85: Common] Error 2
make[2]: Leaving directory 'linuxboot/edk2/BaseTools/Source/C'
make[1]: *** [GNUmakefile:25: Source/C] Error 2
make[1]: Leaving directory 'linuxboot/edk2/BaseTools'
make: *** [boards/qemu/Makefile.board:62: boards/qemu/qemu.rom] Error 2

Ubuntu18.04

GNUmakefile:314: recipe for target '~/dev/linuxboot/edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin' failed
make[1]: Leaving directory '~/dev/linuxboot/edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector'
make[1]: *** [~/dev/linuxboot/edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin] Error 127


build.py...
 : error 7000: Failed to execute command
        make tbuild [~/dev/linuxboot/edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector]


build.py...
 : error F002: Failed to build module
        ~/dev/linuxboot/edk2/OvmfPkg/ResetVector/ResetVector.inf [X64, GCC5, DEBUG]

- Failed -
Build end time: 19:50:24, Jul.23 2020
Build total time: 00:00:06

boards/qemu/Makefile.board:62: recipe for target 'boards/qemu/qemu.rom' failed
make: *** [boards/qemu/qemu.rom] Error 1

Thanks.

Transfering control to BDS 7B44408
Entry Point 7B42280 (7B42280)

LinuxBoot: BDS time has arrived
LinuxBoot: connect pci root brdiges
efi_visit_handles 2F707EBB
status=0000000E
LinuxBoot: signal root bridges connected
OnRootBridgesConnected: root bridges have been connected, installing ACPI tables
Select Item: 0x19
Select Item: 0x27
Select Item: 0x19
Select Item: 0x25
Select Item: 0x19
Select Item: 0x29
Select Item: 0x19
Select Item: 0x26
InstallQemuFwCfgTables: installed 7 tables
LinuxBoot: signal dxe end
LinuxBoot: signal smm ready to lock
InstallProtocolInterface: 60FF8964-E906-41D0-AFED-F241E974E08E 0
efi_visit_handles 00000000
handle_count=00000028
LinuxBoot: bds_main dispatch
LinuxBoot: signal ready to boot
LinuxBoot: Looking for bzimage
LinuxBoot: FFS buffer=00000000072B0018
LinuxBoot: FFS length=00127490
LinuxBoot: unable to load bzImage image
ASSERT [DxeCore] /home/xcc/linuxboot-main/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c(607): ((BOOLEAN)(0==1))
!!!! X64 Exception Type - 03(#BP - Breakpoint) CPU Apic ID - 00000000 !!!!
RIP - 0000000007F3FB6F, CS - 0000000000000018, RFLAGS - 0000000000000002
RAX - 0000000000000070, RCX - 0000000007F2BCA0, RDX - 00000000000003F8
RBX - 0000000007F2BCA0, RSP - 0000000007F2BC60, RBP - 0000000007F50260
RSI - 0000000007F4FBA8, RDI - 0000000007991218
R8 - 0000000000000001, R9 - 0000000000000000, R10 - 0000000000000000
R11 - 0000000000000000, R12 - 0000000007F50260, R13 - 0000000000000000
R14 - 0000000007A1AF98, R15 - 0000000003FDFC01
DS - 0000000000000008, ES - 0000000000000008, FS - 0000000000000008
GS - 0000000000000008, SS - 0000000000000008
CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 00000000FFFFFF80 000000000000001F, LDTR - 0000000000000000
IDTR - 0000000003FDDD80 000000000000021F, TR - 0000000000000000
FXSAVE_STATE - 0000000007F2B8C0
!!!! Find image based on IP(0x7F3FB6F) /home/xcc/linuxboot-main/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll (ImageBase=0000000007F2C000, EntryPoint=0000000007F2C240) !!!!

The TSC clock is not longer available after kexec. It looks like it needs to be reset. This bug doesn't seems to be specific to linuxboot, but is inducing issues with KVM later on.

This can be check with cat /sys/devices/system/clocksource/clocksource0/available_clocksource
By the way, linuxboot kernel detect properly TSC on Xeon cpus.

If jumper J43 is moved to pins 2-3 for a few seconds the CMOS NVRAM will be cleared. On reboot the AMI DxeCore will halt the system with post code 0x0d during the call to ExitBootServices(), possibly indicating a segfault.

Reflashing with the stock AMI BIOS and rebooting will re-write the contents of the NVRAM and allow LinuxBoot to be reflashed. The contents of the CMOS NVRAM were the same after two repetitions of this process:

# xxd -g4 /sys/devices/pnp0/00\:04/nvram
00000000: 00000001 d220827f 02ffff02 43548a1b  ..... ......CT..
00000010: 0013e641 82920012 17004306 0ca94202  ...A......C...B.
00000020: 08ebffff 20040cf0 07020000 00000000  .... ...........
00000030: 00000000 01100128 02028180 01000041  .......(.......A
00000040: 01c86040 d1400000 02200480 04200000  ..`@.@... ... ..
00000050: 0000a420 c0002008 82020000 9400424a  ... .. .......BJ
00000060: 9200a060 08402202 0010010a 80502080  ...`.@"......P .
00000070: 0200                                 ..

Phenomenon

This happened in the implementation of LinuxBoot on QEMU-ARM64.
When I replace UEFI shell with my Linux kernel Image, I found a weird Phenomenon:

Succeed:  UEFI(DT) ------> Kernel+U-root (Image) ---kexec---> Ubuntu

Fail: UEFI(ACPI) ------> Kernel+U-root (Image) ---x---> Ubuntu

Succeed: UEFI(ACPI) --grub--> Ubuntu --kexec--> Kernel+U-root (Image) --kexec--> Ubuntu

• The UEFI -->Kernel+U-Root means UEFI directly boot Kernel after BDS phase by EFI_stub.
• When I used the UEFI that use ACPI to config kernel, the first kernel would fail to boot Ubuntu by kexec, without any message.
• But when I first boot Ubuntu, then boot my little kernel ( I put the kernel Image in a virtual disk so Ubuntu can find this file ), then boot Ubuntu again, it would work well.

Reason

When UEFI using ACPI to config kernel, the kernel will generate an empty DT which contains some EFI map messages, command line, physical address for Linux, etc.

However, when Ubuntu is booted by grub, the fdt file (empty DT) it generated contains a node called "uefi-secure-boot", which cannot be generated by the kernel built by my own.

Thus, when my Linux with u-root is booting Ubuntu by kexec, Ubuntu cannot find the "uefi-secure-boot" node from the fdt, and consequently goes wrong.

Temporary solution

I commented the line blow in the source code of Ubuntu, then reinstalled Ubuntu.

UEFI_PARAM("Secure Boot Enabled", "linux,uefi-secure-boot", secure_boot)

Thus Ubuntu would not try to find this node and could be successfully booted by my Linux kernel.

Suggestion

The true solution to this problem is supposed to be modifying the source code of Linux kernel built on my own, to generate an additional "uefi-secure-boot" node.

This problem is important for LinuxBoot because it means we have to customize the Linux kernel in firmware to adapt to various target Runtime OS like Ubuntu and CentOS.

I just discovered the problem when I implemented LinuxBoot on ARM64. I hope this group could take it into consideration and come out with a good solution.

If we have two different versions of a bios with different offsets of FVs, building with one rom first then the other will cause both folders to be left in the build/$BOARD/rom directory. This can mask problems as we end up building with the old FV rather than the new unintentionally if the Makefile isn't changed.

We can clean out the directory, or keep a record and warn when FV offsets have changed.

Right now we're maintaining a fairly large Linux kernel patch that implements the Boot Device Selection (BDS) part of the DXE code: https://github.com/osresearch/heads/blob/master/patches/linux-4.9.80/0000-efi_bds.patch

This does several things:

• Changes the EFI file type from EFI Application to EFI Drive
• Sets the entry point to the new bds_main().
• Locates the initrd image inside a FV
• Registers a callback for the end of driver discovery phase (and then returns to DxeCore)

When the callback is called, the BDS is responsible for:

• Locking SMM
• Connecting all PCI devices (?)
• Signaling end of DXE
• Signaling end of boot services
• And then jumping into the Linux kernel's efi_main().

The drawback to this approach is that we have to maintain the patch for the Linux kernel and it doesn't work with an arbitrary user-provided kernel. Ideally we would be able to use any Linux kernel built with CONFIG_EFI_STUB (or perhaps any multiboot kernel, if we wanted to put Xen or BSD into the flash).

Other features we can add to the LinuxBoot BDS DXE:

• Add additional firmware volumes (for working around broken ROM layouts)
• Enable the BIOS_SEL1 registers to map the entire flash chip (https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/9-series-chipset-pch-datasheet.pdf page 318 and 386)
• Locate kernel command line inside an NVRAM (linuxboot/heads#311)
• Locate the intird in a way that doesn't cause memory errors (linuxboot/heads#264)

Prior to kexecing the user kernel, LinuxBoot boot runtime should have a way of locking down the platform configuration bits.

int the Makefile,i cant understand the two lines:
$(BUILD)/Linux.ffs: $(KERNEL)
$(BUILD)/Initrd.ffs: $(INITRD)
how to create Linux.ffs and Initrd.ffs by bzImage / initrd.cpio.xz ??

The Leopard mainboard comes in several variants with different UEFI layouts and memory controller configurations. We could support them as separate mainboards (named leopard-ddr3 and leopard-ddr4 or something similar) or we could have a way to specify mainboard and variant to the build system.

The TPM is not detected by the LinuxBoot kernel. It appears that the "Tpm20Acpi" DXE is not being run; we've removed most of the TCG things, so a dependency analysis needs to be run.

With me_cleaner, a lot of ROM space (several MiB) could be freed from ME region and potentially used by BIOS region instead.

Is it possible to relocate FVs (especially the DXE FV) inside the enlarged BIOS region to claim these space? And if possible, how to do that?

I have investigated a lot about the build process of EDK2, only to find there should be an FDF to record all the FVs' offset and size, but failed to find how the FDF is built to binary and stored in the resulted FD image.

[Probably, the mailing list would be the better forum, but I still do not know how to subscribe with a non Google Mail account.]

The ROM kernel should boot as quick as possible, so besides hosting configurations to build a minimal Linux kernel, patches and guides how to further speed up the boot should be collected in the LinuxBoot repository/infrastructure.

Right now the Makefile assumes that the ROM file will be in board/$(BOARD)/$(BOARD).rom. The user should be able to override this by specifying a different, possibly external path to their ROM.

The board mainboards/sunxi/nezha is currently based on a fork where I shoved in some extras on top of smaeul's mainline patches, which will land in upstream at some point:
https://lore.kernel.org/lkml/[email protected]/

When merged, we can switch to upstream, maybe 6.0.

UTK is almost ready.

Two changes need to merged into utk before it can replace the Perl scripts. The tracking bugs are:

1. Option to use system xz command
2. Repack

We have the ability to test the changes with leopard, winterfell, QEMU and a new board (Tyan). We'll need help to test the others.

When I run Linuxboot on a server, the server boot becomes slower, the linuxboot project has to load the Linux kernel twice, the device will be loaded twice, is there any way to reduce the boot time of Linuxboot?Thanks!

i want to create linuxboot.rom for qemu,so
first run
make KERNEL = path/to/bzImage INITRD= path/to/initrd.cpio.xz config
then run
make
when create merged.vol,it failed as below:

./bin/create-ffs
--compress
--type FIRMWARE_VOLUME_IMAGE
build/qemu/rom/0x00084000/9e21fd93-9c72-4c15-8c4b-e77f1db2d792/0.fv build/qemu/dxe.vol build/qemu/qemu.txt
| ./bin/create-fv
--size 0x748000
-o build/qemu/merged.vol
alignment attribute 05
FV pad failed
build/qemu/merged.vol: Unable to create FV
boards/qemu/Makefile.board:43: recipe for target 'build/qemu/merged.vol' failed
make: *** [build/qemu/merged.vol] Error 255

Is there anyone know what the possible reason is ? thanks

boards/qemu/Makefile.board doesn't define how the ffs components are extracted, so a parallel make fails the first time. This likely affects winterfell, too.

The following two repositories do the same thing:

• github.com/linuxboot/linuxboot
• github.com/linuxboot/mainboards

The later has been given more attention recently, but the former is more publicly visible (more stars, bugs, ...) and better documentation.

The proposal is to:

• Clean out all usage of Perl in favor of UTK and Makefiles
• Merge github.com/linuxboot/mainboards into github.com/linuxboot/linuxboot
• Transfer the CI system, etc... over too.
• Archive github.com/linuxboot/mainboards

BOARD = qemu
KERNEL = vmlinuz-virt
INITRD = initramfs-virt.gz
ROM = boards/qemu/qemu.rom

I get a different error on the first try.

$ make
( cd edk2/OvmfPkg ; ./build.sh )
Initializing workspace
/home/folaht/Ehsaj/linuxboot/edk2/BaseTools
Loading previous configuration from /home/folaht/Ehsaj/linuxboot/edk2/Conf/BuildEnv.sh
WORKSPACE: /home/folaht/Ehsaj/linuxboot/edk2
EDK_TOOLS_PATH: /home/folaht/Ehsaj/linuxboot/edk2/BaseTools
CONF_PATH: /home/folaht/Ehsaj/linuxboot/edk2/Conf
using prebuilt tools
Running edk2 build for OvmfPkgX64
  File "/home/folaht/Ehsaj/linuxboot/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 548
    except BaseException, X:
           ^^^^^^^^^^^^^^^^
SyntaxError: multiple exception types must be parenthesized
make: *** [boards/qemu/Makefile.board:62: boards/qemu/qemu.rom] Error 1

LinuxBoot works on Leopard, but there are some issues with very slow boot times.

Some of the required DXE/SMM modules are very slow to startup:

• PchBiosWriteProtect.efi takes 2.4 seconds
• IioInit.efi takes 3.6 seconds
• PpmInitialize.efi, 3.4 seconds

Locking SMM is also slow over 6 seconds for the first protocol and 14 seconds for the second:

0.010 [2018-03-22 18:47:47.746] signal smm ready to lock
0.006 [2018-03-22 18:47:47.803] handle_count=00000600
5.973 [2018-03-22 18:47:53.776] InstallProtocolInterface: EF117840-B255-11E2-8EE4-A60DC653765B 770ED018
0.014 [2018-03-22 18:47:53.790] InstallProtocolInterface: EF117840-B255-11E2-8EE4-A60DC653765B 760B9018
14.429 [2018-03-22 18:48:08.219] InstallProtocolInterface: 86C77A67-0B97-4633-A187-49104D0685C7 770E3EB0

Whatever is happening during exit boot services is also taking up to thirty seconds:

0.003 [2018-03-22 18:48:09.079] ExitBootServices
28.304 [2018-03-22 18:48:37.383] efi_main done 057D

When I replaced the UEFI shell with the linux-4.19.6 compiled bzimage according to the example, I entered the server and then entered the uefi shell and displayed a black screen，why？

I am observing below error with 'make run' command,

root@xxxlab-9:/home/ubuntu/linuxboot# uname -a
Linux xxxlab-9 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
root@xxxlab-9:/home/ubuntu/linuxboot# lsb
lsblk lsb_release
root@xxxlab-9:/home/ubuntu/linuxboot# lsb
lsblk lsb_release
root@xxxlab-9:/home/ubuntu/linuxboot# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.4 LTS
Release: 16.04
Codename: xenial
root@xxxlab-9:/home/ubuntu/linuxboot# uname -a
Linux xxxlab-9 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
root@xxxlab-9:/home/ubuntu/linuxboot# make run
make: *** No rule to make target 'bzImage', needed by 'build/qemu/Linux.ffs'. Stop.
root@xxxlab-9:/home/ubuntu/linuxboot#

Any help to resolve this issue is appreciated.

When I try make a second time, I get a different error.
See other issue.

BOARD = qemu
KERNEL = vmlinuz-virt
INITRD = initramfs-virt.gz
ROM = boards/qemu/qemu.rom

GenFfs.c: In the "GetAlignmentFromFile" function:
GenFfs.c:545:5: error: the "InFileHandle" pointer is used after "fclose" [-Werror=use-after-free]
  545 | Error(NULL, 0, 4001, "Resource", "memory cannot be allocated of %s", InFileHandle);
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GenFfs.c:544:5: note: call "fclose" here
  544 | fclose (InFileHandle);
      | ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings are treated as errors
make[3]: *** [../Makefiles/footer.makefile:27: GenFfs.o] Error 1

I can't find anything about CONFIG_EFI_BDS in the linux kernel source. Where are you?

Why do I need an UEFI shell to implement Linuxboot, and the system doesn't need an UEFI shell to boot, and if there is no UEFI shell in a bios file, then do I need to provide a bios file with an UEFI shell? In fact, I did the same, and asked the producer to recompile a bios file with an uefi shell for me. If I could I want to know the order in which Linuxboot is executed (I only know that Linuxboot is executed as an efi file).Thanks!

when I make run the linuxboot with qemu it cause this mistake,anyone can help me?
cut the log

handle_count=00000049
LinuxBoot: bds_main dispatch
LinuxBoot: signal ready to boot
LinuxBoot: Looking for bzimage
LinuxBoot: FFS buffer=0000000006E1E018
LinuxBoot: FFS length=001E1030
LinuxBoot: unable to load bzImage image
ASSERT [DxeCore] /home/liu/work/linuxboot/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c(607): ((BOOLEAN)(0==1))
!!!! X64 Exception Type - 03(#BP - Breakpoint) CPU Apic ID - 00000000 !!!!
RIP - 0000000007F33EC6, CS - 0000000000000038, RFLAGS - 0000000000000206
RAX - 0000000000000070, RCX - 0000000007F32D00, RDX - 00000000000003F8
RBX - 0000000007F32CA0, RSP - 0000000007F32C60, RBP - 0000000007F52C30
RSI - 0000000007F52BA8, RDI - 0000000007918C18
R8 - 0000000007F32D10, R9 - 0000000000000000, R10 - 0000000000000070
R11 - 0000000000000000, R12 - 0000000007F52C30, R13 - 0000000007F52178
R14 - 0000000007A18230, R15 - 0000000003FDFC01
DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030
GS - 0000000000000030, SS - 0000000000000030
CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 0000000007BEEA98 0000000000000047, LDTR - 0000000000000000
IDTR - 00000000078FE018 0000000000000FFF, TR - 0000000000000000
FXSAVE_STATE - 0000000007F328C0
!!!! Find image based on IP(0x7F33EC6) /home/liu/work/linuxboot/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll (ImageBase=0000000007F33000, EntryPoint=0000000007F39923) !!!!

An attempt to port LinuxBoot to the Dell E7420 mentions that there are no guidelines for which DXE modules are necessary to retain, which can be discarded etc.

We should document that.

I've seen firmware volumes with the extended header preset, and it turns out on the roms I'm looking at, the HeaderLength field doesn't include the size of the extended header. To get the correct start of data, the ExtHeaderOffset must be added to the ExtendedHeaderSize if it exists.

The Leopard AMI firmware has per-file compressed sections, which are not supported by the edk2 DxeCore. The symptom is that the linuxboot.rom file is created, but DxeCore doesn't load any DXE or SMM modules, complains about missing required architectural protocols, reports that the BDS has an address of 0x0 and then panics.

The extract-firmware tool has a --repack option that will decompress the LZMA sections and make a single-level FFS. Ideally this will be specified on a per-board basis. We can't make it the default since other platforms that do not use the edk2 DxeCore might not support LZMA compressed firmware volumes, so it is necessary to preserve the per-file compression to have sufficient space in the ROM.

When running linuxboot.rom in QEMU using Linux 4.14.62 (also tried with 5.10.3 and 5.4.69), the following error occurs despite a successful build, no matter the kernel config or initramfs contents:

$ make run
[...]
+--------------------+
|                    |
| Starting LinuxBoot |
|                    |
+--------------------+
num tables=0005
49AA7D31FC1BCDB0
42146F0205AD34BA
FvLoader: adding firmware volume 0xFF500000
FvLoader: error rc=0000000A
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
InstallProtocolInterface: 665E3FF6-46CC-11D4-9A38-0090273FC14D 7B2E408
LinuxBoot: waiting for BDS callback
[...]
--------
Transfering control to BDS 7B2E408
Entry Point 7B2C280 (7B2C280)
--------
LinuxBoot: BDS time has arrived
LinuxBoot: connect pci root brdiges
efi_visit_handles 2F707EBB
handle_count=00000001
PCI Bus First Scanning
PciBus: Discovered PCI @ [00|00|00]

PciBus: Discovered PCI @ [00|01|00]
   BAR[0]: Type = PMem32; Alignment = 0xFFFFFF; Length = 0x1000000;     Offset = 0x10
   BAR[2]: Type =  Mem32; Alignment = 0xFFF;    Length = 0x1000;        Offset = 0x18

PciBus: Discovered PCI @ [00|02|00]
ASSERT [PciHostBridgeDxe] <workpath>/linuxboot/edk2/MdePkg/Library/BasePciCf8Lib/PciCf8Lib.c(1114): ((Address) & (~0xffff0ff | (3))) == 0

<workpath> is the absolute path to where Linuxboot is cloned.

It occurs when running make BOARD=qemu-linuxboot in HEADS, and even when using a make tinyconfig kernel so the kernel config and initramfs don't seem to be the issue.

It looks like the assertion is made during the call to gBS->ConnectController() in efi_connect_controllers() on line 170 of dxe/linuxboot.c

efi_main 0518
efi_main 053D
ERROR: Type:2; Severity:80; Class:3; Subclass:D; Operation: D
bds_entry
OK
bds_main 1
handle_buffer=0000000000001000
connect pci root brdiges
efi_visit_handles 2F707EBB
handle_count=00000010
signal root bridges connected
signal dxe end
signal smm ready to lock
num tables=0006
42146F0205AD34BA
dispatch = 000000007F3F2F68
efi_visit_handles 00000000
handle_count=00000430
bds_main dispatch
bds_main 2
bds_main 5
make_boot_params
early_init done
handle=000000007EC3CB98
fv=000000007EC3B730
000000007EC3B748
000000007F40A5D8
read section rc=0000000E
handle=000000007EC3CA18
fv=000000007EC3B530
000000007EC3B548
000000007F40A5D8
initrd 000000007C4F3018
001EDE00
efi_main
efi_main 0503
efi_main 050A
efi_main 0518
efi_main 053D
ERROR: Type:2; Severity:80; Class:3; Subclass:D; Operation: D

There is a "Adding a new mainboard" section. Is there maybe some tutorial which goes into more detail?
Like starting with the BIOS from some desktop mainboard manufacturer (Gigabyte,Asrock...) . How do you know what you can remove?
Do you actually need to remove stuff or is this only due to size constraints (chip with bigger size would be an alternative then) ?
Is this reasonable to do without having in depth knowledge of UEFI internals? Would it be scriptable or would you always need some initial manual work for a specific mainboard model?
Are there mainboards which are maybe easier to port, like server mainboards or from certain manufacturers?

I would like to try out linuxboot on the Dell R630. However, that model is no longer available. Would you expect the given version to work on a newer model? If so, which one?

When I run Linuxboot on a server that can boot into the operating system normally, I enter localboot -grub -d on the u-root command line but I can't recognize the hard disk in the system, and when I can directly find the grub configuration on another server and boot into the operating system, is there any problem with localboot?

**u-root command line input
/#localboot -grub -d
/#mounted: []
/#No boot configuration found

When testing with the QEMU board, Linux seems to be unable to find the initramfs passed via INITRD=in the make command, only seeming to work when the initramfs is compiled into the kernel via CONFIG_INITRAMFS_SOURCE.

For instance, when building the QEMU board with Linux 4.14.62 and the following make command:

make BOARD=qemu KERNEL=bzImage INITRD=initramfs.cpio.xz

...the following is the trimmed output of Linux:

[...]
[    1.126287] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    1.131970] Please append a correct "root=" boot option; here are the available partitions:
[    1.137506] 0100           65536 ram0 
[    1.137542]  (driver?)
[    1.148742] 0101           65536 ram1 
[    1.148757]  (driver?)
[    1.157381] 0102           65536 ram2 
[    1.157392]  (driver?)
[    1.166110] 0103           65536 ram3 
[    1.166121]  (driver?)
[    1.174361] 0104           65536 ram4 
[    1.174371]  (driver?)
[    1.183369] 0105           65536 ram5 
[    1.183379]  (driver?)
[    1.191239] 0106           65536 ram6 
[    1.191248]  (driver?)
[    1.199519] 0107           65536 ram7 
[    1.199532]  (driver?)
[    1.206887] 0108           65536 ram8 
[    1.206897]  (driver?)
[    1.215189] 0109           65536 ram9 
[    1.215201]  (driver?)
[    1.222033] 010a           65536 ram10 
[    1.222042]  (driver?)
[    1.230619] 010b           65536 ram11 
[    1.230639]  (driver?)
[    1.238051] 010c           65536 ram12 
[    1.238061]  (driver?)
[    1.246527] 010d           65536 ram13 
[    1.246538]  (driver?)
[    1.252880] 010e           65536 ram14 
[    1.252890]  (driver?)
[    1.259175] 010f           65536 ram15 
[    1.259203]  (driver?)
[    1.266338] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    1.269803] Kernel Offset: disabled
[    1.273164] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

The kernel cannot find the initramfs.cpio.xz, even though it is included in the linuxboot.rom.

EDIT: Clarified that INITRD= is a build parameter, not a kernel parameter.

I tried to run qemu with heads as the kernel and ramdisk, using the following commands in the linuxboot build directory:
sudo make BOARD=qemu KERNEL=../heads/build/qemu-linuxboot/bzImage INITRD=../heads/build/qemu-linuxboot/initrd.cpio.xz config
sudo make
sudo make run

The resulting run gave the following error while booting:
0.927991] Trying to unpack rootfs image as initramfs...

[ 3.745463] ------------[ cut here ]------------

[ 3.745973] WARNING: CPU: 0 PID: 1 at free_init_pages+0x2d/0x7a

[ 3.746226] Modules linked in:

[ 3.746551] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.62-heads #0

[ 3.746828] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015

[ 3.747190] task: ffff880006058000 task.stack: ffffc90000014000

[ 3.747443] RIP: 0010:free_init_pages+0x2d/0x7a

[ 3.747658] RSP: 0018:ffffc90000017e70 EFLAGS: 00000287

[ 3.747882] RAX: ffff880004da3000 RBX: ffff880000000000 RCX: ffff8800050f2818

[ 3.748152] RDX: ffff8800050f3000 RSI: ffff880004da2018 RDI: ffffffff81af162d

[ 3.748252] RBP: ffff8800050f3000 R08: 0000000000022080 R09: ffff880005ee81c0

[ 3.748252] R10: 0000000000000090 R11: ffff880005eece00 R12: 0000000080000000

[ 3.748252] R13: ffffffff81af162d R14: 0000000000000000 R15: 0000000000000000

[ 3.748252] FS: 0000000000000000(0000) GS:ffff880006400000(0000) knlGS:0000000000000000

[ 3.748252] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

[ 3.748252] CR2: 0000000000000000 CR3: 0000000002c0a000 CR4: 00000000000006f0

[ 3.748252] Call Trace:

[ 3.748252] ? do_early_param+0x89/0x89

[ 3.748252] free_initrd+0x73/0x8b

[ 3.748252] populate_rootfs+0xee/0xfc

[ 3.748252] ? clean_rootfs+0x12b/0x12b

[ 3.748252] do_one_initcall+0x92/0x138

[ 3.748252] ? do_early_param+0x89/0x89

[ 3.748252] kernel_init_freeable+0x146/0x1c6

[ 3.748252] ? rest_init+0x95/0x95

[ 3.748252] kernel_init+0x5/0xe6

[ 3.748252] ret_from_fork+0x35/0x40

[ 3.748252] Code: 86 ff 0f 00 00 41 55 49 89 fd 48 25 00 f0 ff ff 41 54 55 48 89 d5 48 81 e2 00 f0 ff ff 53 48 39 c6 75 08 48 89 f3 48 39 d5 74 08 <0f> 0b 48 89 d5 48 89 c3 48 39 eb 73 39 49 89 ec 48 89 df 49 29

[ 3.748252] ---[ end trace 1b64cae965fb82bb ]---

[ 3.767684] Freeing initrd memory: 3392K

It subsequently seemed to try a network boot - I expected an initrd shell.

Any idea what may be the problem?

It looks like the #10 fix added an extra dependency on extract.intermedate to ensure that the vendor DXE files were created in build/$(BOARD)/rom, but this adds extract.intermedate to $^ for the resulting LinuxBoot firmware volume.

create-fv doesn't die, it just reports an error and moves on.

Currently, all boards have different build recipes. Some build with cpud, some with this or that set of CLI tools or u-root templates.

In addition, with cpud, there needs to be a pair of SSH keys.

Let's rework that to uniform recipes:
All boards build the same u-root environment, and we add targets for specific templates as a make var, plus one for passing the cpu key pair.

Examples:

make qemu/x86_64

make qemu/x86_64 TEMPLATE=minimal

make qemu/x86_64 TEMPLATE=cpu CPUKEY=`pwd`/cpu_rsa.pub

Note: We could also imply generating keys automatically of none is provided AND none is found in a default location (~/.ssh/cpu_rsa.pub).

Releases aren't ready until chipsec stops complaining.