coreboot

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.

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.

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] coreboot for ARM64 Qemu – Week #6

This week I worked on completing the build and sorting all complications imposed by it. As I talked in the last post, I was facing some issues regarding setting up smp for this port. I solved this issue by adding an assembly file which declared smp_processor_id and then defined it by setting the right registers. I had to do some background reading on arm64 details. This provided me with the information I needed.

Next up, was another hitch. During the build, ‘mmu_enable()’ and ‘arch_secondary_cpu_init()’ function calls are happening for all stages but the definitions for these functions are getting compiled only for ramstage. So this gave recurrent errors since the compiler couldn’t find these definitions. While attempting to sort this, I stumbled across something on the chromium tree. There was a patch which dealt with some of the issues, similar to mine. I had to cherry pick and apply this change.

After debugging and sorting through some more errors, I was finally able to get it to build successfully.

coreboot.rom: 4096 kB, bootblocksize 37008, romsize 4194304, offset 0x90c0 alignment: 64 bytes, architecture: arm64

Name Offset Type Size

fallback/romstage 0x90c0 stage 12108

fallback/ramstage 0xc080 stage 17768

config 0x10640 raw 2034

revision 0x10e80 raw 577

(empty) 0x11100 null 4124312

HOSTCC cbfstool/rmodtool.o

HOSTCC cbfstool/rmodule.o

HOSTCC cbfstool/rmodtool (link)

The complete build can be found here.

I attempted to boot off on qemu after this,

$qemu-system-aarch64 -machine type=virt -nographic -bios ~/coreboot/build/coreboot.rom

This did not give any output, which meant probably I had to make some changes in the uart set up. I attempted to debug this by adding few printks early in bootblock once the console_init is done. This process ongoing, I hope to get through. Another aspect in question is the bootblock initialisation. The src/arch/arm64/armv8/bootblock_simple.c calls for an appropriate bootblock_cpu_init(). This is another thing I will be working on in the coming days.

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

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.

[GSoC] EC/H8S firmware week #5

The T40 is flashing leds! The toolchain is still a little bit tricky. I’m using the debian package gcc-h8300-hms, written a small linker script and took the startup assembly routine from Johann Gysin’s led radiator.

Now I can flash leds. But what about booting the board? I would say it’s enough to put

(!MAINOFF) = high
FAN ON = high
pulse high on (!PWRSW_H8)

But it’s not enough. Also the FAN isn’t starting to rotate. I’ll try to debug every pin this week and solder some debug pins for the 2nd EC (PMHx) to the my modified T40 as well as to an unmodified T42p. The H8S is talking to the PMHx via SPI, while the H8S is the master and is doing bit banging SPI in software, because it doesn’t have a hardware unit for that. I’ll also use these pins for testing my SPI implementation. I’ll try to reuse an open source SPI implementation.

I also asked me if it’s a good idea to port coreboot for the T40 before continuing any efforts to the EC, but it’s a little bit harder, because the T40 uses a LPC/FWH flash in a TSOP40 case. Another option is changing the hardware to a board which is already supported by coreboot like a x60/t60 or x201. But it’s much more harder to access the 8 pins for flashing the EC on these boards.

Before switching to another board, the powersequencing must work and I need a robust recovery way, because when you kill the EC by flashing a new firmware, you don’t get a second chance, unless you solder a lot. Chrome EC fix this problem by splitting the EC firmware into 2 parts. One read-only part and one read-write’able part. Only the second part gets updated and the read-only part can at least boots the device.

Before starting the H8S port for Chrome EC I want to have a bootloader. Because it would improve developing speed. I think implement this is much faster than doing the full Chrome EC support and most of the bootloader code can be re-used for Chrome EC.

I’m also not perfectly sure Chrome EC is the best solution. It’s special use-case is EC, which is perfect. But neither the documentation (I think there is more than one page) nor the bugtracker is public. Thus it makes difficult to use. I’m also not sure if Chrome EC would apply my H8S port into their repository.

[GSoC] coreboot for ARM64 Qemu – Week #4 and #5

From this week I started dealing with the core aspects of aarch64 design. I continued with the process of building the armv8, along with handling the required patching-up, interfacing, hook-ups. In my last post, I had talked about the toolchain building error (in binutils) for arm64 which I was facing on OSX. I had to remove the –enable-gold flag from the binutils. After making this small update, the build_BINUTILS looked like this, and I was able to get the toolchain working.

