Hardware Version 11.2.#.# updates

Does anyone have the recovery.img file? Could someone with the full scale tablet make a recovery img and upload it here? I dont think the system.bin in a update.zip will work. at least it doesn't seem to be.
If we had the recovery.img file I wold be willing to try it on my device.

It's linked over in this ongoing thread in attempts to view the image file that was extract so it can be ported. http://www.androidtablets.net/forum...g-clockwork-recovery-tablets-4.html#post59317
 
Here's some of the extracted code from the "system.ius" update file downloaded when doing the "Upgrade system" from the Settings menu.

It defines an address range 40007fc0 40ffffc0. What is this and how can I view that range on the device? The (normal) line is what I get when running #cat /proc/cmdline from shell.


Code:
 Booting linux(recovery) ...
%s bmagic=0x%08x hwver=%d.%d.%d.%d console=ttySAC3,115200 androidboot.mode=recovery bootm 40007fc0 40ffffc0 Booting linux(normal) ...
console=ttySAC3,115200 androidboot.mode=normal ls.
bootl Boot pre-burned linux.
adr adr (OEM implanted image burnning tool.) burn data size nd_addr
adr system mem_addr
adr user mem_addr
adr ndisk mem_addr
adr rd mem_addr
adr rd_ mem_addr
adr lk mem_addr
adr nk mem_addr
adr as mem_addr
adr uboot mem_addr
Here's another reference to the address and maybe why there has been no success in loading from SD card.
Code:
 bootm 40007fc0 Bootm failed, system halted...
 Function for updating uImage from SD is currently removed!

Update: Seems I'm more than two month behind these guys with these little discoveries about a recovery partition. http://forum.xda-developers.com/showpost.php?p=10071197&postcount=754
 
Last edited:
Little by little we'll get there. I've got ubuntu running on a spare PC at home now, but I know NOTHING about linux. I'm working on learning what I can, which will hopefully eventually include building android from source...that's down the line. Before we get there, though, a major hurdle to overcome:

We need a way to burn/flash the memory on this tablet

There are tablets that use a similar boot system out there (u-boot) and tablets that use a similar chip and architecture (infotmic IMAP x200/210/220) but they all have a way to get into recovery, boot from an sd card, or otherwise flash the memory. The ZT-180 seems to be the closest relative (aside from the disgo 6000 which appears to be identical) but has a different boot system and an easy way to put it into "flash" mode.

What it seems we need to do, which I'm sure is no simple task, is modify the boot image to give us recovery/flash options. ClockworkMod is one such way to do this, but we need to get it ON the device in the first place, or figure out how to boot from an sd card.

To do this we have two examples of when the device software flashes the memory. When downloading and installing an update, and when booting with the "three finger salute" and flashing back to stock. Unfortunately the latest update (that's now not active) form last week never made it to this point, it downloads, "loads", then reboots right back to where you were. Some have reported minor changes, but I'm not convinced it did anything. Back in December the update that took us from firmware DG 1.01 to DG2.02 downloaded, loaded, burned the file system, then reboot. I’m not sure what was different then versus now.

A few members have extracted the settings.apk package and discovered that once downloaded the update process is based on two commands:

Code:
infoup inject /local/system.bin
Infoup reboot
The inject command appears to extract the system.bin file into /dev/mtd/mtd2, which we assume is the recovery partition. The reboot command seems to do just that, nothing different from a normal reboot (or is there???).
Infoup seems to be a proprietary command, probably made for infomtic chips? (my theory is the command name is a combination of “infomtic” and “update”). It appears to have three options:
Code:
[/FONT]
[FONT=Tahoma]infoup inject[/FONT]
[FONT=Tahoma]Infoup clear[/FONT]
[FONT=Tahoma]Infoup reboot[/FONT]
I tried issuing the clear command and it appears to clean out /dev/mtd/mtd2, but not sure what good that gives us.

So, for right now we can’t seem to figure out how the update is actually burned into memory, which turns us to the only way we can reliably see the unit flash itself: the crippled miniature recovery option. When you boot with the “three finger salute” you are given an option to “press required keys” to recover. If you’re have hwver=11.2.0.6 and the DG2.02 firmware when you press the menu key again the unit is flashed back to a stock DG2.02 state. Hwver=11.2.1.5 units seem to be stuck with firmware DG2.01 and when trying to recover get a message that there is no recovery image and to try to recover from SD (which no one has figured out how to do).

I don’t know enough to do anything with this, but I hope someone in the community does. What seems like the next logical step it to decompile the boot image and find out exactly what happens when turning on with the “three finger salute” and how it goes about burning the file system. I started a new thread to see if anyone is able to do this…it’s way beyond my capabilities right now. If we can find out the mechanism of their basic recovery then we’ll be on our way to loading custom ROMs…I think.

I thought perhaps using the infoup inject command would change what’s inside /dev/mtd/mtd2 and therefore change what is burned when restoring the device. It doesn’t seem like this is the case, though, as injecting one of the early March update files doesn’t appear to change anything, nor did anything change when I issued the “infoup clear” command. Both times the recovery seems to burn a fresh copy of the DG2.02 firmware, which is what’s leading me to wonder where the heck the recovery image is stored.

Whew, that’s all for now, I just needed to do a brain dump of where we seem to be stuck.
 
Last edited:
Back
Top