Workshop 2

Let's get in touch with the hardware stuff

Content

• The basics about firmware flashing
  • Flash ICs
  • Write protection mechanisms
  • Programmers
  • Flash layout
  • IFD

  • FMAP

  • Hands-on: Dumping the vendor firmware

  • Hands-on: Flashing the BIOS region

• The Wedge100s

  • Build coreboot for fsp_broadwell_de

  • Hands-on: Build coreboot for wedge100s

  • Hands-on: Run coreboot on wedge100s

Content

• Debugging
  • Serial console
  • CBMEM console
  • EHCI debug
  • SPI console
  • GDB in QEMU
  • GDB in coreboot
  • Speakermodem
  • Serialice
  • Postcode

  • Debugging techniques on Wedge100s

• Payloads
  • Choosing the right payload
  • Payload types
  • Libpayload
  • Native Graphics Init
  • Hands-on: SeaBIOS with secondary payload
  • Hands-on: TianoCore
  • Hands-on: LinuxBoot with systemboot

Flash ICs

How do they look like ?

CC-by-SA Raimond Spekking

CC-by-SA Tobias ToMar Maier

CC-by-SA MOS6502

Flash ICs

• Typical SPI / QSPI
• SOIC-8 and WSON-8 common packages
• Easily identified by colored point on the chip
• 3.3V, 2.5V and 1.8V

1980

Today

64KB

512KB

4MB

16MB

512MB

• Vendor specific
  • instructions
  • page size
  • block size
  • #blocks
  • software write protection
  • erasure time
  • OTP

Write protection

hardware based

Write Protection

software based

SPI controller

SPI flash

SMM

• Protected region
• Volatile
• Flash independent

• Protected region
• (Non)volatile
• Vendor specific

• BIOS_CNTL
• PRR (Protected Range Registers)

Write Protection

hardware write protection on Chromebooks

• WP-Screw

• Battery powered latch
• EC

Programmers

• No external components
• Running Operation System
• Recovery mechanism
• Transparent flash IC
• Very fast

• Needs external components
• Hardware might interfere
• Voltage / current limits
• Support for flash IC
• Slower
• No recovery needed

Programmers

Baseboard Management Controller

• Only on server platforms
• Recovery mechanism
• Very fast
• High external component count
• Also allows Serial-over-LAN
• Good for debugging and testing

External Programmers

SF100

• https://www.dediprog.com/product/SF100
• SPI programmer
• HighSpeed USB interface
• +94 sec for 16MiB flash

CC-By-SA Patrick Rudolph

External Programmers

for developers: EM100Pro

• Expensive
• https://www.dediprog.com/product/EM100Pro
• FPGA that emulates common SPI ASICs
• High speed USB interface
• Disables in-circuit SPI flash
• Uploads 16MiB in 3 seconds

CC-By-SA Patrick Rudolph

CC-By-SA Patrick Rudolph

External Programmers

for hackers: Raspberry PI

• Native SPI interface
• Ethernet
• Uploads 16MiB in 10 seconds
• GPIOs / UARTs / I2C
• Short circuit might cause the CPU to reboot

CC-By-SA Patrick Rudolph

External Programmers

buspirate and SPI compatible

• Cheap
• Bit bang mode (1 bit per USB transaction)
• Very slow
• Very slow !
• Uploads 16MiB in +30 minutes

External Programmers

wiring

• Not safe to use external power supply
  • Try to use S3 resume or WOL
  • Might power the SoC
  • SoC might missbehave or read from flash ...
• Make sure voltages are OK

• Safe to apply external power
  • Doesn't power SoC

External Programmers

rules for wiring

1. Make sure pinout is correct
2. Make sure voltage is correct
3. Use a current limited power supply
4. Start with low frequencies
5. Use short wires

flashrom

general

flashrom

advice reading firmware

Hands-on: Dumping the vendor firmware

Hands-on: Dumping the vendor firmware

Task:

