What about RT linux?

Hi, radxa team and RockPi4 users :slight_smile:

I want to make a custom OS build with kernel patched by the RT-PREEMPT patch. What the best way to do that?

I saw original rockchip-linux repo has the develop-4.4-rt176 branch. Offcourse, this branch has no latest commits from the radxa’s release-4.4-rockpi4 branch.

Is it possible to use develop-4.4-rt176 branch while building the custom OS image using https://github.com/radxa/rockchip-bsp? Or I must to apply the RT-PREEMPT patch manually to the radxa’s release-4.4-rockpi4?

Similar unanswered topic - PREEMPT-RT Kernel

You can try to apply the ROCK Pi 4 patches from the release-4.4-rockpi4 branch to the develop-4.4-rt176 branch. I think there will not be much conflicts. Or you can just copy the ROCK Pi 4 device tree and build in the develop-4.4-rt176 branch. It should work.

1 Like

Thanks. I will try these methods soon and will report about my results.

1 Like

@MX_Master, just curious if you did get the develop-4.4-rt176 kernel up and running? I am currently without a Rock Pi 4 to test it on, so all I can do is verify that kernel and image build correctly.

Don’t have any RockPi4 boards yet :slight_smile: I can confirm the develop-4.4-rt176 branch build is successful. I’ll test it when my first board will arrive to me :smile:

You can also try the latest upstream kernel. At least on my board this works out of the box. I haven’t tested all features though. But I guess that a proper patched upstream RT kernel should work as well.

Switching to a mainline kernel would entail porting some of the Rockchip specific drivers (e.g. ap6256 / bcm43456). On the other hand, the Rockchip kernel has some quirks like hidden dependencies (i.e. call dependencies not reflected in Kconfig) that make tailoring it rather difficult.

The first 5.x.y branch to appear in linux-stable-rt would probably be a good starting point.

mainline ap6256 patch is sent recently.

https://lkml.org/lkml/2019/5/28/911

1 Like

Thank you @jack! And will brcmfmac support the chip? Linux Wireless lists only BCM43455 at the moment.

BCM43455 and BCM43456 can use the same driver, the difference should be only the firmware. Actually the firmware of BCM43455 can work on BCM43456.

But we actually haven’t tested the wifi/bt on 5.2 kernel yet.

I was able to test Rockchip branch develop-4.4-rt176 recently, but without success. I used radxa-rockpi-4b-linux.dts and also transferred and enabled overlays from Radxa’s repository. The kernel boots but runs into a problem with Mali. It ends up running in circles with this error sequence:

[    2.809253] [drm] Rockchip DRM driver version: v1.0.1
[    2.810022] rockchip-drm display-subsystem: dmc is disabled
[    2.810794] rockchip-vop ff900000.vop: missing rockchip,grf property
[    2.811686] rockchip-drm display-subsystem: bound ff900000.vop (ops 0xffffff80088d2c38)
[    2.812431] rockchip-vop ff8f0000.vop: missing rockchip,grf property
[    2.813186] rockchip-drm display-subsystem: bound ff8f0000.vop (ops 0xffffff80088d2c38)
[    2.813900] rockchip-drm display-subsystem: failed to bind ff960000.dsi (ops 0xffffff80088c9818): -517
[    2.815111] rockchip-drm display-subsystem: master bind failed: -517

It seems to be DTS related, earlier there was a stack trace:

