SIDEBAR
»
S
I
D
E
B
A
R
«
HOWTO: restore an iPad using only Free Software
Feb 14th, 2018 by miki

Thanks to the fine people at the libimobiledevice project, who bothers to reverse engineer Apple products, I recently succeeded in resurrecting a relative’s iPad stuck in a boot loop (something with jailbreaking, running Sydia, missing an iOS update and attempted Sydia removal) without any use of proprietary tools.

This is a brief recipe of the procedure done using Ubuntu 16.04.

As the required tool from libimobiledevice, idevicerestore, is not packaged in the Ubuntu libimobiledevice package we need to build this from scratch from the sources.

iPad during recovery

iPad in recovery mode during firmware download using libimobiledevice

  1. Install build dependencies
    sudo apt install libusbmuxd-dev libplist-dev libplist++-dev libzip-dev
  2. fetch and build libimobiledevice main library
    cd
    git clone https://git.libimobiledevice.org/libimobiledevice.git
    cd libimobiledevice/
    ./autogen.sh
    make
  3. fetch and build libirecovery library
    cd
    git clone https://git.libimobiledevice.org/libirecovery.git
    cd libirecovery
    ./autogen.sh
    make
  4. fetch and build idevicerestore tool, using the homebuilt libraries
    cd
    git clone https://git.libimobiledevice.org/idevicerestore.git
    cd idevicerestore
    CFLAGS="-I$HOME/libirecovery/include -I$HOME/libimobiledevice/include" LDFLAGS="-L$HOME/libirecovery/src/.libs \
    -L$HOME/libimobiledevice/src/.libs" PKG_CONFIG_PATH=~/libirecovery:~/libimobiledevice/src ./autogen.sh
    make
  5. put the iDevice in recovery mode (iPad = press power+home until screen with “iTunes+cable” symbol appear, see image above and check Apple support for details), make sure it has adequate charge or it will refuse (red battery flashing)
  6. perform the actual restore, asking for flashing of latest firmware (~2.5GiB automatically downloaded), this will probably get you in trouble if you desire to jailbreak the device. I noticed while writing this post that the below actually doesn’t run the tool using the libraries built above, but I’m leaving it as it was done because it “worked for me” (TM) and I can’t experiment further because I haven’t got access to any iDevices (and desire to keep it that way):
    sudo $HOME/idevicerestore/src/idevicerestore --latest
    NOTE: using cached version data
    Found device in Recovery mode
    Identified device as j71ap, iPad4,1
    Latest firmware is iPad_64bit_11.2_15C114_Restore.ipsw
    Verifying 'iPad_64bit_11.2_15C114_Restore.ipsw'...
    Checksum matches.
    Extracting BuildManifest from IPSW
    Product Version: 11.2
    Product Build: 15C114 Major: 15
    INFO: device serial number is DMPM4V3SFK15
    Device supports Image4: true
    Variant: Customer Upgrade Install (IPSW)
    This restore will update your device without losing data.
    Using cached filesystem from 'iPad_64bit_11.2_15C114_Restore/058-86080-124.dmg'
    Found ECID 6653578882512
    Getting ApNonce in recovery mode... 03 6b cc ac 57 8a b4 29 29 c1 a9 fe e4 97 54 3b a8 36 59 5a 
    Trying to fetch new SHSH blob
    Getting SepNonce in recovery mode... df 5c ad 67 48 bd 38 b4 6f 72 0a 5c b0 81 87 c3 95 37 4a da 
    WARNING: Unable to find BbChipID node
    WARNING: Unable to find BbSkeyId node
    Request URL set to https://gs.apple.com/TSS/controller?action=2
    Sending TSS request attempt 1... response successfully received
    Received SHSH blobs
    Extracting iBEC.ipad4.RELEASE.im4p...
    Personalizing IMG4 component iBEC...
    Sending iBEC (710360 bytes)...
    Recovery Mode Environment:
    iBoot build-version=iBoot-4076.30.43
    iBoot build-style=RELEASE
    Sending AppleLogo...
    Extracting applelogo@2x~ipad.im4p...
    Personalizing IMG4 component AppleLogo...
    Sending AppleLogo (22709 bytes)...
    ramdisk-size=0x10000000
    Extracting 058-85997-124.dmg...
    Personalizing IMG4 component RestoreRamDisk...
    Sending RestoreRamDisk (59978774 bytes)...
    Extracting DeviceTree.j71ap.im4p...
    Personalizing IMG4 component RestoreDeviceTree...
    Sending RestoreDeviceTree (101420 bytes)...
    Extracting kernelcache.release.ipad4...
    Personalizing IMG4 component RestoreKernelCache...
    Sending RestoreKernelCache (13226783 bytes)...
    About to restore device... 
    Waiting for device...
    Device 3fb0f5cc97b83c61c85d4b8333796d9e536a4c83 is now connected in restore mode...
    Connecting now...
    Connected to com.apple.mobile.restored, version 15
    Device 3fb0f5cc97b83c61c85d4b8333796d9e536a4c83 has successfully entered restore mode
    Hardware Information:
    BoardID: 16
    ChipID: 35168
    UniqueChipID: 6653578882512
    ProductionMode: true
    Starting FDR listener thread
    About to send NORData...
    Found firmware path Firmware/all_flash
    Getting firmware manifest from build identity
    Extracting LLB.ipad4.RELEASE.im4p...
    Personalizing IMG4 component LLB...
    Extracting applelogo@2x~ipad.im4p...
    Personalizing IMG4 component AppleLogo...
    Extracting batterycharging0@2x~ipad.im4p...
    Personalizing IMG4 component BatteryCharging0...
    Extracting batterycharging1@2x~ipad.im4p...
    Personalizing IMG4 component BatteryCharging1...
    Extracting batteryfull@2x~ipad.im4p...
    Personalizing IMG4 component BatteryFull...
    Extracting batterylow0@2x~ipad.im4p...
    Personalizing IMG4 component BatteryLow0...
    Extracting batterylow1@2x~ipad.im4p...
    Personalizing IMG4 component BatteryLow1...
    Extracting glyphplugin@2x~ipad-lightning.im4p...
    Personalizing IMG4 component BatteryPlugin...
    Extracting DeviceTree.j71ap.im4p...
    Personalizing IMG4 component DeviceTree...
    Extracting recoverymode@2x~ipad-lightning.im4p...
    Personalizing IMG4 component RecoveryMode...
    Extracting iBoot.ipad4.RELEASE.im4p...
    Personalizing IMG4 component iBoot...
    Extracting sep-firmware.j71.RELEASE.im4p...
    Personalizing IMG4 component RestoreSEP...
    Extracting sep-firmware.j71.RELEASE.im4p...
    Personalizing IMG4 component SEP...
    Sending NORData now...
    Done sending NORData
    About to send RootTicket...
    Sending RootTicket now...
    Done sending RootTicket
    Waiting for NAND (28)
    Checking filesystems (15)
    Checking filesystems (15)
    Unmounting filesystems (29)
    Unmounting filesystems (29)
    Creating filesystem (12)
    About to send filesystem...
    Connected to ASR
    Validating the filesystem
    Filesystem validated
    Sending filesystem now...
    [==================================================] 100.0%
    Done sending filesystem
    Verifying restore (14)
    [==================================================] 100.0%
    Checking filesystems (15)
    Checking filesystems (15)
    Mounting filesystems (16)
    Mounting filesystems (16)
    About to send KernelCache...
    Extracting kernelcache.release.ipad4...
    Personalizing IMG4 component KernelCache...
    Sending KernelCache now...
    Done sending KernelCache
    Installing kernelcache (27)
    About to send DeviceTree...
    Extracting DeviceTree.j71ap.im4p...
    Personalizing IMG4 component DeviceTree...
    Sending DeviceTree now...
    Done sending DeviceTree
    Certifying Savage (61)
    Flashing firmware (18)
    [==================================================] 100.0%
    Updating gas gauge software (47)
    Updating gas gauge software (47)
    Updating Stockholm (55)
    About to send FUD data...
    Sending FUD data now...
    Done sending FUD data
    About to send FUD data...
    Sending FUD data now...
    Done sending FUD data
    Fixing up /var (17)
    Modifying persistent boot-args (25)
    Unmounting filesystems (29)
    Unmounting filesystems (29)
    Got status message
    Status: Restore Finished
    Cleaning up...
    DONE
  7. The iDevice should reset and boot into the new firmware.
