<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 = <®_vcc3v3>; vqmmc-supply = <®_aldo1>;
<apritzel>
yes
<tokyovigilante>
[ 2.749024] sunxi-mmc 4022000.mmc: no support for card's volts
<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>
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
<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
<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>
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.
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]
<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