<apritzel>
well, kernel-wise not too bad, nicely evolving in the last months, graphics stack patches have been posted by parthiban lately
<apritzel>
for U-Boot I hope I can post something soon and still push it into the next release, but that depends on review (hint hint MasterR3C0RD, parthiban)
<MasterR3C0RD>
apritzel: I'll be looking back at the A133 code over the next few days; any idea what cutoff will be for next U-Boot?
<apritzel>
the currently planned date for the end of the merge window is 27th Jan
<apritzel>
we can go with the current approach of having a separate DRAM driver file for now, and join them later, potentially even with some A523 code
<loki666>
Ok my use case will be the same retro gaming. With that in mind, how far fetched are sound and gpu
<apritzel>
I think parthiban should be able to answer this, IIRC he was mentioning some work on both these areas?
<loki666>
Ok thanks
<jernej>
apritzel: I'm cosidering unifying dram configuration structs back into one, because dram driver uses safe (slow) parameters for rank, width and size scanning and then different for final configuration.
<jernej>
this considerably lowers const propagation opportunities
<apritzel>
so the drivers are getting bigger then, you mean? And supporting multiple SoC in one even more so?
<MasterR3C0RD>
loki666: AFAIK, GPU is not working yet as the newer PowerVR drivers are still fairly restricted to a specific GPU (BXM-4-something I think)
<jernej>
apritzel: correct
<loki666>
Arf... That's a big issue for a retro gaming distro indeed
<MasterR3C0RD>
apritzel: Alright, will investigate over the next few days; have been tidying up the workbench a bit so I should be back on that soon
<jernej>
apritzel: and extra delay tweaking stage is needed due to now quite high speed ram (for AW case)
<apritzel>
MasterR3C0RD: PowerVR: but I thought parthiban had this sorted, somehow, or at least had some hope?
<jernej>
while this stage was included in libdram from at least H6 onwards, it wasn't really needed until now
<jernej>
PowerVR is constantly adding support for different variants, at least in kernel driver. mesa lags behind.
<MasterR3C0RD>
apritzel: He had the driver running partially, but command rewriting for Vulkan is still a bit of a mess as far as I remember
<MasterR3C0RD>
jernej: Which stage, the eyescan or something else?
<jernej>
yes
<apritzel>
loki666: Sega Genesis games should be fine, though :-D
<loki666>
Yes but the main UI is OpenGL ES
gsz has joined #linux-sunxi
<MasterR3C0RD>
The open-source drivers don't support OpenGL anyways; they're Vulkan only, so that'll end up depending on good Zink support
junari has quit [Remote host closed the connection]
<MasterR3C0RD>
jernej: I looked at eye scan before, as I think apritzel's Teclast device was using it in the DRAM driver, but it didn't seem completely necessary there at least. It also seems like the A133 driver does things differently and doesn't actually use the DMA controller like it suggests it does; however I do remember seeing that the A523 does use it
<jernej>
avaota a1 also uses eyescan. I think it can't be avoided.
<jernej>
btw, there is no dma involved in this driver
<MasterR3C0RD>
Ah, so the symbols are liars after all HAHA
<apritzel>
so I guess we go ahead with three different drivers for the time being, then look at potential consolidations later?
<apritzel>
(H616, A133, A523)
<MasterR3C0RD>
Yeah, seems like the best option; it's unlikely I'll have enough time before the window closes to get the drivers recombined
<apritzel>
well, that's pretty much out of the question already, since I don't think there is any code yet (combining H616 and A133)?
<MasterR3C0RD>
No there isn't, aside from the knowledge that the DRAM timings for the H616 work for the A133 (which saves a lot of work on my end reverse-engineering and pulling out the timings)
<loki666>
Ok I'll try to grab the unit
<MasterR3C0RD>
loki666: Where did you find this other A133P unit? The only one I knew about up to this point is the TRIMUI Smart Pro
<loki666>
Should be a MagicX Mini Zero 28
<loki666>
The MagicX Touch Zero 40 also sports a A133P
<MasterR3C0RD>
Interesting, they're stating 1.8GHz max clocks, but that's slightly inaccurate as the A133P has OPP entries up to 2.0GHz
<loki666>
Well maybe they down clock the CPU for battery... Usually it's GPU the culprit for higher emulators
<MasterR3C0RD>
Probably important to note that as well; although CPU DVFS will be in the next kernel, only the original A100 DVFS tables are set up at the moment, so clocks there are restricted to ~1.5GHz. Another thing to work on, though that should actually be quite simple to get working; fairly straightforward low-hanging fruit for anyone with access to a
<MasterR3C0RD>
vendor tree that'd like to work on that
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
ity has quit [Quit: WeeChat 4.4.4]
bauen1 has joined #linux-sunxi
<jernej>
apritzel: pushed dram fixes now make it work with my avaota a1 board. eye scan (tweaking delays) is not implemented, but it seems to work fine for the moment.
<jernej>
I'm still puzzled why loading U-Boot proper doesn't work
<apritzel>
via FEL, or SD card?
<jernej>
FEL
<jernej>
do you have any MMC tweaks that I don't?
<apritzel>
I have some fixes for the MMC mod clock, but I don't think they are critical (would just be half as fast)
<jernej>
hm... maybe I should start with proper DT file :)
<jernej>
do you have any?
<apritzel>
updated that on top of your branch, doesn't change anything ;-)
<apritzel>
I believe your clock_get_pll6() is not quite right, since you don't set CONFIG_SUNXI_GEN_NCAT2
<jernej>
apritzel: so this doesn't help, even when booting from SD card
<jernej>
apritzel: is DM pinctrl driver needed for that?
<apritzel>
Another thing I was wondering about is the SPL stack: you put it at 0x28000, I put it at 0x44000
<apritzel>
jernej: I have all those things, U-Boot proper (when booted through Syterkit) is working fine for me, including SD card and USB
<jernej>
ok, let me check that
<apritzel>
I don't know the reason why the BootROM doesn't load to the beginning of SRAM A1 anymore, but it seems like also boot0 avoids that region, so I figured I should leave it alone
<jernej>
systerkit uses 0x28000 for stack
<jernej>
I changed it to 0x44000 and fel boot still doesn't work
<apritzel>
so it shouldn't affect the return to FEL
<jernej>
ok, does SPL configure in any way?
<jernej>
*GIC
<apritzel>
no, we don't touch it, and neither does U-Boot proper
<apritzel>
it could be that we corrupt some BROM state, either its stack or some buffer?
<apritzel>
but the whole FEL operation is quite unstable for me on the Avaota. It's stable on the X96QPro+, though (which even has a power and reset button!)
<apritzel>
junari: any chance you could share your DDR3 code changes? Then I could do the debugging on that box instead ...
<jernej>
well, memtest report that he posted didn't finish properly...
<apritzel>
details ;-)
<jernej>
apritzel: but BROM stack doesn't matter in case of SD card boot, right?
<apritzel>
no, it should not
<apritzel>
maybe I could skip the whole DRAM init, I think that should still work for just testing the SPL returning to FEL ...
<jernej>
you can use xfel to init dram and then try whole SPL (without DRAM init) & U-Boot proper chain via FEL?
<jernej>
ah, xfel knows how to initialize only LPDDR4 for T527
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<jernej>
apritzel: when you're using systerkit for testing your U-Boot proper, do you use BSP TF-A?
<jernej>
or systerkit boots straight to U-Boot proper?
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.6, revision: 5.2.6+git-7609-afed1336e, build type: debug, sources date: 20160102, built on: 2024-12-18 20:43:05 UTC 5.2.6+git-7609-]
<jernej>
apritzel: looks like some security features needs to be disabled to access from non-secure world
<jernej>
it didn't solve the issue on my end, but I think it's one step closer
<jernej>
btw, I pulled the code from BSP bl31.bin
warpme has joined #linux-sunxi
ity has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<jernej>
apritzel: I believe CPU handling in TF-A can be adapted from mediatek mt8192 code, since it seems they use same IP core for CPU & cluster handling
<jernej>
apritzel: I also think we need new method in U-Boot for switching back to aarch32 mode and that's why FEL boot doesn't work
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
apritzel has joined #linux-sunxi
<apritzel>
jernej: ah yeah, testing the AArch32 return was on my list of things to check
<apritzel>
and yes, when using Syterkit, I am also using scp.bin and bl31.bin shipped with it
<apritzel>
though I think SMP didn't work anyway, IIRC, so I had to disable PSCI in the DT
smaeul_ has joined #linux-sunxi
smaeul has quit [Ping timeout: 480 seconds]
aperezdc has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
ity has quit [Remote host closed the connection]
ity has joined #linux-sunxi
junari has joined #linux-sunxi
<junari>
there's two runs of the program. The first successful one was with correct parameters, the second with incorrect ones to check that the ported code is able to find errors