ftg has quit [Read error: Connection reset by peer]
macromorgan has quit [Ping timeout: 480 seconds]
macromorgan has joined #linux-sunxi
<apritzel>
wens: I did some experiments with CPUS_TIMER0: I can see it counting down at the expected rate when I select any other of the muxed parents, but it stops when I select the audio PLL
<apritzel>
I started both the main AUDIO0PLL and the MCU AUDIO1PLL, and I see the locked bits set, so I assume they are running fine
radxanaoki has joined #linux-sunxi
<apritzel>
do I need to set any other registers for the audio PLLs to work?
apritzel has quit [Ping timeout: 480 seconds]
dfas has quit [Remote host closed the connection]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
<wens>
apritzel: the manual describes a specific procedure for the audio PLLs, which is not at all what we do
<wens>
the downstream driver just toggles all enable-related bits together
<wens>
I might try that
<wens>
nope, dma still not firing
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump02 has quit [Ping timeout: 480 seconds]
Asara has quit [Ping timeout: 480 seconds]
Asara has joined #linux-sunxi
apritzel has joined #linux-sunxi
gsz has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
evgeny_boger has quit [Remote host closed the connection]
gsz has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
gsz has quit [Read error: No route to host]
psydroid|2 has joined #linux-sunxi
gsz has joined #linux-sunxi
gsz has quit [Read error: Connection reset by peer]
<Jookia>
for anyone vaguely interested, i have an updated t113-s3 manual. the OWA section is noticably changed, with the RX and expand stuff being completely removed
psydroid|2 has quit [Ping timeout: 480 seconds]
<Jookia>
I also have a T113-S4 datasheet that refers to the product series as 't113x'
psydroid|2 has joined #linux-sunxi
psydroid|2 has quit []
_whitelogger has joined #linux-sunxi
apritzel has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
dsimic is now known as Guest26262
dsimic has joined #linux-sunxi
Guest26262 has quit [Ping timeout: 480 seconds]
<Jookia>
apritzel: digging through the t113-s4 stuff, it looks like nothing needs to be changed in uboot or the config. kind of. the dump i have of the BSP has TPR13 of 0xb4006103 and awboot has the DRAM_CLK as 936
<apritzel>
Jookia: I see, but those are *board specific* DRAM parameters, so we expect them to be different for each board anyway, so it shouldn't be an issue
<apritzel>
Now since the DRAM is on the package, they should be all the same, ideally, but we don't know if Allwinner is using different DRAM chips for different batches of T113-s3, for instance
<apritzel>
but I would expect the t113-s4 parameters to be slightly different
<Jookia>
awboot uses the same TPR13 as the t113-s3 but for the t113-s4
<Jookia>
the tpr13 here is found by dumping a device tree from the preinstalled linux on this board
<Jookia>
since sunxi's uboot 'fixes up' the dram_para dt nodes
<Jookia>
maybe those are different to the ones used for setup
<apritzel>
mainline U-Boot also changes TPR13 during setup
<Jookia>
the b4006103 is present in the eGON header too
<apritzel>
Jookia: so is there actually a problem? Does it not work, neither with the T113-s3 parameters nor with the other values?
<Jookia>
apritzel: i haven't done a build for the board yet, i have to make a device tree and things like that so i'm just digging through the BSP today to get some questions answered
<Jookia>
ok, sys_config.fex uses 0x34000100. so the t113-s3 ram config should be completely fine.
<Jookia>
i don't quite understand why awboot is clocking the dram up to 936
<Jookia>
it is a mystery
<apritzel>
why not? if it works for them? The DRAM chips are surely different, so might take a higher frequency.
<Jookia>
i mean yeah but that might end up leaving people with boards that don't boot because their t113s4 doesn't support that frequency
gsz has joined #linux-sunxi
<Jookia>
and no clear reason why
<apritzel>
AW is routinely underclocking DRAM in general, for unknown reasons. We suspect it's to leave some wiggle room for board differences
<apritzel>
now with co-packaged dies there is much less variation, so going higher might be fine
<gamiee>
it surprises me that allwinner uses that very bad .fex files
<Jookia>
is there that much speed benefit clocking RAM higher?
<apritzel>
gamiee: .fex seems to be some file extension they like, they use that everyone, and it's often unrelated to that old FEX format
<gamiee>
haha yeah :D
<apritzel>
use that *everywhere*
<Jookia>
.fex? more like .ini
<gamiee>
even binaries sometimes have .fex
<apritzel>
exactly
<gamiee>
i am still waiting for that official upstreaming announced by Tom Cubie...
<apritzel>
Jookia: .fex in an ini-style format was used by Allwinner ages ago before they switched for devicetree, as a replacement for DT
<gamiee>
but .fex is still used for configuration
<gamiee>
at least, i saw it multiple times being a thing
<buZz>
retrocomputing is still popular :)
macromorgan has quit [Ping timeout: 480 seconds]
<gamiee>
buZz: allwinner likes to re-use everything. Heck, their tools are from 2012 and are mix of lua scripts and other weird stuff
<apritzel>
Jookia: I could measure decent performance improvements on memory benchmarks (like 20% ish) when clocking some boards higher
<Jookia>
wow
<buZz>
gamiee: thank heavens #linux-sunxi exists to get this HW back to normal linux :)
<gamiee>
buZz: exactly! That's why I love this community. (although not participating actively right now)
<gamiee>
still I tend to read what's happening here when I can :D
<buZz>
being on irc, you're more active than 99% of ppl that use its productions ;)
<apritzel>
Jookia: as mentioned, we often have say DDR3-1600 chips, but AW clocks them at 672 MHz (which should be 800 MHz instead)
<apritzel>
the other DRAM parameters specified by JEDEC (latencies, for instance) are also often very conservative, leaving performance on the table
<gamiee>
and the worst thing is, we do not know why AW uses such configuration. If it's due that random TV box vendor can just use the SoC and do low-cost board and layouting, so it will work "everywhere", or it's due silicon limitations/bugs/whatever.
<apritzel>
gamiee: yeah, exactly. It looks like it's the former, though
<apritzel>
not surprised, and little to no commit messages are unfortunately standard in "github land" :-(
<Jookia>
yeah. it's disappointing
<Jookia>
i don't think people realize just how important it is to justify your change
<Jookia>
there's not really unit tests for hardware so often times you're just kind of guessing whether it's okay to change something :(
<apritzel>
yeah, and often enough there was quite some research involved in finding the issue, so that info should be preserved (and not dumped into some web forum)
radxanaoki has quit [Quit: radxanaoki]
JohnDoe_71Rus has joined #linux-sunxi
<Jookia>
apritzel: would you like me to put my clocking notes in the wiki somewhere? i'm not sure exactly how considering it has a lot of files with it, and it's very specific. but i think it belongs on the wiki
<apritzel>
Jookia: yes, please, put it in the wiki
vagrantc has joined #linux-sunxi
<Jookia>
I'll try and get that done tomorrow
vagrantc has quit [Quit: leaving]
hentai has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
colinsane has quit []
colinsane has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
<paulk>
btw talking about f1c100s dram, the dw_memctl has a public datasheet that synopsys released long ago