openpower.foundation_sw_dev

You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

12 KiB

Raw Blame History

title

author

Building and flashing coreboot

To build coreboot image, follow the steps below:

Clone the coreboot repository:

git clone https://github.com/Dasharo/coreboot.git \
   --depth=1 -b raptor-cs_talos-2/rel_v0.7.0

Start docker container:

cd coreboot
docker run --rm -it \
   -v $PWD:/home/coreboot/coreboot \
   -w /home/coreboot/coreboot \
   -u "$(id -u):$(id -g)" \
   coreboot/coreboot-sdk:0ad5fbd48d /bin/bash

Configure and start the build process inside of the container:

(docker) cp configs/config.raptor-cs-talos-2 .config
(docker) make olddefconfig
(docker) make

After image is built you can exit the container, either with exit or Ctrl+D. To flash it to your platform:

Make sure you're running System Package v2.00, if not, get it from here and update/downgrade. Start the platform once so SEEPROM is also updated, then power off.

Copy images to BMC:

scp -O build/bootblock.signed.ecc root@<BMC_IP>:/tmp/bootblock.signed.ecc
scp -O build/coreboot.rom.signed.ecc root@<BMC_IP>:/tmp/coreboot.rom.signed.ecc

Flash both partitions:

pflash -e -P HBB -p /tmp/bootblock.signed.ecc
pflash -e -P HBI -p /tmp/coreboot.rom.signed.ecc

Boot the platform as usual and enjoy coreboot running on Talos II:

[]https://asciinema.org/a/zkQV1KhxY4n6IrlzssuvFHHS5

Building and flashing Heads

Reminder: Heads requires coreboot. Instructions above must be performed before flashing Heads. It also requires a compatible USB security dongle and TPM (more about it later).

Technically, TPM isn't a hard requirement of Heads, however its usefulness without it is very limited, up to a point where it doesn't have any advantages over Petitboot.

Just as earlier, start with cloning the repository:

git clone https://github.com/Dasharo/heads.git \
   --depth=1 -b raptor-cs_talos-2/release

Start docker container:

cd heads
docker run --rm -it \
   -v $PWD:/home/heads/heads \
   -w /home/heads/heads \
   -u "$(id -u):$(id -g)" \
   3mdeb/heads-docker:2.4.0 /bin/bash

Build:
```
(docker) make BOARD=talos-2
```

This will take a while, wait for it to finish and then exit the container. In the process, a coreboot image will also be built, but with slightly different configuration. For security and reproducible images, BUILD_TIMELESS is always enabled. While it actually strips file paths, it also removes file names and line numbers from asserts in the code. It makes reporting and debugging potential issues harder, so we suggest using coreboot built manually, at least for the time being.

Steps for flashing Heads are similar to those done for coreboot.

Copy the Heads binary to the BMC (assuming in the Heads root directory):
```
scp -O build/zImage.bundled root@<BMC_IP>:/tmp/zImage.bundled
```
Log in to the BMC:
```
ssh root@<BMC_IP>
```

Flash the BOOTKERNEL partition with Heads:

pflash -e -P BOOTKERNEL -p /tmp/zImage.bundled

Answer yes to the prompt and wait for the process to finish. After that, start the platform and begin configuring Heads.

PNOR emulation

Flash device can be emulated by BMC, which is something we were often using for development and testing. This saves a lot of time which would be spent flashing, as well as reduces the wear of flash device.

However, this still requires System Package v2.00, and if this is different than what real flash holds, SEEPROM will have to be updated when switching between physical and emulated image. Also, this approach doesn't survive BMC reboots and power losses. BMC doesn't have enough space to keep full PNOR image in non-volatile memory, so tmpfs must be used for emulation. Don't try to put more than one image in tmpfs or BMC will run out of RAM, which most likely will require manual power cycle.

To start, obtain full flash image, either by downloading it from RaptorCS release page or reading from existing image on BMC with:

pflash -r /tmp/talos.pnor

