[WIP]rockchip64: bump rockchip64-edge kernel to 6.5 #5657

amazingfate · 2023-08-30T17:29:19Z

Description

Patches are updated and build is successful. I haven't tested the kernel yet.
Here are patch fixes:
1, add-rockchip-iep-driver.patch: rk3288.dtsi is moved to arch/arm/boot/dts/rockchip/rk3288.dtsi
2, general-possibility-of-disabling-rk808-rtc.patch: drivers/mfd/rk808.c is moved to drivers/mfd/rk8xx-core.c
3, rk356x-rga.patch: removed becaused of upstream merged
4, board-rockpis-0001-arm64-dts.patch: fixed due to upstream change
5, board-nanopi-r2c-plus.patch: new added patch fixing missing &vcc_io_33

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

Patches are all applied
Kernel build is successfull

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation
My changes generate no new warnings
Any dependent changes have been merged and published in downstream modules

rpardini · 2023-08-31T16:28:43Z

Cherry-picked, built, builds OK. Rebased, OK.
Tested on

✅ Tinkerboard-2: OK, all fine.
🟥 RockPro64: boots but fails (full dmesg) and network does not come up. Maybe this is related to some of our rp64 patches?

rpardini · 2023-08-31T16:34:22Z

(also on RockPro64)

# cat /sys/kernel/debug/devices_deferred
ff320000.syscon:io-domains	platform: wait for supplier /i2c@ff3c0000/pmic@1b/regulators/LDO_REG8
ff770000.syscon:io-domains	platform: wait for supplier /i2c@ff3c0000/pmic@1b/regulators/LDO_REG4
serial0-0	serial: wait for supplier /i2c@ff3c0000/pmic@1b/regulators/DCDC_REG4
sound-dit	asoc-audio-graph-card: parse error
fe300000.ethernet	platform: wait for supplier /i2c@ff3c0000/pmic@1b/regulators/SWITCH_REG1
sdio-pwrseq	pwrseq_simple: external clock not ready
fe310000.mmc
ff100000.saradc	platform: supplier vcc1v8-s3 not ready
avdd-regulator	platform: wait for supplier /i2c@ff3c0000/pmic@1b/regulators/SWITCH_REG2
fe320000.mmc	platform: wait for supplier /i2c@ff3c0000/pmic@1b/regulators/LDO_REG4
vcc1v8-s3	platform: wait for supplier /i2c@ff3c0000/pmic@1b/regulators/DCDC_REG4
cpufreq-dt

rpardini · 2023-08-31T16:52:32Z

@amazingfate added the rebase for the patches, just so work is not lost. Hope you don't mind.

amazingfate · 2023-08-31T17:01:05Z

sdio-pwrseq pwrseq_simple: external clock not ready

I think this is a fix for this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/rockchip?h=v6.5&id=ebceec271e552a2b05e47d8ef0597052b1a39449

There are a lot of vcc supplies not ready, but upstream 6.5 doesn't have change for rockpro64's devicetree.

amazingfate · 2023-08-31T17:26:58Z

@rpardini for rockpro64, what about trying kernel arg fw_devlink=on or fw_devlink=off?
I encountered waiting for suppliers issues long time ago and the fw_devlink arg did solve it.

rpardini · 2023-08-31T17:43:32Z

@rpardini for rockpro64, what about trying kernel arg fw_devlink=on or fw_devlink=off?

Indeed, fw_devlink=on brings back the USB3 so I can use a USB3 ethernet, but not much else. Thanks, with this I can recover to previous kernel without reimaging it.

I encountered waiting for suppliers issues long time ago and the fw_devlink arg did solve it.

Yeah, but consider the rp64 was OK in 6.4.y.... I'm gonna take a look at our patches, a lot of rp64 stuff in there.

rpardini · 2023-08-31T18:10:42Z

