Category: coreboot

Hello!

During week 13 I worked on:

• writing project documentation
• bug fixing
• code cleanup
• changing debug messages to information popups

DOCUMENTATION

All functions and variables are now documented in javadoc style, I also attached some comments in code, documentation can be generated with doxygen. Besides documenting code I prepared documentation for functional tests which I executed. It contains described test cases and test results.

NEW WORKING CONFIGURATIONS

To make automatic building of coreboot image feature more useful it is necessary to add more data about working configurations. Every added configuration also needs to be tested to check if tool correctly recognizes hardware on target system and builds working coreboot image. I can do this for my hardware, so of course I did, I can also add some fake configurations for testing purposes, but I can’t do this for hardware which I do not have.

Here is description of application, building process and information about data I need to add a working configuration: link. I will be grateful for every configuration which you will send!

GUI IMPROVEMENTS

Tool is targeted mostly for users which are not familiar with coreboot and flashrom details and also dont know how to proceed with building a working coreboot image. Taking it into consideration I changed most debug/error messages to appear in a form of a popup with description what action is needed from application user to proceed or what went wrong.

SUMMARY

End user flash tool is my first experience with coreboot and flashrom. Both of them are not easy projects, especially for someone who does not have great experience with firmware programming, because most code involves serious low level implementations, but in End user flash tool project I have been working always few layers above it because my work involved GUI programming, system programming, integration of external tools like bios_extract or cbfs_tool and adding few features to libflashrom. By doing it I learned a bit how these tools work internally. I am now also more familiar with coreboot itself. This work gave me good basics and smooth entry to the coreboot world. As all of this is interesting and working for such project is very satisfying I want to dive in more and also maintain and extend the tool.

We had an table on the cccamp 2015 in Mildenberg. The cccamp (chaos communication camp) is one of Europe big hacker events every 4 years where several hackers come together and do camping. Everybody could relax a little bit and talk to each other in a nice background. The camp infrastructure contained own wifi, dect, gsm network and a 10 GBit uplink in the middle of nowhere. You could give your tent a 1 Gbit uplink to the internet ;).

Our table was in the BER village, named to the never finished airport near Berlin, Germany. Several people from the coreboot community showed up (CareBear, felix, mue, paulk-collins, tnias, zaolin, […]) and we shared a lot of ideas to each other. In that way we flashed several laptops, replaced some WSON chips with SOIC-8’s. Also we’ve found another bug in the sandybridge ram init, a fix is waiting for merge on gerrit #11248.
paulk-collins came by to talk about a EC open source firmware for the ENE KBxxx embedded controllers.
One of the MAME hackers visited us to get ideas how to port a Dell notebook (ENE KBxxx based EC).
Felix did some work on ME as well other hackers joined him.
Tnias and zaolin started the idea of a raspberry pi doing all the flashing including detection of the device. This could let us drink more Mate while other do the flashing themself.
In the end a thunderstorm reached our tent and we had to evacuate it.

Hopefully everybody can come to Bonn this year.

Hello!

During weeks 10, 11 and 12 I worked on:

• functions for gathering hardware specific data
• automating process of building coreboot image
• GUI improvements

GATHERING HARDWARE SPECIFIC DATA

As I mentioned in my last post, if coreboot image should be built automatically then application needs to collect hardware specific data. During last weeks I added functions responsible for:

• dumping VGABIOS from memory: Some systems (like Lenovo T60 with ATI graphics) require adding VGABIOS dumped from memory to coreboot image, because factory BIOS patches it at runtime, so in certain cases using option rom extracted from factory BIOS may not work
• getting EDID data: to know what type of display panel is used in system
• getting motherboard model name: this is mandatory to recognize if we can install coreboot in system or if we have known working configuration

AUTOMATING PROCESS OF BUILDING COREBOOT IMAGE

It is now possible to build and flash coreboot image by clicking few application buttons without taking care which options are correct for system. Of course this is not possible for all hardware configurations, for now this is very limited, but with time database of known good configurations will grow and more users will be able to flash coreboot in such easy way.

Process of automated image building:

1. Check if working configuration for system is known.
2. Check if configuration requires additional option rom.
3. If necessary, add option rom extracted from factory bios or extracted from running system memory.
4. Build image.

GUI IMPROVEMENTS

I decided to change a look of ‘ROM options’ tab. Previously just raw output of cbfs_tool with rom contents info was redirected to GUI log window. Now it is visible in a form of table, what in my opinion is more readable.

LAST WEEK AND FURTHER PLANS

GSoC “pencils down” date is coming up on Friday, so only few days are left. I want to use this time for:

• writing project documentation
• looking for bugs and fix them
• code cleanup
• adding new working configurations and testing them (I need your help with it)
• change debug messages to information popups

What after GSoC? I would like to still contribute, there is place for many improvements and possible extensions.

Hello!

During weeks 7, 8 and 9 I worked on:

