CSC Armbian for RK3318/RK3328 TV box boards


jock
 Share

23 23

Recommended Posts

@lucky62

The legacy rockchip kernel (the Android one) uses a special driver from rockchip to handle the infrared module, but the mainline kernel uses the standard gpio-ir-receiver driver, which is already in the dtb: https://github.com/paolosabatino/armbian-build/blob/0a7db86c08d77e73c3fba97487d66defa36768ce/patch/kernel/archive/rockchip64-5.10/board-tvbox-rk3318.patch#L199

 

Also the gpio pin of the ir receiver is correcly configured in the armbian dtb, so it should work. I remember I tested on my board and the hardware layer was working.

Maybe you need instead to configure the remote keymapping. For that use you can ir-keyable utility, in particular, ir-keytable -t should help you test the remote. Usually box remotes use the NEC protocol. In the device tree I can also add a "default" keymapping, but actually I forgot to provide one of that and should recompile the image. Tomorrow I will take a look to this too. In the meantime, if you can report that the remote keystrokes are detected by ir-keytable -t may just confirm that the hardware works.

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

25 minutes ago, jock said:

@kruzer it looks like a patch is not applied or sort of. You can take a look into output/debug/patching.log if all the patches are applied correctly, but tomorrow I will take a look myself if the github repo is correctly aligned, can't remember if I have some fixes not yet uploaded in my local repository.

Yes, there is a problem with one patch:

Processing file /Armbian/rk3318/patch/kernel/rockchip64-current/add-csgpio-to-rockchip-spi.patch
1 out of 4 hunks FAILED -- saving rejects to file drivers/spi/spi-rockchip.c.rej

 

spi-rockchip.c.rej

Link to post
Share on other sites

2 minutes ago, kruzer said:

Yes, there is a problem with one patch:


Processing file /Armbian/rk3318/patch/kernel/rockchip64-current/add-csgpio-to-rockchip-spi.patch
1 out of 4 hunks FAILED -- saving rejects to file drivers/spi/spi-rockchip.c.rej

 

spi-rockchip.c.rej 1.27 kB · 0 downloads

Ahh ok, yes I remember the offending patch: it has been fixed in mainline armbian and I just forgot to align the online github repo. Tomorrow I will align. If you're in a hurry, you can even download that patch file from master armbian repository and substitute, it should work.

Link to post
Share on other sites

9 hours ago, jock said:

@lucky62

Maybe you need instead to configure the remote keymapping. For that use you can ir-keyable utility, in particular, ir-keytable -t should help you test the remote. Usually box remotes use the NEC protocol. In the device tree I can also add a "default" keymapping, but actually I forgot to provide one of that and should recompile the image. Tomorrow I will take a look to this too. In the meantime, if you can report that the remote keystrokes are detected by ir-keytable -t may just confirm that the hardware works.

 

Thanks for directing me to the right way.

At first attempt the ir-keytable -t was not working. I was trying to use the different protocols according the LibreElec Infra-Red Remotes page but I was getting the errors:

# ir-keytable -p nec -t
Protocols for device can not be changed
Protocols changed to 
Testing events. Please, press CTRL-C to abort.

Then I read few other web pages and looking into /etc/rc_maps.cfg and found, that my IR device is not the first (rc0):
 

# ir-keytable
Found /sys/class/rc/rc1/ (/dev/input/event2) with:
	Name: gpio_ir_recv
	Driver: gpio_ir_recv, table: rc-empty
	LIRC device: /dev/lirc0
	Attached BPF protocols: Operation not supported
	Supported kernel protocols: other lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon 
	Enabled kernel protocols: lirc 
	bus: 25, vendor/product: 0001:0001, version: 0x0100
	Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc0/ (/dev/input/event1) with:
	Name: dw_hdmi
	Driver: cec, table: rc-cec
	Supported kernel protocols: cec 
	Enabled kernel protocols: cec 
	bus: 30, vendor/product: 0000:0000, version: 0x0001
	Repeat delay = 0 ms, repeat period = 125 ms

 

So I must start the ir-keytable with  -s rc1 parameter then finally got it working:

