Workaround for "read-only mode" - install to SD card

[joeyhewitt]

Here's a rough guide to how I got the official T-Mobile Froyo release running from the external SD card. Booting is done via fastboot tethered to a PC, but after that you can disconnect and keep running off the SD (provided you don't reboot.) If there's interest I can provide more info/files.

My tablet is stuck with stock recovery, and Android bootloops when I try to boot normally. I can "fastboot boot" CWM 3.0.2.0 (no success with anything else really -- still not sure why), so I've got root adb.

Get the official T-Mobile Froyo release, decrypt it with the matching recovery (also fastbooted), unzip it. Recompile both the recovery kernel and the Froyo OS kernel, hacking the SD devices to be swapped (external SD card becomes mmcblk3 and internal MMC memory is mmcblk2.) This is so you won't have to fiddle with references to device IDs in config files, installation scripts, etc.

Partition and format the SD card roughly according to the MMC partition layout for the partitions that show up in Linux, using GPT. Here're the commands I used from the recovery (shell, parted commands, shell):

umount /cache
umount /system
umount /data
umount /sdcard
parted /dev/block/mmcblk3

mklabel gpt
unit s
mkpart logical 34 35
mkpart logical 36 37
mkpart logical ext3 38 688166
mkpart logical ext3 688167 917543
mkpart logical ext3 917544 950312
mkpart logical ext2 950313 954409
mkpart logical ext3 954410 3051562
mkpart logical 3051563 3084331
mkpart logical 3084332 3117100
mkpart logical 3117101 3149869
mkpart logical 3149870 3182638
mkpart logical 3182639 3215407
mkpart logical ext3 3215408 3248176
mkpart logical fat32 3248177 7798552
mkpart logical 7798553 7831321
mkpart logical 7831322 7864090
name 1 SOS
name 2 LNX
name 3 APP
name 4 CAC
name 5 MSC
name 6 FDR
name 7 UDA
name 8 OLG
name 9 LGF
name 10 RES
name 11 RGN
name 12 VAR
name 13 USP
name 14 SDC
name 15 WP1
name 16 WP2

mke2fs /dev/block/mmcblk3p3; tune2fs -j /dev/block/mmcblk3p3
mke2fs /dev/block/mmcblk3p4; tune2fs -j /dev/block/mmcblk3p4
mke2fs /dev/block/mmcblk3p5; tune2fs -j /dev/block/mmcblk3p5
mke2fs /dev/block/mmcblk3p6
mke2fs /dev/block/mmcblk3p7; tune2fs -j /dev/block/mmcblk3p7
mke2fs /dev/block/mmcblk3p13; tune2fs -j /dev/block/mmcblk3p13
dd if=/dev/block/mmcblk2p15 of=/dev/block/mmcblk3p15 bs=1M
dd if=/dev/block/mmcblk2p16 of=/dev/block/mmcblk3p16 bs=1M

Note the dd for p15 and p16 -- these contain data like your device IDs and MAC addresses. I'm not sure if they are actually needed in Android (the bootloader can read the "real" read-only ones and passes them on the kernel command line), but to be safe we'll copy them.

The partition table then looks like this:

Model: SD SD04G (sd/mmc)
Disk /dev/block/mmcblk3: 4027MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17.4kB  18.4kB  1024B                SOS
 2      18.4kB  19.5kB  1024B                LNX
 3      19.5kB  352MB   352MB   ext4         APP
 4      352MB   470MB   117MB   ext3         CAC
 5      470MB   487MB   16.8MB  ext3         MSC
 6      487MB   489MB   2098kB  ext2         FDR
 7      489MB   1562MB  1074MB  ext3         UDA
 8      1562MB  1579MB  16.8MB               OLG
 9      1579MB  1596MB  16.8MB               LGF
10      1596MB  1613MB  16.8MB               RES
11      1613MB  1630MB  16.8MB               RGN
12      1630MB  1646MB  16.8MB               VAR
13      1646MB  1663MB  16.8MB  ext3         USP
14      1663MB  3993MB  2330MB  fat32        SDC   msftres
15      3993MB  4010MB  16.8MB               WP1
16      4010MB  4026MB  16.8MB               WP2

I shrunk data partitions down to fit my small SD card, and some are tiny because they aren't needed for anything but preserving the numbering.

