Thread: aera 795 stuck on 'Loader' after fw update (could getting Unit ID from GMA or UNL files help?)

Definitely good news, potentially. I didn't even know if the aera 7xx actually has a working region 154, most likely your result means either (i) it's present but protected against copying, or (ii) it isn't present at all. Either of those situations gives the 'error' return for that rrgn command. The good thing is that it tried to copy 154 which is the most common region for nonvol in modern devices. It indeed parsed the 'reboot' command successfully but of course the device just isn't able to complete the boot cycle.

This result doesn't entirely rule out flash damage however. It could be that 154 is indeed present and unprotected against copying on a healthy aera 795, but the region on yours is physically corrupt although quite less chance of that i think. Let's press on and see if we can get a full region dump of regions 1 thru to 255, in particular it's the file system content that we want, which is either region 48 or 83 on most devices. We also want the nonvol if it's not protected and in a region other than 154. This will take some time to complete and you may not want to constantly watch it to note a boot attempt before removing the card however even if you interrupt it after, say 30 mins or more, it will probably have dumped enough. Ensure the battery is charged at least 75% and the usb port and cable used is reliable. Many of the possible 255 regions either will be empty (i.e. dumped *.bin file has 0 bytes) or not exist on the device (error message in update.log as shown for 154 in your previous attempt). Regardless, we'll try to dump everything for completeness. I've attached a complete kit behind the spoiler so extract it onto a CLEAN card then proceed as before using the ramloader RGN with Updater.exe in preboot. I don't know the size of the 795's flash memory but i suspect it's quite large. Use a 32GB card if you have one or minimum 16GB card (or even use a 64GB or larger one but ensure it's reformatted in FAT32 not the default exFAT). If you only have an 8GB card use that anyway, we'll likely get something worthwhile even if it's just the reassurance that it can successfully dump some regions.

Spoiler:

[Only registered and activated users can see links. ]

We'll have quite more to do later if this works but ongoing we'll hopefully have the knowledge of what's actually contained in the device's folders and files. It may be a little frustrating that this is taking a long time to work thru because i'm taking baby steps with this repair procedure. I'm doing that because (i) It's still an expensive device, over 2 grand US when released in ~2011 and a good 2nd hand unit's value is prob up to $1000 still; (ii) I don't have one that i can easily access to test stuff on [i have a PPL but just like me all my pilot friends are just too poor or too cheap to own a nice bit of kit like that ] and (iii) I'm trying to use the policy of "do no harm" here.

There's still a chance there's flash damage of course but instinct and previous experience now tells me that's not so likely. Good luck and post the outcome when you can, i may not be available for a while to get back after you do so please be patient awaiting my response to your next post. You'll need to use a hoster site like Zippyshare or Anon files etc. for a good result because even at maximum compression it'll be much too big to attach on our server. If every single region dump fails (proving flash damage) then it'll be quite small.

PS: No change to 5.60 on boot screen is not unexpected and is nothing to be concerned about. The BIN component of that RGN has not been flashed to the device, it's just used to start the card txt commands. There is no actual update with that method so V5.50 still shows.