Jump to content


Photo

Official X10 Airpad ROM image


  • Please log in to reply
12 replies to this topic

#1 kevinw

kevinw

    Member

  • Jr. Member
  • PipPip
  • 13 posts

Posted 09 September 2011 - 11:48 PM

Here is the official X10 Airpad ROM

http://dl.dropbox.co...2225/update.img

Here are the tools to update the ROM

http://dl.dropbox.co...rpadUpdater.zip

To update your ROM:

1. Download AirpadUpdater.zip and update.img. Unzip AirpadUpdater.zip. It contains driver files and a flash program.
2. Power off your tablet
3. Hold down the ESC button on your Airpad and then connect the USB cable from your tablet to your computer. Release the ESC button after the USB cable is connected.
4. If you have not already installed the Rockchip driver file, install the appropriate Windows driver from AirpadUpdater.zip
5. Run RKBatchTool.exe. If you have installed the RK29 driver and successfully connected the Airpad in flash mode then the first box in the connected devices lists will appear green.
6. Select the … button and choose the update.img
7. Press Upgrade
8. It will take several minutes for the ROM to flash, the Airpad to reboot and reinitialize, and then for the Airpad to reboot once more. Do not interrupt this process.

#2 jkpjj

jkpjj

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 130 posts

Posted 10 September 2011 - 02:37 AM

Thank you very much for this.

Before I endeavour to flash the Lanyu 910 with an image for a somewhat different hardware, it would be nice to try to create a sure way back. I'm not yet aware of the exact details of the flashing process, so bear with me, a few beginner questions and perhaps also some more advanced, hopefully I'm not totally on the wrong track here:

1) I have copies of mtdblock0..mtdblock8 (mtdblock 9 seems to be the internal user data storage at /flash) copied from my device - is it possible to build a flashable image from these? Anyone have a tested solution or a program to do this?

It's obvious mtdblock4 correspons to system.img, and many of the others look pretty straightforward, too, but not exactly sure, is there a similar one-to-one correspondence. Here's what /proc/mtd shows. Might it be that "recovery" contains the whole flashable .img file for - hmm, what? system perhaps won't fit there, maybe kernel & boot?

# cat /proc/mtd
dev: size erasesize name
mtd0: 00400000 00004000 "misc"
mtd1: 00800000 00004000 "kernel"
mtd2: 00400000 00004000 "boot"
mtd3: 00800000 00004000 "recovery"
mtd4: 10000000 00004000 "system"
mtd5: 10400000 00004000 "backup"
mtd6: 07400000 00004000 "cache"
mtd7: 10000000 00004000 "userdata"
mtd8: 00400000 00004000 "kpanic"
mtd9: b4400000 00004000 "user"

2) Is it possible to flash only one mtd "partition" (not sure what's the correct term) with the Rockchip flash tool, e.g. to flash only the kernel, or only the system?

3) Apparently it's in principle technically possible to just "dd" stuff into the MTD on a running Android system. Obviously there are limitations to this - you shouldn't dd over the mounted root file system, and flashing the kernel apparently depends on whether the kernel executes in place (I read it works like this on some systems). Any knowledge how this works on Rockchip 2918 / Lanyu 910?

4) I think I read somewhere that it's possible to flash/boot a Rockchip device from a SD card. Would it be possible to make a memory-card-bootable android with this, much like a USB-bootable desktop? This would allow to retain the original OS for safety and use a different OS with little risk.

5) Does the flashing normally overwrite the user flash (mtdblock9, /flash)? If not, is there still some risk to losing the data by e.g. flashing modifying the "partition table" (mtd setup)

I guess it shows in the questions that I'd rather use some linux tools for flashing than a Windows program.

Edited by jkpjj, 10 September 2011 - 02:38 AM.


#3 jkpjj

jkpjj

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 130 posts

Posted 11 September 2011 - 02:56 PM

I found a couple of answers to my questions:

2) Is it possible to flash only one mtd "partition" (not sure what's the correct term) with the Rockchip flash tool, e.g. to flash only the kernel, or only the system?

Yes, apparently - editing "update-script" inside the image seems one way to do this.

"I guess it shows in the questions that I'd rather use some linux tools for flashing than a Windows program."

Another possibility to update only part, and with a linux tools, appears to be using firmware update utilities found at https://sites.google...let/apad-irobot

#4 fun_

fun_

    Advanced Member

  • Hero Member
  • PipPipPip
  • 525 posts

Posted 12 September 2011 - 04:23 AM

try rkdump to dump update.img from backup partition(mtd5).
http://androtab.info...p/devel/rkutils

EDIT:
hmm. on rk28x8 tablets, mtd driver is very strange, e.g. /dev/mtd/mtd* are useless. this is one of reason why I made special tool for rk28 tablets.
but, from jkpjj's /proc/mtd, it seems normal... very interesting :) I guess some common tools may work with rk29...

Edited by fun_, 12 September 2011 - 04:32 AM.

http://androtab.info/

#5 jkpjj

jkpjj

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 130 posts

Posted 12 September 2011 - 06:52 AM

Thanks - but file from mtdblock5 doesn't appear to be in the format that rk29xximagetools expects (tried both with adb pull mtdblock5 and the smaller one with rkdump):

File header: RKAF
Read loader's offset
Read loader's len
Read update.img's offset
Read update.img's len
Output Loader
offset(0x0) len(0x0)
Output updata.img
offset(0x0) len(0x0)
Unpack updata.img to Temp folder
Check file...

#6 fun_

fun_

    Advanced Member

  • Hero Member
  • PipPipPip
  • 525 posts

Posted 12 September 2011 - 08:04 AM

Thanks - but file from mtdblock5 doesn't appear to be in the format that rk29xximagetools expects (tried both with adb pull mtdblock5 and the smaller one with rkdump):

File header: RKAF


use APFTool.exe to unpack
http://androtab.info/

#7 jkpjj

jkpjj

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 130 posts

Posted 12 September 2011 - 11:25 AM

use APFTool.exe to unpack


Thanks, I thought I tried that, too, but apparently I botched something, as now it works.

#8 Csharp

Csharp

    Newbie

  • Jr. Member
  • Pip
  • 7 posts

Posted 16 September 2011 - 08:58 AM

Is there a way to unpack boot.img, it seems to have a KRNL header.
Really want to modify it... recovery.img seems to have the same problem?

#9 jkpjj

jkpjj

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 130 posts

Posted 16 September 2011 - 09:16 AM

The format consists of a header of 8 bytes and then a gzip-compressed cpio archive and then a checksum or something like it - there's a description at http://www.slatedroi...magetools-v21/.

On a GNU/Linux system I just used tail -c +9 < mtdblock2 > initrdinitramfs.gz and then gunzip (which ignore checksum as trailing garbage) to uncompress, then cpio to look at it / extract.

Initrd Initramfs is a name used for these gzip-compressed cpio archives which are extracted at boot, for example /boot/initrd.img-2.6.35-22-generic on desktop/laptop. boot on Lanyu contains init.rc, init.rk29board.rc and the rest of the stuff at root file system.

Recovery.img is in the same format.

Is there a way to unpack boot.img, it seems to have a KRNL header.
Really want to modify it... recovery.img seems to have the same problem?


Edited by jkpjj, 16 September 2011 - 03:25 PM.


#10 Csharp

Csharp

    Newbie

  • Jr. Member
  • Pip
  • 7 posts

Posted 16 September 2011 - 09:44 AM

The format consists of a header of 8 bytes and then a gzip-compressed cpio archive and then a checksum or something like it - there's a description at http://www.slatedroi...magetools-v21/.

On a GNU/Linux system I just used tail -c +9 < mtdblock2 > initrd and then gunzip (which ignore checksum as trailing garbage) to uncompress, then cpio to look at it / extract.

Initrd is a name used for these gzip-compressed cpio archives which are extracted at boot, for example /boot/initrd.img-2.6.35-22-generic on desktop/laptop. boot on Lanyu contains init.rc, init.rk29board.rc and the rest of the stuff at root file system.

Recovery.img is in the same format.


Thanks! It worked flawlessly, except with kernel.img.
So I wonder, is this kernel.img actually used, or in ANOTHER format? They seem to have a lot of formats going on so it confuses me...
Also, when rebuilding these images, what procedure do I have to follow?

#11 jkpjj

jkpjj

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 130 posts

Posted 16 September 2011 - 01:35 PM

I've been thinking about whether there's a hook system which could be used to have the tablet to run as root some of my own scripts, without reflashing any custom images. One goal would be to get the tablet rooted in the usual sense at each boot without flashing and without using adb from computer. System is not writable, but a modified copy of system mounted on /system could be one way to do this.


I haven't found a hook system as such, but it does seem perhaps I could piggyback the starting of my own "boot script". A couple of ideas how this could be done, which I'm outing here, so people more familiar can comment if they have a chance of working

1) connect to adbserver from local Android application; not sure how to do this or if it's possible