iPad during firmware flashing using libimobiledevice

iPad during firmware flashing using libimobiledevice

If you want to interact with iDevices from within Ubuntu during ordinary use, you could also install some utils and plugins for that. Below will fx. add a context menu in nautilus with info about the iDevice and install the ideviceinstaller command line utility which can be used to administer installed applications on the device.

sudo apt install libimobiledevice-utils nautilus-ideviceinfo ideviceinstaller

[Danish] Open source og LoRa er lidt vel store ord
Jan 6th, 2017 by miki

Redigeret 2018-08-03: rettet døde links

Min kommentar til LoRa og LoRaWANs åbenhed i forbindelse med artikel i Version2 med overskriften “TDC holder fast i proprietær IoT-standard – andre kører billig open source”, som nok mest minder om et bidrag til “open washing” af LoRa/LoRaWAN-teknologien. Se mere om open washing i denne blogpost fra Open Knowledge Foundation Denmark (Engelsk udgave).

Det er noget misvisende at snakke om at LoRa eller LoRaWAN er “open source”. Man er i hvert fald nødt til at skelne hårdt mellem LoRa og LoRaWAN.

LoRa specificerer radiomodulationen i luften, og det er en proprietær teknologi udviklet af virksomheden Semtech, som både har varemærkebeskyttet og patenteret den (EPO-patent);

LoRa is a proprietary spread spectrum modulation scheme that is derivative of Chirp Spread Spectrum modulation  (CSS)

