Category: coreboot

[GSoC] coreboot for ARM64 Qemu – Week #2

I spent the previous week working on the architecture of the qemu port. I made an attempt to dive into the internals of memory mapping for armv8. And then formulated an initial memory map structure for the armv8 port. After that I moved into developing some code. The most challenging aspect of this was moving to and fro between the qemu-armv7 existing port and the foundation-armv8 patches (now depreciated) of chromium and extracting the required modifications. My current work is building on qemu-armv7  taking inspiration on some aspects from the foundation armv8 which cater to the alterations required for 64-bit.

I then moved onto developing the default mem_uart which would be used in our emulation. After writing up a backbone for this new port, Marc suggested I push to gerrit and seek some reviews on it there. This was an important change from the development strategy I followed last year, when I did all the development locally and then pushed the end results to gerrit. This year, I would be following a more dynamic approach, with a continuos review-and-modify development cycle.

My plan for this week involves starting to build the firmware written thus far. I will look to load the built firmware in qemu and try getting some output on the console and finally get qemu-debug up and running.

 

[GSoC] End user flash tool – week #2

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!

[GSoC] EC/H8S firmware week #2

The last week was a little bit depressive. I did the some resoldering. Pin P90 wasn’t connected to 3.3V which is needed to enter the flash boot mode. It was soldered  to the VCC of the Serial level shifter MAX3243. After searching some minutes with the Multimeter for a better power source, I decieded to use 3.3V near the H8S. It’s now a very long cable across the board.

