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
<tokyovigilante> ok, they are fixed now
<apritzel> thanks!
<apritzel> were you able to try the second SD card slot?
<tokyovigilante> not yet, will do now
<apritzel> I am actually curious whether this one could read at UHS speeds, so much faster than the abysmal 25MB/s on the first slot
<tokyovigilante> Only /dev/mmcblk0 currently with a card in, and no card detect it seems, where's the best place to look
<apritzel> it should be possible with specifying aldo1 as the vqmmc-supply (and NOT vmmc-supply as in my patch), and with opening up the aldo1 range to 1.8-3.3V
<tokyovigilante> would be good, presumably it's able to boot from the second slot?
<apritzel> not sure about that, depends on whether ALDO1 has the right default voltage and is enabled
vagrantc has joined #linux-sunxi
<apritzel> so try to uncomment that vmmq-supply line in there, and change it to vqmmc-supply
<tokyovigilante> so I need &mmc2 { vmmc-supply = <&reg_vcc3v3>; vqmmc-supply = <&reg_aldo1>;
<apritzel> yes
<tokyovigilante> [ 2.749024] sunxi-mmc 4022000.mmc: no support for card's volts
<tokyovigilante> [ 2.754933] mmc1: error -22 whilst initialising SDIO card
<apritzel> oh, actually great!
<apritzel> now change ALDO1's max voltage to 3.3V and try again
<apritzel> (great because it means the MMC core code correctly uses the regulator)
<apritzel> I am not an expert in this field, but to my understanding SD cards need to start negotiating at 3.3V I/O, and the only can switch to 1.8V and higher speed modes *later*
<tokyovigilante> makes sense, wasn't happy at 3.3v either though
<tokyovigilante> [ 1.647343] sun50i-h616-pinctrl 300b000.pinctrl: supply vcc-pc not found, using dummy regulator
<tokyovigilante> [ 1.649210] vdd-sys: Bringing 1000000uV into 940000-940000uV
<tokyovigilante> [ 1.650090] vcc-sd2: Bringing 1800000uV into 3300000-3300000uV
<tokyovigilante> ...
<tokyovigilante> [ 1.699512] sunxi-mmc 4021000.mmc: card claims to support voltages below defined range
<tokyovigilante> [ 1.706608] sunxi-mmc 4022000.mmc: no support for card's volts
<tokyovigilante> [ 1.709921] mmc1: new high speed SDIO card at address 0001
<tokyovigilante> thats the wifi I assume at mmc1
<tokyovigilante> [ 1.726542] mmc2: error -22 whilst initialising SDIO card
norton has quit [Ping timeout: 480 seconds]
<tokyovigilante> oh wait just max voltage for aldo1? ie 1.8-3.3v?
<apritzel> yes
<apritzel> and do you set DCDC2 in U-Boot, to 1.0V? I don't know how stable it is to change that voltage when the SoC is in full swing already, so it would be best set to 0.94V already in the SPL
<tokyovigilante> I am, shall i remove that and just set DCDC3?
<apritzel> either that, or just program it to 0.94V already there
<tokyovigilante> default 940 if AXP717_POWER
<tokyovigilante> would work then?
<tokyovigilante> or better to just remove it entirely?
<apritzel> Maybe avoid a default line in the Kconfig, but put the respective line in the _defconfig: CONFIG_AXP_DCDC2_VOLT=940
<apritzel> you could also leave this out, for an experiment, and see what the Linux driver reports, to learn about the reset voltage
<tokyovigilante> ok, will do. Still doesnt seem happy at 0.94 though, will try just return 0;-ing from int axp_set_dcdc2(unsigned int mvolt)
<tokyovigilante> [ 1.680468] vdd-sys: Bringing 900000uV into 940000-940000uV
<apritzel> oh, if it makes trouble in U-Boot, indeed just keep it out there
<tokyovigilante> Does that imply reset voltage is 0.9?
<apritzel> that looks like it, yes
<apritzel> and 0.9V is a valid VDD-SYS voltage, but since the BSP uses 0.94V, we should follow suit here
<tokyovigilante> no I just mean setting 0.94 in u-boot doesn't make any change to the SD2 slot (or bluetooth) behaviour, rest of the system seems ok
<apritzel> oh yeah, DCDC2 / VDD-SYS is unrelated to the SD card problem, it was just something I saw in your BSP regulator dump
<apritzel> in general higher voltages typically give higher stability, at the cost of a higher power consumption
<apritzel> so if they go the extra mile to set it to 0.94V, there might be a stability problem with the default 0.9V
<apritzel> but that may just show in certain situations, like higher (ambient) temperatures, or under load, or with a flaky power supply
<tokyovigilante> ok, cool, will leave it in.
<tokyovigilante> have pushed up all those changes
vagrantc has quit [Quit: leaving]
<apritzel> cool, thanks, I see it, looks good on a first glance
<apritzel> tokyovigilante: I posted the (extended version) of the AXP717 driver: https://lore.kernel.org/linux-sunxi/20240310010211.28653-1-andre.przywara@arm.com/T/
<apritzel> I would be grateful if you could test this, and ideally provide your "Tested-by" tag on the mailing list
<apritzel> (macromorgan and I can assist with the technicalities)
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
<tokyovigilante> awesome apritzel, thanks! will do.
<macromorgan> awesome. I'll test it and get it started. Thank you again for all your work.
ftg has quit [Read error: Connection reset by peer]
<libv> so by moving all template end tags }} to a new line, the parser is happy.
<libv> so fixed now, but fugly
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
junari has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
macromorgan has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<Jookia> gamiee: interesting
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
psydroid[m] has joined #linux-sunxi
apritzel has joined #linux-sunxi
<wingrime-ww> apritzel: thanks!
<wingrime-ww> apritzel: does mainline uboot have any display support for mq-r?
<wingrime-ww> apritzel: I connected one and (expectedly) got nothing
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
<Jookia> wingrime-ww: did you add the panel and enable the display engine/tcon in your device tree?
<Jookia> and enable all the modules
<Jookia> or something like that
apritzel has joined #linux-sunxi
<wingrime-ww> Jookia: I expected there something present for display in dt
<wingrime-ww> Jookia: I don't think de is diffrent, it maybe worth a try, atleast I can expect it clocked propertly
warpme has joined #linux-sunxi
warpme has quit []
<Jookia> wingrime-ww: i think you have to specify a panel or lcd timings at the very least
<wingrime-ww> Jookia: my panel have markings H050JGB50-05258Y CJ050QGH50-05442Y and no other info besides it
<wingrime-ww> Jookia: no idea where I can get timings for such panel, for other panels from china there also no much info
<libv> wingrime-ww: worst case scenario, you can guess at it
<libv> it's probably 60Hz
<libv> do you know the resolution?
<libv> feed that to cvt, and you should be in the ballpark, plus lcd panels are quite forgiving
warpme has joined #linux-sunxi
<wingrime-ww> seems 800x480
chewitt has joined #linux-sunxi
<wingrime-ww> so anyone have luck with t113 RGB in uboot?
<tokyovigilante> apritzel: I'm being gormless, but I can't get your mailing list patchset to apply to the next-20240308 tree using git-am
<wingrime-ww> for enable SUNXI_DE2 I need some patches ....
warpme has quit []
warpme has joined #linux-sunxi
<apritzel> tokyovigilante: you don't need to base it on next, really, the patches should apply on some 6.8-rc as well
<apritzel> tokyovigilante: were you able to download/extract the patches?
<apritzel> wingrime-ww: we indeed don't have DE support in U-Boot for anything beyond A64
<tokyovigilante> yup, have tried both direct mbox download from lore.kernel.org and using b4, patch 0003 not applying
<tokyovigilante> I am so far from github pull requests right now ;)
<apritzel> tokyovigilante: git am is very picky, but "patch -p1" is more forgiving
<tokyovigilante> That is the tragedy of git, that PRs are clearly not the way it was intended to work
<apritzel> so you start with git am, then apply the patch with "patch", then do "git add ...", then "git am --continue"
<tokyovigilante> oh no, seems it was a pebkac, created a branch called next-20240308, that wasn't actually a branch of next-20240308...
<tokyovigilante> add_x_powers_axp717_pmic_support.mbx
<tokyovigilante> Applying: regulator: axp20x: fix typo-ed identifier
<tokyovigilante> sorted
<tokyovigilante> Applying: dt-bindings: mfd: x-powers,axp152: document AXP717
<tokyovigilante> Applying: mfd: axp20x: add support for AXP717 PMIC
<tokyovigilante> Applying: regulator: axp20x: add support for the AXP717
<apritzel> as I said: you don't need -next, and I wouldn't really recommend it, it was just for the mailing list post, since we are so close to the merge window
<wingrime-ww> apritizel: do you know what is !SUNXI_GEN_NCAT2 witch blocks VIDEO_SUNXI
<apritzel> wingrime-ww: forget VIDEO_SUNXI, that's the legacy code for the old display engines
<apritzel> you want SUNXI_DE2
<apritzel> I don't know how much the D1 DE differs from the previous ones, but given that we are at least two generations behind with support, I don't expect this to be trivial
<apritzel> there are some old R40 patches (which don't apply anymore, and are not trivial to fix), and I hear that the H6 is close to that
<apritzel> technically we know everything we need to know, since Linux has support, and you could trace back the patches to the DRM driver
<tokyovigilante> do you want me to do any testing with the battery in?
<wingrime-ww> aprizel: does DE2 required for simple framebuffer output too RGB?
<apritzel> wingrime-ww: yes
<apritzel> tokyovigilante: I didn't put any battery charging bits in yet
<apritzel> tokyovigilante: but you can test the power key!!!
<tokyovigilante> very good
<wingrime-ww> aprizel: mainline have DE2 and rgb and I need only dt changes?
<wingrime-ww> *mainline linux
<apritzel> if you press it once when the system is up, it should power down, assuming Fedora has wired that up correctly
<tokyovigilante> so it won't charge the battery currently?
<tokyovigilante> I feel like that was working, but will check
<tokyovigilante> just waiting for my modules to xz (I should really have chosen zstd...)
<apritzel> tokyovigilante: I don't know if the AXP charges automatically, and we just need the drivers for tuning and monitoring
<apritzel> wingrime-ww: I think so, Linux should work with the right DT nodes
<apritzel> wingrime-ww: (and you don't need U-Boot or simplefb for that to work)
<tokyovigilante> cool, just booting up now, if the power button works I'll try the battery ;)
<apritzel> wingrime-ww: some DTs in arch/riscv/boot/dts/allwinner indeed have LCD panel support, so you might be able to copy or at least get inspiration from that
<tokyovigilante> ok, seems to be working well, all voltages seem correct, and the bluetooth flakiness seems to have resolved
norton has joined #linux-sunxi
<apritzel> tokyovigilante: that's great to hear!
<tokyovigilante> oh no, maybe not
<tokyovigilante> [ 230.893180] rtw_8821cs mmc1:0001:1: firmware failed to leave lps state
<tokyovigilante> and no power button sorry
<tokyovigilante> otherwise behaviour no different from previous patches, so I'll call it a win
<apritzel> tokyovigilante: was the WiFi stable before?
<tokyovigilante> yup, and remains so as long as I use rfkill to disable bluetooth
<tokyovigilante> so doesn't quite make sense for it to be a power issue, given the chip just needs 3.3v
<apritzel> can you somewhat bisect what caused it to break? Is it just the new AXP patches?
<tokyovigilante> oh sorry the bluetooth was always problematic
<apritzel> or did you do any DT changes as well meanwhile?
<apritzel> but that message above is from the WiFi?
<tokyovigilante> it works but just spews errors constantly
<tokyovigilante> Its a combined wifi/BT chip, those errors have only started with enabling bluetooth, and software disabling it is enough to stop them
<apritzel> tokyovigilante: right, I have seen similar with a similar chip in that Transpeed TV box
<tokyovigilante> the wifi has been surprisingly good, just not the fastest
<apritzel> there is the question about the 32K clock on the pin, this is what I commented in the powerseq node
<apritzel> it might be that the BT part needs that
<apritzel> maybe the datasheet says so?
<tokyovigilante> oh yup
<tokyovigilante> I can't actually find the datasheet, the pinout I found is from aliexpress, hilariously. Did find the non-SDIO one so can have a look
<tokyovigilante> thanks wayback machine
<tokyovigilante> Although that's the USB version
<apritzel> I am afraid the info I was after might depend on the SDIO/UART version
JohnDoe1 has joined #linux-sunxi
dsimic is now known as Guest2347
junari has quit [Ping timeout: 480 seconds]
dsimic has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
Guest2347 has quit [Ping timeout: 480 seconds]
warpme has quit []
<apritzel> tokyovigilante: so the vendor DT references 32Kout on PG10 for the WiFi
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
ftg has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
ftg has quit [Read error: Connection reset by peer]
ftg has joined #linux-sunxi
warpme has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
<apritzel> tokyovigilante: regarding the power key: can you check that you have CONFIG_INPUT_AXP20X_PEK compiled in?
<apritzel> does anybody know if "T95" (without any suffixes) is only used for that H616 TV box? I feel like it's a super generic name, used for years, on boxes with various SoCs? Or did the others all have a suffix?
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has quit []
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe1 has quit []
<libv> google for "t95 amlogic" gives a lot of hits as well
<libv> even rk3566
<libv> so not a reliable name at all
diego71 has quit [Remote host closed the connection]
acmeplus has joined #linux-sunxi
<libv> the X96 feels equally bad
diego71 has joined #linux-sunxi
<acmeplus> I’ve been following the progress from tokyovigilante and apritzel about the rg35xx plus. I’ve managed to get it to boot but it seems I’m not getting T-AF to work. There are no BL31 traces and in order for the kernel to boot I need to disable PSCI, but even with that I’m not getting a prompt. I’m sure I’m doing something wrong. Some traces here: https://gist.github.com/acmeplus/24290b784c727c015c5b44bc094baf0d
<acmeplus> I also have a rg35xx H, but other than the analogues and dual USB they should be identical
<tokyovigilante> hmm, not sure why TF-A isnt running, looks like its in your combined image and sunxi-fel is uploading it in your second gist.
<tokyovigilante> i do note you're trying to boot a batocera kernel by tbe looks? you might not have apritzel's PMIC patches unless you added them and built the kernel from source. Shouldn't stop you from booting the kernel though.
<tokyovigilante> If you're stuck i can build the world's worst BSP based on my Fedora testing image and send it over. its easy enough to just stuff a custom kernel in, and write u-boot on.
macromorgan has joined #linux-sunxi
<acmeplus> tokyovigilante: I'm using apritzels' kernel as well as the return 0 change for T-AF. The sdcard I used for that was the orangepi-zero2, but just to have a 64bit comparable rootfs, I don't think it matters which one I use because I've not yet reached init.
vagrantc has joined #linux-sunxi
diego71 has quit [Remote host closed the connection]
diego71 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> acmeplus: you would need to actually *load* TF-A, what you load with sunxi-fel are just the broken down components of U-Boot, the SPL and U-Boot proper
<apritzel> the easiest is to just use sunxi-fel's "uboot" load command and the combined image file:
<apritzel> sunxi-fel uboot u-boot-sunxi-with-spl.bin
<apritzel> this is the image file that contains the SPL, TF-A, U-Boot proper
<apritzel> we did the broken down load (SPL and proper separately) in the beginning just to figure out what's working
<apritzel> acmeplus: and it's great that you have the "H" model, the DT would be somewhat different, at least to accommodate the second USB port
<acmeplus> apritzel: yes, I tried the regular uboot u-boot-sunxi-with-spl.bin, but there's no activity after the Trying to boot from FEL (or MMC1 if I flash it). Not sure if I'm missing an extra debug flag or something.
<acmeplus> About the H, for batocera I just build the exact same firmware for both consoles (with the H DT) and the plus just ignores the analogues.
<acmeplus> That's of course reusing the stock kernel, since the display changes and some other bits have not been published.
Skippythekangoo has joined #linux-sunxi
<apritzel> acmeplus: mmh, that's odd, I don't immediately see something wrong with your build or boot process (with the "uboot" command)
<apritzel> what's your cross-compiler?
<acmeplus> Right now the regular one in ubuntu 22, I used linaro 7.4 before, but I can try again because I agree it does not make sense
<apritzel> no, any half way modern distro provided compiler is fine, and I'd say probably better than Linaro
<acmeplus> Yeah, that's what I thought when I started running into problems.
<apritzel> acmeplus: just to double check, can you use this binary bl31.bin? https://paste.c-net.org/TheaterNeedy
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<acmeplus> apritzel: same result, nothing after Trying to boot from FEL with sunxi-fel uboot u-boot-sunxi-with-spl.in
apritzel has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
apritzel has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
<apritzel> acmeplus: interesting. Can you try: sunxi-fel spl spl/sunxi-spl.bin write 0x40000000 bl31.bin reset64 0x40000000
Schimsalabim has joined #linux-sunxi
<apritzel> regarding the kernel: in your log it's a v6.0-rc5 one, I doubt that one would get you very far. You would at least need the AXP717 patches
macromorgan has quit [Ping timeout: 480 seconds]
norton has quit [Ping timeout: 480 seconds]
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<apritzel> jernej: smaeul: the RG35XX+ apparently connects the PMIC to the NMI pad on the H700 SoC, and the vendor DT mentions an r_intc, so I guess we need to add support for that
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<acmeplus> apritzel: same result uploading bl31.bin. And I updated the kernel before to your branch, and looks better: https://gist.github.com/acmeplus/24290b784c727c015c5b44bc094baf0d?permalink_comment_id=4981173#gistcomment-4981173
<acmeplus> another thing is that tokyovigilante shared his binary u-boot-sunxi-with-spl.bin and I have the same issue (stuck at Trying to boot FEL). So I'm going to open up the H tonight and test with that one because at this point a hardware difference (or semi fried board) is the only possible explanation.
<acmeplus> I now the plus boots even with the orange pi zero 2w 5.4 using the original stock uboot.
<acmeplus> I know the plus boots even with the orange pi zero 2w 5.4 using the original stock uboot.
<apritzel> so no sign of TF-A output after the SPL typically points to DRAM problems (what we had originally on the RG35XX+), but since you can run U-Boot and the kernel, that is unlikely to be the case here
megi has quit [Quit: WeeChat 4.2.1]
<apritzel> acmeplus: can you double check this anyway: upload TF-A after running the SPL, but do no exec/reset64 it
megi has joined #linux-sunxi
<apritzel> then do "sunxi-fel read 0x40000000 0x10000 bl31-readback.bin" and compare that to the file you wrote
<apritzel> another cause could be troubles switching to 64-bit, but since the SPL already ran successfully, this can't be it either
<acmeplus> bl31.bin and readback are identical up to 0xc070
<acmeplus> i.e. the whole bl31.bin
<acmeplus> Will connect the UART to the H later tonight
<apritzel> right, thanks, was worth a try
<acmeplus> yup, thanks a lot