CAR bootblock is most likely fixing a lot of the issues here, decreasing amount of binaries that need to be located at exact offset to bootblock
(not checked).
Moving cbfs creation to libreboot would lower the space required, accelerate the build process, and decrease cost of adding new board to about 128KiB or less.
When libreboot would save individual binaries instead of entire image, it's important to check contents of cbfs generated by coreboot system, and in case libreboot didn't save a copy of everything - throw an error.
This will also need to be added/used as project inside libreboot build system, so image creation is saner and more flexible (like several payloads, or other data types). It will also make it more clean to add EC images, when shared on flash with host firmware, though one caveat to think about would be targets that don't use coreboot at all.
if you look at the comments in x86/memlayout.ld, cbfstool needs some magic for XIP to work
readelf -h build/cbfs/fallback/*.elf
File: build/cbfs/fallback/bootblock.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0xfffffff0
Start of program headers: 52 (bytes into file)
Start of section headers: 83248 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 11
Section header string table index: 10
File: build/cbfs/fallback/bootblock.raw.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0xfffffff0
Start of program headers: 52 (bytes into file)
Start of section headers: 83248 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 11
Section header string table index: 10
File: build/cbfs/fallback/postcar.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x2000000
Start of program headers: 372 (bytes into file)
Start of section headers: 52 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 8
Section header string table index: 1
File: build/cbfs/fallback/ramstage.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0xe00000
Start of program headers: 372 (bytes into file)
Start of section headers: 52 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 8
Section header string table index: 1
File: build/cbfs/fallback/romstage.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x2000000
Start of program headers: 52 (bytes into file)
Start of section headers: 83452 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 8
Section header string table index: 7
CAR bootblock is most likely fixing a lot of the issues here, decreasing amount of binaries that need to be located at exact offset to bootblock
(not checked).
Moving cbfs creation to libreboot would lower the space required, accelerate the build process, and decrease cost of adding new board to about 128KiB or less.
When libreboot would save individual binaries instead of entire image, it's important to check contents of cbfs generated by coreboot system, and in case libreboot didn't save a copy of everything - throw an error.
This will also need to be added/used as project inside libreboot build system, so image creation is saner and more flexible (like several payloads, or other data types). It will also make it more clean to add EC images, when shared on flash with host firmware, though one caveat to think about would be targets that don't use coreboot at all.
> if you look at the comments in x86/memlayout.ld, cbfstool needs some magic for XIP to work
```
readelf -h build/cbfs/fallback/*.elf
File: build/cbfs/fallback/bootblock.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0xfffffff0
Start of program headers: 52 (bytes into file)
Start of section headers: 83248 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 11
Section header string table index: 10
File: build/cbfs/fallback/bootblock.raw.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0xfffffff0
Start of program headers: 52 (bytes into file)
Start of section headers: 83248 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 11
Section header string table index: 10
File: build/cbfs/fallback/postcar.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x2000000
Start of program headers: 372 (bytes into file)
Start of section headers: 52 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 8
Section header string table index: 1
File: build/cbfs/fallback/ramstage.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0xe00000
Start of program headers: 372 (bytes into file)
Start of section headers: 52 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 8
Section header string table index: 1
File: build/cbfs/fallback/romstage.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x2000000
Start of program headers: 52 (bytes into file)
Start of section headers: 83452 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 8
Section header string table index: 7
```
Furthermore /Makefile.inc includes /site-local dir unconditionally, intended for eg. coreboot distro. Paper can generate /site-local/Makefile.inc with cbfs-files-y and place it there
Paper solutions
Short term: Use /site-local/Makefile.inc
In long term investigate possible choices of implementation:
stripping out only those relevant cbfs-files* lines for given target and somehow using that directly with make
building sample image without payload and extracting all files, while keeping track of their type, compression and potentially offset. A script in release tarball would then assemble desired configuration of an image based on those files + payload + flash size + any extra config. Alternatively paper just generates every possible configuration, but with more targets being added that might end up not being sustainable.
##### Current coreboot cbfs assembly examples (/Makefile.inc)
`seavgabios.bin` from path in `CONFIG_PAYLOAD_VGABIOS_FILE`
```
cbfs-files-$(CONFIG_SEABIOS_VGA_COREBOOT) += vgaroms/seavgabios.bin
vgaroms/seavgabios.bin-file := $(CONFIG_PAYLOAD_VGABIOS_FILE)
vgaroms/seavgabios.bin-type := raw
```
`ramstage` stage with compression: none/LZMA
```
cbfs-files-$(CONFIG_HAVE_RAMSTAGE) += $(CONFIG_CBFS_PREFIX)/ramstage
$(CONFIG_CBFS_PREFIX)/ramstage-file := $(RAMSTAGE)
$(CONFIG_CBFS_PREFIX)/ramstage-type := stage
$(CONFIG_CBFS_PREFIX)/ramstage-compression := $(CBFS_COMPRESS_FLAG)
```
Furthermore `/Makefile.inc` includes `/site-local` dir unconditionally, intended for eg. coreboot distro. Paper can generate `/site-local/Makefile.inc` with `cbfs-files-y` and place it there
---------
##### Paper solutions
Short term: Use `/site-local/Makefile.inc`
In long term investigate possible choices of implementation:
* stripping out only those relevant cbfs-files* lines for given target and somehow using that directly with make
* building sample image without payload and extracting all files, while keeping track of their type, compression and potentially offset. A script in release tarball would then assemble desired configuration of an image based on those files + payload + flash size + any extra config. Alternatively paper just generates every possible configuration, but with more targets being added that might end up not being sustainable.
CAR bootblock is most likely fixing a lot of the issues here, decreasing amount of binaries that need to be located at exact offset to bootblock (not checked).
Moving cbfs creation to libreboot would lower the space required, accelerate the build process, and decrease cost of adding new board to about 128KiB or less.
When libreboot would save individual binaries instead of entire image, it's important to check contents of cbfs generated by coreboot system, and in case libreboot didn't save a copy of everything - throw an error.
This will also need to be added/used as project inside libreboot build system, so image creation is saner and more flexible (like several payloads, or other data types). It will also make it more clean to add EC images, when shared on flash with host firmware, though one caveat to think about would be targets that don't use coreboot at all.
Current coreboot cbfs assembly examples (/Makefile.inc)
seavgabios.bin
from path inCONFIG_PAYLOAD_VGABIOS_FILE
ramstage
stage with compression: none/LZMAFurthermore
/Makefile.inc
includes/site-local
dir unconditionally, intended for eg. coreboot distro. Paper can generate/site-local/Makefile.inc
withcbfs-files-y
and place it therePaper solutions
Short term: Use
/site-local/Makefile.inc
In long term investigate possible choices of implementation: