77 replies to this topic

[christophecvr]

p.s. Since the new layout from openembedded to openpli-oe-core

The removal of a package using the git ...bb -c clean and rebuild with git ....bb -f -c build does give strange errors on rebuilding. to really check the good working I'm forced to rebuild freshly from scratch.

Now it's in procces, Is there not an faster way when experimenting then always have to rebuild the full image to test the proper working ? (i always keep workdir)

Somewhere there must be a trick to clean the build register but do not now how in openpli-oe-core

[pieterg]

You changed the name from util smargo . But now there are coming build errors and opkg conflicts again.

which errors do you experience?
The name of the package should not matter (unless I made a typo somewhere)
I just wanted to make it clear the util was built from the oscam sources, so I changed the name of the package.

With extra patch you removed the depends from individual cam's to the .inc That's a bad move as they may need to be treathed differently. Now it's not possible for user who build themself to add a change concerning those settings
depending on version. This was actually a very important setting. And will makes maintenace later on very easy.

libusb was missing as a dependency, so I wanted to add that. And as all 3 variants use the same dependencies, I decided to move them to the include file, to avoid having to duplicate all these variables.
I think as soon as we have to add a different variant, which uses different configure options or dependencies, it's early enough to think of an elegant way to share the same include file.

[christophecvr]

which errors do you experience?
The name of the package should not matter (unless I made a typo somewhere)
I just wanted to make it clear the util was built from the oscam sources, so I changed the name of the package.

Now I'm performing first a fresh build will pass error if they occur again. See my note message about openpli-oe-core strange behaviour when using -b xxxx.bb -c clean and build afterwards.

libusb was missing as a dependency, so I wanted to add that. And as all 3 variants use the same dependencies, I decided to move them to the include file, to avoid having to duplicate all these variables.
I think as soon as we have to add a different variant, which uses different configure options or dependencies, it's early enough to think of an elegant way to share the same include file.

Yes the libusb was missing as depent , but was not needed since oscam does has a statically link to lib usb-1.0. The libusb add will be happy with any libusb even 0.xxxxx . the smartreader protocol needs at least libusb-1.0-xxxxxxxx
Otherwise, whitout libusb-1.0.xxxxxx it will work with default libusb which is still libusb-0.xxxxx . Then You can not use smarteader protocol only mouse and that's using ftdio drive end dev /dev/ttyUSBxx .No speed settings avbl.

Since the base lib usb does not need 1.0 ... They included into the bin with static libusb-1.0 . To change the smartreader module needs to be changed in oscam itself . Then later on we will be able to use libusb-1.0 avbl trough dynamic links and box needs libusb-1.0 installed ass well (in that case )

O and yes the libusb well or not I agree is a mess in so what every project . for oscam it's not a real needed parameter for now. the day it becomes needed it will not be libusb but libusb-1.0 as package. Or ... let's hope that libusb 0.xxx will be gone ... that would simplify things . dreams are dreams .... Hope it will be come reality

Yes for now the three versions are using the same extra settings. I did spent a lot lot time to test it out if that's ok. for now it's ok can change very fast with oscam ........ That's why its actually important to have them separated according to versions's.
and your able to keep stable or unstable like it is, really experiment with experimental. In certain way's experimental needs to be seen as an alpha fase project.

Like you noticed pcsc = set to 0 .

I did test and yes could use pcsc as well. for that I needed to first build the pcsc. The included pcsc bb files needed well to be patched. In orde to use that in a box . That on the other way could disturn other project's using pcsc support on other boxes then dm. entso ...... . Now actually also pcsc is migrating to use libusb-1.0 that would again require al lot of changes ......

I know sometimes we become nut's of all those changes butt ....

Now the build of image is done will come soon with result's about feed builds

[pieterg]

libusb is still a build time dependency, even though there is no runtime dep

[christophecvr]

