Before performing extended online research, please do not hesitate to ask even questions that you fear might be too simple to ask. Chances are, that I can help you quickly. This is how you would’ve applied the patch, assuming you copy it into a file called “mybmap.patch”:
sudo env --chdir /usr patch -p1 < mybmap.patch
But you do not need to do that because you already have a copy of reform-flash-rescie where you have made the edit manually. The file in /usr/bin/ is “read-only” because it’s only supposed to be changed by the superuser (aka the root user). That’s why you need to run above command with “sudo”: xkcd: Sandwich
So yes, you should be able to run this, assuming that you are in the directory where reform-flash-rescue2 is in:
bmaptool: info: no bmap given, copy entire image to ‘/dev/mmcblk2’
bmaptool: info: synchronizing ‘/dev/mmcblk2’
bmaptool: info copying time 4m 42.0s, copying speed 4.6 MiB/sec
Error: /dev/mmcblk2: unrecognized disk label
I tried booting the device without the SD card, and the screen is simply blank. None of the startup services show up. The keyboard is lit and the OLED screen turns on, but it’s still stalled.
Perhaps I need to just wait for my RK3588 to ship? Sure hope I didn’t brick the module.
Huh… Okay, I think I will have to run the script myself. I can do this on my imx8mq classic Reform and I hope I run into the the same issue as you did, so that I can fix it.
I don’t think your module is bricked. This can only happen if you should flash a broken u-boot to eMMC. If you put a fresh sd-card with a rescue system in, that system should boot just fine.
I’ll write here again once I have some results. Sorry for the mess. Apparently nobody has run this script for a while and bugs have crept in…
I really appreciate your effort with all of this. It really puts into perspective how much work goes into programming things like computers and phones we take for granted!
I appreciate that you stick around to help me find these issues. While I wrote these tools, I’m rarely ever using them and thus I do not encounter these problems. The problem you are facing is a fundamental one and hints that reform-flash-rescue has never been used by anybody. It is fundamentally broken because after bmaptool finishes, the following is on the device:
So bmaptool wrote the compressed image to the device. It didn’t uncompress it. This is why parted later fails. It can naturally not see any partition table on the device.
To fix this, we have to fix bmaptool. The fundamental problem is, that gitlab CI appends the query part ?job=build to the end of the URL. This means, that bmaptool does not find an extension like .gz at the end and thus does not decompress the image. We have to teach bmaptool to strip off the query part when checking for the filename extension. I prepared this pull request to do exactly that:
It will take some time until this pull request was accepted by upstream and it will take even longer for a release to be made and that then getting added to Debian. To avoid having to wait that long, we can patch the bmapt-tools package in the mntre.com repository. So I backported my patch for upstream here:
I set this to auto-merge, so if everything goes right, this will be in the repos in ~1.5 hours.
This will btw also conveniently fix the problem which made you add --nobmap. With those changes above, you do not need to add this anymore because bmaptool will try to find a bmap file behind the URL ending in .gz.bmap?job=build instead of trying to access a url ending in .gz?job=build.bmap which is what happened before…