Now let’s see, how good this works? Nothing :(. Recheck with a voltmeter and found another problem with P91 (/SUS_STAT). When connecting SUS_STAT with an 1k resistor to 3.3V the voltmeter shows 0.04V. This means it’s driven by something else to 0V. My hope was that the chipset isn’t driving this until it’s powered. But sadly it is driving it to 0V. What’s SUS_STAT? SUS_STAT can be used as LPCPD (LPC power down) and is used to notify devices to enter a low power state soon. Suspend Status is active low, which means all device should be in low power mode.
What should I do now? I need 3.3V on that line.

There are multiple solution:

  • Remove 1k and burn it to death. But likely this could kill the chipset or
    a least this certain pin or multiple pins
  • Cut the pin
  • Bend the pin upwards while desoldering
  • Desolder the whole chip and bend afterwards, resolder
  • Replace the chip with a socket (expensive and rare)

This decision is not easy to take, especially because I never done most
of these things. This got me stuck for a while until Peter helped me out,
he bend a single pin upwards. Thanks!

The next week milestone is still flashing the EC, the same goal since the first week. So the time schedule will be a little big chaotic. Maybe I can hurry up and reach another weekly goal fast than a week.

Because I was stuck on that a little bit, I took another look on ebay and bought a development board with a H8S/2633. 2633 is a little bit newer than the 2100 series
which is used in Lenovo laptops. The board should arrive in one week, but atm it’s in german customs. Such development boards are hard to get for a “good” price. Brand new boards start with several hundred euros or dollars. E.g. the debugger E10 (USB device) cost around 1000 Euro, it’s only a stupid USB device. I already bought on ebay an E8, previous generation debugger, but it can not debug the chip, only flash them with the Renesas software/IDE.

Beside my project I’ve done some other work on coreboot. I helped Holger Levsen on creating a reproducible build job for coreboot on reproducible.debian.net. More info about reproducible builds are on their wiki page.  To improve reproducibility I created 2 patches #10448 #10449. They cleaned up reproducible bugs in coreboot and without building Payloads, most targets are now reproducible. Great thanks to Holger Levsen for his work on that!

[GSoC] coreboot for ARM64 Qemu – Week 1

To begin with the aim of introducing coreboot for arm64 qemu, the first task I had to accomplish was to set up a qemu aarch64 environment to work on. In this post, I will talk about building qemu and then booting a kernel that allows us to begin experimentation with this architecture.

To begin building qemu, we need a few packages:

pkg-config, libfdt-dev

Next,  we need a qemu version which support aarch64, so I installed qemu 2.3.0.  Here you can also do :

sudo apt-get install build-dep qemu

Since I was building it on a mac, I was required to do a brew install qemu (again, v2.3.0). For mac, it is recommended to use actual gcc rather than the existing ‘gcc’ which is symbolic-linked to llvm-gcc (x86_64-apple-darwin13.4.0/4.9.2/). Going with the innate gcc kept giving me pains, so I downloaded gcc 4.9.2, created a manual link and used it for my build. Moving on, we now need some of the source code;

git clone git://git.qemu.org/qemu.git qemu.git
cd qemu.git
./configure --target-list=aarch64-softmmu

The last command will usually return an error, saying DTC (libfdt) not present. The problem is that qemu tries to search for dtc binaries in qemu/dtc. Even if you install dtc using sudo apt-get install device-tree-compiler, we keep getting this error. So probably you need to have the binaries in qemu/dtc. Doing this in the repo will fix it.

git submodule update --init dtc

Then, run the ./configure command again. The output can be found here. We then have to run a make command,

make

This gives the following ouput. After this successful build, we have an executable ./qemu-system-aarch64 in qemu.git/aarch64-softmmu. I then used a prebuilt kernel image that has a combined initial RAM disk (initrd) and a basic root file-system. It can be downloaded from here.

Then finally, we run this kernel in our generated aarch64 system to find the linux boot sequence and eventually a log in prompt.

qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -nographic -smp 1 -m 2048 -kernel ~/Downloads/aarch64-linux-3.15rc2-buildroot.img  --append "console=ttyAMA0"

The boot sequence results as

Welcome to Buildroot
buildroot login: root
# ls
# uname -a 
Linux buildroot 3.15.0-rc2ajb-00069-g1aae31c #39 SMP Thu Apr 24 11:48:57 BST 2014 aarch64 GNU/Linux

This gives us an aarch64 qemu environment with linux on which we can begin building coreboot.

With the development platform ready, I now begin my actual work on building coreboot for qemu arm64. For this week, I look at the ( now obsolete ) foundation-armv8 patchset and begin my development. The first task would be to create an appropriate media structure / functions that I would use.

 

[GSoC] End user flash tool – week #1

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.

[GSoC] EC/H8S firmware week #1

The first task of my project is a working development board. A development board means that I have serial communication and I can flash new firmwares the chip and whole mainboard isn’t booting. The chip is a H8S 16-bit microcontroller with 64kb to 128kb EEPROM and is available in different packages. BGA and TQFP. BGA means the pins are under the chip, TQFP has pins on the side. TQFP is nice to hack, but most modern Thinkpads use the BGAs. But a T40 or T42 use a TQFP package. A friend donated his old T42 to me! Thanks a lot! Now with a hackable T42 I can start to create a development board out of the T42 mainboard. Like most other microcontroller this chip has a programmable bootloader in a ROM (called rom loader). The bootloader can boot to different states, configurable via 5 pins (MD0 MD1 P90 P91 P92).
P90 to P92 are only read when MD0 and MD1 are in a special bootstate.
After reading the documentation I found that the pins must match the following volatage levels to select the flash boot mode:

MD0-MD1 = 0V, P90-P92 = 3.3V.

Besides these configuration pins we need some additional wires to the following pins:
/RES – reset active low
UART RX – serial communication
UART TX –

Now it gets interesting. The MCU (microcontroller unit) can use a pin for different purposes depending on the PCB designer. Those pins called multifunction pins. Hopefully we don’t get blocked by unaccessible pins. After reading more documentation and using a Multimeter on the board I found out that /RES, RX, TX, MD1 require soldering, but are easy accessible. MD0 is already in a good state.
P90 is connected via a resistor to ground, but we need it to 3.3V.
Let’s find the resistor to solder 3.3V to it… Mhh. tricky! 3h later I found it on the
board hidden under the PMH4 (2nd EC/GPIO expander). Very uncommon.

P91 is named /SUS. Suspended active low, but can be driven by multiple controllers (chipset + h8s).
Because we want to boot linux on the main cpu later in the project we should not kill the chipset. I added a pin connector to this pin.

And the last pin P92 was connected to the SuperIO UART’s level shifter (MAX3242). I had to desolder the chip because P92 was driven by the level shifter.

Near the EC are 2 testpoints which are connected to an I2C bus. I soldered these too, because an I2C could be useful.

1 P91
2 GND
3 md1
4 /RESET
5 RX
6 TX
7 I2C SDA
8 I2C SCL
+
1 patch cable with a 3.3V + 1k Resistor (for P91).

So far so good. But somehow it doesn’t work. Some pins doesn’t have the right level. P92 doesnt have 3.3V. Why not?
P92 is pulled up via a resistor to VCC of the TTL shifter. The VCC isn’t powered. I need to resolder it to another 3.3V pin somewhere and take another look
on the other levels too.

PS. Some work was already done before GSoC started. I posted the first part of soldering on my blog

Report on Chrome OS upstreaming

In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other.

In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers.

As a result, upstream benefits from lots of new features and hardware support that was introduced during Chrome OS development, some of which warrant a shout out:

First, new hardware support: There’s MIPS support, and on the ARM side we now run on SoCs by Broadcom, Marvell, Qualcomm, and RockChip.

In terms of infrastructure, the biggest single item that came up during upstreaming is probably a safe method to declare the memory map on devices. Compared to x86, most architectures that prospered in embedded applications have a more complicated view on memory, so more care is required there.

Looking at files like src/soc/nvidia/tegra132/include/soc/memlayout.ld, it becomes clear what kind of memory is available for which purpose on that SoC.

In addition to that, there are efforts to make Chrome OS’ verified boot available as an option in upstream coreboot, and also to update the flash image format to allow for safer incremental updates.

One thing to note is that significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip. Welcome to coreboot!

In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented.

GSoC 2015 H8S EC firmware

Hi community,

I’m Alexander Couzens on the list and in IRC known as lynxis. I’ve experience with embedded Linux and hardware integration of wireless devices using OpenWrt. I started modifying my vendor BIOS several years ago because my brand new Lenovo X201t didn’t allow me to use good wireless cards because it checked all pci networks devices against a white list. After my mainboard was replaced I had to do the same modification again or install coreboot. Of course I went for coreboot 🙂 While installing coreboot I also started developing it, my GSoC is the H8S Embedded Controller firmware. The EC controls a lot of things in your laptop. An EC controls the battery charging and discharging, the keyboards, docking and undocking, multiple sensors, thermals sensors, fan, lid switch and power regulators.

Continue reading GSoC 2015 H8S EC firmware

[GSoC-2015] Introduction – End user flash tool

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

[GSoC-2015] Introduction – Qemu Support for ARM64

Moin!

A new post after a long time. I’ll introduce myself again for the benefit of (few? :P) faded memories. I am Naman, a senior year undergraduate from India. I worked on developing alternate resource-efficient CBFS access patterns for ARM SoCs as a part of GSoC-2014. I am fortunate enough to engage as a GSoC student for coreboot this year too. I have had a busy semester but finally, as the summers arrive, I look forward to dive into the riveting world of coreboot hacking!

This summer I would be working to introduce a qemu target for arm64 architecture supporting coreboot. Currently, In order to work on aarch64, users require to have suitable hardware. This project intends to clear away this constraint. We have a growing aarch64 support with the tegra132 port, but no support for arm64 in emulation. Having a qemu target might be helpful for many projects which aim to arm64 work.

Continue reading [GSoC-2015] Introduction – Qemu Support for ARM64