However a few years back I got all kind of strange problems; programs crashed, the tablet didn't boot / come out of sleep mode, etc. Flashing a newer CyanogenMod firmware helped only for some time.
Recently I have taken the dust of the tablet to have a deeper look into the problems I am experiencing with the thing.
 |
| Lenovo IdeaPad K1 with crashes and errors in log file (CatLog) |
Most information can be found in the XDA forums; this posting is a good start to find the required files.
I mainly used:
- Recovery / first file system:
nvflash_CM10.1_Wifi_Kaschemme_v1.zip - Main CyanogenMod firmware file system:
cm-10.1-20130916-NIGHTLY-k1.zipand/orcm-10.1.3-RELEASE-k1-wifi.zip - Google apps items:
gapps-jb-20130427-nonneon-tonyp-keyboard.zip
Detailed information
The following (among more) is inside:- An Nvidia Tegra 2 T20 processor at 1GHz.
- The flash chip is Toshiba 32 GbB emmc chip with a now way obsolete 2nd generation controller in a painful to (de)solder BGA package: 32GB Toshiba THGBM2G8D8FBA1B NAND Flash.
- The memory chip is also a BGA package: 1GB Eplida B8132B2PB-6D-F LPDDR2 DRAM.
The device has the following partition table:
| Partition number | Name | Start sector | Num Sectors | Size Mbyte | Description | FS type | Android / Linux mount point |
| 2 | BCT | 0 | 1024 | 4 | System configuration data | data | |
| 3 | PT | 1024 | 512 | 2 | Partition table | data | |
| 4 | EBT | 1536 | 1024 | 4 | Bootloader ? | data | |
| 5 | GP1 | 2560 | 512 | 2 | also some bootloader related partition table | data | |
| 6 | SOS | 3072 | 1536 | 6 | Recovery partition | android boot | /dev/block/mmcblk0p1 |
| 7 | LNX | 4608 | 2048 | 8 | kernel /boot partition | android boot | /dev/block/mmcblk0p2 |
| 8 | APP | 6656 | 107520 | 420 | System root partition | ext4 | /dev/block/mmcblk0p3 /system |
| 9 | CAC | 114176 | 32768 | 128 | Cache partition | ext4 | /dev/block/mmcblk0p4 /cache |
| 10 | MSC | 146944 | 512 | 2 | miscellaneous | data | /dev/block/mmcblk0p5 |
| 11 | USP | 147456 | 35840 | 140 | Bootloader ? | data | /dev/block/mmcblk0p6 |
| 12 | UDA | 183296 | 6740992 | 26332 | User data | ext3 | /dev/block/mmcblk0p7 /data |
| 13 | TMP | 6924288 | 614400 | 2400 | Temp partition | ext4 | /dev/block/mmcblk0p8 |
| 14 | GPT | 7538688 | 276480 | 1080 | Partition table | data |
The hope is that I can identify
Contacting the boot loader
One of the important steps is to get "contact" with the bootloader to get a deeper understanding of the state of the flash.The tegra has a possibility to boot over USB. That means that the ROM bootloader is not getting its further data from flash (nand, sd, emmc), but waits on data coming from the USB subsystem. This is a special protocol of Nvidia.
The linux tool for this is called nvflash, this program can be found in the archive of the upgrade images. More information can be found here or with google.
The first step in the process is to get a more "advanced" bootloader working on the process so that actually communication and flashing is possible. For this is a special "Nv3p server" bootloader needed (
bootloader.bin). Because of the secure system should this bootloader be accompanied by a key in a binary blob (blob.bin). And there is the need for a kind of board description file BCT file (flash.bct) to let the bootloader know what kind of memory and flash is used. This all can be found in the flash package for android. Making an udev rule
By making an udev rule is it possible to set the correct permissions and to remove the need to be root to communicate with the tablet. This is actually linux basics, but not something I do daily so I personally forget all the details every time.Basic work flow:
Check location of the device with lsusb:
$ lsusb
Bus 003 Device 012: ID 0955:7820 NVidia Corp. Tegra 2 AC100 developer mode
Check the relevant parameters for the udev script:
$ udevadm info -a -p $(udevadm info -q path -n /dev/bus/usb/003/012)
looking at device '/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.1':
KERNEL=="3-3.1"
SUBSYSTEM=="usb"
DRIVER=="usb"
ATTR{idProduct}=="7820"
ATTR{idVendor}=="0955"
ATTR{ltm_capable}=="no"
ATTR{manufacturer}=="NVIDIA Corp."
ATTR{maxchild}=="0"
Make the udev rule:
$cat /etc/udev/rules.d/60-nvflash.rules
# nvflash support for Nvidia Tegra systems attached to USB
SUBSYSTEM=="usb", ATTR{idVendor}=="0955", ATTR{idProduct}=="7820", MODE="0660", GROUP="plugdev"
Reload the rules and check if something is recognized:
$ sudo udevadm control --reload-rules
$ udevadm test /devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.1
$ sudo udevadm monitor
Getting data from the flash chip
With the following commands is it possible to get the partition table and the data of each partition. The first command ensures that the Nv3p server is up and running.
$ ./nvflash --blob blob.bin --bct flash.bct --odmdata 0x300c0011 --bl bootloader.bin --getpartitiontable partition.txt
$ ./nvflash --resume read 12 UDA.bin
$ ./nvflash --resume read 3 PT.bin
This did not result into an error. So reading from flash does work in principle. Next is a sanity check of each partition, where the data partitions are most important.
$ file UDA.bin
UDA.bin: Linux rev 1.0 ext3 filesystem data, UUID=1d1ae925-25c3-4daf-a78c-5e92106cad73 (large files)
$ fsck.ext3 -v -f UDA.bin
$ mkdir -p test
$ sudo mount UDA.bin test
Here are errors found. I am not certain if this means we have errors on our flash chip or that the file system just crashed by a hard shutdown before.
Re-flashing the device
I try to flash the image with the verify option switched on.
$ ./nvflash --blob blob.bin --bct flash.bct --odmdata 0x300c0011 --configfile flash.cfg --bl bootloader.bin --format_partition 2 --sync
$ ./nvflash -r --format_partition 2
$ ./nvflash -r --format_partition 3
....
$ ./nvflash -r --format_partition 14
$ ./nvflash -r --blob blob.bin --bct flash.bct --setbct --odmdata 0x300c0011 --configfile flash.cfg --create --verifypart -1
Nvflash v1.8.90246 started
[resume mode]
Using blob v1.1.57813
sending file: flash.bct
- 4080/4080 bytes sent
flash.bct sent successfully
odm data: 0x300c0011
setting device: 2 3
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: GP1
creating partition: SOS
creating partition: LNX
creating partition: APP
creating partition: CAC
creating partition: MSC
creating partition: USP
creating partition: UDA
creating partition: TMP
creating partition: GPT
Formatting partition 2 BCT please wait.. done!
Formatting partition 3 PT please wait.. done!
Formatting partition 4 EBT please wait.. done!
Formatting partition 5 GP1 please wait.. done!
Formatting partition 6 SOS please wait.. done!
Formatting partition 7 LNX please wait.. done!
Formatting partition 8 APP please wait.. done!
Formatting partition 9 CAC please wait.. done!
Formatting partition 10 MSC please wait.. done!
Formatting partition 11 USP please wait.. done!
Formatting partition 12 UDA please wait.. done!
Formatting partition 13 TMP please wait.. done!
Formatting partition 14 GPT please wait.. done!
done!
Enabling verification for partition ID = 4...
sending file: bootloader.bin
\ 1393296/1393296 bytes sent
bootloader.bin sent successfully
Enabling verification for partition ID = 6...
sending file: recovery.img
\ 4573184/4573184 bytes sent
recovery.img sent successfully
Enabling verification for partition ID = 7...
sending file: boot.img
| 2816000/2816000 bytes sent
boot.img sent successfully
Enabling verification for partition ID = 8...
sending file: system.img
- 264010336/264010336 bytes sent
system.img sent successfully
Enabling verification for partition ID = 13...
sending file: userdata.img
userdata.img file is smaller than the system.img file; I would expect that the flash process goes with the same speed or faster. Is this than the sign that flash or memory is bad? The tablet feels warm so maybe it is from calculating the checksum; I will have to wait for an hour.Waiting is not really working. When the verification option is enabled is the userdata.img always failing around 139657210 bytes. This does not become better when I move partition 13 a significant amount of sectors forward. Probably this means I have a memory problem and not a flash problem.
A normal write, without the checksum calculation for the verify, does work normally.
$ ./nvflash --bl bootloader.bin --blob blob.bin --bct flash.bct --setbct --odmdata 0x300c0011 --configfile flash.cfg --create
Nvflash v1.8.90246 started
Using blob v1.1.57813
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 4
chip sku: 0x8
chip uid: 0x0428914840c12157
macrovision: disabled
hdcp: enabled
sbk burned: true
dk burned: true
boot device: emmc
operating mode: 4
device config strap: 0
device config fuse: 0
sdram config strap: 0
sending file: flash.bct
- 4080/4080 bytes sent
flash.bct sent successfully
odm data: 0x300c0011
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: bootloader.bin
\ 1393296/1393296 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 2 3
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: GP1
creating partition: SOS
creating partition: LNX
creating partition: APP
creating partition: CAC
creating partition: MSC
creating partition: USP
creating partition: UDA
creating partition: TMP
creating partition: GPT
Formatting partition 2 BCT please wait.. done!
Formatting partition 3 PT please wait.. done!
Formatting partition 4 EBT please wait.. done!
Formatting partition 5 GP1 please wait.. done!
Formatting partition 6 SOS please wait.. done!
Formatting partition 7 LNX please wait.. done!
Formatting partition 8 APP please wait.. done!
Formatting partition 9 CAC please wait.. done!
Formatting partition 10 MSC please wait.. done!
Formatting partition 11 USP please wait.. done!
Formatting partition 12 UDA please wait.. done!
Formatting partition 13 TMP please wait.. done!
Formatting partition 14 GPT please wait.. done!
done!
sending file: bootloader.bin
\ 1393296/1393296 bytes sent
bootloader.bin sent successfully
sending file: recovery.img
\ 4573184/4573184 bytes sent
recovery.img sent successfully
sending file: boot.img
| 2816000/2816000 bytes sent
boot.img sent successfully
sending file: system.img
- 264010336/264010336 bytes sent
system.img sent successfully
sending file: userdata.img
- 142382496/142382496 bytes sent
userdata.img sent successfully
The tool to check the sdram didn't work for me. Nvidia has some special tools but they are not free available or ask for a special memory description files. I can maybe get those out of the bct file but still...
The output below is what the nvflash tool is giving me:
$ ./nvflash --cmdhelp --odm
Nvflash v1.8.90246 started
--odm command usage ->
nvflash --odm CMD data --bl --go
-----------------------------------------------------------------------
used to do some special diagnostics like sdram validation, fuelgauge etc
each CMD has data associated with it
For e.g.
1. SD/SE diagnostic tests:
nvflash --odm runsediag --bl --go
nvflash --odm runsddiag --bl --go
---------------------------------------------------------------------
used to run SD/SE diagnostic tests, where N is the input parameter like
SDController Instance.
2. Sdram verification:
nvflash --bct --setbct --configile --create --odmdata --odm verifysdram --bl --go
---------------------------------------------------------------------
used to verify sdram initialization i.e. verify sdram params in bct is
in accordance with actual SDRAM attached in device or not.
N can be either 0 or 1. '0' implies soft test where known word patterns
are written for each mb and read back. This word pattern validates all
the bits of the word. '1' implies stress test where known word patterns
are written on entire sdram area available and read back. This tests every
bit of the the entire available sdram area
-----------------------------------------------------------------------
$ ./nvflash -r --bct flash.bct --configfile flash.cfg --odmdata 0x300c0011 --odm verifysdram 0
Nvflash v1.8.90246 started
[resume mode]
command failure: no commands found
Conclusion
I cannot really conclude that my memory or flash is bad, despite of the "struggle" I had with the nvflash tool. In general I don't see errors with the flash process, and when I have an error then they don't depend on the flash location and are probably more a not related "feature" of the nvflash tool and bootloader firmware.A memory error would be still possible, but in that case I would have expected more often problems and real hard crashes.
The conclusion must be that I have a different problem.
No comments:
Post a Comment