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/ca... https://wiki.mrchromebox.tech/Unbricking#Unbricking.2FFlashing_with_a_Suzy-Q...
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/ca...
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_2021062... https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_2021062...
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.
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... 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 consoles 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?
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?
Any thoughts?
Thanks James