[coreboot] Issues building a ROM for Toshiba Chromebook 2 (aka Swanky)
Marcos Scriven
marcos at scriven.org
Tue Feb 23 16:46:50 CET 2016
Sorry to follow up so soon - but just noticed an error in my post. I meant
*fallback/refcode *not *fallback/romstage, *which although still slightly
different in size was at least built rather than extracted and re-inserted,
and is at the same offset as the original.
On Tue, Feb 23, 2016 at 3:41 PM, Marcos Scriven <marcos at scriven.org> wrote:
> 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/7b07afc6/attachment-0001.html>
More information about the coreboot
mailing list