Custom Sylvania ROM development

Status
Not open for further replies.
Xi2wiked said:
Oh well, no risk = no reward :)
Click to expand...

Great attitude! That was our approach as well when we were trying to identify the manual update process which finally succeeded to get us a manual Froyo update. Fingers still number from the number of factory resets.

In the thread http://www.androidtablets.net/forum...recovery-bootable-sd-card.html?highlight=resv you'll see we broke down the file structure to conclude "Recovery" is mtd2 "resv". Also the partition is in "raw" format. Nothing else was done with this information as we went on to the update process.

The "system" partition has successfully extracted into the various /system folders for modification.
$file_structure.JPG

One thought was to find a way to re-pack the image and burn using the IUW utility in USB Mode: Expert mode which allows each of the partitions to be selected individually.

$IUW_Expert_burn.JPG

All of the images (.bin, .img) in the picture above exist and they burn fine, just none of them are customized.

If you need any assistance with any of the development environment/tools/utilities (cygwin/XP or Unbuntu, unyaffs-4k/mkyaffs2image, HEX editor, HEX to Decimal conversion, adb, etc.) or anything else to push this along just ask.
 
Last edited:
Quick update, I had recovery on my tab! :) got it working while in terminal emulator. No, I wont say how yet. I want to make sure I can reproduce it. I also screwed my tab up in the process and am working on reviving her....
 
The recovery is not functional at all btw, being as its not even built for our device. anyone here know how to fix/port files? I went for a boot strap recovery. What it does is plants files in /system/bin which get accessed during boot, and will load a recovery
 
If anyones interested in helping me with this pm me and ill send the files and a how to, thatll get you where ive gotten so far also, dont attempt this unless you positively know how to fix your tab if/when you mess it up lol
 
Xi2wiked said:
Heres the pics I promised :)

A picture is worth a thousand words......
Click to expand...

Congrats Xi2wiked! Can't view images though it's asking to sign in, could you insert them in a post? Edit your post, "Go Advanced" and you can insert the images inline with the post.

RECOVERY: /dev/block/mtdblock2 is just the raw data of a *.ius file

Here's another discovery that may assist the recovery/custom process - /dev/block/mtdblock2 "resv" is just the raw data from an *.ius file!
$resv_img.JPG

If you pull an image of that partition it will load in the IUW tool since it's a multi-part update file with an IUW header, U0, UBOOT, Ramdisk, Kernel, and System images. infoTM's recovery process does nothing more than burn the *.ius file as we are doing in the manual update process. Therefore, if we can repack an custom *.ius file and push to mtd2 then apply the three finger factory reset the new image should be burned to the device.

$mtd2resv.JPG

Or, what about wiping mtd2 then you would receive the "No recovery image is found, try recover from SD" when attempting a three finger factory reset and the device would read from the sd card burned with the custom *.ius file.

Now how to build a custom *.ius file to burn?
 
Last edited:
cfrockit said:
Congrats Xi2wiked! Can't view images though it's asking to sign in, could you insert them in a post? Edit your post, "Go Advanced" and you can insert the images inline with the post.

Here's another discovery that may assist the recovery/custom process - /dev/block/mtdblock2 "resv" is just the raw data from an *.ius file!
View attachment 2498

If you pull an image of that partition it will load in the IUW tool since it's a multi-part update file with an IUW header, U0, UBOOT, Ramdisk, Kernel, and System images. infoTM's recovery process does nothing more than burn the *.ius file as we are doing in the manual update process. Therefore, if we can repack an custom *.ius file and push to mtd2 then apply the three finger factory reset the new image should be burned to the device.

Or, what about wiping mtd2 then you would receive the "No recovery image is found, try recover from SD" when attempting a three finger factory reset and the device would read from the sd card burned with the custom *.ius file.

Now how to build a custom *.ius file to burn?
Click to expand...

Thats great news.... Now can We build an aosp rom and instead of zipping it to flash, can we
Just repackage it as an ius and flash?
If anyone wants to build a custom rom or for that matter just edit a current 11.2.1.8 update file and try to repack, ill flash it.
No risk = no reward right? :) btw my wife thinks im nuts because of how happy getting the recovery to work made me.....
Some people just dont understand lol
 
Got a quick easy edit we can try, replace the current launcher with adw.launcher, repack and we can see if she'll flash. Dont know how to package as an ius though.... Propably be easier to make it a .bin file?
 
Last edited:
Work In Progress - Investigation of the header information of an *.ius (infoTM Update Wrap) file in preparation of creating a custom update file.

  • The first 200 bytes of an *.ius file are the header information for the IUW Version 1.0 application (IUW.exe).
  • The header includes the image contents (magic number, header and payload checksums) of an update file.
  • The image contents are displayed by IUW.exe as "Wrap Information:" as shown below.
$header.JPG

In the header information the following is known -

  • "WUI" is repeated multiple times to signify data read by IUW.exe
  • The 1st instance is followed by the magic number as reported in /proc/cmdline and the FileNum: as reported in the wrap information which includes the "hwver".
Code: 
C:\>adb shell cat /proc/cmdline
console=ttySAC3,115200 androidboot.mode=normal [B]bmagic=0xeef07901[/B] [B]hwver=11.2.0.6[/B]
  • There will be a varying number of "WUI" following the first depending on how many images are contained in the *.ius update file.
  • Except of the 1st instance described above, the data following each of remaining "WUI" represents the various images (U0, UBOOT, Ramdisk, Kernel, Userdata, System, etc.) that are included.
  • Each image is defined by a code.
  • The codes to represent the various images present in the multi-part *.ius update file are "00" U0, "01" UBOOT , "02" RD, "04" LK, "07" ADR_USER, "09" ADR_AS
  • In the header the FileNum: 11.2.0.5.1.3 is a string of 6 sets of digits and NOT represented sequentially but in two sets of three. 05 00 02 03 01 0B=11
$resv_img1.JPG

While all of this information is nice to know, the intent is to be able to package a custom update file that will install using the manual update process.
 
Caution! Installing BusyBox bricked my tablet.
My tablet is a EX7 upgraded to 2.2.1 (Beta 4) though it also bricked my stock version.

It installed ok, but the tablet would not boot up again, I didnn't do anything with BusyBox, just installed it.

It was a soft brick, I could re-burn everything OK.

I got BusyBox from Amazon App market.
 
Status
Not open for further replies.

Similar threads

cfrockit
Hardware ID "hwver=11.2.3.1"
2
Replies
17
Views
18K
Jv90
Jv90
cfrockit
InfoTM Update Wrap Files (*.bin,*.ius)
Replies
4
Views
45K
momchi
M
cfrockit
SYTAB7MX Hardware Id "hwver" 11.2.7.4 InfoTMIC Update Wrap (.ius)
2
Replies
18
Views
18K
mattglad
M
cfrockit
Other infoTMIC 10" tablets getting "official" update to 2.2
Replies
5
Views
11K
manupriyam
M
cfrockit
Solution to Experiment gone wrong, stuck on logo, No recovery image is found
Replies
12
Views
15K
bobhobbs
B
Back
Top