lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
montjoie has quit [Ping timeout: 264 seconds]
montjoie has joined #armbian-rockchip
DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian-rockchip
<DC-IRC> <amazingfate> Does bluetooth works on opi3b with legacy 5.10 kernel? I can see bluetooth from `rfkill list` but I can't enable it from gnome's system setting. I don't know if xunlong's image works. @microlinux @rpardini
* DC-IRC <rpardini> is switching to legacy kernel to test
<DC-IRC> <rpardini> Yeah same here. `rfkill list` sees it, but unblocking it does nothing.
<DC-IRC> <rpardini> On the DT.... `&pinctrl` has 2 `wireless-bluetooth` nodes, one at uart1 and another at uart8. Quick look at schematics shows UART1 only.
<DC-IRC> <amazingfate> I just made some fixes on mainline kernel to get the same status as legacy kernel.
<DC-IRC> <amazingfate> Gpio2 B1 is for sdmmc1 pwren and uart8 rtsn
<DC-IRC> <rpardini> yeah but uart1's rts should be GPIO2 B5, no?
<DC-IRC> <rpardini> I think if we twist those a bit me might only need an hciattach
<DC-IRC> <rpardini> I think if we twist those a bit we might only need an hciattach
<DC-IRC> <rpardini> damn I now realized I'm looking at mainline DT not vendor, sorry
<DC-IRC> <amazingfate> They should be almost the same. I copied a lot from vendor devicetree.
<DC-IRC> <rpardini> oh okay yeah indeed.
<DC-IRC> <rpardini> looks to me uart8 is unrelated here, and &uart1 is missing the rtsn pin (uart1m0_rtsn)
<DC-IRC> <amazingfate> Yeah I just added it.
<DC-IRC> <amazingfate> Removing uart8's pinctrl doesn't harm the wireless.
<DC-IRC> <rpardini> yeah if we get the uart working then it might be just an hciattach away
<DC-IRC> <rpardini> we've DT for "OrangePi 4 LTS" (3399) which seems to have same uwe stuff
<DC-IRC> <rpardini> a small firmware path fix might also be in order
<DC-IRC> <rpardini> but that will only show, I suspect, after we do the hciattach
<DC-IRC> <amazingfate> Here is the patch I use for mainline.
<DC-IRC> <rpardini> looks sane
<DC-IRC> <rpardini> I realize now there's a pile at play here.... uwe driver at network drivers, but then also a rockchip64-specific patch at `wifi-4003-uwe5622-adjust-for-rockchip.patch`
<DC-IRC> <rpardini> it's Paolo's
<DC-IRC> <rpardini> and meanwhile at orangepi4-lts.conf
<DC-IRC> <rpardini> there's a custom `hciattach_opi` bin
<DC-IRC> <amazingfate> Let me try it.
<DC-IRC> <rpardini> and is invoked as `/usr/bin/hciattach_opi -n -s 1500000 /dev/ttyBT0 sprd`
<DC-IRC> <rpardini> did you get a ttyBT node with the `sprd-mtty` DT?
<DC-IRC> <amazingfate> It works.
<DC-IRC> <rpardini> 🥳
<DC-IRC> <amazingfate> I will create a pull request.
<DC-IRC> <rpardini> great. have you considered submitting the DT upstream? I know it's early
<DC-IRC> <rpardini> also without the uwe driver upstream we'd need to strip it down a lot
<DC-IRC> <rpardini> (Kwiboo took my uboot stuff, which has your mainline DT inside)
<DC-IRC> <amazingfate> I'm not familiar with the way to get code upstream. I have to learn how to configure a mail client to send a patch.
<DC-IRC> <amazingfate> And yeah, uwe driver is making the dts looking not good.
<DC-IRC> <rpardini> Yeah it's a bore, not to mention the cover letter
<DC-IRC> <rpardini> I'll look into it, maybe we could split the DT into upstream-worthy and Armbian-UWE-only parts.
<DC-IRC> <rpardini> unrelated (vendor kernel), maybe we can strip those off? (panel stuff)
<DC-IRC> <rpardini> Sebastian Reichel (`sre`)'s talk at Kernel Recipes about the rk3588
<DC-IRC> <rpardini> starts at 06:52:08
<DC-IRC> <nicod_sbc> That's awesome. That kind of content of devs explaining what steps they take to add a board or fix a bug.
<DC-IRC> <nicod_sbc> That's awesome. That's the kind of content I'd love of devs explaining what steps they take to add a board or fix a bug.
<DC-IRC> <rpardini> I just feel bad nobody asked decent questions at the end. If any of us would be there there'd be no time enough for all the questions
<DC-IRC> <efectn> i wonder why there is still no rockchip rng and crypto driver on mainline
<DC-IRC> <efectn> i hope they will mainline them with rk3588
<DC-IRC> <rpardini> Yeah I'm confused. Seems there's 2 crypto blocks?
<DC-IRC> <rpardini> He didn't _mention_ any of the PD stuff either
<DC-IRC> <efectn> it doesn't even work properly on downstream 🤣
<DC-IRC> <efectn> it seems they will send a PATCH for HDMI RK soon https://gitlab.collabora.com/shreeya/rk3588-linux/-/commits/rk3588-hdmi-upstream/
<DC-IRC> <efectn> it seems they will send a PATCH for HDMI RX soon https://gitlab.collabora.com/shreeya/rk3588-linux/-/commits/rk3588-hdmi-upstream/
<DC-IRC> <rpardini> heh, which proves my point: HDMI-In is more in-demand for this board than HDMI out
<DC-IRC> <rpardini> "AI folks".
<DC-IRC> <rpardini> I wonder much power is wasted due to the critical-marked linked clock gates
<DC-IRC> <rpardini> heh, which proves my point: HDMI-In is more in-demand for this SoC than HDMI out
<DC-IRC> <rpardini> I wonder how much power is wasted due to the critical-marked linked clock gates
<DC-IRC> <rpardini> this looks like vendor rx driver exactly.
<DC-IRC> <rpardini> first commit he just ran GNU indent
<DC-IRC> <rpardini> this looks like vendor rx driver exactly.
<DC-IRC> <rpardini> first commit she just ran GNU indent
<DC-IRC> <efectn> devicetree seems wrong as well. rk3588s doesn't support hdmir
<DC-IRC> <efectn> devicetree seems wrong as well. rk3588s doesn't support hdmirx
<DC-IRC> <dsx724> All the discussion was actually held offline already.