After that, you can "flash" the partitions mentioned earlier by adding additional parameters to use the file instead of physical flash:

pflash -f -P <partition> -p <image_file> -F /tmp/talos.pnor

Change <partition> to one of HBB, HBI, BOOTKERNEL and <image_file> to /tmp/bootblock.signed.ecc, /tmp/coreboot.rom.signed.ecc or /tmp/zImage.bundled, respectively.

To tell BMC to present the contents of this file as flash, run:

mboxctl --backend file:/tmp/talos.pnor

Sometimes this command fails with a timeout, in that case run it again until it succeeds.

We've noticed that sometimes, despite no error message printed, physical flash was used anyway. It is easy to spot when one copy has Hostboot and the other has coreboot, but it can be missed when both images have different versions of coreboot. It caused us few hours of unnecessary debugging of issues that were already fixed...

With the file now mounted, platform can be started. Host firmware and OS shouldn't be able to tell the difference, except for different reported erase block size and maybe different access times.

To get back to original flash, run:

mboxctl --backend vpnor

It will report an error (Failed to post message: Connection timed out), but will revert to physical device nonetheless. This can be confirmed by checking the output of mboxctl --lpc-state:

root@talos:~# mboxctl --lpc-state
LPC Bus Maps: Flash Device

Since the file is now the full image with coreboot (and optionally Heads), it can be simply written to flash, should you choose to accept it:

pflash -E -p /tmp/talos.pnor

Noticeable differences between Hostboot and coreboot

For those wondering why we even started this project, here are some of the differences between Hostboot and coreboot.

First of all, coreboot uses C, while Hostboot was written in C++. The latter can be viewed as a complete operating system - it can use multiple threads simultaneously, manages virtual memory and uses memory swapping (even before RAM is trained). Each major istep (IPL Step, which in turn stands for Initial Program Load) is a separate application, with some common dynamically loaded libraries. coreboot, on the other hand, runs all of the code in just 3 separate stages - bootblock, romstage and ramstage. This allows for tighter linking process, which reduces the final size of the code.

Another significant difference is reduced amount of RAS (Reliability, Availability, Serviceability) features enabled in coreboot. Talos II is often used as a workstation, and while RAS has its uses in servers (it is preferred to start with partially working hardware than not starting at all), for home users booting fast is usually more important. Because of that coreboot doesn't support bad DQ masking for DRAM, it can also optionally skip initial RAM scrubbing. Because of these reasons, as well as smaller size of code in general, booting coreboot is significantly faster than Hostboot - some preliminary results can be found here.

Another technical difference is the way data is passed to Skiboot. Hostboot uses HDAT - a format specific to this particular firmware. For coreboot, a device tree conforming to a well-defined specification is used. In fact, Skiboot internally converts HDAT to device tree anyway. At the moment, some information is not presented by coreboot (https://github.com/Dasharo/dasharo-issues/issues/446, https://github.com/Dasharo/dasharo-issues/issues/32), but those seem to be rather cosmetic than anything else - if you know about something that requires those pieces of information to be present, let us know.

TPM

TPM is an integral part of security mechanisms added by Heads. As existing I2C TPMs were hard to obtain at the time we were working on this part of the project, and LPC TPMs couldn't be used due to the way POWER9 processor exposed access to LPC bus, we had to consider other options.

The solution we ended up with was to create our own I2C TPM 1.2 module, based on Infineon SLB9645TT1.2 chip. This chip isn't supported by drivers in Hostboot and upstream Skiboot, to make use of it you have to use coreboot and Dasharo's fork of Skiboot.

Links and references

Here are some links to documentation related to this project:

main user documentation page
release notes and binaries
list of known issues, if you want to create new issue remember to add proper tag
scripts for dumping debug data and logs
dump of SCOM accesses and other debug output divided by isteps
other uncategorized developer notes
Open Source Firmware Slack channel dedicated to coreboot on OpenPOWER

We invite you to test for yourselves and share the results, both good and bad, either on channels listed above or in issue.

12 KiB Raw Blame History