ff320000.syscon:io-domains platform: wait for supplier /i2c@ff3c0000/pmic@1b/regulators/LDO_REG8

Hmm @amazingfate. pmic@1b is actually a "rockchip,rk808" -- this might be exactly the same we've encountered in 6.5-rcX for 3588, 3568, etc; see https://lore.kernel.org/all/20230518040541.299189-2-sebastian.reichel@collabora.com/ @efectn

I'm reworking the .config and will test.

rpardini · 2023-08-31T18:36:44Z

actually a "rockchip,rk808" -- this might be exactly the same we've encountered in 6.5-rcX for 3588, 3568, etc

Bingo. When I re-enabled the RK808, Paolo's patch broke; I fixed it, and RockPro64 works now.

Feel free to squash the commits I pushed.

schwar3kat · 2023-08-31T19:09:42Z

I ran a quick test last night on Orange Pi R1 Plus LTS (RK3328) did not boot.
That was before @rpardini changes.
I will test again later with the changes.

rpardini · 2023-08-31T19:30:46Z

I will test again later with the changes.

Yes, could be, since CONFIG_MFD_RK808 "Rockchip RK805/RK808/RK809/RK817/RK818 Power Management Chip", and the Orange Pi R1 Plus LTS uses a RK805.

schwar3kat · 2023-08-31T21:40:41Z

Yes, could be, since CONFIG_MFD_RK808 "Rockchip RK805/RK808/RK809/RK817/RK818 Power Management Chip", and the Orange Pi R1 Plus LTS uses a RK805.

Orange Pi R1 Plus LTS - booting got further this time, starting the kernel. No networking.

extraargs="fw_devlink=on" makes no difference. Using dtb from 6.4 makes no difference.

I eventually managed to retrieve the hardware log.
I think that I've found where the issue is. This board uses trigger=netdev to drive front LED's for network activity and this is somehow corrupting systemd system. Two serial getty config files sometimes go missing. If I remove the LED config from the armbian-leds.conf file and replace the missing config files, it boots and works.

