[coreboot] Issues building a ROM for Toshiba Chromebook 2 (aka Swanky)

[Marcos Scriven]

Hi all

I've built a ROM for swanky which just results in a brick, and wondering if
anyone else has had success with this (or any Bay Trail Chromebook), or
could otherwise provide guidance please.

I've been able to reprogram the ROM directly, and am working with a patched
boot stub region for now. I'm happy to experiment with ROM builds that will
brick the machine (though annoyingly on the Toshiba Chromebook 2 the
Winbond chip is just a little too close to the shielding/heatsink, so I
have to take that off too (sadpanda)).

Some links for context:

ROM build artifact:
https://github.com/marcosscriven/chromebook-coreboot/releases/download/release-1456238351/swanky.rom

Config:
https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238351/build/boards/swanky/.config

Build script:
https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238351/build/build_rom.sh

Build log:
https://travis-ci.org/marcosscriven/chromebook-coreboot/builds/111222889#L2001


(NB The build log is for multiple boards, and includes other full and boot
stub builds, so use the log link above to the line where the full swanky
rom build starts.)

Here's the layout for the custom build:


*vagrant at vagrant-ubuntu-trusty-64:~$ cbfstool swanky.rom print*
*swanky.rom: 8192 kB, bootblocksize 1184, romsize 8388608, offset 0x700000*
*alignment: 64 bytes, architecture: x86*

*Name                           Offset     Type         Size*
*cmos_layout.bin                0x700000   cmos_layout  1164*
*pci8086,0f31.rom               0x7004c0   optionrom    65536*
*cpu_microcode_blob.bin         0x710500   microcode    104448*
*config                         0x729d80   raw          4555*
*fallback/refcode               0x72af80   stage        4171*
*etc/boot-menu-key              0x72c040   raw          1*
*etc/boot-menu-message          0x72c0c0   raw          27*
*(empty)                        0x72c140   null         15896*
*fallback/romstage              0x72ff80   stage        35475*
*fallback/coreboot_ram          0x738a80   stage        74547*
*fallback/payload               0x74ae00   payload      103192*
*(empty)                        0x764180   null         245272*
*mrc.bin                        0x79ffc0   spd          70168*
*(empty)                        0x7b1240   null         240984*
*spd.bin                        0x7ebfc0   spd          1024**(empty)
                 0x7ec400   null         79576*


And here's the layout for a backup made via SPI directly on the chip
(Implied *0x700000 *offset):

*vagrant at vagrant-ubuntu-trusty-64:~$ cbfstool swanky-by-spi.bin print -r
BOOT_STUB*
*Performing operation on 'BOOT_STUB' region...*
*Name                           Offset     Type         Size*
*cmos_layout.bin                0x0        cmos_layout  1164*
*pci8086,0f31.rom               0x4c0      optionrom    65536*
*cpu_microcode_blob.bin         0x10500    microcode    104448*
*config                         0x29d80    raw          5259*
*fallback/vboot                 0x2b240    stage        15518*
*(empty)                        0x2ef40    null         4120*
*fallback/romstage              0x2ff80    stage        36458*
*fallback/coreboot_ram          0x38e80    stage        82415*
*fallback/refcode               0x4d0c0    stage        4296*
*fallback/payload               0x4e1c0    payload      67396*
*u-boot.dtb                     0x5e940    mrc_cache    4842*
*(empty)                        0x5fc80    null         258840*
*mrc.bin                        0x9efc0    spd          70168*
*(empty)                        0xb0240    null         245080*
*spd.bin                        0xebfc0    spd          1024*
*(empty)                        0xec400    null         78360*


The labels, offsets, types, and sizes of all the various blobs looks fine
*except fallback/romstage**.* (vboot and u-boot are gone as I don't need
verification, which worked fine for my wolf build.)

I'm not sure why my build (from the same commit hash of Google's coreboot
fork as in the config extracted from original rom) is placing that blob at
a different offset? I can't see anything in the config that would affect
that.

The more troubling thing is my refcode is a little smaller! I've extracted
it from the shellball with this method here:
https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238351/build/util/extract_blobs.sh#L56

So far as I can tell *fallback/refcode *is a (U)EFI blob, the failure of
which I'd imagine would result in not booting from disk, but not entirely
sure it's the reason I seeing nothing at all.

I guess the thing I'd find most helpful is guidance on *how to debug this*
myself? Only two things I could find:

1) A mention of 'USB to USB' in a 2013 Coreboot presentation:
https://docs.google.com/presentation/d/1eGPMu03vCxIO0a3oNX8Hmij_Qwwz6R6ViFC_1HlHOYQ/edit#slide=id.gf4036fef_0177

It's not entirely clear how this works - so far as I can tell it's
essentially USB OTG, where the Chromebook USB port could act as a client. I
don't see though how the CPU sets that up before the ROM code even runs,
unless it's some microcode in the processor itself?


2) I've also seen mention of Servo, but I don't seen any such header on my
board. Looking at a photo of the Acer C720 here, it does look like there's
an oblong space with pads there, but that would be a hell of a surface
mounting job:
https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook


I hope I've provided sufficient background info, but if anyone's willing or
able to help, I'd of course be happy to add more detail.

Thanks

Marcos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160223/1743b9d2/attachment.html>