00:00 <apritzel> SPI NOR is much easier, since there it's less platform setup, and there is no higher protocol, just standard JEDEC command 0x03

00:03 <apritzel> but give it a try, just not sure how big and unwieldy the whole MMC code gets. And sunxi-fel has provisions for compiling target code to be uploaded

00:05 <iscle> apritzel: My original plan was to base the mmc code on the spi flash code, but I'm seeing that it really just reads/writes registers 1 by 1 by sending writel and readl commands, is that right? I mean, no real custom code is getting run on the SoC itself, it's just what's available in FEL?

00:05 <iscle> This is good because we can keep all the logic in the computer, but bad because it will be a lot slower..

00:05 <apritzel> not fully, I think, there is some code uploaded to do the transfer

00:05 <iscle> fel-remotefunc-spi-data-transfer.c could be it?

00:06 <apritzel> yes, exactly

00:06 <apritzel> but yeah, the idea is to run the non-criticial platform setup code on your host, and just let writel/readl go via FEL callbacks

00:07 <apritzel> it might be sufficient to just write some small MMC FIFO drain/fill routines in ARM code, similar to the SPI data transfer idea

00:08 <apritzel> and do the MMC command handling on the host, not sure how timing critical this is

00:09 <apritzel> so you would just need a small code snippet to do (512/4) reads from the FIFO reg, and write that to some buffer

00:10 <apritzel> then you download the buffer via the FEL read primitive, which works at ~500 KB/s

00:11 <apritzel> you would still need to be very patient for dumping even an 8GB eMMC, though ;-)

00:12 <apritzel> like 4.5 hours patient :-(

00:12 <iscle> The unisoc code I wrote dumped at 30KB/s so 500KB/s is quite fast by comparison hahaha

00:14 <apritzel> there was once some report that you can switch the MUSB to use USB2.0 transfers, and still being usable by the BROM code, reportedly giving huge performance benefits

00:52 <MasterR3C0RD> Oh, I probably should have mentioned, apritzel: That a133 patch has been working perfectly for me with USBBoot

00:53 <MasterR3C0RD> Seeing that's the only way I can boot this device with anything else (no SD card)

01:03 <apritzel> MasterR3C0RD: ah great, thanks for testing! I think it misses the rvbar_reg address, to enable 64-bit mode, did you add this?

01:05 <MasterR3C0RD> I didn't, but it's been booting fine. Hmm...

01:05 <MasterR3C0RD> Ah but I guess that's because U-Boot does that itself

01:06 <apritzel> yes, there is this 32/64-bit detection code

01:07 <apritzel> should be 0x08100040 anyway

01:10 <MasterR3C0RD> Just added that in locally as the RVBAR, USBBoot still works. That's the same value I've been using in U-Boot so not surprising

01:12 <MasterR3C0RD> I did also set up the SID maps, but I think I mentioned that before. The first 5 values of the map match the T7 according to AW Linux sources, so I presume it's the same, but the rest are blank for me; from their naming I'd assume they might be related to secure boot?

01:13 <MasterR3C0RD> In that case wouldn't be surprising if they're empty since my device isn't locked

01:17 <MasterR3C0RD> You mentioned the exact layout doesn't matter too much already, but thought it was worth noting

01:24 <MasterR3C0RD> iscle: I'd be willing to test out any eMMC code you end up throwing together for A133. In the meantime I'm starting with a clean U-Boot tree and reimplementing the DRAM code; the aodzip repo would probably work with modifications for DDR4 but I'm aiming for mainline

02:04 <iscle> Great, so the MMC remotefunc should be ready now, it's just a matter of implementing everything else in sunxi-fel. The remotefunc is as small as possible, and has just the part that read/writes data to the MMC and the busy loops that get executed afterwards. This should give us the best performance possible, leaving just regular logic and register writing for the individual FEL function calls

02:05 <iscle> https://gist.github.com/iscle/a4eb746033b24170a714569a5dd8e407

02:05 <iscle> Code is based on mainline u-boot

02:07 <iscle> Generated ARM code is 212 bytes

02:07 <iscle> For reference, generated ARM code for SPI flash is 468 bytes

04:22 <MoeIcenowy> apritzel: well technically when I implement 3G PinePhone support / R40 dual rank support, I read the code from BPi codedrop

04:22 <MoeIcenowy> but you know, I just applied the tips on the sunxi_dw driver

06:53 <MasterR3C0RD> Re-ported my code yet again, and still no dice. Quickly copied over the RE'd code from the aodzip repo, mainly to double check if it's an issue in my code or if I'm missing initialization elsewhere. It booted, so there's my answer. Now to figure out what I'm screwing up...

08:31 <sputnik2023> @iscle I tested your patch on h616/H313

08:32 <sputnik2023> I found this patch to have some issues on H616

08:34 <sputnik2023> Without this patch, the transmission and reception speeds can reach 100Mbps+

08:38 <sputnik2023> If we use this patch, the board as the sender will cause the network to be disconnected but it works fine as the receiver,and the speed is only 60Mbps used iperf3

08:43 <sputnik2023> 19: 294528 0 0 0 GICv2 74 Level 3002000.dma-controller

08:54 <sputnik2023> https://github.com/rundekugel/USBGadgetNetwork/blob/main/create-dual-rndis-and-cdcecm.sh

08:55 <sputnik2023> This script can produce RNDIS and CDC network devices

10:12 <apritzel> MasterR3C0RD: at least you have something to bisect between... You are using FEL for testing this, I hope? That should make it easy to trial-and-error

10:13 <apritzel> iscle: ah, thanks for that. Just please note to be careful with the license: You cannot take GPLed code and slap an MIT license in front of it

10:42 <apritzel> MoeIcenowy: no worries, as I don't think anybody cares, really. Especially not if you don't copy&paste large chunks of code

10:53 <apritzel> iscle: I'd say you can just drop the license and the "based on the SPI code", as there is not really anything license worthy you copied

13:34 <MoeIcenowy> apritzel: of course the codebase of u-boot dram code have diverged so much that copy-n-paste to existing driver is not so possible

13:34 <MoeIcenowy> I think it originates from the codedrop of H3 from allwinner, which have clear license text

13:57 <iscle> sputnik2023: Thanks for testing the patch! Now I remembered I also have an H616 board (TV Box) but never have tried booting anything on it yet. I'll solder the UART cables and test it out with the script you provided. It also has 4GB RAM so it should also work nicely as a UMS gadget :)

13:58 <iscle> apritzel: Thanks for the license tip, do you think we can make it GPL just like the U-Boot code? If I'm not mistaken, sunxi-tools is also GPL right?

14:22 <apritzel> yes, exactly, just keep it GPL, as the whole project. I don't know why this the SPI code was MIT in the first place

18:51 <iscle> I have the emmc init code and command sending code written, and it executes fine on the device (it does not crash) but the emmc controller reports a response timeout. I'm probably missing GPIO pull ups, or enabling some regulator. I will check a bit more tomorrow, but it's looking good!

20:09 <MasterR3C0RD> Rewrite #4 finally got the DFI starting; temporarily copied over a single routine from the other repo just for the time being; will replace it with a clean version later. My guess is that I messed up the DRAM timing setup code the first few times; this time I cross-compared Binja and Ghidra to be extra certain