• Connect to OpenBMC on wedge100s
• Enable the SPI interface
• Route SPI to flash IC
• Run flashrom
• Cleanup
• Set boot from ext. flash

What you need:

• A wedge100s
• SSH credentials for the OpenBMC

20min

Hands-on: Dumping the vendor firmware

Preparations for flashing:

$ source /usr/local/bin/openbmc-utils.sh

$ devmem_set_bit $(scu_addr 70) 12

$ gpio_set COM6_BUF_EN 0

$ gpio_set COM_SPI_SEL 1

$ [ -c /dev/spidev5.0 ] || mknod /dev/spidev5.0 c 153 0

$ modprobe spidev

Hands-on: Dumping the vendor firmware

Using flashrom:

$ flashrom -V -p linux_spi:dev=/dev/spidev5.0 ...

$ ... -r firmware.bin

$ ... -w firmware.bin

Hands-on: Dumping the vendor firmware

Clean up after flashing:

$ source /usr/local/bin/openbmc-utils.sh

$ devmem_set_bit $(scu_addr 70) 12

$ gpio_set COM6_BUF_EN 1

$ gpio_set COM_SPI_SEL 0

Hands-on: Dumping the vendor firmware

Boot from ext flash:

$ source /usr/local/bin/openbmc-utils.sh

$ gpio_set BRG_COM_BIOS_DIS0_N 1

$ gpio_set BRG_COM_BIOS_DIS1_N 0

$ gpio_set COM_SPI_SEL 0

$ wedge_power.sh reset

Hands-on: Dumping the vendor firmware

Just copy the scripts:

$ git clone git@github.com:zaolin/FB-Workshop-Samples.git
$ cd FB-Workshop-Samples/wedge100s/scripts/

Run doit.sh:

$ ./doit.sh -r firmwaredump.rom

Hands-on: Dumping the vendor firmware

Verify what you got:

$ cd coreboot/util/ifdtool
$ make
$ ./ifdtool -d firmwaredump.rom

...

Found Region Section
FLREG0:    0x00000000
  Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
FLREG1:    0x0bff0500
  Flash Region 1 (BIOS): 00500000 - 00bfffff
FLREG2:    0x04ff0003
  Flash Region 2 (Intel ME): 00003000 - 004fffff
FLREG3:    0x00020001
  Flash Region 3 (GbE): 00001000 - 00002fff
FLREG4:    0x00001fff
  Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused)

...

Hands-on: Dumping the vendor firmware

Flash layout on x86

• IFD contains flash layout
• Multiple bus masters!
• Southbridge multiplexes access
• Southbridge supports up to two flash ICs
• One partition for each Coprocessor
• ME >> BIOS

IFD - Intel Flash Descriptor

• Supported since ICH7
• Flash layout
• Access permissions
• Flash special instructions
• OEM section
• Number of flash ICs
• Maximum SPI bus clock
• PCH straps like HAP bit
• Required to boot a PC

IFD - Intel Flash Descriptor

but ...

• No support for fine-grained updates
• Vendor specific
• Layout might change in the future
• Not under firmware control

Hands-on: Flashing the BIOS region

Task:

1. Dump firmware layout of existing firmware
2. Rewrite firmware into BIOS section of IFD

What you need:

• coreboot ifdtool
• Wedge100s scripts
• Wedge100s firmware dump

5min

Hands-on: Flashing the BIOS region

Hands-on: Flashing the BIOS region

$ util/ifdtool/ifdtool -f layout dumpedfirmware.rom

$ ./doit.sh -w dumpedfirmware.com -l layout -i bios

$ ./doit.sh -w dumpedfirmware.com --ifd -i bios

FMAP - Flashmap

• Developed by google in 2015
• Vendor independent flash layout
• Each region has multiple subregions
• Converted by fmaptool
• Can be referenced in coreboot
• Build time sanity checks
• Patches for flashrom pending

