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 <[email protected]> wrote: > > ---------- Forwarded message --------- > From: Marcos Scriven <[email protected]> > Date: Tue, 23 Feb 2016 at 15:46 > Subject: Re: Issues building a ROM for Toshiba Chromebook 2 (aka Swanky) > To: <[email protected]> > > > 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 <[email protected]> > 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@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/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 >> > >
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
