search

tbsdtv / linux_media

TBS linux open source drivers
https://github.com/tbsdtv/linux_media/wiki
Other
174 stars 80 forks source link

Compile fails on RPi 4 Buster Kernel 5.4.79-v7l+ - issues with mn88436 and ov9650 #220

Open the-unknown opened 3 years ago

the-unknown commented 3 years ago

Hey there,

I am using a TBS5520SE connected to a RasPi 4 using Raspian Buster and current stable Kernel 5.4.79-v7l+

I did the following steps

git clone https://github.com/tbsdtv/media_build.git
git clone --depth=1 https://github.com/tbsdtv/linux_media.git -b latest ./media
cd media_build
make dir DIR=../media
make allyesconfig
make -j4

make -j4 fails with the following errors:

  LD [M]  /home/pi/media_build/v4l/altera-stapl.o
  Building modules, stage 2.
  MODPOST 737 modules
ERROR: "__aeabi_ldivmod" [/home/pi/media_build/v4l/mn88436.ko] undefined!
ERROR: "__aeabi_uldivmod" [/home/pi/media_build/v4l/mn88436.ko] undefined!
ERROR: "__devm_regmap_init_sccb" [/home/pi/media_build/v4l/ov9650.ko] undefined!
make[3]: *** [scripts/Makefile.modpost:94: __modpost] Fehler 1
make[2]: *** [Makefile:1645: modules] Error 2

So it's clearly an issue with mn88436 and ov9650

How can I solve this issue?

steven1758 commented 3 years ago

Hi Sir

You can send email to our support@tbsdtv.com we will help you with this

Thanks

Kind Regards

6by9 commented 3 years ago

Something in mn88436 is doing a divide on a 64bit variable when running on a 32bit system. Quick search suggests https://github.com/tbsdtv/linux_media/blob/latest/drivers/media/dvb-frontends/mn88436.c#L2067

Use

do_div(frequency, 1000000);
freq = (UINT32)frequency

instead.

