Custom Sylvania ROM development


Senior Member
Dec 26, 2010
Custom Sylvania ROM development

One of the challenges of creating a custom ROM for the Sylvania tablet is getting the source code.

Short of that being provided anytime soon, it has been suggested we can work backwards using the BETA Froyo *.ius update files.

However, the update files are custom multi-part files containing several parts of the firmware and Android OS - U0 (u-boot-nand.bin), Ramdisk.img, Linux Kernel, User Data, and system.img.

Stragulus of xda, who is doing [ROM] Flytouch2 Froyo development which is a similar infoTM based device, provided some assistance in explaining how these files can be pulled apart into separate pieces. He also joined the discussion to provide direction on how to modify parts of the images to create a custom modification.

Not knowing enough about what he explained but interested enough to investigate further, a very manual method has been identified to extract the various parts of the OS.

The parts extracted from a ius file can now be examined and modified and then manually burned to the device using the InfoTM Update Wrap (IUW) Version 1.0 utility USB mode: Expert burn method.

How to manually extract the various parts from the ius file.

Requirements: Hex Editor, IUW Version 1.0 utility, ability to use these tools

Using the IUW Version 1.0 utility, Choose a wrapped image: for example

Each ius file is a multi-part file containing several parts of the Android OS - U0 (u-boot-nand.bin), RD - Ramdisk.img, LK - Linux Kernel, ADD_USER - User Data, and ADD_AS - system.img.

Observe the Image List: information contained in Wrap Information: which corresponds to these parts.

Company: error
Board:    error
Size:    64 MB

Image List:
U0 (246 KB)
RD (173 KB)
LK (2376 KB)
ADD_AS (62934.5 KB)
Per Stragulus suggestion, using this information (size in KB * 1024 bytes) will lead us to identify the beginning and end of each section. Once these breaks have been identified each section can be copied to an individual file.

Open the ius file in a HEX Editor -

The beginning of the file is header information for the InfoTM Update Wrap (IUW) utility followed by 00 padding. Leading us to Offset: 0x200

U0 - u-boot-nand.bin

Offset: 00000200 is the beginning of U0 - u-boot-nand.bin

Using the Wrap Information for U0, it size is 246KB * 1024 = 251904 in Decimal.

Converting to HEX 0x3D800 then adding to beginning offset 0x200 gives us the end location - Offset: 0003D9FF.


The end of u-boot-nand.bin leaves us at the beginning of Ramdisk.img. As suggested also by Stragulus we could have searched for gzip headers (0x270519).

Now select from 0x03DA00 using Length of 173KB * 1024 = DEC 177152 = 0x02B400 ending at 0x068DFF is Ramdisk.img.

For a HOWTO: Unpack, Edit, and Re-Pack Boot Images - Android Wiki see the section on Unpacking, Editing, and Re-Packing the images


The next section also begins with header (0x270519). LK or Linux Kernel begins at 0x068E00 and it's length is 2376KB * 1024 = DEC 2433024 = 0x252000. Adding to the beginning offset this section ends at 0x2BADFF.


Starting at the end of the last section, 0x2BAE00, using the length of 4.5KB from the Wrap Information the length is 0x001200, therefore the end is at offset 0x2BBFFF.


The end of the last section placed us right back at the last header (0x270519). From here to the end of the file is the system.img.

In summary:

[FONT=Courier New]

Description:     Address      Length       End
u-boot-nand      00000200     0003D800     0003D9FF
Ramdisk          0003DA00     0002B400     00068DFF
LK               00068E00     00252000     002BADFF
USER_DATA        002BAE00     00001200     002BBFFF
SYSTEM           002BC000     03D75A00     040319FF[/FONT]
Each section can now be selected and paste into a new file, creating individual sections of the update file used in the IUW Version 1.0 utility USB mode: Expert burn method.

DO NOT ATTEMPT TO BURN without understanding the potential risks. It is unknown if cutting/pasting the individual parts leaves them intact.

Work In Progress - Investigation and modification of these parts can now begin. Enjoy and have fun!

Updated 04/23/2011 - Additional information provided by Stragulus

As requested, a tutorial on how to extract images from the *.ius files. Post #2

