[linux-dvb] siano firmware and behaviour after resuming power

[linux-dvb] siano firmware and behaviour after resuming power

[Luca Olivetti]

[Since linux-media silently discards my email --leaving through the 
stray viagra message anyway, yay-- I'm trying the old list and I hope 
that someone sees it. What bother me most is the need to unplug and 
replug the device when I power off the pc]

I just got a dvb-t usb stick from dealextreme.
The dealextreme lottery gave me a siano sms1xxx based device, usb id
187f:0201.
In the latest mercurial repository, this device requires the firmware
dvb_nova_12mhz_b0.inp but it's nowhere to be found.
I found some forum posting suggesting to use
http://www.steventoth.net/linux/sms1xxx/sms1xxx-hcw-55xxx-dvbt-01.fw
(renaming it to the name required by the driver), and I did and it worked.
Then, out of curiosity, I also tried the 03 revision
http://www.steventoth.net/linux/sms1xxx/sms1xxx-hcw-55xxx-dvbt-03.fw and
it also worked.
Since these firmwares are for hauppauge devices, I wonder if using them
will have some undesirable side-effect or there's no problem.


Oh, when I turn off the pc the stick is attached to (a vdr machine), it
still supplies 5v to the usb ports, and when I turn it on again the
stick fails. I have to unplug and replug it to make it work.
These are the messages in syslog:

Nov  1 13:57:19 vdr.ventoso.local kernel: smscore_detect_mode: line:
755: MSG_SMS_GET_VERSION_EX_REQ failed first try
Nov  1 13:57:24 vdr.ventoso.local kernel: smscore_set_device_mode: line:
829: mode detect failed -62
Nov  1 13:57:24 vdr.ventoso.local kernel: smsusb_init_device: line: 387:
smscore_start_device(...) failed
Nov  1 13:57:24 vdr.ventoso.local kernel: smsusb_onresponse: line: 120:
error, urb status -2, 0 bytes
Nov  1 13:57:24 vdr.ventoso.local last message repeated 9 times
Nov  1 13:57:24 vdr.ventoso.local kernel: sms_ir_exit:
Nov  1 13:57:24 vdr.ventoso.local kernel: smsusb: probe of 3-2:1.0
failed with error -62
Nov  1 13:57:24 vdr.ventoso.local kernel: usbcore: registered new driver
smsusb


I tried to unload the modules before switching off, followed by a usb 
reset, but without great success.

Bye
-- 
Luca






_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] siano firmware and behaviour after resuming power

[BOUWSMA Barry]

Sorry for not composing this reply sooner...

On Tue, 1 Dec 2009, Luca Olivetti wrote:

> [Since linux-media silently discards my email --leaving through the stray
> viagra message anyway, yay-- I'm trying the old list and I hope that someone

And as linux-media hijacks the Reply-To: header so that my mailer
won't send you a copy without uncomfortable gymnastics, I have to
ignore it in order to make sure that you, or anyone else, actually
gets a reply even if you've promptly `UNSUSCIRBE'd upon receiving
that chastising bounce.

Similarly, as I'm not subscribed to linux-media, please include
me in any replies that you want me to see immediately, lest I
overlook them in the flood of developer mails there -- though
since you can't post there, you'll probably have to keep your
replies here.  So this is meant for anyone who pipes up but
does what is wanted by moving the conversation elsewhere.




> The dealextreme lottery gave me a siano sms1xxx based device, usb id
> 187f:0201.
> In the latest mercurial repository, this device requires the firmware
> dvb_nova_12mhz_b0.inp but it's nowhere to be found.

I have the following in a source directory:

ls -lart  /home/beer/src/siano/firmware/
total 428
-rw-rw-r-- 1 beer besoffen 84164 2008-12-31 16:22 isdbt_nova_12mhz_b0.inp
-rw-rw-r-- 1 beer besoffen 71428 2008-12-31 16:22 tdmb_nova_12mhz_b0.inp
-rw-rw-r-- 1 beer besoffen 93624 2008-12-31 16:22 dvb_nova_12mhz_b0.inp
-rw-rw-r-- 1 beer besoffen 38428 2008-12-31 16:26 tdmb_stellar_usb_12mhz_downld.inp
-rw-rw-r-- 1 beer besoffen 38720 2008-12-31 16:26 tdmb_stellar_usb_12mhz_eeprom_a2.brn
-rw-rw-r-- 1 beer besoffen 40348 2008-12-31 16:28 dvbh_stellar_usb_12mhz_downld.inp
-rw-rw-r-- 1 beer besoffen 39676 2008-12-31 16:28 dvbt_stellar_usb_12mhz_downld.inp

This is from a URL provided by Siano in the archives of this list
which can probably be found by searching for keywords like DAB
or their host library.

Interestingly, in this older kernel which I use, I have the
firmware to be loaded

-r-xr-xr-x  1 beer drunkards  40096 2007-05-17 14:38 tdmb_stellar_usb.inp

which does not correspond in size to the above, so I can't
remember how I got it without finding an older system disk
from which I copied this -- on which the other non-DAB/DMB
mode firmwares would be found for size/checksum comparisons.
Presumably this was from the accompanying CD-ROM, wherever
that might be these days -- wait, I should be able to dig a
second one from the packaging if I can find that, should you
be particularly interested.


In my source code at hand I find
        { USB_DEVICE(0x187f, 0x0201),
                .driver_info = SMS1XXX_BOARD_SIANO_NOVA_B },
for your device (capable of more than mine) and the corresponding
firmware named as
        [SMS1XXX_BOARD_SIANO_NOVA_B] = {
                .name   = "Siano Nova B Digital Receiver",
                .type   = SMS_NOVA_B0,
                .fw[DEVICE_MODE_DVBT_BDA] = "sms1xxx-nova-b-dvbt-01.fw",
        },


Within another file I see some alternative names for the
firmwares for my `stellar' device; in your case of a `nova'
product a table can be found in the source file smscoreapi.c:

static char *smscore_fw_lkup[][SMS_NUM_OF_DEVICE_TYPES] = {
        /*Stellar               NOVA A0         Nova B0         VEGA*/
        /*DVBT*/
        {"none", "dvb_nova_12mhz.inp", "dvb_nova_12mhz_b0.inp", "none"},
        /*DVBH*/
        {"none", "dvb_nova_12mhz.inp", "dvb_nova_12mhz_b0.inp", "none"},
        /*TDMB*/
        {"none", "tdmb_nova_12mhz.inp", "none", "none"},
        /*DABIP*/
        {"none", "none", "none", "none"},
        /*BDA*/
        {"none", "dvb_nova_12mhz.inp", "dvb_nova_12mhz_b0.inp", "none"},
        /*ISDBT*/
        {"none", "isdbt_nova_12mhz.inp", "dvb_nova_12mhz.inp", "none"},
        /*ISDBTBDA*/
        {"none", "isdbt_nova_12mhz.inp", "isdbt_nova_12mhz_b0.inp", "none"},
        /*CMMB*/
        {"none", "none", "none", "cmmb_vega_12mhz.inp"}
};


Looks like your device isn't capable of DAB/DAB+/DMB, and
I'm puzzled to see the difference in firmwares between the
ISDBT modes, but I'm unfamiliar with that operation.




> I found some forum posting suggesting to use
> http://www.steventoth.net/linux/sms1xxx/sms1xxx-hcw-55xxx-dvbt-01.fw
> (renaming it to the name required by the driver), and I did and it worked.
> Then, out of curiosity, I also tried the 03 revision
> http://www.steventoth.net/linux/sms1xxx/sms1xxx-hcw-55xxx-dvbt-03.fw and
> it also worked.
> Since these firmwares are for hauppauge devices, I wonder if using them
> will have some undesirable side-effect or there's no problem.

In looking at the sms-cards.c source file, these Hauppauge
rebrandings seem to be a change of the USB IDs, but the
same firmwares are listed as are used by the Siano-sourced
devices.

In other words, there shouldn't be a problem, and they may well
be identical.  However, to set your mind at ease, I'd have to
dig out my other copy of the firmwares to list file sizes and
md5sums in order that you can see whether they match.



> Oh, when I turn off the pc the stick is attached to (a vdr machine), it
> still supplies 5v to the usb ports, and when I turn it on again the
> stick fails. I have to unplug and replug it to make it work.

As I managed to kill off my workstation, more than once, I
see the same problem with other USB devices that get power
through other means.  I'd be inclined to believe this may be
a problem in the USB stack, where it's not issuing a proper
reset to restore the devices -- if this is possible with
power supplied.

Specifically, with one USB WLAN stick which receives external
power, I have to re-plug it if I've brought it up to load
the firmware.  The other two USB WLAN sticks, one of similar
type and one somewhat different but also similar, are the
same, though they're powered from the machine -- after a cold
boot, they work fine; after a warm reboot if they've loaded
the firmware, they fail to respond properly to the attempt
to firmware load or possibly to enumerate -- I'd have to
actually reboot again to see where.

I can't remember if the Siano USB device is the same way.
For two other USB-attached DVB devices, one of which requires
firmware loading, the other which doesn't, but both of which
have their own power supplies, there's no problem.

Another device which seems to have this problem is one external
hard drive, which I've had to power externally, and it seems
that after these reboots or crashes, it fails to get back to
a useful state without replugging and reset.  Another drive
is fine, but may be getting its power switched by a USB hub.


Those are just my observations -- as to whether this is a
more general USB stack problem, or whether each driver for
all these devices needs to be rewritten to handle this case
of a device in a warm state, I don't know as I'm unfamiliar
with the internal workings of USB or the devices.  But this
seems to be a common enough problem, particularly annoying
with my USB WLAN sticks, that it should be tackled -- either
a complete power cycle or re-plug cycle is needed after a
normal reboot, which is painful.  Particularly if done
remotely.



> _______________________________________________
> linux-dvb users mailing list
> For V4L/DVB development, please use instead linux-media@vger.kernel.org


thanks,
barry bouwsma

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] siano firmware and behaviour after resuming power

