[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen
ok! One problem identified and resolved - the "No EEPROM/flash device found." It turns-out that no on-board circuitry was damaged in connecting the external flash programmer. Instead, this Samsung Chromebook 4, model XE310XBA-K01US, revision 1.0 motherboard, is *missing* the four series resistors connecting the H1B2C Google Security Chip to the GigaDevice 25LQ128D boot flash memory device. Consequently, the Serial-Out line always remains in the pulled-up high state, and the GSC sees all 1's. Only the Gemini Lake SOC SPI bus is connected to the boot flash device. The simplest solution is to solder-bridge the pads for these 0402 size resistors, which then allows Closed Case Debugging to function as expected. More generally, it seems that manufacturer implementations of Google reference designs can be quite variable. Some boards do not include the separate SPI bus multiplexer chip shown in presentations on the GSC, and instead, directly connect the GSC and SOC tri-state GPIO lines and provide pull-up resistors. And, as in this case, some manufacturers do not even connect the GSC to the boot flash memory device. As I understand, manufacturers are not suppose to leave the GSC disconnected from the SPI bus to the flash device. However, also, apparently there are no legal constraints associated with the "Chromebook" trade name requiring Closed Case Debugging to be functional. It would be useful to keep track of these "problem" Chromebooks. I haven't discovered the cause of my difficulty with the external flash programmer. I note that the Not-Write-Protect and Not-Hold lines are not part of the basic 4-wire SPI bus, and I have not found documentation about how these lines are driven. It may be that their default state depends upon the Closed Case Debugging permissions. But now, with CCD working, the external programmer is not needed. So, I can get back to debugging my u-boot payload. James ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen
On 7/23/21 1:58 PM, Matt DeVillier wrote: >> Ironically, the inability to attach a flash programmer in-circuit to a >> Chromebook having Google's H1 security chip represents a kind of security >> failure. Specifically, how is the boot flash content to be verified with >> the certainty that the true content has not been hidden by Cr50, or by, for >> instance, flashrom running from eMMC root, when the AP is used to read the >> boot flash? > Inability? due to it being a WSON-8 chip or? Every Chromebook since > ~2013 has supported ISP, AFAIK. And up until recently, most used a > clippable SOIC-8 chip. > Lucky for me, the Chromebook 4 still uses the SOP8 208MIL package. Or, it might be argued, unlucky for me, that I would bother the boot flash chip. "Inability" only based upon the theory that maybe the Chromebook multiplexer was damaged when I connected the TUMPA to the flash chip. Of course, I still don't really know what the problem is. It might be the result of the way I connected the TUMPA - operator error. It may be that this Chromebook was already defective upon receipt. Or, there may be some obscure bug in my current build of Google flashrom. Or, it might just be some unlucky unlikely random hardware glitch. So, "inability" may be inappropriate here, and I'm in a mood, feeling frustrated. But I do appreciate your help. Something will work out - one step at a time. James ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen
On Fri, Jul 23, 2021 at 12:13 PM James Feeney wrote: > > On 7/23/21 8:07 AM, Matt DeVillier wrote: > > Thanks for your review. > > >> 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 > > > > That seems like shortsightedness from Google, not providing some kind of > internal test/verification function for some hardware I/O. > > >> 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. > > > > Hmm - tentatively, it might be useful to other people to offer the advise > "NEVER attach an in-circut flash programmer to an octopus board!" I don't > know that anyone would want to actually test this conjecture with their own > hardware. It looks like I may have to buy the service manual from Samsung, > but they refuse to tell me whether it includes the schematics. > > Ironically, the inability to attach a flash programmer in-circuit to a > Chromebook having Google's H1 security chip represents a kind of security > failure. Specifically, how is the boot flash content to be verified with the > certainty that the true content has not been hidden by Cr50, or by, for > instance, flashrom running from eMMC root, when the AP is used to read the > boot flash? Inability? due to it being a WSON-8 chip or? Every Chromebook since ~2013 has supported ISP, AFAIK. And up until recently, most used a clippable SOIC-8 chip. > > It cannot be verified. The only alternative is to unsolder the flash chip, > and read it externally. Of course, if Cr50 has been compromised, verifying > boot flash may not matter. But then, in the end, this is Google's "Security > by Obscurity - just hide it in hardware" strategy, since I don't know that > there is any way to verify the Cr50 code running in the H1 chip. You'd think > that, by now, people would have given-up on the "Security by Obscurity" > strategy - but I suppose that marketing and management have still not > caught-up, gotten the memo, whatever - "Intellectual Property Rights", "Trade > Secrets", "National Security", blah, blah, blah. > > Also ironically, the actual cost to provide circuit protection for in-circuit > flash programming is approximately "zero" - the cost of a few resistors and > maybe a diode. I found this interesting: > > "Integrity Enhancements for Embedded Linux Devices", David Safford > https://selinuxproject.org/~jmorris/lss2013_slides/safford_embedded_lss_slides.pdf > > It looks like the maximum current on a typical ARM SC300 GPIO, as used for > the H1, is about 4mA. Compare this to the maximum current available from a > typical buffer output, as from a flash programmer, of about 50mA, if these > circuits were to be directly connected. > > > > James ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen
On 7/23/21 8:07 AM, Matt DeVillier wrote: Thanks for your review. >> 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 > That seems like shortsightedness from Google, not providing some kind of internal test/verification function for some hardware I/O. >> 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. > Hmm - tentatively, it might be useful to other people to offer the advise "NEVER attach an in-circut flash programmer to an octopus board!" I don't know that anyone would want to actually test this conjecture with their own hardware. It looks like I may have to buy the service manual from Samsung, but they refuse to tell me whether it includes the schematics. Ironically, the inability to attach a flash programmer in-circuit to a Chromebook having Google's H1 security chip represents a kind of security failure. Specifically, how is the boot flash content to be verified with the certainty that the true content has not been hidden by Cr50, or by, for instance, flashrom running from eMMC root, when the AP is used to read the boot flash? It cannot be verified. The only alternative is to unsolder the flash chip, and read it externally. Of course, if Cr50 has been compromised, verifying boot flash may not matter. But then, in the end, this is Google's "Security by Obscurity - just hide it in hardware" strategy, since I don't know that there is any way to verify the Cr50 code running in the H1 chip. You'd think that, by now, people would have given-up on the "Security by Obscurity" strategy - but I suppose that marketing and management have still not caught-up, gotten the memo, whatever - "Intellectual Property Rights", "Trade Secrets", "National Security", blah, blah, blah. Also ironically, the actual cost to provide circuit protection for in-circuit flash programming is approximately "zero" - the cost of a few resistors and maybe a diode. I found this interesting: "Integrity Enhancements for Embedded Linux Devices", David Safford https://selinuxproject.org/~jmorris/lss2013_slides/safford_embedded_lss_slides.pdf It looks like the maximum current on a typical ARM SC300 GPIO, as used for the H1, is about 4mA. Compare this to the maximum current available from a typical buffer output, as from a flash programmer, of about 50mA, if these circuits were to be directly connected. James ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen
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: 0x45 > Capabilities: 5500 > 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 > OpenNoLongPPY 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 > OverrideBattY 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
[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen
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: 0x45 Capabilities: 5500 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 OpenNoLongPPY 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 OverrideBattY 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
[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen
On Thu, Jul 22, 2021 at 3:56 PM James Feeney 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 0x0111 memsize 0x8ccd4 srcaddr 0xffc34064 filesize > 0x3cdcb > Loading Segment: addr: 0x0111 memsz: 0x0008ccd4 filesz: > 0x0003cdcb > using LZMA > Loading segment from ROM address 0xffc34048 > Entry Point 0x01110015 > BS: BS_PAYLOAD_LOAD run times (exec / console): 147 / 46 ms > CSE FWSTS1: 0x8245 > CSE FWSTS2: 0x3085 > CSE FWSTS3: 0x > CSE FWSTS4: 0x0008 > CSE FWSTS5: 0x > CSE FWSTS6: 0x4000 > 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
[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen
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 0x0111 memsize 0x8ccd4 srcaddr 0xffc34064 filesize 0x3cdcb Loading Segment: addr: 0x0111 memsz: 0x0008ccd4 filesz: 0x0003cdcb using LZMA Loading segment from ROM address 0xffc34048 Entry Point 0x01110015 BS: BS_PAYLOAD_LOAD run times (exec / console): 147 / 46 ms CSE FWSTS1: 0x8245 CSE FWSTS2: 0x3085 CSE FWSTS3: 0x CSE FWSTS4: 0x0008 CSE FWSTS5: 0x CSE FWSTS6: 0x4000 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. 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 consoles seems entirely as
[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen
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. 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 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 On Fri, Jul 2, 2021 at 7:10 PM James Feeney wrote: > > Ok, I finally flashed this coreboot.rom to the Samsung Chromebook 4, > octopus/casta/bluebird, after disconnecting the battery and: > > $ flashrom -p host --wp-status > $ flashrom -p host --wp-disable > $ flashrom -p host -l layout.txt -i BIOS -w coreboot.rom > $ flashrom -p host -r cbimage.bin > > with > > $ cat -A layout.txt > 1000:00f7efff BIOS$ > > where flashrom says > > FREG0: Flash Descriptor region (0x - 0x 0fff) is read-only. > FREG5: Device Expansion region (0x 00f7 f000 - 0x 00ff ) is locked. > > > Now, pressing the power button lights the display backlight, but that is all. > > There is no u-boot prompt, though I have no experience with what to expect > here. > > Any suggestions, please? > > Thanks > James ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
