173 replies to this topic

[SpaceRat]

Is it possible to apply the 120 second restriction only if time sync is set to use transponder time?

It is.
See my answer on OpenViX forum.

Gesendet von meinem SM-N910F mit Tapatalk

[birdman]

 

If "init 4" doesn't work, than means it is not code in Enigma that refuses the clock change. Interesting...

If you're using ntp instead of ntpdate, ntp will not adjust the clock immediately but it will gradually adjust it, over a large timespan. That's not what you want in this case.

 

The usual way to run an ntpd is to run ntpdate once at boot time to set the time, then run ntpd to keep it accurate.

 

The ntpdate-sync script (in OpenVix at least) is slightly weird in that it appears to do a one-off correction if you are bringing up a static IP address, but (somehow) attempts to slew the clock (so that it drifts towards correctness at some future time) if it is a DHCP one.

[SpaceRat]

The ntpdate-sync script (in OpenVix at least) is slightly weird in that it appears to do a one-off correction if you are bringing up a static IP address, but (somehow) attempts to slew the clock (so that it drifts towards correctness at some future time) if it is a DHCP one.

It's the same in OpenPLi, as it comes right out of yocto (openembedded).

One doesn't need to understand everything in yocto, some things simply don't make sense at all.

I'll stick with the ntpdate manpage, which says:

-b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adj‐
time() system call. This option should be used when called from a startup file at boot time.

Actually it would be even better to run a one-shot-NTP-sync service (initscript) on boot after networking, in the way that systemd is configured to, but I think it's safe to assume that ifup will in most cases happen at boot only or at least in situations where the box is not doing critical stuff and/or is almost in sync anyways.

Edited by SpaceRat, 30 December 2017 - 04:59.

[littlesat]

The clock stuff in oscam should be remover asap... this is really a not done mechanism!!

Edited by littlesat, 30 December 2017 - 07:44.

[MiLo]

You are assuming here that the internal i2c buses are exported to the kernel and user space. I very much doubt that. A driver developer has no interest in making the i2c bus available to user space.

The bus driver does that, not the I2C driver.

The I2C device driver is probably broadcom's. It registers itself as I2C master controller, and the kernel then creates the bus interface (without any effort on the driver's side). This also creates the sysfs entries.

As I said, just browse around in /sys/bus/i2c/ and you'll probably find the tuners too there.

[WanWizard]

Question is also if there is an internal connector of some sort to be found, that you can connect something to. You have pass-through I2C RTC's, but they are useless if you can't connect it. Also, not a lot of users will be able to add something like this.

[Erik Slagter]

for Raspberry PI there are RTC´s around, means the software can be used straight away on an armhf box, we just need someone to do the beta testing
https://thepihut.com...ur-raspberry-pi
https://raspberry.ti...t-raspberry-pi/

That's exactly the RTC IC's I am talking about, but then on a break out box. The same objections apply.

[Erik Slagter]

 

You are assuming here that the internal i2c buses are exported to the kernel and user space. I very much doubt that. A driver developer has no interest in making the i2c bus available to user space.

The bus driver does that, not the I2C driver.

The I2C device driver is probably broadcom's. It registers itself as I2C master controller, and the kernel then creates the bus interface (without any effort on the driver's side). This also creates the sysfs entries.

As I said, just browse around in /sys/bus/i2c/ and you'll probably find the tuners too there.

.
./devices
./devices/i2c-0
./devices/i2c-1
./devices/i2c-2
./devices/i2c-3
./devices/i2c-4
./drivers
./drivers/ir-kbd-i2c
./drivers/ir-kbd-i2c/bind
./drivers/ir-kbd-i2c/uevent
./drivers/ir-kbd-i2c/unbind
./drivers/dummy
./drivers/dummy/bind
./drivers/dummy/uevent
./drivers/dummy/unbind
./drivers/mpu3050
./drivers/mpu3050/bind
./drivers/mpu3050/uevent
./drivers/mpu3050/unbind
./uevent
./drivers_probe
./drivers_autoprobe

No tuners there. But there are a few buses, so it might work. But you didn't consider the situation where the i2c bus is not registered to the kernel. There is nothing that forces a manufacturer to register it's bus with the kernel. These may be all i2c buses, but it also may only part of them.

[Erik Slagter]

Question is also if there is an internal connector of some sort to be found, that you can connect something to. You have pass-through I2C RTC's, but they are useless if you can't connect it. Also, not a lot of users will be able to add something like this.

Exactly the last. That's why I proposed a USB device. I could develop such a thing, wouldn't be that hard, it's just that I can't make production of it.

 

But I2C is parallel & piggyback, anywhere you have +, mass, SDA and SCL available, you can just connect it. Having said that, some buses maybe multiplexed and some of them may be hispeed, which may render the whole bus unusable if you connect a non-hispeed compatible device.

Edited by Erik Slagter, 30 December 2017 - 11:56.

[SpaceRat]

Sorry to disturb the enthusiasm about RTCs:
They would definitely be nice to have, but they aren't the wonder cure.

The boxes would still need to get a time (sync) somehow, the RTC would only remove the need for quirks like save-rtc.sh/bootmisc.sh resp. fake-hwclock.