[Luca Olivetti]

En/na BOUWSMA Barry ha escrit:
> Sorry for not composing this reply sooner...

Thank you for replying, no need to be sorry, I've been trying to send 
the message for ~1 month, so I'm not really in a hurry ;-)

> 
> I have the following in a source directory:
> 
> ls -lart  /home/beer/src/siano/firmware/
> total 428
> -rw-rw-r-- 1 beer besoffen 84164 2008-12-31 16:22 isdbt_nova_12mhz_b0.inp
> -rw-rw-r-- 1 beer besoffen 71428 2008-12-31 16:22 tdmb_nova_12mhz_b0.inp
> -rw-rw-r-- 1 beer besoffen 93624 2008-12-31 16:22 dvb_nova_12mhz_b0.inp
> -rw-rw-r-- 1 beer besoffen 38428 2008-12-31 16:26 tdmb_stellar_usb_12mhz_downld.inp
> -rw-rw-r-- 1 beer besoffen 38720 2008-12-31 16:26 tdmb_stellar_usb_12mhz_eeprom_a2.brn
> -rw-rw-r-- 1 beer besoffen 40348 2008-12-31 16:28 dvbh_stellar_usb_12mhz_downld.inp
> -rw-rw-r-- 1 beer besoffen 39676 2008-12-31 16:28 dvbt_stellar_usb_12mhz_downld.inp
> 
> This is from a URL provided by Siano in the archives of this list
> which can probably be found by searching for keywords like DAB
> or their host library.

Ah, ok, I got my sources from linuxtv and there's no firmware there.
In fact, one of the search results for "siano firmware" was a message 
from Mauro asking Uri (who doesn't work for siano any more) for 
permission to distribute the firmware, with no follow-ups.

> 
> In looking at the sms-cards.c source file, these Hauppauge
> rebrandings seem to be a change of the USB IDs, but the
> same firmwares are listed as are used by the Siano-sourced
> devices.
> 
> In other words, there shouldn't be a problem, and they may well
> be identical.  However, to set your mind at ease, I'd have to
> dig out my other copy of the firmwares to list file sizes and
> md5sums in order that you can see whether they match.

Don't worry, there's been no harm to the device (though it hasn't seen 
too much use).

> 
> 
> 
>> Oh, when I turn off the pc the stick is attached to (a vdr machine), it
>> still supplies 5v to the usb ports, and when I turn it on again the
>> stick fails. I have to unplug and replug it to make it work.
> 
> As I managed to kill off my workstation, more than once, I
> see the same problem with other USB devices that get power
> through other means.  I'd be inclined to believe this may be
> a problem in the USB stack, where it's not issuing a proper
> reset to restore the devices -- if this is possible with
> power supplied.

I found a something here

http://marc.info/?l=linux-usb-users&m=116827193506484&w=2

that purportedly resets an usb device.
What I tried was, before powering off:

1) unload the drivers
2) use the above to reset the stick
3) power off

