On Thu, Jul 22, 2021 at 3:56 PM James Feeney <ja...@nurealm.net> wrote: > > On 7/3/21 8:22 AM, Matt DeVillier wrote: > > Thanks for that. > > > I don't see the command you used to flash -- what was that? You also > > didn't clear the WP range (flashrom --wp-range 0,0) which has > > historically been needed on small core/Atom boards, but if you didn't > > get an error flashing/erasing then you're probably fine. > > >> $ flashrom -p host -l layout.txt -i BIOS -w coreboot.rom > > The write-protect range was already 0,0, so I didn't bother with setting that. > > > display backlight means it's booted to ramstage, since that's where > > FSP-S will init the backlight. It most likely means coreboot ran > > successfully and the payload is the issue. > > > > How to debug? Get yourself a Suzy-Q cable, rebuild with the serial > > console enabled, flash via Suzy-Q, and then monitor via the > > /dev/ttyUSB1 serial port (CPU UART) > > > > see: > > https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md > > https://wiki.mrchromebox.tech/Unbricking#Unbricking.2FFlashing_with_a_Suzy-Q_cable > > > > I finally received a SuzyQable. There was a supply issue. > > And, after lots of reading at > > https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md > > and related, followed by a bit of trial and error, and then observing the AP > console, the boot sequence ends with > > ... > CBFS: Found 'fallback/payload' @0xf2d00 size 0x3ce03 > Checking segment from ROM address 0xffc3402c > Checking segment from ROM address 0xffc34048 > Loading segment from ROM address 0xffc3402c > code (compression=1) > New segment dstaddr 0x01110000 memsize 0x8ccd4 srcaddr 0xffc34064 filesize > 0x3cdcb > Loading Segment: addr: 0x01110000 memsz: 0x000000000008ccd4 filesz: > 0x000000000003cdcb > using LZMA > Loading segment from ROM address 0xffc34048 > Entry Point 0x01110015 > BS: BS_PAYLOAD_LOAD run times (exec / console): 147 / 46 ms > CSE FWSTS1: 0x80000245 > CSE FWSTS2: 0x30850000 > CSE FWSTS3: 0x00000000 > CSE FWSTS4: 0x00080000 > CSE FWSTS5: 0x00000000 > CSE FWSTS6: 0x40000000 > ME: Manufacturing Mode : NO > ME: FPF status : fused > Putting xHCI port 0 into host mode. > xHCI port 0 host switch over took 0 ms > BS: BS_PAYLOAD_LOAD exit times (exec / console): 17 / 28 ms > mp_park_aps done after 0 msecs. > Jumping to boot code at 0x01110015(0x79b38000) > > > And then - nothing - other than that the screen backlight comes on. > > So yes, as you say, seems like coreboot works, and my u-boot does not. > > > > if you want to try a tested/verified prebuilt image w/Tianocore > > payload, you can use: > > https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_20210621.rom > > https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_20210621.rom.sha1 > > > > > Compiling flashrom from from both > > git clone https://chromium.googlesource.com/chromiumos/third_party/flashrom > WARNERROR=no CONFIG_MEC1308=no CONFIG_ENE_LPC=no make > > and > > git clone > https://chromium.googlesource.com/chromiumos/platform/standalone-hdctools > flashrom install > > which seem to act the same, and then running > > sudo ./flashrom -p raiden_debug_spi:target=AP > > 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 > > Hmm. Nothing I can do until this is made to work. > > While waiting for the SuzyQable, I had tried reading the flash memory with > the TUMPA flash programmer. No joy. I suppose it is possible that I may > have burned-out something on the Chromebook board. However, this seems > highly unlikely, because the AP can still boot from the flash memory, and > because of the apparent circuit layout. While I do not have a schematic for > this Samsung Chromebook 4, listening to > > OSFC 2018 - Google Secure Microcontroller and CCD | Vadim Bendebury > Oct 2, 2018 > https://www.youtube.com/watch?v=gC-lbMNmIsg > > and noting particularly the block diagram in slide 9, from > > https://2018.osfc.io/talks/google-secure-microcontroller-and-ccd-closed-case-debugging.html > https://2018.osfc.io/uploads/talk/paper/7/gsc_copy.pdf > > - the "AP PROG" AND "EC PROG" labels on H1 are backwards - it very much > appears that both the AP and the Google H1 security chip access the AP flash > through a separate multiplexer chip of some kind. As best as I can tell, > there is a kind of multiplexer *internal* to the H1, as seen in slide 2, > which connects the GPIO pins to the internal hardware protocol blocks, and > another *external* multiplexer that separates the AP and EC SPI buses. Any > overloads, applied from attaching a flash programmer to the flash memory, > would seem likely to have effected access to flash memory equally, by *both* > the H1 and the AP. And that is not the case here. It also seems unlikely > that the SPI circuitry would have been built without any kind of circuit > protection. But again, I have not seen the actual circuit schematic. Still, > it would be a very odd kind of circuit failure to have damaged the opposite > end of only one multiplexer port. I also note that the operation of the > Cr50, AP, and EC consol es seems entirely as might be expected. > > So Matt - question: Have you been able read the AP flash memory of an actual > Samsung Chromebook 4, model XE350XBA-K01US, using a SuzyQable? 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. > > If you have actual experience with the Samsung Chromebook 4, then I must > infer that I've broken the hardware. That would be possible if the GoldLake > CPU and H1 SPI bus lines were really connected together directly, without any > separate multiplexer chip. Otherwise, I am inclined to question this version > of flashrom. For instance, I notice that the Cr50 console reports explicitly > > [10398.332186 enable_spi_pinmux: AP] > > and, after access, > > [10398.445490 usb_spi_board_disable] > [10399.512358 AP UART on] > [10399.514036 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX] > > but never explicitly says "usb_spi_board_enable" - though I have no idea if > that means anything. > > Still, it seems possible that Cr50 may be able to read the AP flash memory, > but then "hides" the output because of some "security" mechanism, or that > this version of flashrom is having some kind of Cr50 communication problem, > giving all 1's. It is also remotely possible that Cr50 has an SPI software > bug. SPI is a little weird in that the clock polarity and the clock phase, > with respect to reading data, varies from manufacturer to manufacturer. The > clock has to be exactly right for this GD25LQ128D chip. > > Clearly, coreboot itself is having no trouble reading boot flash memory. I > wonder if the same is true for my version of u-boot. I expect that u-boot > has to have its own SPI driver for AP flash memory? Or, does coreboot just > load the payload to RAM, and then that's the end of boot flash access? the latter :) > > Any thoughts? > > Thanks > James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
