Category: coreboot

This covers commits 6cb3a59 (which is the 4.1 tag) up to commit 406effd5

This week brought the addition of one new chipset and four new mainboards: Welcome the Intel Skylake SoC, and the new mainboards google/cyan, intel/kunimitsu, intel/sklrvp, and intel/strago, which are Braswell or Skylake based.

As for tools, the script that generated the 4.1 release was added to the tree. To aid with debugging build issues, buildgcc shows the URLs it uses to download the sources to the toolchain. The standard git hook now uses a customized version of Linux’s checkpatch.pl utility for better coding style compliance tests. The cbmem utility gained OpenBSD compatibility when reading timestamps.

The USB host drivers in libpayload saw improvements both for USB3, supporting SuperSpeed hubs and showing more robustness in the presence of strangely behaving USB devices, and for DWC2 controllers, which now support LowSpeed devices behind HighSpeed hubs. coreboot also passes more information to libpayload on where to find the flash part as well as the parameters of the CBFS that was used during boot.

The CBFS format is seeing new development: The default alignment for files is now hardcoded to 64 bytes, which was already the default. There are no known instances where this value was changed, and it simplifies development going forward. The change is forward compatible in that old users can still read new CBFS images. New users run into problems if they work on a CBFS image with a different alignment configuration.

Furthermore there were discussions on how to extend the CBFS format compatibly. So far this led to numerous refactorings in cbfstool to simplify further development.

Finally, there were a whole lot of bug fixes: ARM64, the code for Nvidia’s Tegra210 chipset and the google/foster and google/smaug boards saw lots of development, from making them boot again to various hardware enablement. AMD’s RS780 chipset was effectively disabled due to a typo in the build system. There’s an ongoing effort to bring AMD K8/Fam10h into shape again, which also positively affected HD Audio configuration. CBMEM timestamps are more complete than ever.

There was also the usual bunch of cleanups that get rid of unused Kconfig symbols and configuration options, deal with wrong indentation, and replace magic numbers with meaningful names.

Hello again! During week 6 I worked on two things:

• functional tests of libflashrom on T60
• GUI improvements – filtering and searching list of supported hardware

TESTING LIBFLASHROM

For testing I used Lenovo T60 with Macronix chip and Raspberry Pi. I connected to the chip with SOIC clip and attached it to Raspberry SPI. I needed to disassemble my laptop almost completely because on T60 BIOS chip is blocked by a magnesium frame which must be removed. It is important for me to have easier access to the chip without disassembling everything every time so  I removed a part of frame that covered the chip.

Tested functions:

• fl_flash_probe: function returns proper flash context if we provide a specific chip as its argument, if we probe for all known chips and there are multiple chips found (like in Lenovo T60 with Macronix chip) correct error code is returned (I also needed to implement a way to output multiple flash chips to GUI and then select a proper one, I will describe it in my next post).
• fl_image_read: correct data is loaded to buffer
• fl_flash_erase:  chip has been properly erased
• fl_image_verify: verification succeeded
  
• fl_image_write: data has been correctly written on the chip
  

filtering and searching supported hardware

It is possible now to find a specific chip, board or chipset on the list by selecting filtering options like vendor, size or test status. You can also search by entering a name of a particular hardware (or part of a name). I plan to extend this screen and provide more filtering options when I will finish implementing higher priority features like automating a process of creating a working coreboot image and checking hardware compatibility.

Dear coreboot community,

It has been more than 5 years since we have “released” coreboot ‘4.0’.
That last release marked some very important milestones that we originally prototyped in the abandoned LinuxBIOS v3 efforts, like the coreboot filesystem (CBFS), Kconfig support, and (strictly) separate device trees, build logic and configuration.

Since then there have been as many significant original developments, such as support for many new architectures (ARM, ARM64, MIPS, RISC-V), and related architectural changes like access to non-memory mapped SPI flash, or better insight about the internals of coreboot at runtime through the cbmem console, timestamp collection, or code coverage support.

It became clear that a new release is overdue. With our new release process only slowly getting in shape, I decided to take a random commit and call it ‘4.1’.

The release itself happens at an arbitrary point in time, but will serve as a starting point for other activities that require some kind of ‘starting point’ to build on, described below.

Future releases will happen more frequently, and with more guarantees about the state of the release, like having a cool down phase where boards can be tested and so on. I plan to create a release every three months, so the changes between any two release don’t become too
overwhelming.

With the release of coreboot 4.1, you get an announcement (this email), a git tag (4.1), and tar archives at http://www.coreboot.org/releases/, for the coreboot sources and the redistributable blobs.

Starting with coreboot 4.1, we will maintain a high level changelog and ‘flag days’ document. The latter will provide a concise list of changes which went into coreboot that require chipset or mainboard code to change to keep it working with the latest upstream coreboot.

For the time being, I will run these efforts, but I’ll happily share documentation duties with somebody else – it is a great opportunity to keep track of things, learn about the project and its design and various internals, while contributing to the project without the need to code.

Please contact me (for example by email or on IRC) if you’re interested, and we’ll work out how to collaborate on this.

The process should enable users of coreboot to follow releases if they want a more static base to build on, while making it easier to follow along with new developments by providing upgrade documentation.

Since moving away from a rolling (non-)release model is new for coreboot, things may still be a bit rough around the edges, but I’ll provide support for any issues that arise from the release process.

