02:51 <juanesf91> Hi

02:51 <juanesf91> The A523 doesn't have HDMI, a second ETH port, NPU, or DSP. The A527 has HDMI, a second ETH port, but no DSP or NPU. The T527 has everything, so to speak. It would be feasible to separate the DTS.

02:53 <juanesf91> a523 https://usercontent.irccloud-cdn.com/file/PBEunZJC/1000154416.jpg

02:53 <juanesf91> a527 https://usercontent.irccloud-cdn.com/file/GQACGRr9/1000154417.jpg

02:53 <juanesf91> t527 https://usercontent.irccloud-cdn.com/file/djmonvro/1000154418.jpg

03:02 <juanesf91> a523 have gpadc 4-ch and a527/t527 24-ch. T527 have can x2

03:26 <wens> juanesf91: not all T527s have NPU

03:27 <wens> juanesf91: see https://linux-sunxi.org/A523

03:28 <wens> juanesf91: you can edit the wiki and add your findings to the table

09:20 <apritzel> juanesf91: are you suggesting we should have different per-SoC .dtsi files, one for each SKU?

09:21 <apritzel> because this wouldn't be necessary, I think: we believe they probably use the same die, just in a different package, and naturally not connect all the peripherals

09:24 <apritzel> take the 2nd Ethernet port, for instance: the A523 silicon most likely has that 2nd GMAC, it's just not connected to any pins/pads (for once because the A523 just had 522 pads, where the A527/T527 have 644)

09:25 <apritzel> so an A523 system is conceptually not different from an A527 where you just don't connect a PHY to the 2nd GMAC. That's why we have: status = "disabled"; for most peripherals (those with pins) in the .dtsi

09:26 <apritzel> and then put: status = "okay"; in the board .dts, depending on whether this peripheral is used

09:27 <apritzel> also having multiple .dtsi creates a lot of churn and confusion, and descends into a proper nightmare when you see that for instance the Radxa board comes with both the A527 and T527, depending on what you order, exactly

09:28 <paulk> it's a bit weird that some have the npu and others not if it's the same die though

09:28 <apritzel> paulk: it all looks like it's fused off

09:28 <paulk> mhh sad

09:29 <apritzel> the reset and clock gates are there, at least

09:29 <paulk> sometimes they just don't mention it but it's still functional

09:29 <paulk> like isp on h3

09:29 <apritzel> yes, that was mostly the case on the H616 family as well, I think

09:31 <apritzel> given how expensive TSMC masks are, that's the most economical move, though, and you don't run into problems where you run out of one die when you still have plenty of closely related ones

09:37 <wens> rockchip has these -base.dtsi -extra.dtsi splits

09:44 <wens> I don't think we have split .dtsi files for any of the arm64 stuff

09:47 <apritzel> wens: yeah, and I find the Rockchip .dtsi split the most confusing ever, honestly

09:48 <wens> yeah, that's like two levels of splitting

09:56 <apritzel> one could argue that naming it a523.dtsi is not accurate, and I started to think if we should adopt Allwinner's die names, so sun55iw3 or something

09:59 <wens> maybe, but it would be harder for casual folks and non-sunxi kernel developers to follow

13:15 <apritzel> wens: did you ever send a U-Boot defconfig for the OrangePi 4A? Since the .dts is in the DT rebasing repo, you can cherry-pick it: ./tools/update-subtree.sh pick dts <rebasing commit id>

13:15 <apritzel> compare https://docs.u-boot.org/en/v2025.07/develop/devicetree/control.html#resyncing-with-devicetree-rebasing

13:36 <wens> apritzel: not yet

14:06 <wens> apritzel: I see a "audio1pll-4x" clock in the clock tree diagram. obviously this clock doesn't exist.

14:07 <wens> apritzel: and I see you corrected it to audio0pll-4x in our upstream version?

14:32 <apritzel> wens: yeah, it's unclear indeed. I am not even sure I spotted the "1" at all, since I was just aware of that one main audio PLL

14:33 <apritzel> I wonder since the timers can be muxed to that, we can probably even run an experiment to prove what it is and also the exact frequency or dividers used

14:37 <wens> the "ahb" parent for the timers suggests something at 200 MHz

14:40 <wens> it seems we're not configuring the r-ahb and r-apb* clocks? they are all at 24 MHz on by board

14:41 <apritzel> quite possible, that's typically a U-Boot task. We model the clocks, and can read them from Linux, but I think there is nothing that would ever program or change that

14:44 <apritzel> also I figured that one of the APB clocks is still at 24 MHz, where it should be much higher: the manual says APB1 should be "max 160 MHz"

14:44 <wens> I guess we can force something with assigned clock rates?

14:47 <apritzel> this is used for UART and I2C, which are probably fine with 24 MHz (although that limits the UARTs to 1.5 Mbps), but also for the PWMs, where we want something higher than 24 MHz

14:47 <apritzel> maybe, though traditionally we just set something reasonable in U-Boot and never bothered. I would treat this like a U-Boot bug, really

14:48 <wens> I think there's no harm forcing it at the dtsi level

14:49 <wens> U-boot could even use that?

14:56 <apritzel> we set up the bus blocks in the SPL, with just a per-SoC #define, so .dtsi won't help

15:01 <apritzel> I guess it doesn't hurt to have the bus clocks configured in the DT using assigned-clock-rates, though. But it might become interesting if the U-Boot default and this rate differs, and we switch at runtime

15:02 <apritzel> it might temporarily break the serial console used by earlycon?

15:03 <wens> I think we left all the apb clocks with uart/i2c alone on previous SoCs

15:03 <wens> they were always on a separate apb bus, and we kept them at 24 MHz

15:03 <wens> whereas the other apb bus with stuff like I2S we increased

15:03 <wens> anyway, this might be why my audio stuff isn't working

17:10 <wens> apritzel: could you check if the h728 tv box has a 32k crystal or not? it should be obvious as the two crystals are probably side by side

17:23 <apritzel> wens: ah, just saw your patch. Will do once home ...

17:24 <wens> I have patches for the dev boards

17:28 <wens> nope, dma still doesn't run :(

18:40 <apritzel> wens: checked the board, but it's hard to say, as I don't see the 24 MHz crystal either: I guess it's all hidden under this rather large heat sink

18:42 <apritzel> I see a crystal oscillator right next to the WiFi chip, but I guess that's the private one for the AIC

22:48 <apritzel> does anyone know how to change the "initial view" settings in a pdf file to collapse the bookmarks/outlines by default? The new generation of Allwinner user manuals always expands them, which is a pain with all the thousands of registers being a separate bookmark item

23:18 <dlan> I have no such problem with qpdfview here

23:25 <apritzel> dlan: interesting, I am using xpdfreader, and it expands. Was never a problem with the older docs, say the H616 manual