El que haya instalado xubuntu, y pruebe la orden que decía unas páginas atrás:
user@gtablet-ubuntu:~$ cat /proc/mtd
dev: size erasesize name
mtd0: 01000000 00020000 "misc"
mtd1: 01000000 00020000 "recovery"
mtd2: 01000000 00020000 "boot"
mtd3: 0f7c0000 00020000 "system"
mtd4: 093a0000 00020000 "cache"
mtd5: 00400000 00020000 "bootbmp"
mtd6: 00400000 00020000 "kbmp"
mtd7: 02000000 00020000 "logodata"
descubrirá que hay una partición nueva, cuyo nombre es kbmp de 4M, y que sospecho es la pantalla de inicio de linux (la azul), el problema es que yo para instalar xubuntu no he rehecho la tabla de particiones, sólo he cambiado el contenido de la partición SOS por el núcleo de linux. De hecho si se leen las particiones con nvflash, están exactamente igual que antes.
Si se miran los mensajes del linux con dmesg, aparece entre otras cosas lo siguiente:
[ 4.908872] tegra_nand: 1 NAND chip(s) found (vend=0xad, dev=0xdc) (Hynix NAND 512MiB 3,3V 8-bit)
[ 4.912375] tegra_nand: NVIDIA Tegra NAND controller @ base=0x70008000 irq=56.
[ 4.918221] block 0x00000021 is bad.
[ 5.007359] block 0x000004e4 is bad.
[ 5.210283] 8 cmdlinepart partitions found on MTD device tegra_nand
[ 5.213732] Creating 8 MTD partitions on "tegra_nand":
[ 5.217190] 0x000000e40000-0x000001e40000 : "misc"
[ 5.221359] 0x0000052a0000-0x0000062a0000 : "recovery"
[ 5.225390] 0x000006320000-0x000007320000 : "boot"
[ 5.229374] 0x0000073a0000-0x000016b60000 : "system"
[ 5.233505] 0x000016be0000-0x00001ff80000 : "cache"
[ 5.237444] 0x0000009c0000-0x000000dc0000 : "bootbmp"
[ 5.241238] 0x000002da0000-0x0000031a0000 : "kbmp"
[ 5.244933] 0x000003220000-0x000005220000 : "logodata"
lo que confirma lo de los bloques defectuosos, que coinciden exactamente en 2 de los tres lugares en que nvflash no es capaz de leer (el primero y el último), y que entre partición y partición hay un hueco, seguramente pensado para poder expandir la partición correspondiente sin tocar el resto si aparecen nuevos sectores defectuosos.
Lo malo es que kbmp la coloca entre misc y logodata:
0x0000009c0000-0x000000dc0000 : "bootbmp"
0x000000e40000-0x000001e40000 : "misc"
0x000002da0000-0x0000031a0000 : "kbmp"
0x000003220000-0x000005220000 : "logodata"
0x0000052a0000-0x0000062a0000 : "recovery"
0x000006320000-0x000007320000 : "boot"
0x0000073a0000-0x000016b60000 : "system"
0x000016be0000-0x00001ff80000 : "cache"
lo cual no tiene mucho sentido, porque para hacerlo tendría que haber desplazado el resto hacia atrás, y no parece muy lógico que lo haya hecho. Seguramente la habrá colocado al final, detrás de cache, que ha sufrido una reducción de tamaño respecto a lo que tenía antes (0x93a0000 frente a 0xa940000), y que no hay problema en formatear con tamaño menor para hacer el hueco para kbmp, ya que es una caché, y por tanto lo lógico es que su contenido pueda borrarse entre arranque y arranque de Android, sin que eso afecte al sistema.
De hecho si se hace el cat /proc/mtd de nuevo desde Android el resultado es:
localhost / # cat /proc/mtd
dev: size erasesize name
mtd0: 01000000 00020000 "misc"
mtd1: 01000000 00020000 "recovery"
mtd2: 01000000 00020000 "boot"
mtd3: 0f7c0000 00020000 "system"
mtd4: 0a940000 00020000 "cache"
mtd5: 00400000 00020000 "bootbmp"
mtd6: 02000000 00020000 "logodata"
en el cual no existe kbmp y cache tiene el tamaño anterior.