[    2.548970] [drm] Rockchip DRM driver version: v1.0.1
[    2.549668] rockchip-drm display-subsystem: dmc is disabled
[    2.550427] rockchip-vop ff900000.vop: missing rockchip,grf property
[    2.551249] rockchip-drm display-subsystem: bound ff900000.vop (ops 0xffffff80088d2c38)
[    2.552017] rockchip-vop ff8f0000.vop: missing rockchip,grf property
[    2.552841] rockchip-drm display-subsystem: bound ff8f0000.vop (ops 0xffffff80088d2c38)
[    2.553555] rockchip-drm display-subsystem: failed to bind ff960000.dsi (ops 0xffffff80088c9818): -517
[    2.554919] rockchip-drm display-subsystem: master bind failed: -517
[    2.556987] mali ff9a0000.gpu: GPU identified as 0x0860 r2p0 status 0
[    2.557792] mali ff9a0000.gpu: Protected mode not available
[    2.559236] mali ff9a0000.gpu: l=0 h=2147483647 hyst=5000 l_limit=0 h_limit=0
[    2.559992] ERROR: Bad of_node_put() on /gpu@ff9a0000
[    2.559999] CPU: 2 PID: 7 Comm: kworker/u12:0 Not tainted 4.4.167-rt176 #4
[    2.560000] Hardware name: ROCK PI 4B (DT)
[    2.560016] Workqueue: deferwq deferred_probe_work_func
[    2.560018] Call trace:
[    2.560027] [<ffffff800808558c>] dump_backtrace+0x0/0x1c4
[    2.560032] [<ffffff8008085764>] show_stack+0x14/0x1c
[    2.560039] [<ffffff80083031e0>] dump_stack+0x98/0xc0
[    2.560048] [<ffffff80086034ec>] of_node_release+0x34/0xa8
[    2.560053] [<ffffff8008305418>] kobject_put+0xa0/0xc0
[    2.560057] [<ffffff8008602c14>] of_node_put+0x14/0x20
[    2.560062] [<ffffff80085ffdbc>] of_find_compatible_node+0x4c/0xa0
[    2.560066] [<ffffff800847305c>] get_model_dt_node+0x44/0x84
[    2.560070] [<ffffff8008473418>] kbase_ipa_model_add_param_string+0x34/0xe8
[    2.560073] [<ffffff8008472fc0>] kbase_simple_power_model_init+0x120/0x178
[    2.560076] [<ffffff8008473580>] kbase_ipa_init_model+0x70/0xb0
[    2.560079] [<ffffff8008473680>] kbase_ipa_init+0xc0/0x184
[    2.560086] [<ffffff8008480a90>] kbase_devfreq_init+0x430/0x4a4
[    2.560091] [<ffffff80084696e4>] kbase_platform_device_probe+0x7ac/0xa90
[    2.560096] [<ffffff800848845c>] platform_drv_probe+0x54/0xa8
[    2.560100] [<ffffff8008486d74>] driver_probe_device+0x17c/0x25c
[    2.560104] [<ffffff8008486f84>] __device_attach_driver+0x60/0x9c
[    2.560107] [<ffffff80084854a0>] bus_for_each_drv+0x7c/0x8c
[    2.560111] [<ffffff8008486b6c>] __device_attach+0xa4/0xf8
[    2.560115] [<ffffff80084870f0>] device_initial_probe+0x10/0x18
[    2.560119] [<ffffff8008486264>] bus_probe_device+0x2c/0x8c
[    2.560122] [<ffffff8008486698>] deferred_probe_work_func+0x78/0x8c
[    2.560128] [<ffffff80080a23dc>] process_one_work+0x1b0/0x294
[    2.560132] [<ffffff80080a3624>] worker_thread+0x27c/0x3bc
[    2.560137] [<ffffff80080a7a2c>] kthread+0xcc/0xdc
[    2.560142] [<ffffff80080823f0>] ret_from_fork+0x10/0x20

The full boot log can be found here.

1 Like

Try to remove the MIPI stuff in the DTS. We have enabled two displays(vopb and vopl) for the current branch. The mipi display is enabled by default, you can remove that in dts. It should boots. We have confirmed with Rockchip engineer that the rt branch is working.

1 Like

Thank you @jack for the hint. I set the dsi node to “disabled” and removed MIPI DSI driver support from the kernel kconfig. The system boots and seems to run stable.

Some errors in boot log due to the kernel not being able to add devices - probably a mismatch between the copied Radxa DTS file and the DTSi files included from the Rockchip branch.

The bad of_node_put() on /gpu@ff9a0000 stack trace is still present. During shutdown the system hangs due to multiple exceptions, most of them in rt_mutex_lock()

Scheduling latencies are different, but not significantly lower than with the standard Radxa kernel.

  Kernel	Latency +/- SD (us)	Max Latency
  4.4.154	29.8 +/- 11.986		49.0
  4.4.167-rt176	25.9 +/- 11.631		45.0

Seems like some more investigation is necessary.

1 Like

Patch for Linux kernel version 5.2 is released: patch-5.2-rt1.patch

2 Likes

Hello!
Are there any news about successful RT linux build?