# ir-keytable -s rc1 -p nec -t
Protocols changed to nec 
Testing events. Please, press CTRL-C to abort.
3009.632067: lirc protocol(necx): scancode = 0xdf0c
3009.632120: event type EV_MSC(0x04): scancode = 0xdf0c
3009.632120: event type EV_SYN(0x00).
3009.684073: lirc protocol(necx): scancode = 0xdf0c repeat
3009.684129: event type EV_MSC(0x04): scancode = 0xdf0c
3009.684129: event type EV_SYN(0x00).
3009.792069: lirc protocol(necx): scancode = 0xdf0c repeat
3009.792121: event type EV_MSC(0x04): scancode = 0xdf0c
3009.792121: event type EV_SYN(0x00).

 

So last point is to find the correct key mapping and make the settings persistent.

 

Link to post
Share on other sites

@lucky62 The key mapping is stored in the kernel, and ir-keytable is a tool to test but also store the key mappings in the kernel, It also allows you to retrieve and restore the whole mapping table at once.

You should use ir-keytable to do the mapping, then retrieve the whole table from the kernel and save it in a file, then restore the table in the kernel on every reboot.

Link to post
Share on other sites

3 hours ago, jock said:

@lucky62 The key mapping is stored in the kernel, and ir-keytable is a tool to test but also store the key mappings in the kernel, It also allows you to retrieve and restore the whole mapping table at once.

You should use ir-keytable to do the mapping, then retrieve the whole table from the kernel and save it in a file, then restore the table in the kernel on every reboot.

Wrong approach, use "ir-keytable -ts rc1" to collect the scancode for any key on your remote control. Drop them in a toml file (man rc_keymap) and assign your linux input key‐codes. When done, check with "ir-keytable --test-keymap=<whatever_name>.toml". If the test is error-free, move <whatever_name>.toml to /etc/rc_keymaps/<whatever_name>.toml and register the file in /etc/rc_maps.cfg such as 

*       rc-empty                 <whatever_name>.toml

as a new last line.
I recently did this for my FRIENDLYARM RC-100, see friendlyarm_rc-100.toml as reference. This way a udev rule picks up the keymap als soon as the rc kernel device is detected and the remote is working out of the box after every reboot.
Now start collecting of <whatever_name>.toml files for any available remote control with the prefered keymapping and drop them in your distribution. This way choosing a remote control is only a registration in rc_maps.cfg away. Replace "rc-empty" if your remote reports a different keymap: 

# ir-keytable
Found /sys/class/rc/rc1/ (/dev/input/event2) with:
    Name: gpio_ir_recv
    Driver: gpio_ir_recv, table: rc-empty
    ...

 

friendlyarm_rc-100.toml

Link to post
Share on other sites

18 minutes ago, kruzer said:

It looks ok, I can't see any big difference to mine: http://ix.io/3nfR.

Does multitool boot on this box with hdmi? You can compare this log to dmesg form multitool, check if the hdmi lines look similar.

 

I see some minor? differences.. 

 

Multitool: 

[    1.109368] dwhdmi-rockchip ff3c0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (inno_dw_hdmi_phy2)
[    1.120107] dwhdmi-rockchip ff3c0000.hdmi: registered DesignWare HDMI I2C bus driver
[    1.128859] rockchip-drm display-subsystem: bound ff3c0000.hdmi (ops 0xffffff8008b12088)

 

Yours:

[    4.851954] dwhdmi-rockchip ff3c0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (inno_dw_hdmi_phy2)
[    4.854533] dwhdmi-rockchip ff3c0000.hdmi: registered DesignWare HDMI I2C bus driver
[    4.856289] rockchip-drm display-subsystem: bound ff3c0000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm])

 

 

Multitool (lines I am unsure about):

[    0.291795] phy phy-ff430000.hdmiphy.0: Looking up phy-supply from device tree
[    0.291821] phy phy-ff430000.hdmiphy.0: Looking up phy-supply property in node /hdmiphy@ff430000 failed

[    1.073401] rockchip-drm display-subsystem: Linked as a consumer to ff3c0000.hdmi

[    1.103000] ERROR: could not get clock /hdmi@ff3c0000:hclk_vio(3)

 

