[GSoC] End user flash tool – week #7 #8 #9

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.

choose_chip

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!

coreboot changelog – Weeks of 2015-07-27 and 2015-08-03

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.

The truth about Purism: Behind the (coreboot) scenes

This post does not reflect the opinion of the coreboot project leadership, but reflects the personal opinion of its author, Alex Gagniuc.

Since the last time I talked about Purism’s stab at a coreboot laptop, a lot happened, including the launch of the non-libre Librem 15, alongside with plans for a 13″ version. My last post seems to have sparked quite some controversy on the subject, placing me on the CC field of many emails between not-so-happy supporters and Todd Weaver. I’ve avoided writing on this subject again, because I didn’t have anything good to say about Purism. However, considering the amount of new emails being generated lately, I think I should follow up on why the Librem 15 failed on the freedom front, and why another Purism laptop is just as likely to fail.

The road so far

A lot has happened since my last post, including a lot of media coverage on the issue. Now I can use acronyms like FSP, ME, and EC, without having to worry about losing 90% of my audience. It’s great that there is now a lot of non-technical coverage on the issue, something that non-corebooters can easily digest. However, some things also happened behind the scenes, which I’d now like to talk about.

Trying to meet Todd in person

After my initial post, a large number of emails flew back and forth between angry backers, Crowdsupply, and Purism, with me on the CC field. From this, I’ve had the chance to communicate with Todd Weaver directly, and express to him my concerns on why the Librem was about to fail. I also offered to set up a meeting with Stefan and Ron. I’ve talked to Stefan, and he seemed excited to speak with Todd and help put coreboot on the Librem. Ron shared the following over the email thread:

Todd, I think the overall concern with librem and your statements is the seeming lack of realization that you're walking over very well trod ground, and there are lessons learned, and we might as well pass them on.
I for one seeing you making the same mistakes that have been frequently made over 15 years, and there's benefit to learning what we've learned.

That was back in March. The meeting hasn’t yet happened. The discussion died down when I asked Todd to produce the current source code for the upcoming librem. After almost a month from my initial inquiry, on May 11, Todd wrote:

We will be releasing the source code once we get coreboot working on our rev1 which will be shipping within the next few weeks.

The Librem 15 launched

Fast forward a few months later, after the email exchanges died down, I get a tip that the Librem 15 has shipped with AMI UEFI firmware. While I do not have a Librem 15 in my possesion, this has been confirmed by PC World. Although I hate having been right about this, I love saying this: I told you so.

Todd claims he has coreboot developers working on Librem

A new wave of angry emails ensued just recently. I once again had the chance to communicate with Todd directly. He claimed to have three coreboot developers working for Purism, but they wanted to remain anonymous. He did, however, provide the name on one of the developers, whom I shall not mention for privacy reasons. Of course, I was curious to see what that person worked on:

[coreboot]$ git log |grep Author |grep -i <first name> -c
0
[coreboot]$ git log |grep Author |grep -i <last name> -c
0
[coreboot]$

I’ve informed Todd that this developer is not a coreboot contributor, and for the purpose of our discussion, does not count as a coreboot “developer”. I’ve asked Todd to produce git hashes of patches contributed by one or both of the other two developers. He has not done so.

Purism attacks Minifree (formerly Gluglug)

purism_attacks_minifree

Just this morning, a tweet was brought to my attention, which, to me, seems like a direct attack on Minifree from Purism. The tweet compared an “old heavy IBM Thinkpad”, with the Librem 15, showing the picture of a T60 Thinkpad running libreboot. This is also one of the pictures Gluglug (now Minifree) used on its product page when they were selling the T60 model.

For those of you unaware, Minifree (formerly Gluglug) sells laptop systems which are completely free, from the OS down to the firmware, and which are endorsed by the FSF through their Respects Your Freedom certification. The Minifree laptops are what we, as the community have been working to achieve since the inception of LinuxBIOS more than fifteen years ago, and the reason I have stuck with the project for over half a decade despite all the difficulties and roadblocks. To attack Minifree is to insult all of our hard work over the years, and to me, it indicates that Purism really doesn’t give a damn about your freedom, but they really like your support and money.

I know I promised I would also talk about why another Purism laptop is just as likely to fail as the Librem 15, but I’ve ranted enough for one post. I’ll describe that into more detail next time.


UPDATE: I just received the following private email from Todd Weaver:

Ouch, that is not an approved tweet. I asked to have it removed, since I am a big fan of what Gluglug did/does. And we provide it as an alternative from our own website.

Update: coreboot conference in Europe, October 2015

UPDATE: Invitations published, venue is decided, few bed+breakfast rooms at the venue are still available

TL;DR: coreboot conference Oct 9-11, more info at http://coreboot.org/Coreboot_conference_Bonn_2015

 

Dear coreboot developers, users and interested parties,

