Maybe you can add the module using dkms
Archlinux on Rock5b
By PR what do you mean?( is that Pull Request?)
In fact I wondered if by installing kernel through AUR, we could customize kernel. With yay
I think it is possible to edit pkgconfig
before installing it. Or if we have to use the manual installation to tweak kernel. If that makes sense
I donāt know much about dkms
, is that a way to load module without recompiling?
DKMS: When you update the kernel, the module (once setup) will be compiled and installed and will match with that kernel version.
Normally used for out of tree modules but it can work also for in tree modules
Ok, so that would allow me just to compile missing kernel module for my specific kernel version, and install it without recompiling kernel if I got what you said?
Not sure which category in tree
/ out of tree
this ath9k
module belongs to though
Correct, compile missing modulesā¦
If mainline is the reference:
In tree, as in the same tree, so when you are talking about a module that is already in the mainline kernel.
Out of tree, an external module that is not part of mainline kernel.
I have once created one, for an external module (get one from another linux kernel repo)
PKGBUILD - aur.git - AUR Package Repositories (archlinux.org)
Just received my new AX210 wireless card which should be supported without installing kernel modules hopefully. But was good to know in case I need that later.
linux-radxa-rkbsp5-git is updated to rkr4.1 branch, following the original radxa fork of rockchip verndor kernel with additional GOFASTER patches.
linux-radxa-rkbsp5-bin is still following the official radxa debian repository which is currently at rkr3.5
additionally, i have moved the firmware and libmali blobs to the linux packages because they really depend on the kernel version being used. So when the new kernels are installed it will ask to remove libmali package. If this is asked please replace it.
Has anyone been able to cross-compile and/or compile natively on board a workable libmali?
what do you mean, there is no source to compile for userspace binary of libmali (what we call as libmali), there is kernel driver open sourced and it is already a part of the vendor kernel?
I meant the wrapper for closed source. I have to resort to the Rockchip deb package, and the latest one from Rockchip is for rk3.6. I rely on the wrapper. (https://github.com/JeffyCN/mirrors/tree/libmali) and build everything natively.
/usr/lib/aarch64-linux-gnu/libmali-valhall-g610-g6p0-x11-gbm.so
/usr/lib/aarch64-linux-gnu/libmali.so
/usr/lib/aarch64-linux-gnu/libmali_hook.so
/usr/lib/aarch64-linux-gnu/libmali.so -> libmali.so.1
/usr/lib/aarch64-linux-gnu/libmali.so.1.9.0
-rw-r--r-- 1 root root 43763352 Jul 29 2020 /usr/lib/aarch64-linux-gnu/libmali.so.1.9.0
If i understand correctly looks like Archlinux uses libmali-valhall-g610-g13p0-wayland-gbm.so and libmali-valhall-g610-g13p0-x11-gbm.so directly, no wrapper like in debian. If that is correct, you just drop in the new closed-source one and thatās it. Just like in the old days. Is that it?
there are some dependencies in between blobls and the actual kernel versions but yeah thats it.
when i look at that repo, i saw what they are doing with debian, it is my first time seeing this idea, and i like the wrapping idea, but i have a feeling that this will reuqire to modify somewhere else at some point.
When i directly use the blobs without any wrapper not all apps works but most of them work so i was ok with it.
So i am also curious if this wrapper thing actually works?
Yeah, it does. But i was never able to build it from sources (on board) . Actually you can build it just fine, but has linkage problems at run-time (that was long time ago).
interesting, sounds like a nice little weekend project. but not this weekend.
I opened an issue long ago with rockchip (canāt find whereā¦) but they were not able to reproduce the problem. So i thought the problem was at my side.
the problem is on always on our side since the moment we buy this half working sbcs
Let me know your progress on this, but seems archlinux found a way to bypass this.
nah, what i am doing is already available in armbian as well so called, malirun
ffmpeg-mpp &ffmpeg4.4-mpp packages areupdated with encoder support now. And fixed lots of stuff including 4gb memory issue and lots of others.
Kodi packages are still using the old version, because i noticed another issue with kodi which i think because of kodi rather than ffmpeg. I will update those as well after this kodi issue is clearified.
In case any issues, feel free to report.