Monday, September 7, 2015

The NVidia Kill Switch

So after receiving the replacement NVidia Shield Tablet for the battery recall, I started searching the forums and found a way to defeat the "Kill Switch" for the old tablet after the replacement has been activated.

The TL;DR is that the old tablet has a program called TegraOTA.apk which automatically downloads an "urgent" OTA and applies it without any user permissions.  This OTA would effectively thrash critical files and then reboot itself into a bricked state.  Then at a later date, NVidia is supposed to send out a return kit to retrieve the "dangerous tablet".

However, it looks like there is a way to defeat the "Kill Switch" by effectively disabling or deleting the TegraOTA.apk.  The following is the simple procedure which I used to disable the OTA. [Refer to http://forum.xda-developers.com/shield-tablet/general/kill-kill-switch-shield-tablet-xx-t3179489]

The NVida Kill Switch:
To defeat this with a custom recovery like TWRP, do the following:

  1. Hold "Power" + "Vol Down"
  2. Use Vol Button to select "Recovery" then press "Power" to confirm and enter recovery
  3. For TWRP and from the "Home" menu:
    1. Press "Mount" -> Select "System" -> Return
    2. Press "Advance" -> "File Manager" -> select /system/app/TegraOTA -> Press "Select" and "Delete" folder.

For now this should prevent the OTA download with the kill switch.  Not sure what the future will hold though as NVidia may have a way to bypass this.  But until that Return Kit comes, I'll be enjoying my 2 tablets



How to Unlock, Root and Custom Recovery for the NVidia Shield

NVidia had a battery recall for the NVidia Shield Tablet a month back.  I received my Shield two weeks ago but I never got the time to migrate over to the new shield until now.  So I have rooted this device before, but I seemed to have lost my notes to do so.  So today I'm going to document my process for my future reference and those TL;DR peeps.  You can also refer to this excellent link:
[Refer to http://forum.xda-developers.com/shield-tablet/general/stock-recovery-images-ota-library-guides-t2988881]

NOTE: Use these instructions at your own risk, I am not responsible for any damages to your device

Step 1: Backup your Old Shield
Unfortunately my device was unrooted during the last OTA update (the battery recall check image), so I was not able to utilize Titanium Backup without re-rooting.  Fortunately most of my data is the external 32GB SD card, so I had a few files to migrate over from internal flash to my external SD card.  I just noted my file organization and installed applications list (this is already saved in your google account).

Step 2: Download the necessary files for your host system(windows)
  1. ADB Drivers - Install for the NVidia Shield (choose one):
  2. Minimal ADB and Fastboot - Install these tools for unlocking and flashing: 
  3. SuperSU - Install this on the Shield to get root: 
  4. TWRP (or CWM) Custom Recovery - Easy way to manage your images: 
  5. [Optional] SD Card to copy SuperSU and OTA image (for updates)
Step 3: Install the following downloaded files from Step 2
  • ADB Drivers
  • Minimal ADB and Fastboot
Step 4: Enable Developer Mode
  1. On the tablet, go to "Settings" -> "About tablet"
  2. Tap "Build Number" 10 times
  3. Plug your Shield Tablet to the your computer (Note: you may need to manually update the drivers via Device Manager)
  4. Go to "Settings" -> "Developer options" -> Click on "USB debugging" and on "Always USB Debugging" select OK 
Step 5: Boot into Fastboot Mode
  1. Fully power off your Shield Tablet by holding down the power button then select "Power Off"
  2. Power on your device by simultaneously holding "Power" button + "Down / Vol-" Button and release when it powers on.
  3. Select "Fastboot Protocol"
Step 6: Unlock the Bootloader (WARNING: May void your warranty and ALL OF YOUR DATA WILL BE DELETED)
  1. Open "Minimal ADB and Fastboot" shell
  2. Enter "fastboot devices" and verify that your device is listed
  3. Enter "fastboot oem unlock"
  4. Select "Unlock Bootloader" with Vol+/- and press "Power" to select
  5. You should now be unlocked
Step 6: Install TWRP Recovery
  1. Copy the TWRP image to your "Minimal ADB and Fastboot" directory
    • e.g. "twrp-2.8.7.1-shieldtablet.img" to "C:\Program Files (x86)\Minimal ADV and Fastboot>"
  2. Enter "fastboot flash recovery twrp-2.8.7.1-shieldtablet.img"
  3. Select "Recovery" on tablet using Vol+/- buttons and press power to boot your new recovery partition TWRP
  4. It will prompt you to "Keep System Read Only", just proceed to Allow Modification
Step 7: Root/ReRoot Shield Tablet
  1. Copy "UPDATE-SuperSU-v2.46.zip" to your SD card and install SD into Shield Tablet
  2. Tap "Install", navigate to the "external_sd" and select "UPDATE-SuperSU-v2.46.zip" to install
Step 8: [Optional] Install latest OTA:
  1. Download OTA from NVidia or from:
  2. Copy image to SD Card
  3. Tap "Install", navigate to the "external_sd" and select "OTA Image" to install

NOTE: If you have trouble booting, Go to recovery (TWRP) and wipe the cache partition

Monday, January 5, 2015

Hierarchical State Machines in Python

Recently I've been messing around with Python for some project at work.  I thought it was a good time to dig up some of my old interests on Hierarchical State Machines using Python.  I've wrote this last year just for experiments, but I decided to try integrating it with a project at work.

So what exactly is a Hierarchical State Machine (HSM) anyway?  It is a super set of a Finite State Machines(FSM).  And like all FSM, they are basically event filters that only react to an event if the state handles it.  For a given state, certain events can invoke an action or cause a transition to another state.  This is very common design technique to model behavior in an embedded systems.  But one of the problems with realizing the state machine in code is that you end up with too many states and too many transitions that makes it complicated and unmanageable for non trivial systems.

Enter the HSM which basically allows states to be nested.  The advantages of nesting a state into another state is that the child state doesn't need to handle every event/signal.  If the current state doesn't have a handler for it, then it can pass the event to its parent and see if this has a handler for the event/signal.  Otherwise that state can continue passing that event up to the state hierarchy.  You can think of this as a sort of class inheritance.  This offers some big advantages such as:
  1. More opportunities for refactoring code - similar behavior can be pushed up to the parent
  2. Less event handlers - Common events can be pushed up to the parent instead of every child state
  3. Less transitions - Each state doesn't need to handle the transition
  4. Consistent setup and teardown - Each state handles specific operations, while parent handle common operations
Anyhow, there are many resources about HSM that you can google or find here.

From my perspective, I only care about being able to draw a HSM state machine using some UML diagramming tool and then map it directly into some code.  So here is my python implementation of HSM @ https://github.com/howard-chan/HSM.git

Of course for this to be useful, I need an example to demonstrate its capabilities.  So using Visual Paradigm as my UML drawing tool, I created this simple HSM model of a camera.

Here we have a camera that really has 4 states (Off, OnShoot, OnDispPlay, OnDispMenu) which are nested into the parent states (On, OnDisp).

Here we see that any state will handle the PWR event.  If we are in any one of the child On states (OnShoot, OnDispPlay, OnDispMenu), we see that each child doesn't directly handle the PWR event so it pushes the event up to the parent which does handle the PWR event.  In this case, its the On state which will handle the PWR event and cause a transition to the Off state.  As the HSM transitions from say the "OnDispMenu" to "Off" state, each of the "exit" event handling are invoked to clean up the state, til it enter the "Off" state which triggers the "entry" even handling to setup the state.

So for the following event sequence fed to the Camera:
    # Instantiate Camera
    basic = Camera("Canon")
    # Turn on the Power
    basic.Run(evt.PWR)
    # Take a picture
    basic.Run(evt.RELEASE)
    # Take another picture
    basic.Run(evt.RELEASE)
    # Playback the photo
    basic.Run(evt.MODE)
    # Oops, pushed the release button by accident
    basic.Run(evt.RELEASE)
    # Go to menu settings
    basic.Run(evt.MODE)
    # Uh oh, low battery
    basic.Run(evt.LOWBATT)
    # Time to turn it off
    basic.Run(evt.PWR)

We get the following output:
Run  Canon[Off](evt:PWR)
Tran Canon[Off -> On]
  Canon[Off](EXIT)
Exit Low Power Mode
  Canon[On](ENTRY)
Open Lens
  Canon[On](INIT)
Tran Canon[On -> On.Shoot]
  Canon[On.Shoot](ENTRY)
Enable Sensor
  Canon[On.Shoot](INIT)
Run  Canon[On.Shoot](evt:RELEASE)
CLICK!, save photo
Run  Canon[On.Shoot](evt:RELEASE)
CLICK!, save photo
Run  Canon[On.Shoot](evt:MODE)
Tran Canon[On.Shoot -> On.Disp.Play]
  Canon[On.Shoot](EXIT)
Disable Sensor
  Canon[On.Disp](ENTRY)
Turn on LCD
  Canon[On.Disp.Play](ENTRY)
Display Pictures
  Canon[On.Disp.Play](INIT)
Run  Canon[On.Disp.Play](evt:RELEASE)
  evt:RELEASE unhandled, passing to Canon[On.Disp]
  evt:RELEASE unhandled, passing to Canon[On]
  evt:RELEASE unhandled, passing to Canon[:root:]
Unhandled event:RELEASE Canon[<hsm.State instance at 0x00000000058EA708>]
Run  Canon[On.Disp.Play](evt:MODE)
Tran Canon[On.Disp.Play -> On.Disp.Menu]
  Canon[On.Disp.Play](EXIT)
  Canon[On.Disp.Menu](ENTRY)
Display Menu
  Canon[On.Disp.Menu](INIT)
Run  Canon[On.Disp.Menu](evt:LOWBATT)
  evt:LOWBATT unhandled, passing to Canon[On.Disp]
  evt:LOWBATT unhandled, passing to Canon[On]
Beep low battery warning
Run  Canon[On.Disp.Menu](evt:PWR)
  evt:PWR unhandled, passing to Canon[On.Disp]
  evt:PWR unhandled, passing to Canon[On]
Tran Canon[On.Disp.Menu -> Off]
  Canon[On.Disp.Menu](EXIT)
  Canon[On.Disp](EXIT)
Turn off LCD
  Canon[On](EXIT)
Close Lens
  Canon[Off](ENTRY)
Enter Low Power Mode
  Canon[Off](INIT)

Well that is it for now, I'll probably elaborate on how the HSM.py works on my next entry

Sunday, January 4, 2015

Yeah!!, my first post

I have been putting off starting this blog for ages.  Now that its a new year, it is time to set thing in motion.

The purpose of this blog is to help me keep track of any tricks, artifacts, tid-bits of knowledge, or tools that I have come across along the way as firmware engineer.  I've been at this for about 18 years now mostly working on bare metal firmware for ASICs such as bluetooth basebands (Marvell (88W8688, 88W8787, 88W8797), SSD controllers (Sandforce SF2200), etc.)  

Now I have recently changed jobs and my first opportunity working on Linux.  I've been wanting to do this for so long, but I have never been able to find anytime to work on it as a hobby.  If I do work on it, it just feels like work.  But now that is a job, working on linux feels more like a hobby than anything else.  Its actually fun and there is just so much to learn.  

So that is where I am at and if everything works out as I have intended, this blog will journal my adventures in Linux and IOT related stuff which I can reference to and perhaps others will find helpful.

Happy New Year 2015!!