[WIP] Asus Eee Pad Transformer native install

[Gary13579]

Wait... you wouldn't happen to be using an SBKv2 device, would you? When ASUS changed to SBKv2 to change the boot key, breaking our capability of using nvflash, they also started locking the bootloader, which should prevent you from flashing custom kernels. I'd be shocked if the bootloader accepts the custom bootimg.cfg but rejects the zImage kernel, but I guess it's a possibility worth mentioning.

[sim590]

I've noticed something. There's a difference between the boot.cfg file from your blob file and the one from the guy on the XDA forum thread.

XDA thread boot.cfg file
$this->bbcode_second_pass_code('', '
bootsize = 0x800000
pagesize = 0x800
kerneladdr = 0x10008000
ramdiskaddr = 0x11000000
secondaddr = 0x10f00000
tagsaddr = 0x10000100
name =
cmdline = nvmem=128M@384M mem=1024M@0M vmalloc=128M gpt video=tegrafb console=tty0 usbcore.oldscheme_first=1 lp0_vec=8192@0x1fbed000 root=/dev/mmcblk0p7 ro quiet splash
')
Your boot.cfg file
$this->bbcode_second_pass_code('', '
bootsize = 0x8d6000
pagesize = 0x800
kerneladdr = 0x10008000
ramdiskaddr = 0x11000000
secondaddr = 0x10f00000
tagsaddr = 0x10000100
name =
cmdline = nvmem=128M@384M mem=1024M@0M vmalloc=128M gpt video=tegrafb console=tty0 usbcore.oldscheme_first=1 lp0_vec=8192@0x1fbed000 root=/dev/mmcblk1p1
')

Where I want to bring your attention is on the variable "bootsize". When I use bootsize = 0x8d6000, flash fails, but when I use bootsize = 0x800000, it doesn't fail but I get a bunch of errors on loading:
$this->bbcode_second_pass_code('', '
Initramfs unpacking failed: LZMA data is corrupt
upli_phy_power_on: timeout waiting for phy to stabilize
upli_phy_power_on: upli write failed
tegra-ehci tegra-egci.1: Failed to power on the phy
g_ether gadget: rndis: can't bind, err 0
mxt_config_settings
power_supply dock_battery: driver failed to report `status' proterty
power_supply dock_battery: driver failed to report `status' proterty
sdhci-tegra sdhci-tegra.2
sdhci-tegra sdhci-tegra.2
sdhci-tegra sdhci-tegra.0
sdhci-tegra sdhci-tegra.0
Tegra protected aperture disabled because nvmap is using system memory
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[... bunch of errors I don't want to type ...]
CPU1: stopping <------------------- this is weird, isn't it?
unwind: Unknown symbol address c0008364
unwind: Index not found c0008364
Light sensor: a13000a_interrupt_handler
')
And from there, the tablet is frozen. I want to specify that, here I used linux3.1.10+.img while updating the cfg file with aboot--i686 program.

That's all I can say for now..

[Gary13579]

The bootsize should be irrelevant. All it does is tell abootimg how big to create the blob. It could be that the blob was too big to flash onto your tablet, but that should not be the case, as I imagine the boot partition is the same size on all TF101 tablets. I have read somewhere that recovery is stored on the same boot partition, so it's possible that your recovery image is larger than mine, leaving less space for the blob... but that's just my first guess.

As for the error, I fear that my original assumption was correct and that /dev/sda is not created at boot. This is totally a guess, but it could be that because /dev/sda is a USB device (the port that connects the TF to keyboard is USB), the block device isn't immediately available. Like I said though, this is just a guess. I strongly suggest just using the microSD card. The SD port isn't very... stable. If the screen wiggles too much, it'll cause a quick disconnect/reconnect of the keyboard, which also would unmount the SD card, which is pretty dangerous if you're running an OS off of it.

[sim590]

$this->bbcode_second_pass_quote('', 'A')s for the error, I fear that my original assumption was correct and that /dev/sda is not created at boot. This is totally a guess, but it could be that because /dev/sda is a USB device (the port that connects the TF to keyboard is USB), the block device isn't immediately available. Like I said though, this is just a guess. I strongly suggest just using the microSD card. The SD port isn't very... stable. If the screen wiggles too much, it'll cause a quick disconnect/reconnect of the keyboard, which also would unmount the SD card, which is pretty dangerous if you're running an OS off of it.

[Gary13579]

I very highly doubt that is the issue, at least if you've got it booting the kernel now. What filesystem is /dev/sda1?

[sim590]

The sdcard's only partition is sda1 and is in ext2.

[Gary13579]

Ah. The problem is probably the bootsize param. What you've set it to is only 8.1mb, while the kernel/initramfs image is 8.9mb. So it's probably cutting off the initramfs image, which causes the LZMA data corrupt error. So you need to increase the bootsize, and figure out why it isn't getting flashed.

What recovery are you using? I think I read somewhere that the recovery and kernel are stored on the same partition. It's possible that the recovery you're using is too large and it can't fit both on the same partition, but idk.

[sim590]

I use Clockworkmod recovery v5.8.3.4 (touch version, because the other was messing everything and wouldn't mount the internet sdcard).

[Gary13579]

Can you try the non-touch version from this thread? I believe this is the recovery I use, and it can definitely install zips from internal memory. http://forum.xda-developers.com/showthr ... ?t=1213723

It may not be a proper solution, but it would give us a lead to whether this is the issue or not. I imagine touch based recoveries would eat up more storage.

[sim590]

Ok! I'll try this and give you some news. But, in the meantime, may be this would help:

I've opened an "adb shell" session and mounted some partitions of the internal sdcard and looked at the size:
$this->bbcode_second_pass_code('', '
~ # df -ah
Filesystem Size Used Available Use% Mounted on
tmpfs 360.8M 48.0K 360.7M 0% /dev
devpts 0 0 0 0% /dev/pts
proc 0 0 0 0% /proc
sysfs 0 0 0 0% /sys
/dev/block/mmcblk0p2 512.8M 16.1M 496.7M 3% /cache
/dev/block/mmcblk0p1 503.9M 455.5M 48.4M 90% /mnt/blk1
/dev/block/mmcblk0p3 1.9M 1.9M 0 100% /mnt/blk3
/dev/block/mmcblk0p4 521.1M 8.3M 512.8M 2% /mnt/blk4
/dev/block/mmcblk0p7 13.0G 118.6M 12.8G 1% /mnt/blk7
')

Is mmcblk0p4 the boot partition? If so, there seems to have plenty of space.. I can't find information about the android partitions, you may know more than me about this!