coreboot on UPsquared

Goetz Salzmann

Hi,

we, a college of mine and I, are trying to get coreboot to work on the UPsquare.

There is an Intel CRB Leafhill, that uses the same SoC.

Unfortunately we are stuck in FSP/memory init. As the board uses memory down,
there is no SPD eeprom.

Our attempts to reverse the MRC / memory parameters where not successful.
The SMBIOS data is totaly wrong. (e.g. it claims the RAM would be LPDDR3).

Could you please provide some documentation on
- how does the BIOS detect the amount/kind of memory used
- how is the FSP/MCR configured?
(- any suggestion on the FSP version to use?)

More questions to follow, once we got past this problem.


Some additional information, for the forums.

We use a Dediprog SF100 with a Pomona-clip. Using 1.8v levels, it works find
to read / flash die SPI chip, while the board is disconnected from power.

While Leafhill uses a different UART for debugging, we where able to change
the UART in coreboot/FSP.

Michael Miller

This project interests me. Other then being open, what is the benefits of this BIOS implementation?

Goetz Salzmann

You can read up about coreboot on coreboot.org

Beside being open, coreboot is much less code, compared to a complete UEFI implementation.
While UEFI already is very fast to boot, coreboot still is faster.

My reason for porting coreboot to UPsquared is less code, parts of this code is available as source and with less code you get less danger of having hidden bugs.

e.g. the stock UPsquared BIOS ist 16MB, our current coreboot image is 8MB, and has still space available. You could fit a complete Linux into the remaining space. But I don't care for linux ;-)

Goetz Salzmann

After 3 days, we finally made some progress.

In order to get coreboot to work, we have to reverse the memory configuration. The board uses memory down and has no SPD eeprom with the DDR configuration.

We did all our work on a Kickstarter edition 4C/4GB board. We also have a 2C/2GB board, but we will look at that later.

We were able to dump most of the relevant memory controller registers from the stock bios using EFI shell.

But the swizzling information was not accessible.

The memory controller of Apollo Lake can map each of the 32 supported functions to any of the 32 lanes, for each of the 4 channels.

These are just 32! * 4 or 2.631308369E35 * 4 possibilities.

This would take too long ;-)

But we realized that the BIOS update is neither compressed nor encrypted.

From the coreboot source we knew that all 4 channels are configured with
4 consecutive arrays with 32 bytes each. Each of these bytes can have a value
of 0x00 to 0x1f, and every value must be present.

bluerise and dloss started a coding battle and we were able to narrow it down to 4 possible sets of variations.

In the end these are the swizzle settings:

Channel 0:
    0x0d, 0x0a, 0x08, 0x0b, 0x0c, 0x0f, 0x0e, 0x09, 
    0x06, 0x00, 0x03, 0x04, 0x07, 0x01, 0x05, 0x02, 
    0x1c, 0x1a, 0x19, 0x1b, 0x1d, 0x1f, 0x1e, 0x18, 
    0x10, 0x17, 0x15, 0x16, 0x14, 0x12, 0x13, 0x11
Channel 1:
    0x00, 0x07, 0x04, 0x05, 0x06, 0x02, 0x03, 0x01, 
    0x08, 0x0f, 0x0d, 0x0b, 0x0a, 0x09, 0x0e, 0x0c, 
    0x17, 0x11, 0x13, 0x12, 0x14, 0x15, 0x16, 0x10, 
    0x1c, 0x1a, 0x1d, 0x1f, 0x18, 0x19, 0x1e, 0x1b
Channel 2:
    0x0d, 0x08, 0x0b, 0x0e, 0x0c, 0x0f, 0x09, 0x0a, 
    0x04, 0x07, 0x01, 0x06, 0x02, 0x03, 0x00, 0x05, 
    0x18, 0x19, 0x1c, 0x1a, 0x1d, 0x1e, 0x1f, 0x1b, 
    0x11, 0x13, 0x15, 0x10, 0x16, 0x12, 0x17, 0x14
Channel 3:
    0x00, 0x05, 0x04, 0x07, 0x03, 0x02, 0x06, 0x01, 
    0x0a, 0x0b, 0x08, 0x09, 0x0c, 0x0e, 0x0d, 0x0f, 
    0x12, 0x16, 0x14, 0x13, 0x17, 0x11, 0x15, 0x10, 
    0x19, 0x1f, 0x1d, 0x1b, 0x1e, 0x18, 0x1c, 0x1a

With that we are able to pass the MRC init, but still have some work to do.

Most of the coreboot work was done by Suresh Bhudur, who is working with our company since last month.

Michael Miller

Very cool. When you say faster boot, how much faster are we talking?

Goetz Salzmann

And we are able to boot linux!

Ubuntu 16.04 from an USB stick.

FreeBSD and OpenBSD still hang, probably broken ACPI tables.

Goetz Salzmann

We still use the debug version of almost everything, it currently takes about 4 min to boot to Linux.

But the official BIOS is already very fast, when you want to boot Windows/Linux.

Our goal is to evaluate secure boot, and not speed. But at some point we will have a look at fast(er) boots.

Goetz Salzmann

Continuing work on coreboot, today.

And documenting the finding.

We have two boards, probably both Innovator boards.

One with a Pentium N4200 and 4GB and one with a Celeron N3350 and 2GB RAM.

To figure out how much memory the board has, UP uses two GPIOs (GPIO_214, GPIO_215) for DDR_ID0/DDR_ID1.



[th]ID0[/th]
[th]ID1[/th]
[th]Memory[/th]


0
0
2GB


0
1
4GB


1
0
8GB


1
1
unknown



Next up is figuring out, what channels are used.

Cz3103

Hi, may I know how you connect the pin for bios flashing? I got some trouble

Javier Arteaga

Hi Cz3103,

There's some documentation available on the wiki on BIOS flashing procedure:

• UP
• UP Squared

Of course, please proceed with caution. I hope that helps!

dickgi

Just wondering what the latest status is of getting coreboot to work on the UP2? I am considering using this platform and it would be nice if there was an easy way to boot to Linux.

siro

Hi,
I bought the platform as it is possible to run coreboot on it.
Can you please give access to the sources ?

Do you plan to upstream your code ? If not I can help adding upstream coreboot support.

pietrushnic

@siro,
did you get any reply?

I'm also interested in supporting coreboot mainlining, so if any code will be available on gerrit please add me to reviewers.

pietrushnic

Some time ago I had a conversation related to porting that hardware on Twitter.

hramazan

Goetz Salzmann I'm working about coreboot and have some problem about memory init. Could you help me? Here you can see my problem and where exactly i stucked.