Ok here results from fresh build , All good no errors (the conflict where there due to the work dir having build packages from my previous not official patch I gues ..., that's why I first restarted from scracth)

The only point now is change back
1) "some" extra oe make depends back to specific version. Like ssl,libusb,pcsc support. That's for this project really needed. to simplify testings on further integration.
2) I know , I did redesign the whole oscam stuff when a started with openpli. It was based on the things made from the first implementer who seemded to be gone for performing patches and updates.
I personnaly did used oscam and compiled it self trough other compile tools already before I used openpli (i was (gemini image user on 7020) and on dream8000 opendreambox with gemini plugin user)
I just wanted to have some kind of basic working oscam setup into the image. That's makes it a bit easier for the newbee starter. Neverthless minimum knowledge about network and linux will always be needed when using this cam.

In the current situation it may be better to remove the ocam-unstable and change the stable into that what's currently called unstable. As the currently called unstable is stable . pffff a bit filosophic ....

That's what we have with such a fast evoluating project. tag 1.10 is stable now only very limited changes are adapted if needed due to coding changes or exeptional discovered bugs. An unstable version is not there anymore the next is experimental , that version is like the name says

[christophecvr]

@pieterg

I just also find out why when I did not put a rev= (whitout an autorev in file) in a uri file for svn package I ended up with error "uknown srcrev error please give version". And why you did it like that that it was not ????

The file meta-openpli/conf/distro/include/openpli-unstable-versions.inc has this autorev setting for the package The hours a lost on this fact .... o yeee

[pieterg]

I moved the rev to openpli-unstable-versions.inc in order to allow the rev to be overloaded externally.
Perhaps you had a typo in the way in which you declared the variable, when you got the error?

[spock]

Nice to see better oscam support, thanks!

I just tried to get my smargo running in smartreader+ protocol on my VU+ Ultimo with oscam, but I keep getting libusb: error -99 when it tries to init the reader. Tried both with device by usbid (004:002 etc.) and with serial. Anyone knows what that's about?

Installed libusb-0.1 and libusb-1.0 manually but the problem remains. Obviously made sure that usbserial and ftdi_sio modules are not loaded. The reader does however work fine in mouse protocol on the VU, also on my pc and router it can run in smartreader protocol fine with oscam.

lsusb on the ultimo also isn't very detailed in it's output, the verbose flag doesn't give any more details in it's output. And list_smargo util is not working, probably due to usbutils lacking verbosity?

Would be nice to get it running in smartreader mode on the VU so I can keep all cards there instead of having to have a separate instance of oscam running on the router!

Edited by spock, 25 June 2012 - 08:48.

[christophecvr]

Nice to see better oscam support, thanks!

I just tried to get my smargo running in smartreader+ protocol on my VU+ Ultimo with oscam, but I keep getting libusb: error -99 when it tries to init the reader. Tried both with device by usbid (004:002 etc.) and with serial. Anyone knows what that's about?

Installed libusb-0.1 and libusb-1.0 manually but the problem remains. Obviously made sure that usbserial and ftdi_sio modules are not loaded. The reader does however work fine in mouse protocol on the VU, also on my pc and router it can run in smartreader protocol fine with oscam.

lsusb on the ultimo also isn't very detailed in it's output, the verbose flag doesn't give any more details in it's output. And list_smargo util is not working, probably due to usbutils lacking verbosity?

Would be nice to get it running in smartreader mode on the VU so I can keep all cards there instead of having to have a separate instance of oscam running on the router!

It's only working on openpli 3.0
You need to install latest versions of oscam .With software manager on box . No need to change somethings to the ftdio_sio drivers. For mouse they must be installed anyway.
There is no need to install libusb manually.

Edited by christophecvr, 25 June 2012 - 10:11.

[spock]

Thanks for the quick reply

I'm running openpli-3.0. smargo is version 1.4.

Here is output of srp_tools (with ftdi_sio loaded since srp_tools uses /dev/ttyUSB0):

root@vuultimo:/media/hdd/smargo# ./srp_tools_mipsel
smartreader+ version v1.4

MODE	autoswitch
FREQ	-nan Mhz
KERNEL  normal
T_MODE  t = 0
EGT	 0

