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
