Quote Originally Posted by Alvinhyc View Post
Flashing the 2584's boot.bin saved as an RGN file to overwrite the ramloader in rgn12 and subsequently 5 & 43 this should be the first method to try, because it will not cause damage to a more region.
Yes it should be relatively safe. You presently have 2842's ramloader flashed to rgn12 and other than causing 'system software missing' it hasn't further bricked the device. It's reasonable to assume that 2584's ramloader won't do any worse, and at best may be compatible with the 4044's main firmware resulting in booting the device. That's essentially what's referred to as a "hybrid-firmware" but in reverse. Usually, a device's original boot.bin is combined with the other fw components of a related device to do a safe and easily reversible conversion whereas in this case you'd be using a related device's ramloader/boot.bin as the only component of an RGN file to exclusively flash rgn12 and thus retaining the original native main fw in rgn14 and resources fw in rgn127. I would be reasonably confident that there'll be nothing unpleasant result from such an experiment and somewhat hopeful of a successful booting. ANY flashing other than standard is risky to some extent however! Thus it'd be at your risk of course. To make a boot.rgn, open the US/EU GCD in RGN_Tool, use the overrides to change HWID to 4044 and SW Version to 100, uncheck the lower boxes then save as boot.rgn as shown below, to then flash with Updater.exe in preboot.
Spoiler: Click for Image
[Only registered and activated users can see links. ]

Last resort is to flash the 2584 or 2842 full firmware to the RGN file using Update.exe or via a media card, I know it may not be salvageable in the end. So I'll wait a while before trying it and see if I can wait until Garmin releases another firmware update for the 4044 device.

Yes, please help me to understand the steps and toolkit for these two methods.
I'd suggest to not try it yet of course however the steps are quite simple. The firmware GCD of 2584 or 2842 is saved as an RGN file using RGN_Tool and named <any_name>.RGN then flashed using Updater.exe in preboot - usually 'safe-naming' is used in a format of "<HWID>01000<SWV>.RGN" where HWID is 4 digits of the actual device and SWV is 3 digit fw version, e.g. 258401000580.RGN or 284201000260.RGN. Any other naming bypasses Updater.exe's check query of the device's actual HWID and forces the flash so although "OUT.RGN" is usually used for hybrid or foreign fw RGN naming as a warning of its nature, you can save as RGN_Tool's suggested default naming, e.g. "BMWMotorradNavigatorVI_580.RGN" or "2842-V2.60.RGN" for easy identification.
Spoiler: Click for Image
[Only registered and activated users can see links. ]

You could also save the individual 14.bin and 127.bin using RGN_Tool and then flash using the appropriate Ldr.bin for either 2584 or 2842 via SD method. The commands for Update.txt would be:
xrgn,14,2:/14.bin
xrgn,127,2:/127.bin
reboot
As the device is only recognizing a HWID folder of 2842 that's what you'd need to have in the Updater folder. The 14.bin and 127.bin would need to be placed directly in the root of the card along-side the Garmin folder for the above txt commands to work. The shorter the read path the better.

Yes, the device is under warranty, in fact I have tried to contact GARMIN TAIWAN, the reply is:
Code:
Please Login or Register to see the links
I also messaged the eBay seller asking how to send the device in for repair? But never got any response.
So the worst case scenario is that I can't send the device back to BMW or GARMIN.
So the response from Garmin is to handball to problem to BMW ... i'd expect that you'll get a similar response from BMW telling you to contact Garmin.

I would like to ask you, if there is another 4044 device that is brand new and has not been changed, can I safely back up Region 12 and other Regions in the machine without the 4044 boot.bin(Ldr.bin) ?Because I might be able to borrow another 4044 device.
Here's the problem with that idea, you don't have the native ramloader for 4044, it's what you want to obtain in fact. So you'd have to use 2584 or 2842's to make Ldr.bin and i'm sure you already know that. As you found out to your misfortune, that process writes the Ldr.bin's ramloader data to rgn12 so whether you'd get a virgin dump of 4044's 12 or of its modified 12 is unknown.... but possibly the latter although i think not. Potentially a risky procedure for the owner of the other device anyway because at latest on the next boot cycle his device will write 5 & 43 from 12 which will certainly have been updated with foreign data by then. If you did manage to get a dump of the virgin 4044's rgn12, it is theoretically possible to 'manufacture' a ramloader by deleting some additional data in hex. You can see yourself by using HexCmp to look at the original boot.bin from 2842 and your dumped 2842-12.bin. You'll see that the first 962,612 bytes are the same and that's the total size of the boot.bin. The 2842-12.bin has 18,874,368 bytes so needs to be trimmed back to obtain what should then be a working ramloader. I'd think flashing a complete rgn12 copy from a different device would be a very bad idea and the twist is knowing exactly what to delete when you don't have an original ramloader with which to compare 12's data.

Good luck with whatever to decide to do. I'm happy to help you further with advice or even making flash files.