The version of the Videolan Client (VLC) for Fedora Core 5 from freshrpms does not include DVB support.

[foo@localhost ~]$ vlc --program 4704 dvb:12207000:0:3:27500000
VLC media player 0.8.5 Janus
status change: ( new input: dvb:12207000:0:3:27500000 )
status change: ( audio volume: 256 )
status change: ( play state: 1 )
[00000295] main input error: no suitable access module for `dvb:12207000:0:3:27500000'
status change: ( stop state: 0 )
[00000285] main playlist: nothing to play

A quick search through the VLC Documentation shows it must be rebuilt with the ‘experimental’ --enable-dvb option.

I took the source RPM from Freshrpms, added the --enable-dvb option on the ./configure line and attempted to rebuild.

Assuming you have an up to date Fedora Core 5 installation, working DVB hardware with the necessary drivers. To do this you will need (at least) the following packages installed:

gnutls-devel libdvdread-devel libdvdnav-devel libebml-devel libmatroska-devel libmodplug-devel libmad-devel libid3tag-devel lame-devel faac-devel faad2-devel a52dec-devel flac-devel mpeg2dec-devel speex-devel libtheora-devel x264-devel SDL_image-devel fribidi-devel aalib-devel libcaca-devel wxGTK-devel xosd-devel lirc-devel libcdio-devel vcdimager-devel avahi-devel libopendaap-devel libmpcdec-devel libcddb-devel libdca-devel

These are available from the core & extras Fedora repositories, some are located in the ATrpms & Freshrpms repositories.

Build the new RPM with the following:

[root@localhost ~]# rpmbuild –ba /usr/src/redhat/SPECS/videolan-client.spec

To install the new RPM I had to --force –nodeps the RPM transaction:

[root@localhost ~]# rpm -U --force --nodeps videolan-client-0.8.5-1.fc5.i386.rpm videolan-client-devel-0.8.5-1.fc5.i386.rpm

This time when I retry launching VLC I got the following:

[foo@localhost ~]$ vlc --program 4704 dvb:12207000:0:3:27500000
VLC media player 0.8.5 Janus
[00000544] skins2 interface error: Cannot open display
[00000544] skins2 interface error: cannot initialize OSFactory
Remote control interface initialized. Type `help' for help.
[00000548] dvb access error: the DVB input old syntax is deprecated, use vlc -p dvb to see an explanation of the new syntax

It turns out that the VLC documentation is rather outdated. After poking around in the VLC user interface I extracted the necessary command-line arguments to make it work.

The following command line execution of VLC will tune to the frequency 12.207Ghz, vertical polarisation, symbol rate 27.5Mhz with an ‘automatic’ FEC and select program 4704 (Sky News).

[foo@localhost ~]$ vlc --program=4704 dvb:// :dvb-adapter=0 :dvb-frequency=12207000 :dvb-srate=27500000 :dvb-caching=300 :dvb-inversion=2 :dvb-probe :dvb-voltage=13 :no-dvb-high-voltage :dvb-tone=-1 :dvb-fec=9 :dvb-code-rate-hp=9

And this variation will stream it over UDP to localhost port 1234.

[foo@localhost ~]$ vlc --program=4704 dvb:// :dvb-adapter=0 :dvb-frequency=12207000 :dvb-srate=27500000 :dvb-caching=300 :dvb-inversion=2 :dvb-probe :dvb-voltage=13 :no-dvb-high-voltage :dvb-tone=-1 :dvb-fec=9 :dvb-code-rate-hp=9 :sout=\#duplicate\{dst=std\{access=udp,mux=ts,dst=127.0.0.1:1234\}\}

And without further a do, the pre-built RPMS and modified source RPM I created.

Binary RPM:

videolan-client-0.8.5-1.fc5.i386.rpm
videolan-client-devel-0.8.5-1.fc5.i386.rpm
videolan-client-debuginfo-0.8.5-1.fc5.i386.rpm

Source RPM:

videolan-client-0.8.5-1.fc5.src.rpm

Lastly, you can select multiple programs from the same transponder and stream them to separate destination addresses, see the example in Chapter 9 of the VLC documentation.

Feedback & Questions welcomed!

