Author: dmitro

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.

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!

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.

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

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!

This week I started with adding new functions to libflashrom. I added 3 functions which purpose is to return a list of supported hardware:

int fl_supported_flash_chips(fl_flashchip_info_t *fchips);
int fl_supported_boards(fl_board_info_t *boards);
int fl_supported_chipsets(fl_chipset_info_t *chipsets);

For example, to obtain a list of supported boards, you can create an array of structures fl_board_info of suitable size, then pass it to fl_supported_boards(fl_board_info_t *boards) and you will have it filled with data, but how do you know what size your array should have?

There are other 3 functions which return number of supported hardware of certain type:

int fl_supported_flash_chips_number();
int fl_supported_boards_number();
int fl_supported_chipsets_number();

Work on libflashrom is still in progress, but as you can see some changes are already made, so I thought that it will be good idea to send a patch just for initial review to know if I am going in a good direction, so I sent a patch to flashrom mailing list.

With use of these functions I was able to extend GUI part of coreboot end user flash tool and add screen which shows list of supported chips, boards and chipsets – screen.

I also started writing unit tests for GUI part, I wanted to use googletest framework, but finally decided to go with QtTestLib as it provides easy introspection for Qt’s signals and slots.

After all of this work I am more familiar with flashrom codebase, but still have much to do and learn, now comes hard, but exciting part – testing and fixing functions related to operations – like reading, verifying, erasing and flashing. Some of flashrom functions previously used in libflashrom are now static or do not exist anymore. I ordered  ThinkPad T60 laptop and SOIC clip for testing purposes, T60 already arrived so lets start disassembling it!

During first week I worked mostly on implementing a part of graphic interface. I prepared a presentation with description of very basic elements and features – link. I will appreciate your feedback about it as it is not its final form!

Is this interface handy enough or should be somehow changed?
Are some important features / options of flashrom or cbfs_tool missing?
Do you have any suggestions?

I also started working with libflashrom – patch set implemented by Nico Huber some time ago (patch), the code is a bit outdated and most functionalities are not working at the moment. I did few changes and now I am able to use fl_set_log_callback() to redirect flashrom print output to GUI. I implemented fl_supported_programmers() function which returns a list of supported programmers. Any suggestions about libflashrom are very welcome! For now I will align to this.

Plan for this week:
1. Continue implementing / improving GUI.
2. Writing unit tests for GUI part.
3. Learning flashrom codebase by fixing and extending libflashrom patch.

Hello coreboot!

My name is Łukasz Dmitrowski and I study Computer Science at West Pomerania University of Technology in Szczecin. I am relatively new to coreboot and firmware programming, but definitely want to dive in, this is why I have chosen coreboot from all available organizations. Last year I participated in GSoC and implemented MQTT-SN client for Wiselib library. It was really great and interesting experience. This year I am excited even more about my project! It is a very good starting point to get familiar with coreboot and stay with you also after GSoC.

Continue reading [GSoC-2015] Introduction – End user flash tool