Yours:

[   11.002844] rc rc0: dw_hdmi as /devices/platform/ff3c0000.hdmi/rc/rc0
[   11.003165] input: dw_hdmi as /devices/platform/ff3c0000.hdmi/rc/rc0/input0

 

Link to post
Share on other sites

4 hours ago, Dragao said:

I see some minor? differences.. 

I hoped for more descriptive errors, but those give no clue. Next step is to compare dtb extracted from original android image, do you have a backup?

Link to post
Share on other sites

53 minutes ago, kruzer said:

I hoped for more descriptive errors, but those give no clue. Next step is to compare dtb extracted from original android image, do you have a backup?

Yes I have made a backup with the Multitool. 

You want to whole backup ? 

 

Link to post
Share on other sites

37 minutes ago, Dragao said:

You want to whole backup ? 

 

No, only dtb is needed to compare, try the instructions provided here by @lucky62

If you don't have su preinstalled on android, I will show you how I did it from backup, but some listings from running android will be required.

Link to post
Share on other sites

8 hours ago, usual user said:

Wrong approach, use "ir-keytable -ts rc1" to collect the scancode for any key on your remote control. Drop them in a toml file (man rc_keymap) and assign your linux input key‐codes. When done, check with "ir-keytable --test-keymap=<whatever_name>.toml". If the test is error-free, move <whatever_name>.toml to /etc/rc_keymaps/<whatever_name>.toml and register the file in /etc/rc_maps.cfg

Hello UU, :D

I followed you guide, I grabbed all the codes and have created the toml file, copied to the /etc/rc_keymaps and registered in /etc_rc_maps.cfg. It is working. But...

 

My remote has the few special keys, like Youtube, Netflix, TV control keys. These are also in my toml file, but names are not recognized by driver. Seems that key names must be only from defined set. What are the allowed names?

 

Second point not clear to me - how are the KEYs mapped to system/program actions?

For example - I would like to open YouTube in the browser when I will press the YouTube KEY, how to do?

 

Keys defined in my toml file (keys marked with * are not recognized):

0xdf06 = "KEY_OK"
0xdf1a = "KEY_UP"
0xdf48 = "KEY_DOWN"
0xdf47 = "KEY_LEFT"
0xdf07 = "KEY_RIGHT"
0xdf42 = "KEY_HOME"
0xdf0a = "KEY_BACK"
0xdf18 = "KEY_MENU"
0xdf03 = "KEY_MODE"
0xdf54 = "KEY_1"
0xdf16 = "KEY_2"
0xdf15 = "KEY_3"
0xdf50 = "KEY_4"
0xdf12 = "KEY_5"
0xdf11 = "KEY_6"
0xdf4c = "KEY_7"
0xdf0e = "KEY_8"
0xdf0d = "KEY_9"
0xdf0c = "KEY_0"
0xdf41 = "KEY_FN"
0xdf10 = "KEY_DEL"		*
0xdf5d = "KEY_VOLUMEUP"
0xdf5c = "KEY_VOLUMEDOWN"
0xdf4b = "KEY_YOUTUBE"	*
0xdf4f = "KEY_NETFLIX"	*
0xdf5f = "KEY_HELP"
0xdf01 = "KEY_PLAY"
0xdf1c = "KEY_POWER"
0xdff1 = "KEY_TVPOWER"	*
0xdff2 = "KEY_TVOUTPUT"	*
0xdff3 = "KEY_TVMUTE"	*
0xdff4 = "KEY_TVVOLUMEDOWN"	*
0xdff5 = "KEY_TVVOLUMEUP"	*

 

 

x88pro10_remote.png

Link to post
Share on other sites

51 minutes ago, lucky62 said:

My remote has the few special keys, like Youtube, Netflix, TV control keys. These are also in my toml file, but names are not recognized by driver. Seems that key names must be only from defined set. What are the allowed names?

You cannot invent keycodes randomly, you must use the keycodes known to the input event system. "man rc_keymap" SEE ALSO

Quote

 

53 minutes ago, lucky62 said:

Second point not clear to me - how are the KEYs mapped to system/program actions?

