I found this thread that suggested I could disable fw write protection from my linux distro by downloading gsctool and it seems to have been working - I entered root mode with `sudo -i` and it had me do the button presses every few seconds. Eventually the device turned off and now it seems to be stuck in a boot loop - the power button will turn on for a few seconds then turn off again and the keyboard backlighting will blink on for less than a second.
I let it sit for a while in case it was normal procedure but after a few minutes I tried a hard reset holding the power button down but the boot loop repeats so fast that it doesn’t have any effect.
Any idea how I can get out of this mode? I tried pressing CTRL + D a bunch with no luck. Should I unplug the device from power and let it die?
My end goal was to switch from RW_LEGACY to full UEFI firmware but the fw write protect was still enabled on the device. I purchased the SuzyQ adapter but didn’t even get to the step where it is used.
Any ideas or is the device dead? I let the battery deplete but plugging it back in now and same issue, stuck in a boot loop no screen activity. Any hope to get the files off of it? I was going to back them up before doing the firmware update - never imagined just enabling CCD mode would have such risk involved.
Since you have a SuzyQ, you may be able to read the CCD logs from a separate computer, which might give an idea of where it’s getting stuck:
As for “get the files off of it”, Redrix uses a standard M.2 2230 or 2280 SSD, you can put it on another computer or an USB case and the Linux partition should be readable.
Hi @Zidrewndacht, thank you for the helpful information.
I tried the commands listed there in both a regular console as well as a root console on my second computer and no luck getting logs to diagnose the problem further. A bunch of `minicom: cannot open /dev/ttyUSB0: Permission denied`. The instructions are not very clear though so I’m not sure if I’m missing a step or not. They go into compiling custom firmware and editing the grub config but my whole issue is nothing is POSTing so none of that is possible on the device.
Should I just assume that it is bricked and follow the instructions here Unbricking/Flashing with a SuzyQable | MrChromebox.tech ? I’m not sure if the “CCD flags factory reset“ part is true since I only got through step 1 of disabling write protect and it failed. Should I try going through the steps again even as the device is not booting?
Hi @MrChromebox yes, I tried both sudo minicom -D /dev/ttyUSB0 as well as running it in a root console using sudo -i and then trying minicom -D /dev/ttyUSB0. Both result in Permission denied.
if you mean by doing something like ls /dev/ttyUSB*, yes. The error is that the file or directory cannot be found when I tried running the commands while the USB connection timed out and I had to unplug and replug the cables.
I am running the commands in a Ubuntu Distrobox, as my OS is immutable so it cannot install packages like minicom in the standard way. Would this be an issue?
minicom now working, I am now getting errors from flashrom. Running sudo flashrom -p raiden_debug_spi:target=AP -r badflash.rom results in:
flashrom unknown on Linux 6.17.7-ba25.fc43.x86_64 (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
libusb error: ../usb_device.c:265 LIBUSB_ERROR_ACCESS
USB: Failed to open device
USB: Failed to open device
libusb error: ../usb_device.c:265 LIBUSB_ERROR_ACCESS
USB: Failed to open device
USB: Failed to open device
Raiden: No usable device found.
Error: Programmer initialization failed.
Any ideas on how to proceed from this? As expected, USB1 logs are silent since I have default MrChromebox ROM which does not have those enabled and USB0 is looping which makes sense given it’s the TPM info and it is stuck in a boot loop. USB2 is telling me the battery is charging from being connected to my PC.
Edit: I’m new to how distroboxes work… I had to be in the distrobox terminal to install flashrom but apparently you have to not be in it to use flashrom. However, using minicom works correctly in the distrobox terminal. I suspect it has to do with situations that sudo are needed, because even though I type sudo is does not ask for a password when in the distrobox terminal. Same with sudo -i, no password needed but the terminal does say root.
Running it in my regular terminal seems to have done the trick.
Alright, that sorted out I was successful in generating badflash.rom and hwid.txt with correct board info in hwid.txt.
However, vpd.bin is not created. The command ./cbfstool badflash.rom read -r RO_VPD -f vpd.bin does not result in any errors however.
Any ideas on how to get that? Is it because the device does not have an ethernet port? I don’t fully understand the implications of not copying this data and would rather preserve it if possible.
Eager to see life in my laptop again and figuring that I could just reflash later with a fixed rom since I already extracted the bad flash rom, I went ahead and performed the flash.
I did run ./cbfstool coreboot_edk2-redrix-mrchromebox_20260125.rom add -n hwid -f hwid.txt -t raw before, figuring that some data out back into the new rom is better than none. Then I ran
The verification step failed however, but my laptop is in a different state now.
flashrom 1.4.0 on Linux 6.17.7-ba25.fc43.x86_64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
FISK: AP
Raiden target: 2,0
Found Winbond flash chip "W25Q256JV_M" (32768 kB, SPI) on raiden_debug_spi.
===
This flash part has status UNTESTED for operations: WP
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to [email protected] if any of the above operations
work correctly for you with this flash chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and mention
which mainboard or programmer you tested in the subject line.
You can also try to follow the instructions here:
https://www.flashrom.org/contrib_howtos/how_to_mark_chip_tested.html
Thanks for your help!
Reading ich descriptor... done.
Using region: "bios".
Reading old flash chip contents... done.
Erase/write done from 500000 to 1ffffff
Verifying flash... FAILED at 0x01b95473! Expected=0xd3, Found=0xc3, failed byte count from 0x00500000-0x01ffffff: 0x64fd9
Your flash chip is in an unknown state.
Please report this to the mailing list at [email protected] or
on IRC (see https://www.flashrom.org/Contact for details), thanks!
I’m not sure if it’s doing RAM training or what but the display lights up and the fans kick on very loudly. The device does eventually turn off after a minute or so though. Is this progress? Are the next steps to load a flash drive with my distro installer or how do I proceed? Thank you for the assistance.
So I then ran sudo flashrom -p raiden_debug_spi:target=AP --wp-disable and sudo flashrom -p raiden_debug_spi:target=AP --wp-range 0,0 which now lets sudo flashrom -p raiden_debug_spi:target=AP --wp-status return:
But unfortunately is still results in a verification error:
Reading ich descriptor... done.
Using region: "bios".
Reading old flash chip contents... done.
Erase/write done from 500000 to 1ffffff
Verifying flash... FAILED at 0x01b9531b! Expected=0xcd, Found=0x4d, failed byte count from 0x00500000-0x01ffffff: 0xe10c9
Your flash chip is in an unknown state.
Please report this to the mailing list at [email protected] or
on IRC (see https://www.flashrom.org/Contact for details), thanks!
I’m not sure what exactly I did but the device just booted into my linux distro successfully after entering my LUKS encryption password! The old screen that said You are in Developer Mode where I had to press a few buttons to boot into my linux distro are gone so I’m assuming the full UEFI ROM flash was successful?
To recount the steps that I followed in case they were at all helpful and anyone else runs into this:
I tried running echo "ccd open" | sudo tee -a /dev/ttyUSB0 > /dev/null again and then flashing, but that resulted in a verification error just the same.
I tried pressing Power button + Refresh key twice like it says in Recovering a device bricked due to RO verification. Also did it with the Back arrow key just to the left of the refresh key just in case.
Finally I tried pressing CTRL + D which was the moment that I saw the coreboot logo for the first time but I have a feeling this was coincidental because the device turned off at the LUKS decryption screen before I could run to the device to enter my password. Then when I unplugged the SuzyQ cable, I got nothing. I suspected that the device was simply dead and not getting enough juice to sustain a charge so I plugged it into its wall charger and voila! So potentially the first flash went fine (despite the error in verification) and it simply was too dead to proceed.
TL;DR: Make sure your device has enough battery to boot
My final question for this thread is what steps should I now perform to make sure the device is in a good, secure state? It all got lost and jumbled in the different troubleshooting steps I had to do from different places. Reading the warning in Disabling Software Write Protection, it seems that it might be a good idea for me to undo the troubleshooting that I did in my last post that disabled the software write protection? Or should I not worry about it? And if I do enable it (presumably with sudo flashrom -p raiden_debug_spi:target=AP --wp-disable but I am not sure), will it wipe my laptop?
Like I said, likely coincidental. Even moreso with your understanding. But it’s something I did so I want it to be on record in case someone else is in a tricky situation like mine in the future.
What are your thoughts on the software write protection - should I re enable it? And do I need to disable CCD? I didn’t expect the OS to boot back as normal when going from RW_LEGACY to full UEFI so I’m not sure what state the device is in. I value security so would like the all possible safeguards to be put back in place that actually do something.
The Clean Up section doesn’t mention much but I also did things that aren’t mentioned and are specifically said should not be necessary to do manually (like disabling software write protection) so this situation isn’t exactly by the book.
software WP allows certain address ranges of the chip to be WP. It requires constructing the firmware layout in a way that works with the protected ranges. My firmware does not currently do that, so re-enabling the stock settings would prevent things from working properly.
no, you should explicitly keep it enabled via ccd reset factory per the docs
you have to disable software WP when flashing the UEFI firmware externally without having flashed internally via the script first. This is mentioned right above the section in the link you posted.
Ahh I actually never read that part of the page because I was stuck on the failed verification from step 1. I got those commands from Disabling Software Write Protection where it explicitly states, “(read: you don’t ever need to do this)“ which is what made me think otherwise. I believed it was a shot in the dark I was testing but good to know it was part of the course! Thank you for the clarification!
