00:14 <iscle> Well, after days of trying, I can't get the MMC controller (or card) to respond properly. I've checked clocks, vregs... everything should be okay, but it always triggers an error interrupt when sending a command: RTO_BACK

00:15 <iscle> Which means the card did not respond

00:18 <iscle> The code is here, only for A133 unless you add register definitions and fix the clocks. https://github.com/iscle/sunxi-tools/tree/mmc-dump-wip

00:18 <iscle> MMC peripheral should be the same as other sunxi SoCs

00:19 <iscle> Important stuff is in fel-mmc.c and fel-clock.c

00:51 <iscle> Maybe it's not working because I did not configure the delay registers...

04:32 <MasterR3C0RD> Aliasing pattern is quite odd with bank groups; 0x00-0x0F alias at 0x50-0x5F, 0x10-0x1F alias to 0x40-0x4F

04:39 <MasterR3C0RD> Which would seemingly implicate BIT(4) and BIT(6). With the bus full-width, and if my understanding from testing so far is correct, this means BIT(0) and BIT(1) aren't messed with during mapping, which pushes the offset up. This would make sense, and mean BIT(6) is the bit responsible for addrmap_bg_b1

04:39 <MasterR3C0RD> But then why is the difference of bits BIT(6) | BIT(4)?

04:51 <MasterR3C0RD> For reference, my device has 1 bank group bit; this pattern occurs when initialization is done using 2 bank group bits.

06:57 <MasterR3C0RD> For those who would like to review the code thus far: I still need to replace 2 non-critical functions from the aodzip repo that I've been using for testing (phy_dx_bit_delay_compensation implementation and simple_wr_test from aodzip), and implement a few more trainings, but U-Boot at least starts up. https://github.com/BrokenR3C0RD/u-boot/commit/30ad387e9d08d52c67361f93a9b48aab477bd2f1

08:53 <machinehum> I'm sure people here heard of the pine64 A527 board?

09:01 <gamiee> machinehum : yes, I sent here link

09:02 <gamiee> it seems A527 is much more similar to T527 in the end

09:02 <machinehum> Awesome

09:02 <machinehum> Yeah I'll certainly pick myself up one

10:01 <apritzel> gamiee: Btw: please note the SoC on that pine64.com device page. I get highly suspicious when websites try to sell me some "8-core A55 processor", without mentioning the SoC platform and model

10:01 <apritzel> I guess you wanted to avoid mentioning "Allwinner"? ;-)

10:45 <apritzel> gamiee: also: Yuzuki used the official debug UART feature of the USB-C port, and I think made some adapter for it, though I cannot find it anywhere to buy. Maybe something for Pine64 to stock?

11:04 <apritzel> MasterR3C0RD: that's quite some impressive work! Looking forward to properly review it ...

12:53 <apritzel> MasterR3C0RD: also, we had some very recent updates to the H616 DRAM code, so please check the latest history of that file in the mainline repo. For instance the size determination routine changed.

14:57 <MasterR3C0RD> apritzel: Thanks! As for the H616 changes, I quickly reviewed them; the changes made give me some ideas as to detect the bank groups (which are lower order in the address mapping), and the alternate phy_inits are a TODO in my branch atm. As for the MBUS configurations, I haven't started on those yet

15:02 <MasterR3C0RD> There's a few changes I made in the A133 driver that might be nice extras for H616 as well; for example in the DFI initialization I pulled out the mode register writes into macros that make it more clear which MR is being written, replacing a few of those magic numbers

15:11 <MasterR3C0RD> I do wish documentation for the PHY would materialize so the code was a little more comprehensible; it seems like it may be a DWC core based on how functions are named (ddrphy_phyinit_C_initPhyConfig for example). Best match based on specs would be the LPDDR4 multiPHY

15:39 <apritzel> yeah, we always wish for more documentation, but it never materialised so far, so don't hold your breath on that, and just send it

15:40 <apritzel> oh, regarding macros: please replace them with (static) functions. The result will effectively be the same (compilers are very clever these days!), but it looks better and is safer (type checking in the compiler, etc)

15:44 <apritzel> MasterR3C0RD: and feel free to send refactor patches fthe H616

15:44 <apritzel> for the H616

21:30 <MasterR3C0RD> apritzel: Heh, I actually made them macros because I didn't want to tack on another function immediately; I've split them out locally though. I also updated my copy of the `mctl_auto_detect_dram_size` code, alongside the (barely functioning) bank group and (working great) bank detection

21:30 <MasterR3C0RD> s/split them out/turned them into static functions/

21:38 <MasterR3C0RD> Still trying to unravel the bank group mystery; considering it's an XOR relationship I'm curious if it's some weird interaction between columns and bank groups