more debug things I know

This commit is contained in:
Jaroslav Kysela 2015-04-15 21:26:35 +02:00
parent 3c53abd77c
commit fde136f774
4 changed files with 85 additions and 0 deletions

View File

@ -0,0 +1,21 @@
A problem with the original firmware and satip-axe firmware is that
sometimes there are many continuity errors in the stream. Also, sometimes
the 8192 PID (means FULLMUX) does not work (bandwidth only few KB instead
megabytes).
The CC errors are visible using 'axe-debug pti vdev 0' or
'grep -v AAAAAAAAAAAA /proc/STAPI/stpti/PTI0/vDeviceInfo'.
The CC errors are not detected by the PTI interface when 8192 PID (fullmux)
is used.
So there is a data-loss somewhere between STV0900 (demux) and STx7018 (PTI).
The data-loss is visible more when multiple tuners are used together.
Possible steps:
- decode I2C communication with the demodulator
- try to inject I2C commands to STV0900
- write own axe-fe module ? because nothing else depends on it,
it could be replaced, the only big thing is to determine the i2c
connection to STx7018

25
debug/hardware.txt Normal file
View File

@ -0,0 +1,25 @@
Hardware:
=========
* CPU STx7108, 32-bit kernel
6 x PTI interface (used first four - 0-3)
(appears something like programmable transfer interface or so)
* Demodulators 2x STV0900 (dual)
* 2x LNBH24 - Dual LNB supply and control IC with step-up and I2C interface
I2C address map:
================
0x10 - LNBH24 #1 / section A : cfg write
0x11 - LNBH24 #1 / section A : diagnostic read
0x12 - LNBH24 #1 / section B : cfg write
0x13 - LNBH24 #1 / section B : diagnostic read
0x14 - LNBH24 #2 / section A : cfg write
0x15 - LNBH24 #2 / section A : diagnostic read
0x16 - LNBH24 #2 / section B : cfg write
0x17 - LNBH24 #2 / section B : diagnostic read
0xd0 - STV0900 #1 - write
0xd1 - STV0900 #1 - read
0xd2 - STV0900 #2 - write
0xd3 - STV0900 #3 - read

View File

@ -4,12 +4,34 @@
echo "deb 0xffffffff" > /proc/bus/nim_sockets
# AXE-firmware command
axe-debug tuner
#
# Enable i2c debug
#
echo "i2c_dbg_trans 1" > /proc/bus/ivo_i2c
# AXE-firmware command
axe-debug i2c
#
# Disable debugging
#
echo "deb 0" > /proc/bus/nim_sockets
echo "i2c_dbg_trans 0" > /proc/bus/ivo_i2c
# AXE-firmware command
axe-debug off
#
# proc PTI files - see PTI.txt
#
axe-debug pti
axe-debug pti dmesg <fe_num_0-3>
axe-debug pti pid <fe_num 0-3>
axe-debug pti util <fe_num 0-3>
axe-debug pti pdev <fe_num 0-3>
axe-debug pti vdev <fe_num 0-3>

17
debug/software.txt Normal file
View File

@ -0,0 +1,17 @@
TS flow
*******
main_axe.out binary initializes paths using STAPI from PTI to the dmxts interface
which provides buffers of size 2695168 bytes per queue.
Kernel modules
**************
Demodulators and LNB supply/DiseqC chips are driven from the axe-fe module
(which uses axe-i2c module doing the I2C I/O).
The frontend (probably only LED control ?through I2S bus?) is driven from
the axe-fp module.
The dmx module is not used but it works as a section decoder. Unfortunately,
there is no DVR module to collect output and to offer standard DVR API.