coreboot on UPsquared

Goetz SalzmannGoetz Salzmann Posts: 29New Member
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.

Comments

  • Michael MillerMichael Miller Posts: 93New Member
    This project interests me. Other then being open, what is the benefits of this BIOS implementation?
  • Goetz SalzmannGoetz Salzmann Posts: 29New Member
    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 SalzmannGoetz Salzmann Posts: 29New Member
    edited July 2017
    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 MillerMichael Miller Posts: 93New Member
    Very cool. When you say faster boot, how much faster are we talking?
  • Goetz SalzmannGoetz Salzmann Posts: 29New Member
    And we are able to boot linux!

    Ubuntu 16.04 from an USB stick.

    FreeBSD and OpenBSD still hang, probably broken ACPI tables.
  • Goetz SalzmannGoetz Salzmann Posts: 29New Member
    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 SalzmannGoetz Salzmann Posts: 29New Member
    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.
  • Cz3103Cz3103 Posts: 2New Member

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

  • Javier ArteagaJavier Arteaga Posts: 163Emutex mod

    Hi Cz3103,

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

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

  • dickgidickgi Posts: 1New Member

    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.

Sign In or Register to comment.