00:00 <MasterR3C0RD> Just need to take some time to understand what it's doing exactly; I'll be spending some more time on this in the coming days

00:01 <iscle> dram init code has always been a mistery for me

00:03 <apritzel> DRAM code is somewhat rocket science, mostly because the authors don't seem to have a real clue about it as well ;-)

00:04 <apritzel> so yes, it is "routinely" reverse engineered, but it's still quite tricky to get it into a decent shape, and even then there is mystery, like the occasional mis-detection we see on the H616

00:06 <apritzel> but by all means: please give it a go: if you can get it close to the existing code in mainline U-Boot (in style and quality), then I am more than happy to test and eventually merge it

00:09 <apritzel> MasterR3C0RD, iscle: there are several components of a DRAM controller, and AW likes to mix and match for new SoCs. So it's worth to check for similarities in *parts* of the code

00:11 <iscle> I'll take a look at it after fixing the USB DMA code xD I'm almost there, it sends and receives, but it consistently misses some bytes depending on the length (for example, for 6, 7, 10, 11, 14, 15, 18, 19)

00:13 <MasterR3C0RD> Just added in a struct def for the CCM bits in mctl_sys_init, seems to match just about perfectly with that of the H6

00:13 <apritzel> MasterR3C0RD: yeah, the CCU seems to be pretty stable over the last few generations, starting with the H6

00:14 <apritzel> though don't sweat it with that struct, as we don't need most clocks in the SPL code

00:15 <MasterR3C0RD> apritzel: I know, it was just faster to copy the struct and see if the decomp still made sense :-)

00:21 <MasterR3C0RD> .away

01:38 <iscle> it looks like that the usb dma issue is really something to do with the memory itself. by the looks of it, the dma is really transfering the number of bytes that are requested, but the buffer is not filled with the correct contents

01:38 <iscle> https://pastebin.com/yZugDsNp

01:38 <iscle> that's what I receive on the host computer using the serial gadget, the sequence is always sending "a" repeated n times

01:39 <iscle> as you can see, when it fails, the data gets filled from the previous buffer

01:39 <iscle> s/buffer/dma transfer

01:43 <iscle> I have checked with wireshark that the data is really transfered and it's not some host-side error, and it really is transferred like that