Patrick

Hello! During week #4 and #5 I worked on several cases:

1. Integration of cbfs_tool features.
2. Improving libflashrom querying functions / integrating already existing patches.
3. Extending and improving GUI.

Integration of cbfs_tool features

cbfs_tool is bigger project than bios_extract, so I took a little more to integrate it than during bios_extract integration as I needed to do some investigation how it works. I imported code related to:

• creating rom file
• adding components like stage, payload, option rom, bootsplash etc.
• printing rom content
• deleting components.

The same like in case of libflashrom and bios_extract I created a static library and linked it with flash tool.

IMPROVING LIBFLASHROM querying functions / integrating patches

After posting my draft patch for initial review on flashrom mailing list I got great feedback which helped me a lot. Urja Rannikko and Stefan Tauner pointed my mistakes and proposed improvements, moreover Anton Kochkov shared his libflashrom changes where he worked on similiar issues.  This community is really helpful. Thanks!

So, I did improvements in querying functions. Currently we have:

const char** fl_supported_programmers(void);
const char* fl_version(void);
fl_flashchip_info *fl_supported_flash_chips(void);
fl_board_info *fl_supported_boards(void);
fl_chipset_info *fl_supported_chipsets(void);
int fl_supported_info_free(void *p);

Unnecessary functions which return number of supported hardware of certain type have been removed. Now we can call functions to allocate the table and get a pointer to it. Of course I will create a patch and post it for second review.

I had a problem as my SOIC clip did not arrive on time, I was not able to test operations related functions on my T60. Actually it was my fault because I have not noticed a comment on internet auction that it may go from China. I have been waiting for 3 weeks for its arrival. Now I already have it so my main focus this week is to test libflashrom on real hardware.

extending / improving gui

I extended a GUI part to allow user to manipulate with rom contents like adding payload, bootsplash etc. and also removing such components. Of course this is not a main purpose of my project. The main focus is to create a tool which will allow user to don’t care about which options are correct. I will be going in this direction, I want to automate a process of creating a coreboot image as much as possible. So currently this is a kind of ‘advanced mode’. I implemented it for several reasons:

• after integration of bios_extract, cbfs_tool and libflashrom it was not big effort to do it
• implementing and testing it helped me to better understand integrated code and its features
• there are also advanced users who may want to do some manual changes

Tasks for current week:

• test probing, reading, flashing with libflashrom on T60 (through linux_spi)
• GUI improvements proposed by Stefan Tauner(searching, sorting and filtering in supported hardware screen)
• code cleanup

For the week 3, I started to build the coreboot image to run on the target arm64 qemu. As soon as I started, I had to face a big red flag, a toolchain building error! The new toolchain (v1.31) failed to build on MacOSX. Despite several attempts, binutils failed to build and I couldn’t get the toolchain running. /buildgcc also failed on OSX due to missing string search for clang. Marc kindly help me out on this by introducing a small patch on this front. I also tried using the actual gcc and g++ (and not the innate gcc and g++ on OSX which are just symlinks to clang) but couldn’t rectify the toolchain build error.  But strangely, when I tried to build an older toolchain (v1.24) on the same machine, it worked. Confused, I decided to move forward with the build with the old toolchain itself.

I had to make some modifications on the src/mainboard/emulation/Kconfig, to bring up the new emulation mainboard. After this, I was able to successfully generate a configuration by running make menuconfig.

Next step was to make and generate the build/coreboot.rom. I have been facing some errors while building which I have been resolving on the way. The plan for this week is to finish the build. I also want to look at solving the toolchain building issue. Stepan said that the new toolchain hasn’t been tested on OSX, so this should provide some useful insights.

During week 3 I worked on integrating bios_extract tool. I did analysis of code, understood it a bit and thought: “Nice, it should be fast and easy, I just need to do few changes”. Was it? Not completely.

After my analysis I knew that I need to do three things:

• change main function to a function which I could invoke from GUI
• redirect logs to GUI
• make it possible to select output directory for extracted individual modules

I implemented it and decided that best solution will be to pack object files to static library. I compiled it and linked with my app, then I tried to extract a BIOS image and – BAM! – segmentation fault. Hmm, I did not change anything in extraction logic, so where I messed up? I started reverting my changes – segfault, segfault, segfault. I reverted almost all changes – still segfault. I downloaded bios_extract again and tried to first create object files from unchanged code, then build standard bios_extract app and apply my changes one by one. I compiled without any changes, tried to run bios_extract and… segmentation fault. I tried to compile with provided Makefile – it worked. Whoops, I missed checking Makefile content. This caught my attention:

CFLAGS ?= -g -fpack-struct -Wall -O0

fpack-struct? What is this sorcery? I googled it. Aha! Got you! This compiler flag packs all structure members together without holes, so structure alignment is not applied. Now it was obvious why I had segmentation faults, even if code was the same it worked differently because of different spaces between structure members. From this moment it was fast and easy 🙂

So, bios_extract is already integrated, it is possible to select rom file, select output directory and extract submodules there. Of course bios_extract log output is redirected to GUI. This is good, I can use rest of the week to work on libflashrom, my SOIC clip did not arrive yet, so I am still not able to test operation related functions, but already have feedback about my modifications applied to previously existing libflashrom patch, so I can start improving it – big thanks for review!