[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen

[Matt DeVillier]

On Thu, Jul 22, 2021 at 7:29 PM James Feeney  wrote:
> On 7/22/21 3:53 PM, Matt DeVillier wrote:
> ...
> > > I get "No EEPROM/flash device found".  Running with -V, I see flashrom is just reading all 1's.
> >
> > you need to open the CCD first. With the battery disconnected, from a
> > terminal attached to /dev/ttyUSB0, run:
> > ccd open
> > ccd reset factory
> > ccd
> >
> > that should show the ccd state as open, with all capabilities in
> > column 1 set to 'Y'.
> >
> > then flashrom will be able to detect / read / write the flash chip
>
> I believe that I have already done all of that.  But please, check to see if I know what I'm doing here:

LGTM
> > ccd
>
> State: Opened
> Password: none
> Flags: 0x400005
> Capabilities: 5555555555000000
>   UartGscRxAPTx   Y 1=Always
>   UartGscTxAPRx   Y 1=Always
>   UartGscRxECTx   Y 1=Always
>   UartGscTxECRx   Y 1=Always
>   FlashAP         Y 1=Always
>   FlashEC         Y 1=Always
>   OverrideWP      Y 1=Always
>   RebootECAP      Y 1=Always
>   GscFullConsole  Y 1=Always
>   UnlockNoReboot  Y 1=Always
>   UnlockNoShortPP Y 1=Always
>   OpenNoTPMWipe   Y 1=Always
>   OpenNoLongPP    Y 1=Always
>   BatteryBypassPP Y 1=Always
>   UpdateNoTPMWipe Y 1=Always
>   I2C             Y 1=Always
>   FlashRead       Y 1=Always
>   OpenNoDevMode   Y 1=Always
>   OpenFromUSB     Y 1=Always
>   OverrideBatt    Y 1=Always
> read_tpm_nvmem: object at 0x100a not found
> [50.223548 Console unlock allowed]
> read_tpm_nvmem: object at 0x1007 not found
> TPM:
> Capabilities are modified.
> Use 'ccd help' to print subcommands
> > ccd testlab
>
> CCD test lab mode enabled

I've never used testlab mode, looks like it just disables the need for
physical presence so shouldn't be an issue
> > see above, the ccd being closed w/default capabilities set is
> > preventing the flash chip from being visible/read/written.
> >
> > I've used ccd to read/write many an AP flash, including APL/GLK Chromebooks.
>
> Including a Samsung octopus board?  Samsung didn't "cut corners" on the design implementation?

Not a Samsung one, but considering they are all built from the same
reference board, it's unlikely Samsung somehow broke CR50 AP access.
Then again, they did manage to screw up the HPET (among other things)
on CELES. Still, I would consider that a pretty low possibility. I
have an Asus octopus/AMPTON board here that I've flashed 100x via ccd.
> I'm hoping very much that the problem is something simple.  But still:
>
> $ sudo ./flashrom -p raiden_debug_spi:target=AP
> flashrom abb3b091 on Linux 5.12.14-arch1-1 (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> Raiden target: 2
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.

that's definitely the issue, I'm just not sure offhand what else could
cause the AP flash to not be available.
> After running flashrom, the machine appears always to reboot.  The Cr50 console says:

this is expected, since the CR50 switches modes to enable flash
access. It will reboot when exiting SPI mux mode regardless of the
flash operation.
> [631.035522 enable_spi_pinmux: AP]
> [631.106361 usb_spi_board_disable]
> [631.668071 AP UART on]
> [631.669563 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX]
> [631.884475 deferred_tpm_rst_isr]
> [631.885501 AP on]
> [631.886077 tpm_reset_request(0, 0)]
> [631.886932 tpm_reset_now(0)]
> [631.890377 tpm_init]
> tpm_manufactured: manufactured
> [631.892402 tpm_reset_now: done]
> [632.031471 AC: R-]
>
> Are there any other things to try, before heating-up the soldering iron?  Is there any way to cross-check what flashrom is seeing?  Is there any way for Cr50 to directly access the AP boot flash memory itself and then report through the Cr50 console, without involving flashrom?

I don't believe so, someone from Google would likely be able to better answer
> I see something called "spihash", which gives:
> > spihash ap
>
> [1396.457412 enable_spi_pinmux: AP]
> [1396.460723 spi_hash_pp_done: AP]
> >
>
> Then, there is a delay, followed spontaneously by:
>
> [1456.460903 spi_hash_disable]
> [1457.020969 AP UART on]
> [1457.022476 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX]
> [1457.237365 deferred_tpm_rst_isr]
> [1457.238426 AP on]
> [1457.239028 tpm_reset_request(0, 0)]
> [1457.239898 tpm_reset_now(0)]
> [1457.243381 tpm_init]
> tpm_manufactured: manufactured
> [1457.245449 tpm_reset_now: done]
> [1457.384220 AC: R-]
>
> It doesn't look like "spihash ap" is returning anything.  But then, from what little I've been able to find, the hash is only suppose to perform some kind of security validation.  And "spihash ec" acts about the same.

never used those functions / not familiar, but assume they are vboot related
> As to the "broken hardware" theory, have you ever heard of anyone attaching a flash programmer to a Google octopus board and successfully reading flash memory content *in circuit*?

never tried since CCD option is available, but in theory it should be possible.
> Thanks
> James