Thread: IMPORTANT! If you want HELP in case of a bricked Garmin device, please follow this

@derlangehans

Originally Posted by derlangehans

I patched it by myself, i used the wrong fw...

You've flashed patched DriveSmart 60 fw to the 61 and lost your HWID in the process. This may or may not be reversible and re-flashing to DS61 might even permanently brick it.

It seems that the device still boots up (because you have Mass Storage Mode or Media Transport Protocol available) but it isn't capable of proper video output because DS60's display software isn't compatible with the DS61's hardware. Does it give any tones or other audio?

I triggered an FW update with the official Webupdater.
It was successfully installed, but it will not work again.
To trigger the update i changed the GarminDevice.xml .....
...........
But after i this it shows me the old one again.....

Several points here:
1. WU has given you the firmware GCD for DS61 Version 6.30 regardless that you'd changed the XML to V3.50 when it should have read that there is already a higher version and given a message that no fw update was available.
2. Be aware that any changes you make manually to GarminDevice.xml are overwritten on the next successful boot-cycle. I think either (a) your artificial changes weren't properly saved and so WebUpdater read "V6.00" and determined the original model's HWID (2588 for DS61) anyway (in many devices' XMLs the HWID is written twice, not just near the start) therefore it loaded DS 61 V6.30 GCD to the device, or, (b) WU has read the HWID 2588 and ignored the fact that the XML shows the higher version 6.50 loaded already.
3. WU determines the device's identity solely from the HWID written in the XML, as far as i'm aware anyway. Therefore it makes no difference whether the UID matches the model/HWID or indeed whether the UID and Model Description are even present (it could be "1" written as the UID instead of the 10 numerals, e.g. "<Id>1234567890</Id>" and "Garmin GPS" for description and WU would still offer updates based on the HWID shown in the XML).
4. Even with the correct (DS61) GCD in .System loaded by WU, it's clear the device didn't initiate gupdate.gcd on the next boot-cycle. If it had done so then it would now be working again normally as a DS61.
5. Assuming that you're correct and preboot is no longer available in it's present state, it may be possible to recover it using SD text commands and flashing individual BIN files directly to appropriate regions. As it seems the device fully boots (because it's internal memory is visible to Windows Explorer in MSM or MTP state) it should be able to read from and write to a microSD card because that process is done at the end of the boot-cycle. The decision that needs to be made is which boot.bin to use as Ldr.bin for initiating TXT commands. Clearly with DS60's bootloader the device boots but if we use DS61's ramloader (boot/bin/Ldr.bin) it may not be compatible with the DS60's main firmware presently in region 14 but we do know that DS60's is compatible presently (because it boots up) however if we use it to flash DS61's firmware and there is compatibility issues between 60's ramloader/bootloader and 61's firmware then the device may never boot again. To explain further, the device's main system software in region 14 initiates the Ldr.bin on the card which in turn executes the text commands. If the DS60's fw cannot start the DS61's Ldr,bin then nothing happens and that's safest to try first. If we use DS60's Ldr.bin it will initiate for sure (because it's being started by compatible fw) but after the DS61's BIN files have been flashed to the regions it's entirely possible that 60's bootloader in region 5 and 61's fw in region 14 won't play nice.

It's entirely your decision which way we go from here because there are risks with either path. If it was my device it'd be using the 61's Ldr.bin and only resorting to using 60's as a last resort if the device isn't recovered and also not hard-bricked in the first attempt. Goodness knows what's been written to the device's non-volatile memory and whether some poisoned data may surface during or after recovery attempts, such corruption can be deadly even some time later after an apparently successful recovery.

Let me know what you want to do and i'll make an SD flash kit for you but before doing that i must look closely at your GarminDevice.xml. Please remove or disguise the 10 numeral UID from "<Id>xxxxxxxxxx</Id>" before posting it.


@isg

Originally Posted by isg

.....
Changed the bytes as required, make rgn from boot.bin, prepared SD card and update.txt, fw_all.bin and resouces.bin in the root.
I have put the SD card in the slot, started the device, entered pre boot, loaded rgn, unit showed Software Loading, updater said loaded successfully and then loader and that is all.
After 2 min. (just for safety) powered off the device, checked SD card - nothing new on it.
As far as I understand commands if process goes right there should be 41.bin in SD root and update log file in 0972 directory.

Umm. Updater.exe reporting success only means it's run the RGN file. I wonder what was initiated from the card, if anything. What's very concerning is not writing anything back to the card as you noted.

Non from the above. Started the unit for testing - same behaviour.

Well at least it's still alive. I would try the SD flash again but this time let it run for longer. Put into preboot by holding the screen and connecting it to a power source. That way it stays running so let it go for an hour or so unless it reboots itself. Check first that there isn't a carriage return (blank line below) or a space accidentally copied after "reboot" in your Update.txt file too.

Originally Posted by Butters

@isg

Umm. Updater.exe reporting success only means it's run the RGN file. I wonder what was initiated from the card, if anything. What's very concerning is not writing anything back to the card as you noted.
Well at least it's still alive. I would try the SD flash again but this time let it run for longer. Put into preboot by holding the screen and connecting it to a power source. That way it stays running so let it go for an hour or so unless it reboots itself. Check first that there isn't a carriage return (blank line below) or a space accidentally copied after "reboot" in your Update.txt file too.

All done by the book again. Waiting period with loader on screen more than 1 hour All files checked, directories names, update.txt lines, changed boot.bin were checked too. Still same unit behaviour and nothing on SD card.

That's not good but i think it's unlikely to be a hardware failure although cross-flashing can cause many problems. While it lives there's still hope for recovery. The odd thing is that the modded boot.bin doesn't rely on the unit's firmware at all so it should work to start the text commands regardless of the software/firmware state of the device. Just to be sure there's no problem with your microSD find another card of 4 to 8GB and freshly format it FAT32. Not suggesting by this next suggestion that the files you've made might be at fault, but just in case try the flash kit i've made too: [Only registered and activated users can see links. ]

@derlangehans
I'll get back to you after i've looked at the XML later.

@isg
So it reads the card, copies regions but isn't writing to the two firmware regions. I suggest attempt erasing them with ergn commands:

Code:

Please Login or Register to see the links

You can use the same card after removing "last_id.bin" from 0972 folder.

If that works the device should stop bootlooping, stick on logo screen and importantly regain preboot mode. In fact it'll default to that mode but still won't have Mass Storage Mode. Risk is all yours of course but if we can use Updater.exe normally with full original firmware i think we can fix it.

No luck with regions removal:
​Parsing "ergn,14"
Error
Parsing "ergn,127"
Error
Parsing "reboot"