And this is what shows in oscam (debug 65535, also here usbserial and ftdi_sio is unloaded):

2012/06/25 12:43:08 5B3CE8 h restarting reader smargo
2012/06/25 12:43:08 5B3CE8 h creating thread for device 004:002
2012/06/25 12:43:08 5B3CE8 h start reader thread action 8
2012/06/25 12:43:08 77208460 r data from add_job action=8 client r smargo
2012/06/25 12:43:08 77208460 r IFD: Opening device 004:002
2012/06/25 12:43:08 77208460 r IO:SR: Looking for device 002 on bus 004
2012/06/25 12:43:08 77208460 r Libusb init error : -99
2012/06/25 12:43:08 77208460 r ERROR, function call SR_Init(reader) returns error.
2012/06/25 12:43:08 77208460 r Cannot open device: 004:002

lsusb and list_smargo:

root@vuultimo:/media/hdd/smargo# lsusb -vvv
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 003 Device 001: ID 1d6b:0001
Bus 004 Device 001: ID 1d6b:0001
Bus 004 Device 002: ID 0403:6001
root@vuultimo:/media/hdd/smargo# list_smargo
root@vuultimo:/media/hdd/smargo#

It's a bit weird isn't it? It really should work

edit: oscam is latest from openpli-3.0 feed, currently #7069

Edited by spock, 25 June 2012 - 10:48.

[christophecvr]

Yes its' correct that the ftdi acces is unloaded for your smargo up on start off oscam. That automatic only for the device in Your case I can see 004:002 that is correct.

root@dm8000pli:~# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 003 Device 001: ID 1d6b:0001
Bus 004 Device 001: ID 1d6b:0001
Bus 001 Device 002: ID 04cc:1520
Bus 001 Device 003: ID 0781:5406
Bus 001 Device 004: ID 0403:6001
root@dm8000pli:~# list_smargo
Looking for smartreader with an out endpoint = 0x82 :
bus 001, device 004 : 0403:6001 Smartreader (Device=001:004 EndPoint=0x82 insert in oscam.server 'Device = Serial:Smart 15')
root@dm8000pli:~#

That's the output on dreambox dm8000 openpli.

First off all I think You best reflash The box with the latest openpli 3.0
There where some changes lately with serial devices drivers and so on, the normal updates did caused bug's. It was alpha at begin stage .

Do not interfere with manual installing things. Do not change settings.

[spock]

I just tried this on my usb-modded dm500hd. And there it works fine!

root@dm500hd:~# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 003 Device 001: ID 1d6b:0001
Bus 004 Device 001: ID 1d6b:0001
Bus 001 Device 002: ID 058f:6387
Bus 003 Device 002: ID 0403:6001
root@dm500hd:~# list_smargo
Looking for smartreader with an out endpoint = 0x82 :
bus 003, device 002 : 0403:6001 Smartreader (Device=003:002 EndPoint=0x82 insert in oscam.server 'Device = Serial:Reader 152')
root@dm500hd:~#

2012/06/25 13:47:14 77400468 h restarting reader smargo
2012/06/25 13:47:14 77400468 h creating thread for device Serial:Reader 152
2012/06/25 13:47:14 77416310 r Using 0x82 as endpoint for smartreader hardware detection
2012/06/25 13:47:14 77416310 r Found reader with serial Reader 152 at 003:002
2012/06/25 13:47:14 77416310 r Found smartreader device Serial:Reader 152
2012/06/25 13:47:15 77416310 r reader smargo initialized (device=Serial:Reader 152, detect=cd, mhz=480, cardmhz=480)
2012/06/25 13:47:15 77416310 r smargo card detected
2012/06/25 13:47:18 77416310 r ATR: 3F 77 18 00 00 C2 7A 42 02 68 90 00

I will try to reflash the ultimo and report back.

[spock]

Reflashed but no luck on the ultimo. Tried both with device = 004:002 and the serial that list_smargo showed on my dm500hd.

