Flash log, unbricking, Cr50, CCD, SuzyQ: Lenovo Flex 3 BOTENFLEX

Support Device Recommendation
21

there’s nothing of value at this point to log with the existing firmware since there is no output from the CPU console on a release build.

I would simply reflash the UEFI Firmware, following the instructions in the unbricking docs to persist your VPD, in case it was just a bad flash. If that doesn’t work, then we can flash a debug build to get serial console out and see what’s going wrong.

1 Like
22

okay, my progress so far:

Enabled write protect again, found out you need to do this every time

Plugging out the battery seemed to break it. Advising this may conflict with the general software flashing WP removal guide, battery is only working on some, I already connected the pins.

The cable needed to be inserted the correct way, with the transistors upwards, otherwise it wouldnt detect it.

$ sudo flashrom -p raiden_debug_spi:target=AP -w coreboot_edk2-botenflex-mrchromebox_20240914.rom --ifd -i bios
flashrom 1.4.0 on Linux 6.10.12-200.fc40.x86_64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

FISK: AP
Raiden target: 2,0
Found GigaDevice flash chip "GD25B128B/GD25Q128B" (16384 kB, SPI) on raiden_debug_spi.
Found GigaDevice flash chip "GD25Q127C/GD25Q128E" (16384 kB, SPI) on raiden_debug_spi.
Found GigaDevice flash chip "GD25Q128C" (16384 kB, SPI) on raiden_debug_spi.
Multiple flash chip definitions match the detected chip(s): "GD25B128B/GD25Q128B", "GD25Q127C/GD25Q128E", "GD25Q128C"
Please specify which chip definition to use with the -c <chipname> option.

I am always confused why there are multiple chips with different names, had the same on my Thinkpad T430.

For debugging it could be interesting to backup the written ROM.

$ sudo flashrom -p raiden_debug_spi:target=AP -c "GD25Q128C" -r ./stock-firmware.rom  
$ sha1sum ./stock-firmware.rom
#repeat for comparison
# did not match? repeatedly

So the firmware is always different? Is this some security mechanism?

Attempting to flash

$ echo "ccd open" | sudo tee -a /dev/ttyUSB0 > /dev/null

$ sudo flashrom -p raiden_debug_spi:target=AP -c "GD25Q128C" -w coreboot_edk2-botenflex-mrchromebox_20240914.rom --ifd -i bios

FISK: AP
Raiden target: 2,0
Found GigaDevice flash chip "GD25Q128C" (16384 kB, SPI) on raiden_debug_spi.
Reading ich descriptor... done.
Using region: "bios".
Reading old flash chip contents... done.
Erase/write done from 381000 to ffffff
Verifying flash... VERIFIED.

And… It worked!

IMG_20241006_214401_637
IMG_20241006_214401_6372405×648 180 KB

23

I ran Windows 11, Clonezilla, Fedora Kinoite, uBlue Aurora, and probably more in the future.

Runs well, batterylife 9h+, really great!

The CCD flash was unproblematic, I would be curious to find the issue though. I already resold 2 CCD adapters in Germany, people are interested in this!

I suppose things like

  • disabling auto-turning-on when opening the lid
  • removing bootsplash logo
  • decreasing boot time
  • …

Will require compiling myself.

I will also experiment with replacing the edk2 payload with Heads, if I have time.

Thanks for the support and the documentation!

24

I’ve been wondering, since this is something I see quite a bit. In what situation would you open the chromebook without the intent of powering it on?

1 Like
25

Good question! I think as a control freak I just want to use the lid however I want.

I often throw my Laptop into a bag while doing updates, so in KDE I said “turn off display, nothing else” when closing the lid.

When opening it up, apart from cleaning or applying like a hardshell case, I dont think it is ever a dealbreaker.

I would love to use Heads on the Chromebook though, and will experiment with that.

1 Like