Packaging files for 2-stage flash method (from flytouch 2) Post #3
Last edited:
As requested, a tutorial on how to extract images from the *.ius files.

I used ghex2 on Ubuntu as hex editor. But any hex editor on any OS will do, just google for one. If you don't grasp the concept of hex editors, you shouldn't bother with this!

To locate ramdisk.img:

ramdisk.img consists of a u-boot header which is 64 bytes long, followed by a gzipped root image.

To locate uImage, search for the first bytes of the u-boot header, which is always: 0x27051956. If you find this in your editor (edit, find, then key in the hexadecimal bytes), you should see a readable label for the image (e.g. 'ramdisk' or something similar) a little past the bytes you just searched for.

Now that you have found the header, you know where the gzipped image is, as that is 64 bytes past the offset of the byte-string you just searched for. So take note of the offset of the 0x2705.. bytes, add 64 to it, and that's where your gzipped image is.

To extract the gzipped image, you simply try to uncompress it using gzip in ubuntu. Here's how I did it (replace GZIP_OFFSET with the one you just calculated):

dd if=file.ius bs=GZIP_OFFSET skip=1 | gzip -cd - | gzip > ramdisk.gz

In the 2.0.6 image the offset is 0x3DA00 hex, that's 252480 decimal. In linux, you can do this to calculate: printf %d 0x3da00, or just use an online hex/dec converter.

Now, you have the gzipped ramdisk image. Notice that I compress it again right after uncompressing, as the uncompression is only there to find all of the data in the .ius file.

Since uImage contains both the u-boot header *and* the zipped ramdisk, you need to get the u-boot header as well, and prepend it to the ramdisk.gz you just created. We use dd again to extract it, using the offset of the 0x2705.. byte-string:

dd if=file.ius bs=1 skip=UBOOTHEADER_OFFSET count=64 of=ramdisk.uboot_header

Now, concatenate both files to produce uImage:

cat ramdisk.uboot_header ramdisk.gz > ramdisk.img

Finding the kernel

The uImage file also starts with a 64-byte u-boot header, just like the ramdisk above. So search for 0x27051956 again. This time, the label following it will be something like 'Linux-'.

Now, to extract it, we need to know how big it is. If you run the windows IUW tool, it will display a list of images contained in the IUS file, including their size in KB. The kernel is "LK", so for 2.0.6 it reports:

LK (2376 KB)

Round that size up a few kilobytes (e.g. 2380), and use that to extract. For 2.0.6, the offset starting at the u-boot header is 0x68E00 hex, 429568 decimal:

dd if=file.ius bs=1 skip=429568 count=$((2380*1024)) of=uImage


In the *.ius image, the system.img is also compressed with gzip. So now, we search for the gzip header, which always starts with the byte-range 0x1F8B08. There will be multiple gzipped data blocks in the IUS file, so you'll have to search a bit until you find the right one. We know that system.img is pretty large, so you know you've found system.img if the resulting file is big (around 60MB).

When you've found an offset with the gzip byte-header, try to extract the gzipped data, similar to how we did this above for the zipped ramdisk:

dd if=file.ius bs=GZIP_HEADER_OFFSET skip=1 | gzip -cd > outfile

In the 2.0.6 ius, the offset is 0x2BC040 hex, 2867264 decimal

If this produces a big enough outfile, you'll know you have found system.img. Verify by running the 'file' command on it:

$ file outfile
outfile: VMS Alpha executable

Rename file: mv outfile system.img


Just take this from another firmware, it's a completely empty yaffs2 filesystem. Or just enter recovery mode on your tablet and do a factory reset, this has the same effect as flashing an empty filesystem.


I don't know how to locate this. It's in the .ius file preceding the ramdisk, so if you know the offset of the ramdisk, you only have a limited amount of data to search through. But you might just use IUS to flash it, and all the other images, to your tablet, as you only need to update U0 once. After that, you can simply flash other images as you see fit.
Another quick tutorial on creating ramdisk images on linux:

Given an uImage file:

mkdir ramdisk
cd ramdisk
dd if=/path/to/uImage bs=64 skip=1 | gzip -cd | cpio -id

