So you weren't correct when you stated "nothing happens in either the first or second case" because it did flash cured fw_all in 14.bin using the modded boot RGN.
In an otherwise healthy device defaulted to preboot, loading cure firmware would immediately change the default mode from preboot to Mass Storage and even a badly corrupted or unformatted or RAW file system would become visible to the PC, if not in Windows File Explorer then certainly in Disk Management for re-formatting correctly.
Here's what i think has happened to your device, one of two things and maybe even both:
(1) the flash drive has been irrevocably damaged by the failed attempt to convert the device to O750 with the region layout compromised, maybe other things too but particularly in regards the physical space allocated to the file system (48/83), also most likely that failure wrecked the Virtual region 12 to which the ramloader is written each time a flash is initiated with a (standard) boot.bin/Ldr.bin. The reason a flash with Updater.exe, used in the normal way, fails is because region 12 on the device is not being rewritten and maybe is never going to be capable of that because it's either been destroyed or rendered permanently unwritable, so it can't be re-flashed with correct (O6x0) ramloader data. Therefore region 12 cannot in turn write (either at all or correctly) to the physical regions 5 (the bootloader) and region 43 (the x-loader). However when the modded ramloader is flashed as RGN to execute txt commands on the card, that process is completely bypassed, importantly so is also the process involving the fw in region 14 which [normally] invokes the bootloader in region 5 to initiate starting the device;
and/or,
(2) the nonvol region (in the current O6x0 layout) 41 is poisoned with confusing and incompatible data. That causes the device to malfunction badly when it reads messed up data in 41 and explains why it will re-identify as O750 after a failed flash using Update.exe normally. That poisoning may be either:
(i) a permanent corruption; or,
(ii) erasable by using ergn command. Erasure using ergn doesn't stop the device replacing some essential and limited data in the region provided that it can then fully boot up, and hopefully that re-written data will be clean if it does fully boot.
So in effect, (1) and 2(i) are fatal and not correctable by any software cure.
Using 2(ii) is risky because the device may be left totally dead and never again even turn on.... but in my opinion it's the only remaining option left now. If you wish to do do, use the flash kit with the modded_boot.rgn to execute the erase command. Remove last_id.bin of course and replace the contents of Update.txt in 2512 folder with this:
ergn,41
reboot
If it does revive and become stable enough to enter Mass Storage Mode with cure O6x0 fw loaded (which it is already) then maybe it can be recovered... but possibly with limited functionality due to a crippling or deletion of some nonvol data which cannot be ever replaced.



Likes: 



Reply With Quote
Bookmarks