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: > 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 > > 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? 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. After running flashrom, the machine appears always to reboot. The Cr50 console says: [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 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. 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*? Thanks James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