and, before loading the drivers, issue a reset again.
Sometimes it works, sometimes it doesn't, the end result is that I 
cannot leave the device plugged-in if I want to use it.
Not to mention the annoying blue led constantly on :-D


> Those are just my observations -- as to whether this is a
> more general USB stack problem, or whether each driver for
> all these devices needs to be rewritten to handle this case
> of a device in a warm state, I don't know as I'm unfamiliar
> with the internal workings of USB or the devices.  But this
> seems to be a common enough problem, particularly annoying
> with my USB WLAN sticks, that it should be tackled -- either
> a complete power cycle or re-plug cycle is needed after a
> normal reboot, which is painful.  Particularly if done
> remotely.

Oh, it's a pain even if done locally, though you could say that doing it 
from the couch is actually doing it remotely ;-)

Thank you for your time.

Bye
-- 
Luca

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] siano firmware and behaviour after resuming power

[BOUWSMA Barry]

On Thu, 3 Dec 2009, Luca Olivetti wrote:

> > This is from a URL provided by Siano in the archives of this list
> > which can probably be found by searching for keywords like DAB
> > or their host library.
> 
> Ah, ok, I got my sources from linuxtv and there's no firmware there.
> In fact, one of the search results for "siano firmware" was a message from
> Mauro asking Uri (who doesn't work for siano any more) for permission to
> distribute the firmware, with no follow-ups.

Oh, in case it would be helpful (meaning that either the previous,
now snipped, filesizes would match your firmware, or these which
I quote now match), here's what I dug out of the musty depths of
the machine hidden away -- these are likely to be the files for
the firmware as extracted from the CD-ROM that came with my 
device, if not downloaded elsewhere, based on the timestamps.

[13:00:05]beer@charlie:/tmp$ ls -lart /tmp/server/usr/lib/hotplug/firmware/
total 928
-r-xr-xr-x 1 beer besoffen  40324 2007-03-21 21:48 dvbh_stellar_usb.inp
-r-xr-xr-x 1 beer besoffen  38144 2007-05-17 14:35 dvbt_stellar_usb.inp
-r-xr-xr-x 1 beer besoffen  38144 2007-05-17 14:35 dvbt_bda_stellar_usb.inp
-r-xr-xr-x 1 beer besoffen  40096 2007-05-17 14:38 tdmb_stellar_usb.inp

Sorry I only saved those corresponding to my device.  As you can
see, the file sizes differ between the two sources, but perhaps
you can match them against the tarballs from Steven Toth, to
determine whether your firmware is the same as either of these
manufacturer- or vendor-supplied sources.

This is all going from memory, but if it helps set your mind at
ease, then I'm happy to help.



> > As I managed to kill off my workstation, more than once, I
> > see the same problem with other USB devices that get power
> > through other means.  I'd be inclined to believe this may be
> > a problem in the USB stack, where it's not issuing a proper
> > reset to restore the devices -- if this is possible with
> > power supplied.
> 
> I found a something here
> 
> http://marc.info/?l=linux-usb-users&m=116827193506484&w=2
> 
> that purportedly resets an usb device.
> What I tried was, before powering off:
> 
> 1) unload the drivers
> 2) use the above to reset the stick
> 3) power off
> 
> and, before loading the drivers, issue a reset again.
> Sometimes it works, sometimes it doesn't, the end result is that I cannot
> leave the device plugged-in if I want to use it.

That might work for a planned reboot -- my reboots are 
occasionally unplanned, and the devices are in part hanging
at boot time.  I guess if I had had the patience to watch and
see if the wait eventually timed out, I could test just how
the system came up and reset anything not present (and then
configure it as needed). Too much work for a non-critical
system, when I'd rather it Just Work.

I am lazy.  So sue me  :-)


barry bouwsma

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] siano firmware and behaviour after resuming power

[Luca Olivetti]

En/na BOUWSMA Barry ha escrit:

>> I found a something here
>>
>> http://marc.info/?l=linux-usb-users&m=116827193506484&w=2
>>
>> that purportedly resets an usb device.
>> What I tried was, before powering off:
>>
>> 1) unload the drivers
>> 2) use the above to reset the stick
>> 3) power off
>>
>> and, before loading the drivers, issue a reset again.
>> Sometimes it works, sometimes it doesn't, the end result is that I cannot
>> leave the device plugged-in if I want to use it.
> 
> That might work for a planned reboot 

This being a vdr machine, the reboot is either planned or due to a power 
loss, and I suppose that the latter would really reset the device, but I 
didn't try.
The problem is that even so (planned reboot/switch off) it only works 
sometimes.


> -- my reboots are 
> occasionally unplanned, and the devices are in part hanging
> at boot time.  I guess if I had had the patience to watch and
> see if the wait eventually timed out, I could test just how
> the system came up and reset anything not present (and then
> configure it as needed). Too much work for a non-critical
> system, when I'd rather it Just Work.
> 
> I am lazy.  So sue me  :-)

As I'm getting older, I'm also getting lazier, so I'm not going to sue 
you ;-)

Bye
-- 
Luca

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] siano firmware and behaviour after resuming power

[Mauro Carvalho Chehab]

Em Thu, 03 Dec 2009 09:53:21 +0100
Luca Olivetti <luca@ventoso.org> escreveu:

> Ah, ok, I got my sources from linuxtv and there's no firmware there.
> In fact, one of the search results for "siano firmware" was a message 
> from Mauro asking Uri (who doesn't work for siano any more) for 
> permission to distribute the firmware, with no follow-ups.

Yes. I also tried with Udi, without success so far. It would be really
wonderful if Siano could get binary distribution rights for the firmware.

Cheers,
Mauro.



Cheers,
Mauro

Re: [linux-dvb] siano firmware and behaviour after resuming power

[Rodd Clarkson]

On Thu, 2009-12-03 at 14:38 +0100, Luca Olivetti wrote:
> En/na BOUWSMA Barry ha escrit:
> 
> >> I found a something here
> >>
> >> http://marc.info/?l=linux-usb-users&m=116827193506484&w=2
> >>
> >> that purportedly resets an usb device.
> >> What I tried was, before powering off:
> >>
> >> 1) unload the drivers
> >> 2) use the above to reset the stick
> >> 3) power off
> >>
> >> and, before loading the drivers, issue a reset again.
> >> Sometimes it works, sometimes it doesn't, the end result is that I cannot
> >> leave the device plugged-in if I want to use it.

I've also got a siano card, but in my case it's embedded in my Dell
laptop, so yanking it out and plugging it back in isn't even an option.

The card is however a USB device and I've included the lsusb -v output
at the end in case it's useful.

I've tried the firmware you're referring too, but there's also a request
for sms1xxx-nova-b-dvbt-01.fw in the dmesg and this is asked for first
(in my case), with a siano supplied one sought if it can't find this
first one.

I'm not having problems with cold restarts, but suspend/hibernate sees
the things go bad on resume.

I've added some stuff to /etc/pm/sleep.d which unloads the modules and
then reloads then on resume.  It's a simple script:

#!/bin/bash
case $1 in
 hibernate)
  echo "Suspending to disk"
  modprobe -r smsdvb
  modprobe -r smsusb
 ;;
 suspend)
  echo "Suspending to RAM"
  modprobe -r smsdvb
  modprobe -r smsusb
 ;;
 thaw)
  echo "Suspend to disk is over, Resuming..."
  modprobe smsdvb
  modprobe smsusb
 ;;
 resume)
  echo "Suspend to RAM is over, Resuming..."
  modprobe smsdvb
  modprobe smsusb
 ;;     
 *)     
  echo "somebody is calling me totally wrong."
 ;;     
esac

This addresses these problems for me.  You might be able to add
something similar to /etc/pm/power.d to unload modules to address the
problem.


Rodd



Bus 001 Device 003: ID 2040:1801 Hauppauge 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x2040 Hauppauge
  idProduct          0x1801 
  bcdDevice            0.01
  iManufacturer           1 Hauppauge Computer Works
  iProduct                2 WinTV-NOVA
  iSerial                 3 f05eb5ec
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)