You now have all the ramdisk contents. Repackage into ramdisk.img:

cd ramdisk
find . | find . | cpio -o -H newc | gzip > ramdisk.gz
mkimage -T ramdisk -A 'ARM' -C none -n 'ramdisk' -a 0x41000000 -e 0x41000000 -d ramdisk.gz ramdisk.img

On ubuntu, you need to install the uboot-mkimage package first.

I would think that the 2-stage flash method I developed for the flytouch2 would work on the Sylvania tablets as well. Instead of switching the cards from slot 1 to slot 2 (which you don't have), you'll have to remove the card from the slot, reboot, and then immediately put it back in. E.g. don't boot off of it again, as it will reflash stage1, but put it in immediately after it boots, so the second stage boot process will be able to locate the files to be flashed on the sd-card.

A few things might need to be changed for this to work. To do this, you must extract the ramdisk in the /android folder and modify file system/bin/stage2 - this file is what is run after it first reboots to flash the second stage.

I _think_ on the sylvania tablets, the external card slot is actually the *second* sd-card, as many of these tablets use an internal sd-card. So you'll have to change the line that mounts the sd-card:

$BUSYBOX mount -n -t vfat -o rw /dev/block/mmcblk0p1 /mnt/sdcard

You will likely have to change mmcblk0p1 to mmcblk1p1.

But the next step is CRITICAL, and must be done by someone who knows that the crap they're doing: Find out where to flash the images to!

E.g. this is how system.img in /stage2 is flashed on the flytouch2 tablet:


$BUSYBOX mount -n -t yaffs2 /dev/block/mtdblock3 /mnt/system
cd /mnt/system
$BUSYBOX tar -xzpf $SYSTEM_TAR >/mnt/sdcard/system_tar_out.txt 2>&1

In this bit of code, /dev/block/mtdblock3 (nand flash on flytouch2) needs to be changed to the mount point of the /system partition (/dev/block/mmcblk0p<something>?)

Also, ramdisk is overwritten in this stage, on flytouch2:

$BUSYBOX cat $RAMDISK_STAGE2 > /dev/block/mtdblock0

/dev/block/mtdblock0 is the ramdisk partition on flytouch2, find out which one that is on the sylvania tablets!

Finally, you don't want the second stage flash procedure to reboot the tablet immediately after flashing, as in these tablets, it will immediately start booting from the sd-card and flash stage1 again! So uncomment these lines at the end of /system/bin/stage2:

# Reboot tool? Reboot tool? Where we come from, we don't need no stinking
# reboot tool.
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

You could replace them by something else that indicates flashing is done. The one thing I was able to use at this stage was the screen's brightness, although it should be possible to write to the screen as well if you know how. ;) Anyway, changing brightness is easy to spot in the stage2 file.

Once you have modified stage2, you'll have to repackage ramdisk.img and put it back in /sdcard/android/ramdisk.img

For the 2-stage flashing process, you'll have to repack system.img into a tarball. For this, you'll need to extract system.img using unyaffs, and repack it using tar, e.g.:

mkdir system
cd system
unyaffs-4k /path/to/system.img
<modify stuff>
tar -cvzf /sdcard/stage2/system.tar.gz .
md5sum /sdcard/stage2/system.tar.gz|cut -d' ' -f1 > /sdcard/stage2/system.tar.gz.md5

You'll need a patched unyaffs version (I named this unyaffs-4k) as it uses different settings, you can find the one I used here: Just compile it under linux with make. If it doesn't compile, you might need a 32-bits system!

The ramdisk.img extracted from the .ius file goes into /stage2/ramdisk.img, you just need to calculate an md5 checksum and add it to the sdcard as well:

md5sum /sdcard/stage2/ramdisk.img | cut -d' ' -f1 > /sdcard/stage2/ramdisk.img.md5

Hope this helps!
We're not alone in our frustration with many things not working as expected on these tablets. The devices noted in the link below are similar to the Sylvania/Disgo tablets in design/manufacturing/development.

They seem to have many more firmware versions and even a different method of updating but are still challenged with many of the same issues.

FIRMWARE RELEASES: firmware files, benefits and bugs for the Flytouch2 v2 /Superpad 2

Their development efforts can benefit us with partial fixes as they find ways to work around the issues with this tablet.

A short term goal is to create at least one custom ROM for the Sylvania/Disgo fixing some of the most annoying issues. It could then be easily burned to the device in case it has to be factory reset. Any assistance is welcome.

If you're interested in seeing how they put together their variations of firmware, download them, unpack them, investigate the file structure and the contents. Each one has a little something of interest. So far I've come across a new version of "My Pad", a stand alone "Update Check" (which of course states "Able to update" but we all know it's an endless loop so why bother), an Ethernet settings apk which is interesting because our tablet thinks it has an Ethernet port turned on by default. There are working Google Calendar apk's, a newer Flash version (still may not work without more tweaks), and a few more applications, which install and work on an updated DG2.20 device.

How to unpack the firmware - The downloaded firmware files may contain a zip archive "firmware-discovery". This can be extracted with 7zip

The extracted files may be in .tar format which 7z can unpack as well.

"system.tar" is an archive of the /system folder on the device which contains the applications, framework, libraries, etc.

A note of Warning - Don't attempt to use any of these firmware updates to update the Sylvania/Disgo tablet.
Last edited:
<5>[B]Linux version (neville@neville-desktop) (gcc version 4.4.0 (GCC) ) #16 Wed Feb 25 15:33:59 CST 2015[/B]
<4>CPU: ARMv6-compatible processor [4117b365] revision 5 ([B]ARMv6TEJ[/B]), cr=00c5387f
<4>CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
<4>Machine: IMAPX200
<4>Ignoring unrecognised tag 0x00000000
<4>Ignoring unrecognised tag 0x54410008
<4>Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 65536
<7>free_area_init_node: node 0, pgdat c0493a34, node_mem_map c055b000
<7>  Normal zone: 512 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 65024 pages, LIFO batch:15
<4>[B]CPU IMAPX200[/B] (id 0x13ab2000)
<6>IMAP Clocks, (c) 2009 [B]Infotm Micro Electronics[/B]
<6>iMAPx200: 67108864 bytes SDRAM reserved for memalloc at 0x4102c000
<4>IMAP Power Management, Copyright 2010 Infotm
<4>Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 65024
<5>[B]Kernel command line: console=ttySAC3,115200 androidboot.mode=normal bmagic=0xeef07901 hwver=[/B]
<6>PID hash table entries: 1024 (order: 0, 4096 bytes)
<6>Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>[B]Memory: 256MB = 256MB total[/B]
<5>Memory: 188416KB available (4188K code, 993K data, 128K init, 0K highmem)
<6>SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>Hierarchical RCU implementation.
<4>Console: colour dummy device 80x30
<7>FOUND calc 114583, divisor 36
<6>console [ttySAC3] enabled
<6>Calibrating delay loop... 789.70 BogoMIPS (lpj=1974272)
<4>Mount-cache hash table entries: 512
<6>CPU: Testing write buffer coherency: ok
<6>NET: Registered protocol family 16
<4>imapx200: Initialising architecture
<6>leaving imap_arch_init
<6>imapx200_dma_init: Registering DMA channels: ok!
<4>bio: create slab <bio-0> at 0
<5>SCSI subsystem initialized
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6><6>imapx200_iic0 imapx200_iic0: i2c-1: IMAPX200 I2C adapter
<6><6>imapx200_iic1 imapx200_iic1: i2c-2: IMAPX200 I2C adapter
<6>[COLOR=sienna]Bluetooth: Core ver 2.15[/COLOR]
<6>NET: Registered protocol family 31
<6>Bluetooth: HCI device and connection manager initialized
<6>Bluetooth: HCI socket layer initialized
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
<6>TCP established hash table entries: 8192 (order: 4, 65536 bytes)
<6>TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
<6>TCP: Hash tables configured (established 8192 bind 8192)
<6>TCP reno registered
<6>NET: Registered protocol family 1
<6>RPC: Registered udp transport module.
<6>RPC: Registered tcp transport module.
<6>RPC: Registered tcp NFSv4.1 backchannel transport module.
<6>[COLOR=blue]Trying to unpack rootfs image as initramfs...[/COLOR]
<6>Freeing initrd memory: 172K
<3>iMAP PWM Driver Init.
<6>ashmem: initialized
<6>ROMFS MTD (C) 2007 Red Hat, Inc.
<4>yaffs Feb 25 2015 04:58:25 Installing. 
<6>alg: No test for stdrng (krng)
<6>io scheduler noop registered
<6>io scheduler anticipatory registered
<6>io scheduler deadline registered
<6>io scheduler cfq registered (default)
<6>IMAPX200 Decode Driver probe OK
<6>Registered led device: lcd-backlight
<6>Imap Framebuffer Driver Initialization Start!
<6>LCD TYPE :: will be initialized
<4>Console: switching to colour frame buffer device 100x30
<6>fb0: imapfb frame buffer device
<6>fb1: imapfb frame buffer device
<6>Set Lcd Backlight Brightness 75
<1>imap-fb, 0x0, 0x0, 0x3e
<6>Imap Framebuffer Driver Initialization OK!
<6>HDMI Probe to add i2c driver for HDMI device
<6>[COLOR=blue]Device for HDMI will be Initializad[/COLOR]
<4>[EP932_Reg_Set_Bit]bfore set [8]6 bitMask[80]
<4>[EP932_Reg_Set_Bit] after set [8]86
<4>[EP932_Reg_Set_Bit]bfore set [8]86 bitMask[40]
<4>[EP932_Reg_Set_Bit] after set [8]c6
<4>[EP932_Reg_Clear_Bit]bfore clear [8]c6 bitMask[20]
<4>[EP932_Reg_Clear_Bit] after clear [8]c6
<4>[EP932_Reg_Clear_Bit]bfore clear [9]0 bitMask[20]
<4>[EP932_Reg_Clear_Bit] after clear [9]0
<4>[EP932_Reg_Clear_Bit]bfore clear [9]0 bitMask[10]
<4>[EP932_Reg_Clear_Bit] after clear [9]0
<4>[EP932_Reg_Set_Bit]bfore set [9]0 bitMask[8]
<4>[EP932_Reg_Set_Bit] after set [9]8
<6>Init HDMI device OK
<6>HDMI device add i2c driver OK!
<6>Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
<4>[imapx200_serial]:imapx200_serial_gpio_cfg for other
<6>imapx200-uart.0: imapx200_serial0 at MMIO 0x20e20000 (irq = 51) is a IMAPX200
<4>[imapx200_serial]:imapx200_serial_gpio_cfg for other
<6>imapx200-uart.1: imapx200_serial1 at MMIO 0x20e21000 (irq = 23) is a IMAPX200
<4>[imapx200_serial]:imapx200_serial_gpio_cfg for other
<6>imapx200-uart.2: imapx200_serial2 at MMIO 0x20e22000 (irq = 13) is a IMAPX200
<4>[imapx200_serial]:imapx200_serial_gpio_cfg for other
<6>imapx200-uart.3: imapx200_serial3 at MMIO 0x20e23000 (irq = 33) is a IMAPX200
<6>brd: module loaded
<6>loop: module loaded
<6>iMAPx200 NAND MTD Driver (c) 2009,2014 InfoTM
<6>Method: IRQ(1), DMA(1), SECC(0), DEC.RDY, CRCD++
<4>NAND ID: ad d5 14
<4>Assigned as H27UAG8T2MTR
<6>NAND device: Manufacturer ID: 0xad, Chip ID: 0xd5 (Hynix H27UAG8T2MTR)
<6>Scanning device for bad blocks
[B]<5>Creating 8 MTD partitions on "H27UAG8T2MTR":
<5>0x000001800000-0x000001a00000 : "ramdisk"
<5>0x000001a00000-0x000002000000 : "kernel"
<5>0x000002800000-0x00000a800000 : "resv"
<5>0x000012800000-0x00001e800000 : "system"
<5>0x00001e800000-0x00005c000000 : "userdata"
<5>0x00005c000000-0x000060000000 : "cache"
<5>0x000060000000-0x00007ff00000 : "Local-disk"
<5>0x00007ff00000-0x000080000000 : "panic"[/B]
<6>imapx200_ssim0 imapx200_ssim0.0: bitbang at c83e82c0
<6>gmac-univ Ethernet Driver, V1.0
<0>eth0: gmac-univ at d0838000 IRQ 32 MAC: 00:00:00:00:00:00 
<6>PPP generic driver version 2.4.2
<6>PPP MPPE Compression module registered
<6>NET: Registered protocol family 24
<5>usbmon: debugfs is not available
<6>ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<6>imapx200_usbhost20 imapx200_usbhost20: Infotm Ehci Controller
<6>imapx200_usbhost20 imapx200_usbhost20: new USB bus registered, assigned bus number 1
<6>imapx200_usbhost20 imapx200_usbhost20: irq 44, io mem 0x20c81000
<6>imapx200_usbhost20 imapx200_usbhost20: USB 2.0 started, EHCI 1.00
<6>usb usb1: configuration #1 chosen from 1 choice
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 4 ports detected
<6>ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
<6>imapx200_usbhost11 imapx200_usbhost11: Infotm Ohci Controller
<6>imapx200_usbhost11 imapx200_usbhost11: new USB bus registered, assigned bus number 2
<6>imapx200_usbhost11 imapx200_usbhost11: irq 26, io mem 0x20c80000
<6>usb usb2: configuration #1 chosen from 1 choice
<6>hub 2-0:1.0: USB hub found
<6>hub 2-0:1.0: 4 ports detected
<6>usbcore: registered new interface driver cdc_wdm
<6>Initializing USB Mass Storage driver...
<6>usbcore: registered new interface driver usb-storage
<6>USB Mass Storage support registered.
<6>usbcore: registered new interface driver usbserial
<6>usbserial: USB Serial Driver core
<6>USB Serial support registered for GSM modem (1-port)
<6>usbcore: registered new interface driver option
<6>[COLOR=green]option: v0.7.2:USB Driver for GSM modems[/COLOR]
<6>mice: PS/2 mouse device common for all mice
<6>---Headphone is not alive!
<6>input: gpio-keys as /devices/platform/gpio-keys/input/input0
<6>ads7846 spi0.0: touchscreen, irq 5
<6>input: ADS7846 Touchscreen as /devices/platform/imapx200_ssim0.0/spi0.0/input/input1
<6>iMAPx200 RTCv2, (c) 2009, 2014 InfoTM Microelctronics Co., Ltd
<6>using rtc device, imap, for alarms
<6>imapx200_rtc imapx200_rtc: rtc core: registered imap as rtc0
<6>i2c /dev entries driver
<6>Linux video capture interface: v2.00
<6>usbcore: registered new interface driver uvcvideo
<6>USB Video Class driver (v0.1.0)
<6>Bluetooth: Generic Bluetooth USB driver ver 0.6
<6>usbcore: registered new interface driver btusb
<6>[SDHCI0]:infoTM sdhci host driver init.
<3>[sdhci]-SDIO MAX CLOCK RATE = 96000000
<6>Registered led device: mmc0::
<6>mmc0: SDHCI controller on info_sdi0 [imapx200_sdi0.0] using ADMA
<3>wacom driver registered
<6>usbcore: registered new interface driver usbhid
<6>usbhid: v2.6:USB HID core driver
<6>logger: created 64K log 'log_main'
<6>logger: created 256K log 'log_events'
<6>logger: created 64K log 'log_radio'
<6>logger: created 64K log 'log_system'
<6>Advanced Linux Sound Architecture Driver Version 1.0.21.
<6>WM8987: Audio Codec Driver v0.12
<6>usb 1-1: new high speed USB device using imapx200_usbhost20 and address 2
<6>asoc: WM8987 <-> imapx200-i2s mapping ok
<6>mmc0: new high speed SDHC card at address a3d8
<6>mmcblk0: mmc0:a3d8 SD16G 14.9 GiB 
<6> mmcblk0: p1
<6>usb 1-1: configuration #1 chosen from 1 choice
<6>Proc-FS interface for audio codec
<6>ALSA device list:
<6>  #0: imapx200 (WM8987)
<6>TCP cubic registered
<6>NET: Registered protocol family 17
[COLOR=darkorange]<6>Bluetooth: L2CAP ver 2.14
<6>Bluetooth: L2CAP socket layer initialized
<6>Bluetooth: SCO (Voice Link) ver 0.6
<6>Bluetooth: SCO socket layer initialized
<6>Bluetooth: RFCOMM TTY layer initialized
<6>Bluetooth: RFCOMM socket layer initialized
<6>Bluetooth: RFCOMM ver 1.11
<6>Bluetooth: BNEP (Ethernet Emulation) ver 1.3
<6>Bluetooth: BNEP filters: protocol multicast
<6>Bluetooth: HIDP (Human Interface Emulation) ver 1.2[/COLOR]
<6>VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
<6>imapx200_rtc imapx200_rtc: setting system clock to 2011-05-01 04:09:21 UTC (1304222961)
<6>Freeing init memory: 128K
<7>FOUND calc 114583, divisor 36
<7>FOUND calc 114583, divisor 36
continued -
Last edited:
continued - dmesg

<6>yaffs: dev is 32505859 name is "mtdblock3"
<6>yaffs: passed flags ""
<4>yaffs: Attempting MTD mount on 31.3, "mtdblock3"
<4>yaffs: restored from checkpoint
<4>yaffs_read_super: isCheckpointed 1
<6>yaffs: dev is 32505860 name is "mtdblock4"
<6>yaffs: passed flags ""
<4>yaffs: Attempting MTD mount on 31.4, "mtdblock4"
<4>yaffs: restored from checkpoint
<4>yaffs_read_super: isCheckpointed 1
<6>yaffs: dev is 32505861 name is "mtdblock5"
<6>yaffs: passed flags ""
<4>yaffs: Attempting MTD mount on 31.5, "mtdblock5"
<4>yaffs: restored from checkpoint
<4>yaffs_read_super: isCheckpointed 1
<6>yaffs: dev is 32505862 name is "mtdblock6"
<6>yaffs: passed flags ""
<4>yaffs: Attempting MTD mount on 31.6, "mtdblock6"
<4>yaffs: restored from checkpoint
<4>yaffs_read_super: isCheckpointed 1
<7>FOUND calc 114583, divisor 36
<3>[COLOR=red]init: cannot find '/system/etc/', disabling 'flash_recovery'[/COLOR]
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 0
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 0
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 0
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 0
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 0
<6>warning: `rild' uses 32-bit capabilities (legacy support in use)
<4>Vivante GPU power is ON
<4>Entered imapx200_hifi_hw_params, channel = 2
<6>CPU_DAI name is imapx200-i2s
<4>freq is 16934400 
<4>i2s clkdiv = 45, cdclkdiv = 2
<6>----params is 44100
<4>state write is 0x22
<4>valrate is not equal the value of the srate 
<7>----src_addr0 is 483b0000, src_addr1 is 483b1000
<6>---congratulation, you can listen to the music!
<6>request_suspend_state: wakeup (3->0) at 21290897002 (2011-05-01 04:09:39.947697000 UTC)
<4>rtusb init --->
<4>=== pAd = d53c6000, size = 476392 ===
<4><-- RTMPAllocAdapterBlock, Status=0
<6>usbcore: registered new interface driver rt2870
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 0
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 724249387
<4><-- RTMPAllocTxRxRingMemory, Status=0
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 0
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 724249387
<4>Key1Str is Invalid key length(0) or Type(0)
<4>Key2Str is Invalid key length(0) or Type(0)
<4>Key3Str is Invalid key length(0) or Type(0)
<4>Key4Str is Invalid key length(0) or Type(0)
<4>1. Phy Mode = 0
<4>2. Phy Mode = 0
<4>NVM is Efuse and its size =2d[2d0-2fc] 
<4>3. Phy Mode = 0
<4>RTMPSetPhyMode: channel is out of range, use first channel=1 
<4><==== rt28xx_init, Status=0
<4>0x1300 = 00073200
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 0
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 724249387
<7>[OPS DEBUG] Get into asysops device driver
<7>[OPS DEBUG] Open asysops device node OK
<7>[OPS DEBUG] Get asysops ioctl
<7>[OPS DEBUG] Normal exit asysops ioctl, 724249387
<4>===>rt_ioctl_giwscan. 4(4) BSS returned, data->length = 505
<4>==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
<4>===>rt_ioctl_giwscan. 4(4) BSS returned, data->length = 529
<4>==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
<7>pendown state:0x1
<7>>>>>>Enter pendown state
Observations -

  • Is the reference to Bluetooth just a driver or is there actually hardware?
  • Maybe I'm missing it but where's the reference to the "orientation sensor" driver? Or is it these?
Last edited:
cat /proc/cpuinfo
Processor    : ARMv6-compatible processor rev 5 (v6l)
BogoMIPS    : 789.70
Features    : swp half thumb fastmult vfp edsp java 
CPU implementer    : 0x41
CPU architecture: 6TEJ
CPU variant    : 0x1
CPU part    : 0xb36
CPU revision    : 5

Hardware    : IMAPX200
Revision    : 0000
Serial        : 0000000000000000

cat /proc/meminfo
MemTotal:         188984 kB
MemFree:            7012 kB
Buffers:           23332 kB
Cached:            42604 kB
SwapCached:            0 kB
Active:            55724 kB
Inactive:          67140 kB
Active(anon):      25756 kB
Inactive(anon):    39520 kB
Active(file):      29968 kB
Inactive(file):    27620 kB
Unevictable:         368 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         188984 kB
LowFree:            7012 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         55800 kB
Mapped:            23584 kB
Shmem:              7980 kB
Slab:              10664 kB
SReclaimable:       6992 kB
SUnreclaim:         3672 kB
KernelStack:        1712 kB
PageTables:         5904 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       94492 kB
Committed_AS:    2638404 kB
VmallocTotal:     514048 kB
VmallocUsed:      101996 kB
VmallocChunk:     387076 kB
Last edited:
This is a 10" update file for a specific Hardware ID "hwver" which can be identified by inspecting the *.ius file with the infoTM Update Wrap tool. A 10"update file will brick a 7" device, do not install the incorrect update.
In member Xi2wiked located a previously unknown update file.
whilepoking around I found there's a new update formy, gonna burn and fla**** real quickto see what it is, then back to work on the market :)

A binary file comparison identifies the differences between the two files.

C:\Sylvania>fc /b
Comparing files and
00000018: 6D EB
00000019: 32 0E
0000001A: 5B 83
0000001B: 11 26
0000001C: 29 7C
0000001D: B6 C9
0000001E: 84 38
0000001F: 69 47
0001D0C4: 40 60
0001D0CD: 35 32
0001D130: 40 60
0001D138: 02 20
0001D139: 3B 30
00020A20: 0B 05
00020A4C: 40 60
0002AA6C: 31 32
0002AA75: 32 30
0002AA76: 33 39
0002AA78: 30 31
0002AA79: 32 39
0002AA7B: 32 31
0002AA7C: 31 38
The first differences 0x18 to 0x1F are in the "InfoTM Update Wrap Tool" (*ius) file header information.

The last part - Offsets 0x2AA6C to 0x2AA7C differences are the time stamp for U-boot. However, the version of the file is the same "627".

U-Boot 2009.08-svn627 (Jan 22 2013 - 09:19:18) in file

U-Boot 2009.08-svn627 (Jan 21 2013 - 23:02:21) in file

This U-boot version is different than the one originally identified that failed to install since it wouldn't respond to screen touches.
The version of U-boot is depicted in the image in parenthesis ( ) after the Hardware ID "hwver".

Work In Progress on remaining differences.
Last edited:
Let me know if you need anything from me in regards to this update, Im still messing around with it on my tab. Btw, if anyone wants to try editing/rebuilding a custom update for the let me know because I have absolutely no problem flashing it to my tab as long as I can get it to burn to my sd card :) I like being a test dummy!
I wanna try and get us a recovery. There is 2 recovery methods I'm looking into. Would prefer a flashable clockwork recovery .Img over the second choice though......
Last edited:
Gonna get me a new laptop to try and build a cwm. Recovery for our devices. What we need is for someone to get us the source code. I also want to try and build a cyanogen mod rom for our device.