I wanted to write my own kernel, and since nobody has released any tools for creating those blob files I had to reverse engineer it myself.
The attached script is fairly simple, but has to be used with extreme caution. I have kept it as simple as possible and currently it will only be able to do single partition writes to boot or recovery. It can easily be extended to multiple partition writes or other types of partitions, but for our purposes I do not see any use case for that. For me writing recovery and boot is all I need. Anything else can be written from system directly.
Please note that I accept no responsibility for bricks. This script has not yet been tested much, but every test that has been done with boot or recovery images has been successful. In particular check if you get any error messages from the script, if so DO NOT FLASH THE BLOB (which could still have been created)!
Please note that I have only used this script under Linux and it has a few standard dependencies (which are all part of most standard Linux distros). It might well work under cygwin or similar but I have not yet tested that.
The usage is very simple:
mkblob [boot|recovery] [imagefile] [bloboutput]
so for example
mkblob boot /tmp/boot.img /tmp/blob
After you have the blob file you can flash it staging using
dd if=/sdcard/blob of=/dev/block/mmcblk0p4
Make sure you check md5sums after the transfering of the blob to the eeepad to be safe. Once you have flashed it to the staging partition simply reboot the Transformer and you will see a progress bar when it starts booting at which point the transformer is flashing the partitions. Once it's done you should be all set.
I recommend that you do not flash boot and recovery without testing in between. If you break both, you have a brick!
A full rooting guide and some prepared blobs (enough for most purposes!) can be found on @BumbleDroid and @DroidRay blog at
http://androidroot.mobi/asus-eee-pad-transformer-tf101-root-cwm-recovery/ .
Credits go to @BumbleDroid for some interesting discussions and the patching and building of a functional CWM recovery.
Please let me know if you had success or problems with this
| Attachment | Size |
|---|---|
| mkblob.gz | 1.24 KB |
Comments
Some technical details
The basic idea is very simple. There is a header that is in the file (the header I have in the script is slightly longer since it e.g. contains a value which tells the bootloader that there is just one partition in the blob. That value is technically variable, but I didn't need that feature).
The crucial line is then
head="$header $partaddr $filepos $length 01 00 00 00"
whcih tells you exactly what the file looks like before the partition contents are pasted in.
$partaddr is the internal partition address of the Eee Pad, so is different depending on whether we flash boot or recovery. And those are the same in the two released Eee Pad versions (WW/US) [I did check that in the ASUS Firmware releases]. You can see in the script what they are.
$filepos is the hex address of the partition start in the blob. Again that is constant in my script as we only have one partition - it can very easily be adapted to accept multiple partitions, though I couldn't see when I would need that.
$length is the size of the partition in hex.
One thing to note is that each 4-byte hex value is reversed in the file (as in the bytes are reversed), ie the address 0x4C is actually 0x0000004C . That applies to all the values above.
I'm not entirely sure what the value '01 00 00 00' (which actually is just 0x1) represents but it is constant in all blobs for all partitions. It could be that that value is an override flag if one wanted to ignore a partition or similar, but I haven't tested that.