Chris’ Miscellanea

Full Disk Encryption with Cyanogenmod CM12.1 on a Samsung Galaxy S4 Mini

noreply@blogger.com (Christian Vogel) — Sat, 08 Aug 2015 15:15:00 +0000

Update August 9th: Just skip to the last line of this post where we realize that we could have spared us all of the hassles and resize2fs from within the running android system ☺.

If you try to enable full disk encryption on Cyanogenmod CM12.1 using the normal settings menu (Security -> Encrypt Phone) it doesn't work, the phone will just soft-reboot and nothing will have happened.

If you "logcat" the debugging log of your phone (using adb logcat) within the huge amount of data, some hint about what might have gone wrong can be found:

➜ ~ grep Cryptfs logcat_encryption.txt
I/Cryptfs ( 199): Check if PFE is activated on Boot
E/Cryptfs ( 199): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs ( 199): Error getting crypt footer and key
E/Cryptfs ( 199): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs ( 199): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
E/Cryptfs ( 199): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs ( 199): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.

On android, the footer that tells the operating system that an partition is encrypted resides on the end of the filesystem and it needs a little space between the logical end of the filesystem in a partition, and the physical end of the partition to be squeezed in when converting a phone from unencrypted to encrypted.

http://forum.xda-developers.com/nexus-4/help/looking-encryption-footer-t2676700

Running the recovery system (boot while keeping Volume-Up and Home pressed), we can have a look at the partition sizes and filesystem details. We learn that on my S4 mini, the userdata partition (mmcblk0p24) has a size of 5685231 1k blocks, and the /data filesystem claims a size of 1421307 4k blocks.

$ adb shell
~ # cat /proc/partitions
major minor #blocks name
(...)
179 24 5685231 mmcblk0p24
~ # tune2fs -l /dev/block/mmcblk0p24
(...)
Block count: 1421307
(...)
Block size: 4096

As 5685231-1421307*4 = 3, that's only 3 meager 1k blocks at the end of the filesystem, whereas the encryption footer needs a space of at least 16k, the allmighty internet tells me. So, let's build a filesystem that leaves 128kByte of free space on the end as I don't know if Android 5 has enlarged the footer from what the websites I had found claims, or if there's some alignment requirement for it. So I'll be generous. (5685231-128)/4=1421275.75 so I'll create a ext4 filesystem occupying 1421275 4k blocks:

~ # mke2fs -b4096 -T ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata 142127

(note: I made a mistake, ch0pped off the 5!)
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
35600 inodes, 142127 blocks
7106 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=146800640
5 block groups
32768 blocks per group, 32768 fragments per group
7120 inodes per group
Superblock backups stored on blocks:
32768, 98304

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Do I really have to mention at this point that this will erase all your files? Alternatively one could try "resizefs" to resize the filesystem, but that program isn't included in my recovery. Anyhow, it seems to be prudent to try encryption on an otherwise virgin install, as one risks data loss anyhow when performing the encryption process and there are reports of phones not booting up correctly after encyption had been enabled.

Then reboot the phone, do a half-hearted initial setup of the device, configure a simple PIN for testing, and encrypt your phone. (I also enabled debugging so that I can run logcat again to catch errors).

$ grep Cryptfs logcat_encryption_newfs.txt
(...)
I/Cryptfs ( 196): Check if PFE is activated on Boot
E/Cryptfs ( 196): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs ( 196): Error getting crypt footer and key
E/Cryptfs ( 196): not running with encryption, aborting
E/Cryptfs ( 196): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
D/Cryptfs ( 196): Just asked init to shut down class main
D/Cryptfs ( 196): unmounting /mnt/shell/emulated succeeded
D/Cryptfs ( 196): unmounting /data succeeded
I/Cryptfs ( 196): keymaster version is 2
I/Cryptfs ( 196): Using scrypt for cryptfs KDF
D/Cryptfs ( 196): Just triggered post_fs_data
D/Cryptfs ( 196): post_fs_data done
D/Cryptfs ( 196): Just triggered restart_min_framework
I/Cryptfs ( 196): Using scrypt for cryptfs KDF
I/Cryptfs ( 196): Enabling support for allow_discards in dmcrypt.
I/Cryptfs ( 196): load_crypto_mapping_table: target_type = crypt
I/Cryptfs ( 196): load_crypto_mapping_table: real_blk_name = /dev/block/platform/msm_sdcc.1/by-name/userdata, extra_params = 1 allow_discards
I/Cryptfs ( 196): Encrypting ext4 filesystem in place...
I/Cryptfs ( 196): Encrypting group 0
I/Cryptfs ( 196): Encrypting from sector 0
I/Cryptfs ( 196): Encrypting group 1
I/Cryptfs ( 196): Encrypted to sector 1356288
I/Cryptfs ( 196): Encrypting from sector 16777216
I/Cryptfs ( 196): Encrypted to sector 16867328
I/Cryptfs ( 196): Encrypting from sector 16874496
I/Cryptfs ( 196): Encrypted to sector 17014784

The phone will now reboot and ask for the PIN you entered. Unfortunately this takes *ages*! But if everything is fine, you can now setup your phone to your heart's content and set up a real password to have a securely encrypted phone. We'll have to see how stable this encrypted phone will be in daily use.

From Chris’ Miscellanea

Update: I made a mistake and chopped off the "5" at the end, so my filesystem only occupies 1/10 of the available space and has a completely unusable size of 500 MB :-(. So, to not have to start all over again, I'll try to resize the file system in place.

➜ e2fs adb shell

shell@serranoltexx:/ $ su

root@serranoltexx:/ # df

Filesystem Size Used Free Blksize

(...)

/data 553.0M 490.2M 62.8M 4096

Check the sizes of the underlaying block device, and the dmcrypt mapper:

root@serranoltexx:/ # cat /proc/partitions

major minor #blocks name

(...)

179 24 5685231 mmcblk0p24

(...)

254 0 5685215 dm-0

Indeed, the crypted partition is exactly 16kB smaller (the crypt footer) than the raw block device. So we can hopefully let resize2fs autodiscover the target size. Unfortunately, we cannot access the block device hosting /data, and we can't umount /data because the android framework is still running. So we use the same method as the volume daemon to shutdown most of android. (your device will not no longer react to user input on the buttons or touch secreen):

root@serranoltexx:/ # setprop vold.decrypt trigger_shutdown_framework

root@serranoltexx:/ # umount /data

root@serranoltexx:/ # e2fsck -f /dev/block/dm-0

e2fsck 1.42.9 (28-Dec-2013)

Pass 1: Checking inodes, blocks, and sizes

(...)

(fix problems as they appear here)

root@serranoltexx:/ # resize2fs /dev/block/dm-0

resize2fs 1.42.9 (28-Dec-2013)

Resizing the filesystem on /dev/block/dm-0 to 1421303 (4k) blocks.

The filesystem on /dev/block/dm-0 is now 1421303 blocks long.

I rebooted the phone the hard way via sync; echo b >/proc/sysrq-trigger.

Now /data is at the expected size of 5.5 GB.

➜ ~ adb shell df
Filesystem Size Used Free Blksize
(...)
/data 5.4G 734.3M 4.7G 4096

Of course, now that we have found out how to resize an ext4 filesystem in place from within android, we realize that we could have made it that way from the beginning 😉. Without data loss. Just run the last 4 commands but using the physical emmc device and append the right number of blocks we need to resize2fs while the device is still unencrypted...

e2fsck /dev/block/mmcblk0p24

resize2fs /dev/block/mmcblk0p24 14221303

That should do the trick. Reboot and run the normal encryption process.

Public Service Announcement: Putty

noreply@blogger.com (Christian Vogel) — Tue, 07 Jul 2015 06:31:00 +0000

A recent upgrade of sshd apparently broke my saved putty connections, which have a deprecated key-exchange protocol on the top of the "Algorithm selection policy."

It manifests itself as a long pause, showing a black putty terminal window, followed by the message: PuTTY Fatal Error: Server unexpectedly closed network connection.

The putty event window will show it being stuck in the "Doing Diffie-Hellman group exchange" phase.

From Chris’ Miscellanea

If you run your sshd in debug mode, you'll see that sshd isn't happy with the selection of the key exchange protocol.

➜ ~ sudo /usr/sbin/sshd -p 2222 -d
debug1: sshd version OpenSSH_6.9, OpenSSL 1.0.2c 12 Jun 2015

(...)

debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth]

debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth]

Hm, kex protocol error: type 30 seq 1 [preauth]

Connection closed by 10.120.102.56 [preauth]

(...)

From Chris’ Miscellanea

It seems that OpenSSH recently had removed an ancient method of key exchange, as is to be read on this thread on the misc@OpenBSD mailing list.

If you open putty 's session configuration and move the "Diffie-Hellmann group exchange" right to the bottom of the "Algorithm selection policy" (Configuration / Connection / SSH / Kex), everything works again.

From Chris’ Miscellanea

SDM220 Power Meter, MODBUS, Python, RS485

noreply@blogger.com (Christian Vogel) — Sun, 29 Mar 2015 17:00:00 +0000

The Eastron SDM220 is a very inexpensive one-phase power/energy meter, which can be readout via RS485. I got myself one to play with, and there are a few observations I wanted to write down.

From Chris’ Miscellanea

It's actually a pretty nifty meter, measuring power and energy in both directions, voltage and line frequency. Furthermore it outputs power-factor (cosϕ) and reactive or apparent power (which is basically the same thing, just represented differently).

One thing that cost me some time to resolve, especially as I used a selfmade RS485 adapter in the first place about the correctnes of which I was unsure are: The RS485 terminals are wired incorrectly, B and A are swapped, this has been verified with an industrial/commercial interface. Connectors 7, 8 and 9 are GND, A and B. In that order. If the link is idle, B will be positive with respect to A.

There's an existing modbus library for Python (pymodbus) which works perfect, so far. The serial modbus link is instantiated like this (if the modbus runs with parity = None).

cl = pymodbus.client.sync.ModbusSerialClient('rtu',
port='/dev/ttyUSB1', baudrate=9600,
parity='N',stopbits=2,
timeout=0.125)

The values stored in the device are actually IEEE754 floating point values, which can be converted to python floats very conveniently, they are fetched as two consecutive 16bit register, concatenated to a 32bit field, and then reinterpreted as the 32bit float:

resp = client.read_input_registers(basereg,2, unit=1)

return struct.unpack('>f',struct.pack('>HH',*resp.registers))

The documentation for the SDM220 is actually quite comprehensive, but it took me quite a while until I really figured out what they meant... So here are the register numbers I sucessfully used to get date off the device:

# Symbol Reg# Format
( 'V', 0x00, '%6.2f' ), # Voltage [V]
( 'Curr', 0x06, '%6.2f' ), # Current [A]
( 'P[act]', 0x0c, '%6.0f' ), # Active Power ("Wirkleistung") [W]
( 'P[app]', 0x12, '%6.0f' ), # Apparent Power ("Scheinl.") [W]
( 'P[rea]', 0x18, '%6.0f' ), # Reactive Power ("Blindl.") [W]
( 'PF', 0x1e, '%6.3f' ), # Power Factor [1]
( 'Phi', 0x24, '%6.1f' ), # cos(Phi)? [1]
( 'Freq', 0x46, '%6.2f' ) # Line Frequency [Hz]

esp8266 firmware upgrade, odd baudrate in bootloader?

noreply@blogger.com (Christian Vogel) — Tue, 02 Dec 2014 20:04:00 +0000

So, I also got one of those ESP8266 wifi/serial modules, which are pretty neat. Unfortunately mine seemed to come with an ancient firmware on it, and pretty unconveniently those didn't want to be re-flashed with newer software.

From Chris’ Miscellanea

The bootloader seems to initialize the modules' serial port to the pretty insane value of 76923 bps, so that in "programming" mode, the stupid windows-utility (or, for that matter, any program expecting standard-baudrates) will fail to communicate with the module.

From Chris’ Miscellanea

If you have a suitable serial cable (a FTDIchip FT2232 is what I used), you can calculate "custom dividers" for most uncommon baudrates, and use those instead of 38,4kBps (the "magic" baudrate indicating that the custom one should be used).

Base-frequency for the ft2232 is 60 Mhz, so we'll use a custom divisor of 780 (60Mhz/76923).

$ setserial /dev/ttyUSB0 spd_cust divisor 780
$ cu -l ttyUSB0 -s 38400
Connected.

ets Jan 8 2013,rst cause:1, boot mode:(7,7)

waiting for host

ets Jan 8 2013,rst cause:1, boot mode:(7,7)

waiting for host

ets Jan 8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 24444, room 16
tail 12
chksum 0xe0
ho 0 tail 12 room 4
load 0x3ffe8000, len 3168, room 12
tail 4
chksum 0x93
load 0x3ffe8c60, len 4956, room 4
tail 8
chksum 0xbd
csum 0xbd

Interestingly, that seems to be only the bootloader of the module, after this, the device switches to the more common 115200kbps and responds to AT-commands, given that GPIO15=GND, GPIO2=Vcc, GPIO0=Vcc and CH_PD=Vcc. (pullups to Vcc via ~5kΩ resistor)

So, to get the windows-only updater to run successfully, we...

connect GPIOs and CH_PD as listed above (AT-Mode)
power up module
module will start bootloader with 77kbps, then change into AT-command mode, at 115200 bps
connect GPIO0 to GND (firmware download mode)
pulse CH_PD to LOW to restart module
firmware will restart, but bootloader does NOT go back to 77kbps
run firmware-upgrade in windows

From Chris’ Miscellanea

Now I'm upgraded to version 170901 (whatever that means).

AT+GMR
00170901

Building pyqwt 5.2.0 by manually installing the pyqtconfig.py module.

noreply@blogger.com (Christian Vogel) — Tue, 26 Aug 2014 19:56:00 +0000

For playing with GNU radio I had to install quite a lot of dependencies to get all the modules to build, unfortunately there's currently a build issue with PyQwt, which are the Python bindings for Qwt, the Qt Widgets for Technical Applications.

Installation of PyQwt-5.2.0 fails with an error message of...

Requires at least PyQt-4.2 and its development tools.
==> ERROR: A failure occurred in build().
Aborting...

...and this is because of the configuration script of PyQwt that tries to import PyQT's pqtconfig.py, that no longer is installed by PyQt 4.11.1!

There are a few bugreports to be found on the web, e.g.

To fix this, get yourself the pyqt-x11 source, then run the configure script as appropriate for your particular Linux installation...

[optiplex …/chris/AUR/python2-pyqt4/src/Py2Qt-x11-gpl-4.11.1]
$ python2 configure.py -v /usr/share/sip --qsci-api -q /usr/bin/qmake-qt4 Determining the layout of your Qt installation...
This is the GPL version of PyQt 4.11.1 (licensed under the GNU General Public
License) for Python 2.7.8 on linux2.
Type '2' to view the GPL v2 license.
Type '3' to view the GPL v3 license.
Type 'yes' to accept the terms of the license.
Type 'no' to decline the terms of the license.
Do you accept the terms of the license? yes
Found the license file pyqt-gpl.sip.
Checking to see if the QtGui module should be built...
Checking to see if the QtHelp module should be built...
Checking to see if the QtMultimedia module should be built...
Checking to see if the QtNetwork module should be built...

(...)

Creating pyrcc4 Makefile...
Creating Qt Designer plugin Makefile...
Creating pyqtconfig.py...

At this point, the proper pyqtconfig.py script has been created, install to the python site-package directory.

[optiplex …/chris/AUR/python2-pyqt4/src/Py2Qt-x11-gpl-4.11.1]
$ sudo install -m644 pyqtconfig.py /usr/lib/python2.7/site-packages/PyQt4/pyqtconfig.py

