ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
ftg has quit [Read error: Connection reset by peer]
paulk-bis has joined #linux-sunxi
paulk has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi
machinehum has joined #linux-sunxi
<machinehum> Do people here know the status of part like this getting mainlined?
Daaanct12 has joined #linux-sunxi
Danct12 has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
Daaanct12 is now known as Danct12
<jernej> machinehum: just check DT in linux-next. Initial DT landed just 12 days ago and currently supports only UARTs: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/riscv/boot/dts/sophgo/cv1800b-milkv-duo.dts
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
buttersalt has quit [Remote host closed the connection]
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
junari_ is now known as junari
<junari> warpme: if you want to try, I added new patch with dram para from your "old" miniarch image
<junari> apritzel: you can try too, I made changes based on your comments
junari has quit [Remote host closed the connection]
<Jookia> usb gadget is broken too on this board :(
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
bauen1 has joined #linux-sunxi
apritzel has joined #linux-sunxi
jkm has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
machinehum1 has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<warpme> apritzel: i tested your apx313 code from ml. Works nicely (albeit in my case I still need increase dcdc3 to 1150 to have boot ongoing)
bauen1 has quit [Ping timeout: 480 seconds]
kuba2k2 has joined #linux-sunxi
tnovotny has joined #linux-sunxi
dsimic is now known as Guest3930
dsimic has joined #linux-sunxi
Guest3930 has quit [Ping timeout: 480 seconds]
tnovotny has quit [Quit: Leaving]
<warpme> junari: i applied (with some missing code) https://gist.github.com/iuncuim/2150b7a5317700314393665260ca628e still hangs :-( FYI: this lpddr4 code works for me stable: https://github.com/orangepi-xunlong/u-boot-orangepi/blob/6fe17fac388aad17490cf386578b7532975e567f/arch/arm/mach-sunxi/dram_timings/h616_lpddr4.c maybe this might be helpful?
junari has joined #linux-sunxi
<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]
junari has joined #linux-sunxi
junari has quit []
warpme has quit []
warpme has joined #linux-sunxi
tnovotny has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
tlwoerner_ has quit []
tlwoerner has joined #linux-sunxi
DarkNeutrino has quit [Read error: Connection reset by peer]
DarkNeutrino has joined #linux-sunxi
warpme has quit []
vagrantc has joined #linux-sunxi
<jernej> apritzel: how did you find importance of bit 16 in sysreg for ths?
machinehum1 has left #linux-sunxi [#linux-sunxi]
<apritzel> jernej: DarkNeutrino pointed me to this, he found that in some BSP U-Boot drop
<apritzel> jernej: wanted to ask you about this anyway:
machinehum has joined #linux-sunxi
<DarkNeutrino> Yep
<apritzel> to me it looks like we should not rely on firmware clearing this bit, especially as it's used by the SRAM driver
<apritzel> what about we add a syscon node to the THS node, as let the driver toggle this bit via the existing regmap?
<apritzel> ... add a syscon *property* to the THs node ...
<jernej> if only we could get some description of this register...
<jernej> syscon sounds good at this stage
<apritzel> the register is the same that we use to switch SRAM C ownership
<jernej> is it?
<machinehum> What's linux-next? Just a branch that's going to get merged?
<apritzel> I think so: offset 0x0 in SRAMC
<machinehum> apritzel: How are things?
<machinehum> Did you ever take a look at that V5 I sent you lol?
<apritzel> machinehum: linux-next is the staging branch for the next merge window, to detect conflict early and let people test things early
<machinehum> That's what I figured
<apritzel> machinehum: yes, I played around with the V5 board a little bit, and created a pinctrl driver for it: https://lore.kernel.org/linux-arm-kernel/20221110014255.20711-3-andre.przywara@arm.com/
<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
<machinehum> What is sophgo?
<apritzel> jernej: DarkNeutrino: this is the one breadcrumb I could find: https://github.com/bigtreetech/u-boot/commit/fc5742b9c63266cc2236b578219e27300eff52bd
<DarkNeutrino> Yep thats the commit
<DarkNeutrino> There is nothing more i know about the bit or the importance
<apritzel> I was wondering if multiple peripherals (including THS) use SRAM C, and each of them have their own bits?
<apritzel> machinehum: sophgo? in what context?
<jernej> manufacturer of risc-v soc
<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?
kuba2k2 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
tnovotny has quit [Quit: Leaving]
warpme has quit []
warpme has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
<warpme> junari: unfortunately with https://gist.github.com/iuncuim/20b1dfd767f1119c2f91bd3ce071d641 i'm still getting freezes. I done memory controller reg dumps for: your code and for well working xulong code: https://gist.github.com/warpme/a1b3f86be77d8bf91c8646d66ac43186
<warpme> there are small differences in few lines.
<warpme> it looks your code and xulong has h616_lpddr4_2133.c the same. Major differences are in dram_sun50i_h616.c and in dram_sun50i_h616.h
<warpme> defconfig i was using with ypur code: https://gist.github.com/warpme/35b28e3c7c1035c12a9e2b1fd0b35e07
JohnDoe_71Rus has quit []
warpme has quit []
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
sunshavi_ has quit [Ping timeout: 480 seconds]
kuba2k2 has quit []
sunshavi_ has joined #linux-sunxi
DonkeyHotei has joined #linux-sunxi
apritzel has joined #linux-sunxi
tlwoerner has quit [Read error: No route to host]
tlwoerner_ has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi