Missing kernel module mn88473/general kmod questions

Could you please provide a package for kernel module mn88473 (https://cateee.net/lkddb/web-lkddb/DVB_MN88473.html). This is a DVB-T2 tuner found in the Astrometa DVB-T2 USB stick which I believe is quite popular.

On a more general note: Is this a good place to ask for additional kernel modules? Is there a strightforward way to compile modules I need myself?

1 Like

Hello,
I created issue on our Gitlab.
//EDIT: Support for DVB-T2 tuners will be added later in 2018.

Good place to ask for additional kernel modules is our Gitlab.
You can create issue like I did for you or you can request it also on our e-mail tech.support(at)turris.cz, where I’ll ask you for lsmod on clean system (e.g. live distribution of Ubuntu on your PC) and after you plug dvb tuner to it and do the difference between these two and then I will create issue on Gitlab and I’ll inform you of progress directly on Gitlab.

2 Likes

Thanks for the pointer and for opening the issue!

I’m not 100% sure what lsmod outputs you are asking for – from the Omnia, from an lxc container, from a separate host?

From some system (kernel) that can use the module, e.g. a live distribution on your PC, as pointed out. It won’t work on lxc in Omnia.

EDIT: but as you provided the particular module name already, I’m personally not sure it can bring some new information…

Ah, yes, that makes sense. The live distribution thingie somehow got me confused.

FWIW, I managed to compile the module for the Omnia and install it. The stick is scanning for channels as I type. Took me quite a bit to figure out the TurrisOS/OpenWRT build system but I finally succeeded.

If there’s any interest from others, I’d be interested to learn how I can help getting this into TurrisOS.


Well, the bad news is that although the tuner is recognised both by the kernel and mythtv, mythtv fails to find any channels. I’ll look into that some more, but maybe there’s a reason the driver is still in staging for kernel 4.4…


//EDIT:
Update: w_scan detects 3 of the 6 available muxes, so the driver seems to work in principle.

I’ve put the kernel module here for now. Let me know if it works for you.

Thanks. ko? Is it normal ipk? Content is different (ELF). I see inside, that it downloads fw from https://github.com/OpenELEC/dvb-firmware/blob/master/firmware/dvb-demod-mn88473-01.fw, isnt better to copy fw directly to /lib/firmware on omnia?

Btw, OpenELEC one fw is exactly the same as linked from .fi site (which I already have in /lib/firmware before)

Edit: https://gitlab.labs.nic.cz/turris/openwrt/commit/e947a125935fd9f7ec1b035e5eba6d0e781f56d5
–>
https://repo.turris.cz/omnia-kernel-modules/packages/base/kmod-dvb-mn88473_4.4.114+0-1-00afa2f7f9014596e68ef88734989083-0_mvebu.ipk

:wink:

We just must wait for higher kernel, and then we will able to test it (RC 3.9.5 has kernel_4.4.113)

* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-dvb-mn88473:
* kernel (= 4.4.114-1-00afa2f7f9014596e68ef88734989083-0) *

:disappointed_relieved:

Btw, is there any way, how to find, if I have Panasonic MN88472 or Panasonic MN88473, without dissasembly device?

No, it’s the raw kernel module. You have to put it into /lib/modules/$(uname -r) and create a file /etc/modules.d/dvb-mn88473 that just contains the text “mn88473”. Then you can load it via “modprobe mn88473”. It should also autoload when you insert the USB stick.

I just enabled the driver in that’s already present in the Omnia kernel source tree. I haven’t checked how the download came in there. However, as far as I know, it will only download a firmware file if none is already present.

Cool find, thanks! Should be out any time now, so lets see how that behaves.

Edit:

You should be able to install the ipk with “-f” – you’ll just have to move/copy the .ko from

/lib/modules/4.4.114-1-00afa2f7f9014596e68ef88734989083-0 to

/lib/modules/4.4.113-1e4a549d177ab3da12b2052fba6a4dd5-1

Once you have the driver installed, use the command “dmesg” right after inserting the USB stick. You should find the driver’s messages stating what kind of chip it detected.

I tested your raw:
Message output looks little bit better

[1596631.655438] usbcore: registered new interface driver dvb_usb_rtl28xxu
[1597653.500602] usb 4-1: new high-speed USB device number 2 using xhci-hcd
[1597653.657349] usb 4-1: dvb_usb_v2: found a 'Astrometa DVB-T2' in warm state
[1597653.728655] usb 4-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[1597653.728760] DVB: registering new adapter (Astrometa DVB-T2)
[1597653.735104] i2c i2c-9: Added multiplexed i2c bus 10
[1597653.735115] rtl2832 9-0010: Realtek RTL2832 successfully attached
[1597653.735409] usb 4-1: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
[1597653.735481] r820t 10-003a: creating new instance
[1597653.746916] r820t 10-003a: Rafael Micro r820t successfully identified
[1597653.753432] Registered IR keymap rc-empty
[1597653.753607] input: Astrometa DVB-T2 as /devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb4/4-1/rc/rc0/input0
[1597653.753615] rc0: Astrometa DVB-T2 as /devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb4/4-1/rc/rc0
[1597653.757979] usb 4-1: dvb_usb_v2: schedule remote query interval to 200 msecs
[1597653.769834] usb 4-1: dvb_usb_v2: 'Astrometa DVB-T2' successfully initialized and connected
[1597932.398598] usb 4-1: DVB: adapter 0 frontend 0 frequency 0 out of range (174000000..862000000)
[1598301.980103] rtl2832 9-0010: i2c reg read failed -32
[1599044.492404] rtl2832 9-0010: i2c reg read failed -32
[1599276.351718] usb 4-1: USB disconnect, device number 2
[1599276.352202] r820t 10-003a: destroying instance
[1599276.352404] dvb_usb_v2: 'Astrometa DVB-T2:4-1' successfully deinitialized and disconnected
[1662274.084182] usb 4-1: new high-speed USB device number 3 using xhci-hcd
[1662274.240943] usb 4-1: dvb_usb_v2: found a 'Astrometa DVB-T2' in warm state
[1662274.317050] usb 4-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[1662274.317151] DVB: registering new adapter (Astrometa DVB-T2)
[1662274.325453] i2c i2c-9: Added multiplexed i2c bus 10
[1662274.325464] rtl2832 9-0010: Realtek RTL2832 successfully attached
[1662274.330181] mn88473 9-0018: Panasonic MN88473 successfully attached
[1662274.330199] usb 4-1: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
[1662274.330255] usb 4-1: DVB: registering adapter 0 frontend 1 (Panasonic MN88473)...
[1662274.330308] r820t 10-003a: creating new instance
[1662274.341714] r820t 10-003a: Rafael Micro r820t successfully identified
[1662274.341729] r820t 10-003a: attaching existing instance
[1662274.348606] r820t 10-003a: Rafael Micro r820t successfully identified
[1662274.355616] Registered IR keymap rc-empty
[1662274.355783] input: Astrometa DVB-T2 as /devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb4/4-1/rc/rc0/input1
[1662274.355791] rc0: Astrometa DVB-T2 as /devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb4/4-1/rc/rc0
[1662274.356814] usb 4-1: dvb_usb_v2: schedule remote query interval to 200 msecs
[1662274.372306] usb 4-1: dvb_usb_v2: 'Astrometa DVB-T2' successfully initialized and connected
[1662539.873120] usb 4-1: DVB: adapter 0 frontend 0 frequency 0 out of range (174000000..862000000)
[1662540.446909] mn88473 9-0018: downloading firmware from file 'dvb-demod-mn88473-01.fw'
[1662540.952988] mn88473 9-0018: firmware parity check succeeded=0x20
[1662541.128615] usb 4-1: DVB: adapter 0 frontend 1 frequency 0 out of range (42000000..1002000000)
[1662541.214285] rtl2832 9-0010: i2c reg read failed -32
[1663049.456221] mn88473 9-0018: firmware already running

Not sure what i2c reg dailed means, but I think its DVB-T related anyway. I dont have w_scan on Omnia, so I must rely on tvheadend, and both multiplexes was unsucessfull

2018-02-06 17:25:32 info tvheadend[30370]: mpegts: 530MHz in CZ DVB-T2 - tuning on Panasonic MN88473 #0 : DVB-T #1
2018-02-06 17:25:32 info tvheadend[30370]: epggrab: 530MHz in CZ DVB-T2 - registering mux for OTA EPG
2018-02-06 17:25:32 info tvheadend[30370]: subscription: 001E: "scan" subscribing to mux "530MHz", weight: 6, adapter: "Panasonic MN88473 #0 : DVB-T #1", network: "CZ DVB-T2", service: "Raw PID Subscription"
2018-02-06 17:25:32 warning tvheadend[30370]: linuxdvb: Unable to provide BER value.
2018-02-06 17:25:32 warning tvheadend[30370]: linuxdvb: Unable to provide SNR value.
2018-02-06 17:25:32 warning tvheadend[30370]: linuxdvb: Unable to provide UNC value.
2018-02-06 17:25:37 info tvheadend[30370]: mpegts: 530MHz in CZ DVB-T2 - scan no data, failed
2018-02-06 17:25:37 info tvheadend[30370]: subscription: 001E: "scan" unsubscribing
2018-02-06 17:25:37 info tvheadend[30370]: mpegts: 554MHz in CZ DVB-T2 - tuning on Panasonic MN88473 #0 : DVB-T #1
2018-02-06 17:25:37 info tvheadend[30370]: epggrab: 554MHz in CZ DVB-T2 - registering mux for OTA EPG
2018-02-06 17:25:37 info tvheadend[30370]: subscription: 0020: "scan" subscribing to mux "554MHz", weight: 6, adapter: "Panasonic MN88473 #0 : DVB-T #1", network: "CZ DVB-T2", service: "Raw PID Subscription"
2018-02-06 17:25:42 info tvheadend[30370]: mpegts: 554MHz in CZ DVB-T2 - scan no data, failed
2018-02-06 17:25:42 info tvheadend[30370]: subscription: 0020: "scan" unsubscribing

thanks for the tip for the “official” module! I will test it later. Are you sure there isnt required higher kernel (for proper functionality)? Commit looks quite small, still.

I just had a look at the “official” package – so far it does not contain the driver at all, so it’s obviously still very much a work in progress. The answer to your question probably depends on which version of the driver the Turris team eventually decides to include. The .ko I posted earlier was built against Kernel 4.4.110 (deployment Kernel at the time of compiling) and works just as well (or bad) with the current 4.4.113. I’d expect the same to hold true if only the minor Kernel version changes but no guarantees from my side. :wink:

I was suspicious about the small size. But at least we have hope that this is working on.

Regarding kernels, someone from team wrote some time ago, that some changes needs to be done in kernel level, so maybe thats the reason, why your compiled module doesnt work entirelly (I dont claim that my test proving anything, as I cant compare DVB-T2 on any other device, and also my tvheadend isnt newest). At least I dont see any other reason, when the firmware used on OE (Rpi) is the same.

Github request is now closed, and it looks like merged to stable. I dont see any much differences in code, so I hope we will be happy with next Turris OS release :slight_smile:

The GitLab issue you linked points to commits and merge request.

Driver should be part of latest release Turris OS 3.9.6 is out!. I personally dont test it yet (sleep time), but hoping T2 could work now…

Edit: Ou :frowning: Turris OS 3.9.6 is out!

Hi, latest test seems to have .ko included.

I am not experienced enough to “hack it” into older Turris OS:
I copied mn88473.ko into /lib/modules/(uname-r)/ and dvb-mn88473 into /etc/modules.d/. I have .fw files in /lib/firmware. Got:

modprobe mn88473
Segmentation fault

But maybe for you it is interesting for test… (not sure if dvb-demod-mn88473-01.fw is needed in firmware folder or not)

@paja @pepe or @miska, Could you please check, if patches, mentioned here are included?

As I understand, those are not part of mainstream kernel.

First one fixing dissapearing DVB stick (more revisions in the world)

--- mn88473.c.orig         2016-09-17 23:02:36.207362191 +0200
+++ mn88473.c      2016-09-17 23:03:10.420786897 +0200
@@ -492,7 +492,7 @@

           dev_dbg(&client->dev, "chip id=%02x\n", uitmp);

-          if (uitmp != 0x03) {
+          if (uitmp != 0x03 && uitmp != 0x08) {
               ret = -ENODEV;
               goto err_regmap_0_regmap_exit;
           }

confirmed to work.

Next one should solve DVB-C scanning above 500MHz:

diff -Naur linux/drivers/media/tuners/r820t.c linux/drivers/media/tuners/r820t.c
--- linux/drivers/media/tuners/r820t.c	2016-12-30 23:12:01.000000000 +0300
+++ linux/drivers/media/tuners/r820t.c	2016-12-30 23:15:48.000000000 +0300
@@ -766,7 +766,7 @@
 		lna_top = 0xe5;
 		lna_vth_l = 0x62;
 		mixer_vth_l = 0x75;
-		air_cable1_in = 0x60;
+		air_cable1_in = 0x00;
 		cable2_in = 0x00;
 		pre_dect = 0x40;
 		lna_discharge = 14;

also confirmed as worked.

I believe, that the same fix will be need for possible LXC OS’s, so far I didnt test them for tvheadend.

Hi,
it should not be a problem to include these fixes. But it will be probably in one of the future versions, as we have feature freeze for 3.10 right now.
Gitlab issue https://gitlab.labs.nic.cz/turris/openwrt/issues/177

1 Like

Thank you… I will wait little bit more then :slight_smile:

Do you know, hows the situation with LXC? I assume, that OS comes from other vendors, not by NIC. I suppose it could be done in LXC’s OS by tinkering with kernel modules, but currently I am lacking of knowledge and time to trying it within container.

@paja, one correction:
this patch is fine and related to the mn88473: [media] mn88473: finalize driver - kernel/git/torvalds/linux.git - Linux kernel source tree

but on the top of it should be applied also this

--- mn88473.c.orig         2016-09-17 23:02:36.207362191 +0200
+++ mn88473.c      2016-09-17 23:03:10.420786897 +0200
@@ -492,7 +492,7 @@

           dev_dbg(&client->dev, "chip id=%02x\n", uitmp);

-          if (uitmp != 0x03) {
+          if (uitmp != 0x03 && uitmp != 0x08) {
               ret = -ENODEV;
               goto err_regmap_0_regmap_exit;
           }

according guys from the linked discussion, this is even improve quality of driver - some of USB sticks doesn report themselfs as 0x03, but 0x08…

LXC uses host’s kernel, so I don’t think it can do any changes around kernel modules either.

2 Likes