New subject: Issues building a ROM for Toshiba Chromebook 2 (aka Swanky)

24 Feb 2016

      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 <marcos@scriven.org 
mailto:marcos@scriven.org> wrote:
---------- Forwarded message ---------
From: Marcos Scriven <marcos@scriven.org <mailto:marcos@scriven.org>>
Date: Tue, 23 Feb 2016 at 15:46
Subject: Re: Issues building a ROM for Toshiba Chromebook 2 (aka
Swanky)
To: <coreboot@coreboot.org <mailto:coreboot@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@scriven.org <mailto:marcos@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@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

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