Must be something preventing this from working on the vuplus/ultimo builds.

2012/06/25 13:03:11 77300468 h restarting reader smargo
2012/06/25 13:03:11 77300468 h creating thread for device Serial:Reader 152
2012/06/25 13:03:11 77313D10 r Libusb init error : -99
2012/06/25 13:03:11 77313D10 r Cannot open device: Serial:Reader 152

Isnt it strange that with no smargo connected, the dm500hd shows this output from list_smargo: "Looking for smartreader with an out endpoint = 0x82 :"
And on the ultimo there is no output at all from list_smargo, either with the smargo connected or not.

Edited by spock, 25 June 2012 - 12:06.

[christophecvr]

Yes the looking up for device with endpoint 0x82 is correct.

But the dm500 which kernel does it use ? kernel must be above 2.6.32 . If dm uses kernel 3.2 ok if not it will not work.

for the vu I don't know. If kernel high enough it should work. (i can't test it)

There seems to be something wrong with your smargo as well . Some 1.4 revisions did contained a bug, others where ok.
All my smargo's are at 1.7 now. kan only be done with argolis utils on windows xp or windows 7. For xp the ftdio drivers needs first to be uninstalled and replaced by the latest stable avbl for windows. did not happened by me with microsoft updates. For windows 7 if ftdio drivers are installed it's ok.

When using device = Serial:Reader 152 , oscam can't find the device by first attempt. It does always luch a second attempt one minute later and then it works. That's a curious issue.

2012/06/25 13:01:57   5E3528 r Using 0x82 as endpoint for smartreader hardware detection
2012/06/25 13:01:58   5E3528 r Smartreader device Serial:Smart 15 not found
2012/06/25 13:01:58   5E3528 r Cannot open device: Serial:Smart 15
2012/06/25 13:02:58   5E3528 r Using 0x82 as endpoint for smartreader hardware detection
2012/06/25 13:02:58   5E3528 r Found reader with serial Smart 15 at 001:003
2012/06/25 13:02:58   5E3528 r Found smartreader device Serial:Smart 15
2012/06/25 13:02:58   5E3528 r reader usbsmart15 initialized (device=Serial:Smart 15, detect=cd, mhz=600, cardmhz=600)
2012/06/25 13:02:59   5E3528 r usbsmart15 card detected
2012/06/25 13:03:00   5E3528 r ATR: 3B F7 11 00 01 40 96 70 70 0A 0E 6C B6 D6

Note the minute between attempt one and two . If You wait one minute is very long -

[spock]

The dm500hd has kernel 3.2, also openpli-3.0_20120625

root@dm500hd:~# uname -a
Linux dm500hd 3.2-dm500hd #1 SMP Sat Jun 16 21:37:02 CEST 2012 mips GNU/Linux

Ultimo runs kernel 3.1.1, openpli-3.0_20120625

root@vuultimo:~# uname -a
Linux vuultimo 3.1.1 #1 SMP Mon Jun 25 04:39:50 CEST 2012 mips GNU/Linux

The smargo unit works fine both on my router with openwrt/mipsel (kernel 3.3.8) and on my Linux PC (archlinux, kernel 3.4).

Seems like there is something wrong in the vuplus/ultimo openpli build, doesn't it?

Edited by spock, 25 June 2012 - 12:34.

[christophecvr]

Yes since it work's ok on dm500hd the reader is ok.

for the ultimo, If the list_smargo does not work there is something wrong with the build, i don't know what's wrong.

[spock]

Hopefully oscam devs can shed some light on this, or tell me if I can provide more information to help debug this.

[christophecvr]

try for once just to replace the binary oscam-experimental on the vu duo by that which is installed on 500hd (if vu do is mipsel it may work)

[spock]

try for once just to replace the binary oscam-experimental on the vu duo by that which is installed on 500hd (if vu do is mipsel it may work)

tried this but no luck. also file size was the same for both binaries so I think they were already the same binary.

[christophecvr]

is your machine vuduo or vuultimo ??