2) add a parameter to rild in /data/local.prop - something like

setprop rild.libpath /data/libril-with-boot.so

Have /data/libril-with-boot.so be otherwise like normal libril, but check if my boot script has been run, and if not, have it run the script.


If there's a simpler way, that'd be welcome too.

Edited by jkpjj, 16 September 2011 - 05:00 PM.


#12 Aiah

Aiah

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 106 posts

Posted 16 September 2011 - 03:50 PM

The kernel.img (extracted from the firmware images with the wendal tools) seems to be different.
But it realy looks like a normal kernel

* I stripped the header (8bytes)
* I ran it through a disassembler [loading at c0408000]
* I checks various function entrie points (usbin /proc/kallsyms and the vanilla kernel source)
all functions i check where at the right point

* the method discriped in the rk29xx wendal thread can be used for the kernel to

- using wendal tools extract the kernel.img
- ls -l kernel.img (and note the file size)
- strip header & footer
dd if=kernel.img of=kernel.bin bs=1 skip=8 size=(filesize-12)
- reapply header & footer
rkcrc -p kernel.bin newkernel.img (ps modify rkcrc with correct header tag)
- verify kernel.img newkernel.img

rkcrc recreated an exact copy from the stripped kernel.bin
P.S. 2nd 4 bytes from header is the size

bytes 0..3 KRNL
bytes 4..7 08 bd 7b 00 (little endian) 0x7BBD08 = 8109320 = size of kernel

#13 jkpjj

jkpjj

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 130 posts

Posted 16 September 2011 - 05:18 PM

Thanks, I can confirm this on my system - I assumed a kernel would be recognized by "file" and have something recognizable at the start like the x86 vmlinuz format has, but that clearly isn't the case.

The kernel.img (extracted from the firmware images with the wendal tools) seems to be different.
But it realy looks like a normal kernel

* I stripped the header (8bytes)
* I ran it through a disassembler [loading at c0408000]
* I checks various function entrie points (usbin /proc/kallsyms and the vanilla kernel source)
all functions i check where at the right point

* the method discriped in the rk29xx wendal thread can be used for the kernel to

- using wendal tools extract the kernel.img
- ls -l kernel.img (and note the file size)
- strip header & footer
dd if=kernel.img of=kernel.bin bs=1 skip=8 size=(filesize-12)
- reapply header & footer
rkcrc -p kernel.bin newkernel.img (ps modify rkcrc with correct header tag)
- verify kernel.img newkernel.img

rkcrc recreated an exact copy from the stripped kernel.bin
P.S. 2nd 4 bytes from header is the size

bytes 0..3 KRNL
bytes 4..7 08 bd 7b 00 (little endian) 0x7BBD08 = 8109320 = size of kernel