08:02 <rockosov> narmstrong: Hello! Hope you have a couple minutes to answer my question... And really sorry for ping you in vacation. I was on long vacation as well and didn't have ability to prepare v3 tty devname changes here https://lore.kernel.org/lkml/20230705181833.16137-1-ddrokosov@sberdevices.ru/. Today I was going to send new version with real struct names, but saw the GH merged previous version to

08:02 <rockosov> tty-testing branch. What should I do in the such situation? Do I need to ask GH revert v2 and apply v3? Or it's not required?

08:04 <rockosov> jbrunet: xdarklight Also I hope you know right actions in such situation... Could you please help me to choose the right way?

08:21 <narmstrong> rockosov: hi, no problem, it’s not a big deal, if you wish just send a follow up patch or leave it as is

08:22 <narmstrong> The patch is functional so no need to revert

08:27 <rockosov> narmstrong: Okay, thank you! Should follow up patch have v1 version? It's total separate patchset, right?

08:33 <narmstrong> rockosov: yep

08:33 <rockosov> narmstrong: Thanks a lot! Have a nice vacation!

08:41 <narmstrong> rockosov: thx!

17:22 <xdarklight> hexdump0815: ping - RE audio issues

17:24 <xdarklight> hexdump0815: can you play audio with both sample rates, then look at two files: /sys/kernel/debug/clk/clk_summary (you already did that) and also /sys/kernel/debug/meson-clk-msr/measure_summary (this is some IP block which allows spying on the SoC internal clock signals - this is useful to compare what Linux sees in clk_summary with what this special SoC internal IP sees)

17:50 <xdarklight> to all reverse engineering interested people here wanting to take a look at the DDR firmware blobs on G12A and newer SoCs: $ dd if=aml_ddr.fw bs=1 skip=96 | lz4 > foo.bin.dec

17:50 <xdarklight> as far as I can tell foo.bin.dec now as ARM64 instructions and contains plain text

17:55 <xdarklight> and to nobodies surprise it also contains the string dwc_ddrphy_apb_wr - which may indicate that these SoCs still use a DesignWare DDR PHY

19:13 <hexdump0815> xdarklight: thanks a lot for that hint - i'll have a look soon and paste the results

20:28 <f_> Hi xdarklight thanks for the tip :)

20:28 <f_> Older SoCs (gxbb, gxl) lack a DDR firmware though

20:29 <f_> I think it may be located in a ROM somewhere?

20:31 <xdarklight> f_: if I was a hardware developer I would not want some DDR firmware in ROM because if there's the tiniest of typos I'm screwed and a new HW revision is needed. I think the code you're staring at for the GX SoCs has been moved into a firmware blob (whatever the reason for this may be, possibly because you mentioned some data being present in multiple BLx stages? that's just a wild guess though)

20:36 <f_> Hm.

20:36 <f_> But since this firmware is almost the same as the iMX's DDR firmware I guess Amlogic don't have the sources for it.

20:37 <f_> But I can't know for sure, I'm very much unfamiliar with both the iMX8 and the G12A/G12B and later.

20:38 <xdarklight> yep, that's also a possibility

20:39 <f_> But it seems like the firmware has some debug symbols? The only way to know for sure would be to feed that binary into something like Ghidra.

20:39 <f_> `dwc_ddrphy_apb_wr` looks like the name of a function.

20:40 <xdarklight> I think it's part of some printf() (debug) message

20:41 <f_> Maybe

20:41 <f_> Again, the only way to know for sure would be to feed this binary to Ghidra.

20:41 <xdarklight> not sure about debug symbols and I haven't played with Ghidra for a long time (and not planning to do so at the moment, not enough time)

20:41 <f_> Might do that out of curiosity.

20:43 <f_> Now, back to GXBB/GXL; not sure if that'll help or not, but I found some similarily-named registers to what we have in the old BL2 sources in the linux-sunxi wiki

20:44 <xdarklight> at least some sunxi SoCs are also using the DesignWare DDR memory controller

20:44 <xdarklight> I forgot which ones exactly

20:48 <f_> I think all of them supported by linux

20:48 <f_> Either way some similarily-named registers were documented.

20:49 <f_> Let me find that page real quick.

20:52 <f_> https://linux-sunxi.org/A10_DRAM_Controller_Register_Guide

20:52 <xdarklight> I think we should say "all of them supported by (mainline) u-boot" because Linux requires working DDR memory

20:53 <f_> At least the A10 is using a DWC PHY.

20:54 <f_> But if you look at that table of registers, and compare it to https://git.vitali64.duckdns.org/archive/amlogic-bl2.git/tree/plat/gxb/ddr/ddr_pub_define.h for example

20:54 <f_> you'll see that some registers have very similar names.

20:54 <f_> E.g. DDR0_PUB_DCR v.s. SDR_DCR

20:55 <f_> The base address differs though.

20:55 <f_> On A10 it's 0x01c01000 and on GXBB it's 0xc8836000

20:59 <f_> I just noticed that a few days ago; while I paused my work on REing I'm still trying to find stuff from time to time.

21:00 <f_> when I'm bored :P

21:00 <f_> (will resume in a few weeks most likely)

21:01 <xdarklight> my interpretation is: those big addressing offsets are implementation defined - so Amlogic says "I want the memory controller at address X" and Allwinner says "I want the memory controller at address Y"

21:01 <f_> Yeah most likely.

21:17 <f_> I should try documenting as much registers as I can.

23:11 <f_> So we know for sure Amlogic used a Synopsys DesignWare DDR PHY at least since Meson6.