00:01 <MasterR3C0RD> My DRAM driver is nearly complete; there are a few issues preventing my code from performing a full boot but I think I've narrowed it down to one part of initialization thanks to aodzip's tree

00:10 <iscle> apritzel: Completely offtopic question, but it's a question I've always had. What's the difference between the drivers/gpio and drivers/pinctrl folders in the linux kernel? Pinctrl ends up controlling the GPIOs, right?

00:20 <apritzel> MasterR3C0RD: yes, please send a PR with any BROM dumps you have. Though not sure smaeul will have time to merge them, my A523 dumps are still sitting there ...

00:20 <apritzel> at least they would be available publicly

00:21 <apritzel> iscle: pinctrl and gpio happen to be separate subsystems in the kernel (for pinmuxing and GPIO control, respectively), even though they might be implemented by the same hardware IP

00:22 <MasterR3C0RD> apritzel: What region of memory would I want to dump, 0x00000-0x10000?

00:23 <apritzel> MasterR3C0RD: yes, this one, but maybe also the 64K after this

00:24 <apritzel> I guess one is NBROM, the other SBROM

00:25 <apritzel> iscle: for sunxi we decided to put just one driver in pinctrl/, and registering the GPIO banks from this driver as well. Since both are using the same MMIO frame, that's the easiest

00:25 <iscle> apritzel: According to the A133 datasheet, the N_BROM and S_BROM are in the same memory location. It might be a typo? https://linux-sunxi.org/images/archive/f/f9/20230922151420%21A133_User_Manual_V1.1.pdf

00:26 <iscle> apritzel: Yeah, having everything in one place makes sense, it was a bit confusing for me when I first got into kernel stuff

00:27 <apritzel> iscle: there would be alternatives, like exporting a regmap, but since there is shared code with bank and pin decoding, it would be really a bit over the top

00:28 <apritzel> iscle: regarding the overlapping addresses: not necessarily, since only one of the BROMs would be mapped at one point in time

00:28 <apritzel> I *think* it starts with the SBROM, but then maps in the NBROM if the "secure boot" fuse is not burnt

00:35 <MasterR3C0RD> apritzel: Next 64K are blank, so will just process first 64K

00:44 <apritzel> thanks!

03:49 <MasterR3C0RD> My DRAM init code finally works! It's a mess from all the debugging, and there's a few calibration routines I still need to port that aren't necessary on my device, but it successfully starts U-Boot. I'll take a look at a later point at how different it actually is from the H616, and whether they could be merged into a single driver, but for now I'm keeping them separate.

05:10 <gamiee> https://pine64.com/product/yuzuki-avaota-a1-single-board-computer-4gb-32gb/

09:47 <apritzel> gamiee: nice! There is one nasty bug with either PLL_PERIPH0 or the MMC clock in the CCU driver, then I can hopeful send some patches

09:49 <apritzel> MasterR3C0RD: great! if you could post this at one point, as an RFC if in doubt, that would be warmly welcomed!

11:42 <dsimic> MasterR3C0RD: nice! :)

11:42 <dsimic> gamiee: woohoo, great! :)

15:00 <macromorgan> loki666: Try dropping the RAM back down to the 1100 like it exists today, but changing CONFIG_DRAM_SUN50I_H616_TPR6=0x33c00080 in your config and see if it works better?

15:01 <macromorgan> I *might* have missed that in my last upstreaming attempt... I think I did that for that value and things worked better for me

15:01 <macromorgan> I tested with the sunxi-custodian tree as-is and with 1160 for the RAM, and in both cases did very intermittently get the RAM error I hadn't seen in a while

15:02 <macromorgan> it's possible I made that TPR6 change and forgot to note it or why I did it though

15:09 <loki666> Ok I'll let you know

15:16 <macromorgan> thanks

15:25 <apritzel> macromorgan: I actually backed out the TPR6 change, because I thought it didn't make sense

15:25 <apritzel> because the idea was that we take the DRAM parameters from the BSP verbatim

15:25 <macromorgan> I'm testing that specific change on top of the sunxi-custodians branch now

15:26 <macromorgan> I thought it was a typo or something, honestly I don't know. Out of my element on the RAM stuff.

15:26 <apritzel> so if some bits needs to change, we should change that in the code, so the registers are populated correctly with the BSP TPR values

15:27 <apritzel> yeah, I got confused about this as well, so thought I better hold it back until hearing otherwise

15:27 <apritzel> that's one of the reasons I asked you to test it: to make sure it doesn't break completely

15:27 <apritzel> we now have time to fix this - but properly

15:29 <MasterR3C0RD> apritzel: I'll be happy to post my code once I clean it up; just want to get it into more acceptable condition first.

15:30 <macromorgan> I'm in no major hurry... if I get U-Boot working the next step is to fix the device detection code, and that's not looking fun

15:30 <macromorgan> :-p

15:30 <MasterR3C0RD> Somewhat unrelated, as a way to get the ball rolling a little more smoothly I quickly wrote up an issue asking Imagination for firmware and device info for the GPU: https://gitlab.freedesktop.org/imagination/linux-firmware/-/issues/5

15:32 <apritzel> MasterR3C0RD: oh dear, that sounds like a proper rabbit hole, but godspeed!

15:33 <apritzel> macromorgan: so the current TPR6 value in mainline is 0x40808080, right? And that's the same value as used by the BSP code? And you say it works better with 0x33c00080?

15:33 <macromorgan> I think it does yes... I'm testing it anyway to confirm if it fixes the RAM problem

15:35 <MasterR3C0RD> apritzel: They appear to have been making good progress on the drivers from what I've seen; most of their code is specific to BXE GPUs at the moment but there does appear to be basic Rogue support, enough that it might be possible to bring up DRM at minimum

15:36 <MasterR3C0RD> s/BXE/B-series/

22:25 <MasterR3C0RD> Any suggestions on how I would implement bank and bank group autodetection like how columns and rows are detected in the H616 driver? If I loop while checking mctl_mem_matches(1 << (config->banks + config->bankgrps + 1 + config->bus_full_width + 1)), I can get banks autodetecting, but bank groups don't seem to detect no matter what I try so far

22:27 <apritzel> jernej: junari: ^^^

22:32 <MasterR3C0RD> Actually double checked the address mapping code; the detection code for banks seems legit (mapping is set up as cols + bankgrps - 2, in addrmap[1] which is internal base 2)

22:35 <MasterR3C0RD> (typo in that above code, it's mctl_mem_matches(1 << (config->banks + config->bankgrps + config->cols + 1 + config->bus_full_width)))

22:39 <MasterR3C0RD> Address mapping for bank groups however is constant `0x01` with internal base `2`, which would imply to be that `mctl_mem_matches(1 << (config->bankgrps + 1 + config->bus_full_width))` should work; however it does not

22:48 <MasterR3C0RD> OH I think I figured it out; the addresses are probably by-bit, not by-byte are they

22:49 <MasterR3C0RD> So mctl_mem_matches won't work here; instead I need to check if the bits match

23:17 <MasterR3C0RD> That's not it... if bankgrps is too high (in my case, 2 instead of 1), it mirrors the data written to RAM+0x00 to RAM+0x50

23:44 <MasterR3C0RD> Hmm, there seems to be junk every 0x2000 bytes as well