Sunday, 16 April 2017

Resurrection of a Lenovo Ideapad K1: to neon or not to neon

In my previous post here I discussed my struggle with flashing my wife’s Lenovo Ideapad K1. And in the end I had to conclude that I could not conclude that I have bad flash or bad memory. This all was interesting, but not so helpful to get the tablet back to usable again.

When I install my images:
  • First: CM10.1_Wifi_Kaschemme_v1 or K1_CM10_JB_Starter_v2 with the nvflash tool.
  • Second: cm-10.1.3-RELEASE-k1-wifi.zip or cm-10.1-20130916-NIGHTLY-k1.zip with the recovery firmware CWM6.0.x.x.
I don't have any problems. The problems start after installing the gapps that are missing in these CyanogenMod android 4.1 / 4.2 images.  I use for that the file gapps-jb-20130427-nonneon-tonyp-keyboard.zip

I did a bit more research on my problems. There are a few elements to my "not working" tablet which helped me to narrow down the issue:
  • Messages that various google services have stopped or are not working any more.
  • Programs like youtube that not start or google play that gives [RH01] errors.
  • Logfile that gets filled with SIGILL errors and register dumps.
The last symptom  helped me most. After some time spend with google search I started to understand that I am hitting here an essential Tegra 2 vs Android 3.2+ issue.

The Tegra 2 T20 was at the time a relative advanced dual core Cortex A9 processor with a very good GPU so that it could do video decoding and encoding in the GPU. The Arm part is good but the GPU was the more advanced Nvidia item. A bit similar situation like the BCM2835 SoC processor of the Raspberry pi. Only is this not an ARMv6 but real ARMv7-A architecture, but to reduce some costs/complexity they have not implemented all the typical Cortex-A9 functions like the Advanced SIMD (NEON) extension. Probably Nvidia expected not to need this because the GPU could do the multimedia power lifting much better. From Tegra 3 Nvidia starts to support the full "instruction set".

The SIGILL error happens when a program is trying to execute a NEON instruction on a not NEON processor.  In the past, older than Android 4.1, was the assumption that most processors were ARMv5 and did programs not use NEON instructions, also not for AMRv7A.  In the SDK was it also explicitly asked for to have libraries for ARMv5 and ARMv7A with and without NEON or other extensions.

The issue I now have in 2017 looks to be two fold:
  • Google started to ship APK packages optimized for NEON, maybe on purpose, maybe by accident or maybe the compiler starts to optimize more/better in this direction.
  • For higher android versions is NEON compatibility of the ARMv7A architecture assumed.
This means that when a newer Android is installed on a tegra 2 platform we will hit the lack of NEON support. The program or parts of it will crash when there are no backup libraries for NEON emulation. All the google service packages and programs such as the google play, youtube etc. have this (potential) problem. My issue is that this "newer" is already by the Android 4.2 from the CM10 images and that the gapps package is pulling in a lot of newer versions of the libraries to support certain API's to talk back to Google and the Android universe.

It must be possible to keep and skip to the correct versions of the google apps to keep them working. However that is not so easy. There is always the danger that a new installed app is bringing the system down.

At this moment I see as only option to stay at android 3.2 and not to update too much. I have installed the old not rooted official Lenovo image: K1_A301_11_11_111108_US.zip and with that older outdated version is for the last hours youtube and the web browser working.

Case closed: a working tablet with obsolete Android 3.2 and an odd ball ARM device in my collection.

A side note: this tablet went obsolete in early 2012 and therefore there are still some people working on it up to late 2013. There are quite some messages in the XDA and Lenove forums from that time, but nowadays are all links in the posts to file sharing servers dead. It is very difficult to find various images back. Therefore it is not really possible to have a long life on this kind devices in terms of (software) support. The PC is in that way a much durable concept.

Short update: Improved Android 3.2.1 image

I searched a bit longer and found here the following thread with a better Android 3.2.1. image for this tablet. This image has the following improvements:
  • Newer version of the root file system: 14_14_120109 build
  • Recovery image / bootloader
  • No levono market and other not working apps
  • Rooted
The original image name is: K1_Stock_120109_nvflash_R2.zip but it can also be found as honeycomb.zip

Saturday, 15 April 2017

Resurrection of a Lenovo Ideapad K1

My wife is the lucky owner of an Lenovo Ideapad K1, an Android 10" tablet I have bought for her in 2011.  Lenovo is clearly not supporting the product any more; an  difficult findable product on their own website.  This was a relative cool product, tegra 2 based and 1GB memory and 32 GB flash, that I could buy at the time in Japan. This tabled was a nice toy to consume media like reading websites of watching youtube movies.
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.zip and/or cm-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.
Changing things in the hardware will be very hard and/or impossible.

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
And for some reason is the process hanging at this point. The 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
This probably means that I will have to search for a memtest tool for the tegra.
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.