[linux-dvb] Linux DVB on Mac PowerPC (Yellow Dog Linux - Freecom USB and DEC2000-t)

Johannes Stezenbach js at linuxtv.org
Mon Dec 12 13:11:21 CET 2005


On Mon, Dec 12, 2005, Tim Hewett wrote:
> Johannes,
> 
> On 10 Dec 2005, at 20:31, Johannes Stezenbach wrote:
> 
> [DEC2000-t problem]
> 
> >>NIP [c0012168] strlen+0x4/0x18
> >>LR [c01609ec] strlcpy+0x24/0x70
> >>Call trace:
> >>[c01ec704] _request_firmware+0xc8/0x37c
> >>[f22dbe6c] ttusb_dec_probe+0x2ac/0xc58 [ttusb_dec]
> >
> >Can't see from the code why it would crash here (provided the  
> >calltrace
> >isn't bogus). You could add a printk() just before the
> >request_firmware() call in ttusb_dec_boot_dsp() to check if the
> >parameters are sane. Or just generally sprinkle some printk()
> >in there to find the reason for the crash.
> 
> Experimentally I removed the calls to le16_to_cpu() in
> ttusb_dec_probe() and it now works, so it was a byte ordering
> issue. It is worrying that the calls to le16_to_cpu() do not resolve
> this automatically, from the name of that function I would imagine
> that it exists to convert between 16 bit little endian into a native
> CPU byte ordered short integer, adapting its behaviour between
> doing nothing and swapping bytes around depending on the
> architecture it was compiled on. The kernel source for
> le16_to_cpu() doesn't appear to differentiate depending on
> architecture so where byte swapping is needed for Intel is it also
> done on PowerPC when it shouldn't be. Many Kernel devices
> also call le16_to_cpu() so quite how Linux manages to run on
> PowerPC at all is a bit of a mystery. Maybe no devices are shared
> with any available for Intel, DVB ones excepted.

le16_to_cpu() does nothing on Intel. But IIRC those le16_to_cpu()
calls were added because of some other PPC user's complaints.

See rev 1.63 in
http://linuxtv.org/cgi-bin/viewcvs.cgi/v4l-dvb/linux/drivers/media/dvb/ttusb-dec/ttusb_dec.c?rev=1.77&root=v4l&view=log

I need to check this. Does someone have a hint for me?

Anyway, I noticed before that the switch() statement lacks a default
label. Of course I thought "it can't happen, because _probe() won't
be called for a wrong id"...

> Now both devices work on Yellow Dog Linux on the PowerPC CPU,
> the Freecom even supports recording multiple channels from the
> same multiplex, the DEC2000 doesn't probably because USB1.1
> isn't fast enough.

Thanks for digging into this.

Johannes



More information about the linux-dvb mailing list