00:02 <tokyovigilante> Ah ok. No I have gone down a rabbit hole of changing values while only vaguely understanding the science behind it :) Thanks for pointing out where the 90316800 comes from, makes more sense now. Should be able to replicate the correct behaviour now

00:18 <apritzel> and for the sake of completeness: those base frequencies are (44100 * 512) and (48000 * 512), so the two common sample rates *shifted*

00:20 <apritzel> I *think* the 512 is: 32 bits / sample * 2 channels * 4 times the base sample rate

00:21 <apritzel> well, that's 256, of course, but close enough ;-)

00:25 <loki666> The Wikipedia intro page for SDM is tax form explanation level WTF

00:28 <apritzel> loki666: didn't I say "rocket science" above? ;-)

00:32 <loki666> Yes but I don't think there is any "science" in SDM... More like voodoo

00:33 <apritzel> I think SDM just refers to the technology used to efficiently implement the fractional divider, on top of this there is the whole PLL voodoo ...

00:36 <apritzel> loki666: does that help? https://en.wikipedia.org/wiki/Frequency_multiplier#Fractional-N_synthesizer

00:37 <apritzel> that explains where the SDM comes in

04:17 <tokyovigilante> I didn't put any of the DTS routings in v1 because the RG35XX devices need an extra GPIO outside the codec to enable the headphone switch, so they will need a separate simple sound card device, but that can come as a different patch

04:31 <tokyovigilante> Ah this absolutely works, awesome! Thanks apritzel. Will collate the rest of the changes and send a v2 in presently

07:30 <MasterR3C0RD> Added a phy_dx_bit_compensation implementation to my A133 tree; mechanism is similar to the H616, but I noticed a few patterns and took advantage of them; not sure if it's "too clever" though. https://github.com/BrokenR3C0RD/u-boot/commit/d8d0ee4a54b12722e491e1355933de00dbf1e698

07:32 <MasterR3C0RD> It makes a few patterns a little more obvious, for example that the delay0 registers are mixed with the delay1 registers

07:34 <MasterR3C0RD> Rather, interleaved

09:02 <loki666> apritzel: I doesn't really help. But thanks.

11:52 <Parthiban> MasterR3C0RD: From Andre Przywara in the linux mainling list I understand that you have a working / WIP tree for A133 u-boot with DRAM support. Shall I already pull it get it to work with upstream u-boot? Thanks.

11:53 <apritzel> parthiban: Hi, welcome back ;-)

11:53 <Parthiban> apritzel: Thanks.

11:55 <apritzel> parthiban: if you check the logs, MasterR3C0RD posted a link to his repo earlier today

11:56 <apritzel> though that's just the DRAM bits, there is more code needed to support the A133

11:56 <apritzel> I had this last year: https://github.com/apritzel/u-boot/commits/a133-WIP/https://github.com/apritzel/u-boot/commits/a133-WIP/

11:59 <paulk> oh glad to see Allwinner finally stopped merging the PHY and uMCTL2 registers

12:00 <paulk> is there ongoing work for T527 btw?

12:01 <apritzel> paulk: DRAM driver or general?

12:01 <Parthiban> apritzel: checking the changes.

12:01 <paulk> apritzel: both I guess :)

12:02 <apritzel> I am chasing a weird bug in my clock driver, but apart from that I got a 6.12-rc1 based tree with working pinctrl, clocks, watchdog, USB2.0, I2C, PMICs, MMC

12:03 <apritzel> ready to post that once I find that issue either in PLL_PERIPH0 or the MMC mod clock, it breaks MMC support unless I hack it

12:04 <apritzel> I also have the U-Boot bits without DRAM, and am using an improved Syterkit branch to replace the SPL and load U-Boot proper. MMC and USB work in U-Boot as well

12:04 <paulk> nice work :)

12:05 <Parthiban> apritzel: Oh, that's great. Do you have the cpu pll clock driver as well lined in?

12:06 <apritzel> I have some sketch for that, but don't use that at the moment. There are still some question marks, but it's not a show stopper at the moment

