Debian on the TF101

Date: Sep 2011
Authors: Trent W. Buck
Audience:Experienced Debian end users
Status: draft


This document is the first step towards a Debian Pure Blend for the ASUS Eee Pad Transformer (TF101), with full hardware support. The up-coming armhf Debian architecture is used.


the install process is rife with gotchas. Reading the article in full before purchase is strongly recommended.


this process executes binary blobs outside Debian's trust infrastructure. Before you proceed, consider the chances that any given blob has been compromised, and how unhappy you would be if an attacker had a back door into your TF101, all the secrets you will put on it, and all the networks to which you will connect it.

Acknowledgements: this document was possible thanks to the constant assistance of lilstevie (Steven Barker), who had a working Ubuntu 11.04 armel install on the TF101 before I even owned one.

The TF101 is built around the NVidia Tegra 2 platform, a dual-core ARM Cortex-A9 SOC. A 16GB or 32GB eMMC package provides non-volatile storage; it is soldered onto the mainboard and can not be replaced or upgraded.

The eMMC is believed to be a "modern" NAND+FTL package with more than enough write-erase cycles to last a typical lifetime.

A conventional d-i install was never attempted. Instead, a Debian environment was prepared elsewhere and loaded onto the eMMC using the proprietary nvflash program.

NVFlash & Prerequisites

As at Sep 2011, only a static x86 binary is available. It is included in the latest linux4tegra release (12~a1.0).

For some reason, a bootloader must be uploaded into RAM before the eMMC can be read from or written to. It does not need to match the version already in the eMMC's EBT partition, nor will it overwrite that partition unless/until you ask nvflash to do so.

A binary copy of the ASUS bootloader is embedded in the ASUS firmware zip file. As at Sep 2011 the latest US firmware is Within the zip is a single file called "blob", containing several partitions.

To extract the EBT partition from "blob", git clone BlobTools, make blobunpack, and run blobunpack on blob. The EBT file is the ASUS bootloader. The US EBT's md5sum was 7934929ae976dbbea24a7e97308ceb04.


the ASUS zipfile is a couple of hundred megabytes.

NVFlash requires a local copy of the partition table, in an ini-style plain text format. NVFlash can repartition the eMMC based on flash.cfg, but it cannot query the eMMC for its current partition table. Except when repartitioning, flash.cfg must correspond to the partition table already on the eMMC.

For example, to back up the Android user data (UDA) partition from the eMMC requires the default partition table. A reverse-engineered copy of this is available in lilstevie's linux-flash-kit.

Similar to the partition table and EBT partition (bootloader), nvflash must have a local copy of the BCT partition before it can do anything useful. This contains model-specific magic that I (twb) do not comprehend.

Unfortunately neither NVidia nor ASUS provide a copy of the TF101 BCT, and it is non-trivial to extract from an existing TF101. Therefore a reverse-engineered third-party copy must be used. I (twb) used the copy from lilstevie's linux-flash-kit.

NVidia Tegra 2 systems have an optional signing process called "SBK". ASUS have elected to enable this feature on the TF101. The SBK is a shared secret baked into the device. The corresponding SBK must be passed to nvflash. If this is not done, or the SBK passed is incorrect, nvflash will exit with status 0x4.

Every TF101 has the same SBK baked into it:

0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98


some/all TF101G (the 3G model) are expected to have a different SBK. Until you know the SBK that corresponds to your device, you can not install Debian.

To acquire an SBK, perform rubber-hose or black-bag cryptanalysis on the associated ASUS staff. Once successful, please publish the SBK widely, as (AFAIK) ASUS cannot revoke it from units that have already rolled out.

Finally, there is an "ODM Data" magic number, believed to model-specific or perhaps SOC-specific. For the TF101, it is:


Using NVFlash

To use nvflash, the target TF101 is connected to the nvflash host via the USB-to-40pin cable, and the TF101 is put into "APX mode". To enter APX mode, hold the VolUp and Power buttons for several seconds during the boot process.

In APX mode, the TF101's screen is off, and lsusb on the nvflash host will report an NVidia device. If lsusb lists an ASUS device, you're in Android, not APX.

$ lsusb -d 0955:
Bus 001 Device 036: ID 0955:7820 NVidia Corp.

If the device is running or suspended, hold the power button for several seconds to turn it off.

In the above example, observe the USB bus address is 001/036. nvflash can be run as an unprivileged user by granting that user write access to /dev/bus/usb/NNN/MMM, e.g.

$ sudo chgrp nogroup /dev/bus/usb/001/036
$ sudo -u nobody nvflash ...

Note that every time you reboot the TF101 or disconnect and reconnect the USB cable, the USB bus address will change and you will need to chgrp again. This might be circumvented via a udev rule; this is left as an exercise for the reader.

Having everything lined up, we can now initiate a backup of the UDA partition to a local file (where 15 is UDA's id in flash.cfg)

$ sudo -u nobody ./nvflash \
    --bct transformer.bct --setbct \
    --configfile flash.cfg \
    --bl bootloader.bin \
    --odmdata 0x300d8011 \
    --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 \
$ sudo -u nobody ./nvflash -r --read 15 UDA.img
$ file UDA.img
Linux rev 1.0 ext4 filesystem data, UUID=[...] (extents) (large files)


from power on, you have a few seconds to hit Power+VolUP to enter APX. Unlike entering a PC BIOS, it doesn't matter if Android or Linux area already running -- all that matters is how long since boot.


Hardware Grumbling

The dock has four rubber feet on its base, but when the unit is open, only the front pair are used. The hinge has a separate pair of crappier rubber feet, and these push the entire unit up off the base's rear rubber feet.

Unlike Eee netbooks (e.g. the 701 and the 1005), when the unit is closed its "rest" position is to be open by some half a centimetre. This means that if you bounce the unit in your hand, the case bangs shut then springs back out a little. This worries me about how well it will handle being transported loose in e.g. a backpack or suitcase.

Because the panel is sidelit instead of backlit, there is a noticable white smudge in the middle of the bottom of the screen. This is especially noticable in a dark room, with a completely black background -- for example, when at the framebuffer console.

The USB ports on the keyboard dock sit behind little slide-out covers. These covers are a pain to open, and must be bent out of the way to insert a USB device. If a device is constantly inserted during normal use (e.g. a USB mouse), these plastic covers will quickly get stuck in a bent position and be impossible to reinsert. Possibly the covers can simply be cut off and thrown away; I have yet to attempt this.