About every OS (At least all major Linux distros, CrApple CrapOS Somewhat Pussy and Windows) uses NTP for periodic syncs by default.
It would definitely be the better default, but the problem are non-networked boxes.

We wouldn't have this discussion if we could rely on NTP to work for everybody.

[Erik Slagter]

It's a vicious circle. A STB shouldn't need to have an RTC because it receives the correct time all of the time. The problem is that the "correct time" is received at a too late stage in booting. The correct time should be set early in the boot process, not in some userland process like enigma or even oscam.

 

I can identify two problems in this thread, let me have this clear:

 

1) no time at all when the receiver has been powered off completely (not deep standby but truly disconnected from the mains)

2) time doesn't get corrected whenever set at some point

 

1) is only relevant for those who (very) frequently take the receiver completely of the power grid. I don't understand why someone whould do so on a regular basis.

2) may be relevant for all of us, in the long run when a receiver has been powered on for a long time

 

I think 1) is difficult to resolve without a proper battery backuped RTC or an NTP server. OTOH it's relevant for a small group of users. But 2) should be easy to fix, imho. The drawback that the system time is adjusted by a user process (enigma) which is not ideal.

[littlesat]

For recording timers you need the correct time. When the box is not connected to the www the only option is to synch via transponder time... (via e2?)

[WanWizard]

In the RTC case, don't make it more complex than it is. Every other device has the option to set the clock manually, from PC to microwave. An STB shouldn't be any different.

[mrvica]

Question is also if there is an internal connector of some sort to be found, that you can connect something to.

most STB´s have a JTAG Interface, we just need to locate SDA/SCL pins, this is how they did it on the dbox2 almost 10 years ago, only two files needed, ds1307 driver and a tool to set the time, ds1307 creates a device /dev/dbox/clock (we still have /dev/dbox/oled0 there) and the tool communicate with it, the driver is free (GPL), by the way how can I compile ds1307.c to ds1307.ko

Attached Files

•  ds1307_hwrtc.zip   12.57KB   2 downloads

[WanWizard]

Still very complex for most users, a different solution for very STB, and in some cases will require soldering.

 

It would be better to combine a DS1307 + battery and a FT201X onto a small USB-stick style PCB.

[MiLo]

The VU box pretends there's nothing there (the DVB drivers aren't GPL so cannot use the kernel's I2C routines).

Xtrend reveils a bit more internals:

root@et8000:/sys/bus/i2c/devices# grep . */name
0-0008/name:a8304
0-004b/name:stv6418
3-0008/name:a8304
4-0008/name:a8304
i2c-0/name:bcm-i2c0
i2c-1/name:bcm-i2c1
i2c-2/name:bcm-i2c2
i2c-3/name:bcm-i2c3
i2c-4/name:bcm-i2c4
i2c-5/name:bcm-i2c5
i2c-6/name:bcm-i2c6

Apparently, some voltage regulators and the scart plug controller...

Using i2cdetect you can see some more chips are there (don't try this at home kids...):

root@et8000:/sys/devices/i2c-0/0-004b# i2cdetect -r 0
i2cdetect: WARNING! This program can confuse your I2C bus
Continue? [y/N] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- UU -- -- -- 0c -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@et8000:/sys/devices/i2c-0/0-004b# i2cdetect -r 1
i2cdetect: WARNING! This program can confuse your I2C bus
Continue? [y/N] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@et8000:/sys/devices/i2c-0/0-004b# i2cdetect -y -r 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@et8000:/sys/devices/i2c-0/0-004b# i2cdetect -y -r 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- UU -- -- -- 0c -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- 4a -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@et8000:/sys/devices/i2c-0/0-004b# i2cdetect -y -r 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- UU -- -- -- 0c -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- 3d 3e 3f 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@et8000:/sys/devices/i2c-0/0-004b# i2cdetect -y -r 5
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@et8000:/sys/devices/i2c-0/0-004b# i2cdetect -y -r 6
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

[MiLo]

Question is also if there is an internal connector of some sort to be found, that you can connect something to.

I'm pretty sure the tuners have I2C busses running to them. You can connect the chip there.

As for the drivers, just activate it through menuconfig and rebuild the kernel. You can "bind" the driver through sysfs (google knows how) or through the devicetree (on ARM based systems).

[Erik Slagter]

Question is also if there is an internal connector of some sort to be found, that you can connect something to.

most STB´s have a JTAG Interface, we just need to locate SDA/SCL pins, this is how they did it on the dbox2 almost 10 years ago, only two files needed, ds1307 driver and a tool to set the time, ds1307 creates a device /dev/dbox/clock (we still have /dev/dbox/oled0 there) and the tool communicate with it, the driver is free (GPL), by the way how can I compile ds1307.c to ds1307.ko

JTAG is something quite different to I2C. But that's not the issue, there are I2C busses for the tuners.

[mrvica]

I mixed it up, SCL = Serial Clock, SDA = Serial Data, must be I2C ( great relief), I located them already on the board, JTAG has other pins (TDI, TDO, TCK, TMS, TRST)

[WanWizard]

there are I2C busses for the tuners.

 

Pretty useless for this purpose if they are not exposed.

 

I've opened the box on the top of my test stack (happened to be a Formuler 1), nothing in there an average user could add too. You'll need to be advanced and have good soldering skills to get anywhere.