build_BINUTILS() {
 if [ $TARGETARCH == "x86_64-elf" ]; then
 ADDITIONALTARGET=",i386-elf"
 fi
 CC="$CC" ../binutils-${BINUTILS_VERSION}/configure --prefix=$TARGETDIR \
 --target=${TARGETARCH} --enable-targets=${TARGETARCH}${ADDITIONALTARGET} \
 --disable-werror --disable-nls --enable-lto \
 --enable-plugins --enable-multilibs CFLAGS="$HOSTCFLAGS" || touch .failed
 $MAKE $JOBS || touch .failed
 $MAKE install DESTDIR=$DESTDIR || touch .failed
}

The work had just began after fixing the toolchain. On attempting to building, the faced error I got was :

toolchain.inc:137: *** building bootblock without the required toolchain. Stop.

This was due to certain wrongly configured CONFIG options in the Kconfig. After this stage the initial bring-up of arm64 looked stable. Moving forward, I was met with an error in src/arch/arm64/c_entry.c

src/arch/arm64/c_entry.c: In function ‘arm64_init’: src/arch/arm64/c_entry.c:52:2: error: implicit declaration of function ‘cpu_set_bsp’ [-Werror=implicit-function-declaration] cpu_set_bsp();

The inclusion of necessary files and structures were correct, and I kept getting this error. Furquan ultimately pointed to change 257370 following which, I could get past this. After this, I had to solve another BSD/OSX issue about date in genbuild_h.sh to get my build progressing.

Subsequently, some architectural decisions had to be made for the armv8. In the initial version, I had been banking on cbfs_media based structure in media.c, for creating functions for read, write and map. But the older formulation (in cbfs_core.c and cbfs_core.h) is changed now. In order to keep up, and to maintain uniformity, we decided to handle this as it is handled in armv7, i.e by creating a mapping to the qemu memory mapped space. Another point of discussion for stage loading. It is being brought up similar to armv7 for now. This might change in the future. Also the organisation for UART was finalised. plo11.c is included, as in src/drivers/uart/Makefile.inc. by setting the DRIVERS_UART_PL011 in armv8 Kconfig.

Next hitch was dealing with SMP. In my proposal, I had suggested that incorporating smp into the emulation could be a long term goal. But since smp is a part of core arm64 logic, this cannot be completely ignored at this stage. I am met with this

coreboot/src/arch/arm64/stage_entry.S:94: undefined reference to `smp_processor_id’
build/arch/arm64/c_entry.romstage.o: In function `seed_stack’:

A cpu file which adds smp_processor_id() is needed at this moment, which I am currently working on. Next week’s plan is to get past these (and meet new unforeseen issues 😛 ) and boot off on qemu.

[GSoC] End user flash tool – week #4 #5

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

Integration of cbfs_tool features.
Improving libflashrom querying functions / integrating already existing patches.
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

[GSoC] EC/H8S firmware week #3|4

In the last 2 weeks I managed to flash the H8S on the T40 using the OEM Renesas Flash Tool including their flash application. Flashing works in 2 steps, first upload a flash application into the H8S. Second this flash application will receive the firmware (via serial) and write it into the flash. Thanks to Renesas this application is available in source code. I would like to write an own flasher later.

But I wasn’t able to create a proper application yet. I could write the led programm in assembly, but having a working c compile is needed anyway.

I built a toolchain with gcc 4.9.2. The toolchain buildscript is very simple and can be found on github. I stopped my building efforts for now (building one based on gcc 4.4.6). There’s also a debian package for h8300 (based on gcc 3.4.6) which may be a good alternative. Before continuing in building toolchains and my led application, I’m reading me into linkerscipts and take a look how the compiler is working (e.g. what must a crt0 do?).

At the moment I know how the application should be compiled, where the reset vectors are and where the entrypoint. But putting these things together into a binary image is my task now.

The dev board I mentioned in my last post was stuck by the german post for the last 2 weeks, because there were on strike. The board is now in the custom office and I’ll collect in the next days, which will takes severals hours in Berlin.

[GSoC] coreboot for ARM64 Qemu – Week #3

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.