<junari>
warpme: one thing that different is that 4 lines from clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x390, BIT(5), BIT(4)); try to comment it
<junari>
There are no differences in other registers
junari has quit [Remote host closed the connection]
chewitt has joined #linux-sunxi
<warpme>
junari: i had commented them already.... To be 100% sure we are using the same code: may you pls provide me full latest dram_sun50i_h616.c and h616_lpddr4_2133.c ?
DarkNeutrino has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
kuba2k2 has joined #linux-sunxi
paulk-bis has quit []
paulk has joined #linux-sunxi
JohnDoe_71Rus has quit []
junari has joined #linux-sunxi
bauen1 has joined #linux-sunxi
junari has quit [Remote host closed the connection]
<apritzel>
(which was admittedly an example for the pinctrl driver rework, but still)
<jernej>
DarkNeutrino: can you tell which file to check for that bit?
<jernej>
apritzel: I believe that AW changed mappings on H616. IIRC warpme reported some strange connection between Cedrus and THS.
<apritzel>
machinehum: my feeling is that with the T113s patches being ready now, adding U-Boot support will be much easier, as I believe the V5 is another NCAT2 SoC?
<machinehum>
Could you get it booting? last I was trying I couldn't get the ddr init stuff working
<jernej>
so mappings should be investigated
<machinehum>
apritzel: I'm not sure
<apritzel>
jernej: yeah, I had testing this in U-Boot on my list
warpme has joined #linux-sunxi
<machinehum>
All I know is I spent 2 weeks straight reverse engineering some blob
<apritzel>
jernej: I can confirm that just clearing bit 16 fixed the THS reading for me
<DarkNeutrino>
The file ? Apritzel can you post the link to the commit ? Im on the phone and not close to the PC for another hour or 2
<apritzel>
machinehum: "Sophon(Beijing) is a subsidiary of Bitmain, focusing on the development of artificial intelligence chips and artificial intelligence products."
<machinehum>
I thought that was CVITEK
<machinehum>
That made this CV1800b
<machinehum>
Bitmain? The bitcoin mining equiptment company?
<jernej>
apritzel: so I guess this must be in boot0 binary? I doubt they have it in U-Boot proper
<jernej>
apritzel: looking into cedar-ve driver, logic for sram is inverted to usual one. driver clears all bits but msb
<jernej>
for some reason all 31 bits are first set and then cleared
<apritzel>
jernej: I have no real clue, just the observation that clearing bit 16 fixes THS
<jernej>
I planned to do some work on H616 over the weekend anyway, so I'll test this a bit
<apritzel>
I was looking already at the regmap/syscon code we use in the EMAC driver, looks not too hard, if a bit elaborate for just flipping a single bit
<jernej>
according to comments I see, 0x3000000 register is just for sram mapping between cpu and peripherals
<jernej>
but it's a bit weird that cedrus driver claims all of them, including one for ths
<apritzel>
... which might be just "because it works" (TM). Maybe each peripheral uses just a chunk of SRAM C, and has its own switch bit?
<jernej>
ah, ths vendor driver has a nice comment in it: "It is necessary that reg[0x03000000] bit[16] is 0."
<jernej>
apritzel: yeah, I'm afraid that is most likely explanation. I'll try to determine which are important for cedrus. They shouldn't overlap.
<apritzel>
we don't use SRAM C from the CPU side after the SPL (I think), so we don't really care what happens with that chunk, as long as the peripherals are happy
<apritzel>
jernej: ah, yeah, figuring out what bits cedrus really needs would be a good experiment
<jernej>
afaik, this mapping exists just to allow bigger SPL/boot0
<apritzel>
yes, and this seems to be also Allwinner's intention
<apritzel>
just for early booting, and then it belongs to the peripherals
<apritzel>
which sounds reasonable and efficient to me
<apritzel>
machinehum: I haven't forgotten about it, but it's all a question of priorities. At the moment many more people are pushing for T113/D1, H616/H618, and even F1C200s, so V5 is just at the end
<machinehum>
apritzel: Oh no worries lol, I'm just curious if you took a look. TBH I abandoned that project anyways
<machinehum>
What's going on with the F1C200s?
<gamiee>
V5?
<apritzel>
machinehum: lots of smaller projects seem to like it
<machinehum>
gamiee: I liked the part, because it had two camera lanes
<machinehum>
I wanted to build a stereo pair
<gamiee>
V5 is great, I know the SoC, I have that board.
<machinehum>
You just used their canned immage?
<gamiee>
Lindenis V5 BSP have greatly tuned ISP for the cameras, amazing quality
<machinehum>
Cool
<gamiee>
yeah, I used their SDK and BSP stuff
<machinehum>
At the time I was trying to mainline stuff... was challenging to say the least
<apritzel>
in general supporting a new SoC is quite some work, partly because AW likes to change things for little reason here and there, and partly because our driver and firmware design is not very forward looking
<apritzel>
the new pinctrl driver approach I posted back then was one small step in the direction to make it easier
<warpme>
jernej : it's great you will look on h616 again. If you will play with OPi Zero2 - i will be curious your potential experience with aw5622 (few days ago i pointed you for stable code which works well for me on H6, H616 and rk3566). Strange thing i'm getting that: the same aw5622 code woks well on all sbc i have but only on h616 it breaks sun50i_cpufreq_nvmem loading (kernel page fault at nvmem module load). As aw5622 code works fine
<warpme>
on h6/rk3566 - i suspect real issue is h616 specific....
<apritzel>
warpme: which version of sun50i_cpufreq_nvmem? I have seen vendor patches that were just plain wrong, plus you have that THS issue we were just talking about ...
<warpme>
apritzel : iirc lastly i synced my code ths & nvmem code to armbian current master
<apritzel>
I think Armbian carried (still carries?) one of those wrong patches
<warpme>
ah - that would be "great" - as this might be causing mine kernel page faults at nvmem module load?
<warpme>
(with aw5622 wifi)
<apritzel>
well, kernel page faults sounds unrelated to THS or cpufreq, unless you overclock your chip (inadvertently)
<apritzel>
but I guess you have a whole bunch of non-mainline patches in your branch?