Thread: BMW Motorrad Navigator VI HWID 4044 with "SYSTEM SOFTWARE MISSING" message

@Alvinhyc
Are you sure that your BMW Navigator VI has both Firmware Version 10.00 and HWID of 4044? The only Nav V1 of which i'm aware has latest fw V5.80 and HWID 2584. Please check both and then advise before we can help further: [Only registered and activated users can see links. ]. Supply a link to that V10.00 fw if you have it.

That's not a US/EU firmware device of course. I suspect it's a localized model, such as China, Taiwan ..... maybe? I'm not able to locate any firmware for that HWID unfortunately. You may need to contact the local Garmin branch or BMW dealer to ask for a copy of the firmware. If you can find the correct firmware (any version, even a UAT [beta] version will do) for HWID 4044 we can likely fix this device easily.

Did you take that photo of the screen before the attempt to dump NV region with the wrong ldr.bin?

My understanding and assumptions: You've used the wrong boot.bin as ldr.bin according to your Post #322. Likely you used the one from US/EU fw so tell us if you changed the HWID in RGN_Tool to 4044 or left it as (e.g.) 2584? If you didn't change it to 4044 and flashed it with wrong ldr.bin, then the device likely now has HWID (?)2584 in it's regions 5 & 43. However the main fw region 14 is still reporting HWID 4044. The incorrect ramloader (boot.bin/ldr.bin) previously flashed to rgn12 may have written the incorrect bootloader into rgn5. That is being initiated by rgn14 however it's unable to subsequently boot the device hence the screen message "System Software Missing". So although the correct fw_all.bin data (the main 'system software') is in rgn14, it cannot start the device.

Please confirm or correct all the above information if you are able to locate appropriate firmware.

The reason your PC detects the device in Windows Device Manager is because it's defaulted to preboot mode due to being unable to execute the system software (firmware) in rgn14. Because it's in preboot we can probably successfully re-flash it using Updater.exe if you can find the firmware. Good luck.

I'd have thought that the device sold in UK domestic market would run same fw and have the same HWID as the US market device. Try contacting the seller or Garmin UK to see if they can inform you regarding the origin of the device or better still give you the firmware.

Meanwhile, more info required:

• So when you tried to dump the regions you used HWID 2842's ldr.bin in folder named 4044? That 2842 ramloader is from Nav VI Japan fw.
• You didn't get successful dumps?
• Also, why did you want to dump the bootloader rgn5? It's usually protected against writing/flashing in most devices anyway.
• Do you have the full firmware for 2842 JN?

Please answer all 4 questions above.

When any flash is done the ramloader (bootbin/ldr.bin) is written to a virtual region 12 and rgn12 in turn writes the bootloader (aka Boot BLK) to physical region 5 and the X-Loader to region 43. It might be possible to convert the device to a JN device using HWID 2842's full firmware via Updater.exe seeing it's in preboot mode. Of course you'd need to understand that's risky and the device may die completely. However, it presently has 2842's bootloader in rgn5 and hasn't died, so maybe with JN fw_all.bin flashed to rgn14 it might boot up ... or die completely trying.

I'd read previously about some US/EU Nav VI's having the ghost-touch screen problem. Garmin has been replacing them without question, however i wasn't aware that they had issued a different HWID device 4044 for the problematic US/EU 2584. The fact they have changed the HWID indicates to me that they've also changed the firmware in some way and likely that's because they fitted a different screen, so that makes the 'old' 2584 firmware incompatible with the 'new' 4044 hardware. If so, flashing 2584 or 2842 system software (fw_all bin and, maybe, resources.bin) to the newer hardware would potentially make the 4044 screen inoperable. So great caution is needed regarding any ongoing action involving the old US/EU or the JN firmware to the point that i'd now seriously advise against that.

Likely all the various HWID models have the same PCB P/Ns (identical mainboard) and probably the localized firmwares use the same ramloader (boot.bin) with appropriate HWID and with different system firmware in fw_all.bin and perhaps also varying resources.bin data.

The same ramloader hypothesis is strongly supported by the fact your 4044 device hasn't died with 2842's ramloader written to region 12 even though the main system software of 4044 isn't booting.

IMPORTANT: Why are there two different Unit ID's in the update logs though, the UID shouldn't have changed. Do you have an explanation? Did you try to load an NV dump from your friend's 2842 device to your 4044? I hope not ...(shudder!). Or are those dumps from different units, your 4044 and your friend's 2842/s?

