jernej

Driver needs a bit of rework since Cedrus on H6 needs a bit different initialization. I guess you need this for video encoding?

It's not supported on H6 yet.

It's ARM9 core, so it's very old architecture. Only BSP kernel exists, but who knows where source can be found. So, even if sources for kernel can be found, it would be a waste of time to support it in Armbian.

Not at the moment. Thing is that it's, as you said, proof of concept. RPi variant is probably the one that it will be sent upstream (asynchronous job submission, which is much more performant), but it needs to be tweaked to be more universal. Hopefully we'll start working on this soon, since HEVC request api is the only common interface between RPi4 driver and Cedrus, Hantro and RKVDEC.
 
FYI, RKVDEC HEVC will most likely miss 5.20, since it was posted just yesterday and cut off date for new media features is end of this week.

If there is no status line, it's considered active. You have to set status to "okey" only when parent node sets it to "disabled". For example, sun50i-h6.dtsi has spdif node set to disabled. In sun50i-h6-tanix-tx6.dts we override status to "okay".

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.

Few differences I see:
- different drive strength for wifi (lower than TX6) - not that important
- slightly different eMMC settings (lower frequency, etc) - might be important
- different IR key codes (nothing surprising)
- it seems that slightly different LED display driver is used (can't be sure unless I see detailed PCB photo)
- T95 max has slightly higher DRAM frequency (672 MHz) vs. TX6 (666 MHz)
- different DRAM config, but it's unclear how much they influence stability

I have TX6 box with 8822BS wifi+bt too. I have patches for this wifi, meant to be upstreamed. Speed is probably not on par with out of tree driver and has locking issue (I never experienced it, but it was discovered during testing it on another wifi), but it generally works ok. Take a look here: https://github.com/jernejsk/linux-1/commits/rtw88-test2 (ignore first two patches). BT needs some more patches and FW extracted from Android image (I asked Realtek, but they are not interested in officially supporting BT on 8822BS version). I don't have those patches available anywhere currently.

If there is no status line, it's considered active. You have to set status to "okey" only when parent node sets it to "disabled". For example, sun50i-h6.dtsi has spdif node set to disabled. In sun50i-h6-tanix-tx6.dts we override status to "okay".

SPDIF is already included in base H6 DTSI file (any board can easily enable it, if present) and it will be enabled for Tanix TX6 by default in 5.17

Few differences I see:
- different drive strength for wifi (lower than TX6) - not that important
- slightly different eMMC settings (lower frequency, etc) - might be important
- different IR key codes (nothing surprising)
- it seems that slightly different LED display driver is used (can't be sure unless I see detailed PCB photo)
- T95 max has slightly higher DRAM frequency (672 MHz) vs. TX6 (666 MHz)
- different DRAM config, but it's unclear how much they influence stability

No, not really, only general instability (app crashes, kernel lockups, etc.). Note that Android has completely different display stack, so you can't compare it to X11. If you really want to prove it's driver issue, you would need to create BSP based image and test it there. But I never done that for 64-bit Allwinner SoCs, so I have no idea how hard it would be.
 
Strange, your DT blob has this:
 
awleds { device_type = "awleds"; compatible = "allwinner,fd6513_dev"; status = "okay"; leds_clk = <0x87 0x07 0x05 0x01 0xffffffff 0xffffffff 0x00>; leds_dat = <0x87 0x07 0x06 0x01 0xffffffff 0xffffffff 0x00>; phandle = <0x1bd>; }; which clearly indicates it should have FD6513 LED driver and thus display. Maybe it's one image for several box variants.

@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:
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi#L32-L38
 
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.

I know about the changes, I'm the one who made them. However, everything works for me . Note that there are some issues with 5.17-rc releases due to some sunxi pinctrl driver bugs, which were resolved recently. Last patch is not applied yet.

You don't need to wait so long, just pick mentioned DT lines.

No, because I don't care about Apple products.

@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:
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi#L32-L38
 
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.

No, because I don't care about Apple products.

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.

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:
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi#L32-L38
 
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.

T95 needs different configuration of DRAM driver. Quick and dirty T95 U-Boot port with appropriate defconfig can be found here: https://github.com/jernejsk/u-boot/commits/t95

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.

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.

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.