Hard Drive Jenga

A term used to describe removal of Hard Drives from a RAID storage array where the objective of the game is to remove as many drives as possible without the array collapsing causing catastrophic data loss. Not for the faint hearted!

Not to be confused with Hard Drive Dominoes (another fine example).

Bit of an update, my previous post is now getting a significant amount of traffic; in fact it’s my hottest post yet!

Progress over at http://tifmxx.berlios.de/ – I downloaded the latest revision of this driver and it appears to be going through re-structuring, still not-functional I am afraid.

However, a month since contacting TI I received a response to my telephone-based support request by email.

From: support@ti.com

Hello Michael,

I am sorry TI doesn’t support software drivers for cardbus devices,
please see below for more details on this:

TI PC Card, Flash Media, IEEE 1394 and Smart Card Controller
Devices:

Texas Instruments (TI) I does not develop software drivers for
these multi-function controllers. Our devices are used in Personal
Computers and add-in cards from many manufacturers. These
manufacturers include drivers from Microsoft and, for certain
platforms, from the Linux community that enable the PC Card and 1394
functions in these TI devices. Texas Instruments does not provide
drivers for Windows, Linux or any other operating system.

If you are encountering difficulties with your PC or add-in card,
please contact the manufacturer for support. Texas Instruments does
not provide any support for these end products.

If you require drivers for Flash Media or Smart Card you need to
contact the PC manufacturer. TI does not provide drivers for atypical
system applications.

Additional information

To find the manufacturer of the card, use the FCC’s web page
http://www.fcc.gov/oet/fccid/ to search for the FCC ID number printed
on the bottom of the card. If it came preinstalled, please contact
the store where you purchased the computer.

Third-party vendors have developed Card &Socket Services driver
support for other operating systems. These vendors include Phoenix
Technologies/Award Software, and SystemSoft:

Microsoft
www.microsoft.com 800-426-9400

Award Software/Phoenix Technologies www.phoenix.com
800-677-7305

Systemsoft Corp.
www.systemsoft.com 800-796-0088

Softex, Inc.
www.softexinc.com 512-452-8836

Best Regards,
Sandeep.

TI assumes no liability for applications assistance or customer
product design. Customer is fully responsible for all design
decisions and engineering with regard to its products, including
decisions relating to application of TI products. By providing
technical information, TI does not intend to offer or provide
engineering services or advice concerning Customer’s design. If
Customer desires engineering services, the Customer should rely on
its retained employees and consultants and/or procure engineering
services from a licensed professional engineer (LPE).

***Please do not delete the below Thread ID when replying to this
email, doing so will delay our response to your inquiry***

[SR THREAD ID:1-3RGCWY]

Dear Michael Cutler

Thank you for choosing Texas Instruments Technical Support. Your
case 1-227511394 has been resolved. See the description below for
details.

Would like Linux driver for this card. I told him we didn’t supply
them and to contact PCMCIA, but he said that he knew somebody who had
managed to get these from TI

Regards,

X0045551

Texas Instruments

Semiconductor Technical Support

http://www-k.ext.ti.com/sc/technical_support/pic/americas.htm

If you have further questions please reply to this email.

TI assumes no liability for applications assistance or customer
product design. Customer is fully responsible for all design
decisions and engineering with regard to its products, including
decisions relating to application of TI products. By providing
technical information, TI does not intend to offer or provide
engineering services or advice concerning Customer’s design. If
Customer desires engineering services, the Customer should rely on
its retained employees and consultants and/or procure engineering
services from a licensed professional engineer (LPE).
***Please do not delete the below Thread ID when replying to this
email, doing so will delay our response to your inquiry***
[SR THREAD ID:1-3RGCWY]

And my response.

Dear Sandeep,

Thank you for taking the time to respond to my query. I appreciate that Texas Instruments (TI) does not tend to support end-users of your devices, especially with driver problems and believe me if it were that simple I would not be taking up your time today.

The reason I am contacting you is simple, I am trying to use my TI 7×20/7×21 Flash Media controller (PCI ID 104c:8033) within Linux. After a lot of research on the subject I discovered this page on the Everest Consultants Inc website. It suggests the Texas Instruments hired Everest to produce Linux Device Drivers for this particular chip; judging by the write up they have produced a well designed and much needed driver solution. I contacted Everest about obtaining this driver and they referred me to you.