01:44 <iscle> (For those interested, really cheap and useful, can be found in aliexpress: https://github.com/ataradov/usb-sniffer)

02:19 <jakllsch> nice

02:48 <jakllsch> hmm, the ones on Ali all seem to be speed bin 4 CPLD and clone FX2 chips

02:48 <jakllsch> both things that the github page warn against..

02:54 <iscle> jakllsch: Mine is speed bin 4 CPLD and it works just fine, I managed to capture Apple CarPlay data, as well as this USB-Serial data

02:55 <iscle> You could always buy this for the PCB and overall assembly and then swap those two chips if they are giving you any issues (which, so far, I haven't experienced)

07:23 <MasterR3C0RD> So far, aside from some very minor differences DRAM init code on A133 matches that of the H616, just with different offsets (`SUNXI_DRAM_COM_BASE = 0x4810000`, `SUNXI_DRAM_CTL_BASE = 0x4820000`, `SUNXI_DRAM_PHY0_BASE = 0x4830000`). Still going to try and dig a little deeper; H616 only supports DDR3 memory whereas my device has DDR4.

07:39 <tokyovigilante> apritzel: interestingly there are a few differences in the Tina-Linux sources for the H616 CCU, for example using bit 27 as the PLL enable bit, and not modelling the HS audio clock at all, just the 4x. e.g. https://home.xyhcloud.com:1443/tina-linux/linux-5.4/-/blob/f6f0698224f3592db7f44665f3cee62cb0d312e7/drivers/clk/sunxi-ng/ccu-sun50iw9.c

08:58 <tokyovigilante> hmm, seems this is more complex than anticipated...

09:18 <apritzel> tokyovigilante: try to not read too much wisdom into BSP code, I have seen bits that are just nonsense

09:20 <apritzel> for many parts it's OKish, but you see that they lack an honest review, and having ideas tossed around like we do on the mailing list

09:23 <apritzel> tokyovigilante: on the matter of enable bits: we do this for the D1 (and the upcoming A523) as well, following a recommendation in the manual: keep the PLLs running, and just gate them

09:24 <apritzel> tokyovigilante: in general I'd recommend to look at the D1 CCU code, some things are solved differently there (read: better), and if nothing else it's a source of inspiration

09:27 <apritzel> tokyovigilante: also the A100 CCU code has some good comments

10:14 <apritzel> MasterR3C0RD: are you sure it's DDR4 and not LPDDR4? We have H616 LPDDR4 support in mainline U-Boot now

17:49 <MasterR3C0RD> apritzel: Definitely DDR4: https://gist.github.com/BrokenR3C0RD/2d9c8ca1d6ae82d957e96d5c46c445df#file-sonic_lcd-boot0-log-L54

17:59 <apritzel> junari, jernej: do you have any notes or code for H616 DDR4 DRAM support? This is for A133/R818, but reportedly the code is close to H616?

21:23 <MasterR3C0RD> Approximate header file for the functions called by `mctl_sys_init` in A133 boot0: https://gist.github.com/BrokenR3C0RD/7efa647733f70ee911a90e9bbbf20b87

21:25 <MasterR3C0RD> It seems that there'a few differences in the clock setup that's done in `mctl_sys_init`; I'm not sure how many were intentional or not. This is an approximate direct port of the decompiled `mctl_sys_init` from boot0: https://gist.github.com/BrokenR3C0RD/3b622f5981028c56437bd778786af012

21:30 <MasterR3C0RD> s/intentional or not/intentional changes by the authors of the H616 code or actual differences from the A133/

21:33 <apritzel> thanks for that, but please note that the clock setup is actually the easy part ;-) AW does the full featured PLL setup (incl. pattern), not sure that actually helps or not. We never needed that before though

21:38 <MasterR3C0RD> Just had to get that out of the way so I have a better understanding of what I'm doing here; I'm working on the `mctl_com_init` code now

21:43 <apritzel> sure, thanks for doing that, and sorry, didn't want to dampen your enthusiasm ;-)

21:45 <iscle> MasterR3C0RD: The log you sent for the sonic pad actually shows dram version v0.69, while the code that is in the .o (fake .a) binary is showing an older version. Have you tried decompiling the newer code and see if there are any differences or if it's closer to H616?

21:47 <MasterR3C0RD> No I haven't; I didn't even notice that since the commit ID matched what I was expecting

21:54 <MasterR3C0RD> The .o is probably easier to work with anyways to start; I can look into it more later, but I wouldn't think the changes are that significant (the .o is v0.59) and the basics are likely similar

22:15 <apritzel> AW does some occasional updates, but this more about finetuning, which we can follow up later, the bulk of the code stays the same

23:40 <iscle> FINALLY! USB DMA TX seems to be working correctly!

23:40 <iscle> An entire week working just on this, lol

23:42 <iscle> AW differentiates between two types of DMA: Inner and outer. Inner seems to be a DMA controller which comes bundled together with the USB IP and works exclusively with it. It's what they seem to use in the BSP, but for some reason it is buggy and misses data depending on the number of bytes written. AW only uses DMA for multiples of the endpoint max size (512 bytes on most endpoints) and then uses PIO for the remaining bytes.

23:43 <iscle> Instead, I used the outer DMA, which is the normal DMA engine that the entire system uses for other peripherals. And this seems to work just fine, although it required more setup in the dma driver

23:49 <apritzel> iscle: awesome, good job!

23:49 <apritzel> iscle: but: "An entire week working just on this, lol"> that was somewhat expected, wasn't it?

23:51 <apritzel> with "required more setup in the DMA driver" you mean the MUSB sunxi DMA driver, right, not the sun6i-dma driver? So that code goes untouched?

23:51 <iscle> apritzel: well, at first I thought this was going to be a 2-3 day job (at most) to get it into a working state, because the DMA registers for the inner dma were quite straight forward and the rest of the glue code was already written for the musb peripheral.... But I was not expecting a buggy dma engine (I'm assuming it's buggy, because I could not find any other reason for it not to work)

23:51 <iscle> apritzel: yes, I mean in the musb sunxi dma driver, the sun6i-dma is untouched

23:51 <apritzel> great!

23:52 <apritzel> have you tested UMS? Is there some performance improvement, or at least less CPU utilisation?

23:53 <iscle> I haven't, this board only has 64MB of RAM and 16MB SPI flash which is quite slow. I have a T113-s3 board with SD card slot which I can test on if I get it to boot

23:54 <apritzel> iscle: is there anything SoC specific in your code? Or shall it work on all devices using sunxi-musb?

23:55 <iscle> I also found that the FIFO configuration that was being used for sunxi devices was a bit off for some of them (which I don't think affects anything, but I created a new one for v853 based on the BSP code that also should be compatible with other SoCs)

23:55 <iscle> apritzel: It should work with all sunxi devices

23:57 <iscle> Not sure how important the fifo config is, but this is the new config: https://github.com/iscle/linux-v853/blob/b7023ef3ea0a14a5178b00c3b22b92181d77134d/drivers/usb/musb/sunxi.c#L673