Remove references to blob and boot.img from the update.pkg scripts (since they won't need to be flashed), rezip it, adb push it to the device, and install it using the CWM menu item.

Replace the kernel in boot.img (for SD device ID swap I mentioned above), and "fastboot boot" it. Mine looks like it's hung during the T-Mobile boot animation, but eventually gets through. Android should come up as normal, and you can disconnect from the PC and use it until you reboot. Mine's a little laggy on this first boot -- not sure if it's a slow SD card to blame, or if it's just how the first boot goes on this tablet. My 4G modem is not working right now, but everything else seems to work.

Superuser.zip can be installed with the same hacked CWM recovery.

I'm working on Honeycomb, but seem to be having early boot problems, and I'm wondering if "fastboot boot" is different enough from a regular flash boot that some kernels can't handle it.

P.S. If you're happy with what you're stuck with on /system etc, you could potentially use that from the built-in memory, and put only your read/write stuff on SD. You'd probably have to patch more initscripts etc to do that though.

 

[giveen]

There is no gingerbread reelase.

 

[joeyhewitt]

There is no gingerbread reelase.

Oops, meant froyo. My point was that the vold service in pre-HC releases might be easier to work with. I've booted my GB-based phone off of an SD card via fastboot before.

 

[Nocturnal_50]

Oops, meant froyo. My point was that the vold service in pre-HC releases might be easier to work with. I've booted my GB-based phone off of an SD card via fastboot before.

have you seen the method used in general involving the holding of all buttons for 2min then performing a wipe of dalvik cache?

 

[joeyhewitt]

have you seen the method used in general involving the holding of all buttons for 2min then performing a wipe of dalvik cache?

Tried (minus removing capacitive cover -- maybe if I get more desperate I'll try) and it didn't work for me. Although I tried wiping the cache first, since that's what you said here. I guess I'll try the other order. I've already verified that formatting /cache has no effect (contents are still there), so unless it has unexplained side-effects I'm not very optimistic.

P.S. Wait, 2 minutes?! You said 15 seconds before. Edit: saw your new instructions, I'll try that.

 

[Nocturnal_50]

Tried (minus removing capacitive cover -- maybe if I get more desperate I'll try) and it didn't work for me. Although I tried wiping the cache first, since that's what you said here. I guess I'll try the other order. I've already verified that formatting /cache has no effect (contents are still there), so unless it has unexplained side-effects I'm not very optimistic.

P.S. Wait, 2 minutes?! You said 15 seconds before. Edit: saw your new instructions, I'll try that.

to be honest I was drinking the night I got it resolved on mine so 2min would have seemed extremely short, so stick with the 2min for now... if it some how happens to fix it then I will be looking into alternative measures to get this thing back to RW (it will probably involve acquiring a RO streak)

 

[joeyhewitt]

I think my problems booting the kernels in newer ROMs and recoveries are because I'm stuck using the old bootloader. Can anyone confirm that there are in fact incompatibilities? Since I can't just flash the new one, anyone know how to boot an nvflash-pushed bootloader image into fastboot mode, so I can then hopefully push a kernel image and boot that? Or perhaps can I patch the new kernel to work with the old bootloader?

Thanks.

 

[Nocturnal_50]

I think my problems booting the kernels in newer ROMs and recoveries are because I'm stuck using the old bootloader. Can anyone confirm that there are in fact incompatibilities? Since I can't just flash the new one, anyone know how to boot an nvflash-pushed bootloader image into fastboot mode, so I can then hopefully push a kernel image and boot that? Or perhaps can I patch the new kernel to work with the old bootloader?

Thanks.

any change to the bootloader is included in the kernel, unless you mean recovery then you are just running in circles making everyone wonder what you are going on about

 

[joeyhewitt]

any change to the bootloader is included in the kernel, unless you mean recovery then you are just running in circles making everyone wonder what you are going on about

Sorry, I'm talking about the Tegra low-level bootloader, "bootloader.bin", which is flashed to the EBT partition (and it or possibly a variant is used for nvflash; I'm not sure if they are interchangeable.) I see the official Froyo release has one with a date March 2011 (shown on-screen when in fastboot mode), and looking at the one from the HC release in a hex editor (buried in the "blob" file from the update pkg), it says December 2011. This doesn't necessarily prove there are changes, but given the usual requirements to flash the official HC release before the third-party ROMs or recoveries, I think this is what's going on -- the HC release flashes in the new boot loader that the ROM/recovery needs.

Edit: The NVC partition may also be involved, don't know much about this yet. On all of this, anyone feel free to correct me if you know more; I'm just explaining it as far as I've been able to cobble together from scraps of information and hex dumps.