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

[Marcos Scriven]

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 <[e-mail]> 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/relea...
>
> Config:
> https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238351...
>
> Build script:
> https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238351...
>
> Build log:
> https://travis-ci.org/marcosscriven/chromebook-coreboot/builds/111222889#L20...
>
> (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.
>
> 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...
>
> 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_...
>
> 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-dev...
>
> 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