You might be able to safely write via Updater.exe the boot.bin of 2842 or 2584, by loading it as an *.RGN file with HWID first changed to 4044. That should then allow regions 5 and 43 to have the correct HWID written to them from rgn12 thus removing the HWID conflict between regions which is what i suspect is stalling the boot process. I'm assuming there that there's no material data difference in the various ramloaders but we MUST try to confirm that before you go further. If the only difference is the HWID written into the BIN files then it should be safe to try.

Could you please post copies of all 5.bin and 154.bin files you've dumped, clearly indicating which is from those two UIDs. Also please supply a link to the 2842's fw GCD. You can attach them to our server provided you RAR or ZIP them as max. size 15.07mb. Use the post editor behind "Go Advanced" to find the "Manage Attachments" button for that. You'll need to split the compressed GCD into several parts to attach, or just upload the single original file to MegaNZ, AnonFiles or Zippyshare. I already have the US/EU 2584 firmware to compare.

Originally Posted by Alvinhyc

I know that using the same firmware on completely different hardware will have serious consequences, so until now I only use 2842's ldr.bin to execute rrgn 5 and rrgn 154 on 4044 hardware, and dare not try other actions.

You were wise not to try other actions. However rgn5 as said previously is the bootloader (aka 'U-boot') and is a vital region because if it's either erased or changed in an inappropriate way (e.g. flashed with data from an unrelated device) it will likely result in a totally dead irrecoverable device. As to your use of 2842's ldr.bin exclusively, i do have a query below about that.

So Ramloader will first write to region 12 and then execute it.

I mentioned previously that rgn12 is a virtual region. My understanding is that it's functions are solely to accept data from the ramloader file (boot.bin/ldr.bin) and then in turn write to two other physical regions i.e. bootloader data to rgn5 and x-loader data to rgn43. Region 43 is also a vital region like 5, because although it's function varies somewhat depending on whether the device's flash chip is NAND or NOR, it one way or another is essential in executing rgn5 either via RAM or via the CPU in some way. So if 43 can't start 5 indirectly, or 5 is started but can't in turn properly load fw_all from rgn14 and execute it, the device cannot boot. Garmin's 'fail-safe' for the latter situation where fw_all isn't able to be started (whether because 14 is empty, corrupted or simply compatible with the bootloader) is to default the device to preboot mode and show on screen the message "System Software Missing" thus prompting a user to load the appropriate data to regions from an *.RGN file via Updater.exe. So in your case 14 should be unaltered from V10.00 data along with every other region for a 4044 device including the regions like 14 which have a specific HWID in their data. (other than 5 and 43 of course, they via virtual rgn12 have been flashed using 2842's ramloader).

I've tried changing the HWID from 2842 to 4044 and putting Ldr.bin in the SD card. This is not equivalent to using Updater.exe to write boot.bin to region 12, right?

Yes it's the same but in the sense that if the device can execute from media card and also provided both 5 & 43 are already healthy. The point is that the x-loader, 43, is always involved and if the starting blocks are missing/corrupt in 43 then the device is finished because 12 can't be started anyway.

I will learn and try to use Updater.exe to write boot.bin to region 12.

It's a very simple operation. The appropriate boot.bin is opened in RGN_Tool and then saved as an *.RGN file without any other *.bin files in in. If successful, 12 will be overwritten with the correct bootloader data and it then flashes 5 & 43 on next boot attempt. Don't do it yet though because we need to clear up some inconsistencies and check some more data as written below.

I have not tried loading NV dumps from other 2842 units to my 4044.

Good. Although the Non-Volatile (NV) region is partly re-written with the device's unique information on each successful boot, having information from another device (even of the same HWID) in region 41/154 can cause irreversible bricking even at some later time during normal operation. BTW, what you might be referring to as "NV dumps" is maybe a multiple region dump such as you supplied in "Region Data" of the "From_HWID-2842(BMW NAV VI V2.6)" folder. I want to be clear that the generally accepted meaning of "NV dump" (and the way i always use it) is a copy of a specific region and that's the dedicated non-volatile region of a device which is either 41 or 154 although sometimes it's both regions for certain units.

