.png){kind=small}
Introduction
3mdeb Embedded Systems Consulting is a company that evangelizes open-source software on all levels. That includes the firmware, bootloaders, hypervisors, operating systems, and more. As befits a company promoting open-source, it should utilize open-source in daily lives. That is our hardware should run open and secure software whenever and wherever possible. Since the center of our daily work is a workstation, it should meet our requirements in the first place. Most of the employees' PCs in 3mdeb are either HP Compaq 8200 / 8300 (Elite) or Dell OptiPlex 7010 / 9010. Because our company is a licensed coreboot consultant, it would be a shame for us to not have our hardware running coreboot. While the HP workstations are supported in coreboot the Dell machines are not (or rather weren’t 1 year ago when I started my work with them). This fact was the only thing separating us from the dream of having all machines running open-source firmware. That’s how my journey began. I hope you will enjoy reading this and the next posts from the series.
Enabling mainboard support in coreboot
HP Compaq 8200 Elite and Dell OptiPlex 7010 / 9010 are old, one would say. What is the gain from porting such outdated hardware, one would ask. There are three reasons (at least from my perspective):
- profession fetish (yeah well… when you work with hardware for some time, you fall in love with it at some point to the extent that you want to control your machine at every possible level, you want to play with it as much as you can)
- realize the company open-source firmware dream
- these machines have 2nd / 3rd Gen Intel processors which have native initialization support in coreboot, that means you can control whole boot process. The lack of blobs required (except the microcode and possibly EC firmware) makes it the best choice for fully open and auditable firmware. There is no newer Intel hardware with fully open support. If you are looking for it, then your all efforts are in vain.
So machines designed for 2nd / 3rd Gen Intel processors are quite special in coreboot because it is the last, fully open-source capable silicon in the project. It is important for security-aware people, to be able to audit the software they are using and proof code through reproducible builds. 3mdeb is made of such people.
Being fully open-source is one thing, but the ease of enabling new hardware is unbelievable. coreboot developers created a Go utility that helps to port new hardware to the project called autoport. This tool is capable of creating a patch that should be already bootable and is ready to be upstreamed. What is more, the tool can generate CMOS runtime configuration, native graphics initialization support, and even certain Embedded Controller support.
The first patches introducing the Dell OptiPlex 7010 / 9010 support in coreboot were generated by the autoport. There were two patchsets for the OptiPlex 7010:
- by Paul Menzel: https://review.coreboot.org/c/coreboot/+/25095/1
- by Alexander Couzens (Lynxis): https://review.coreboot.org/c/coreboot/+/20239/1
However, neither of them provided a booting implementation. 3mdeb Founder, Piotr Król joined the porting effort at the end of 2018. But due to his limited free time, lack of development machine (Piotr was testing on his own workstation for daily jobs) and sudden lack of responses on the patchset, he stopped soon after. At that time I though about taking over the effort.
Debugging booting problems
In the Q1 of 2019 I decided to buy a Dell OptiPlex 7010 / 9010 myself so I could continue the porting efforts. I could not use any production workstation from the office and this board has two SPI flashes what makes it hardware for development (need to switch the SPI clip or have two CS pins). Having an own machine made the development and debugging much easier. Fortunately I had a RaspberryPi 3 in stock which was able to drive 2 CS pins so I could quickly flash both chips.
Dell OptiPlex 9010 flashing clips 10.03.2019
Dell OptiPlex 9010 flashing setup 10.03.2019
The flash chips were so close to the CPU heatsink, that I had to remove it. Watch out, the CPU overheats quickly, so this setup is only viable for quick-flash testing (but for me it was more than enough to resolve most coreboot booting issues).
In the beginning, I tried to reproduce the problems mentioned in the patchsets, i.e. build a coreboot binary with SPI flash console - it is a debug messages buffer in the BIOS flash written during the boot process. Allows gathering debug information where the board has no other means of connecting a debug hardware (serial port like RS232, LPC debug card or USB debug dongle). Gathering the logs from SPI flash revealed some information, the board was hanging at postcar stage loading (a stage after RAM initialization, that tears the temporary memory environment down). The results were the same as obtained by Piotr: http://paste.ubuntu.com/p/BztHbKNtVm/
One thing that came to my mind is that the SPI flash console may interfere with the boot process. So I have decided to change the debug interface. There were three other options for me: LPC debug card, USB serial debug or serial port debug. Only the last one was viable for me at that time, because I had no debug card (and I would have to solder the LPC header) and FTDI USB dongle. To achieve the goal, I looked for the Super I/O chip model on the board and the datasheet for it. It occurred to be the SMSC SCH5545 (the same as one detected by Lynxis in https://review.coreboot.org/c/coreboot/+/20238/1 ). Unfortunately, there is no datasheet for this particular chip and it doesn’t figure in Microchip product offer. As I have been informed later, the SMSC SCH55** are a special design chips for Dell, so obviously I would never find a datasheet for it. However, I could use a SCH5627 datasheet.
I had all the basic information needed to implement a driver to initialize the serial port. Based on the Lynixs' patchset I have made the serial port working (although I had to fix some bugs, for example to IO base address byte order was incorrect, thus the patch was not working). Disabled SPI flash console in favor of the serial console, rebuilt the coreboot image and burned on the flash, powered the machine on, and… it worked! I have booted the machine up to the SeaBIOS! Prepared a Linux live image quickly to check how it will behave with the operating system running. Thankfully it didn’t have any outstanding issues.
Summary
That would conclude the bringup of the Dell OptiPlex 7010/9010 with coreboot. One would think that the port is almost complete (all that is left is the Super I/O support and code cleanups), but unfortunately not yet. One day a power cut occurred and the machine lost the AC power. When I tried to power the platform on, it was no longer booting. If you are wondering why the title calls this PC “cursed hardware”, then know that the power loss booting problem was one of the reasons why I used this term. If you are curious about the whole story then stay tuned to the next blog posts from the series. There is also a free product incoming which would be ready-to-use binary for this hardware.
If you think we can help in improving the security of your firmware or you
looking for someone who can boost your product by leveraging advanced features
of used hardware platform, feel free to
book a call with us or
drop us email to contact<at>3mdeb<dot>com. If you are interested in similar
content feel free to sign up for our newsletter