__devm_regmap_init_sccb is likely to be a dependency from Kconfig pulling in the wrong (or insufficient) things. Looks odd as VIDEO_OV9650 does select REGMAP_SCCB (https://github.com/tbsdtv/linux_media/blob/latest/drivers/media/i2c/Kconfig#L1062)

d2ydx2 commented 3 years ago

I also had this problem with the build and confirm that it remains present with the latest Raspberry Pi OS update (Linux kernel 5.10.11-v7l+), and the latest code from this repo.

I see from the above thread that TBS has offered support for this issue privately, has anyone availed of this, and if so what was the outcome?

I am very new to the area of drivers etc. but I really want to get my TBS based DVR back up and running, so I have tried to dig into this issue a little further myself.

It seems to me that the approach outlined in the wiki here is massively overkill for people who just want to build and install specific drivers for their own TBS device(s). Would it not be possible to simply cut out all of the other device drivers that are unnecessary anyway and only build and install the TBS ones (or even a specific driver)?

As the build problem here seems to be caused by code in a driver that is not needed anyway, cutting those out at least should help.

Note: There is a build config utility make menuconfig that's documented in the upstream LinuxTV.org drivers that allows you to select/deselect specific drivers and features before building. I tried this but was unable to identify which exact option I should leave on to ensure a successful build of the TBS drivers. Any pointers around this would be appreciated.

6by9 commented 3 years ago

For mn88436 it's a change that is only in the TBS drivers tree due to commit https://github.com/tbsdtv/linux_media/commit/b9529423c5bae9f94ace03054ebbf127bf5ac521, so absolutely nothing to do with being a Raspberry Pi, but everything to do with being a 32bit system that is being incorrectly asked to do a 64bit divide.

VIDEO_OV9650 isn't needed. Easiest is to go into https://github.com/tbsdtv/linux_media/blob/latest/drivers/media/i2c/Kconfig#L1084 and delete the Kconfig block for it.

You can't easily pick and choose which bits are and aren't built when building the backported media-tree. It has to rebuild all of the media subsystem to ensure symbols match.

4l3x2k commented 3 years ago

I'am used to the approach with media_build a long time for my pvr project.

Last time I tried another approach as the media_tree / upstream kernel does not contain the staging media drivers from rpi kernel. With this approach even those drivers are compatible and loaded without the need for rebuilding them. Honestly this is nothing for end users or beginners.

The outline is as follows:

I comment because it shows another approach getting desired drivers built and running.

Make command look like this

make O=~/linux-build drivers/media/dvb-core/dvb-core.ko drivers/media/usb/dvb-usb/dvb-usb.ko drivers/media/vtunerc/vtunerc.ko drivers/media/tuners/si2157.ko drivers/media/tuners/av201x.ko drivers/media/dvb-frontends/si2183.ko drivers/media/usb/dvb-usb/dvb-usb-tbs5520se.ko

Install command look like this

sudo cp drivers/media/usb/dvb-usb/dvb-usb.ko /lib/modules/5.4.83-v7+/kernel/drivers/media/usb/dvb-usb/
sudo cp drivers/media/dvb-core/dvb-core.ko /lib/modules/5.4.83-v7+/kernel/drivers/media/dvb-core/
sudo mkdir -p /lib/modules/5.4.83-v7+/kernel/drivers/media/vtunerc
sudo cp drivers/media/vtunerc/vtunerc.ko /lib/modules/5.4.83-v7+/kernel/drivers/media/vtunerc/
sudo cp drivers/media/tuners/av201x.ko /lib/modules/5.4.83-v7+/kernel/drivers/media/tuners/
sudo cp drivers/media/tuners/si2157.ko /lib/modules/5.4.83-v7+/kernel/drivers/media/tuners/
sudo cp drivers/media/dvb-frontends/si2183.ko /lib/modules/5.4.83-v7+/kernel/drivers/media/dvb-frontends/
sudo cp drivers/media/usb/dvb-usb/dvb-usb-tbs5520se.ko /lib/modules/5.4.83-v7+/kernel/drivers/media/usb/dvb-usb/
6by9 commented 3 years ago

I'll agree that building a single kernel with all features is "fun".

I did look at the changes that have been made here with a view to determining how easy they would be to cherry-pick across (probably into staging), but changes seem to be dotted throughout the media directories. Without all the variants of cards that are supported here it'd be difficult to be sure of covering them all. Even just trying to support some would be quite involved.

Doing a quick diff between the main Linux kernel trees and here, there are a fair number of extra drivers present :-(

I wonder what TBS's reluctance is with upstreaming their changes? OK the FPGA based PCI cards are going to be a fair amount of effort, but most of the USB ones I've had a quick look at require far more modest changes.

CvH commented 3 years ago

https://github.com/tbsdtv/linux_media/issues/87 :)

The same problems over and over again, I have really no idea why not even the low hanging fruits are going upstream. Not sure if this out of tree building mess is considered the best way to support the consumer. It is a mess since years and it getting worse.

Hauppauge for example has now basically everything up streamed, so you plug in your device, ready - regardless of your distribution or your device. TBS has in total 0,00 up streamed in 4 years - works nowhere (without installing out of tree driver that fail regular) since 10ish years.

6by9 commented 3 years ago

Hi @CvH Nearly no mainline support.

I picked up a TBS6981 (dual DVB-S2) off eBay as a test TBS device, and then found out that it's supported in mainline as it's CX23885 / CX24132 / CX24117 which is all bog standard :-/ I'm keeping my eyes open for other devices going cheap, but there aren't a huge number of useful ones that fall into that category.

The drivers are a bit of a mess when it comes to kernel coding standards, but nothing that a bit of checkpatch.pl --fix_inplacewon't deal with the majority of. If licences and copyrights were obvious (half of them aren't), then perhaps submitting to staging would be reasonable.

d2ydx2 commented 3 years ago

@4l3x2k - Hi, thanks for sharing that alternative approach, it gives me some hope. IIUC after your build process you ended up with just a handful of kernel modules that you just copy over, which can be loaded after which the DVB device is seen by the system.

With this approach even those drivers are compatible and loaded without the need for rebuilding them.

By that, do you mean these built kernel modules may still work after future system kernel updates without all this fuss each time? i.e. how the "closed source userspace" drivers are described here... which honestly sounds ideal to me, but perhaps that's referring to an entirely different approach?

In any case, as it happens I also have the TBS5520SE so what you did is probably exactly what I would like to do and I'm wondering if you'd be happy to share more details on the steps you outlined which I fully admit are indeed deeper than I, as a total newcomer to kernel building and linux drivers, have ever ventured before, but with a little more guidance I am prepared to give it a go, and would be happy to write up comprehensive instructions for newbies to follow, if I can get it to work.

Aside: Having read through thread #87 referred to by @CvH, it seems that this section was written specifically about TBS and their approach! It's such a shame that at least their USB devices don't have mainline support, as a Pi 4 + a TBS USB tuner (such as the TBS5520SE) can be the basis of a really neat low power TV/DVR solution (when the drivers work), but I don't imagine anyone enjoys this kind of hassle. I did do some research before I purchased my TBS device, and so I expected a rough ride, but the hardware is exactly what I wanted so I thought I'd risk it anyway.

4l3x2k commented 3 years ago

@d2ydx2

@4l3x2k - Hi, thanks for sharing that alternative approach, it gives me some hope. IIUC after your build process you ended up with just a handful of kernel modules that you just copy over, which can be loaded after which the DVB device is seen by the system.

That's it. No hassle with version symbol mismatch or building the whole media subtree.

With this approach even those drivers are compatible and loaded without the need for rebuilding them.

By that, do you mean these built kernel modules may still work after future system kernel updates without all this fuss each time? i.e. how the "closed source userspace" drivers are described here... which honestly sounds ideal to me, but perhaps that's referring to an entirely different approach?

No. I mean that the drivers specific to the rpi linux kernel can be kept. They reside mainly in the staging area e.g. bcm2835-codec or rpivid. You won't find these drivers in the official linux kernel, linuxtv media_tree nor this tbs media_tree. For tbs drivers you may need to alter the patch if there is a major or minor kernel version change.

The approach by sundek is completely different. I think they use some standard device driver like serial / usb etc. and put their driver logic into the user space. So you don't have to maintain any kernel drivers. Just the interface to the standard drivers. This may also be related to their closed source, which is not allowed for linux kernel drivers I think.

In any case, as it happens I also have the TBS5520SE so what you did is probably exactly what I would like to do and I'm wondering if you'd be happy to share more details on the steps you outlined which I fully admit are indeed deeper than I, as a total newcomer to kernel building and linux drivers, have ever ventured before, but with a little more guidance I am prepared to give it a go, and would be happy to write up comprehensive instructions for newbies to follow, if I can get it to work.

The most work is finding the sources you need for you device and integrate them into the rpi linux kernel. Some are easy, some are hard like @6by9 mentioned. I could provide you with tbs5520se patch for rpi kernel 5.4 and 5.10. Both with green lock led support.

Aside: Having read through thread #87 referred to by @CvH, it seems that this section was written specifically about TBS and their approach! It's such a shame that at least their USB devices don't have mainline support, as a Pi 4 + a TBS USB tuner (such as the TBS5520SE) can be the basis of a really neat low power TV/DVR solution (when the drivers work), but I don't imagine anyone enjoys this kind of hassle. I did do some research before I purchased my TBS device, and so I expected a rough ride, but the hardware is exactly what I wanted so I thought I'd risk it anyway.

I do not know how this repo is related to the manufacturer. Maybe people contributing here are doing it in their spare time. So their may or may not be any resource to make drivers upstream. Despite that, I think that some drivers wouldn't be accepted by upstream. For example the tbs5520se driver changes some kernel interns to register the second frontend.

As @CvH said this hasn't changed for years now and I think it won't change in the future.

4l3x2k commented 3 years ago

Hey there,

I am using a TBS5520SE connected to a RasPi 4 using Raspian Buster and current stable Kernel 5.4.79-v7l+

I did the following steps

git clone https://github.com/tbsdtv/media_build.git
git clone --depth=1 https://github.com/tbsdtv/linux_media.git -b latest ./media
cd media_build
make dir DIR=../media
make allyesconfig
make -j4

make -j4 fails with the following errors:

  LD [M]  /home/pi/media_build/v4l/altera-stapl.o
  Building modules, stage 2.
  MODPOST 737 modules
ERROR: "__aeabi_ldivmod" [/home/pi/media_build/v4l/mn88436.ko] undefined!
ERROR: "__aeabi_uldivmod" [/home/pi/media_build/v4l/mn88436.ko] undefined!
ERROR: "__devm_regmap_init_sccb" [/home/pi/media_build/v4l/ov9650.ko] undefined!
make[3]: *** [scripts/Makefile.modpost:94: __modpost] Fehler 1
make[2]: *** [Makefile:1645: modules] Error 2

So it's clearly an issue with mn88436 and ov9650

How can I solve this issue?

To get this issue down ...

... if you do not need that (mn88436 and ov9650) specific driver. You can issue a command like

make menuconfig

instead of 

make allyesconfig

and disable drivers that you do not want to build.

I started like @d2ydx2 and asked the manufacturer for support. They told me that the driver is not supported for architectures like arm. Only x86!

So ... here we are! Use a PC with their closed driver and be happy. No one is going to buy this hardware for hobby experiments.

d2ydx2 commented 2 years ago

I've tried to get this working every now and then since my earlier posts, hoping that it would just start to work at some stage. But no luck so far :(

Most recently I tried the build (per wiki instructions) on the last Buster release and also the latest Bullseye (both 32bit) and the same issue persists :( I also tried the 64bit version of Bullseye and the build succeeded (still loads of symbol mismatch errors showing in the logs), but alas I then ran into other hassle when attempting to install/build the rest of the software (e.g. tvheadend) I need for my system.

Incredibly frustrating.

@4l3x2k - I would really like to use your alternative approach as one last attempt before giving up entirely and buying a SAT > IP server box plus the official Raspberry Pi DVB-T2 HAT, to replace this so-close-and-yet-so-far TBS5520SE. I have done some background reading and research, and believe I am at the point where I can (almost) follow each of the steps in your outlined approach. If you could provide the patch you used for the TBS5520SE drivers it would be much appreciated. Thanks.

4l3x2k commented 2 years ago

@d2ydx2 I'am a bit behind with the patch for kernel version 5.4 and 5.10. They are named 0001-TBS5520SE-5.4.patch and 0001-TBS5520SE-5.10.patch in the zip file.

The latest patch for kernel version 5.10 is named 0001-dvb-usb-Add-TBS5520SE-5.10.patch in the zip file. It does not contain the latest si2183 statistic changes.

I also added my notes in the zip file as linux.README. TBS5520SE-5.4-5.10-Patch.zip

d2ydx2 commented 2 years ago

Thank you so much for sharing this, I can see you've invested a lot of time really digging into this, and the fruits of your labour bring me so close to getting this box working again!

The latest patch for kernel version 5.10 is named 0001-dvb-usb-Add-TBS5520SE-5.10.patch

This is my first foray into kernel/module building, so please forgive me for returning so soon with another question. I'm a little puzzled by the significance of the two patches 0001-TBS5520SE-5.10.patch and 0001-dvb-usb-Add-TBS5520SE-5.10.patch, as they both affect a similar set of files and apply to the same kernel version, though I can see there are significant differences between them. Is it that the former was a working patch for a previous RPI-OS build, and that the latter is WIP patch for the latest?

4l3x2k commented 2 years ago

The reason why there're two patches for 5.10 kernel is that not only the rpi kernel gets updated so does the tbs5520se kernel module also.

The 0001-TBS5520SE-5.10.patch is from February. The 0001-dvb-usb-Add-TBS5520SE-5.10.patch is from November.

The latest patch for 5.10 kernel is the latter one and contains changes made during February trough November to the tbs5520se kernel module. So you can ignore the former one.

The change made in the following commit is currently missing in 5.10 patch: https://github.com/tbsdtv/linux_media/commit/cb1e66b178377df7f195405f1501418134232dee

The patch should work for all 5.10.x kernel.