jernej
-
Posts
1144 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jernej
-
-
11 minutes ago, danboid said:
Have you already written a script to show the time on the LED using this method?
No, that's the only script I wrote. Once things start to work, I lose interest
And I'm not fond of python, either.
-
@danboidif you prefer, we can continue our discussion here.
Note, mesa has nothing to do with HDMI plug detection. GPU is distinct core from display engine (that's why you have two dri cards present). I would say it's X11 issue, but then, I have no experience with it on H6.
Regarding LED driver - you might make it work with above repo, but then there is easier way, at least if you have some python programming knowledge. I recently added a node for LED display in DT and it will debut with kernel 5.17:
Once you have that in DT, together with enabled i2c-gpio and i2c-dev drivers, you can play with LED display as much as you want. For example, with python script using python-periphery library:
from periphery import I2C i2c = I2C("/dev/i2c-0") # adjust path as needed msgs = [I2C.Message([0x03], flags=I2C._I2C_M_IGNORE_NAK)] i2c.transfer(0x24, msgs) # enable display msgs = [I2C.Message([0xff, 0x67, 0x63, 0x63, 0x47], flags=I2C._I2C_M_IGNORE_NAK)] i2c.transfer(0x33, msgs) # set LEDs i2c.close()
Note, that ignore NAK flag is important. FD650 LED driver is not exactly your standard I2C device.
-
1 hour ago, umtkyck said:
Is there any version for kodi using kernel 5.4? so i can port it.
Sure, just check git history of LibreELEC. Generally, each kernel version is supported at some point in nightly images, except when we're preparing on release. So only 5.11 and 5.12 (maybe 5.13?) were skipped. But as I said, there are always bugs regarding codecs and fixes appear only for current kernel version.
-
IIRC only MPEG2 worked with 4.20. just dig into git history. Note that HEVC bugs are being squashed even now, so anything from that era is (almost) useless. H264 bugs were common till last year...
P.S.: I don't care if you're trying to waste your time with this. I certainly wont. I'll only talk from memory, nothing more.
-
Kernel 4.19 was one of the first which has anything of request API framework IIRC. Task of porting mainlined patches there will be even harder. You can use WIP patches from Bootlin and accompanying libs, but then expect that many videos won't work, especially interlaced H264. Also gstreamer or patched ffmpeg won't be compatible with that API. That's even more futile IMO and don't expect any help from me.
-
On 2/5/2022 at 4:49 PM, umtkyck said:
Just taking the cedrus drivers will not help generally, right?
You'll have to also port headers and maybe more. This is generally not something I'd spend time on. It should be easier to update Linux package on openwrt.
-
hm... that's unexpected. I assumed XR819 comes only with lower specs TX6 (2G version).
-
4 hours ago, Ehsan Vahab said:
I haven't found any other news expect that uboborov's sunxi cedar mainline for Allwinner H3 on legacy kernel.
Now I don't know whether there is an hardware encoder driver for H5 or not?
H3 and H5 have same encoder, so H3 encoder should also work on H5, but I didn't test.
-
13 hours ago, umtkyck said:
how can i find armbian kernel 5.14 for orangepi pc?
There is no 5.14 kernel available in Armbian, I talked about minimum version. In general, codecs are improved with (almost) every release, so latest version is best. I only see images with kernel 5.13 on download page, which should in theory work. You can build your own Armbian image with kernel 5.15 (edge).
-
10 hours ago, Pic55 said:
Unfortunatly I can not upload the pictures (code 200).
You can still use services like imgur.
10 hours ago, Pic55 said:one with 2G of RAM TX6P - probably what you call the mini, and one with 4G of RAM TX6A 6B
I'm still not sure if TX6 variant with 2 GB RAM got renamed to TX6 mini or are these two different products. I only own TX6 with 4 GB RAM, which has RTL8822BS wifi+bt combo.
-
1 hour ago, umtkyck said:
I am using armbian latest stable version : Linux orangepipc 5.10.60-sunxi #21.08.1 SMP Wed Aug 25 18:19:32 UTC 2021 armv7l armv7l armv7l GNU/Linux
5.10 is ancient for video decoding purposes. Codecs started stabilizing after 5.11. With 5.14 you'll have stable and fully working MPEG2, VP8 and H264. If you need low effort solution, build latest gstreamer 1.20 RC with gst-plugins-bad with one of the latest kernels. With proper pipeline, it works. If you need out of the box solution, use LibreELEC distro.
-
There are 3 possibilities regarding wifi on TX6:
- XR819 - wifi only - TX6 mini
- RTL8822BS - presumably older TX6
- RTL8822CS - presumably newer TX6
-
FYI, I ported wifi driver to mainline (top two commits): https://github.com/jernejsk/linux-1/commits/h616-full
To say that code is convoluted is a big understatement.
-
4 hours ago, dotbg said:
Is there any way to to boot directly from USB in case of NAND flash on board?
If by that you mean using USB dongle then no. However, if you put your box in FEL mode, you can load U-Boot via USB using another machine. But that's meant more for developers or unbricking and it's not friendly at all for everyday use.
-
1 hour ago, ArkhanLK said:
would the images and procedure for H616 work on a H313 board?
In theory, yes. As long as it has DDR3 RAM (no other RAM type is supported currently).
1 hour ago, ArkhanLK said:Just wondering if someone else has done it.
Not to my knowledge.
-
8 hours ago, Nurali said:
Is there a way to get hw acceleration for video encoding on recent kernels (5.10.y) for Orange pi one?
Nothing out of the box, but someone forward ported BSP driver to mainline and used that with encoding software that was developed back then. However, if you do that, you would lose mainline Cedrus driver (you can't have two drivers loaded for same core).
I didn't try it myself, so I suggest you search this forum. IIRC it was discussed on this forum somewhere.
-
9 hours ago, usual user said:
But I still don't understand why you insist to involve the 3D accelerator in the video pipeline while the VOP can scan out video formats directly.
GPU rendering is usually preferred in X11 environment. I don't think DRM rendering is implemented in most players under X11. Another common reason would be to use various fancy shaders for post-processing, for features that are not yet supported in driver or not at all in HW.
-
@usual userno idea then. Best to wait on RK devs to update patches, but that will take some time...
@iamdrqIt looks you're using 10-bit video sample. It's always good idea to try 8-bit first.
-
Ah, yes, that should work with upstream VP9 API. I'm not sure what could broke with kernel update. There are few HEVC patches that were upstreamed. Maybe order of the fields changed? You can try simple experiment. Copy hevc-ctrl.h from patched kernel sources to ffmpeg sources (replace existing file) and rebuild ffmpeg. If it fails to build, you know some, probably minor, updates are needed. If it goes through, it might just work.
-
Note that final VP9 API, which landed in media repo, is slightly different than before and new ffmpeg patches will be needed. We only have WIP variant for new VP9 API. It works, but breaks SW VP9 decoding. We have some time untill it lands in stable kernel...
-
If you want video decoding acceleration to work on Kodi with Allwinner SoCs, you need gbm version of Kodi (e.g. without desktop running) and patched version of ffmpeg (I don't think that's provided on Armbian).
-
Did anyone actually bother to port AW859A driver to mainline? I certainly didn't.
-
I don't use any desktop environment (X11 or Wayland) on SBCs, so I can't tell you what works and what not. However, I can tell you that v4l2 request drivers decode video frames to dma-buf, which can be directly imported into DRM or OpenGL ES (mesa exposes functions to do that, but afaik it convert colour space with GPU, still much quicker than CPU). Later option should work everywhere where OpenGL ES is supported, so under X11 and Wayland too. At first glance, it seems that mpv doesn't have this implemented, but I'm not sure. Kodi has both rendering methods implemented, but only when using GBM variant (nobody bothered to enabled that for other environments).
-
12 hours ago, yam1 said:
Do you know if this is the case? AIGLX thinks my ili8488 screen is not DRI2 capable:
Sorry, I don't know. I don't use X11 nor displays via SPI.
Allwinner H6
in Allwinner CPU Boxes
Posted
No, but I'm in contact with few of them. In fact, my job has nothing to do with Linux, although this will probably change in near future. It's just a hobby for getting some experience with developing various Linux drivers and learn how things work nowadays. You won't see me writting userspace apps, except for testing purposes or improving existing code which use drivers I'm working on.
I follow few tutorials for character devices on net. But I find it easier to study existing drivers, especially if working on something new. Linux has well documented common code and there is a ton of helper functions. Reading various slides from presentations of particular subsystem also helps. You have to find the method which works for you.
There is no single source for that either. Also depends what you mean by reverse engineering. Nowadays there is BSP linux source which means you just have to understand that code, but many times even this is not an easy task. But if you mean hard core reverse engineering, like analyzing binaries and trying to understand what they do, that's another beast entirely. It helps if you learn assembly language for target system, read a lot of tutorials, guides, etc. If you can solve various crackmes, then you're already better in this than most people. But truthfully, you really don't need that to be good kernel developer. However, I already found few interesting things that way, because Allwinner hid some things in binaries which were later linked in driver directly.