http://www.everestinc.com/fml.htm

In the meantime I continued researching this on the internet and discovered an open source and “free” (as in freedom) effort to produce a driver for this device. Unfortunately it isn’t progressing particularly quickly because technical documentation on this chip is scarce.

http://tifmxx.berlios.de/

I also discovered another person who had managed to obtain a binary version of what are presumably the Everest-made drivers. It is also interesting to note that the ‘modinfo’ for the driver states it is under GPL (Gnu Public License) and as such, the source code should be available on demand.

http://www.webcon.ca/~imorgan/tifm21/

I have been recording my progress on my personal website. In the past seven days I have had 243 unique visitors who have searched for this device in relation to Linux and discovered my website and the record of my progress, a handful have contacted me directly about it.

There is a great demand for Linux support for this device, I would like to see either the Everest-made GPL driver source code made available or, extensive technical documentation – sufficient to allow open source developers to produce a driver – made available to the Open Source Community.

Yours Sincerely,

–
Michael Cutler . o O ( http://blog.lobstertechnology.com/ )
PGP: 0xC3ABA735

I will follow up by calling them again during mainstream office hours and see where I can get myself transferred to this time.

To my absolute surprise, the Sitecom CN-502 USB Bluetooth Dongle works perfectly with out-of-the-box Fedora Core 4 x86_64. The lsusb output shows it’s a Cambridge Silicon Radio chip (0a12:0001) which is very widely used and well supported.

I bought this thing some time ago because of its protruding aerial; my original intention was to dismantle it and add a huge-gain antenna – Car Whisperer-esque – but I just haven’t got around to doing it.

The lsusb output:

Bus 003 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

For completeness, here is the rest of my config:

$ uname -a
Linux localhost 2.6.14-1.1656_FC4 #1 Thu Jan 5 22:13:55 EST 2006 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q -a | grep -i bluez
bluez-hcidump-1.18-1
bluez-utils-2.15-7
bluez-pin-0.24-2
bluez-libs-2.15-1

And it working:

$ /etc/init.d/bluetooth start
Starting Bluetooth services: [ OK ]
$ hcitool scan
Scanning ...
00:XX:XX:XX:XX:XX XXXXXXXX

Not bad since I found it in a bargain bucket!

Related Links:

Sitecom CN-502 Product Support

Update: TI 7x21 FlashMedia/SD Host Controller (104C:8033 & 104C:8034)

The Compaq R4100 series of laptops feature a 6-in-1 memory card reader based on the widely used Texas Instruments 7x21 chips. Although TI provides Windows drivers there is very little information available to assist in development of a free Linux device driver for it.

It appears that TI actually contracted another company (Everest) to write a Linux device driver, although the write-up on their work shows great potential there is no sign of the driver or its source code. There is however a binary version of the driver built for the 2.6.11 kernel available here - unfortunately it's useless for me since I am running a 64-bit kernel.

I found a few promising leads while Googling where reverse engineering the Windows driver was helping development of a native kernel driver for it.

http://tifmxx.berlios.de/
http://www.webcon.ca/~imorgan/tifm21/

Unfortunately there is no fully working driver as yet, however the Subversion repository at tifmxx.berlios.de is very active, I checked out the latest revision of the code to test it out

make
insmod tifmxx.ko

returned:

tifmxx: Unknown symbol scsi_remove_host
tifmxx: Unknown symbol pci_intx
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_ae
tifmxx: Unknown symbol scsi_host_put
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_brs
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_card
tifmxx: Unknown symbol scsi_add_host
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_af
tifmxx: Unknown symbol scsi_host_alloc
tifmxx: Unknown symbol __scsi_add_device
tifmxx: Unknown symbol scsi_remove_host
tifmxx: Unknown symbol pci_intx
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_ae
tifmxx: Unknown symbol scsi_host_put
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_brs
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_card
tifmxx: Unknown symbol scsi_add_host
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_af
tifmxx: Unknown symbol scsi_host_alloc
tifmxx: Unknown symbol __scsi_add_device

Trawling mailing-lists I found that "pci_intx" wasn't implemented by the kernel in version 2.6.11-1.1369 but it is in later releases like 2.6.14-1.1656 which I also tested with. To workaround this in 2.6.11-1.1369 the recommendation was to add the following code to the top of tifmxx_hw.c.

Although this avoided the pci_intx problem the others remained, *probably* down to SCSI not being enabled in the Fedora Core 4 standard kernel; the missing tifmxx_ symbols simply aren't implemented yet. Rebuilding it without the pci_intx hack on my 2.6.14-1.1659 kernel appeared to be a lot better, looks promising.

tifmxx: Unknown symbol scsi_remove_host
tifmxx: Unknown symbol scsi_add_device
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_ae
tifmxx: Unknown symbol scsi_host_put
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_brs
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_card
tifmxx: Unknown symbol scsi_add_host
tifmxx: Unknown symbol tifmxx_mmcsd_wait_for_af
tifmxx: Unknown symbol scsi_host_alloc

After my recent success with ndiswrapper I decided to give it a bash using some Windows x64 drivers I found while trawling the net. It appears to be an official release for Windows x64 labelled "TI 7x21 FlashMedia/SD Host controller driver -Win64", "version 2.0.0.0", "build id FBCRX02W" - but I found no mention of it on their website - download it here.

ndiswrapper -i tifm21.inf
modprobe ndiswrapper

returned:

ndiswrapper (import:239): unknown symbol: ntoskrnl.exe:'ExReleaseFastMutex'
ndiswrapper (import:239): unknown symbol: ntoskrnl.exe:'ExAcquireFastMutex'
ndiswrapper (import:239): unknown symbol: ntoskrnl.exe:'IoUnregisterPlugPlayNotification'
ndiswrapper (import:239): unknown symbol: ntoskrnl.exe:'IoGetDmaAdapter'
ndiswrapper (import:239): unknown symbol: ntoskrnl.exe:'KeLeaveCriticalRegion'
ndiswrapper (import:239): unknown symbol: ntoskrnl.exe:'KeEnterCriticalRegion'
ndiswrapper (import:239): unknown symbol: ntoskrnl.exe:'IoGetDeviceObjectPointer'
ndiswrapper (import:239): unknown symbol: ntoskrnl.exe:'IoRegisterPlugPlayNotification'
ndiswrapper (load_sys_files:218): couldn't prepare driver 'tifm21'
ndiswrapper (load_wrap_driver:112): loadndiswrapper failed (65280); check system log for messages from 'loadndisdriver'

Game Over... It was a long shot anyway...

I have emailed Everest and will try calling them tomorrow, failing that I might try give TI a call, the binary kernel module is labelled as GPL so the source must be available in some form. Other than that I will be keeping an eye on the progress over at tifmxx.berlios.de

One day... maybe it will all just work... Ah yes, just for completeness... Here is a lspci dump:

03:04.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
Subsystem: Hewlett-Packard Company: Unknown device 3085
Flags: bus master, medium devsel, latency 168, IRQ 185
Memory at b0209000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=03, secondary=04, subordinate=07, sec-latency=176
Memory window 0: 30000000-31fff000 (prefetchable)
Memory window 1: 32000000-33fff000
I/O window 0: 0000a400-0000a4ff
I/O window 1: 0000a800-0000a8ff
16-bit legacy interface ports at 0001

03:04.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
Subsystem: Hewlett-Packard Company: Unknown device 3085
Flags: bus master, medium devsel, latency 64, IRQ 10
Memory at b0206000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [44] Power Management version 2

03:04.4 Class 0805: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
Subsystem: Hewlett-Packard Company: Unknown device 3085
Flags: bus master, medium devsel, latency 64, IRQ 10
Memory at b020a000 (32-bit, non-prefetchable) [size=256]
Memory at b0208c00 (32-bit, non-prefetchable) [size=256]
Memory at b0208800 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2

UPDATE: I just got a response from Everest

This is a custom project done for Texas instruments and not open source. Any queries regarding this driver should be addressed to TI.

In my previous post I mentioned that I got the wireless adapter in my Compaq R4100 series laptop working with ndiswrapper. It appears this was a total fluke, others have had to add "noapic" kernel parameters to get it working correctly. I found if I set this kernel parameter the wireless adapter wouldn't work at all; without it everything works normally.

Tested on Fedora Core 4 x86_64 (2.6.11-1.1369, 2.6.14-1.1656, 2.6.15-1.1830 & 2.6.15-1.1831)

lspci output:
03:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
Subsystem: Hewlett-Packard Company: Unknown device 1356
Flags: bus master, fast devsel, latency 64, IRQ 177
Memory at b0204000 (32-bit, non-prefetchable) [size=8K]

grub.conf:
default=0
timeout=5
splashimage=(hd0,1)/boot/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.15-1.1831_FC4)
root (hd0,1)
kernel /boot/vmlinuz-2.6.15-1.1831_FC4 ro root=LABEL=/ rhgb no_timer_check quiet ignore_ff_buttons=PWRF
initrd /boot/initrd-2.6.15-1.1831_FC4.img

