Any reason to keep the sg drivers
Uwe Bonnes
is there any reason to keep stlink-sg?
stlink-usb can construct the scsi wrapper and I have tested with
several disvcovery boards
Using kernel sg
- is slow with startup and clutters the log
- means useless code duplication
- is harder to port then a pure libusb application
Any opinions?
Karl P
There is no -sg driver anymore.
stlink-sg.c uses libusb (and libusb _only_) to construct scsi mass storage
commands as appropriate for stlink v1. stlink-usb.c uses libusb to construct the
messages for stlink v2. The messages are different, though the naming is no
longer accurate.
Yes, there's plenty of room for duplication between the two to be removed. Lots
of the usb related code in -sg.c should be and could be extract up into
-common.c It hasn't been real high on my personal list of things to do right
now, I've been more concerned with actually _using_ my stm32 boards :)
as for "slow to startup cluttering the logs" that's simply unavoidable, _until_
you put in the modprobe rules on linux, which tells the kernel to flatly ignore
the device. This is the bit that hasn't been done for OSX. I don't have OSX,
so I'm not working on it, but after I removed the sg-utils deps, this should be
all that's needed for stlinkv1 on OSX.
It's already working on windows, though that code is in a branch that hasn't
been merged. https://github.com/burjui/stlink
Cheers,
Karl P
Uwe Bonnes
Karl> There is no -sg driver anymore.
Karl> stlink-sg.c uses libusb (and libusb _only_) to construct scsi mass
Karl> storage commands as appropriate for stlink v1. stlink-usb.c uses
Karl> libusb to construct the messages for stlink v2. The messages are
Karl> different, though the naming is no longer accurate.
No, the messages are the same, so some functionality is not implemented in
V1.
At some point in time, I had a STLINKV1
running with libusb. With the USB PID, the type is known and everything can
be done according. Some comments like
// TODO - never used at the moment, always CMD_SIZE
show where things need to be restored. I will work with an stl32l_discovery
in the next time, which has a V1, and will try it with stlink-usb.c. If it
works, I will remove stlink-sg.c.
Karl> Yes, there's plenty of room for duplication between the two to be
Karl> removed. Lots of the usb related code in -sg.c should be and could
Karl> be extract up into -common.c It hasn't been real high on my
Karl> personal list of things to do right now, I've been more concerned
Karl> with actually _using_ my stm32 boards :)
Could you please test my github fork? I have a F107 board where I used the
WFI (wait for interrupt) command to go into sleep mode and things didn't
work any longer. The fork works for me now.
Karl> as for "slow to startup cluttering the logs" that's simply
Karl> unavoidable, _until_ you put in the modprobe rules on linux, which
Karl> tells the kernel to flatly ignore the device.
stlink_v1.modprobe.conf in master still only tells :
options usb-storage quirks=483:3744:i
which will clutter the log and take ages.
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="0483",
ATTRS{idProduct}=="3744", DRIVER=="usb-storage", RUN+="/bin/sh -c 'echo -n
%k> %S%p/driver/unbind'"
tells the kernel to ignore the device.
Karl> This is the bit
Karl> that hasn't been done for OSX. I don't have OSX, so I'm not
Karl> working on it, but after I removed the sg-utils deps, this should
Karl> be all that's needed for stlinkv1 on OSX.
Karl> It's already working on windows, though that code is in a branch
Karl> that hasn't been merged. https://github.com/burjui/stlink
Bye
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes
>>>>> "Karl" == Karl P <ka...@tweak.net.au> writes:
Karl> There is no -sg driver anymore.
Karl> stlink-sg.c uses libusb (and libusb _only_) to construct scsi mass
Karl> storage commands as appropriate for stlink v1. stlink-usb.c uses
Karl> libusb to construct the messages for stlink v2. The messages are
Karl> different, though the naming is no longer accurate.
Uwe> No, the messages are the same, so some functionality is not
Uwe> implemented in V1. At some point in time, I had a STLINKV1 running
Uwe> with libusb.
^^^^^^
Sould read "stlink-usb.c"
Karl P
On 12/13/2011 08:05 PM, Uwe Bonnes wrote:
>>>>>> "Karl" == Karl P<ka...@tweak.net.au> writes:
>
> Karl> There is no -sg driver anymore.
>
> Karl> stlink-sg.c uses libusb (and libusb _only_) to construct scsi mass
> Karl> storage commands as appropriate for stlink v1. stlink-usb.c uses
> Karl> libusb to construct the messages for stlink v2. The messages are
> Karl> different, though the naming is no longer accurate.
>
> No, the messages are the same, so some functionality is not implemented in
> V1.
They're really not. For the VL, (STlinkv1) they _need_ to be prefixed with the
SG- style commands.
> At some point in time, I had a STLINKV1
> running with libusb. With the USB PID, the type is known and everything can
> be done according. Some comments like
> // TODO - never used at the moment, always CMD_SIZE
> show where things need to be restored. I will work with an stl32l_discovery
> in the next time, which has a V1, and will try it with stlink-usb.c. If it
> works, I will remove stlink-sg.c.
The 32L board has an stlink v2, so yes, of course it works with stlink-usb.c.
stlink-sg.c is only needed for the stlinkv1 as found on the original dongle, and
on the VL discovery board.
>
> Karl> Yes, there's plenty of room for duplication between the two to be
> Karl> removed. Lots of the usb related code in -sg.c should be and could
> Karl> be extract up into -common.c It hasn't been real high on my
> Karl> personal list of things to do right now, I've been more concerned
> Karl> with actually _using_ my stm32 boards :)
>
> Could you please test my github fork? I have a F107 board where I used the
> WFI (wait for interrupt) command to go into sleep mode and things didn't
> work any longer. The fork works for me now.
At some stage, but I'm trying pretty hard to not spend time on things that
aren't getting in my way. I spent a lot of time trying to put things together,
and a lot of time support and testing things with people on IRC. I _know_ there
are still problems where things lock up. I've even seen people talk about
similar problems using stlink hardware on windows with other tools though...
>
> Karl> as for "slow to startup cluttering the logs" that's simply
> Karl> unavoidable, _until_ you put in the modprobe rules on linux, which
> Karl> tells the kernel to flatly ignore the device.
>
> stlink_v1.modprobe.conf in master still only tells :
> options usb-storage quirks=483:3744:i
> which will clutter the log and take ages.
>
> SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="0483",
> ATTRS{idProduct}=="3744", DRIVER=="usb-storage", RUN+="/bin/sh -c 'echo -n
> %k> %S%p/driver/unbind'"
>
> tells the kernel to ignore the device.
>
Seriously? You've done something wrong with the modprobe file...
Dec 13 20:14:42 tera kernel: [ 4451.300886] usb 1-4.1: new full speed USB device
using ehci_hcd and address 9
Dec 13 20:14:42 tera kernel: [ 4451.416402] usb 1-4.1: configuration #1 chosen
from 1 choice
Dec 13 20:14:42 tera kernel: [ 4451.416982] usb-storage 1-4.1:1.0: Quirks match
for vid 0483 pid 3744: 800
Dec 13 20:14:42 tera kernel: [ 4451.416989] usb-storage: device ignored
That's ALL I get on plugging a 32VL discovery, stlinkv1 device into my machine.
If that udev rule works too, that's cool, but personally I'd rather just tell
it to never register, rather than register, then unbind.
Cheers,
Karl P
Uwe Bonnes
...
Karl> libusb to construct the messages for stlink v2. The messages are
Karl> different, though the naming is no longer accurate.
>> No, the messages are the same, so some functionality is not
>> implemented in V1.
Karl> They're really not. For the VL, (STlinkv1) they _need_ to be
Karl> prefixed with the SG- style commands.
Yes, but the prefixing can easily be done in stlink-usb.
...
Karl> Seriously? You've done something wrong with the modprobe file...
I will try again.