• functions for gathering hardware specific data
• extending libflashrom
• GUI improvements
• testing

GATHERING HARDWARE SPECIFIC DATA

Main purpose of End user flash tool project is to provide an easy way to build and flash coreboot ROM. To achieve it there is a need to collect hardware specific data such as:

• lspci -nn output: information about all PCI buses and devices in the system, it is possible to recognize a graphic card, its vendor and device codes
• dump of factory BIOS: it is important to make a copy of factory BIOS in case something will go wrong, but not only in this case, very often there is a need to use a VGABIOS extracted from factory BIOS if particular graphic card or display panel is present in our system, it is the best to make dump two times and then check if files are the same (for example by comparing hashes)

EXTENDING LIBFLASHROM

Sometimes when flashrom probes for all known chips there are multiple chips found. I needed to implement a function which will return all such chips to GUI. Now in this case it is possible to just select which chip is correct by clicking a proper one in dialog box.

GUI IMPROVEMENTS

I decided to change a bit visual design of the app. There is a new (but most important for the project)  tab – ‘Auto’. In this tab it is possible to gather hardware specific data, which will be then used in a process of automatic building of coreboot image and flashing. I also decided to move programmer selection combobox from ‘Flash tab’ to main application window and  add edit text field for parameters.

LOOKING FOR TESTERS

GSoC ends in next week, application is almost done (but will be improved and extended also after GSoC), so this is time for some testing! I would be very grateful if some of you could help me with it. It would be the best if you have Lenovo T60 and external programmer. First there is a need to collect some hardware specific data and then it would be possible to check if application creates working coreboot image basing on this data. So it is not only about testing, but also about making white list of hardware configurations bigger to let more users flash their hardware with coreboot in easy way!

Please contact me on:

• IRC #flashrom #coreboot: lukaszdm
• e-mail: lukasz.dmitrowski@gmail.com

Thanks in advance!

This covers commits ef0158ec up to commit 1cbef1c
Development is typically slower during the summer and 2015 is no exception, so the report switches to a biweekly installment for a while.

The last two weeks have seen improvements in our development tools:
coreboot upstream can now build Chrome OS boards with Chrome OS features (verified boot, interaction with Chrome EC, flash based error logging) enabled, and the projects builders at http://qa.coreboot.org/ are now routinely building these configurations alongside the regular default configs for all boards.
The builders now run ‘make what-jenkins does’ (see coreboot/Makefile.inc) instead of a hard-coded set of commands, which provides the community the capability to adapt the test build without admin intervention.
When adding the .config used for building an image into said image, it’s now minimized which gives visibility to the relevant changes to the config compared to the board’s defaults.
Kconfig features a strict mode, which acts as a ‘warnings-as-errors’ equivalent and fails the build if kconfig would emit any warning. Since we still have a couple of those in the tree, it’s not enabled yet.
For users of cscope or ctags, we now have new make targets to create tree-wide indexes (make ctags-project cscope-project).

Reproducible builds got a boost by fixes to the build.h generator script, which can finally emit stable timestamps based on the git revision, instead of the local time.

External payload integration was coalesced within payloads/external, with more work in progress. The integrated SeaBIOS build can now also be used when building with ccache. libpayload gained robustness in different developer environments, being smarter about looking for compilers, configs and include files in all the right places.

On the Free Software side, more microcode blobs were moved to the 3rdparty/blobs repository and one false positive that libreboot’s blob detector tripped over was eliminated, and with a little more progress, it should soon be possible to build from a fully blob-free coreboot tree. Before you get your hopes up, please note that the result may not be very useful on a lot of boards, so more care must be taken.

The effort to make coreboot capable of booting in 64bit mode on x86-64 is still ongoing and saw the integration of more commits.

coreboot should have an easier time again when building on Cygwin and BSD systems.

Skylake was the chipset with the largest amount of work in the 2 weeks, but there was also the addition of a coreboot port for RISC-V’s Spike ISA Simulator, contributions to the AMD Bettong mainboard and its chipset drivers, as well as fixes and cleanups to AMD K8 and Intel i945.

In terms of style, a bunch of extraneous whitespaces, indenting errors and FSF addresses were also dealt with.

This covers commits 406effd5 up to commit ef0158ec

Apart from adding the google/glados board, this week’s activity concentrated on bug fixes in chipsets and mainboards, spanning AMD K8 and Hudson, Intel Sandy Bridge, Braswell and Skylake, Nvidia Tegra, Rockchip RK3288 and RISC-V. Most of the changes are too small individually and too spread out across the code base for a shout-out (or this report becomes just a fancy kind of “git log”), but two changes stand out:

Native RAM init on Sandybridge gained support for multiple DIMMs on the same channel, further improving the reverse engineered code base for that chipset.

To improve Skylake support, our 8250mem serial port driver now also supports Skylake’s 32bit UART access mode. This may also be useful when reducing code duplication in our serial console drivers (such as on ARM SoCs).

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.