Kilde: Semtech AN1200.22, LoRa(TM) Modulation Basics (https://www.semtech.com/uploads/documents/an1200.22.pdf, afsnit 1)

LoRaWAN er en åben protokol der anvender LoRa som transmissionsmedie, men som yderligere definerer hvordan flere enheder der alle kan snakke LoRa kan fungere sammen i et netværk. Den specificeres af et samarbejde mellem mange interessenter i LoRa Alliance, herunder også Semtech.

Q: What is LoRaWAN(TM)?
A: The LoRa modulation is the pshysical layer (PHY), and LoRaWAN is a MAC protocol for a high capacity, long range star network that the LoRa Alliance is standardizing for Low Power WideArea Networks (LPWAN).

Kilde: Semtech LoRa® FAQ (http://www.semtech.com/wireless-rf/lora/LoRa-FAQs.pdf, spgm. 3)

En mere teknisk beskrivelse kan findes her; https://www.lora-alliance.org/What-Is-LoRa/Technology (from). LoRaWAN-specifikationen selv er næsten frit tilgængelig, det er kun folk med offentlige email-adresser der ikke må få den (dette er senere ændret, pr. 2018-08-03 er den frit tilgængelig).

For mig ser det dog ud som om Semtech og LoRa Alliance helt bevidst mudrer sondringen mellem LoRa og LoRaWAN, og synes det lugter af at det udelukkende er Semtech der kan og må producere silicium der implementerer LoRa. Selvom jeg ikke har kunnet finde steder det bliver sagt helt eksplicit.

Microchip og andre har produkter der snakker LoRa, men Semtech ser ud til altid at være med inde over, så jeg vil tro det stadig er en chip fra deres fabrik der ligger til grund for LoRa-funktionaliteten.

Der er dog folk der har kigget i sprækkerne på LoRa;

Spændende hvad der sker på dette felt. En mere fri og uafhængig infrastruktur i åbne licensbånd skal da være så velkommen.

Mikkel

[Danish] S&S: gemme data i Arduino ROM/Flash (PROGMEM / F())
Dec 21st, 2016 by miki

Mit svar på et spørgsmål i Facebook-gruppen Danske Arduino Entusiaster omkring Arduino ROM/Flash, PROGMEM og system-inklude-filer.

Spørgsmål

Hej er der en der ved hvor jeg kan hente dett lib. <avr/pgmspace.h> jeg skal bruge denne funktion PROGMEM
så jeg kan gemme et billede i Arduino uden SD kort
det kan være der er en der kender en anden måde at gøre det på.

Svar

pgmspace.h er en inklude-fil som er en del af c-biblioteket til AVR-arkitekturen (avr-libc). C-bibliotekets inklude-filer vil normalt ligge i kompilerens “system include”-sti (se GCC options -I og -isystem). Dermed kan den inkluderes blot med “#include <avr/pgmspace.h>”. Se evt. også Arduino-referencen på https://www.arduino.cc/en/Reference/PROGMEM.
 
Bemærk at PROGMEM ikke er en funktion, men en storage modifier (lager-modifikator) som fortæller kompileren at den kan placere en en given variabel i ikke-skrivbar lager (ROM/Flash). Der skal efterfølgende anvendes specielle funktioner til at læse data fra en sådan variabel (se referencen).
Arduino-frameworket har dog lavet en nem måde at placere konstant-strenge i Flash på (normalt lagres de i SRAM!), nemlig funktionen F() som kan anvendes direkte i f.eks. printf/write/print (Serial.print(F(“Waiting for connection”));)
 
Hvis du vil inspicere indholdet af pgmspace.h, kan du finde filen i Arduino IDE’ets installations-mappe under hardware/tools/avr/avr/include/avr/pgmspace.h. Det er ikke en man kan/skal redigere manuelt i, da den er tæt koblet med den binære kode i selve biblioteket.
 
Der findes også EEPROM-lager du sikkert vil kunne bruge til samme formål; https://www.arduino.cc/en/Reference/EEPROM

Se svaret på Facebook.

Den videre færd med F()

Da jeg ikke kunne finde en uddybende forklaring på F()-funktionen (som egentlig er en makro) i Arduino-dokumentationen (brugen nævnes meget kort i PROGMEM , Memory og Print), gravede jeg efterfølgende lidt rundt for at lære mere. I de sparsomme Arduino-eksempler er den anvendt udelukkende med konstante strenge, hvilket også viser sig at være et krav (eller i hvert fald noget der kan castes til const char *).

Makroen er defineret af Arduino-frameworket i filen hardware/arduino/avr/cores/arduino/WString.h (referencerne er ifht. min lokale installation af Arduino 1.6.9, pt. er nyeste 1.6.13) således:

#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))

Altså parametren til F() bruges som parameter til PSTR() (progmem string, er mit bud på navn) som er en makro defineret i pgmspace.h fra avr-libc.

Dens funktion er at caste parametrens type til konstant streng-pointer med PROGMEM modifier;

#define PSTR(s) ((const PROGMEM char *)(s))

Skal vi se på hvad PROGMEM rent faktisk er, så finder vi endnu et sæt makroer der ender med at blive udviddet til kompiler-attributten  __progmem__, igen definieret i pgmspace.h (hardware/tools/avr/avr/include/avr/pgmspace.h):

#define PROGMEM __ATTR_PROGMEM__

#define __ATTR_PROGMEM__ __attribute__((__progmem__))

__progmem__ attributten er en instruks til kompileren (GCC) og linkeren om ved programmering/flashing af programmet at placere disse data i en sektion af hukommelsen der hedder “.progmem“. Se evt. mere om dette i GCC-kompilerens dokumentation. For hver AVR-chip kompileren understøtter er der eksakte definitioner af hvilke hukommelsesadresser .progmem ligger på for netop denne chip.

Dvs. når man i sin kode skriver F(“test”) får man i virkeligheden:

(reinterpret_cast<const __FlashStringHelper *>(((const __attribute__((__progmem__)) char *)(“test”)))

Altså en konstant streng der lagres i AVR-processorens progmem-sektion, og som returværdi får en pointer til en konstant instans af en klasse kaldet “__FlashStringHelper“. Denne klasse må være lavet sådan at den anvender de korrekte mekanismer til at læse fra progmem-området (måske mere om dette i en senere artikel). Arduinos funktion-bibliotek (Serial.print() mm.) er lavet således at de direkte kan tage en parameter af denne type som erstatning for en konstant-streng (og det er netop her Arduino-frameworket viser sin værdi ved at abstrahere sådanne kompleksiteter væk fra programmøren).

Frostlight RGB LED strip
Aug 1st, 2016 by miki

Stumbled across a very cheap RGB LED strip where I live in Denmark from the brand Frostlight. Priced at down to DKK 50 ~ EUR 6.5 ~ USD 7.5 in Fleggaard at Danish/German border but goes for around DKK 200 ~ EUR 26 ~ USD 30 in the ordinary DIY and internet shops (still cheap compared to other sources). For this amount you get a product which on the packaging is called “3 meter farvede LED bånd (RGB)” (which is a little gibberish Danish and not grammatically correct), English: “3 meter colored LED strip (RGB)”, containing these components;

  • 3 meter strip
  • Controller + IR receiver
  • PSU (Power Supply Unit), 230 V->12 V, 22 W
  • IR Remote control

According to the description this setup “does it all”; RGB multi color LEDS, controller doing colour change, fading etc.

  • Length: 3 meter
  • LEDs: 90 (30 LEDS pr. meter, 3.33 cm between LEDs)
  • Width: 10 mm
  • Colors: 16
  • Burn time: 20.000 hours
  • Silicone protected

The big question for me as a maker/hacker/tinkerer was; Does it use individually addressable LEDs?

And no, it doesn’t;

Frostlight RGB LED, strip segment interconnection

Obviously (as could be expected from the price), this strip is made from plain RGB LEDs with discrete R, G & B LEDS in a common anode setup (12V pin is common, current needs to be sinked from each RGB to control colour and intensity).

The brand Frostlight is unknown to me (they have a very non-informative website without any real product information), but they seem to supply LED products to many discount supermarkets in Denmark. They have a youtube channel (which is not even mentioned on the homepage) containing some product information. Even one for the “Frostlight LED farve-bånd”.

I was looking for a quick and cheap way to source LEDs for the awesome WordClock project by grahamvinyl (Arduino source code at github.com/grahamvinyl/WordClock_color_edit). However, it won’t work as all LEDs on the strip will light up in the same colour, but I consider using it for a cheaper tweak of it.

At least I’m confident I’ll find something to use the strip for anyway.

 

Beaglebone Black periodic boot failure; patching mainline u-boot
Jan 15th, 2015 by miki

Patch for u-boot mainline master (http://git.denx.de/u-boot.git) to prevent BBB’s to get stuck in a u-boot prompt because of spurious characters being received on the serial console (see http://www.mikini.dk/index.php/category/beaglebone-black/boot-issue).

diff –git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
index 5ed86d9..c58f467 100644
— a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -12,6 +12,12 @@
#ifndef __CONFIG_TI_AM335X_COMMON_H__
#define __CONFIG_TI_AM335X_COMMON_H__

+#define CONFIG_AUTOBOOT_KEYED
+#define CONFIG_AUTOBOOT_STOP_STR “stop”
+#define CONFIG_AUTOBOOT_PROMPT “autoboot in %d seconds (type ‘%s’ to abort)\n”,bootdelay,CONFIG_AUTOBOOT_STOP_STR
+#define CONFIG_BOOT_RETRY_TIME 30
+#define CONFIG_RESET_TO_RETRY
+
#define CONFIG_AM33XX
#define CONFIG_ARCH_CPU_INIT
#define CONFIG_SYS_CACHELINE_SIZE       64
@@ -102,4 +108,7 @@
/* Now bring in the rest of the common code. */
#include <configs/ti_armv7_common.h>

+#undef  CONFIG_BOOTDELAY
+#define CONFIG_BOOTDELAY               5
+
#endif /* __CONFIG_TI_AM335X_COMMON_H__ */

Patch and compiled binaries at http://www.mikini.dk/wp-content/uploads/2015/01/u-boot_mainline_BBB-autoboot-patch_201501151.zip.

Install the new u-boot by copying the files “MLO” and “u-boot.img” to the root directory of your boot device (first FAT-partition on your SD-card or onboard MMC). Using the stock Debian image (http://beagleboard.org/latest-images) this can be done via USB by powering the board from your computers USB-interface, waiting for the BBB to boot and register its drive as an usb mass-storage in your OS. Now use your favorite file management application to copy the files from the above zip-file replacing the existing files.

Disclaimer: this is mostly an experiment, there is a lot of u-boot trees and patches floating around for the BBB (like https://github.com/beagleboard/u-boot), so probably mainline hasn’t got the most recent stuff for AM335x/BBB yet.

Beaglebone Black periodic boot failure; no high required, just stable voltage
Nov 6th, 2014 by miki

This is test report 3 in the series of tests on the “BBB doesn’t boot” issue, discussed here on the BBB mailing list.

The present test is accompanying this specific post in the discussion thread.

The goal of the test is to establish under which conditions the U15.2 (1A)  input provides a stable boot experience. The four test subjects are a strong pull down of 990 ohm and 0 ohm, and voltage divider circuits using 0 ohm and 1k ohm fixing the voltage at respectively 3.3V and 0.58V.

Results

The strong pull down of 990 ohm and 0 ohm on B_UART0_RX doesn’t prove successful, as was also the case with the weaker pull down of 45k2 ohm in test report 2, and the factory mounted pull down of 100k ohm.

But providing a stable 3.3V or 0.58V using a voltage divider with resistor values 0 ohm and 1k ohm results in a booting BBB in every test case!

This is analogous with the result of test 2 in test report 2, which established the same fact, but for B_UART0_RX = 1.81V using a 82k5 ohm resistor.

The second picture below shows an easy and safe way to establish the condition of test 3 as a permanent fix on the backside of the BBB pcb. It places an insulated wire between VDD_3V3B from terminal 5 on the non-populated P2″CTI JTAG, DNI” header and the B_UART0_RX signal on J1 (UART0 Serial Port) pin 4.

Failure Rates

  • Pull down of 990 ohm: 2 fails/60  boots= 3.33%
  • Forced 0V: 3 fails/60  boots= 5.00%
  • Forced 3.3V: 0 fails/100 boots= 0.00%
  • Forced 0.58V: 0 fails/60  boots= 0.00%

Pictures

Detailed Test Report

(formatted in nice emacs org-mode)

* BBB boot lockup test report 3

** Equipment
*** Device Under Test
    Beaglebone Black (BBB) produced by Element 14 (PCB REV B6, serial EM-400524+XA6001961,
    marked "Element 14").

*** Device Under Test #1
    Modify DUT by applying an additional 1k ohm pull down resistor in parallel to R165
    from J1.4 (B_UART0_RX)/U15.2 (1A) to P8.1 (DGND), thus forming a very strong pull 
    down on B_UART0_RX with resistive value of 1/(1/1k+1/82k5)= 990.1 ohm.

*** Device Under Test #2
    Modify DUT by applying a short circuit from from J1.4 (B_UART0_RX)/U15.2 (1A) to
    P8.1 (DGND), thus forcing 0V on B_UART0_RX.

*** Device Under Test #3
    Modify DUT by applying a short circuit from J1.4 (B_UART0_RX)/U15.2 (1A) to
    P8.4 (VDD_3V3B), thus forcing 3.3V on B_UART0_RX.

*** Device Under Test #4
    Modify DUT by applying a 470k ohm pull up resistor from J1, pin 4 (B_UART0_RX,
    U15-pin 2, signal 1A) to P8, pin 4 (VDD_3V3B), effectively creating a voltage
    divider with existing pull down resistor R165 (100k ohm) fixing voltage on
    B_UART0_RX to 3.3V*100k/(470k+100k)= 0.58V.

*** Power Supply Unit
    Huawei HW-050200E3W, output 5V 2A, USB A-connector. Danish plug.
    Sourced from Huawei E589 mobile wifi.

*** Power Cable
    20 cm no-name USB A male connector to USB Mini-B male connector.

** Test 1+2+3+4 Procedure
   For test 1 use DUT#1, for test 2 use DUT#2, for test 3 use DUT#3, for test 4
   use DUT#4.
   Connect cable Mini-B male to DUT USB Mini-B female. Insert PSU into mains socket.

   Test boot capability of DUT by inserting the cable's USB A connector into the
   PSU while keeping the USB Mini-B connector inserted into the DUT. Then verify
   that the power led (D1) light up, and note whether boot succeeded or failed by
   watching if USR0-USR3 leds (D2-D5) lights up indicating boot. Then remove the
   A connector from the mains adaptor inserting it immediately repeating the test.

   Results can be seen in section Test Results.

** Interpretation

   Test 1 failure rate= 2 fails/60  boots= *3.33%*
   Test 2 failure rate= 3 fails/60  boots= *5.00%*
   Test 3 failure rate= 0 fails/100 boots= *0.00%*
   Test 4 failure rate= 0 fails/60  boots= *0.00%*

   The tests 1 & 2 shows that forming first a strong pull down (replacing 100k
   with 9k1) and then a short forcing 0V on B_UART0_RX, doesn't prevent the failure
   to occur.

   Whereas test 3+4 shows that forming a voltage divider which fixes the voltage
   instead of just pulling up/down indeed makes the system boot at every power up.

   Overall this indicates that the flickering of U15's output 1Y could be caused
   internally in U15 by a spurious input signal on input 1A during power up. This
   can't be elleviated by inserting pull-up/downs, but creating a stable input
   signal on 1A by a voltage divider does solvs the boot issue, disregarding
   whether this voltage is low (0.58V) or high (3.3V).

** Test results

| Boot no. | Test 1  | Test 2   | Test 3 | Test 4  |
|        1 | boot    | no boot  | boot   | boot    |
|        2 | boot    | boot     | boot   | boot    |
|        3 | boot    | boot     | boot   | boot    |
|        4 | boot    | boot     | boot   | boot    |
|        5 | boot    | boot     | boot   | boot    |
|        6 | boot    | boot     | boot   | boot    |
|        7 | boot    | boot     | boot   | boot    |
|        8 | boot    | boot     | boot   | boot    |
|        9 | boot    | boot     | boot   | boot    |
|       10 | boot    | boot     | boot   | boot    |
|       11 | boot    | boot     | boot   | boot    |
|       12 | boot    | boot     | boot   | boot    |
|       13 | boot    | boot     | boot   | boot    |
|       14 | boot    | boot     | boot   | boot    |
|       15 | boot    | boot     | boot   | boot    |
|       16 | boot    | boot     | boot   | boot    |
|       17 | boot    | no boot  | boot   | boot    |
|       18 | boot    | boot     | boot   | boot    |
|       19 | boot    | boot     | boot   | boot    |
|       20 | boot    | boot     | boot   | boot    |
|       21 | boot    | boot     | boot   | boot    |
|       22 | boot    | boot     | boot   | boot    |
|       23 | boot    | boot     | boot   | boot    |
|       24 | boot    | boot     | boot   | boot    |
|       25 | boot    | boot     | boot   | boot    |
|       26 | boot    | boot     | boot   | boot    |
|       27 | no boot | boot     | boot   | boot    |
|       28 | boot    | no boot  | boot   | boot    |
|       29 | boot    | boot     | boot   | boot    |
|       30 | boot    | boot     | boot   | boot    |
|       31 | boot    | boot     | boot   | boot    |
|       32 | boot    | boot     | boot   | boot    |
|       33 | boot    | boot     | boot   | boot    |
|       34 | boot    | boot     | boot   | boot    |
|       35 | boot    | boot     | boot   | boot    |
|       36 | boot    | boot     | boot   | boot    |
|       37 | boot    | boot     | boot   | boot    |
|       38 | no boot | boot     | boot   | boot    |
|       39 | boot    | boot     | boot   | boot    |
|       40 | boot    | boot     | boot   | boot    |
|       41 | boot    | boot     | boot   | boot    |
|       52 | boot    | boot     | boot   | boot    |
|       53 | boot    | boot     | boot   | boot    |
|       44 | boot    | boot     | boot   | boot    |
|       45 | boot    | boot     | boot   | boot    |
|       46 | boot    | boot     | boot   | boot    |
|       47 | boot    | boot     | boot   | boot    |
|       48 | boot    | boot     | boot   | boot    |
|       49 | boot    | boot     | boot   | boot    |
|       50 | boot    | boot     | boot   | boot    |
|       51 | boot    | boot     | boot   | boot    |
|       52 | boot    | boot     | boot   | boot    |
|       53 | boot    | boot     | boot   | boot    |
|       54 | boot    | boot     | boot   | boot    |
|       55 | boot    | boot     | boot   | boot    |
|       56 | boot    | boot     | boot   | boot    |
|       57 | boot    | boot     | boot   | boot    |
|       58 | boot    | boot     | boot   | boot    |
|       59 | boot    | boot     | boot   | boot    |
|       60 | boot    | boot     | boot   | boot    |
|       61 | ------- | -------- | boot   | ------- |
|       62 |         |          | boot   |         |
|       63 |         |          | boot   |         |
|       64 |         |          | boot   |         |
|       65 |         |          | boot   |         |
|       67 |         |          | boot   |         |
|       68 |         |          | boot   |         |
|       69 |         |          | boot   |         |
|       70 |         |          | boot   |         |
|       71 |         |          | boot   |         |
|       72 |         |          | boot   |         |
|       73 |         |          | boot   |         |
|       74 |         |          | boot   |         |
|       75 |         |          | boot   |         |
|       76 |         |          | boot   |         |
|       77 |         |          | boot   |         |
|       78 |         |          | boot   |         |
|       79 |         |          | boot   |         |
|       80 |         |          | boot   |         |
|       81 |         |          | boot   |         |
|       82 |         |          | boot   |         |
|       83 |         |          | boot   |         |
|       84 |         |          | boot   |         |
|       85 |         |          | boot   |         |
|       86 |         |          | boot   |         |
|       87 |         |          | boot   |         |
|       88 |         |          | boot   |         |
|       89 |         |          | boot   |         |
|       90 |         |          | boot   |         |
|       91 |         |          | boot   |         |
|       92 |         |          | boot   |         |
|       93 |         |          | boot   |         |
|       94 |         |          | boot   |         |
|       95 |         |          | boot   |         |
|       96 |         |          | boot   |         |
|       97 |         |          | boot   |         |
|       98 |         |          | boot   |         |
|       99 |         |          | boot   |         |
|      100 |         |          | boot   |         |
|          |         |          | ------ |         |
Beaglebone Black periodic boot failure; fixing B_UART0_RX with voltage divider
Nov 4th, 2014 by miki

Investigating further on the BBB boot issue described in this earlier post and following discussion in the mailinglist, here is a test of another BBB modification trying to remedy this.

This time the modification is done on the non-cpu side of U15 (75LVC2G241 buffer/driver), where the buffered uart0 input (B_UART0_RX) is kept stable using a voltage divider. B_UART0_RX is already pulled low by a 100k resistor, but adding another 82k5 ohms pulling against 3,3v makes up a voltage divider, keeping input 1A on U15 stable at all times at approx. half (~55%) of the voltage between VDD_3V3B and DGND. At stable 3,3V that voltage will be 3.3V*100k/(82k5+100k)= 1.81V (EDIT: first edition of this post erroneously stated the voltage drop of ~1.4V over the pull up as the B_UART0_RX’s voltage level).

Beware that this modification might affect the functionality of uart0 rx capability. I’ll probably test this some time soon (TM) when I got access to my TTL<->USB converter.

These results are summed up in this post on the BBB mailinglist.

Results

Providing a stable B_UART0_RX at 1.8V results in a booting BBB in every test case!

The third picture below shows an easy and relatively safe way to make this a permanent fix on the backside of the BBB. It places a resistor (this one is 82k5 ohm ) between VDD_3V3B from terminal 5 on the non-populated P2 header marked as “CTI JTAG, DNI” and the  B_UART0_RX signal on J2 (UART0 Serial Port) pin 4.

Failure Rates

  • Unmodified BBB (DUT#1):  4 fails/65 boots= 6,2%
  • Fixed B_UART0_RX at ~1.8v (DUT#2): 0 fails/50 boots= 0,0%
  • Strong pull down on B_UART0_RX (DUT#3):  3 fails/50 boots= 6.0%

Pictures

Detailed Test Report

(formatted in nice emacs org-mode)

* BBB boot lockup test report 2
** Equipment*** Device Under Test #1
Unmodified Beaglebone Black (BBB) produced by Element 14
(PCB REV B6, serial EM-400524+XA6001961, marked "Element 14").
*** Device Under test #2
Modify DUT#1 by applying a 82k5 ohm pull up resistor from J1,
pin 4 (B_UART0_RX, U15-pin 2, signal 1A) to P8, pin 4 (VDD_3V3B),
effectively creating a voltage divider with existing pull down
resistor R165 (100k ohm) fixing voltage on B_UART0_RX to
3.3V*100k/(82k5+100k)= 1.81V.
*** Device Under Test #3
Modify DUT#1 by applying a 82k5 ohm pull down resistor from J1,
pin 4 (B_UART0_RX, U15-pin 2, signal 1A) to P8, pin 1 (DGND),
thus forming a stronger pull down on B_UART0_RX with resistive
value of 1/(1/100k+1/82k5)= 45k2 ohm
*** Power Supply Unit
 Huawei HW-050200E3W, output 5V 2A, USB A-connector. Danish plug.
 Sourced from Huawei E589 mobile wifi.
*** Power Cable
20 cm no-name USB A male connector to USB Mini-B male connector.
** Test 1 Procedure
Insert PSU into mains socket. Test boot capability of DUT#1 by
inserting the USB A connector into the mains socket adaptor while
keeping the USB Mini-B connector inserted into the BBB. Then verify
that the power led light up, and note whether boot succeeded or
failed by watching if USR0-USR3 lights up indicating boot. Then
remove the A connector from the mains adaptor wait 3 seconds and repeat.
Results can be seen in section Test Results, column Test 1.
** Test 2 Procedure
Repeat Test 1 procedure using DUT#2.
Results can be seen in section Test Results, column Test 2.
** Test 3 procedure
Repeat Test 1 procedure using DUT#3.
Results can be seen in section Test results, column Test 3.
** Interpretation
DUT#1 failure rate= 4 fails/65 boots= *6,2%*
DUT#2 failure rate= 0 fails/50 boots= *0,0%*
DUT#3 failure rate= 3 fails/50 boots= *6.0%*
Test 2 in reference to Test 1 shows that fixing B_UART0_RX to
1.4v using a voltage divider increases the system boot success
rate from 94% to 100%. Though the modification might affect the
functionality of uart0 rx capability.
Test 3 shows that forming a stronger pull down on B_UART0_RX
(100k->45k), dosn't change the failure rate as might be expected.
This suggest that some strong (internal?) signal that a pull
down in itself can't correct is driving the the 75LVC2G241's
1A input sometime during powerup.
** Test results
 | Boot no. | Test 1  | Test 2 | Test 3  |
 |        1 | boot    | boot   | boot    |
 |        2 | boot    | boot   | boot    |
 |        3 | boot    | boot   | boot    |
 |        4 | boot    | boot   | boot    |
 |        5 | boot    | boot   | boot    |
 |        6 | boot    | boot   | boot    |
 |        7 | boot    | boot   | boot    |
 |        8 | boot    | boot   | boot    |
 |        9 | boot    | boot   | boot    |
 |       10 | boot    | boot   | boot    |
 |       11 | boot    | boot   | boot    |
 |       12 | boot    | boot   | boot    |
 |       13 | boot    | boot   | boot    |
 |       14 | boot    | boot   | boot    |
 |       15 | boot    | boot   | boot    |
 |       16 | boot    | boot   | boot    |
 |       17 | boot    | boot   | boot    |
 |       18 | boot    | boot   | boot    |
 |       19 | boot    | boot   | boot    |
 |       20 | boot    | boot   | boot    |
 |       21 | no boot | boot   | boot    |
 |       22 | boot    | boot   | boot    |
 |       23 | boot    | boot   | boot    |
 |       24 | boot    | boot   | boot    |
 |       25 | boot    | boot   | boot    |
 |       26 | boot    | boot   | boot    |
 |       27 | boot    | boot   | boot    |
 |       28 | boot    | boot   | boot    |
 |       29 | boot    | boot   | boot    |
 |       30 | boot    | boot   | boot    |
 |       31 | boot    | boot   | boot    |
 |       32 | boot    | boot   | boot    |
 |       33 | boot    | boot   | no boot |
 |       34 | boot    | boot   | no boot |
 |       35 | boot    | boot   | boot    |
 |       36 | boot    | boot   | boot    |
 |       37 | boot    | boot   | boot    |
 |       38 | no boot | boot   | boot    |
 |       39 | boot    | boot   | boot    |
 |       40 | boot    | boot   | boot    |
 |       41 | boot    | boot   | boot    |
 |       52 | boot    | boot   | boot    |
 |       53 | boot    | boot   | boot    |
 |       44 | boot    | boot   | no boot |
 |       45 | no boot | boot   | boot    |
 |       46 | boot    | boot   | boot    |
 |       47 | boot    | boot   | boot    |
 |       48 | boot    | boot   | boot    |
 |       49 | boot    | boot   | boot    |
 |       50 | boot    | boot   | boot    |
 |       51 | boot    |        |         |
 |       52 | boot    |        |         |
 |       53 | boot    |        |         |
 |       54 | boot    |        |         |
 |       55 | boot    |        |         |
 |       56 | boot    |        |         |
 |       57 | boot    |        |         |
 |       58 | boot    |        |         |
 |       59 | boot    |        |         |
 |       60 | boot    |        |         |
 |       61 | boot    |        |         |
 |       62 | boot    |        |         |
 |       63 | boot    |        |         |
 |       64 | boot    |        |         |
 |       65 | no boot |        |         |
Beaglebone Black periodic boot failure; establishing failure rate and possible cause
Oct 31st, 2014 by miki

I’ve been hit by the “periodic boot failure” issue of the Beaglebone Black (aka BBB) reported by quite a few on the net. For most users this is an inconvenient annoyance, but for people, like me, using the platform in embedded applications, this issue causes a serious stability issue of the whole system, when 100% reliable boot is not achievable.

After having hunches about instability caused by the intermittent experiences during development, where the board was seen failing boot on power on, and not getting much more help from the net than “try the recommended power supply” (which btw. I can’t use because I live in a country where main sockets are non-US, even a bit non-European standard) I decided to make a systematic test to get the basic facts straight.

I settled on trying to establish some reasonable statistics about the error’s frequency on plain BBBs to have a reference against testing whether a theory put forward on the mailinglist (here and here) about the uboot bootloader being confused by noise being interpreted as valid data on UART0_RXD (pin E15) of the AM3358x  (see near U15 page 4, of the BBB REV B schematics) as the cause of the failure.

Results

This is the results (test report detailed below), I’m posting a writeup in the Beagleboard mailinglist (Edit: my post here), so hopefully you’ll find further discussion about this issue there soon.

Failure rates

Plain BBB (DUT#2+3), Element14 & mbest branded

  • DUT#2: Element14 branded: 4 fails/ 120 boots = 1/30 = 3.33%
  • DUT#3: mbest branded: 2 fail / 40 boots = 1/20 = 5.00
  • Overall: 6 fails / 160 boots = 3/80 = 3.75%

Modified BBB (DUT#1), CircuitCo branded

  • U15 removed, pull down on UART0_RXD : 0 fails / 40 boots = 0.00%
  • U15 removed, no pull down on UART0_RX: 0 fails / 40 boots = 0.00%
  • Overall: 0 fails / 80 boots = 0.00%

Interpretation

The two differing Element14 branded BBB products I have access to, but both PCB REV B6, exhibits a somewhat varying boot failure rate. But overall the boards fail to boot in almost 4 of 100 boots.

Investigating the theory relating to noise on UART0_RXD seems to have paid off, as first removing U15 (SN74LVC2G241: Dual Buffer/Driver With 3-State Outputs) for the purpose of adding a pull down on its pad 6 (which is connected to UART0_RXD)  alleviated the problem altogether. But also the experiment of removing the pull down and redo the test, showed that the act of removing U15 itself caused the boot to always succeed.

Unfortunately, in hindsight, I was too quick to grab the soldering iron, because I should have verified and quantized the occurrence of the failure on the actual board being modified. A shame It didn’t occur to me before modification, but I’ll be more than willing to try to remove U15 on DUT#2, which has had the highest failure rate, if discussions prove that it is a reasonable theory of the root cause of the failure. That is why I continued testing it through to 120 boots, to get more samples for improving statistics in the event that I pull U15 from it later.

Effect of removing U15

The success of removing U15 could be caused by the now floating AM3388 input UART0_RXD (pin E15) which presumably has a default weak internal pull up/down (the AM335x TRM says reset value is pad-dependent (register conf_uart0_rxd in Table 9.7 p. 1366 and  Section 9.3.1.50 p. 1420), which I haven’t yet figured out the exact meaning of)  stabilizing the signal

The activity when U15 is in place is somehow exhibited on output 1Y (pin 6) , probably because it is not stable, and thus has an erratic state, during the first moments of the chips power up sequence. This erratic behaviour can in fortunate/unfortunate circumstances be interpreted as valid bits and resulting bytes by the uart rxd cirtcuitry, which also can happen to be latched into the uart fifo rx buffer, waiting for uboot to read them when its code is executed looking for a user interrupt.

I’ll put in the disclaimer on this thesis, that I haven’t yet studied U15 in detail, but it is advertised as both a level converter, ESD protection and power live-insertion/partial-power-down suggesting it does something in reaction to it’s power condition.

Also the recommendation on page 1 of its datasheet; “To ensure the high-impedance state during power up or power down, OE (active low) should be tied to VCC through a pullup resistor, and OE (active high) should be tied to GND through a pulldown resistor”, seems not to be followed in the BBB circutry, as the OEs are hardwired in to be always active (opposite of the recommendation in the power up/down condition). If this is actually a problem, I need to do further analysis to establish.

Pictures

Detailed test report

(formatted in nice emacs org-mode)

* BBB boot lockup test report

** Device under test #1:
Modified Beaglebone Black produced by CircuitCo (PCB REV B6, serial 007142901445, marked
"beaglebone"+ beagle logo and "beagleboard.org").

Modified by adding hard pulldown resistor on TI AM3358 pin E15 (uart0 rx). Specifically
U15 was removed and terminal pin 6 (1Y=UART0_RX) was shorted to J1 pin 1 through a 82k5
ohm resistor.

** Device under test #2:
Unmodified Beaglebone Black (BBB) produced by Element 14 (PCB REV B6, serial
EM-400524+XA6001961, marked "Element 14").

** Device under test #3:
Unmodified Beaglebone Black (BBB) produced by mbest (PCB REV B6, serial
EM-400441+XA3001688).

** Power supply
Jentec Technologies CF1805-E, output 5V 3A. Danish plug.
Sourced from a D-Link DUB-H7 USB 2.0 HUB.

** Test 1 procedure

Each Beaglebone was tested by consequtively applying power by inserting the 
plug into the mains socket while keeping the DC barrel connector inserted and 
verifying that the power led light up, and then noting whether boot from SD-card 
succeeded or failed. Then removing the PSU from the mains connector waiting 5 
seconds and repeat.

The power supply and SD-card used was the same for all three DUTs.

Results can be seen in section Test 1 results.

** Test 2 procedure

After a short analysis of test 1 results I decided to try to remove the resistor, 
to see if the behavious was restored.

Otherwise test procedure was identical to test 1.
Results can be seen in section Test 2 results.

** Test 1 results (pull down and reference boards)

| Boot no | DUT#1 | DUT#2   | DUT#3   | Note                                  |
|       1 | boot  | boot    | boot    |                                       |
|       2 | boot  | boot    | boot    |                                       |
|       3 | boot  | boot    | boot    |                                       |
|       4 | boot  | boot    | boot    |                                       |
|       5 | boot  | boot    | boot    |                                       |
|       6 | boot  | boot    | boot    |                                       |
|       7 | boot  | boot    | boot    |                                       |
|       8 | boot  | boot    | boot    |                                       |
|       9 | boot  | boot    | boot    |                                       |
|      10 | boot  | boot    | boot    |                                       |
|      11 | boot  | no boot | boot    | DUT#2: pwr sw=lock, rst sw=boot       |
|      12 | boot  | boot    | boot    |                                       |
|      13 | boot  | boot    | boot    |                                       |
|      14 | boot  | boot    | boot    |                                       |
|      15 | boot  | boot    | boot    |                                       |
|      16 | boot  | boot    | boot    |                                       |
|      17 | boot  | boot    | boot    |                                       |
|      18 | boot  | boot    | boot    |                                       |
|      19 | boot  | boot    | boot    |                                       |
|      20 | boot  | no boot | boot    | DUT#2:  pwr sw=no boot, rst sw=boot   |
|      21 | boot  | boot    | boot    |                                       |
|      22 | boot  | boot    | boot    |                                       |
|      23 | boot  | boot    | boot    |                                       |
|      24 | boot  | boot    | boot    |                                       |
|      25 | boot  | boot    | boot    |                                       |
|      26 | boot  | boot    | boot    |                                       |
|      27 | boot  | boot    | boot    |                                       |
|      28 | boot  | boot    | boot    |                                       |
|      29 | boot  | boot    | boot    |                                       |
|      30 | boot  | boot    | boot    | DUT#3: pause before comencing test 31 |
|      31 | boot  | boot    | no boot | DUT#3: pwr sw=no boot, rst sw=boot    |
|      32 | boot  | no boot | boot    | DUT#2: pwr sw=no boot, rst sw=boot    |
|      33 | boot  | boot    | boot    |                                       |
|      34 | boot  | boot    | boot    |                                       |
|      35 | boot  | boot    | boot    |                                       |
|      36 | boot  | boot    | no boot | DUT#3: pwr sw=no boot, rst sw=boot    |
|      37 | boot  | boot    | boot    |                                       |
|      38 | boot  | boot    | boot    |                                       |
|      39 | boot  | boot    | boot    |                                       |
|      40 | boot  | boot    | boot    |                                       |
|      41 |       | boot    |         |                                       |
|      42 |       | boot    |         |                                       |
|      43 |       | boot    |         |                                       |
|      44 |       | boot    |         |                                       |
|      45 |       | boot    |         |                                       |
|      46 |       | boot    |         |                                       |
|      47 |       | boot    |         |                                       |
|      48 |       | boot    |         |                                       |
|      49 |       | boot    |         |                                       |
|      50 |       | boot    |         |                                       |
|      51 |       | boot    |         |                                       |
|      52 |       | boot    |         |                                       |
|      53 |       | boot    |         |                                       |
|      53 |       | boot    |         |                                       |
|      54 |       | boot    |         |                                       |
|      55 |       | boot    |         |                                       |
|      56 |       | boot    |         |                                       |
|      57 |       | boot    |         |                                       |
|      58 |       | boot    |         |                                       |
|      59 |       | boot    |         |                                       |
|      60 |       | boot    |         |                                       |
|      61 |       | boot    |         |                                       |
|      62 |       | boot    |         |                                       |
|      63 |       | boot    |         |                                       |
|      64 |       | boot    |         |                                       |
|      65 |       | boot    |         |                                       |
|      66 |       | boot    |         |                                       |
|      67 |       | boot    |         |                                       |
|      68 |       | boot    |         |                                       |
|      69 |       | boot    |         |                                       |
|      70 |       | boot    |         |                                       |
|      71 |       | boot    |         |                                       |
|      72 |       | boot    |         |                                       |
|      73 |       | boot    |         |                                       |
|      74 |       | boot    |         |                                       |
|      75 |       | boot    |         |                                       |
|      76 |       | boot    |         |                                       |
|      77 |       | boot    |         |                                       |
|      78 |       | boot    |         |                                       |
|      79 |       | boot    |         |                                       |
|      80 |       | boot    |         |                                       |
|      81 |       | boot    |         |                                       |
|      82 |       | boot    |         |                                       |
|      83 |       | boot    |         |                                       |
|      84 |       | boot    |         |                                       |
|      85 |       | boot    |         |                                       |
|      86 |       | boot    |         |                                       |
|      87 |       | boot    |         |                                       |
|      88 |       | boot    |         |                                       |
|      89 |       | boot    |         |                                       |
|      90 |       | boot    |         |                                       |
|      91 |       | boot    |         |                                       |
|      92 |       | boot    |         |                                       |
|      93 |       | boot    |         |                                       |
|      94 |       | boot    |         |                                       |
|      95 |       | boot    |         |                                       |
|      96 |       | boot    |         |                                       |
|      97 |       | boot    |         |                                       |
|      98 |       | boot    |         |                                       |
|      99 |       | boot    |         |                                       |
|     100 |       | boot    |         |                                       |
|     101 |       | boot    |         |                                       |
|     102 |       | boot    |         |                                       |
|     103 |       | boot    |         |                                       |
|     104 |       | boot    |         |                                       |
|     105 |       | boot    |         |                                       |
|     106 |       | no boot |         |                                       |
|     107 |       | boot    |         |                                       |
|     108 |       | boot    |         |                                       |
|     109 |       | boot    |         |                                       |
|     110 |       | boot    |         |                                       |
|     111 |       | boot    |         |                                       |
|     112 |       | boot    |         |                                       |
|     113 |       | boot    |         |                                       |
|     114 |       | boot    |         |                                       |
|     115 |       | boot    |         |                                       |
|     116 |       | boot    |         |                                       |
|     117 |       | boot    |         |                                       |
|     118 |       | boot    |         |                                       |
|     119 |       | boot    |         |                                       |
|     120 |       | boot    |         |                                       |

General DUT#3 behaviour: slower boot, pause after power on, and visible delay while 
lighting USRLED1-3 until SD-card boots. Might be caused by a different uboot edition
than DUT#1 and DUT#2.

** Test 2 results (DUT#1 pulldown removed)

| Boot no. | DUT#1 |
|        1 | boot  |
|        2 | boot  |
|        3 | boot  |
|        4 | boot  |
|        5 | boot  |
|        6 | boot  |
|        7 | boot  |
|        8 | boot  |
|        9 | boot  |
|       10 | boot  |
|       11 | boot  |
|       12 | boot  |
|       13 | boot  |
|       14 | boot  |
|       15 | boot  |
|       16 | boot  |
|       17 | boot  |
|       18 | boot  |
|       19 | boot  |
|       20 | boot  |
|       21 | boot  |
|       22 | boot  |
|       23 | boot  |
|       24 | boot  |
|       25 | boot  |
|       26 | boot  |
|       27 | boot  |
|       28 | boot  |
|       29 | boot  |
|       30 | boot  |
|       31 | boot  |
|       32 | boot  |
|       33 | boot  |
|       34 | boot  |
|       35 | boot  |
|       36 | boot  |
|       37 | boot  |
|       38 | boot  |
|       39 | boot  |
|       40 | boot  |
Huawei E1752 on Ubuntu 10.04
Jun 26th, 2010 by miki

Today I managed to get a Huawei E1752 3G modem (USB id 12d1:1446/140c, usually called E1552 by lsusb) running on Ubuntu 10.04 without all the hassle described elsewhere (see this, this or this or this …).

This particular modem came from the danish cable ISP YouSee, in an offering known as Mobilt Bredbånd (mobile broadband), targeting their existing cable internet customers. Pricing starts at lowest offering of 1 Mbit/384 kbit transmission speed with 1GiB/month data limit at DKK 99/month (~USD 16.5 ~EUR 13.3).

As many recent USB modems, this one is a mode switching type with multiple personalities (Option ZeroCD(TM)). At plugin it defaults to an emulated CD mass storage drive (USB ID 12d1:1446), with an onboard Windows driver and dialer (Mobile Partner). When detected by a driver knowing it’s schizophrenic nature, it can be manipulated, utilizing psychotherapeutic tricks, to switch it’s personality to the modem it actually is (USB ID 12d1:140c). Hence, on non-Windows systems some magic needs to be established to make the modem actually behave like a modem.

One incarnation (se discussion about other stuff here) of this magic is called usb_modeswitch. That is also the solution chosen by the Ubuntu distribution team, and it is present in the repositories and configured for the Huawei E1752 in Ubuntu 10.04 ‘Lucid Lynx’, so we just need to know that we need it. You do now…

Activating usb_modeswitch is a matter of installing the usb-modeswitch package. Find it in Synaptic or issue the following in a terminal:

sudo apt-get install usb-modeswitch

Now all you have to do is insert the modem and check (we like to be certain, right?) with lsusb that you have the 12d1:140c modem device instead of the 12d1:1446 mass storage device.

The Gnome Network Manager should now pick up on the new modem device, and offer you the possibility of adding a new mobile broadband connection. In my case, it defaulted to an Oister connection, but removing that and using the wizard to create a TDC connection (YouSee is a part of/close associate of TDC) did the trick, after reinserting the modem once more.

Now I wonder why my own E160G modem works without usb_modeswitch installed…

»  Substance:WordPress   »  Style:Ahren Ahimsa
© 2016 Mikini Services