The majority of the hardware worked out of the box, the WXGA (1280 x 800) screen needs to be manually frigged into the X configuration. Only the wireless adapter and the memory-card reader are unsupported by the base install.

I got the wireless adapter (Broadcom BCM4318 PCI id 14E4:4318) working using ndiswrapper 1.8 from ndiswrapper.sourceforge.net, it built & installed cleanly into my 64-bit kernel. However, this means you must use 64-bit Windows Device Drivers. Thankfully the List mentions a similar attempt on a HP (HP/Compaq same thing) AMD64 laptop – it works!!

The memory-card reader seems to be harder to get working with mixed reports of success / failure. It appears to be a Texas Instruments PCIxx21, PCI device id 104C:8033 & 104C:8034.

And for my next trick...

Stumbled across this when trying to find out why my 16x DVD media wouldn't burn at anything higher than 4x.

Download your drive's latest firmware, feed it into MediaCodeSpeedEdit and you can edit the burn speeds for all media the drive can recognise.

Save the modified firmware and re-flash your drive with it. Pretty neat!

My only gripe is that the way you do it seems a little odd from the user-interface point of view. You select the media code of your blank discs by name, then double-click it to replace its burn speeds with the speeds of another media code. But hey..... it works!

Related Links

MediaCodeSpeedEdit - http://ala42.cdfreaks.com/MCSE/

