I have a Baytrail Chromebox (ninja) and ran into the same issues, but
unlike swanky it has an intact debug port. I was supposed to get a
servo unit on loan from one of the google coreboot guys but lost track
with the holidays. I'll have to follow up on it as it's probably the
best bet for getting a full replacement firmware working on Baytrail
On 2/23/2016 5:31 PM, Marcos Scriven wrote:
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]
<mailto:[email protected]>> wrote:
---------- Forwarded message ---------
From: Marcos Scriven <[email protected] <mailto:[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] <mailto:[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] <mailto:[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