we are currently trying to organize a coreboot conference and developer meeting in October 2015 in Germany.

This is not intended to be a pure developer meeting, we also hope to reach out to manufacturers of processors, chipsets, mainboards and servers/laptops/tablets/desktops with an interest in coreboot and the possibilities it offers.

My plan (which is not final yet) is to have the Federal Office for Information Security (BSI) in Germany host the conference in Bonn, Germany. As a national cyber security authority, the goal of the BSI is to promote IT security in Germany. For this reason, the BSI has funded coreboot development in the past for security reasons.

The preliminary plans are to coordinate the exact date of the conference to be before or after Embedded Linux Conference Europe, scheduled for October 5-7 in Dublin, Ireland. Planned duration is 3 days. This means we can either use the time window from Thursday Oct 1 to Sunday Oct 4, or from Thursday Oct 8 to Monday Oct 12. The former has the advantage of having cheaper hotel rooms available in Bonn, while the latter has the advantage of avoiding Oct 3, a national holiday in Germany (all shops closed). UPDATE: Preliminary dates are Friday Oct 9 to Sunday Oct 11. The doodle has been updated accordingly. Thursday and Monday could be filled with some cultural attractions if desired.

ATTENTION vendors/manufacturers: If your main interest is forging business relationships and/or strategic coordination and you want to skip the technical workshops and soldering, we’ll try make sure there is one outreach day of talks, presentations and discussions on a regular business day. Please indicate that with “(strategic)” next to your name in the doodle linked below.

If you wonder about how to reach Bonn, there are three options available by plane:
The closest is Cologne Airport (CGN), 30 minutes by bus to Bonn main station.
Next is Düsseldorf Airport (DUS), 1 hour by train to Bonn main station.
The airport with most international destinations is Frankfurt Airport (FRA), 2.5 hours by train to Bonn main station.
There’s the option to travel by train as well. Bonn is reachable by high-speed train (ICE), and other high-speed train stations are reasonably close (30 minutes).

What I’m looking for right now is a rough show of hands who’d like to attend so I can book a conference venue. I’d also like feedback on which weekend would be preferable for you. If you have any questions, please feel free to ask me directly <c-d.hailfinger.devel.2006@gmx.net> or our mailing list <coreboot@coreboot.org>.

Please enter your participation abilities in the doodle below:
http://doodle.com/bw52xs4fc7pxte6d

Regards,
Carl-Daniel Hailfinger

coreboot changelog – Week of 2015-07-20

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).

[GSoC] EC/H8S firmware week #7|#8

Week #7 was is little bit frustrating, because of no real progress, only more unfinished things which aren’t working. Week #8 was a lot better.

1. Sniffing the communication between the 2 embedded controllers H8S and PMH4.

I’ve tried to build an protocol analyser with the msp430, but the data output was somehow strange. For testing purpose I used my H8S firmware to produce testing data. But the msp430 decoded only wrong data. I’m using IRQs on the clock to do the magic and writing it to a buffer before transmitting it via UART. Maybe the msp430 is too slow for that? Possible. Set a GPIO to high when the IRQ routing start and to low when it ends. Visualize the clock signal and connect the  IRQ measure pin to an oscilloscope. The msp430 is far too slow. I’m using memory dereference in the IRQ routine, which takes a lot of time. Maybe the msp430 is fast enough, when using asm routine and registers to buffer the 3 byte transmission. But a logic analyser would definitely work. So I borrowed two logic analyser. An OLS (Openbench Logic Sniffer) and a Saleae Logic16.

There isn’t so much data on the lines. Every 50 ms there is a short transmission of 3 byte. But I don’t want to decode the data by hand. So it needs a decoder for the logic analyser. sigrok looks like the best start point and both analyser are supported.

I’ve started with the Openbench Logic Sniffer, but unfortunately it doesn’t have enough RAM to buffer the input long enough. Maybe the external trigger input can be used. But before doing additional things I would like to test with the Logic16.

The Logic16 doesn’t support any triggers but it can stream all data over USB even with multiple MHz. Good enough to capture all data. I found out that the best samplerate is 2 MHz. Otherwise the LE signal isn’t captured, because it’s a lot shorter than a clock change. In the end I created a decoder with libsigrokdecode.

sigrok-cli -i boots_and_shutdown_later_because_too_hot.sr –channels 0-3 -P ec_xp:clk=2:data=3:le=1:oe=0 | uniq -c 

67 0x01 0x07 0xc8
3 0x01 0x04 0xc8 
4 0x01 0x10 0x48
1120 0x01 0x17 0x48
67 0x01 0x07 0xc8

0x01 0x07 0xc8 is called when only power is plugged in, like a watchdog(every 500ms)
0x01 0x17 0x48 is called when the device is powered on, like a watchdog (every 50ms)
0x01 0x04 0xc8 around the time power button pressed
0x01 0x10 0x48 around the time power button pressed

