12:54 <Soupborsh> Hello, It is me again, absolute beginner trying to port U-Boot to B288 SoC, specifically PocketBook 618.

12:55 <Soupborsh> I updated wiki page to reflect almost everything I know about the device:

12:55 <Soupborsh> https://linux-sunxi.org/PocketBook_Basic_Lux_4_(PB618)

12:56 <Soupborsh> Could you please tell how do I make emmc or at least SD card to work?

13:02 <apritzel> Soupborsh: that doesn't look like "absolute beginner" to me ;-)

13:20 <Soupborsh> Thank you, maybe I learned some things. If I understand correctly, for example one GPIO pin but with other "allwinner,muxsel" value is physically completely other thing?

13:20 <Soupborsh> And "allwinner,muxsel" is somehow replaced by "function" value in mainline U-Boot.

13:32 <apritzel> yes, each pin can be multiplexed to a number of peripherals, depending on the programmed mux value: 0 is always GPIO in, 1 is always GPIO out, 6 is always IRQ, and 7 is always disabled

13:32 <apritzel> the rest (muxes 2-5) depend on each pin, and are very SoC specific

13:32 <apritzel> so that would also be my first approach: create a table with the pinmuxes, and put that in the Wiki, on a B288 page. The Linux drivers have this, see pinctrl-sun8iw10p1.c in various github repos

13:34 <apritzel> (assuming it really is sun8iw10(p1), that would be good to have confirmed)

13:35 <apritzel> Soupborsh: so if I see this correctly, you base this on H3, because it's presumably close?

13:38 <Soupborsh> Yes, I think B288 is most similar to H3 and R40(sun8iw11p1 IIRC). And yes B288 is sun8iw10p1.

13:44 <Soupborsh> I will work on B288 wiki page now.

13:46 <apritzel> and just to double check: there is no manual, right?

13:46 <gamiee> btw did you saw this?: https://www.cnx-software.com/2025/06/13/allwinner-h135-risc-v-multimedia-soc-is-made-for-projectors-and-kvm-solutions/

13:51 <apritzel> yeah, saw it and immediately forgot about it: it looks like a D1s with 256MB instead of 64MB?

13:54 <MoeIcenowy> apritzel: well the HW datasheet says a HDMI RX

13:54 <MoeIcenowy> a quite new block on AW SoCs (well I don't know whether it's really ondie

13:55 <MoeIcenowy> and it's 2nd QFP + ext BGA DDR chip (1st is A13

13:56 <MoeIcenowy> the pinmux looks quite different to D1 then

13:58 <apritzel> MoeIcenowy: so even worse: equally wimpy, but not compatible? ;-)

13:58 <MoeIcenowy> seems so

13:59 <apritzel> Soupborsh: I guess this would be the U-Boot pinctrl patch: https://gist.github.com/apritzel/34a2a623cf73eadef13730bf8810d74d

14:02 <apritzel> so pinctrl looks solvable, and the new pinctrl design in Linux makes this much easier, but clocks are probably much harder (though U-Boot is probably achievable)

14:06 <apritzel> Soupborsh: you can use the H3 as a base (for instance for the DTs), but please remove *everything* that's either not applicable or not used/not tested (like core 2 and 3, all the video parts, and so on)

14:21 <Soupborsh> apritzel: Thank you, you are a genius. Ok I will remove. I am still creating initial almost empty B288 page.

14:29 <apritzel> Soupborsh: thanks, it would be good to have something to dump information to, especially if there is no manual

14:47 <wens> cleaned up the pck600 driver and modified it to a similar style as the sun20i-ppu driver, and now it feels like a full rewrite

14:48 <wens> is anyone working on the a523 mcu ccu driver?

14:48 <apritzel> wens: many thanks, and not surprised about the full rewrite feel ;-)

14:50 <apritzel> wens: I think I had something for the MCU clocks, can dig this out tonight. We also need something for the CPU (+DSU) clocks, for which I also have some sketch.

14:50 <apritzel> but there were question marks on some details, so I would appreciate someone else looking at that

14:51 <apritzel> I think I tried to base the MCU driver on the BSP one, as some kind of experiment, because they are now also using the CCF

14:52 <apritzel> wens: oh, and regarding the "ARM should write a driver": apparently the idea was that this IP would be driven by some SCP core, with the PDs exported via SCMI, so not directly controlled by Linux

14:53 <wens> I see

14:54 <wens> we would need the MCU CCU driver for anything related to audio, or the NPU

14:58 <wens> any preferences for the DT headers? put all the power domain macros in one? or split them by block?

14:59 <apritzel> wens: I recently discovered that actually the AUDIO PLL from that MCU CCU feeds into the R-CCU, and not the audio PLL from the main CCU

16:03 <wens> apritzel: seems like the EMAC should have been called GMAC

16:04 <apritzel> wens: which one? the EMAC1 in A523? I think the naming is off since about the A20 already, Allwinner goes forth and back with the names, I feel.

16:06 <apritzel> or at least the H3, which was called EMAC again, after the A20 GMAC and A10 EMAC

16:40 <wens> well, both. the t527 datasheet uses GMAC and GMAC200

17:00 <apritzel> wens: yes, but that's just a name. The A64, H6, and H616 manuals call the IP "EMAC", and since EMAC0 on the A523/T527 is fully compatible, it would be somewhat odd to use a different name, I think

17:01 <apritzel> wens: are you looking into a GMAC200 driver? The BSP version looked like mostly boilerplate ...

17:04 <wens> yeah, I'm doing the GMAC200 driver

17:04 <wens> supposedly it's a newer dwmac core, so it has the feature registers the driver can probe

17:04 <wens> all that's needed is just a glue to configure the syscon

17:05 <wens> I'm just taking the syscon code from the emac driver

17:06 <apritzel> wens: oh great, many thanks! And yeah, that was my impression as well: no actual MAC code needed, just platform code

17:06 <apritzel> which makes me wonder if we can integrate this into dwmac-sun8i.c?

17:12 <wens> it makes the code path a bit messy, and if you only wanted to use the gmac200, you'd still bring in a bunch of code for the old emac

17:12 <wens> it's doable, but a bit confusing to be honest

17:13 <wens> I actually started with that

17:14 <wens> apritzel: btw, what happened to your "drop syscon default value" patch?

17:16 <apritzel> wens: integrated driver> ah, fair enough, was just an idea. Was already wondering if it's actually useful or not

17:17 <apritzel> wens: drop default> dunno, should probably poke on it. I think people agreed in general

17:24 <wens> heh, took no time to do the glue driver. total ~150 LOC

17:24 <wens> mostly copied lol

17:33 <wens> I thought regulator support had been added to the MDIO core. apparently not

19:12 <wens> PEBKAC, put in wrong base address for the gmac

20:43 <eeschalier> Currently fiddling around with bare-metal ethernet on an OPi One (H3), and noticed something odd about the internal PHY; it reports as being unable to perform Autonegotiation, but nonetheless has the Autonegotiation Enable bit set (which according to IEEE802.3-2022 22.2.4.1.4, should mean that the PHY is capable of Autonegotiation); and as far as I can tell, the device is in actuality perfectly capable of autonegotiation (un

20:47 <eeschalier> adjacent question: does anyone know of any documentation at all regarding the internal EPHY on the H3? I know that at least three of the "vendor-specific" MDIO registers seem to be populated, but I have no idea what they are