[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

GSoC 2015 Introduction – Nicky Sielicki

Hey coreboot community!

My name is Nicky Sielicki. I’m one of our Google Summer of Code 2015 participants. I’m a sophomore, err– I guess now I’m a junior, at the University of Wisconsin. You can read personal details about me at nicky.io, or maybe get to know me– I’m n1cky on freenode! Come say hello.

I’ve been hanging around the coreboot community for about 6 months or so after learning about coreboot from a 2008 GoogleTechTalks video about coreboot and why it’s awesome. I purchased a chromebook in hopes of playing around with coreboot and learning something. Over my winter break, I spent a lot of time reading, flashing unsuccessfully, and understanding more about coreboot.

Continue reading GSoC 2015 Introduction – Nicky Sielicki

On coreboot leadership…

Dear coreboot community!

I want to wholeheartedly thank every single one of you, who has contributed code to the coreboot project, reviewed code, improved our documentation in the wiki, or has contributed to the project by other means. You all have helped create a truly great project.

In 2014 alone, more coreboot devices have shipped than in all previous years combined! Since the start of coreboot v2 in 2003, 345 contributors have put over 12 thousand commits, an estimated effort of 457 years (COCOMO model) into the project. Since 2010, we have added support for all new Intel mobile and AMD R and G series processors. In the last year alone, we have added support for ARM/ARM64 SOCs from 7 vendors and, support for the MIPS and RISC-V architecture.

Continue reading On coreboot leadership…

coreboot GSoC 2015

coreboot has been accepted as a mentoring organization for GSoC 2015! We are accepting student applications for coreboot, flashrom, and SerialICE projects.

Students:  Welcome! Please review the coreboot GSoC page and Project Ideas page. Student applications formally open on 16 March at 19:00 UTC.

Mentors:  Please signup in Melange and request to join the coreboot project. You must signup for 2015, even if you already have a Melange account. You may also find the GSoC Mentor Guide helpful.

Community:  Please recruit and welcome prospective students to the organization. You may provide ideas on the Projects Page.