I have a generic USB2/IEEE1394 (Firewire) external hard drive enclosure. It is built on the Prolific PL-3507 Hi-Speed USB & IEEE 1394 Combo to IDE Bridge Controller; this is a record of my recent troubles with it.

Currently it house's a Maxtor 6 Y130M0 (120Gb) Hard Drive. I've found it to be totally unreliable over the firewire interface and only just bearable over the USB interface. The enclosure itself isn't by any brand and there is no direct customer support for it. I found the following pages while googling.

http://missig.org/julian/blog/2004/06/10/prolific-pl3507...
http://championable.com/2005/01/avoid-prolific-pl3507-chip...
http://www.hollants.com/external_usb_controller_chips.html
http://www.alexking.org/blog/wp-mobile.php?p=1152&more=1

I followed the general advice and downloaded the firmware and various versions of the Flash Utility from:

http://member.newsguy.com/~siccos/PL3507%20Firmware.htm

Basically none of them worked. I used ROMWriter2.0.4.exe and tried the earliest firmware I found: PL3507-0907B.hex. This would go through "Erasing...", "Writing ROM code...", "Reading code from ROM..." then would fail with "ROM code verification error.". I used this version of the tool to successfully copy the firmware off the chip, then re-write it to the chip without problems. I just cant get newer firmware to work.

Currently the chip is on firmware "2003.06.19.241". I have tried all versions of the Flashing Utility I can find against all versions of the firmware I can find.

Unfortunately this chip appears to be widely used, I was about to buy a replacement enclosure when I found that all of them were using the PL3507 chip.

Next Stop, contacting Prolific

Update: 28th December 2005 - Six months later and Prolific never did reply, in the end I threw away the old enclosure as it was no longer needed. Shame.