[coreboot] Issues building a ROM for Toshiba Chromebook 2 (aka Swanky)
Marcos Scriven
marcos at scriven.org
Wed Feb 24 00:31:38 CET 2016
I've subsequently discovered that USB debugging requires EHCI, and sadly
lspci yields no such debug capabilities. Presumably this means either I
figure out what's wrong 'blind', or start soldering a servo port?
On Tue, 23 Feb 2016 at 23:30, Marcos Scriven <marcos at scriven.org> wrote:
>
> ---------- Forwarded message ---------
> From: Marcos Scriven <marcos at scriven.org>
> Date: Tue, 23 Feb 2016 at 15:46
> Subject: Re: Issues building a ROM for Toshiba Chromebook 2 (aka Swanky)
> To: <coreboot at coreboot.org>
>
>
> 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/8accfd13/attachment.html>
More information about the coreboot
mailing list