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:
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@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@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.
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:
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?
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