For example - I would like to open YouTube in the browser when I will press the YouTube KEY, how to do?

Same way as done for any emitted key of your keyboard. User space cannot distinguish which input device emitted the keycode. Desktop environments typically have "shortcut keys" setup tools in the Settings pane.

Link to post
Share on other sites

59 minutes ago, lucky62 said:

My remote has the few special keys, like Youtube, Netflix, TV control keys. These are also in my toml file, but names are not recognized by driver. Seems that key names must be only from defined set. What are the allowed names?

The keycodes are defined in this kernel header file (look for the KEY_ constants).

Youtube, netflix and others are purely userspace programs. What I would do is map the remote keys to KEY_FN_13, KEY_FN_14 and above, and then use an userspace program (I think xfce has some utility that already allows that) that on KEY_FN_13, KEY_FN_14, ... opens the program you want.

 

edit: you may map the remote keys to KEY_FN_12, KEY_FN_11, and below, map the keystrokes to the userspace program you like, so if you hit F12, F11, ... keys on the keyboard the trigger the same program as the remote.

 

Link to post
Share on other sites

On 5/22/2021 at 1:00 PM, jock said:

Hi @nerdherd96 , welcome to the forum :thumbup:

 

HDMI issue is just a news, it is rare but sometimes happens that a box has an incompatibility of some kind. I think @Dragao has the same issue you have, but he didn't report he try to access via ssh AFAIK so can't be sure.

 

Usually it is related to some internal timing calculations done in the kernel to accomodate HDMI signals of the various devices, something that works on a setup may not work on another.

Are you trying the box with an HDMI monitor or an HDMI television? If you have the chance, change the cable with another one of another quality or test the box on another TV/monitor and see if you solve the issue. In the meantime I could take a look if there are some patches, especially done by LibreELEC guys, that may bring better HDMI compatibility.

 

Do those tests if you can and want, maybe later we can hangout on telegram!

I'll let you know! My telegram Is Always on @nerdherd96

Maybe it's a display compatibility problem, but the display shows well until the desktop start. Maybe it's a x11 or lightdm miscofiguration. I would like to know where to take the right logs.

Link to post
Share on other sites

8 hours ago, usual user said:

You cannot invent keycodes randomly, you must use the keycodes known to the input event system. "man rc_keymap"

 

8 hours ago, jock said:

The keycodes are defined in this kernel header file (look for the KEY_ constants).

 

Thanks for explanation. So I understand that I must map my special keys to some keys defined in input_event_codes.h

 

Looking into the file I see that there is a lot of defined keys which I will never have. But I cannot simply use the names on my remote... :(


Current implementation was good when linux was used only on computers with more or less fixed set of keys on keyboard.

But nowadays there is a lot of devices with very different functions (very different input devices) so it will be better to allow user defined keys beside fixed set of standard keys... My opinion... ;)

 

Link to post
Share on other sites

8 hours ago, nerdherd96 said:

I'll let you know! My telegram Is Always on @nerdherd96

Maybe it's a display compatibility problem, but the display shows well until the desktop start. Maybe it's a x11 or lightdm miscofiguration. I would like to know where to take the right logs.

Oh ok, I understand. Maybe try to do apt update && apt upgrade via ssh or via virtual terminal, there was a bug in lightdm display manager that was causing issues during X.org boot.

If you see the bootstrap messages then your HDMI should be fine

Link to post
Share on other sites

2 hours ago, lucky62 said:

But nowadays there is a lot of devices with very different functions (very different input devices) so it will be better to allow user defined keys beside fixed set of standard keys... My opinion... ;)

You need the userspace program to support them too, so you're back to the original problem.

IMHO there already are hundreds of "abstract" keys (all the KEY_* constants) in the kernel you can use to map any device, I don't exclude that you can use hex values to specify custom key maps, but still the userspace has to catch those custom keymaps to do something useful, so I don't think it is really a kernel problem.

Link to post
Share on other sites

8 minutes ago, jock said:

I don't think it is really a kernel problem.

 

It's about the philosophy...
Why these (for example) are in the kernel directly?
 

#define KEY_FINANCE		219
#define KEY_SPORT		220
#define KEY_SHOP		221

 