12:07 <apritzel> I have a PRCM CCU driver as well, which is more important, since we need that for the I2C port driving the PMIC

12:07 <paulk> parthiban: btw there's plenty of SoCs that use the same uMCTL2 (it's probably the most widely-used DRAM controller these days) and that have documentation about it in their SoC manual

12:07 <paulk> most recent TI chips for example

12:08 <Parthiban> apritzel: Ok, I had it started a while ago for A523 CPU pll and swapped to A133.

12:09 <paulk> there's a list: https://paste.paulk.fr/9e4136

12:09 <paulk> that might help with unknown bits

12:09 <paulk> also there's the uMCTL2 databook but it's unfortunately not public

12:12 <paulk> TI's SPRUID7E is a good reference

12:12 <paulk> well you might know about this already

12:20 <apritzel> paulk: thanks, that's interesting. Though a lot of problems come from Allwinner mix-and-matching other components (like the PHY), and then seemingly deviating from JEDEC timings as well

12:22 <paulk> yeah I can imagine...

12:23 <paulk> it's a puzzle with many pieces

12:35 <apritzel> for the A523: at the moment there is this: https://github.com/YuzukiHD/SyterKit/blob/main/board/avaota-a1/payloads/init_dram_bin.c

12:36 <apritzel> so it's a pure binary, mixed ARM/Thumb2, linked to run at like 0x7280000 (in SRAM A3)

12:36 <apritzel> so any help here would be greatly appreciated!

12:37 <paulk> yeah I've had a look at it some time ago with ghydra

12:37 <paulk> it's pretty big

12:38 <paulk> could be easier to just trace its I/O

12:39 <paulk> is that running with some virtual memory enabled? (I guess not...)

12:43 <paulk> either way JTAG could help

13:06 <apritzel> Syterkit doesn't enable the MMU until after DRAM init

13:08 <apritzel> but we can of course hack it, or even run it with something in AArch64 EL2 tracing the MMIO

14:56 <MasterR3C0RD> parthiban, apritzel: I hink I forgot to mention that I had also rebased the A133 patchsets Allwinner had sent in: https://github.com/BrokenR3C0RD/linux-a100

15:02 <MasterR3C0RD> From my understanding, there are a few drivers still missing for the A100 series even with all this, though I also didn't dig in incredibly deep before locking into the DRAM reverse engineering; LCD support comes to mind as one of the standouts

15:06 <MasterR3C0RD> The GPU is also a WIP; Imagination has been working on porting other Rogue GPUs. I opened an issue on their linux-firmware thread to request some of the missing basic bits, as they've been pretty good for it so far: https://gitlab.freedesktop.org/imagination/linux-firmware/-/issues/5

15:06 <MasterR3C0RD> s/thread/project/

15:12 <apritzel> MasterR3C0RD: ah, great! Do you mind posting them? You would need to add your Signed-off-by:, but keep the original authorship and S-o-B:

15:12 <apritzel> then we can review them and get them on the way

15:21 <MasterR3C0RD> apritzel: Sure! It looks like the old patches also had reviewed-by you, do I keep those?

16:00 <apritzel> yes, if there is no significant change

16:01 <apritzel> MasterR3C0RD: does your device have an AXP717 or AXP707 PMIC? Seems like the older devices (like my tablet) used a 707, but newer ones settled for the newer 717?

16:03 <MasterR3C0RD> apritzel: The PMU in mine is referred to by boot0 as AXP806, but is compatible with the AXP305 SPL driver

16:06 <MasterR3C0RD> Sadly identifying by chip is impossible, as all components were rebadged with Creality part numbers

16:17 <apritzel> MasterR3C0RD: that's alright, it's the same driver anyway, so any name we put to it is mostly cosmetic

16:18 <apritzel> I just realised that the AXP707 is basically the same as the good ol' AXP803 (of A64 fame)

22:32 <apritzel> MasterR3C0RD: oh, you were asking for the chip ID of my tablet: it say 0x1400. The tablet is a Teclast P80