Assign Static Device Name for USB Infrared Toy
The last few days I was playing arround with my USB Infrared Toy v2 from Dangerous Prototypes. Due to the fact that I have attached some more devices which are detected as /dev/ACM[0-9] I decided to write an udev rule to assign a static device name.
I stored the rule in the following file: /etc/udev/rules.d/98-ir-toy-v2.rules
SUBSYSTEM=="tty", ATTRS{manufacturer}=="Dangerous Prototypes", ATTRS{idProduct}=="fd08", SYMLINK+="ir_toy" MODE="0666"
Maybe the field “ATTRS{idProduct}==”fd08”“ have to be tweaked for versions differnet of v2. With this rule the IR Toy is accessible via /dev/ir_toy
Rewriting History
Sometimes history has to be rewritten. In real life this is hopefully not possible yet. But in case of git this is possible. Some projecs start with a small repository which evolves over the time to a big bloated repository. Other ones start already bloated. In some cases the wish to split-up the repository in smaller chunks emerges. With some advice from Stefan Seyfried I learned how to rewrite history
The goal was to extract the driver directory from the tdt repository like Stefan already did.
These are the steps to follow:
$ cd /dev/shm/
$ git clone --reference /net/transfer/spark71xx/tdt https://git.gitorious.org/open-duckbox-project-sh4/tdt.git tdt-driver
$ cd tdt-driver/
$ git filter-branch --subdirectory-filter tdt/cvs/driver
The first step speeds up the process of rewriting by doing it all in memory instead of writing everything onto a slow disk device. But please remember to push your work onto a less volatile memory.
$ cd /dev/shm/
In the second step the original repository is cloned. To again speedup things I used a local copy as reference. After cloning the directory structure looked like this
$ tree -d -L 3 tdt/
tdt/
├── custom
├── cvs
│ ├── apps
│ │ ├── dvb
│ │ ├── enigma1-hd
│ │ ├── enigma2
│ │ ├── misc
│ │ ├── neutrino
│ │ ├── tuxbox
│ │ └── vdr
│ ├── boot
│ │ └── u-boot-tufsbox
│ ├── cdk
│ │ ├── integrated_firmware
│ │ ├── make
│ │ ├── own_build
│ │ ├── Patches
│ │ ├── root
│ │ ├── static
│ │ └── tfinstaller
│ ├── driver
│ │ ├── adb_box_fan
│ │ ├── avs
│ │ ├── boxtype
│ │ ├── bpamem
│ │ ├── button
│ │ ├── button_hs5101
│ │ ├── cec
│ │ ├── cec_adb_box
│ │ ├── cic
│ │ ├── compcache
│ │ ├── cpu_frequ
│ │ ├── dvbt
│ │ ├── e2_proc
│ │ ├── frontcontroller
│ │ ├── frontends
│ │ ├── i2c_spi
│ │ ├── include
│ │ ├── ipbox99xx_fan
│ │ ├── led
│ │ ├── logfs
│ │ ├── multicom-3.2.2
│ │ ├── multicom-3.2.4
│ │ ├── multicom-3.2.4_rc3
│ │ ├── multicom-4.0.6
│ │ ├── old
│ │ ├── player2_131
│ │ ├── player2_179
│ │ ├── player2_191
│ │ ├── pti
│ │ ├── rmu
│ │ ├── sata_switch
│ │ ├── siinfo
│ │ ├── simu_button
│ │ ├── smartcard
│ │ ├── stgfb
│ │ ├── tfswitch
│ │ ├── ufs922_fan
│ │ └── wireless
│ └── hostapps
│ ├── flash
│ ├── mkfs.jffs2
│ └── mklibs
└── flash
├── at7500
│ ├── extras
│ ├── scripts
│ ├── scripts_209
│ └── scripts_extended
├── common
│ ├── fup.src
│ ├── mup.src
│ └── pad.src
├── hs7810a
│ ├── extras
│ └── scripts
├── spark
│ ├── extras
│ └── scripts
├── tf7700hdpvr
├── ufc960
│ ├── extra
│ └── scripts
├── ufs910
│ └── scripts
├── ufs912
│ ├── extras
│ └── scripts
└── ufs913
├── extra
├── scripts
└── test
The last step extracts just the directory ‘’tdt/cvs/driver’’
$ git filter-branch --subdirectory-filter tdt/cvs/driver
After this step the filesystem looks like this:
$ tree -d -L 1 tdt-driver/
tdt-driver/
├── adb_box_fan
├── avs
├── boxtype
├── bpamem
├── button
├── button_hs5101
├── cec
├── cec_adb_box
├── cic
├── compcache
├── cpu_frequ
├── dvbt
├── e2_proc
├── frontcontroller
├── frontends
├── i2c_spi
├── include
├── ipbox99xx_fan
├── led
├── logfs
├── multicom-3.2.2
├── multicom-3.2.4
├── multicom-3.2.4_rc3
├── multicom-4.0.6
├── old
├── player2_131
├── player2_179
├── player2_191
├── pti
├── rmu
├── sata_switch
├── siinfo
├── simu_button
├── smartcard
├── stgfb
├── tfswitch
├── ufs922_fan
└── wireless
There are more steps recommended in a stackoverflow article. These steps had not been necessary for my example.
UBIFS as Rootfs
This Post describes how to get startet with an UBIFS root filesystem. I suppose you are using a image generated for the “spark” device. I have not done any tests with “spark7162”. For the spark boxes there is automatically a ubifs image generated.
Generate a core-image-minimal for example. This assumes You already have set-up the yocto build environment.
MACHINE=spark bitbake core-image-minimal
The resulting image can be found here
tmp/deploy/images/core-image-minimal-spark.ubi
This is a ubivolume which can be burned to flash …
The Linux Way
For flashing from Linux booting over USB is recommended. Be cause we do not want to bite the hand that feeds us. For debugging and configuration purposes a Nullmodem Cable and a Terminal Emulator is recommended.
Flashing the image
To get a list with the mtd devices just dump the content of “/proc/mtd”
root@spark:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00010000 "Boot firmware"
mtd1: 00700000 00010000 "Kernel"
mtd2: 00080000 00010000 "Reserve"
mtd3: 00800000 00020000 "Spark Kernel"
mtd4: 17800000 00020000 "Spark Rootfs"
mtd5: 00800000 00020000 "E2 Kernel"
mtd6: 05000000 00020000 "E2 RootFs"
We want to modify the Partion number “6” also known as “E2 RootFs”. Be carefull to not erase Number “0” otherwise your bootloader is blown. At first you have to transfer the image. In absence of any other tools I do use netcat again.
On the host (quadros) run this
$ cat tmp/deploy/images/core-image-minimal-spark.ubi | nc -l -v 3333
On the target run this
root@spark:~# nc quadros 3333 > /tmp/image.ubi
Now we can burn the image onto the flash
root@spark:~# flash_eraseall /dev/mtd6
root@spark:~# ubiformat /dev/mtd6 -q -y -f /tmp/image.ubi
Choosing the right commandline
I had a some difficulties with the console. The default bootagrs point to “ttyAS1” but I have to use ttyAS0. So I have to check this. This is the command line which works for me.
setenv bootargs 'console=ttyAS0,115200 rw init=/bin/devinit coprocessor_mem=4m@0x40000000,4m@0x40400000 printk=1 nwhwconf=device:eth0,hwaddr:00:80:E1:12:40:61 rw ip=172.100.100.249:172.100.100.174:172.100.100.174:255.255.0.0:LINUX7109:eth0:off bigphysarea=6000 stmmaceth=msglvl:0,phyaddr:2,watchdog:5000 ubi.mtd=6 rootfstype=ubifs root=ubi0:rootfs'
The spark u-boot
The spark bootloader has a nice menu integrated. With this you can also write images from a USB stick to the flash. Notice this is not the recommended way. Using ubiformat keeps all required information about the underlying flash device. To get started you need a USB-Stick which is supported by the spark u-noot. To boot the UBI image the commandline also have be tweaked to use ubi instead jffs2. Please have a look at the The Linux Way section for advise.
- Format USB-thumb drive with a single FAT32 partition
- Create an enigma2 folder on the USB-thumb drive
- Copy the file core-image-minimal-spark.ubi to the enigma2 folder and rename it to e2jffs2.img
- Copy the file uImage-spark.bin to the enigma2 folder as-well and rename it to uImage
- Turn the Set-Top-Box off by the power switch
- Put the USB-Stick into the USB-Slot at the back of the STB. Not the front one!
- Press the OK at the Front-Panel and keep it pressed.
- Turn on the box by the power switch.
- Wait until you read “Forc” on the display
- Release the OK Button. Now you can press the Button V+ -> (right).
- After this you can read “U LD” on the display.
- The flashing of the image may take some minutes. After successfull flashing “SUCC” is written on the display and the box reboots.
Analyzing Kernel Oops
There was a little hickup in the kernel while shutting down or rebooting the system. The result of the hickup was a Kernel Oops. Because it had no big influence on the behaviour of the system I did not spend a lot of time on investigation. Yesterday I did some tests with the yocto workflow for kernel development and tried to fix the hickup.
The hickup
The Kernel Oops looked like this one
Unmounting local filesystems...
[ 2135.692000] umount: sending ioctl 4c01 to a partition!
[ 2135.696000] umount: sending ioctl 4c01 to a partition!
Rebooting... [ 2137.744000] ------------[ cut here ]------------
[ 2137.744000] Badness at 80a859a0 [verbose debug info unavailable]
[ 2137.744000]
[ 2137.744000] Pid : 855, Comm: reboot
[ 2137.744000] CPU : 0 Not tainted (2.6.32.59_stm24_0211 #2)
[ 2137.744000]
[ 2137.744000] PC : 80a859a0 SP : 8928be48 SR : 400080f1 TEA : c113ae28
[ 2137.744000] R0 : 00000000 R1 : 00000000 R2 : 80c22e7c R3 : 00002000
[ 2137.744000] R4 : 80c22ba4 R5 : 80a85610 R6 : 00000000 R7 : 00003fff
[ 2137.744000] R8 : 80c229cc R9 : 80a855fe R10 : 89ec440c R11 : 00000000
[ 2137.744000] R12 : fffff000 R13 : 80a859e0 R14 : 00000000
[ 2137.744000] MACH: 000000de MACL: 00000014 GBR : 296c1470 PR : 80a859cc
[ 2137.744000]
[ 2137.744000] Call trace:
[ 2137.744000] [<80a85a04>] 0x80a85a04
[ 2137.744000] [<80a5347a>] 0x80a5347a
[ 2137.744000] [<809db332>] 0x809db332
[ 2137.744000] [<8081f610>] 0x8081f610
[ 2137.744000] [<8081f636>] 0x8081f636
[ 2137.744000] [<8081f780>] 0x8081f780
For me under yocto the best way to get in touch with the source is to start a devshell.
bitbake -cdevshell virtual/kernel
While the occurence of the Oops the PC (program counter) was at address 0x80a859a0. So my first approach was loading the vmlinux in gdb. This was not that succefull because the kernel had no debug symbols included. The next source of information is the Sytem.map file:
cat cat System.map | grep 80a859
80a85904 T _clk_disable
This looks like the cause of the problem is located in this function. To get a closer look I decided to compile the kernel with debug symbols. So I added the following config options:
CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
And recompiled the kernel
bitbake -ccompile -f virtual/kernel
bitbake -cdeploy -f virtual/kernel
And finally copied the kernel onto the USB pendrive. Because I do the most of my testing while booting from USB.
cp tmp/deploy/images/uImage-spark.bin /media/spark/uImage
After unmounting the pendrive I tested on the box with the follwing results:
Unmounting local filesystems...
[ 38.764000] umount: sending ioctl 4c01 to a partition!
[ 38.768000] umount: sending ioctl 4c01 to a partition!
Rebooting... [ 40.816000] ------------[ cut here ]------------
[ 40.816000] Badness at drivers/stm/clk.c:190
[ 40.816000]
[ 40.816000] Pid : 779, Comm: reboot
[ 40.816000] CPU : 0 Not tainted (2.6.32.59_stm24_0211 #2)
[ 40.816000]
[ 40.816000] PC : 80a8b7e4 SP : 88e59e44 SR : 400080f1 TEA : c16772ac
[ 40.816000] R0 : 00000000 R1 : 00000000 R2 : 80c2fe58 R3 : 00002000
[ 40.816000] R4 : 80c2fb80 R5 : 80a8b438 R6 : 00000000 R7 : 00003fff
[ 40.816000] R8 : 80c2f9a8 R9 : 80a8b426 R10 : 89e2048c R11 : 00000000
[ 40.816000] R12 : fffff000 R13 : 80a8b824 R14 : 00000000
[ 40.816000] MACH: 000000de MACL: 00000014 GBR : 296c1470 PR : 80a8b810
[ 40.816000]
[ 40.816000] Call trace:
[ 40.816000] [<80a8b84a>] 0x80a8b84a
[ 40.816000] [<80a58f9e>] 0x80a58f9e
[ 40.816000] [<809e055a>] 0x809e055a
[ 40.816000] [<8082188c>] 0x8082188c
The Oops now tells me where I do have to look at:
[ 40.816000] Badness at drivers/stm/clk.c:190
The next test is to try what gdb tells me the address varies, because this is the kernel with the fix applied. But the mechanism is the same.
# sh4-poky-linux-gdb vmlinux
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux --target=sh4-poky-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from vmlinux...done.
(gdb) list *(0x80a8b460)
0x80a8b460 is in _clk_disable (drivers/stm/clk.c:187).
182 return ret;
183 }
184 EXPORT_SYMBOL(clk_enable);
185
186 void _clk_disable(struct clk *clk)
187 {
188 int ret;
189
190
191 if (clk_is_always_enabled(clk)) {
(gdb)
With this information gdb can help to narrow the source of the problem. In my case I just googled the keywords stm and _clk_disable and found the following patch: linux-sh4-fix-crash-usb-reboot_stm24_0211.diff
JFFS2 vs. UBIFS
After a successfull merge of the UBIFS patches I have made some benchmarks. In both cases I have flashed the same image. It was a fresh build of core-image-minimal from the dylan branch. Maybe these benachmarks have to be repeated with a more representative scenario. More Information regarding UBIFS can be found on eLinux. If you are interested in more flash file system Benchmarks you can also have a look a eLinux.
Mounting a JFFS2 Volume
root@spark:~# time mount /dev/mtdblock6 -tjffs2 /mnt/
real 0m 2.06s
user 0m 0.00s
sys 0m 2.06s
Mounting a UBIFS volume
root@spark:~# time ubiattach -m6 && time mount -tubifs ubi0:rootfs /mnt/
[ 663.748000] UBI: attaching mtd6 to ubi0
[ 663.752000] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 663.760000] UBI: logical eraseblock size: 129024 bytes
[ 663.764000] UBI: smallest flash I/O unit: 2048
[ 663.768000] UBI: sub-page size: 512
[ 663.776000] UBI: VID header offset: 512 (aligned 512)
[ 663.780000] UBI: data offset: 2048
[ 663.940000] UBI: max. sequence number: 28
[ 663.960000] UBI: attached mtd6 to ubi0
[ 663.972000] UBI: MTD device name: "E2 RootFs"
[ 663.976000] UBI: MTD device size: 80 MiB
[ 663.980000] UBI: number of good PEBs: 638
[ 663.988000] UBI: number of bad PEBs: 2
[ 663.992000] UBI: number of corrupted PEBs: 0
[ 663.996000] UBI: max. allowed volumes: 128
[ 664.000000] UBI: wear-leveling threshold: 4096
[ 664.008000] UBI: number of internal volumes: 1
[ 664.012000] UBI: number of user volumes: 1
[ 664.016000] UBI: available PEBs: 0
[ 664.020000] UBI: total number of reserved PEBs: 638
[ 664.024000] UBI: number of PEBs reserved for bad PEB handling: 6
[ 664.028000] UBI: max/mean erase counter: 1/0
[ 664.032000] UBI: image sequence number: 1037100788
[ 664.040000] UBI: background thread "ubi_bgt0d" started, PID 553
UBI device number 0, total 638 LEBs (82317312 bytes, 78.5 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
real 0m 0.31s
user 0m 0.00s
sys 0m 0.28s
[ 664.092000] UBIFS: background thread "ubifs_bgt0_0" started, PID 556
[ 664.160000] UBIFS: mounted UBI device 0, volume 0, name "rootfs"<NULL>
[ 664.164000] UBIFS: LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 664.168000] UBIFS: FS size: 79607808 bytes (75 MiB, 617 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs)
[ 664.172000] UBIFS: reserved for root: 0 bytes (0 KiB)
[ 664.176000] UBIFS: media format: w4/r0 (latest is w4/r0), , small LPT model
real 0m 0.14s
user 0m 0.00s
sys 0m 0.11s
That Was a Close Shave!
While fiddling arround with the ubifs port I recently did. I misstyped the MTD Partion and completly erased mtd0. This sounds not that tragically, but on mtd0 u-boot is located. Without a bootloader there is only a small chance that the box will boot again. To reboot the box in such a situation is a absolut no go. Now you have to start brain work …
For the ubifs tests I have choosen the fresh dylan port of my meta-stlinux layer. This was a first draft and so I just build the ,,core-image-minimal’‘. I included the mtd-utils but I’ve forgotten to include a ssh server aswell. This was not a big issue due to the fact that I used the serial line for connection. For testing I booted the box from USB. The USB was connect through a USB extension cable. Which cut me off from installing a fresh u-boot by inserting a USB Stick.
What are the options?
- Transfer the u-boot by zmodem
- Transfer the u-boot by ethernet.
The name minimal definitly means minimal. There was no serial command I did know to transer data. On the ethernet no SSH no telnet and of course no FTP. Okay lets start thinking…
BANG!!! my good old friend ,,netcat’‘ one little test and yes there is a ,,nc’‘ command. The rest was easy going.
How I solved the issue
On the host PC start the server
cat ~/uboot-alien.bin | nc -v -l 3333
Yes I do know alien is not the correct name for a golden media GM990 Box. But this was the only image I have found.
On the box I used this commands
# nc 192.168.24.157 3333 > u-boot.bin
# du u-boot.bin
520 u-boot.bin
# flash_eraseall -j /dev/mtd0
flash_eraseall has been replaced by `flash_erase <mtddev> 0 0`; please use it
Erasing 64 Kibyte @ 0 -- 0 % complete flash_erase: Cleanmarker written at 0
Erasing 64 Kibyte @ 10000 -- 12 % complete flash_erase: Cleanmarker written at 10000
Erasing 64 Kibyte @ 20000 -- 25 % complete flash_erase: Cleanmarker written at 20000
Erasing 64 Kibyte @ 30000 -- 37 % complete flash_erase: Cleanmarker written at 30000
Erasing 64 Kibyte @ 40000 -- 50 % complete flash_erase: Cleanmarker written at 40000
Erasing 64 Kibyte @ 50000 -- 62 % complete flash_erase: Cleanmarker written at 50000
Erasing 64 Kibyte @ 60000 -- 75 % complete flash_erase: Cleanmarker written at 60000
Erasing 64 Kibyte @ 70000 -- 87 % complete flash_erase: Cleanmarker written at 70000
Erasing 64 Kibyte @ 70000 -- 100 % complete
# flashcp u-boot.bin /dev/mtd0
# reboot
Now it was time to to keep one’s fingers crossed. One deep breath later the box bootet like every time before.
Board: STx7111-Mboard (MB618) [32-bit mode]
info: Disregarding any EPLD
U-Boot 1.3.1 (Oct 19 2010 - 18:08:50) - stm23_0043 - YW 1.0.017 Rel
DRAM: 128 MiB
NOR: 8 MiB
NAND: 512 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
IdentID : 09 00 07 00 00 46 d1
0 ESC to stop autoboot: 3
Except of the little message ,,*** Warning - bad CRC, using default environment’‘ this was caused because by writing 512kb I have destroyed u-boot environment. I am not sure If this is the right u-boot. I would be happy If someone with a Golden Media Spark reloaded Box can send me a copy of the u-boot.