2. Flash back the OEM H8S firmare

The OEM H8S firmware is included in the bios updates. cabextract and strings is enough for extracting it out of the update. Look for SREC lines. Put the SREC lines into a separate file and flash them back via UART bootloader and the renesas flash tool. The display powers up and it’s booting again with OEM BIOS.
I could imagine they are using a similar update method like the UART bootloader. First transfer a flasher application into RAM and afterwards communicate with the flasher to transfer the new firmware, but the communication works over LPC instead of UART.

3. Progress on the bootloader

I’ve implemented the ADC converter to enable the speaker amp and the display backlight brightness.

Written down LPC registers and just enable the Interface in order to get GateA20 working. Still unclear how far this works.

4. How to break into the bootloader?

The idea of the bootloader is providing a brick free environment for further development. The bootloader loads the application which adds full support for everything. It should be possible to stop the loading application and flash a new application into the EC flash. When starting development on the x60 or x201 I want to use I2C line as debug interface. I2C chips have a big footstep and are easy to access. But there must be a way to abort the loading. I will use the function key in combination with the leds.

  1. Remove the battery and power plug.
  2. Press the function key
  3. Put the power plug in
  4. Wait until leds blinking
  5. release the function key within 5 seconds after the leds starting to blink to enter the bootloader.

The H8S will become I2C slave on a specific address.

What next?

  • Add new PMH4 commands to the H8S
  • solder additional pins to MAINOFF PWRSW_H8 A20 KBRC
  • use the logic analyser to put the communication in relation with these signals
  • UART shell
  • I2C master & client
  • solder LPC pins to analyse firmware update process
  • test T40 board with new PMH4 commands and look if all power rails are on

coreboot changelog – Week of 2015-07-13

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.

[GSoC] End user flash tool – week #6

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.

t60_SOIC

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.

supported_hardware

Announcing coreboot 4.1

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

[GSoC] EC/H8S firmware week #6

This week I looked at the communication between the EC H8S and the PMH4. The PMH4 (likely power management hub) is an ASIC which takes care of the power control. It controls who get’s power and who not. It doesn’t do any high level work, more like a big logic gatter. The PMH4 has inputs from several power good pins from different power rails and chips. On the output side it controls some power rails. It can also reset the H8S. The PMH4 also knows over some pins in which power state (ACPI S0,S4,S5) the board is. It doesn’t do any high level work. It’s more like a big logic gatter. There are no ADC on any power lines.

The PMH4 is connected to the H8S via 4 Pins. ~OE LE DATA CLK.

gsoc 2015 pmh4 connector t40

I connected a buspirate in SPI sniffer mode to debug the protocol. But the output looked a little bit strange. There was no data from the PMH4 to H8S (MISO) and the data comes in burst. To get more knowledge on the protocol I used a digital oscilloscope.

pmh4 oscilloscope

The protocol doesn’t look like SPI. LE get’s low after every transmission, ~OE is just high, clock and data just transfer the data. Sometimes when the H8S gets an interupt the Clock pause for some time and continues with the data afterwards. The clock is around ~400kHz.

I confirmed the protocol via the oscilloscope, but still I don’t get any sign from the board. No fan, nothing else. There must be more than this single transmisison. Maybe the board is to much damaged. My modified board was already broken when I got it. There is a loose connection related to the cardbus. Maybe this is my problem I don’t know.

I’ve two board with two connectors for the PMH4 here. Why not using the OEM one as starter help for the other one?

t42 gives some starting help

I think the PMH4 does what it should do. The H8S has an digital-analog-converter pin connected to the video brightness. But I haven’t implemented it yet. But I don’t think the device booted, because neither the CPU nor the chipset produce any heat. Ok, maybe it does, I only used my finger as thermometer. A thermal camera would help here. I’ll borrow a thermal camera for that.

There are lot of pins which I ignore atm. E.g. A20 pin. Is there something to do in a specific time serie?

What’s next?

  • build a small protocol sniffer for the PMH4 XP using a msp430 or stellaris arm
  • make progress on the bootloader
  • find a way to flash back the OEM H8S firmware
  • find a way to flash my bootloader via OEM flash tools

My requirements to the bootloader are

  • UART flashing via XMODEM
  • a simple UART shell
  • I2C as recovery and shell as well

I2C pins are a lot easier to find and modify than the H8S UART. I’m not yet sure if the H8S should be the master or the slave and on what address he should use? Multiple? UART tx is working. Rx is a task to do.

PMH4 / PMH7 / Thinker communication

On newer board the PMH interfaces changed (>= x60, t60, …). They merge the LPC interface and the XP interface into an protocol over SPI. And the new PMH is used as GPIO expander as well.

pmh4 pmh7 thinker communication