So I think I might have a bricked RK3588 Pocket Reform on my hands and would really appreciate some help getting it sorted.
First, some background:
I was looking at trying to reflash the eMMC to a factory state with the latest OS image. I failed to find the reform-flash-rescue command and tried to dd a standard image directly to /dev/mmcblk0 in the assumption that I’d be able to recover by flashing directly over USB if something went wrong.
During this process, I learned of the reform-flash-rescue command which seemed like a significantly wiser alternative and so, while still booted, I ran sudo reform-flash-rescue which failed with boot/flash.bin doesn't exist.
I attempted to reboot to discover that I just got a blank screen.
In order to give myself a known good starting point, I wrote the latest image to my microSD card. I have a known good process for this (using dd) as this is the same process I used on first boot before attempt the reflash.
This new SD card image still doesn’t boot. I just get a blank screen. I have confirmed that there’s nothing on HDMI. Right now, I don’t have a suitable serial adapter to check if there’s anything on the console, but I anticipate it too will be dead. I will order an FTDI serial cable with broken out pins for debugging but it will sadly take a week for that to turn up as I’m in a remote location.
I found a reference to refreshing the eMMC on an iMX8MP on the forums (Flashing eMMC Bootloader / Unbricking (IMX8MP) - #7 by digitalrayne) which gave me some hope that I’d be able to do something similar so I set about doing this myself. I bridged the pins on J21 and connected to the USBSEL but no devices show up on my PC when I power the Pocket Reform on.
I’ve checked that the bridging works as I’d expect by checking continuity between pins 1 and 5 and 2 and 6 from the pads on the board.
I’m pretty sure the 90 degree USB-C adapter I have there is just a pass through, and that’s a dumb USB-C to USB-A cable.
My assumption is that I still need to put the RK3588 into a flashing mode (or ‘RECOVERY’) as it is apparently named on the Firefly iCore-3588Q carrier board, but I can’t see anything like this on the MNT carrier board.
And at this point, I’m reaching the limits of what I can think to try, other than seeing if I can get my hands on a standalone Firefly carrier board (which doesn’t look easy to acquire and seems expensive).
For MASKROM mode, on classic Reform, the RK3588 pin SARADC_IN0_BOOT is wired to XSWITCH. But it’s not connected to anything on Pocket Reform. Also, I’ve never tried this out. If you’re confident with soldering, you can try soldering a 0.1mm magnet wire between R57 and GND on RCORE. I’m not sure what RECOVERY (on test point TP5) does. I’m also not sure if the correct USB port is exposed for MASKROM mode.
OK, I’m relieved that this was the solution. The “any” system image doesn’t contain u-boot, so it relies on having u-boot on the eMMC, which you previously overwrote. It’s possible that only the “any” image was available at the point where yo went to https://mnt.re/system-image, which is a problem with how the most recent build is found in GitLab by the redirect script. I will have to change this to redirect to the manually updated build number in common-rk3588/build-numbers.sh · main · Reform / MNT Reform Factory · GitLab (FYI @josch re: problems if only an “any” image is built in CI on main branch)
The file flash.bin should exist if you are not using an “any” image. Are you? If you are not using the “any” image, which one is it? I’d like to see whether flash.bin is really missing.
If that were the case I’m at a loss how that could’ve happened. The error message you got happens before any flashing is being done. So the script errors out without doing anything. How can it be what led to this?
If that were the case, then I do not understand how that is possible to happen. The reform-flash-resue script chooses the name of the image to flash from the value of the SYSIMAGE variable in /usr/share/reform-tools/machines/$(cat /proc/device-tree/model).conf. So I do not see how it could’ve ever chosen the “any” image to flash.
I downloaded the latest dedicated rk3588 image which booted to the setup UI as expected off an SD card and reform-flash-rescue worked perfectly.
There was certainly no criticism meant in my comment—simply that the error is what prompted me to try the (clearly misguided) other steps mentioned above, using dd to try to write an image directly to /dev/mmcblk0.
Again, I think this is a bit of a miscommunication. The reform-flash-rescue script definitely failed safely here.
My question was whether it is actually safe to manually dd a RK3588-specific image to /dev/mmcblk0, or whether there was more going on. Not to waste your time though; I can always dig into the script.
I did not understand it as such. I just want to figure out where there are remaining bugs in my scripts and then fix them.
Ah okay, thank you!
Unless it was the “any” image it should be safe because the rk3588-specific images do contain the rk3599-specific u-boot at the (hopefully) correct offset.