HOST_FIRMWARE@0xff800000 8M {
        SI_ALL@0 2M {
                # Firmware Descriptor section of the Intel
                # Firmware Descriptor image.
                SI_DESC 4K
                # Intel Management Engine section of the Intel Firmware
                # Descriptor image.
                SI_ME 1,9M
        }
        SI_BIOS@2M 6M {
                RW_SECTION_A@0 0xf0000 {
                        # Alignment: 4K (for updating) and must be in
                        # start of each RW_SECTION.
                        VBLOCK_A 64K
                        FW_MAIN_A
                        RW_FWID_A 64
                }
                RW_SECTION_B@0xf0000 0xf0000 {
                ...
}

FMAP - Flashmap

IFD vs FMAP

Flashing a single FMAP region

• Patches to support FMAP in flashrom are pending
• https://review.coreboot.org/c/flashrom/+/23203
• Adds the --fmap option

$ flashrom --fmap -i RW_SECTION_B -w coreboot.rom

Build coreboot for fsp_broadwell_de

• You need BLOBs
  • Some are not redistributable
  • You have to contact Intel or download the Intel FSP from their Github homepage
  • Or dump them from your hardware

    • Use flashrom -r backup.rom to read the full image

    • Use ifdtool -x backup.rom to extract Intel IFD and Intel ME

  • Copy BLOBs to 3rdparty

  • Integrate them into the build

Build coreboot for fsp_broadwell_de

• You need Intel FSP 1.0
  • https://github.com/IntelFsp/FSP
  • Redistributable since 23th Aug 2018
  • Not integrated into coreboot build system (yet)
  • Configuration values are binary patched into the BLOB
  • Supports runtime configuration using UPD
  • Binary patching is done using BCT
    • https://github.com/IntelFsp/BCT
    • Supports Fedora 24 and Windows
    • Use WINE on Linux
    • Needs ABSF which holds the configuration values

FSP 1.0

FSP 2.0

Build coreboot for fsp_broadwell_de

Build coreboot for fsp_broadwell_de

• You need microcode updates
  • Intel changed the license a few times
  • Redistributable since 23rd Aug 2018 (again)
  • The format changed from binary to the header in the past
  • Documentation on all sites could be improved
  • Without Microcode updates, nothing works!!!

Hands-on: Build coreboot for wedge100s

Hands-on: Build coreboot for wedge100s

Task:

• Select mainboard OCP > weedge100s
• Set path to FMAP
• Select
  • Use Intel Firmware Support Package
  • Add Intel descriptor.bin file
  • Add Intel ME/TXE file
  • Include external microcode header files
• Set console baudrate to 576000

What you need:

• BLOBs
  • Intel ME
  • Intel IFD
  • microcode headers
  • FSP 1.0

Hands-on: Build coreboot for wedge100s

Get the blobs:

• Select mainboard OCP > weedge100s
• Set path to FMAP: src/mainboard/ocp/wedge100s/board.fmd

Set the following path in menuconfig:

• git clone git@github.com:zaolin/FB-Workshop-Samples.git

• Copy BLOBs from FB-Workshop-Samples/wedge100s/blobs/ to 3rdparty/
• Set path to Intel FSP: 3rdparty/wedge100s_broadwelldefsp.rom
• Add Intel descriptor.bin file: 3rdparty/wedge100s_fd.bin
• Add Intel ME/TXE file: 3rdparty/wedge100s_me.bin

Or extract them from the existing blobs

and go the hard way ;)

Hands-on: Build coreboot for wedge100s

• $ git clone git@github.com:zaolin/FB-Workshop-Samples.git

• Copy headers from FB-Workshop-Samples/wedge100s/microcode/ to 3rdparty/
• Select "Include external microcode header files"
• Set path to microcode headers 3rdparty/ ...
   

Get the microcode headers:

Build the coreboot.rom:

• Save settings in menu config
• run make

Hands-on: Run coreboot on wedge100s

Hands-on: Run coreboot on wedge100s

Task:

What you need:

• coreboot.rom build for wedge100s
• SSH credentials for OpenBMC

• Copy coreboot to OpenBMC /tmp folder
• Flash the coreboot.rom
• Reboot the main CPU
• Watch the serial console

10min

Hands-on: Run coreboot on wedge100s

Reset main CPU:

Flashing coreboot on wedge100s:

$ ./doit.sh -l layout -i bios -w /tmp/coreboot.rom

$ /usr/local/bin/wedge_power.sh reset

Start serial terminal to verify that it worked:

$ sol.sh

Debugging

Serial console

• I/O based or memory mapped 8250 UART on x86
• memory mapped PL011 on ARM
• Supports SMM debugging
• Most platforms support serial from bootstage
• Some don't and need BLOBs for UART:
  • Qualcomm
  • Intel's Broadwell_de (and wedge100s)

CC by SA 3.0 AFrank99

CBMEM console

• Immutable after coreboot
• SMM doesn't support CBMEM console
  • Single producer
  • Lock free
• Implemented as ring buffer
  • Might survive hot reset
  • Shows contents of last boot
• Readable using
  • $ cbmem tool
  • /sys/firmware/log
• Supported by SeaBIOS/TianoCore

EHCI Debug

• Only supported on EHCI USB controllers
• Needs a special USB client "debug gadget"
• Supports only High-Speed USB clients
  • 480 MBit/s
  • 8 byte / BULK transfer
  • Much faster than serial
• Only supported in coreboot / Linux kernel
• Doesn't work in bootstage, SMM, libpayload, SeaBIOS...
• Must enable EHCI driver and console redirect to EHCI !

not sold any more

FT2232H + FT2232H + lunch box + tape = 30 €

EHCI Debug

EHCI Debug

SPI console

• Writes to SPI flash
• Not a ring buffer, it stops when buffer is full
• volatile
• Need to be dumped using flashrom
• Only for debugging !
• Needs support in FMAP
• Needs SPI driver in coreboot
• Works in SMM

SPI console

HOST_FIRMWARE@0xff800000 8M {
        SI_ALL@0 2M {
                # Firmware Descriptor section of the Intel
                # Firmware Descriptor image.
                SI_DESC 4K
                # Intel Management Engine section of the Intel Firmware
                # Descriptor image.
                SI_ME 1,9M
        }
        SI_BIOS@2M 6M {
                RW_SECTION_A@0 0xf0000 {
                        # Alignment: 4K (for updating) and must be in
                        # start of each RW_SECTION.
                        VBLOCK_A 64K
                        FW_MAIN_A
                        RW_FWID_A 64
                }
                CONSOLE@0xf0000 0x10000
                ...
}

Add CONSOLE to your RW FMAP:

SPI console

Extract console from dump:

$ flashrom -V -p linux_spi:dev=/dev/spidev5.0 -r dump.rom

Read complete firmware image using flashrom:

$ ./util/cbfstool/cbfstool dump.rom read -r CONSOLE -f spiconsole.log

Boot SPI console enabled device

Shut it down

GDB Qemu on X86

• coreboot generates .debug files in build/cbfs/fallback/

• Stages can be relocatable

• If stage is relocatable:

  • stage is placed in CBMEM

  • S3 resume will load ramstage from CBMEM

  • add an offset to symbol file when starting gdb

Wrote coreboot table at: 00000500, 0x10 bytes, checksum efe3
Writing coreboot table at 0x7ffa9000
 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
 1. 0000000000001000-000000000009ffff: RAM
 2. 00000000000c0000-000000007ff83fff: RAM
 3. 000000007ff84000-000000007ffb1fff: CONFIGURATION TABLES
 4. 000000007ffb2000-000000007ffddfff: RAMSTAGE
 5. 000000007ffde000-000000007fffffff: CONFIGURATION TABLES
 6. 00000000b0000000-00000000bfffffff: RESERVED

coreboot log:

GDB Qemu on X86

$ gdb
(gdb) add-symbol-file build/cbfs/fallback/ramstage.debug 0x7ffb2000
add symbol table from file "build/cbfs/fallback/ramstage.debug" at
    .text_addr = 0x7ffb2000
(y or n) y
(gdb) b main
Breakpoint 1 at 0x60030f80: file src/lib/hardwaremain.c, line 438.
(gdb) target remote localhost:1234

$ qemu-system-i386 -m 1024 -S -s -bios build/coreboot.rom -M q35

Start qemu and wait for gdb connection:

Start gdb and connect to qemu:

GDB Qemu on ARM

$ gdb build/cbfs/fallback/ramstage.debug
(gdb) b main
Breakpoint 1 at 0x60030f80: file src/lib/hardwaremain.c, line 438.
(gdb) target remote localhost:1234

$ qemu-system-arm -m 1024 -S -s -bios build/coreboot.rom -M vexpress-a9 -nographic

Example with non relocatable ramstage on ARM vexpress-a9:

GDB in coreboot

Speakermodem

• x86 only
• frequency modulated PIT timer
• You need a microphone and application to decode the tone
• Very slow

Serialice

• x86 only
• blackbox tracing of arbitrary firmware
• no reverse engineering of copyright protected BLOBs
• RS232 only

Serialice

• serialice shell runs on real hardware
• firmware under test runs in QEMU
• lua scripts intercept all I/O
• redirects some of the I/O to "real" hardware using serialice shell
• all I/O is captured

POST codes

• Legacy x86
• Very basic
• Only gives a hint what did go wrong

Debugging techniques on wedge100s

• Serial console
• SPI console
• CBMEM console
• morse code on LEDs (currently not upstream)

Payloads

Payload types

• Static ELF binaries
• Flat binaries
• bzImage
• uImage (FIT)
• libpayload based

Static ELF binaries

• Converted to Simple ELF (SELF) by cbfstool
• Fixed position in physical address space
• Not relocatable
• SELF segments can be compressed
• Possible payloads:
  • SeaBIOS
  • GRUB
  • Tianocore
  • depthcharge
  • memtest86+

Flat binaries

• Simple entry point
• No conversion
• Supported payloads:
  • uboot

bzImage

• x86 only
• Is already compressed
• Requires trampoline code
• Follows Linux aarch64 calling conventions
• Has a special loader
• vmlinux, vmlinuz, Image isn't supported

bzImage

• Graphics init in coreboot is optional
• Graphics init in kernel is done late
• No BIOS or EFI services
• Flash as size limitation
• Kernel update requires flashing a new firmware

but ...

uImage (FIT)

• ARM64 only
• Multiple sections (kernel, initrd, devicetree, config, ...)
• Has optional compression
• Includes a DTB
• Follows Linux aarch64 calling conventions
• Has a special loader

libpayload

• Bare metal library used by some payloads
• Custom USB driver
• Custom PS/2 driver
• Simple framebuffer driver
• Understands CBFS/CBMEM/CBTABLES ...
• Provides basic libc functions
• ASM stub, payload can be written in pure C

libpayload

•  Don't expect anything
  • No FPU initialized
  • No SSE enabled
  • Single threaded
  • No interrupts
• Has to deal with hardware bugs
• No filesystem drivers
• on x86 32-bit protected mode only
• Single threaded
• No ACPI support
• Simple powermangement in the works
• No filesystem driver

but ...

libpayload

• depthcharge
• nvramcui
• tint
• coreinfo

Payloads that use libpayload

Native graphics init

• 64 KiB VGA Option ROM BLOB
• 16-bit x86 instructions
• No signature
• Optional YABEL emulator in coreboot
• not redistributable

Situation in comercial BIOS:

Situation in comercial EFI:

• GOP driver BLOB
• Signed code
• Can't be run in coreboot
• not redistributable

Community efforts in coreboot:

• Reverse engineered graphics init using YABEL
• Only for integrated LVDS panels
• Only for some panels ...

Native graphics init

• Written in ADA SPARK
• Supports all platforms starting from gm45
• Supports all connector types

Replaced by libgfxinit on x86:

• Requires coreboot support in the payload or OS
• No resolution switching at runtime
• Can be skipped if payload does graphics init
  • SeaBIOS using VGA Option ROM
  • TianoCore using GOP driver
  • Linux using KMS and VBT

In general:

coreboot framebuffer info

1. Provides a framebuffer base address and metadata
2. Only readable by payloads that know about coreboot
3. No support in Microsoft/Apple
4. Payloads that support reading the framebuffer info:
   • Libpayload
   • GRUB
   • SeaBIOS
   • TianoCore
   • GNU/Linux

#define LB_TAG_FRAMEBUFFER    0x0012
struct lb_framebuffer {
    uint32_t tag;
    uint32_t size;

    uint64_t physical_address;
    uint32_t x_resolution;
    uint32_t y_resolution;
    uint32_t bytes_per_line;
    uint8_t bits_per_pixel;
    uint8_t red_mask_pos;
    uint8_t red_mask_size;
    uint8_t green_mask_pos;
    uint8_t green_mask_size;
    uint8_t blue_mask_pos;
    uint8_t blue_mask_size;
    uint8_t reserved_mask_pos;
    uint8_t reserved_mask_size;
};

SeaBIOS

• x86 only
• CSM for TianoCore
• Supports secondary payloads
  • coreinfo
  • tint
  • nvramcui
  • memtest86
• Build using coreboot toolchain

• payloads stored in CBFS
• loaded by a payload

secondary payloads:

• Only text menu
• Runs unsigned Option ROMs
• BIOS services are 16bit real mode
• No Secure Boot
• Runs unsigned code from MBRs
• No mouse support
• CSM for TianoCore
• Build using coreboot toolchain
• TPM support
• PS/2 driver
• Provides all common 16bit BIOS services
• SeaVGABios for "Native graphics Init"

facts

SeaVGABios

• 16bit VGA Option ROM
• Provides VBE 2.0 interface
• Advertises coreboot's framebuffer info
• No mode switching
• No legacy VGA modes
• RGB8 pallette only
• Code doesn't interact with hardware
• Legacy application do work with coreboot's graphics init

facts

Hands-on: Build SeaBIOS with secondary payloads

Task:

What you need:

Hands-on: Build SeaBIOS with secondary payloads

• coreboot firmware for the wedge100s

• Select ocp > wedge100s as mainboard
• Select SeaBIOS master as payload

Enable secondary payloads

• Run coreinfo, nvramtool and memtest86+
• Enable sercon with the right address in the SeaBIOS payload section

15min

Hands-on: Build SeaBIOS with secondary payloads

Hands-on: Build SeaBIOS with secondary payloads

Hands-on: Build SeaBIOS with secondary payloads

Note: memtest86 is VGA text mode only

Hands-on: Build SeaBIOS with secondary payloads

Note: CMOS support is needed by sub-payloads

TianoCore

• Intel Open Source UEFI reference implementation
• Integrated into x86 coreboot build system
• Only graphical menu
• SeaBIOS as CSM
• Build using an external toolchain
• Includes CorebootPkg
• No Secure Boot support yet for coreboot
• No persistent NVRAM support for coreboot

Hands-on: Build Tianocore in QEMU

Task:

• Select mainboard emulation > qemu-q35
• Select Tianocore as payload in menuconfig
• Select "High-resolution" framebuffer in menuconfig
• Delete a patch to enable serial output in Tianocore

What you need:

(No Blobs)

15min

Hands-on: Build Tianocore in QEMU

Hands-on: Build Tianocore in QEMU

Select Tianocore as payload and select "debug build":

Select "high-resolution" frambuffer in Devices > Display :

Hands-on: Build Tianocore in QEMU

Remove the file:

$ rm payloads/external/tianocore/patches/05_CorebootPayloadPkg_noserial.patch

Build coreboot.rom

Run it in qemu:

 $ make

$ qemu-system-x64_86 -m 2048 -M q35 -bios build/coreboot.rom

LinuxBoot

• The idea of running Linux inside the firmware
• Well tested drivers for anything
  • Graphics
  • USB
  • Input device
  • Block devices
  • SCSI devices
  • Network
  • EC/SuperIO
• Easy to write application programs
  • You don't need firmware engineers
• Project works with coreboot, UEFI and u-boot
• If you are stuck with non-coreboot OCP HW look into the repository for LinuxBoot UEFI supported boards.

• coreboot integration
  • Graphics output via KMS and VBT
  • Requires external toolchain (non x86)
  • No EFI boot support (yet)
  • Big payload size
  • Bigger attack surfaces
  • Drivers for VPD, CBMEM console and coreboot framebuffer are available

linuxboot.org

u-root

• Golang initramfs generator
• Only 4 go binaries
• Has an init system and can start systemd
• Supports source/bb build mode
• Compiles everything into a initramfs.cpio
• Supports libraries aka pkg/*
• Is a coreutils replacement and tools can be found under cmds/*
• Tooling is currently somehow complicated because the use of flags
• Missing Golang kexec implementation for other than x86 but kexecbin is available

u-root.tk

systemboot

• App which runs on top of u-root with custom uinit application
• A LinuxBoot bootloader implementation
• Can run multiple boot commands called booter
• Localboot capability with GRUB2, Syslinux and MBR support
• Netboot capability with DHCP/HTTPS support
• TPM support
• VPD support
• Recoveryhandler support
• RNG seeder support
• Boot Configurations
• Verifiedboot is WIP

systemboot.org

Hands-on:

Build coreboot + LinuxBoot with systemboot

Hands-on: Build LinuxBoot with systemboot

Task:

• Select ocp > wedge100s as mainboard
• Select LinuxBoot as payload
• Set "console=ttyS0,57600" as kernel commandline
• Checkout u-root and systemboot
• Build the initramfs.cpio.xz
• Add systemboot as initramfs.cpio.xz into coreboot
• Build coreboot

What you need:

• coreboot firmware for the wedge100s
• u-root from u-root.tk
• systemboot from systemboot.org

45min

Hands-on: Build LinuxBoot with systemboot

Hands-on: Build LinuxBoot with systemboot

Build u-root

• Install a Go 1.9+ toolchain
• export GOPATH=/path/to/go
• git clone .... /path/to/go/src/github.com/u-root/u-root
• go build u-root.go

Build systemboot

• git clone systemboot into the GOPATH
• cd github.com/u-root/u-root
• GOARCH=amd64 ./u-root -build bb  -format cpio -o initramfs.cpio cmds/init path/to/systemboot/netboot/dir path/to/systemboot/localboot/dir path/to/systemboot/uinit/dir
• xz -f --check=crc32 -9 --lzma2=dict=1MiB initramfs.cpio

Hands-on: Build LinuxBoot with systemboot

Configure the kernel

• The coreboot x86 defconfig under payloads/external/LinuxBoot/x86/defconfig should be sufficient if you enable kexec_file_load
• Compile coreboot with LinuxBoot and abort if kernel compilation starts
• cd payloads/external/LinuxBoot/linuxboot/kernel
• ARCH=x86_64 make menuconfig
• make savedefconfig
• cp defconfig ../../x86_64/defconfig
• cd ...

Hands-on: Build LinuxBoot with systemboot

Hands-on: Build LinuxBoot with systemboot

Modify LinuxBoot parameters and build the coreboot image

• Add the kernel command-line parameters under the LinuxBoot payload section in kconfig of coreboot
  • console=ttyS0,57600
• Copy our newly generated initramfs.cpio.xz to payloads/external/LinuxBoot/linuxboot/initramfs.cpio.xz
• Run the build with a custom toolchain LINUXBOOT_COMPILE=/your/toolchain make

Hands-on: Build LinuxBoot with systemboot

Test time ;)

10min