03:40 <MasterR3C0RD> And we have uplink; we'll need a new Ethernet variant, as the reset value is 0x58000 in the syscon but there's no integrated PHY, but the A64's SYSCON variant works

03:50 <parthiban> MasterR3C0RD: Morning. Managed to get the IP as well?

03:51 <MasterR3C0RD> parthiban: Yep, even SSH'd in through it. Seems to be having trouble getting a 1Gbit link, but that might be something I'm doing wrong at this point

04:02 <parthiban> What's the change? only syscon node?

04:04 <MasterR3C0RD> All of the things that you had posted got modified in one form or another; syscon, ethernet, PHY node; plus a modification to the ethernet driver to add the new reset value

04:10 <parthiban> MasterR3C0RD: Post the changes somewhere I can pick and give a try,

04:18 <MasterR3C0RD> parthiban: Just committing the DTSI and driver changes to my branch; then I'll send a Gist with the DTS nodes that worked for getting ethernet running on my end

04:28 <MasterR3C0RD> parthiban: Pushed up the fixes to my `allwinner-a100-stage3` branch, and here's what my DTSI looks like: https://gist.github.com/BrokenR3C0RD/c12261e7e3e8df2d0c3e26d57cf0de3f

04:29 <MasterR3C0RD> s/DTSI/DTS/

04:50 <MasterR3C0RD> Also, I just pushed up a few DRAM init changes you can give a try on your 4GiB board

04:55 <parthiban> Wow, I will try that. Much needed to play with custom PCB

04:58 <MasterR3C0RD> There's some mystery data in TPR13 that I haven't quite figured out the purpose of yet, which I presumed was rank bits; however, that doesn't make sense after further inspection. Hopefully these changes will do the trick for you though

04:58 <MasterR3C0RD> These changes being removing that code

04:59 <MasterR3C0RD> Also added a few memory barriers, DRAM scanning seemed like it would fail every once in a while on my board, but after adding a few extra barriers it became much more consistent.

05:54 <parthiban> MasterR3C0RD: https://pastebin.com/raw/sFrFdLvM

05:55 <parthiban> Did I miss something? I used the para, tpr values from the vendor u-boot

05:59 <MasterR3C0RD> Hmm, I wouldn't think you are: I believe the result you're getting implies that it is aliasing at the 2GiB boundary; in other words, where it would switch to the second rank

06:00 <MasterR3C0RD> Or at some multiple thereof

06:01 <MasterR3C0RD> The parameters it's getting from the auto configuration appear to be perfect

06:02 <MasterR3C0RD> They add up to a full 32 bits of address space; in other words, 4GB

06:03 <MasterR3C0RD> So that points to the address mapping of the rank bit being the culprit

06:06 <MasterR3C0RD> I'm afraid I won't be able to dig any deeper into this tonight, but considering the parameters you're getting look perfect, and that the aliasing pattern isn't changing, that's likely what's going on

06:10 <MasterR3C0RD> Considering I haven't had DRAM init issues on my board since the last few issues were cleared up, and we know the LPDDR4 init code is stable on other devices, that's basically the only difference significant enough to cause this board to not come up yet

06:37 <parthiban> https://pastebin.com/raw/wMMepMT9

06:38 <parthiban> MasterR3C0RD: How do I map this dram_para from vendor u-boot into the upstream one?

06:38 <parthiban> https://pastebin.com/raw/vrJjALbp I see some differences comparing with this.

06:40 <MasterR3C0RD> They mostly line up in the same order as shown there

06:40 <MasterR3C0RD> There's a few unused MRs that are zeroed out on both sides

06:43 <MasterR3C0RD> But the value that tends to differ most frequently is para1, which is, for all intents and purposes, unused by my init code

06:44 <parthiban> I tried booting with older u-boot. So probably the difference in boot0 is from that.

06:48 <MasterR3C0RD> boot0 does something to some of the parameters before they end up in the hands of the DRAM init function, though I'm not entirely sure what. It doesn't appear to cause enough issues to break everything down, however

06:51 <MasterR3C0RD> If you're in a rush to boot U-Boot on your device now, and don't mind if you only have access to half your RAM, I can provide you a patch that'll just disable the second rank for now; it'll only initialize 2GiB, but that would be plenty for basic testing

06:52 <MasterR3C0RD> But I will likely have the fix tomorrow

08:06 <parthiban> MasterR3C0RD: Am using helper board for the development for the display stuff anyways. Not in a rush.

11:20 <junari> tokyovigilante: I'm migrating patches from kernel 6.9 to 6.11 and for some reason I can't run the lcd on my anbernic. Maybe you can suggest something?

11:22 <junari> I get the following log [ 13.939063] platform 6511000.lcd-controller: deferred probe pending: (reason unknown)

11:54 <loki666> junari: here are my patches for 6.12 https://github.com/ROCKNIX/distribution/tree/dev/projects/Allwinner/patches/linux/H700

12:03 <junari> loki666: Thanks. I hope I have found the problem. I did not check the panel name in the driver

13:55 <MasterR3C0RD> parthiban: Sounds good; any progress on that front?

13:57 <parthiban> MasterR3C0RD: figured out display clock and tcon_top. Also I know what to do for lcd controller, mostly phy init varies. Mixer is what am checking now.

13:57 <parthiban> Btw, how is your display connected? DSI or LVDS/LCD?

14:02 <MasterR3C0RD> Not 100% sure, as I haven't verified that yet, but considering the higher pin count of the display ribbon, I'd presume it's LVDS

14:03 <parthiban> Difference is that it shares the PHY between LVDS and DSI.

14:11 <MasterR3C0RD> Hmm, vendor tree uses rgb18 PINCTRL

14:11 <MasterR3C0RD> So it actually uses DE/SYNC

14:13 <MasterR3C0RD> In other words parallel RGB

14:25 <parthiban> Init sequences varies. Atleast it's documented/

14:33 <MasterR3C0RD> Always nice when things are as described

14:33 <MasterR3C0RD> s/as//

21:58 <MasterR3C0RD> Ahhhh I know what the extra code in address mapping was for; that's how boot0 stores info about 1.5GB and 3GB configurations

22:18 <MasterR3C0RD> Also, I had a sneaky little bug in some of the address mapping code that could have potentially been causing some of the aliasing weirdness with bank groups. Will have to check again though

22:18 <MasterR3C0RD> Surprised it didn't cause any other issues though

22:31 <MasterR3C0RD> Unimportant, but I think boot0 might always expect there to be 2 or 3 bank bits. So far it seems like everyone's boards have had 2 or 3 bank group bits, and there's only handling in boot0 for `banks = 3` and `banks != 3`; however both always set at least 2 bank bits, with the `banks == 3` check simply allocating an extra bank bit in the address map

22:41 <apritzel> MasterR3C0RD: ah, any insight on 1.5GB configurations are warmly welcome, since we have H616 boards with that size, which we don't support atm

23:06 <MasterR3C0RD> apritzel: It mainly just seems to be a special case in the address mapping that shifts around address mapping a little, aside from that it's nothing too crazy

23:09 <MasterR3C0RD> I'll take a deeper look when I start combining this driver with the H616's

23:29 <apritzel> thanks! and just to be sure: this odd size can be auto-detected, right?

23:49 <MasterR3C0RD> Yep, boot0 just checks for mirroring at the 1.5GB mark

23:49 <MasterR3C0RD> Or 3GB