For these I also need a userspace program...

 

Why I need to map the physical key YouTube to something unclear/misleading (e.g. KEY_FN_13) when I simply need to start the YouTube?... :-)

 

It will be much better to allow user defined keys...

 

Link to post
Share on other sites

14 minutes ago, lucky62 said:

 

It's about the philosophy...
Why these (for example) are in the kernel directly?
 


#define KEY_FINANCE		219
#define KEY_SPORT		220
#define KEY_SHOP		221

 

For these I also need a userspace program...

 

Why I need to map the physical key YouTube to something unclear/misleading (e.g. KEY_FN_13) when I simply need to start the YouTube?... :-)

 

It will be much better to allow user defined keys...

 

I understand what you mean, but IMHO finance, sport and shop are "abstract" and generic entities whose keys can exist on some remotes (or other devices), like old tablets and mobile-like devices with physical keys (like blackberrys, for example).

Youtube and Netflix are just private companies that tomorrow may disappear or be superseded by others. I don't think there are license issues, but a picky lawyer may want to put a trademark there too...

Link to post
Share on other sites

16 minutes ago, jock said:

Youtube and Netflix are just private companies that tomorrow may disappear or be superseded by others. I don't think there are license issues, but a picky lawyer may want to put a trademark there too...

#define KEY_HP			211

 

Probably Horse Power?....   :D

 

EDIT: idea is not to add more and more keys into the kernel, but allow the user-defined keys and clean the kernel code (keep only required and most commonly used keys).

Link to post
Share on other sites

13 hours ago, kruzer said:

No, only dtb is needed to compare, try the instructions provided here by @lucky62

If you don't have su preinstalled on android, I will show you how I did it from backup, but some listings from running android will be required.

I have rooted my android with Magisk and I have the dtb file 

I have also extracted the dtb from the recovery because it is different (in naming)

 

files can be found here: link

Link to post
Share on other sites

2 hours ago, jock said:

Oh ok, I understand. Maybe try to do apt update && apt upgrade via ssh or via virtual terminal, there was a bug in lightdm display manager that was causing issues during X.org boot.

If you see the bootstrap messages then your HDMI should be fine

Nothing ti do. Also with lxdm, once DM starts, screen goes off. If i stop the dm with systemctl, the console reappears.

Link to post
Share on other sites

11 hours ago, nerdherd96 said:

I'll let you know! My telegram Is Always on @nerdherd96

Maybe it's a display compatibility problem, but the display shows well until the desktop start. Maybe it's a x11 or lightdm miscofiguration. I would like to know where to take the right logs.

Just would like to point out that there is no display at all. Not even for the non graphical part. 

I am not interested in a GUI so for me if I can get the cli to work work be just fine.  but I have same results using a console version of Focal. I have only output on the serial console not through HDMI

Link to post
Share on other sites

Hi there! First of all, thanks @jock for your work! I've managed to run the non-legacy on my X88Pro 10 4G/64G android tv box (I think it's the same as you @lucky62).

Then I saw your note about hardware acceleration and tried the legacy one so that I can then install media-rk3328 to have kodi, and I first realised there was no rk3318-config on the legacy image. I tried to copy the script from the the newer image but I'm far from being an expert in overlays and co... It seems that the rk3318-box-wlan-ext is either not there or not working since the wifi isn't showing up.

 

So I was wondering @lucky62 if you could share your work on github or so. I know you're not on legacy branch but either you succeed on enabling HW acceleration and I'd then switch back to 5.x kernel, or I could dig in the diff from your repo to try to make the wifi, IR and LCD work for legacy kernel. Even if I can't make it work I'd learn a lot and maybe endup watching kodi in ASCII art lol.

 

Also IDK if you saw but I've posted on GitHub a question related to the pic you posted there: I saw you added a fan, is it plugged directly on the board? If yes, could you share a pic on where you did plug it?

 

Thanks in advance for anything you could help me with, will be really appreciated! I'll now open the box and try to got UART console working as you explained in some post I read above here.

Link to post
Share on other sites

  • jock changed the title to CSC Armbian for RK3318/RK3328 TV box boards
 Share

23 23