The first time I used the boot.bin of 2842 without changing the HWID, I was shocked to see "SYSTEM SOFTWARE MISSING" on the machine, and forgot to check the update.log under the Garmin\2842 folder of the SD card.
The second time I changed the HWID to 4044 and tried again, but it still displayed "SYSTEM SOFTWARE MISSING", only to find that it could not return to normal, and then I remembered to check the update.log.

Ok, it's starting to become clearer as to what happened but i still need some more information. When you say "I changed the HWID to 4044 and tried again" do you mean that on your second attempt to that you changed the HWID folder name only or do you mean you changed both the folder name AND changed the internal HWID in the Ldr.bin file too? Also, i find that confusing because if the first attempt was with a folder named 2842 it shouldn't have worked at all if your device was HWID 4044 from the factory and so it wouldn't read an SD folder named anything other than "4044". Was it the other-way around in fact and your first attempt was with 4044 and second attempt 2842? Regardless, the different UID in the update.log files makes no sense to me because the 10-digit Unit Identification number are not changeable. Certainly the 4-digit Hardware Identification numbers are easily edited in fw and thus written to a device of course, although that practice can be risky if used unwisely. Permanently changing a UID is not a trivial process and certainly not a usual or unintended consequence of changing the HWID of a device. So can you absolutely assure me that BOTH log files for UID 3375696611 and UID 3952386425 were from your device and not one from yours and one from your friend's JN device?

I think this is the first time, although the HWID of the Ramloader is 2842, other zones are not damaged even zone 12, so the rrgn command is executed successfully, and the first record shows UID 3375696611 of 4044.
Then region 12 or other region is changed, HWID becomes 2842 UID 3952386425.
When I second use Ldr.bin with HWID changed to 4044, zone 12 or something already has HWID of 2842, so the update.log second record shows UID 3952386425 of HWID 2842.

No that doesn't explain the UID difference as i said above. I'm speculating that if the two entries are indeed from your device that it's a refurbished unit which has had both it's HWID and UID factory reprogrammed and somehow your manipulations with running the 2842's Ldr.bin from SD card has caused it to revert to it's original UID. There is an interesting inconsistency between the two bin files from region 5 too. "2842_5.bin" has internal HWID 2842 as it should, however "5.bin" shows HWID of 2584 which is of course the original US/EU firmware's HWID - see the compare image behind the spoiler below. I was expecting to see 4044 or still 2842 but certainly not 2584. I know you wrote that you've only used 2842's ramloader but is it possible that you used the boot.bin from US/EU firmware to make the Ldr.bin for the second dump? If you didn't use the US/EU ramloader then there might be ramifications from that change happening so please be sure to answer that question in your reply.

As to changes to other regions, or in your words "not damaged", you're correct that they are not changed at all by your use of SD card running Ldr.bin for dumping other regions but certainly 12 is possibly changed because the bootloader data is re-written to it by that process. Hence if there is no change to ldr.bin there is no change to region 12, it only changes if the data in the bin files also changes. So again it's puzzling why the dumped "5.bin" file shows HWID changed to 2584 when i'd expect it to still be 2842, or changed 4044 if you'd altered it in the SD's ldr.bin (ramloader then written to 12 in turn changing 5).

Spoiler: Hex Compare Differences

[Only registered and activated users can see links. ]

Yes, I want to share all my dump files.
I got a complete 2842 firmware file and valid NV data between region 0~region 255........

Thank you, i wasn't expecting a full region dump but it is helpful. However, i must ask again for you to clarify if both the complete (all regions) dump and the one containing only 5.bin and 154.bin are from your device only or if the complete dump is from your friend's. It seems to me that it is indeed from the JN device as the 2842_14.bin matches fw_all.bin from 2842-V2.60.GCD. So could you please supply me with a copy of your device's region 14 and also a copy of it's Garmin folder? Use the Ldr.bin you used for your latest dump and in Update.txt put the commands:
copydir,0:/Garmin/,1:/BackUp/
14,1:/14.bin
reboot

Sorry for the length of this reply and the additional requests however i want to give you every opportunity to restore the device and one ill-considered move could kill it.

EDIT: Important! In your copy of update.txt Post #326 the path to SD is "2/:" but in Post #328 in Update.log it's "1/:". It should be the former i think so you may need to modify the above commands to comply. I'd copied what you had in your later post without thinkng about it. Usually if NV is in rgn154 the path is 2 for the card. In that case 1 is used for the onboard RWFS partition.