Relevant log section:
[[ 98.884788] systemd[1]: dev-ttyGS0.device: Job dev-ttyGS0.device/start timed out.
[ 98.885557] systemd[1]: Timed out waiting for device dev-ttyGS0.device - /dev/ttyGS0.
[ 98.896295] systemd[1]: Dependency failed for serial-getty@ttyGS0.service - Serial Getty on ttyGS0.
[ 98.908214] systemd[1]: serial-getty@ttyGS0.service: Job serial-getty@ttyGS0.service/start failed with result 'dependency'.
[ 98.909363] systemd[1]: dev-ttyGS0.device: Job dev-ttyGS0.device/start failed with result 'timeout'.
[ 131.384767] systemd[1]: armbian-zram-config.service: State 'final-sigterm' timed out. Killing.

lanefu · 2023-09-01T03:44:20Z

Tested it on my PBP, and abused it pretty hard... wifi, bluetooth, sound.. panfrost. all good

https://paste.armbian.com/vetihuqaqu

schwar3kat · 2023-09-02T00:27:10Z

Orange Pi R1 Plus LTS - booting got further this time, starting the kernel. No networking.

This issue is caused by a change in the format of the netdev trigger parameters and the armbian-led-state.service, armbian-led-state-save.sh and armbian-led-state-restore.sh not being able to handle it.

If I set the netdev trigger manually as follows, the LED's behave as expected:

echo netdev | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/trigger
echo lan0 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/device_name
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/link
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/tx
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/rx
echo netdev | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/trigger
echo eth0 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/device_name
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/link
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/tx
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/rx

If I modify the armbian-led-state-restore.sh script to exit0 at the start of the script so that it does not execute on startup, then the device boots (without restoring the LED's). If I remove the exit0 set the LED's manually and reboot then the device fails to boot.

iav · 2023-09-02T02:06:38Z

Try to build Helios64, boot from sdcard.
Seems all works.
dmesg http://termbin.com/blhpy

paolosabatino · 2023-09-02T14:09:16Z

Tested on Opi4-LTS (rk3399), wifi, bluetooth, hdmi, emmc, sdcard, USB2 tested and works but:

I missed to port some fixes to the device tree from 6.3 to 6.4, so I have to fix the dts on 6.5 too
there are occasional issues with USB3 phy that could not get initialized:

[    2.541242] phy phy-ff800000.phy.6: phy poweron failed --> -110
[    2.542011] dwc3 fe900000.usb: error -ETIMEDOUT: failed to initialize core
[    2.542769] dwc3: probe of fe900000.usb failed with error -110

Full log at https://paste.armbian.com/ohewilejaq

I don't know if other are having such issues with usb3 phy, in the device tree nothing changed and the whole phy definition comes from the base rk3399.dtsi (the device label is tcphy1)

Going to investigate a bit into

paolosabatino · 2023-09-02T14:59:52Z

Tested on CSC Rockpi-E (rk3328), boots and works pretty well, both ethernet ports work fine, but 8821cu onboard wifi chip hangs with:

[   46.611008] rtw_8821cu 3-1:1.2: failed to download firmware
[   46.615383] rtw_8821cu 3-1:1.2: leave idle state failed
[   46.623381] rtw_8821cu 3-1:1.2: failed to send h2c command
[   46.638258] rtw_8821cu 3-1:1.2: failed to send h2c command
[   46.646008] rtw_8821cu 3-1:1.2: failed to send h2c command
[   46.654882] rtw_8821cu 3-1:1.2: failed to leave ips state
[   46.654898] rtw_8821cu 3-1:1.2: failed to leave idle state

the firmware file looks like is in the right place, but the driver isn't able to proceed further and the wifi chip isn't able to connect to local router.

paolosabatino · 2023-09-02T16:22:51Z

Tested a couple of rk3318/rk3328 tv boxes: armbian boots but there is no HDMI output at all on both. These boards worked fine with 6.1 kernel.
This is bad news because rk3328 supported boards may have regressed as well, need to figure it out this as well ☹️

paolosabatino · 2023-09-02T16:38:11Z

Orange Pi R1 Plus LTS - booting got further this time, starting the kernel. No networking.

This issue is caused by a change in the format of the netdev trigger parameters and the armbian-led-state-save.sh and armbian-led-state-restore.sh used by armbian-led-state.service not being able to handle it.

If I set the netdev trigger manually as follows, the LED's behave as expected:
echo netdev | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/trigger
echo lan0 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/device_name
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/link
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/tx
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:lan/rx
echo netdev | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/trigger
echo eth0 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/device_name
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/link
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/tx
echo 1 | sudo tee /sys/class/leds/orangepi-r1-plus-lts:green:wan/rx
If I modify the armbian-led-state-restore.sh script to exit0 at the start of the script so that it does not execute on startup, then the device boots (without restoring the LED's). If I remove the exit0 set the LED's manually and reboot then the device fails to boot.

Could you run the two .sh scripts manually as superuser and report the error you get?
The scripts should just skip over if something fails, so it is quite strange systemd fails to boot the system. Perhaps the .service file can also be fixed to say the service is not critical

edit: btw, I don't have "netdev" argument for the trigger file, did you enabled it in the kernel config by hand?
edit2: just checked adding exit 1 in restore script, the system boots anyway and I correctly see the failed status:

root@rk3318-box:~# systemctl status armbian-led-state
× armbian-led-state.service - Armbian leds state
     Loaded: loaded (/lib/systemd/system/armbian-led-state.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sat 2023-09-02 18:45:31 CEST; 1min 34s ago
    Process: 244 ExecStart=/usr/lib/armbian/armbian-led-state-restore.sh (code=exited, status=1/FAILURE)
   Main PID: 244 (code=exited, status=1/FAILURE)
        CPU: 63ms

Sep 02 18:45:39 rk3318-box armbian-led-state-restore.sh[244]: just failing on purpose

schwar3kat · 2023-09-02T23:05:52Z

Could you run the two .sh scripts manually as superuser and report the error you get?

@paolosabatino - I have been working on debugging this. The scripts behave as expected if run manually with some issues that I have worked around. The extra netdev parameters in the save file caused the valid parameters to be removed on restore.
The brightness parameter has another issue. If no network cable is plugged in then when a save is done brightness saves as 0 for that device.

The scripts are working manually. I initially thought that they needed changes, but it was a partial restore that confused me.

The restore script caused the boot to fail, even if I set all exit 1 to exit 0.
When I modified the service to run later after ~~network,~~ timers the board booted, ~~but does not restore correctly yet (I suspect that some parameters can't be set until later still).~~ I suspect that the changes to ledtrig_netdev only configure the /sys/class parameters after the network is initialized. I have no idea why the script bombs the boot when applied early and there are no details in the boot output.

Edit: Modifying the service to use After=timers.target fixes all issues. The question is: would this detrimentally affect other LED triggers?

#Before=sysinit.target
#After=local-fs.target
After=timers.target

My board might be the only one that uses netdev by default and it is not an essential function.

btw, I don't have "netdev" argument for the trigger file, did you enabled it in the kernel config by hand?

MODULES="ledtrig_netdev" in the board file.

orangepi-r1plus-lts.conf.txt

This modified file works on this board with ledtrig_netdev:
armbian-led-state.service.txt
armbian-led-state-save.sh.txt
armbian-led-state-restore.sh.txt
It turns out that we only need to delay the service then the other files work.

~~I suspect that this is not only a rockchip64 issue~~
Edit: I'm not seeing the same delay issue on orangepizeroplus (Allwinner H5) on 6.5.0-edge-sunxi64.

Is this only my board or all of rockchip64? I don't have another suitable board to test.
I suggest that we merge and deal with this separately. unless we can be sure that the service change won't affect other LED functionality,

paolosabatino · 2023-09-03T12:21:29Z

@schwar3kat you found a quite interesting issue; actually the restore script is set, in the service, to boot as early as possible skipping the "default" dependencies check. (see

build/packages/bsp/common/lib/systemd/system/armbian-led-state.service

Line 10 in 531de6c

DefaultDependencies=no

)

Why you need to start the script after timers target in systemd since it should be a kernel-only setting amuses me, but it can indeed be changed in the service file to fix the issue. It would be nice to understand why this happens to avoid possible breakage of such kind in other situations though.

schwar3kat · 2023-09-03T20:29:28Z

It would be nice to understand why this happens

I would like to know if it is all rockchip64, or rk3328/33xx, or only this one board, or some other functionality, but I don't have other boards to test, and I don't know of any other board using this trigger.

I'm not 100% sure whether it is safe to modify the armbian-led-state.service order for all boards. I suspect that it is probably safe, and it would be a universal fix. Maybe we should do this and see if there are complaints?
We can fix it for only this orangepi-r1plus-lts board, by overwriting the service file using a post_family_tweaks_bsp function in the board file. This may be the safest option but its not a universal fix.

@paolosabatino - What would you advise?

I have created Jira issue AR-1857

paolosabatino · 2023-09-03T21:42:20Z

I'm not 100% sure whether it is safe to modify the armbian-led-state.service order for all boards. I suspect that it is probably safe, and it would be a universal fix. Maybe we should do this and see if there are complaints?
We can fix it for only this orangepi-r1plus-lts board, by overwriting the service file using a post_family_tweaks_bsp function in the board file. This may be the safest option but its not a universal fix.

I agree with fixing for all the devices moving after timers; moving back and forth in the boot order should cause no harm to the script which in turn is quite simple task and actually only requires access to rootfs and /sys filesystems. Perhaps the issue is not the script precedence/order in itself but (uneducated guess follows) the kernel module for the netdev trigger may have some internal issues or kind of cyclic dependency making the system unable to boot when it is instructed too early.

schwar3kat

I'm happy for this to be merged when other maintainers agree.
The issue with Orange Pi R1 Plus LTS is being dealt with in AR-1875

rpardini

I'd say merge it, that way it is easier for moar peeps to get involved....

igorpecovnik

lets do it, yes

rpardini

2nd try

… bunch of RK stuff disappears: ``` CONFIG_INPUT_RK805_PWRKEY=y CONFIG_PINCTRL_RK805=y CONFIG_CHARGER_RK817=m CONFIG_MFD_RK808=y CONFIG_REGULATOR_RK808=y CONFIG_SND_SOC_RK817=m CONFIG_RTC_DRV_RK808=y CONFIG_COMMON_CLK_RK808=y ```

…isappeared, replaced by `MFD_RK8XX_I2C` and `MFD_RK8XX_SPI` - restore the victims as well ``` CONFIG_INPUT_RK805_PWRKEY=y CONFIG_PINCTRL_RK805=y CONFIG_CHARGER_RK817=m CONFIG_REGULATOR_RK808=y CONFIG_SND_SOC_RK817=m CONFIG_RTC_DRV_RK808=y CONFIG_COMMON_CLK_RK808=y ```

…ch-voltage-steps.patch` (client_dev -> dev)

alex3d · 2023-09-16T08:34:58Z

Tested a couple of rk3318/rk3328 tv boxes: armbian boots but there is no HDMI output at all on both. These boards worked fine with 6.1 kernel. This is bad news because rk3328 supported boards may have regressed as well, need to figure it out this as well ☹️

@paolosabatino I can confirm no HDMI output on rk3328 box.
I've tried to revert suspicious rk fbdev commit torvalds/linux@497cc66 but no luck.

Here is relevant parts of dmesg diff on 6.1 vs 6.5 kernels:

< platform ff370000.vop: Fixed dependency cycle(s) with /hdmi@ff3c0000
---
> platform ff3c0000.hdmi: Fixed dependency cycle(s) with /vop@ff370000/port/endpoint@0
10c10,14
< rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device
---
> rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes
> rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes
> rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes

It seems rockchipdrmfb is a key but I have not found rockchipdrmfb in 6.1 sources or armbian patches.

amazingfate requested review from Manouchehri, TRSx80, Tonymac32, ahoneybun, brentr, catalinii, joekhoobyar, krachlatte, paolosabatino, schwar3kat, a team and igorpecovnik as code owners August 30, 2023 17:29

github-actions bot added the Hardware ⚙️ label Aug 30, 2023

paolosabatino force-pushed the rockchip64-6.5 branch from f5a8cbf to 0c75dc4 Compare September 2, 2023 17:27

schwar3kat mentioned this pull request Sep 4, 2023

Kernel 6.5 armbian-led-state.service order #5674

Merged

9 tasks

schwar3kat reviewed Sep 4, 2023

View reviewed changes

rpardini previously approved these changes Sep 4, 2023

View reviewed changes

igorpecovnik previously approved these changes Sep 4, 2023

View reviewed changes

igorpecovnik added the Ready to merge Reviewed, tested and ready for merge label Sep 4, 2023

igorpecovnik dismissed stale reviews from rpardini and themself via f8dfd52 September 4, 2023 12:39

rpardini approved these changes Sep 4, 2023

View reviewed changes

amazingfate and others added 6 commits September 4, 2023 14:49

rockchip64: bump rockchip64-edge kernel to 6.5

534db91

rockchip64/edge 6.5.y: rebase patches against v6.5 (.0)

9aeed70

rockchip64/edge 6.5.y: fix patch `general-rk808-configurable-swit…

15b824c

…ch-voltage-steps.patch` (client_dev -> dev)

rockchip64: increase timeout for usb3 type C phy init

d8922d1

rpardini force-pushed the rockchip64-6.5 branch from f8dfd52 to d8922d1 Compare September 4, 2023 12:50

igorpecovnik approved these changes Sep 4, 2023

View reviewed changes

igorpecovnik merged commit 040e5f6 into armbian:main Sep 4, 2023
4 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP]rockchip64: bump rockchip64-edge kernel to 6.5 #5657

[WIP]rockchip64: bump rockchip64-edge kernel to 6.5 #5657

amazingfate commented Aug 30, 2023

rpardini commented Aug 31, 2023

rpardini commented Aug 31, 2023

rpardini commented Aug 31, 2023

amazingfate commented Aug 31, 2023

amazingfate commented Aug 31, 2023

rpardini commented Aug 31, 2023 •

edited

rpardini commented Aug 31, 2023

rpardini commented Aug 31, 2023

schwar3kat commented Aug 31, 2023

rpardini commented Aug 31, 2023

schwar3kat commented Aug 31, 2023 •

edited

lanefu commented Sep 1, 2023

schwar3kat commented Sep 2, 2023 •

edited

iav commented Sep 2, 2023

paolosabatino commented Sep 2, 2023 •

edited

paolosabatino commented Sep 2, 2023 •

edited

paolosabatino commented Sep 2, 2023

paolosabatino commented Sep 2, 2023 •

edited

schwar3kat commented Sep 2, 2023 •

edited

paolosabatino commented Sep 3, 2023

schwar3kat commented Sep 3, 2023 •

edited

paolosabatino commented Sep 3, 2023

schwar3kat left a comment

rpardini left a comment

igorpecovnik left a comment

rpardini left a comment

alex3d commented Sep 16, 2023 •

edited

[WIP]rockchip64: bump rockchip64-edge kernel to 6.5 #5657

[WIP]rockchip64: bump rockchip64-edge kernel to 6.5 #5657

Conversation

amazingfate commented Aug 30, 2023

Description

How Has This Been Tested?

Checklist:

rpardini commented Aug 31, 2023

rpardini commented Aug 31, 2023

rpardini commented Aug 31, 2023

amazingfate commented Aug 31, 2023

amazingfate commented Aug 31, 2023

rpardini commented Aug 31, 2023 • edited

rpardini commented Aug 31, 2023

rpardini commented Aug 31, 2023

schwar3kat commented Aug 31, 2023

rpardini commented Aug 31, 2023

schwar3kat commented Aug 31, 2023 • edited

lanefu commented Sep 1, 2023

schwar3kat commented Sep 2, 2023 • edited

iav commented Sep 2, 2023

paolosabatino commented Sep 2, 2023 • edited

paolosabatino commented Sep 2, 2023 • edited

paolosabatino commented Sep 2, 2023

paolosabatino commented Sep 2, 2023 • edited

schwar3kat commented Sep 2, 2023 • edited

paolosabatino commented Sep 3, 2023

schwar3kat commented Sep 3, 2023 • edited

paolosabatino commented Sep 3, 2023

schwar3kat left a comment

Choose a reason for hiding this comment

rpardini left a comment

Choose a reason for hiding this comment

igorpecovnik left a comment

Choose a reason for hiding this comment

rpardini left a comment

Choose a reason for hiding this comment

alex3d commented Sep 16, 2023 • edited

rpardini commented Aug 31, 2023 •

edited

schwar3kat commented Aug 31, 2023 •

edited

schwar3kat commented Sep 2, 2023 •

edited

paolosabatino commented Sep 2, 2023 •

edited

paolosabatino commented Sep 2, 2023 •

edited

paolosabatino commented Sep 2, 2023 •

edited

schwar3kat commented Sep 2, 2023 •

edited

schwar3kat commented Sep 3, 2023 •

edited

alex3d commented Sep 16, 2023 •

edited