Are you the publisher? Claim or contact us about this channel

Embed this content in your HTML


Report adult content:

click to rate:

Account: (login)

More Channels

Channel Catalog

    0 0
  • 09/23/12--02:47: TUMPA
  • I was planning on “playing” with a certain device, so I wanted some adapter which allowed me to interface with the device at a low level to facilitate the information gathering phase in the hacking process. I wanted something to connect to UART signals, and a JTAG port and maybe something able to program SPI flash chips too; Marek Vasut suggested I should pick up something based on the FT2232H IC, after a round of research I settled on a TUMPA; it arrived some days ago.

    Testing TUMPA under Linux

    The TUMPA manual is more than OK, but some more specific info about linux can still be useful.


    The FT2232H has two serial channels (A and B), on the TUMPA only channel B is dedicated to UART communication, either as TTL signals or as a full RS-232 interface.

    Using the TUMPA for a naked serial connection/console works fine, the linux ftdi_sio USB-serial driver can be used for that, the module can be loaded passing the vendor and product options to it:

    $ sudo modprobe ftdi_sio vendor=0x0403 product=0x8a98

    In this case two new device nodes show up, in my case they are /dev/ttyUSB0 and /dev/ttyUSB1, the latter corresponds to channel B.

    Alternatively a patch to add direct support for TUMPA to ftdi_sio is available and will hopefully be added to linux-3.7, with this mechanism only one new device node shows up (/dev/ttyUSB0 here) which is mapped to channel B (channel A is reserved to JTAG/SPI1 on the TUMPA).

    [  211.848085] usb 2-2: new high-speed USB device number 3 using ehci_hcd
    [  211.996305] hub 2-0:1.0: unable to enumerate USB device on port 2
    [  212.452090] usb 4-2: new full-speed USB device number 3 using ohci_hcd
    [  212.652083] usb 4-2: not running at top speed; connect to a high speed hub
    [  212.672078] usb 4-2: New USB device found, idVendor=0403, idProduct=8a98
    [  212.672086] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [  212.672092] usb 4-2: Product: TIAO USB Multi-Protocol Adapter
    [  212.672098] usb 4-2: Manufacturer: TIAO
    [  212.672103] usb 4-2: SerialNumber: XXXXXXXX
    [  212.770697] usbcore: registered new interface driver usbserial
    [  212.771255] usbcore: registered new interface driver usbserial_generic
    [  212.771835] USB Serial support registered for generic
    [  212.771850] usbserial: USB Serial Driver core
    [  212.791528] usbcore: registered new interface driver ftdi_sio
    [  212.792885] USB Serial support registered for FTDI USB Serial Device
    [  212.794682] usb 4-2: Ignoring serial port reserved for JTAG
    [  212.794755] ftdi_sio 4-2:1.1: FTDI USB Serial Device converter detected
    [  212.797208] usb 4-2: Detected FT2232H
    [  212.797217] usb 4-2: Number of endpoints 2
    [  212.797224] usb 4-2: Endpoint 1 MaxPacketSize 64
    [  212.797229] usb 4-2: Endpoint 2 MaxPacketSize 64
    [  212.797235] usb 4-2: Setting MaxPacketSize 64
    [  212.808428] usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0
    [  212.808477] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

    After connecting the interface to the target device, the serial console on the device can be accessed using minicom:

    $ minicom -D /dev/ttyUSBX


    I tested the SPI interface using a chip from an old motherboard I had lying around, it is a MX25L8005, I just needed to make the connections:

    TUMPA MX25L8005 connection

    TUMPA MX25L8005 connection photo

    and use flashrom which already has support for both the TUMPA and the MX25L8005:

    $ sudo flashrom -p ft2232_spi:type=tumpa,port=B -r flash.bin
    flashrom v0.9.6.1-r1563 on Linux 3.6.0-rc5-ao2 (x86_64)
    flashrom is free software, get the source code at
    Calibrating delay loop... OK.
    Found Macronix flash chip "MX25L8005" (1024 kB, SPI) on ft2232_spi.
    Reading flash... done.

    I2C, GPIO and bit-banging

    FTDI chips are quite flexible, they can operate in a mode called Multi-Protocol Synchronous Serial Engine (MPSSE) which can be used to talk to I2C devices, or to set up some chip lines as GPIO pins, or for bit banging.

    I used MPSSE via libmpsse to read data off a 24C16 EEPROM, the mapping can be derived by joining the different documents about MPSSE Basics, MPSSE Commands and TUMPA manual, a table is following for convenience:

    TMS pin7 ADBUS3 TMS/CS
    RST pin15 ADBUS4 GPIOL0
    RTCK pin11 ADBUS7 GPIOL3

    And here is the final wiring to read an EEPROM via I2C:

    TUMPA I2C connections

    TUMPA I2C connections photo

    With the GPIO mode I was also able to test a trivial circuit with a LED and a resistor and make the LED blink controlling the delay via software using libmpsse.

    I don't know if MPSSE mode can be used to flash programs to PIC microcontrollers too, the PICPgm mentions a USB interface based on an FTDI chip but I didn't go deeper into the matter.

    Reading the FTDI eeprom on TUMPA

    The FTDI chip stores some info into an internal EEPROM, this one can be read (and flashed) using ftdi_eeprom from libftdi (NOTE: bash command line):

    $ ftdi_eeprom --read-eeprom <(echo -e "vendor_id=0x0403\nproduct_id=0x8a98\nfilename=TUMPA-eeprom.bin")

    The official utility to deal with the FTDI eeprom is the closed source FT_PROG.

    Final words

    Now that I know something more about FT2232H I think I can compare the TUMPA to simpler solutions like the basic FT2232H Mini Module:

    • On the plus side, having dedicated connectors for SPI, JTAG and TTL/RS232 on the TUMPA speeds up the connections as that avoids keeping track of the pin mapping each time.
    • On the other hand I note that the TUMPA does not make it easy to access all the FT2232H lines, which is limiting especially in MPSSE GPIO mode.

    I will update the article when I get a chance to test the JTAG functionality.

    0 0

    Support for the Digicom Digitune-S DVB-T USB stick will land in linux 3.9, the patch I sent was accepted along with other small refactorings. The adapter can also be found under these names:

    A dump of the USB communication of the Windows driver is attached, it was captured using SniffUSB 2.0 and it can be made more readable using the tool from v4l-utils.

    I used the dump also to figure out some details about the hardware: before writing any code I had to know what hardware components the adapter was using; the USB bridge (ULi M9206) and the frontend (MT352CG) could be seen clearly when opening the plastic case, but the tuner was protected by a metal shield and I couldn't easily find out what it was by reading the labels printed on the chip, so I tried to look at the USB communication to see if there were any clues, in particular these bits were useful:

    40 23 c0 00 80 00 00 00 >>>
    40 23 00 00 00 00 00 00 >>>
    40 23 c1 00 80 00 00 00 >>>
    c0 23 00 00 60 00 01 00 <<< 63

    I thought they had something to do with some chip identification, and in fact by following the m920x driver code you can derive that this communication means more or less: “read the register at address 0x00 of the I2C device at address 0x60”; the returned value was 0x63 and by grepping through the kernel code for that value this turned out to be the same value used in the mt2060 driver for the PART_REV constant, that was enough to understand what tuner the device was using and make the jigsaw complete.

    At that point adding support for the adapter was easy as all the drivers of the single components were already in the kernel, even the remote control mapping was there: separation of responsibility and modularity are good; what a surprise, eh?

    The firmware was extracted from the USB dumps too, by first using

    $ v4l-utils/contrib/ usbsnoop-digicom-digitune-s-dump.log_ > parsed-Digitune-S-dump.log

    and then by runing on the pre-processed log with this command line:

    $ perl v4l-utils/contrib/m920x/ -i us2 -m fw < parsed-Digitune-S-dump.log
    $ mv fw dvb-usb-vp7049-0.95.fw

    While testing the adapter I've found out that signal reception improves when the little antenna with the magnetic base is on top of some metal object, I put mine on top of a candy tin box and I can get a few more channels, from what I read the physical principle that makes this work is the one of the ground plane of a monopole antenna.

    Note to world: if you want any hardware of yours to be working under linux, just find a way to have some kernel hackers put their hands on it; the rest will come by itself.

    0 0

    I was having a hard time getting the Acer C110 USB pico projector work when connected to the BeagleBone Black, it wasn't showing up on the USB bus at all, no sign of it in the kernel messages and consequently no sign of it in lsusb. The device comes with a Y-cable so it can receive additional power, but even connecting it to an external 5V power source it still wasn't working.

    I thought that the USB port on the BeagleBone had some current limit the projector was exceeding: the current supplied was not enough to power the device, and maybe the power drawn by the device was also confusing the USB host controller.

    I started cutting old USB cables from broken mice in order to build a custom cable without the VCC line to the device, but then a more elegant solution came to my mind: electrical tape; I would have never thought I'd use the words “elegant” and “electrical tape” in the same sentence but here we are.

    Electrical tape on VCC line of USB connector

    Just isolating the VCC line on the USB connector was enough to make the device work with the BeagleBone, provided that the power was taken elsewhere using the Y-cable. I guess that ignoring the VCC line works around the “electrical stress” on the USB host controller, can anyone explain it with more technical details?

    Now the device enumerates and works nicely with libam7xxx, the only trick to keep in mind in order for the device initialization to succeed is to connect first the “data” end of the USB Y-cable to the device and then connect the “power” end to the power source.

    I am also attaching some pictures of the final setup.

    BTW, there's also another lesson learned: don't trust color codes of cheap USB cables, always verify with a continuity test the correspondence between the cables and the pins on the connector.

    Projecting the Ångström login screen
    Cable setup 1
    Cable setup 2

    0 0
  • 03/21/14--07:21: DIY wire-wrapping tool
  • Wire-wrapping is a very handy way to connect wires to PCB pins, especially in two scenarios:

    1. As an alternative to soldering, in order to be able to easily recycle the components.
    2. As an alternative to female jumper wires, in order to save some vertical space (sometimes jumper wire connectors are just too long).

    A DIY wire-wrapping tool can be built from an empty ball point pen ink cartridge or from lollipop sticks, and even out of cotton swabs.

    Tools made this way will work fine with solid core wires between 30 and 24 AWG like for instance those used in CAT5 cables.

    Here's mine, made with a metallic pen cartridge. Last picture is an actual example of use.

    metallic pen cartridge
    hole in the cartridge
    wire wrapping tool
    wire setup
    wrapping the wire
    wire wrapped
    wire wrapped on a trinket

    0 0
  • 04/16/14--14:12: JMP-rope, the hardware
  • The hardware of the first JMP-rope prototype is very simple:

    • A jump rope with large ball bearing handles, to be hacked with zip-ties. Be sure that the rope itself is not too thick, a leather one is mostly OK, but I actually used two ropes for the prototype:
      1. A DOMYOS Jump-in Skipping Rope for the handles, it has nice handles but the rope itself is a little too thick and stiff.
      2. A DOMYOS Basic Skipping Rope for the actual rope: thin and flexible.
      The two together costed less than a leather rope.
    • A micro-controller small enough to fit inside the rope handle: I used a Trinket, relying on wire wrapping to do the needed connections.
    • A small battery: I used a 150mAh lipo battery, a bigger one would have not fit into the handle. A charger for the battery is also good to have, maybe in a second prototype I'll try to stick one inside the handle too; with the current prototype the battery has to be removed in order to be recharged.
    • A LED strip, like a 30 LEDs/m Neopixel strip to tie to the rope. One meter strip will cover one side of the rope. With a beefier battery a 60 LEDs/m strip could be used. An external battery pack could also be used and kept into an arm pocket, one of those used by runners to carry cell phones or MP3 players.
    • A small slip-ring, it has to fit inside the handle; it allows the rope to spin while still keeping electrical contact between the micro-controller and the LED strip. I used a short bolt from outside the handle to hold the slip-ring in place. Ironically the bolt gives a lightsaber kind of look to the JMP-rope handle.
    • A small momentary push button.
    • Two pins and a jumper as the ON switch.
    • Zip-ties and hot glue.

    I thought about using a BlinkyTape but the small battery would have not been enough for the 60 LEDs, and also the slip ring would have been necessary anyway, making the cost go higher. I did steal some code from Blinkinlabs, tho.

    See the pictures below to have an idea of the building process.

    If you are into hardware and want to help me realize a better prototype, get in touch. The Trinket is fine but I think more stuff could be squeezed in by using a custom board, or a Trinket daughter-board.

    JMP-rope internals overview
    JMP-rope handle detail
    JMP-rope LED strip tied to the rope
    JMP-rope programming socket
    JMP-rope lit up

    0 0

    Here are some notes about how to use the PS3 BD Remote Controller with raspbmc (raspbmc is an XBMC distribution optimized for the Raspberry Pi). This is the software setup used in June 2014:

    • Debian Wheezy (actually raspbian)
    • linux 3.12
    • Bluez 4.99

    I use one of those tiny USB Bluetooth adapters, a Mediacom M-UDBT15M.

    1. Install Bluez:
      $ sudo apt-get update
      $ sudo apt-get install bluez python-gobject-2
    2. Associate the PS3 BD Remote Controller (only needed once):
      $ hcitool scan

      then keep pressed Enter+Start on the remote for at least 7 seconds, until the BT device shows up: 00:06:F5:XX:XX:XX BD Remote Control

      Then execute these commands immediately:

      $ bluez-test-device create 00:06:F5:XX:XX:XX
      $ bluez-test-device trusted 00:06:F5:XX:XX:XX yes
      $ bluez-test-input connect 00:06:F5:XX:XX:XX

      Now the controller shows up as an input event device (/dev/input/ps3 linked to something like /dev/input/event0). The keymap can be seen by installing and running evtest.

    3. Configure lirc. This is needed because XBMC input handling is kind of weird (maybe for historical reasons), it tries too hard to differentiate between keyboards and remotes instead of just using the linux evdev API in a generic way.

      Put this in /etc/lirc/lircd.conf:

      include "/usr/share/lirc/remotes/devinput/lircd.conf.devinput"

      And this in /etc/lirc/hardware.conf

      # /etc/lirc/hardware.conf
      # Arguments which will be used when launching lircd
      #Don't start lircmd even if there seems to be a good config file
      #Don't start irexec, even if a good config file seems to exist.
      #Try to load appropriate kernel modules
      # Run "lircd --driver=help" for a list of supported drivers.
      # usually /dev/lirc0 is the correct setting for systems using udev.
      # Default configuration files for your hardware if any

    Reboot and that's it; the default mappings in /opt/xbmc-bcm/xbmc-bin/share/xbmc/system/Lircmap.xml and /opt/xbmc-bcm/xbmc-bin/share/xbmc/system/keymaps/remote.xml are already good enough.


    Raspbmc puts its custom built version of XBMC under /opt, with custom scripts to manage updates and other tasks, why not just create Debian packages of the latest XBMC (with patches for Raspberry Pi) and set up a dedicated apt repository?

    XBMC could modernize its input handling making a better use of the linux evdev API: with modern kernels more remote controls show up as input event devices, and lirc should not be needed to handle them.

    0 0

    Il modem ADSL2+ Wi-Fi N Technicolor, detto anche AGTWI, è fornito da Telecom Italia per i contratti residenziali; il provider non prevede il suo uso come router. Questa è evidentemente una limitazione artificiale del software fornito dal provider, dato che l'hardware è pienamente capace di funzionare come router ADSL. L'hardware è basato su quello del router Technicolor TG582n, la variante usata da Telecom viene chiamata TG582Tn.

    La procedura di sblocco del modem ADSL AGTWI per permetterne l'uso come router è interessante: invece di sfruttare una vulnerabilità (o una backdoor) del software per ottenere privilegi e modificare la configurazione predefinita, si aggira completamente il problema sostituendo il bootloader con quello di un dispositivo abbastanza simile; dopo aver fatto ciò diventa possibile installare software di altri provider che permettono l'uso del dispositivo come router.

    È possibile trovare il TG582n in due revisioni hardware, con relativa variante software: DANT-T con flash da 8MiB e DANT-1 con flash da 16MiB in configurazione dual-bank (cioè con la possibilità di contenere due immagini software da 8MiB, una alternativa all'altra). Il TG582Tn di Telecom Italia invece usa la variante software DANT-V.

    La procedura per sostituire il bootloader DANT-V con quello DANT-T è stata proposta da roleo (necessaria la registrazione al forum) sul forum Il Punto Tecnico e ADSL, ed è stata ripresa fra gli altri da Rix94 e Bestemmie Digitali.

    I documenti attualmente presenti in rete spiegano come saldare una interfaccia SPI per porta parallela alla memoria flash per modificarne il contenuto, e dicono di modificare il bootloader a mano copiando e incollando regioni di memoria da un file all'altro.

    La procedura può essere semplificata e resa più robusta se mettiamo meglio a fuoco gli obiettivi:

    1. Leggere da una memoria flash che usa il protocollo SPI.
    2. Modificare un file binario sostituendo alcune sue regioni con quelle di un altro file binario.
    3. Scrivere su una memoria flash che usa il protocollo SPI.

    Interfaccia seriale

    Per lo sblocco del modem nessuna saldatura è strettamente necessaria, tuttavia, per avere maggiore controllo su cosa sta succedendo, si può saldare opzionalmente una striscia di pin sulla piazzola J3 e cortocircuitare le piazzole R62 e R63 per avere accesso all'interfaccia seriale:

    Interfaccia seriale su TG582Tn

    Per il collegamento si può usare un adattatore USB-seriale basato su chip Prolific PL-2303HX o un adattatore multi protocollo basato su chip FTDI FT2232H o simili.

    Leggere la memoria flash SPI

    La memoria flash nel mio caso è una Spansion S25FL129P; per accedere al suo contenuto può essere usato un qualsiasi programmatore SPI, non necessariamente uno auto-costruito per porta parallela.

    Come programmatore SPI si può usare per esempio un TIAO USB Multi-Protocol Adapter seguendo questo schema:

    Collegamento TUMPA-S25FL129P

    NOTA: il datasheet di S25FL129P riporta che i pin HOLD# (per mettere il chip in pausa) e #W (per abilitare la protezione dalla scrittura) sono active-low quindi per disabilitarne le funzioni dovrebbero essere collegati a VCC, ma in questo caso va bene anche collegarli a GND, per questi motivi:

    • la funzione HOLD# si attiva al fronte discendente, cioè al cambio di livello logico da alto a basso, e collegando il pin a GND il livello è sempre basso, quindi non si attiva mai;
    • l'effetto di W# dipende anche da altri registri di stato del chip, in questo caso viene del tutto disabilitata la funzione di protezione (dal datasheet: SRWD: 0 = No protection, even when W#/ACC is low).

    Per il collegamento si può usare un morsetto di test per chip SOIC-16 come il Pomona 5252, in questo modo nessuna saldatura è strettamente necessaria:

    Collegamento TUMPA-TG582Tn

    Per leggere la memoria usando il TUMPA si può usare flashrom:

    sudo flashrom -p ft2232_spi:type=tumpa,port=A -Vr dump.bin

    È utile conservare una copia di backup del contenuto della flash; potrà essere usata per riportare il dispositivo al suo stato originale.

    Modificare il bootloader

    A questo punto basterebbe scrivere il file bootloader_pn.bin fornito da roleo per avere un dispositivo DANT-T ed essere in grado di installare un firmware generico per DANT-T, ma così facendo si avrebbero gli stessi dati (chiavi, certificati, MAC address, serial number, product version) del modem da cui è stato preso quel file.

    Per mantenere i dati del nostro dispositivo, si dovrà applicare una “patch” al file bootloader_pn.bin.

    Il file bootloader_pn.binè composto da due regioni:

    • da 0x00000000 a 0x0001ffff c'è il bootloader; più precisamente c'è una routine di unpacking ed il binario vero e proprio del bootloader compresso con LZMA.
    • da 0x00020000 a 0x0003ffff c'è la “configurazione di fabbrica”; la regione viene anche chiamata mtdss e contiene i dati identificativi del singolo dispositivo.

    Invece di copiare e incollare regioni di file binari a mano, è possibile usare dd in uno script di shell per automatizzare la procedura:

    # - patch DANT-V flash dump with DANT-T bootloader
    # Copyright (C) 2014  Antonio Ospite <>
    # This program is free software. It comes without any warranty, to
    # the extent permitted by applicable law. You can redistribute it
    # and/or modify it under the terms of the Do What The Fuck You Want
    # To Public License, Version 2, as published by Sam Hocevar. See
    # for more details.
    set -e
      local INPUT_FILE="$1"
      local OUTPUT_FILE="$2"
      local START_ADDRESS=$3
      local END_ADDRESS=$4
      local SIZE=$(($END_ADDRESS - $START_ADDRESS + 1))
      dd if="$INPUT_FILE" of="$OUTPUT_FILE" \
        skip=$(($START_ADDRESS)) count=$SIZE seek=$(($START_ADDRESS)) \
        conv=notrunc iflag=skip_bytes,count_bytes oflag=seek_bytes
      local OUTPUT_FILE="$1"
      local START_ADDRESS=$2
      local END_ADDRESS=$3
      local SIZE=$(($END_ADDRESS - $START_ADDRESS + 1))
      # Write all 0xff to $OUTPUT_FILE
      dd if=/dev/zero count=$SIZE iflag=count_bytes | \
        tr '\0''\377' | \
        dd of="$OUTPUT_FILE" seek=$(($START_ADDRESS)) conv=notrunc oflag=seek_bytes
    # Take the DANT-T bootloader
    copy_region "$DANT_T_BOOTLOADER""$PATCHED_DANT_V_DUMP_FILE" 0x00000000 0x0001ffff
    # Take the DANT-V mtdss region (the board specific data: serial number,
    # certificates, mac addresses, etc.)
    copy_region "$DANT_V_DUMP_FILE""$PATCHED_DANT_V_DUMP_FILE" 0x00020000 0x0003ffff
    # Patch the product code and the firmware variant code, e.g.:
    #   DANT-V -> WL
    #   DANT-T -> WJ
    # This does not appear to be strictly necessary, DANT-T firmwares will install
    # even if we keep the DANT-V data here.
    copy_region "$DANT_T_BOOTLOADER""$PATCHED_DANT_V_DUMP_FILE" 0x000216fc 0x00021713
    # Patch the mtdss region in order to make the device look like a DANT-T,
    # otherwise the client will still ask a DANT-V file (output of bootpd):
    #   bootpd: info(6):   requested path=""  file="DANT-V"
    # It is not enough to patch only the board name (0x00021727 0x00021728), some
    # more data needs to be copied in order to prevent a failure with
    copy_region "$DANT_T_BOOTLOADER""$PATCHED_DANT_V_DUMP_FILE" 0x00021727 0x00021730
    # Erase all the rest of the flash, this will prevent a failure with:
    #   Version BL: 1.0.5
    #   Unhandled TLB
    #   Unhandled exception
    #   EPC=0x8130ff30, BadVAddr=0xc0830000, RA=8130fef8
    #   ...
    # The bootloader will still output the message BLFLAG_FLASH_FAIL (bad FVP) but
    # that is OK, it will be fixed whith the firmware installation via tftp.
    erase_region "$PATCHED_DANT_V_DUMP_FILE" 0x00040000 0x0ffffff

    Scrivere la memoria flash SPI

    Il file dump_patched.bin creato dallo script precedente può essere scritto con flashrom:

    sudo flashrom -p ft2232_spi:type=tumpa,port=A -Vw patched_dump.bin

    Installare un nuovo firmware

    Per installare un nuovo firmware si può evitare di usare il Technicolor Home Install Wizard se si configura un server tftp.

    0 0

    I got a Teclast X98 Air 3G tablet from Aliexpress, it costed 168 € ( with free shipping) and has a high-definition screen and it's an Intel Bay Trail device; so Android, x86 architecture, 2GiB of RAM and 32 GiB of storage on EMMC. I think the product has some minor design issues:

    • the speakers are on the same side, the short side, not great when watching videos, but you want headphones or external speakers for better sound anyway;
    • when displaying content with a white background at medium brightness, the screen shows some —very light— yellowish gradient;
    • when using the leather cover the SIM slot and the MicroSD slot cannot be accessed, they are, well, covered;
    • the device does not rotate the screen automatically when booted in landscape mode, the android login screen is shown always in portrait mode at boot; this is inconvenient when booting the tablet while it's on the desk; BTW the firmware screens and the boot logos are also always shown in portrait mode, I guess that's OK for a tablet, but I would have picked a logo with some radial symmetry, or maybe drawn it at an angle, in order to alleviate the feeling of wrong orientation when booting with the device in landscape orientation;
    • the UEFI firmware informative screen is shown at boot, giving the boot experience and old PC feeling, or maybe I should say classic or familiar, I am not sure; this can be disabled in the firmware settings tho;

    but beside that it's not bad considering the price, it's got HDMI output, 3G and a MicroSD slot (yeah, I'm lookin' right atch-ya, Google Nexuses...).

    I eventually intend to run Debian on it, but let's take a look at the specs and do a full backup first.

    Hardware and kernel support

    Some info about the CPU:

    ao2@localhost:~/WIP/Teclast $ adb shell cat /proc/cpuinfo | grep model\ name | uniq
    model name      : Intel(R) Atom(TM) CPU  Z3736F @ 1.33GHz

    On Debian unstable adb is available in the android-tools-adb package.

    Here is the full dmesg log.

    It's pretty easy to get it, as the device came pre-rooted:

    ao2@localhost:~/WIP/Teclast $ adb root
    ao2@localhost:~/WIP/Teclast $ adb shell dmesg > dmesg-Teclast_X98_Air_3G.log

    UEFI firmware backup (with flashrom)

    The firmware configuration menu (Aptio Setup Utility) can be accessed by pressing ESC or DEL on a USB keyboard connected to the USB OTG adapter.

    The version I have reports these informations:

    BIOS Vendor                    American Megatrends
    Core version                    5.008
    Compliancy                      UEFI 2.3; PI 1.2
    Project Version	                A3G069 1.01 x64
    Build Date and Time	        08/29/2014 09:41:04

    There are newer firmware versions available on the net, so if I am going to test them it's better to save the one I have right now.

    Get and compile flashrom on an x86 host:

    ao2@localhost:~/WIP/Teclast $ git svn clone svn:// flashrom
    ao2@localhost:~/WIP/Teclast $ cd flashrom
    ao2@localhost:~/WIP/Teclast/flashrom $ make NEED_FTDI=no NEED_USB=no CFLAGS=-static LDFLAGS=-static

    Copy it on the target device and read the firmware:

    ao2@localhost:~/WIP/Teclast/flashrom $ adb push flashrom /data
    ao2@localhost:~/WIP/Teclast/flashrom $ cd ..
    ao2@localhost:~/WIP/Teclast $ adb root
    ao2@localhost:~/WIP/Teclast $ adb shell
    root@x98air3g_c6j6:/ # cd /data
    root@x98air3g_c6j6:/data # ./flashrom -p internal -r Teclast_X98_Air_3G_IFWI_flashrom_dump.rom
    flashrom v0.9.7-r1854 on Linux 3.10.20-g4a0098e-dirty (x86_64)
    flashrom is free software, get the source code at
    Calibrating delay loop... OK.
    No DMI table found.
    Found chipset "Intel Bay Trail".
    This chipset is marked as untested. If you are using an up-to-date version
    of flashrom *and* were (not) able to successfully update your firmware with it,
    then please email a report to including a verbose (-V) log.
    Thank you!
    Enabling flash write... OK.
    Found Winbond flash chip "W25Q64.W" (8192 kB, SPI) mapped at physical address 0x00000000ff800000.
    Reading flash... done.
    root@x98air3g_c6j6:/data # exit
    ao2@localhost:~/WIP/Teclast $ adb pull /data/Teclast_X98_Air_3G_IFWI_flashrom_dump.rom

    So flashrom can read the flash memory just fine, I haven't tried to write it yet, but I think I'll do it soon. Since it's an SPI flash there is a chance that it's reasonably easy to re-program it with an external programmer in case of a brick. I haven't taken the device apart yet to see what physical package the flash chip uses.

    EMMC backup

    The EMMC contains a GPT, the available partitions can be listed following the approach in this post, we get this:

    unit :  sectors
    /dev/mmcblk0p1   :  start    =  40,       size  =  131072,    Id=XX
    /dev/mmcblk0p2   :  start    =  131112,   size  =  131072,    Id=XX
    /dev/mmcblk0p3   :  start    =  262184,   size  =  32768,     Id=XX
    /dev/mmcblk0p4   :  start    =  294952,   size  =  32768,     Id=XX
    /dev/mmcblk0p5   :  start    =  327720,   size  =  32768,     Id=XX
    /dev/mmcblk0p6   :  start    =  360488,   size  =  32768,     Id=XX
    /dev/mmcblk0p7   :  start    =  393256,   size  =  131072,    Id=XX
    /dev/mmcblk0p8   :  start    =  524328,   size  =  65536,     Id=XX
    /dev/mmcblk0p9   :  start    =  589864,   size  =  32768,     Id=XX
    /dev/mmcblk0p10  :  start    =  622632,   size  =  32768,     Id=XX
    /dev/mmcblk0p11  :  start    =  655400,   size  =  32768,     Id=XX
    /dev/mmcblk0p12  :  start    =  688168,   size  =  2097152,   Id=XX
    /dev/mmcblk0p13  :  start    =  2785320,  size  =  65536,     Id=XX
    /dev/mmcblk0p14  :  start    =  2850856,  size  =  2097152,   Id=XX
    /dev/mmcblk0p15  :  start    =  4948008,  size  =  56115160,  Id=XX

    And the corresponding partition labels are:

    ao2@localhost:~/WIP/Teclast $  adb shell 'ls -l /dev/block/platform/intel/by-label/' | sort -t '>' -k 2.21n | column -t
    lrwxrwxrwx  root  root  2014-11-20  13:38  ESP         ->  /dev/block/mmcblk0p1
    lrwxrwxrwx  root  root  2014-11-20  13:38  reserved    ->  /dev/block/mmcblk0p2
    lrwxrwxrwx  root  root  2014-11-20  13:38  boot        ->  /dev/block/mmcblk0p3
    lrwxrwxrwx  root  root  2014-11-20  13:38  recovery    ->  /dev/block/mmcblk0p4
    lrwxrwxrwx  root  root  2014-11-20  13:38  fastboot    ->  /dev/block/mmcblk0p5
    lrwxrwxrwx  root  root  2014-11-20  13:38  reserved_1  ->  /dev/block/mmcblk0p6
    lrwxrwxrwx  root  root  2014-11-20  13:38  test        ->  /dev/block/mmcblk0p7
    lrwxrwxrwx  root  root  2014-11-20  13:38  panic       ->  /dev/block/mmcblk0p8
    lrwxrwxrwx  root  root  2014-11-20  13:38  factory     ->  /dev/block/mmcblk0p9
    lrwxrwxrwx  root  root  2014-11-20  13:38  misc        ->  /dev/block/mmcblk0p10
    lrwxrwxrwx  root  root  2014-11-20  13:38  config      ->  /dev/block/mmcblk0p11
    lrwxrwxrwx  root  root  2014-11-20  13:38  cache       ->  /dev/block/mmcblk0p12
    lrwxrwxrwx  root  root  2014-11-20  13:38  logs        ->  /dev/block/mmcblk0p13
    lrwxrwxrwx  root  root  2014-11-20  13:38  system      ->  /dev/block/mmcblk0p14
    lrwxrwxrwx  root  root  2014-11-20  13:38  data        ->  /dev/block/mmcblk0p15

    I didn't have an empty MicroSD card handy, so I used an external hard drive connected to the USB OTG adapter to strore the backups, I had to use adb via TCP/IP:

    ao2@localhost:~/WIP/Teclast $ adb tcpip
    ao2@localhost:~/WIP/Teclast $ adb connect
    ao2@localhost:~/WIP/Teclast $ adb root
    ao2@localhost:~/WIP/Teclast $ adb shell

    And I ran this script:

    # The data partition is more than 20GiB, let's skip it.
    find /dev/block/platform/intel/by-label -type l | grep -v '/data$' |
    while read partition;
      OUTPUT_FILE="/storage/usbcard1/$(basename "$partition").img"
      echo "Dumping '$partition' to '$OUTPUT_FILE'"
      dd if="$partition" of="$OUTPUT_FILE"

    First quick inspection

    There are some Android bootimgs (boot, fastboot, recovery) which can be modified with these Bootimg-scripts, I noticed that the kernel is compiled for a 32-bit architecture.

    Some ext4 filesystems (cache, config, factory, logs, system).

    Some raw data partitions (misc, panic, reserved_1, reserved, test).

    The ESP partition is the UEFI boot partition (EFI System Partition), it's a FAT32 filesystem and can be loop-mounted with no problems.

    A quick analysis with binwalk shows that this partition contains some 800x1000 bitmaps:

    ao2@localhost:~/WIP/Teclast $ binwalk ESP.img
    1051648       0x100C00        Microsoft portable executable
    1149888       0x118BC0        PC bitmap, Windows 3.x format, 800 x 1000 x 24
    2465927       0x25A087        LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, missing uncompressed size
    3620864       0x374000        Microsoft portable executable
    3676128       0x3817E0        PC bitmap, Windows 3.x format, 800 x 1000 x 24
    4992167       0x4C2CA7        LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, missing uncompressed size
    6100480       0x5D1600        Microsoft portable executable
    6198720       0x5E95C0        PC bitmap, Windows 3.x format, 800 x 1000 x 24
    7514759       0x72AA87        LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, missing uncompressed size

    The pictures can be spotted with a really rough approach using rawtoppm from netpbm:

      ao2@localhost:~/WIP/Teclast $ rawtoppm -bgr 800 $(($(stat -c "%s" ESP.img) / 3 / 800)) ESP.img > ESP.ppm

    It turns out that all the three pictures are equal: it's the logo shown at boot right after the UEFI firmware screen.

    The logo is contained once in each of the EFI binaries:

    ao2@localhost:~/WIP/Teclast $ mkdir ESP
    ao2@localhost:~/WIP/Teclast $ sudo mount -o loop ESP.img ESP/
    ao2@localhost:~/WIP/Teclast $ find ESP/
    ao2@localhost:~/WIP/Teclast $ binwalk ESP/EFI/BOOT/bootx64.efi
    0             0x0             Microsoft portable executable
    98240         0x17FC0         PC bitmap, Windows 3.x format, 800 x 1000 x 24
    1414279       0x159487        LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, missing uncompressed size
    ao2@localhost:~/WIP/Teclast $ dd if=ESP/EFI/BOOT/bootx64.efi of=boot_logo.bmp skip=$((0x0017fc0)) count=$((800 * 1000 * 3 + 0x36)) iflag=count_bytes,skip_bytes
    ao2@localhost:~/WIP/Teclast $ sudo umount ESP

    firmware splash logo

    I guess the logo can be pretty easily replaced with a custom one, but I haven't done that yet.

    Maybe the EFI binaries just display the logo and then boot an Android boot image from the right partition, depending on the boot option.

    The tablet has three boot options:

    1. normal boot (just quick press the power button);
    2. DROIDBOOT PROVISION OS (quick press the power button and keep pressed for a while the volume-down key);
    3. DnX mode, accepting fastboot commands (quick press the power button and keep pressed both volume keys for a while);

    and there are three efi binaries, are these things connected?

    I need to learn more about how this UEFI thing works in order to confirm that.

    Just to conclude the boot-logos-analysis™, the device shows three logos during the boot sequence:

    1. the generic Teclast t-pad logo mentioned before;
    2. an animated logo referring the X98 Air 3G device, it's in Chinese but it's pretty straightforward to see that, even with zero knowledge of the language;
    3. an Intel-Inside logo.

    The last two logos are boot animations, fired up one after the other by the bootanim service invoked by the init.rc file that is on the boot partition; the animation data is taken from the system partition, it's in the media/ file: just PNGs, one per frame.

    Pictures attached below.

    So after some hours of looking I found that it'd be super easy to customize the root filesystem and even all the logos of the boot sequence; however what I really want to do is to load a custom kernel, but that's meat for another day.

    boot logo 1
    boot logo 2
    Attached files: 

    0 0

    While I was trying to boot a vanilla linux kernel on the Teclast X98 Air 3G I messed up a bit with the UEFI firmware settings: the battery was not recognized anymore, the tablet was rebooting right after showing the UEFI firmware boot screen, and USB-host was not working either; so no keyboard for accessing the firmware menu to restore the default settings, and no ADB for running flashrom or the Intel FPT to reflash the firmware with. I decided to open the tablet and try to reprogram the flash chip In-System. In order to open the tablet without damaging it I started from the top of the device like shown in the video, and used something like these plastic opening tools.

    The SPI flash chip used for the firmware is a Winbond W25Q64FW in a SOIC-8 package, I first tried to reflash it with a TUMPA, and then with a Beaglebone Black, but I failed, and I even managed to brick the device: the boot screen was not even displayed anymore.

    Guess why... it was because I was trying to flash at 3.3V while the chip is supposed to work at 1.8V.

    These are the FAILS which tech you a lesson the hard way:

    Read the datasheet cover to cover (and maybe even understand it).

    The indication about 1.8V was on the very first page...

    OK, so I had a bricked device, how would I unbrick it?

    There were several scenarios ahead:

    1. The flash chip was just erased, not damaged. Try to flash the chip at 1.8V.
    2. The flash chip was damaged. Unsolder it with a cheap Hot Air station (which I got anyway), and replace the chip with a new one found on AliExpress.
      Goto 1.
    3. Operating at 3.3V damaged some other components. Get another tablet and use this one for spare parts.

    Luckily 1 was the case.

    In order to flash at 1.8V I used this Logic Level Converter board from Sparkfun, and attached it to the BeagleBone Black like shown in the pictures below, I followed the indications from How to Access Chips Over the SPI on BeagleBone Black; the BBB kindly supplies 1.8V at pin 32 on the P9 header, so I used that as a reference for the lower voltage for the level converter.

    The software side was pretty easy as I had flashrom already working on the BBB, and I had a backup of the flash contents:

    root@arm:~/flashrom# echo BB-SPIDEV0 > /sys/devices/bone_capemgr.*/slots
    root@arm:~/flashrom# ./flashrom -V -p linux_spi:dev=/dev/spidev1.0 -w ../Teclast_X98_Air_3G_IFWI_flashrom_dump.rom

    And the tablet was working again.

    Now back to try running vanilla kernels on it.

    Cosimo Orlando published an article about Unbricking a Teclast X98 BIOS with Bus Pirate 4 and Flashrom.

    Teclast X98 Air 3G, internals
    Teclast X98 Air 3G, mainboard
    ISP with a logic level converter, top
    ISP with a logic level converter, angle

    0 0

    Hans de Goede informs me that he has been working on gm12u320-kms: a new linux kernel driver for the Acer C120 mini projector, and possibly other devices based on the Grain Media GM12U320 USB3 bridge chip. Hans' driver exposes the projector as a KMS device and has been based on Viacheslav Nurmekhamitov's famebuffer driver.

    The most interesting feature of this new driver is the support for PRIME: a cross-device buffer sharing mechanism provided by the linux DRM subsystem.

    These USB displays/projectors are usually rather dumb, they just display frames passed to them in a given format, without any hardware acceleration; so PRIME is really useful for them, it allows the rendering to be performed by another (hardware accelerated) device, using the projector just for the final copy to the "screen".

    Before anyone asks, this driver does not work with am7xxx devices.