Now, the pyqwt bindings can be built, e.g. by using ArchLinux's makepkg utility, using the AUR package.

[optiplex /home/chris/AUR/pyqwt]
$ makepkg
==> Making package: pyqwt 5.2.0-10 (Tue Aug 26 21:37:07 CEST 2014)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...

(...)

==> Starting build()...
patching file qt4lib/PyQt4/Qwt5/qplt.py
patching file configure/configure.py
patching file configure/configure.py
Command line options:
{'debug': False,
'disable_numarray': False,

(...)

cp -f ../../qt4lib/PyQt4/uic/widget-plugins/qwt.py /home/chris/AUR/pyqwt/pkg/pyqwt/usr/lib/python2.7/site-packages/PyQt4/uic/widget-plugins/qwt.py
make[1]: Leaving directory '/home/chris/AUR/pyqwt/src/PyQwt-5.2.0/configure/qwt5qt4'
==> Tidying install...
-> Purging unwanted files...
-> Removing libtool files...
-> Removing static library files...
-> Compressing man and info pages...
-> Stripping unneeded symbols from binaries and libraries...
==> Creating package "pyqwt"...
-> Generating .PKGINFO file...
-> Generating .MTREE file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: pyqwt 5.2.0-10 (Tue Aug 26 21:40:25 CEST 2014)

Controlling USB device access on Linux (e.g. BADusb defense)

noreply@blogger.com (Christian Vogel) — Tue, 12 Aug 2014 13:26:00 +0000

So, there was a lot of fuzz about a recent talk by Karsten Nohl et al. at BlackHat about the the unsecurity of current USB implementations (on the computer side) which happily load drivers for all kinds of devices as soon as a (potentially malicious) USB stick is connected.

I completely agree that, as shipped, most computer systems will be susceptible to this attack, and assume that all of their attacks will work as advertised. What I don't agree with at all is their conclusion, which boils down that no effective defenses exist.

While I haven't made my homework to develop a defense, I want to at least show the mechanism in current Linux kernels to limit binding of potentially dangerous drivers to specific devices, so that e.g. a inserted USB-stick would only be mounted as a block device, and its malicious keyboard interface be ignored.

Binding of Drivers

A linux-module can claim ownership of certain usb vendor/device ids or device classes. Those are visible when looking at the modinfo of a kernel module, to facilitate autoloading of modules, but are also registered in internal kernel structures, so that drivers compiled in statically directly can be mated with the proper devices:

$ modinfo snd-usb-audio
filename: /lib/modules/3.15.8-1-ARCH/kernel/sound/usb/snd-usb-audio.ko.gz
license: GPL
description: USB Audio
author: Takashi Iwai
alias: usb:v*p*d*dc*dsc*dp*ic01isc01ip*in*
alias: usb:v0D8Cp0103d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v*p*d*dc*dsc*dp*ic01isc03ip*in*
alias: usb:v200Cp100Bd*dc*dsc*dp*ic*isc*ip*in*
(...)

This information currently comes from the MODULE_DEVICE_TABLE of sound/usb/card.c, stored in an array called usb_audio_ids. The bold one is the "default class", the others all are included in the "quirks table", which includes all exceptions from the default class.

static struct usb_device_id usb_audio_ids [] = {
#include "quirks-table.h"
{ .match_flags = (USB_DEVICE_ID_MATCH_INT_CLASS | USB_DEVICE_ID_MATCH_INT_SUBCLASS),
.bInterfaceClass = USB_CLASS_AUDIO,
.bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, usb_audio_ids);

On connection of a USB device, the kernel will look through all its currently registered modules that claim to support USB devices (by registering those tables with the kernel) and bind devices to drivers (and if it doesn't succeed, it will call udev/hotplug to load a module that does).

The Vulnerability

So, if you connect a particular USB headset, the electronics of which I have laying around... you get a new sound device in ALSA...

[root@optiplex devices]# aplay -l

**** List of PLAYBACK Hardware Devices ****
(...)
card 1: Headset [Logitech USB Headset], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0

But also a new keyboard! (the mute/volume buttons on the headset, but those could be arbitrary buttons entering text, too).

[root@optiplex devices]# xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB-PS/2 Optical Mouse id=8 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Das Keyboard id=9 [slave keyboard (3)]
↳ Logitech Logitech USB Headset id=10 [slave keyboard (3)]

If you look in the sysfs filesystem, you can see, that the USB headset (usb device 5-1) has 4 distinct functions (.0 -- .3) on configuration :1.

[root@optiplex /sys/bus/usb/devices/5-1]# ls
5-1:1.0 bcdDevice maxchild
5-1:1.1 bmAttributes port
5-1:1.2 busnum power
5-1:1.3 configuration product
authorized descriptors quirks
avoid_reset_quirk dev removable
bConfigurationValue devnum remove
bDeviceClass devpath speed
bDeviceProtocol driver subsystem
bDeviceSubClass ep_00 uevent
bMaxPacketSize0 idProduct urbnum
bMaxPower idVendor version
bNumConfigurations ltm_capable
bNumInterfaces manufacturer

And those are described by the (very lengthy) lsusb -v output, which I'll not reproduce completely here, just try it for yourself on any USB device.

Bus 005 Device 006: ID 046d:0a0b Logitech, Inc. ClearChat Pro USB

Device Descriptor:

(...)

bNumConfigurations 1

Configuration Descriptor: (configuration #1 starts here)

bLength 9

(...)

Interface Descriptor: (interface 1:0)

(...)

bDescriptorType 4

bInterfaceNumber 0

(...)

bInterfaceClass 1 Audio

bInterfaceSubClass 1 Control Device

(...)

AudioControl Interface Descriptor: (detailed info about audio capabilities)

bLength 10

(...)

Interface Descriptor: (interface 1:3)

bInterfaceNumber 3

(...)

bInterfaceClass 3 Human Interface Device

bInterfaceSubClass 0 No Subclass

bInterfaceProtocol 0 None

iInterface 0

So, here you have it, one device that (legitimately) is both a soundcard and a keyboard/mouse (e.g. an human interface device). Given enough motiuvation, code could be written for the controller inside the soundcard that enters arbitary text to my computer. And that's basically the vulnerability presented in the Black Hat Presentation by Nohl et al.

Defense

But, you can easily turn off this automatic binding, at least on Linux, with one single command:

[root@optiplex ~]# echo 0 >/sys/bus/usb/drivers_autoprobe

Now, whenever you connect a USB device to your computer, it will not automatically connect the usb-soundcard to the ALSA subsystem and the volume buttons to the hidraw/keyboard driver. If I now connect the aforementioned soundcard, I'll not get a new keyboard in xinput, nor a soundcard in ALSA (and also not a network- or block-device for a network card or USB disk).

The only thing I'll get in my dmesg is the message, that an USB device has been connected:

[13399.092113] usb 5-1: USB disconnect, device number 6
[13405.245389] usb 5-1: new full-speed USB device number 7 using uhci_hcd

And to manually bind this device, you first have to choose the appropriate USB configuration...

# echo 1 >/sys/bus/usb/devices/5-1/bConfigurationValue

...and tell the usb audio driver to bind to that device.

# echo 5-1:1.0 >/sys/bus/usb/drivers/snd-usb-audio/bind

Now you have the USB audio interface, but not the keyboard, yet... If you wanted, you'd just bind usb-hid to interface 3.

# echo 5-1:1.3 >/sys/bus/usb/drivers/usbhid/bind

To verify that your keyboard presses aren't registed from the connected device before, and are registered after binding, you can run "xev" and press the volume buttons (note: those, in principle, could enter arbitrary text to your computer, depending on the programming of the controller in the device).

KeyRelease event, serial 38, synthetic NO, window 0x3800001,
root 0x1dc, subw 0x3800002, time 13880057, (41,58), root:(2384,618),
state 0x10, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

The most often quoted use-case if obviously connection of a usb-storage device, e.g. an external harddrive or flash-stick.

[14567.888596] usb 6-1: new high-speed USB device number 4 using ehci-pci

# echo 1 >/sys/bus/usb/devices/6-1/bConfigurationValue
# echo 6-1:1.0 >/sys/bus/usb/drivers/usb-storage/bind

[14667.692717] usb-storage 6-1:1.0: USB Mass Storage device detected
[14667.692936] scsi7 : usb-storage 6-1:1.0
[14668.696482] scsi 7:0:0:0: Direct-Access TOSHIBA MK4309MAT G5.0 PQ: 0 ANSI: 0 CCS
[14668.698461] sd 7:0:0:0: [sdd] 8452080 512-byte logical blocks: (4.32 GB/4.02 GiB)

(yes, it's a very, very crappy and old USB harddisk)

Proper user-interface, current lack thereof.

To convert all this sysfs poking into a proper user-friendly software, one will have to...

On computer startup, disable autoprobe (probably there's a kernel command line for that).
Statically configure the minimal interfaces used (e.g. the main usb keyboard, trackpad/mouse, ...).
During normal operation, watch hotplug-events or poll the sysfs filesystem for newly inserted usb devices.
Verify presented configurations of USB devices and their interfaces with a policy (e.g. enable only usb-storage devices, e.g. "thumbdrivers"
Ask the user, if he's happy with this device.
On successful verification, only bind the single necessary driver (e.g. usb-storage) to the proper interface of the device.

Of course, for certain devices more sophisticated verification schemes could be envisioned, checking certificates, downloading firmware for verification (which, again, might be forged, ...).

The "Authorized" Mechanism

There's a second mechanism to disable/enable communication with USB device using the "authorized" property of USB controllers. It's described in the kernel documentation.

Windows...

There seems to be a group policy for that... Local Computer Policy, Computer Configuration,Administrative Templates, System, Device Installation, and Device Installation Restrictions

Stairville DJ-X 16, voided my warranty

noreply@blogger.com (Christian Vogel) — Mon, 24 Mar 2014 10:39:00 +0000

The DJ-X 16 is a very basic DMX controller, which I used to test out DMX controlled (d'uh...) LED lights. I cannot recommend it, it lacks a lot of features, and the buttons/faders have a very flimsy feeling. Nevertheless: Because I was pondering if it was worthwhile to modify its firmware, I decided to void the warranty (yeah!) and here are few pictures documenting the insides of this device.

What I found pretty interesting is the fact that, even though I bought it new only a few months ago, and it's still being manufactured exactly like that, it uses pretty antique components, and is an all-through-hole PCB, not a single SMD to be found.

The main controller is a Atmel AT89C55WD, a 8051 compatible 8-bit microcontroller. It's meagre 256 bytes of internal RAM is extended by 8k of High-Speed (120ns...) SRAM. A 29EE010 EEPROM takes care of the 8051's lack of long-term memory. Everything else is 80s-style design, with a lot of 47hc's.

There's a second, smaller, PCB which is home of the SN57176 RS485 driver/receiver, an optocoupler (MIDI out/through), connectors and a 7805 voltage regulator. The flat-ribbon cable connecting this connection-PCB to the main board is nicely labeled on the silkscreen, very convenient.

K1 1 2 COM
K2 3 4 Audio2
K3 5 6 Audio1
k5 7 8 MIDI in
+5V 9 10 +5V
NC 11 12 MIDI through
GND 13 14 GND
+5V 15 16 +5V
NC 17 18 DMX out
+12V 19 20 +12V

From Chris’ Miscellanea

Playing with a AM2302 Temperature/Humidity Sensor & LUFA

noreply@blogger.com (Christian Vogel) — Sun, 09 Mar 2014 19:34:00 +0000

I played around with a Adsong AM2302 Temperature/Humidity sensor today which has a pretty neat serial interface.

From Chris’ Miscellanea

I wrote some code to read in the data using the input-capture mode of the Timer/Counter1 in a AVR ATmega32u4 (way overpowered, but it's handy on a Olimexino 32U4 board) to learn about using the LUFA USB library a little, maybe someone can put it to actual use?

$ cu -l ttyACM0
Connected.
Triggering conversion.
AS2302 raw bytes: recv cnt=0 01 76 00 fa 71
status: 0, temp=250 (*0.1 dC), rh=374 (*0.1%)

Get /dev/spidev on an Raspberrypi running under Archlinux ARM working again.

noreply@blogger.com (Christian Vogel) — Thu, 06 Mar 2014 16:54:00 +0000

Currently, when running a raspberry-pi with the latest kernel available for Archlinux, access to the SPI bus via /dev/spidev no longer works. Bugs have been filed, but apparently the late-binding logic available via spi_register_board_info just seems to be broken right now.

I've written a small kernel module that doesn't fix the initial bug, but just does the binding of spidev to the first two chipselects of the first spi master. It's available on github.

$ ls -la /dev/spidev*
zsh: no matches found: /dev/spidev*

$ sudo insmod rpi_add_spidev_module/rpi_add_spidev_module.ko

$ dmesg

(...)
[ 245.299487] spi_master spi0: ...is the master for device #0.
[ 245.299709] spi spi0.0: ...is the device #0.
[ 245.299734] spi_master spi0: ...is the master for device #1.
[ 245.304763] spi spi0.1: ...is the device #1.

$ ls -la /dev/spidev0.*

crw------- 1 root root 153, 0 Mar 6 16:47 /dev/spidev0.0

crw------- 1 root root 153, 1 Mar 6 16:47 /dev/spidev0.1

# cd /sys/bus/spi/drivers/spidev
# ls -l
total 0
--w------- 1 root root 4096 Jan 1 00:03 bind
lrwxrwxrwx 1 root root 0 Jan 1 00:02 module -> ../../../../module/spidev
lrwxrwxrwx 1 root root 0 Jan 1 00:03 spi0.0 -> ../../../../devices/platform/bcm2708_spi.0/spi_master/spi0/spi0.0
lrwxrwxrwx 1 root root 0 Jan 1 00:02 spi0.1 -> ../../../../devices/platform/bcm2708_spi.0/spi_master/spi0/spi0.1
--w------- 1 root root 4096 Jan 1 00:00 uevent
--w------- 1 root root 4096 Jan 1 00:02 unbind

Using software to talk to a proprietary SPI gyro/accelerometer module works again.

$ sudo ./rpi_gyro /dev/null

Opened gpio25 direction as fd 5.

Opened gpio25 value as fd 6.

Opened /dev/spidev0.0 as fd 7 (0x03, 8, 0).

Opened /dev/spidev0.1 as fd 8 (0x03, 8, 0).

lsm330dlc_dump_regs: dumping accelerometer registers.

$00: $00 $00 $00 $00 $00 $00 $00 $ff

$08: $00 $00 $00 $00 $00 $00 $00 $33

$10: $86 $16 $a6 $26 $48 $25 $21 $1e

$18: $1b $a3 $50 $65 $c0 $00 $50 $00

$20: $27 $00 $00 $80 $40 $00 $00 $ff

$28: $00 $2d $c0 $01 $40 $27 $80 $9e

$30: $00 $00 $00 $00 $00 $00 $00 $00

$38: $00 $00 $00 $00 $00 $00 $00 $00

lsm330dlc_dump_regs: dumping gyro registers.

$00: $d3 $66 $a8 $cc $4d $d0 $11 $f1

$08: $20 $06 $ff $18 $02 $83 $00 $d3

$10: $90 $2b $19 $44 $0c $e0 $61 $60

(...)

Riso Kagaku Corp Webmail Notifier Redux: Kernel Module Cleanup

noreply@blogger.com (Christian Vogel) — Sun, 09 Feb 2014 12:39:00 +0000

Trying to clean up this code, so that it's usable without too much friction...

I put up my slightly modified version of the usbled.c kernel module on github. It includes support for one of the cheapest incarnation of USB-led devices, the Riso Kagaku Corp. Webmail Notifier. It can now be built out-of-tree easily (trying to forward to the kernel guys to merge it eventually) and includes udev rules and a script to automate the re-binding of device from usbhid to the usbled driver).

Earlier posts:

Github: Extending Linux' usbled.c to support the "Webmail Notifier" by Riso Kagaku Corp.

Movie hosted by instagram:

DeLock 61114 uses a NEC Corporation uPD72873 (µPD72873) Chipset (Cardbus Firewire Interface)

noreply@blogger.com (Christian Vogel) — Fri, 25 Oct 2013 18:28:00 +0000

I got myself a Cardbus FireWire card, namely a DeLock 61114. As it's always very hard to find the Chipset used for a particular card, I'd want to post it here, so that it may be found by neighbors also interested in this information.

→ DeLock 61114 uses a NEC Corporation (Renesas) uPD72873 (µPD72873) with vid 0x1033 and pid 0x00e7 [1033:00e7].

If you want to use the card for Audio applications I can attest that it does not work at all with either an Echo AudioFire 4 and a Focusrite Saffire Pro 26 I/O with ffado/jackd under Linux, which is not surprising as the NEC chipset if often classified as "problematic". I bought it for a different purpose and did not know the chipset in advanced, let's hope it will turn out to be usable.

lspci -tv

-[0000:00]-+-00.0 Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller
(...)

+-1e.0-[02-06]--+-[0000:03]---00.0 NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller

lspci -v

$ sudo lspci -s 03:00.0 -v -v -nn
03:00.0 FireWire (IEEE 1394) [0c00]: NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller [1033:00e7] (rev 01) (prog-if 10 [OHCI])
Subsystem: NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller [1033:00e7]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64 (5000ns min, 11000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 8c000000 (32-bit, non-prefetchable) [size=4K]
Region 1: Memory at 8c001000 (32-bit, non-prefetchable) [size=256]
Region 2: Memory at 8c001100 (32-bit, non-prefetchable) [size=256]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Kernel driver in use: firewire_ohci
Kernel modules: firewire_ohci

dmesg on insert

[ 4893.716245] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0

[ 4893.716285] pci 0000:03:00.0: [1033:00e7] type 00 class 0x0c0010

[ 4893.716330] pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x00000fff]

[ 4893.716353] pci 0000:03:00.0: reg 0x14: [mem 0x00000000-0x000000ff]

[ 4893.716377] pci 0000:03:00.0: reg 0x18: [mem 0x00000000-0x000000ff]

[ 4893.716504] pci 0000:03:00.0: supports D1 D2

[ 4893.716511] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot

[ 4893.716732] pci 0000:03:00.0: BAR 0: assigned [mem 0x8c000000-0x8c000fff]

[ 4893.716747] pci 0000:03:00.0: BAR 1: assigned [mem 0x8c001000-0x8c0010ff]

[ 4893.716760] pci 0000:03:00.0: BAR 2: assigned [mem 0x8c001100-0x8c0011ff]

[ 4893.716868] firewire_ohci 0000:03:00.0: enabling device (0000 -> 0002)

[ 4893.717115] firewire_ohci 0000:03:00.0: setting latency timer to 64

[ 4893.776285] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card 2, 4 IR + 4 IT contexts, quirks 0x1

[ 4894.276463] firewire_core 0000:03:00.0: created device fw0: GUID 00004c020001af59, S400

Platform for Test

Dell Latitude D410, Intel(R) Pentium(R) M processor 1.60GHz, 2 GByte RAM, Kernel 3.11.6-1-ARCH, Archlinux x86 (32bit)

$ ffado-diag
FFADO diagnostic utility 2.1.0-Unversioned directory
============================
(C) 2008 Pieter Palmers
2009-2010 Arnold Krille

=== CHECK ===
Base system...
kernel version............ 3.11.6-1-ARCH
Preempt (low latency)... True
RT patched.............. False
old 1394 stack present.... False
old 1394 stack loaded..... False
old 1394 stack active..... False
new 1394 stack present.... False
new 1394 stack loaded..... True
new 1394 stack active..... True
/dev/raw1394 node present. False
/dev/fw* permissions:
crw------- 1 root root 248, 0 Oct 25 20:08 /dev/fw0
User IDs:
uid=1000(chris) gid=100(users) groups=100(users),4(adm),10(wheel),14(uucp),92(audio),190(systemd-journal)
Prerequisites (dynamic at run-time)...
gcc ............... gcc (GCC) 4.8.2
g++ ............... g++ (GCC) 4.8.2
PyQt4 (by pyuic4) . Python User Interface Compiler 4.10.3 for Qt version 4.8.5
jackd ............. jackd version 0.121.3 tmpdir /dev/shm protocol 24
path ............ /usr/bin/jackd
flags ........... -ljack -lpthread -lrt
libraw1394 ........ 2.1.0
flags ........... -lraw1394
libavc1394 ........ 0.5.4
flags ........... -lavc1394 -lrom1394 -lraw1394
libiec61883 ....... 1.2.0
flags ........... -liec61883 -lraw1394
libxml++-2.6 ...... 2.36.0
flags ........... -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lglib-2.0 -lsigc-2.0
dbus-1 ............ 1.6.16
flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -ldbus-1
Prerequisites (static at compile-time)...
gcc ............... gcc (GCC) 4.8.1 20130725 (prerelease)
g++ ............... g++ (GCC) 4.8.1 20130725 (prerelease)
PyQt4 (by pyuic4) . Python User Interface Compiler 4.10.3 for Qt version 4.8.5
jackd ............. sh: jackd: command not found
path ............
flags ........... Package jack was not found in the pkg-config search path.
libraw1394 ........ 2.1.0
flags ........... -lraw1394
libavc1394 ........ 0.5.4
flags ........... -lavc1394 -lrom1394 -lraw1394
libiec61883 ....... 1.2.0
flags ........... -liec61883 -lraw1394
libxml++-2.6 ...... 2.36.0
flags ........... -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lglib-2.0 -lsigc-2.0
dbus-1 ............ 1.6.14
flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -ldbus-1
uname -a...
Linux latitude-d410 3.11.6-1-ARCH #1 SMP PREEMPT Sat Oct 19 00:29:46 CEST 2013 i686 GNU/Linux
Hardware...
Host controllers:
03:00.0 FireWire (IEEE 1394) [0c00]: NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller [1033:00e7] (rev 01) (prog-if 10 [OHCI])
Subsystem: NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller [1033:00e7]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-
Latency: 64 (5000ns min, 11000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 8c000000 (32-bit, non-prefetchable) [size=4K]
Region 1: Memory at 8c001000 (32-bit, non-prefetchable) [size=256]
Region 2: Memory at 8c001100 (32-bit, non-prefetchable) [size=256]
Capabilities:
Kernel driver in use: firewire_ohci
Kernel modules: firewire_ohci

CPU info:
Architecture: i686
CPU op-mode(s): 32-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 13
Model name: Intel(R) Pentium(R) M processor 1.60GHz
Stepping: 8
CPU MHz: 1600.000
BogoMIPS: 3193.49
Configuration...
IRQ information
Hardware Interrupts:
--------------------
IRQ 0: PID: None, count: [906109], Sched None (priority None), drivers: ['timer']
IRQ 1: PID: None, count: [10837], Sched None (priority None), drivers: ['i8042']
IRQ 8: PID: None, count: [1], Sched None (priority None), drivers: ['rtc0']
IRQ 9: PID: None, count: [1], Sched None (priority None), drivers: ['acpi']
IRQ 12: PID: None, count: [755], Sched None (priority None), drivers: ['i8042']
IRQ 14: PID: None, count: [112126], Sched None (priority None), drivers: ['ata_piix']
IRQ 15: PID: None, count: [0], Sched None (priority None), drivers: ['ata_piix']
IRQ 16: PID: None, count: [6925], Sched None (priority None), drivers: ['uhci_hcd:usb1', 'ehci_hcd:usb5', 'i915', 'snd_intel8x0']
IRQ 17: PID: None, count: [608140], Sched None (priority None), drivers: ['uhci_hcd:usb2', 'b43']
IRQ 18: PID: None, count: [0], Sched None (priority None), drivers: ['uhci_hcd:usb3']
IRQ 19: PID: None, count: [47980], Sched None (priority None), drivers: ['uhci_hcd:usb4', 'yenta', 'firewire_ohci']

Software Interrupts:
--------------------

=== REPORT ===
FireWire kernel drivers:

The new FireWire kernel stack is loaded.
If running a kernel earlier than 2.6.37 and problems are experienced, either
try with the old Firewire kernel stack or upgrade to a newer kernel
(preferrably 2.6.37 or later).

ffado output (on EchoFire 4)

05803339228: Warning (StreamProcessor.cpp)[1708] updateState: ignoring identity state update from/to ePS_Created
05803339616: Warning (StreamProcessor.cpp)[1708] updateState: ignoring identity state update from/to ePS_Created
05804389908: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 425.80881) more that 10% off nominal (rate= 512.00000, diff= 3406.470, update_period=8)
05804390013: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 422.66907) more that 10% off nominal (rate= 512.00000, diff= 3381.352, update_period=8)
05804397825: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 426.40921) more that 10% off nominal (rate= 512.00000, diff= 3411.274, update_period=8)
05804397982: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 422.66876) more that 10% off nominal (rate= 512.00000, diff= 3381.350, update_period=8)
05804405797: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 422.66907) more that 10% off nominal (rate= 512.00000, diff= 3381.352, update_period=8)
05804405903: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 424.58093) more that 10% off nominal (rate= 512.00000, diff= 3396.648, update_period=8)

(...)

05805685889: Warning (IsoHandlerManager.cpp)[ 292] Execute: Timeout while waiting for activity

05808703126: Fatal (IsoHandlerManager.cpp)[ 348] Execute: (0x95005f0, Transmit) Handler died: now: 1750DB1D, last: 134FD732, diff: 49202155 (max: 49152000)

05808703167: Warning (StreamProcessor.cpp)[ 173] handlerDied: Handler died for 0x952d360

jackd watchdog: timeout - killing jackd

no message buffer overruns

Notes: More Toradex-T20 Stuff...

noreply@blogger.com (Christian Vogel) — Sun, 20 Oct 2013 10:27:00 +0000

So, I've wasted (again) too much time on the Toradex T20 I've written about earlier. It was collecting dust all of the time, but it's actually quite a nice toy, albeit not receiving nearly as much attention from developers, here are some random notes for myself, blogged so that I don't loose them.

USB

Switch the micro USB-on-the-go-connector (usable as a “normal” port, e.g. for connecting a Wireless LAN card or a USB thumbdrive) to host-mode:

# echo 1 >/sys/bus/platform/drivers/tegra-otg/tegra-otg/enable_host

Devices connected to the micro-usb with a OTG cable will now appear as usual, on the new “usb3” port.

Flash/Boot

Linux-Images to be run by the stock u-boot should look like this:

# mkimage -l /mnt/linux.img
Image Name: Linux_3_1_10+
Created: Sun Oct 20 03:14:16 2013
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6198328 Bytes = 6053.05 kB = 5.91 MB
Load Address: 00008000 ← !
Entry Point: 00008000 ← !

These are “legacy” images. The newer .its-based images work, too, but only with newer kernels (I tried 3.10 and 3.11) and those are broken in different ways, see below.

Copy the linux-images to the “default location” in internal NAND flash where 0x00800000 is the mtd device size (must be a multiple of the “erase block size” and 6198392 is your image file size). “/dev/mtd6” is the “LNX” partition when using the stock mtdparts command line option.

# mtd_debug erase /dev/mtd6 0 0x00800000
Erased 8388608 bytes from address 0x00000000 in flash
# mtd_debug write /dev/mtd6 0 6198392 /mnt/linux.img
Copied 6198392 bytes from /mnt/linux.img to address 0x00000000 in flash

“mtd_debug” is part of the “mtd-utils” package.

To find the correct flash block, have a look at /proc/mtd:

# cat /proc/mtd
dev: size erasesize name
mtd0: 3de80000 00080000 "USR"
mtd1: 00300000 00080000 "BCT"
mtd2: 00080000 00080000 "PT"
mtd3: 00200000 00080000 "EBT"
mtd4: 00080000 00080000 "BMP"
mtd5: 00200000 00080000 "ENV"
mtd6: 00800000 00080000 "LNX" ← !
mtd7: 00080000 00080000 "ARG"

The partitions are shown in proper (NAND-flash) order in u-boot's mtdparts command (even though this also only parses the mtdparts variable):

Tegra2 # mtdparts (note: u-boot prompt, not Linux!)
device nand0 , # parts = 8
#: name size offset mask_flags
0: BCT 0x00300000 0x00000000 0
1: PT 0x00080000 0x00500000 0
2: EBT 0x00200000 0x00780000 0
3: BMP 0x00080000 0x00b80000 0
4: ENV 0x00200000 0x00e00000 0
5: LNX 0x00800000 0x01200000 0
6: ARG 0x00080000 0x01c80000 0
7: USR 0x3de80000 0x01f80000 0

ENV is the u-boot environment, LNX is the default location for the linux kernel, USR the root-filesystem if running from internal flash. For the other partitions, I'm not sure. There's a “lnx_nand.cfg” in Toradex' T20_LinuxImageV2.0 which might shed a light on the exact purpose of all the unexplained partitions, unfortunately this seems to be handled by NVidias binary-only nvflash utility.

Booting with your root-fs on a sd-card (use no cards slower than class 10):

(u-boot environment variables)
myargs=root=/dev/mmcblk0p1 rootfstype=ext4 rootflags=data=writeback,commit=15 rootdelay=5,noatime,nodiratime
myboot=run setup; setenv bootargs ${defargs} ${myargs} ${mtdparts} ${setupargs} ; run myload ; bootm
myload=nboot ${loadaddr} 0 ${lnxoffset}

In principle, the kernel could also be started of a mmc drive:

Tegra2 # fatload mmc 0:1 $loadaddr linux.img

reading linux.img

mmc_send_cmd: MMC Timeout

Interrupt status 0x00000001

Interrupt status enable 0xfbff003b

Interrupt signal enable 0xfbff0002

Present status 0x01e70206

6198392 bytes read

But I always get this MMC Timeout error, and the loaded data is corrupt.

If you want to test a new kernel, booting over TFTP/Network (wired ethernet) or from a USB-disk works as expected (example below uses the same sd-card not working above, in a cheap and crappy usb card-reader):.

Tegra2 # fatload usb 0:1 $loadaddr linux.img
reading linux.img

6198392 bytes read

Tegra2 # bootm

## Booting kernel from Legacy Image at 00408000 ...

Image Name: Linux_3_1_10+

Created: 2013-10-20 9:14:16 UTC

Image Type: ARM Linux Kernel Image (uncompressed)

Data Size: 6198328 Bytes = 5.9 MiB

Load Address: 00008000

Entry Point: 00008000

Verifying Checksum ... OK

Loading Kernel Image ... OK

Starting kernel ...

Kernel and Distribution

I didn't have much luck with a more-recent stock-kernel, the most serious problem in those kernel being a misconfiguration of the voltage regulators. My board became very hot and was pretty unstable. So I'm sticking with the antiquated vendor supplied kernel (3.1.10) right now with a config based on the Toradex shipped one.

I'm running ArchLinux based on the root-filesystem for the compact TrimSlice computer which also runs on a NVidia Tegra.

DCF77 via GPIO on the Raspberry Pi (patched radioclkd2)

noreply@blogger.com (Christian Vogel) — Sun, 22 Sep 2013 10:38:00 +0000

Update 2015-02-15, see below.

After replacing my old linux-PC based router with a Telco-supplied plastic-box, I no longer have a usable NTP server at home. As a first measure, I’ve put a small DCF77 module on a raspberry-pi. It seems that most people add a serial to usb converter for that, but the raspberry has perfectly fine GPIOs that are capable of generating an interrupt for low CPU load -- and that’s all one needs. You can find my very lightly patched radioclkd2 for parsing the pulses on github.
I’ve added an additional filtering capacitor to the back of the module (be careful, inrush current will crash your Pi when connecting the leads!) a long time ago when it was still connected to the old PC, and there’s a pullup from the pulse output (which typically is open-drain/open-collector) to Vcc (3.3V). In my case, on a Rev. A Raspberry, I use GPIO0 (probably a bad choice, because it’s also one of the two accessible i2c pins, but easily changed).
Unfortunately it turned out that at its current location, reception is pretty bad, but easily solved by repositioning the Pi.

Update:I got a few emails regarding this project (which I hadn't had running for quite some time) recently, so I'll try to add this information on the old blog-post.

First, if you get a lot of pulses with bad, and very short, lengths (<10ms)

Reposition the DCF77 receiver with a long cable, away from all your computer stuff and switch-mode power supplies.
Wrap a huge ferrite core around this cable, to attenuate wire-conducted noise to the DCF77 receiver.
Add additional filtering caps at both sides of the cable (near the Rpi and DCF77 receiver module).

That way, I could get reliable reception again.

Second, if your ntpd doesn't seem to register any time from radioclkd2, even if it seems to receive properly: If you enable debug mode in radioclkd2, it will *not* update the shared memory. So after you've verified proper operation, put radioclkd2 in the background without -d.

Webmail Notifer, Linux Kernel Module

noreply@blogger.com (Christian Vogel) — Mon, 02 Sep 2013 20:59:00 +0000

This is an update on the Webmail Notifier, a cheap chinese gadget that's nothing more than a RGB LED connected via USB. In this case, it's an especially cheap version that can only display 7 distinct colours, plus black (off).

Finally I was sufficiently annoyed to put the code into a “proper” kernel module (original module on kernel.org). Here's my patch that adds this particular LED gadget.

Here's the thing cycling through random colours:

Repairing an Alesis IO26

noreply@blogger.com (Christian Vogel) — Wed, 03 Jul 2013 19:24:00 +0000

There's a really common way to kill your firewire-devices, which is to forcefully plug in the 6-pin connector, carrying both supply power and data signals, rotated by 180 degrees (which normally should be prevented by the asymmetrical shape of the connector). That way you'll send +12V, the most common supply voltage, into the chip that connects to the cable. This kills the chip pretty reliably.

This audio-interface (Alesis IO26) was damaged using this method:

From Chris’ Miscellanea

Thankfully the internal layout of the device is pretty clean. There's a stack of two PCBs (only the lower one shown) on the left side inside. The lower one has the DSP, Firewire controller and a ARM based controller. It connects with flat cables to the "analog" boards. On top, it carries a switching power supply generating the internal voltages (+3.3V, +5V, +/-15V and +48V from a single, galvanically isolated 9..30V input) which is missing in the photo.

From Chris’ Miscellanea

A good way to diagnose these kind of errors (according to some forums and FAQs) is to look at the idle-voltage on the firewire-bus lines (TPA0+...TPA0-...). They are supposed to be biased to a internally generated 1/2 Vcc (~1.8V) via 56 Ohm resistors from the twisted-pair lines to a bias pin (TBIAS0/1). It's described in the data sheet of the chip, here it's a TSB41AB2 from TexasInstruments In my case one bias-voltage-regulator spat out 3.3V, the other 0V (there's one for each of the two firewire ports). One of the ports had one receiver line stuck at 0V (chip-internal short to GND).

The only way to repair it is to desolder the chip, and replace it with a new one. Then the interface should be functioning again (I did not populate the mechanically damaged connector and associated terminating resistors, one port is enough for me).

From Chris’ Miscellanea

The two shorted pins #1 and #2 are both GND, so I did not bother to clean up the blob.

Audix APS 910 - Inline Phantom Adapter

noreply@blogger.com (Christian Vogel) — Sun, 09 Jun 2013 10:05:00 +0000

This adapter allows you to connect "normal" electret-type microphones to differential, phantom-powered inputs, like the ones to be found on sound mixing desks. I got one of those, but as the pinout was not mentioned anywhere, I made these photographs.

http://www.audixusa.com/docs_12/units/APS910.shtml

Mini-XLR pinout is supposed to be: 1: GND, 2: Signal, 3: Vbias. Even though the supply pin (3) is quite susceptible to noise coupling into the adapter output, Firther more, the signal pin (2) itself has a 1k or so pullup to Vbias. So to connect to a 2-pin electret microphone, just connect only pin 2. If you need more bias current, also connect pin 3, but then your signal will be slightly attenuated.

Phantom supply current is preetty high, at around 5mA each on "Hot" and "Cold" pins. (P48 on my mixing desk goes down to 13V when the adapter is connected)

From Chris’ Miscellanea

Reboot your Arch-linux running computer early, in case some vital component failed to initialize (a.k.a. e1000e_fsckup_initcpio)

noreply@blogger.com (Christian Vogel) — Fri, 31 May 2013 11:39:00 +0000

Ok, so this is embarrassingly primitive, but so that I don't loose it (again), I put this small script on github. Maybe someone else having a problem with things not initializing properly on every boot can find the concept useful: I have a computer based on a “DFI LanParty Mini-ITX P55-T36” motherboard with an integrated Intel Gigabit interface. Which works fine so far, but always fails to initialize networking on the first bootup after power-on. This is obviously inconvenient for unattended operation.

To fix this once and for all and reboot the computer early, feel free to use the code at https://github.com/vogelchr/e1000e_fsckup_initcpio.

From Chris’ Miscellanea

Antlers (May 2013 edition)

noreply@blogger.com (Christian Vogel) — Thu, 30 May 2013 13:55:00 +0000

I was on vacation again, so here's the obligatory antlers picture. I already posted another one elsewhere, but that was taken with the (a little bit) crappy phone camera and doesn't do the wallpaper and the antlers justice.

From Chris’ Miscellanea

Wireless on Raspberry π, Power Issues

noreply@blogger.com (Christian Vogel) — Sun, 19 May 2013 16:49:00 +0000

I'm playing with a Accellerometer/Gyroscope/Magnetometer board (ebay, link probably stale soon), and to have it somewhat mobile, I've connected it to the ole' trusty Raspberry π.

Unfortunately I have problems with a lot of WiFi adapters because of the many fuses inside of the π dropping voltages (starting with 4,5V from my Notebook/USB hub, it goes down to 3,8V on the USB connector). But adding a short wire bridging all those fuses helps ;-).

The dongle used is really old, it's a

Bus 001 Device 005: ID 07b8:b21d AboCom Systems Inc RT2573

and gets quite warm (correlates well with the high power consumption and hence voltage drop on the fuses), also looses contact with my (just nearby) access point frequently.

[ 2140.585617] ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:5e:42:ff after 500ms, disconnecting.

[ 2140.607093] cfg80211: All devices are disconnected, going to restore regulatory settings

[ 2140.607132] cfg80211: Restoring regulatory settings

[ 2140.607420] cfg80211: Calling CRDA to update world regulatory domain

[ 2141.948125] wlan0: authenticate with 68:7f:74:5e:42:ff

[ 2141.996396] wlan0: send auth to 68:7f:74:5e:42:ff (try 1/3)

[ 2141.998072] wlan0: authenticated

[ 2141.998877] rt73usb 1-1.2:1.0: wlan0: disabling HT due to WEP/TKIP use

[ 2141.998912] rt73usb 1-1.2:1.0: wlan0: disabling HT as WMM/QoS is not supported

[ 2142.035630] wlan0: associate with 68:7f:74:5e:42:ff (try 1/3)

[ 2142.037914] wlan0: RX AssocResp from 68:7f:74:5e:42:ff (capab=0x431 status=0 aid=20)

[ 2142.037943] wlan0: invalid AID value 0x14; bits 15:14 not set

[ 2142.057687] wlan0: associated

Happy Easter

noreply@blogger.com (Christian Vogel) — Sun, 31 Mar 2013 12:05:00 +0000

And remember: As long as the eggs aren't completely covered in snow, it's spring enough.

From 2013-03-31

Webmail Notifier - Linux Hidraw

noreply@blogger.com (Christian Vogel) — Fri, 29 Mar 2013 16:08:00 +0000

I got myself a plastic toy: A small box with a controlable LED that can be turned on- or off, with the intention of notifying the user of unread emails.

https://www.google.de/search?q=webmail+notifier&tbm=isch

My incarnation of this relatively simple concept identifies itself with a USB VID/PID of 0x1294:0x1320:



# lsusb -s 1:14

Bus 001 Device 014: ID 1294:1320 RISO KAGAKU CORP.

And it shows itself in the kernel log as follows:



[10772.855386] usb 1-1.6: new low-speed USB device number 15 using ehci-pci

[10772.949641] hid-generic 0003:1294:1320.000D: hiddev0,hidraw2: USB HID v1.10 Device [MAIL  MAIL ] on usb-0000:00:1a.0-1.6/input0

As it registers itself with the HID subsystem, we can use the resulting hidraw device to talk to it without using any script or tool, just make a convenience symlink with useable permissions using a small udev rule:



$ cat /etc/udev/rules.d/99_webmail_notifier.rules 

# USB Webmail Notifier (RGB LED)

SUBSYSTEM=="hidraw" SUBSYSTEMS=="usb", ATTRS{idVendor}=="1294", ATTRS{idProduct}=="1320", GROUP="users", MODE="0660", SYMLINK="webmailnotify"

Then you can make it change its colour with a simple echo-command in any script:



$ echo -en '\001\0\0\0\0' >/dev/webmailnotify

The only ugly thing about it: It seems to send back some HID report which confuses and angers the kernel routines, but this shall be dealt with at some later point.



[11170.163495] hid-generic 0003:1294:1320.000D: extract() called with n (56) > 32! (swapper/0)

AES/EBU to ‘SPDIF’ - ghetto style

noreply@blogger.com (Christian Vogel) — Sat, 09 Feb 2013 12:41:00 +0000

For interfacing AES/EBU to S/PDIF, I've built a simple transformer out of a small ferrite core, I was planning to convert the 110Ω symmetric AES/EBU signal coming out of a surplus ADC/DAC (I love you, eBay ;-) ...) to the S/PDIF of my computer interfaces (and vice-versa).

There's a nice text about all this over at RANE, but normal people just shell out the 100€ for two of Neutrik's transformers in a box.

The screenshots below show the output of the transformer, terminated by 75 Ohm (or by the audio-interface S/PDIF input, looks identical) when driven by the AES output. I wanted to hide everything in the XLR connector shell, and hence the ferrite beads are pretty small. Therefore they saturate visibly at 32kHz f_s, but it works fine for this signal direction. At 96kHz everything looks perfect.

From Chris’ Miscellanea

The other direction works not as nicely: All of my audio-gear has a pretty high output impedance on the S/PDIF outputs! With a open output, I get something like 3-5V_PP of signal swing, but terminated it goes down to 500mV (just as the spec says). With the saturating ferrite beads, the high-impedance outputs cannot provide the additional current, and the ideally square-shaped output degenerates to tiny spikes of both polarities and is completely unusable. The not-very-pretty-but-working-solution: Just connect the SPDIF to AES 1:1, but keep cable lengths short. (no scope, screenshots, sorry).

M-Audio Fast-Track Pro PCB Pictures

noreply@blogger.com (Christian Vogel) — Mon, 14 Jan 2013 19:42:00 +0000

I'm a little annoyed by the limitations of the M-Audio Fast-Track Pro, so I'm thinking about how to mod it. My main grief is the abysmally bad windows drivers that bluescreen constantly under Win7. Then there is the limitation of USB1.1, which does not have enough bandwidth for anything more than 2x24/96 streams. My plan is to make a normal standalone S/PDIF ADC/DAC (2in, 2out, 24/96) out of it.

First, I took a few pictures of the two PCBs inside the unit, and traced a few signals. You can see immediately that the electronic layout of the unit is very tidy!

Main integrated components:

Texas Instruments TUSB 3200 USB Streaming Controller
Asahi Kasei AK4114 S/PDIF Transceiver
Asahi Kasei AK5381 24bit 96kHz ADC
Asahi Kasei AK4381 24bit 192kHz DAC (compatible successor AK4385)

Misc. Digital

74LVC157A, Quad 2-Input Multiplexer
AT24C64 Atmel 64kBit I2C EEPROM

The phantom voltage generator has a venerable NE555!

OP-Amps

NJM2115 NRC Dual Operational Amplifier
NJM3414 NRC Single Supply Dual High Current Operational Amplifier (Headphone Out)

From M-Audio Fast Track Pro

Note: Archlinux and Xorg Keyboard Layout

noreply@blogger.com (Christian Vogel) — Thu, 10 Jan 2013 15:45:00 +0000

Archlinux for me seems to miss any magic that takes care of automatically providing the correct keymap to xorg's input driver. To make udev provide the correct settings to xorg, this small udev-rule works.

[root@fbsd ~]# cat /etc/udev/rules.d/99_keyboard_keymap.rules
SUBSYSTEM=="input", ENV{ID_INPUT_KEYBOARD}=="1", ENV{XKBMODEL}="pc105", ENV{XKBLAYOUT}="de", ENV{XKBVARIANT}="nodeadkeys"

So far it's understood by xorg just fine.

[  2888.705] (II) XINPUT: Adding extended input device "Das Keyboard" (type: KEYBOARD, id 8)
[  2888.705] (**) Option "xkb_rules" "evdev"
[  2888.705] (**) Option "xkb_model" "pc105"
[  2888.705] (**) Option "xkb_layout" "de"
[  2888.705] (**) Option "xkb_variant" "nodeadkeys"

☠⚠⚡☔☣☢☹⛈ Windows 8...

noreply@blogger.com (Christian Vogel) — Fri, 28 Dec 2012 18:42:00 +0000

Got myself Win8 for €30 (upgrade from a old Student-for-Free Vista license I never used, instead of €150 it looked like a bargain). My normal computer went bad, and I'm playing with a replacement device while waiting for replacement parts to arrive.

http://www.heise.de/ct/schlagseite/2013/1/

This Metro-bathroom-tiles stuff is so incredibly distracting when you want to do real work. Click on a mp3 file, ... *BAM!* fullsceen mp3 player (how could I ever live without such a thing. I mean, music players are meant to get your full attention while reproducing the music). Add a printer? *BAM!* Fullscreen "Add a device" app.

The builtin graphics drivers of the rather old Nvidia Quadro always crash when trying to accellerate video decode. There's a third party tool to turn it off, recommended frequently because it seems to be pretty normal that video accelleration crashes, with a lot of different graphics cards. One of my soundcards is no longer supported, the other one (M-Audio Delta 44) has the usual fucked-up drivers all "Pro Audio" gear has, because all these companies universally employ morons to do the programming who eventually just pick lame excuses out of their ... Oh my, I'm angry..

Apparently "Skype" is now built in. But: It refuses to let you use it without converting your "old" skype account into a "Windows live ID". And I learned that the new bathroom-tile-version doesn't do file-transfer. WTF?!

Sorry, Microsoft, I really wanted to try out this new thing and tried to be open about it, but you made usability for non "grandma got a tablet PC for Christmas" users really abysmally bad, I'm quite frustrated after only a few hours of light use.

And I cannot understand how this usage paradigm of full-screen apps should map to people doing actual work, instead of browsing the web and playing with facebook. And I cannot understand why it cannot be disabled completely (with tile-apps running in a window, for example).

When the parts for my other PC (the motherboard apparently went bad the last few weeks, with LAN and SATA controller deteriorating) arrive tomorrow or on monday, I'm pretty sure what OS I'll NOT install.