<iscle>
apritzel: It's not hitting max USB transfer speeds but I'm not even sure that's possible anyways?
<apritzel>
I think the MUSB IP doesn't have the best reputation when it comes to performance?
<apritzel>
Definitely host mode is discouraged, and AW added a MUX and a separate EHCI/OHCI pair for USB0 in H3 and later to avoid issues
<apritzel>
what's actually important how this relates to the performance without the patch?
<iscle>
I'm going to try that now
<apritzel>
bulk PIO transfers over MMIO are definitely limited by the bus, depending on the SoC and bus speed I dimly remember like 40MB/s in practise, at least in U-Boot:
<iscle>
This is latest mainline (from 3-4 hours ago) with the two commits needed for DMA on T113/D1s
<iscle>
If anyone can help and test it, it would definitely help :)
warpme has joined #linux-sunxi
<MasterR3C0RD>
Oh I just realized my message earlier didn't send
<MasterR3C0RD>
iscle: I'm afraid I'm not using Ghidra, I'm actually using Binary Ninja since I'm more confortable with it. However, I can try to redo my work on Ghidra to make things a little easier, it'll just take a bit
tokyovigilante has quit [Remote host closed the connection]
MasterR3C0RD has quit [Quit: Page closed]
tokyovigilante has joined #linux-sunxi
MasterR3C0RD has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
<MasterR3C0RD>
Remembering why I don't like Ghidra
MasterR3C0RD is now known as MasterR3C0RD
<iscle>
MasterR3C0RD: If it's not too hard for you to redo it in Ghidra, then sure, I'll take a look! If not, I can try to do it myself from scratch and then compare it with your work :)
<MasterR3C0RD>
I think I'm realizing I would rather not LOL, a lot of the nice struct definitions will be a PITA to import into Ghidra. However, I can give an idea of the offsets that are important
<MasterR3C0RD>
Most of the register offsets inside the blocks are similar to the H616, so those can be used as a reference
<MasterR3C0RD>
CCM base is 0x03001000, MCTL_COM is 0x04810000, MCTL_CTL is 0x04820000, MCTL_PHY is 0x04830000, and PRCM is 0x07010000.
warpme has quit [Ping timeout: 480 seconds]
iscle has quit [Remote host closed the connection]
<MasterR3C0RD>
Arguments into init_DRAM are an int32 type (which is unused) and a dram_para struct. All fields are u32s; order goes dram_clk, dram_type, dx_odt, dx_dri, ca_dri, para0-2, mr0-
<MasterR3C0RD>
*para0-para2
<MasterR3C0RD>
mr0-mr6, mr11-mr14, mr17, tpr0-tpr6, and tpr10-tpr14
<MasterR3C0RD>
dram_type values are the same as H616; 0x3 = DDR3, 0x4 = DDR4, 0x7 = LPDDR3, 0x8 = LPDDR4
<MasterR3C0RD>
There's a few other notes I'll make related to the format of para0-para2 and tpr13 (which stores a bunch of flags and additional params) alongside a Gist with my ported code, probably won't be able to get that up until tomorrow though
iscle has joined #linux-sunxi
<iscle>
MasterR3C0RD: Awesome, thanks!
warpme has joined #linux-sunxi
<MasterR3C0RD>
One other thing is that in the H616 code currently in use, mctl_com->clken magically enables access to mctl_ctl and mctl_phy registers. On the A133, mctl_com->maer0 is the register responsible
<iscle>
MasterR3C0RD: had you seen that repo before? maybe it can help you by comparing it to your code
<MasterR3C0RD>
I hadn't actually; it looks like it's even more precise than my attempts
<iscle>
MasterR3C0RD: checking the commit history, the guy does says that it works, so maybe it's worth comparing it with yours and with the RE output and cleaning it up to be 1:1
<dsimic>
as a note, regarding testing the speed, when it comes to reading from USB, you can simply flush the buffer cache and use cat(1) or dd(1) to read a large file from USB pen drive to /dev/null, while using time(1) to see how long did it take
<dsimic>
when it comes to writing to USB, perhaps it would be best to set up another board as a USB gadget that would pipe the received data to /dev/null, to avoid any bottlenecks... if both boards were Allwinner, you could test both USB reads and writes that way at the same time :)
<buZz>
keep in mind that you might want bs=1M or bs=4M to better saturate all the buffers when using dd ;)
<dsimic>
yes, it's also good to test with different values
<buZz>
hmhm, but afaik dd's default will be 'per single byte' which likely is suboptimal for speed
<dsimic>
regarding the suggested USB gadget setup, perhaps setting up USB networking that way would work well for the testing purposes
<dsimic>
buZz: bs=BYTES; read and write up to BYTES bytes at a time (default: 512); overrides ibs and obs
<buZz>
ah, not as bad as i thought!
<dsimic>
which goes back to HDD sector sizes
<buZz>
also a nice dd feature on newer versions is 'status=progress'
<buZz>
to get a progress 'animation' during proces
<dsimic>
indeed
<dsimic>
I use this --> alias dd='dd status=progress conv=fsync'
apritzel has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
hipboi has joined #linux-sunxi
<apritzel>
iscle, MasterR3C0RD: careful with those Allwinner code for DRAM: please don't copy any code from there, we cannot use that then in (GPLed) U-Boot
<apritzel>
it's fine to look in there and get your "aha" moment, but keep your rev-eng-ed code clean
zfrdlc has joined #linux-sunxi
zfrdlc has quit []
zfrdlc has joined #linux-sunxi
zfrdlc has quit []
zfrdlc has joined #linux-sunxi
zfrdlc has quit []
zdelc has joined #linux-sunxi
warpme has quit []
zdelc has quit []
warpme has joined #linux-sunxi
<MoeIcenowy>
apritzel: the aodzip one says it's Based on H616 one and GPL2+
<apritzel>
MoeIcenowy: yes, but that other one (facat/BPI-M2U-bsp) said: "Allwinner Technology, All Right Reserved. 2006-2010 Copyright (c)", and no mention of any license.
warpme has quit []
iscle has joined #linux-sunxi
<iscle>
apritzel: Yeah, the AW one is just to understand a bit better what it's doing and to compare with original code, but I wasn't planning to copy any of it (and I guess MasterR3C0RD was not planning to do so either)
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
jason123onirc has quit [Read error: Connection reset by peer]
dsimic is now known as Guest6053
dsimic has joined #linux-sunxi
Guest6053 has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
JohnDoe_71Rus has joined #linux-sunxi
<macromorgan>
so for the H616 if I'm understanding the PWM controller, there's basically 3 channels (PWM0, PWM2, and PWM4). There are also "virtual" channels that are the complete and total opposite of the real channels (PWM1, PWM3, and PWM5). Does that sound right?
jason123onirc has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
wingrime-ww has joined #linux-sunxi
wingrime1 has quit [Ping timeout: 480 seconds]
wingrime1 has joined #linux-sunxi
wingrime-ww has quit [Ping timeout: 480 seconds]
iscle has quit [Remote host closed the connection]
<apritzel>
macromorgan: if with "complete and total opposite" you mean "inverted": yes, that's how I read it
<apritzel>
well, actually you can provide period and duty cycle separately for each of the *six* channels, though each pair shares a clock source and configuration
<apritzel>
so I don't know how much pain it would be to provide access to six channels individually, or if we just pretend there are only three, and you can get a complementary output, if you want one?
warpme has joined #linux-sunxi
warpme has quit []
<MasterR3C0RD>
apritzel: Dw, wasn't planning on copying that code; that's for the sun8iw11p1 (T3) anyways so that specific code isn't particularly useful
<macromorgan>
I guess I'm not fully comprehending the diagrams on 10.10.3.4 and the text of 10.10.3.5 then (on the T507 datasheet which should be the same). You can vary the timer logic, enable or disable the dead zone, and choose to bypass the clk source or not on an individual channel basis but that's it.
<macromorgan>
I hate upstreaming things I know nothing about... but that's how you learn...
<apritzel>
macromorgan: I am not 100% sure either, but the fact that the H616 only mentions channel 1, 2+3, and 4 tells me we might want to restrict ourselves to just 3 channels
<apritzel>
I will try to have a look later ...
<apritzel>
macromorgan: learning while upstreaming: exactly, and I know how you feel ;-) but at some point it usually clicks ...
<macromorgan>
apritzel: I tested what you told me to in U-Boot for the sunxi custodian tree... working fine as near I can tell
<apritzel>
macromorgan: oh, many thanks! I will push it then after some final testing
<macromorgan>
thank you
<macromorgan>
I'm trying to remember now how I got the mmc2 slot to work, and also figure out what I'm going to do for PWM
<macromorgan>
I know pin PE22 is the CD GPIO...
<macromorgan>
I think pin PE4 may be important too (possibly a GPIO controlled regulator, but I can't confirm that yet)
tiop has joined #linux-sunxi
<macromorgan>
yeah, that's it... PE22 is the CD and PE4 is a gpio controlled regulator for the logic I'm pretty sure
vagrantc has quit [Quit: leaving]
warpme has quit []
iscle has joined #linux-sunxi
<iscle>
When porting a new device to sunxi-fel (from sunxi-tools), how are the values "spl_addr", "scratch_addr", "thunk_addr" calculated?
<apritzel>
iscle: that's a bit tricky: it depends on what memory the BootROM uses (for stack, IRQ stack, heap)
<apritzel>
spl_addr is where the BootROM normally loads the SPL/boot0 payload, so 0x20000 on most recent SoCs
<apritzel>
(this could be elsewhere in SRAM, but this way we stay compatible with MMC/SPI loading, so the SPL can be linked statically against the same address)
<apritzel>
scratch_addr is a small region where sunxi-fel uploads small code snippets, like for reading MMIO registers. Normally it's just 4K after spl_addr
<apritzel>
thunk_addr is for a slightly larger area where sunxi-fel uploads the "SPL stack saver" code, so it must not be used by the BROM, and not be used by the SPL
<apritzel>
that code saves and restores the BROM's FEL stacks, to make space for a contiguous SPL. When we return to FEL after the SPL has run, it copies the stacks back, so needs to be still alive
<apritzel>
- code for the Allwinner MMC controller
<apritzel>
- generic MMC protocol code
<iscle>
I'm seeing that A133 (the device I'm porting) is the same as V831 and V536, so I'll just copy one of those configs and change the soc_id. Even the watchdog address is the same :)
<apritzel>
that's doable (as you rightly said conceptually not that far from the SPI NOR code), but much more complex
<iscle>
apritzel: About MMC, I already did that for unisoc socs, i wrote everything from scratch and it worked :)
<iscle>
It was quite slow because I did not set up the clocks, but I could read everything
<apritzel>
well, I started experimenting with generating standalone binaries (importing U-Boot code, for the DRAM init), and uploading them
<apritzel>
this would avoid duplicating the efforts and keeping everything in sync
<apritzel>
I guess we could borrow the SPL's MMC code as well, since that does everything already
<apritzel>
so you would point it to a U-Boot source directory, it would wrap the existing U-Boot source, generate a .bin file, and put it somewhere, say /usr/share/sunxi-tools