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
<apritzel> junari: so what are the DRAM parameter you used for the OPi Zero3? I have: DX_ODT=0x07070707, DX_DRI=0x0e0e0e0e, CA_DRI=0x0e0e,
<apritzel> ODT_EN=0xaaaaeeee, TPR6=0x3300c080, TPR10=0x402f6663, TPR11=0x24252624, TPR12=0x0e0e100f
<apritzel> gather from some boot0 dump some time ago
<apritzel> however it doesn't work: it detects only 128MB or 64MB, then hangs
vagrantc has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has quit [Ping timeout: 480 seconds]
<Jookia> wigyori: mango pi mq
diego71_ has joined #linux-sunxi
diego71 has quit [Ping timeout: 480 seconds]
colinsane has quit []
colinsane has joined #linux-sunxi
junari has joined #linux-sunxi
<junari> apritzel: a few days ago I posted here a link to all the necessary patches, although they do not use TPR6
<junari> I received my values via md.l dump in the SPI u-boot with further restoration via the driver
<junari> But they are very similar to yours
<junari> DX_ODT=0x07070707, DX_DRI=0x0e0e0e0e, CA_DRI=0x0e0e, ODT_EN=0xaaaaeeee, TPR6=0x44000000, TPR10=0x402f0663, TPR11=0x24242624, TPR12=0x0f0f100f
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
junari_ has joined #linux-sunxi
macromorgan_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
macromorgan has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
junari_ has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
junari has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
warpme has quit []
kuba2k2 has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
tnovotny has joined #linux-sunxi
dsimic is now known as Guest3814
dsimic has joined #linux-sunxi
Guest3814 has quit [Ping timeout: 480 seconds]
warpme has quit []
bauen1 has joined #linux-sunxi
kuba2k2 has quit [Read error: Connection reset by peer]
tnovotny_ has joined #linux-sunxi
tnovotny has quit [Read error: Connection reset by peer]
Daanct12 has quit [Quit: WeeChat 4.0.5]
warpme has joined #linux-sunxi
<warpme> junari: fyi: great work for h618 lpddr4 support. i backported your code and it work grat on my zero3
kuba2k2 has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
junari__ has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
<warpme> fyi: lpddr4 based opi zero2w also works nicely with lpddr4 code :-)
Danct12 has joined #linux-sunxi
<apritzel> warpme: what are the parameters you use? Because junari__'s didn't work for me, I still see 128MB and then a hang. Haven't dug deeper yet, or need to double check that the PMIC is set up correctly
<apritzel> warpme: also: as you seem to have an Zero2W: care to send a DT? And do you have the add-on board as well?
<warpme> apritzel : i'm using dram para from junari - but i need to incr. dcdc3 to 1150mV. With 1100mV i have kernel hang freeze in middle of boot :-(
<warpme> btw: i'm still on 2021.07 codebase as i added Eth support for ac200/ac300 + axp305/axp313/axp1530 support. Soon i have plan to play with kernel in-kernel h616 ephy support (but not having strong motivation as there is no yet kernel ac300 support afaik)
<warpme> re zero2w add-on board: i'm awaiting for shipment. currently i'm using uwe5622 based wifi.
<warpme> junari: fyi: your code works nicelly for lpdd4 - but compilation fails (for me) for lpddr3 variants. (probably some cosmetics in h616_ddr3_1333.c is needed?)
<apritzel> warpme: ah, 1150mV was a good hint, that now seems to work
<apritzel> (it actually writes 1140mV, since it's the 20mV range already)
<apritzel> and actually even 1140mV is not enough for me, it hangs then after leaving TF-A, but 1160mV goes further
<warpme> apritzel : indeed - i recall 1140mV was a first stable for me so I added 100mV for safety :-)
<apritzel> or wait, I think the manual is wrong about the DCDC3 encoding:
<apritzel> warpme: so 1100mV would be 0x1e, which is actually 800mV, that's surely too low
<apritzel> so fixing this it works much better now for me, with the nominal 1100mV
<warpme> apritzel : ah this explains why i recall i had total illogical results when i was playing with dcdc3. So i there bug in axp20x-regulator.c ?
<warpme> So is there bug in axp20x-regulator.c ?
<apritzel> no, the Linux version is correct - that has been confirmed with an oscilloscope back when we upstream the Linux AXP driver)
<apritzel> but there is a bug in your version of U-Boot's driver/power/axp313a.c
<apritzel> now that I have tested this successfully, I will post my version of U-Boot's AXP313a driver
<apritzel> warpme: junari__: nice team debugging effort :-)
<warpme> ah great - let me know - i will test on devices :-)
<warpme> yeah. nice to have you guys here!
<apritzel> warpme: have you ordered that expansion board for the Zero2W as well, with the Ethernet jack?
<warpme> yes
<apritzel> yeah, that's the one
junari__ is now known as junari
<junari> apritzel: warpme: you can look in my patch for axp313 there are correct value for dcdc3
<junari> it was many time ago, when we understand that datasheet is wrong
<warpme> junari - i compared mine /drivers/power/axp313.c with yours (from patchset) and only difference are some printfs....
<apritzel> junari: Firefox dislikes the certificate from yandex.ru, and the company firewall outright denies the whole domain anyway :-(
<apritzel> so I will have to wait till tonight to have a look
JohnDoe_71Rus has joined #linux-sunxi
<apritzel> so does anyone have an H616/H618 board with LPDDR4, but less than 4GB of DRAM? OrangePi shipped different images for each DRAM size, so likely the DRAM parameters are different
<junari> apritzel: company fyrewall - maybe, but my firefox say that site secure
<junari> warpme: can you please post my patch somewhere for apritzel?
<warpme> sure give me sec....
<apritzel> junari: it's not a biggie, since I can override it, but I get: Error code: SEC_ERROR_UNKNOWN_ISSUER
<junari> hmm, maybe redirection or something else
<warpme> apritzel : may you try hxxp://warped.inet2.org/opi3-zero-ddr4-uboot-junari-patches.zip ?
<junari> oh this free internet
<junari> My first opizero3 had a defective HDMI soldering, maybe something wrong with your
<warpme> junari: do you have stable operation on zero3 with your code. I had 2 hangs in last 10min....let me try zero2w
<apritzel> warpme: thanks, I got it
<warpme> apritzel : be my guest!
<junari> warpme: yes, but I test with openwrt
<junari> without problem
wasutton- has joined #linux-sunxi
<warpme> my tests are with hd live tv continuous playback - so probably a bit more stresfull (dma from video decoder to gpu with iommu)
<warpme> now i'm testing on zero2w...
<buZz> tv playback is stressfull?
<warpme> hmm - zero2w also freezes with distorted picture. oh....
wasutton3 has quit [Ping timeout: 480 seconds]
<warpme> buZz : well - after all it is contineius transfers of data between Eth - decoder - gpu - hdmi in dma mode with iommu
<buZz> at pretty low rates, isnt it?
<jakllsch> decoded video isn't low rate
<jakllsch> it's a raster image(s) for every frame
<buZz> over DMA though, shouldnt take much load?
<jakllsch> CPU no, memory yes
<buZz> is the 'with iommu' the culprit?
<jakllsch> i don't think that'll make much difference..
<jakllsch> using the IOMMU would add some iommu page table lookup traffic though
<warpme> fyi: i tested zero3/zero2w whole night playback with xulong uboot. both were stable iirc
<warpme> only diff is uboot
<junari> It's strange that your boards need more voltage when mine runs at 1100
<buZz> junari: maybe cable has high resistance ;)
<apritzel> for video decoding (and also 3D rendering) you having constant *concurrent* load on the DRAM controller:
<apritzel> one for the display engine to scan out the framebuffer (say 1080p@60Hz => ~500 MB/s)
<apritzel> and the other for the GPU or video decoder to fill the framebuffer, with a similar data rate
<junari> warpme: What do I need to do to check the situation on minimyth?
<apritzel> junari: your version of axp313.c is doing the right thing, so you really get 1.1V when you say so
<buZz> ~355MB/s , isnt it?
<buZz> i dont know but it sounds like not very high for ram?
<apritzel> not for PC hardware, no ;-)
<buZz> :)
<buZz> ok
<apritzel> but also the point is that two DMA engines constantly access potentially the same pages
<apritzel> or say nearby pages, so the DRAM controller has to close them, and reopen the other pages, which means the timing setting are really exercised and can become critical
<apritzel> so hangs during 3D rendering or video playback can point to imprecise DRAM parameters
<apritzel> that is what the old lima-memtester was exercising
<apritzel> on normal (DRAM heavy) workloads the DRAM controller stress is often dampened by the caches
<apritzel> buZz: btw: 355 MB/s is for 24bit depth, but typically framebuffers (at least on sunxi) are using 32 bits per pixel
<warpme> junari: i'm developing 2 distros. second is miniarch (enabler/bootstrap for ArchLinux on SBCs). If you want I can prepare image for you - so you will have full standard ArchLinux on Zero3....
<warpme> apritzel : nice mailing :)
<buZz> apritzel: ah, alpha too?
<apritzel> buZz: I don't know if it's actually used for an alpha channel, but just aligning each pixel on a word makes things a lot easier
<buZz> hmhm
<junari> warpme: yes please. I'll try it on my board
<warpme> sure give me few sec
bauen1 has quit [Ping timeout: 480 seconds]
mps has left #linux-sunxi [#linux-sunxi]
<junari> warpme: about lpddr3, I think it's because of the new tpr6 parameter
tnovotny_ has quit []
<warpme> junari: oh it was small cosmetics in /arch/arm/mach-sunxi/dram_timings/h616_ddr3 files. i fixed this and tested code on zero2. works ok :-)
junari has quit [Remote host closed the connection]
<warpme> junari: here is test image with 2021.07 uboot + yours lpddr4 code. https://github.com/warpme/miniarch/releases/download/20230531-6.3.5-g66a40f5ba/MiniArch-20230718-6.5.7-board-h618.orangepi_zero3-SD-Image.img.xz Install proc. help: https://github.com/warpme/miniarch#quick-start Note: this is pure ArchLinux - so config for i.e. loading sun50i_cpufreq_nvmem So it is not loaded at boot. So no cpu dvfs for software cooling. If you dont
<warpme> have cpu cooler - board may randomly turn-off by kernel ths when it reach crit trip (when die will reach 100C)
<warpme> (interestingly: adding "debug" in kernel command line significantly reduces such critical temp power-offs for me. fyi: on /boot part there is boot-debug.scr with enabled kernel "debug". you can use it to have debug kernel verbosity at Archlinux boot)
apritzel has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
bauen1 has joined #linux-sunxi
warpme has quit []
vagrantc has joined #linux-sunxi
<junari> warpme: On the first board the image is loaded, on the second - not
<junari> and hdmi does not work
warpme has joined #linux-sunxi
<junari> But HDMI didn’t work for me on my tvbox with a TV and monitor, so I think it’s a matter of the mainline drivers
<junari> With the second board that not starting, I'll see what can be done. Maybe dram_para should be another
warpme has quit []
warpme has joined #linux-sunxi
ftg has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
warpme has quit []
JohnDoe_71Rus has quit []
tlwoerner_ has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
tlwoerner has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
<GrantM11235[m]> Is the tcon on the f1c100s similar to any other chips?
apritzel has joined #linux-sunxi
buttersalt has joined #linux-sunxi