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 has quit [Ping timeout: 480 seconds]
ftg has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<cyrozap> Hi, all, I'm having some trouble getting U-Boot to boot over FEL on my Orange Pi Zero2 (H616).
<cyrozap> I've tried with both 2022.04 and git master (2022.07-rc2-00085-g6f00b97d7e), and the latest version of sunxi-fel (v1.4.2-146-g76089c8).
<cyrozap> Watching the USB communications, it seems to get stuck when trying to read the eGON bytes back from `soc_info->spl_addr + 4`.
<cyrozap> When it tries to send that command, the USB bulk out for the `aw_send_fel_request()` times out.
<cyrozap> As far as I can tell, U-Boot is correctly returning to FEL (enabling debug prints in the SPL shows "Returning to FEL sp=53a18, lr=53ad8").
<cyrozap> Okay, I went through some old files I had that *did* work, and found that sunxi-fel v1.4.2-116-g6c02224 is able to boot U-Boot 2021.07-rc3-00033-gaab8b17e94. Guess I'll be doing some bisecting...
<cyrozap> Looks like the problem is in U-Boot, since the latest sunxi-fel is able to work with that older U-Boot version.
<cyrozap> Wow, okay--building literally the exact same version of U-Boot as the working binary with the exact same build of TF-A (bl31.bin) that I originally built that U-Boot binary with doesn't work.
<cyrozap> I wonder if it's a compiler issue?
<cyrozap> Looks like last time I used aarch64-linux-gnu-gcc 10.3.0, and now I'm using 12.1.0.
adjtm has quit [Ping timeout: 480 seconds]
<bauen1> so i think more things are working now, its still complaining about some voltage regulators but gets to the shell
<bauen1> i've also found out that debian does build the dwmac-sun8i.ko driver for ethernet but doesn't ship it on the installer
<bauen1> nevermind, i do get the driver but i don't get the ethernet interface ...
apritzel has joined #linux-sunxi
<bauen1> apritzel: thanks, it worked, now i'm facing the problem that i can't get ethernet to show up as interface :)
<bauen1> syslog after boot and after trying to modprobe dwmac-sun8i.ko a few times: https://paste.debian.net/1241635/
<bauen1> judging by https://freenode.irclog.whitequark.org/linux-sunxi/2021-05-10#29866741 i should be able to ignore all of the `Jan 1 00:05:04 kernel: [ 5.597457] sun50i-a64-pinctrl 1c20800.pinctrl: supply vcc-pf not found, using dummy regulator` messages, right ?
<bauen1> perhaps a bit more problematic is the `Jan 1 00:05:04 kernel: [ 6.104178] regulator-dummy: Underflow of regulator enable count` seemingly while trying to init axp20x-regulator
<bauen1> and as far as i've found in the code `Jan 1 00:58:31 kernel: [ 3213.825357] dwmac-sun8i 1c30000.ethernet: IRQ eth_wake_irq not found` means that the stmmac_platform driver has parsed the device tree and found the ethernet entry
<montjoie> bauen1: I saw regulator-dummy: Underflow of regulator enable count which is bad
<bauen1> montjoie: my theory would be that due to `Jan 1 00:05:04 kernel: [ 6.066097] vdd-cpus: failed to get the current voltage: -ETIMEDOUT` `axp20x-regulator` fails, and during failing disables the dummy regulator twice ?
<bauen1> so in theory if i make the regulator-dummy go away it should work "better" ?
apritzel has quit [Ping timeout: 480 seconds]
<bauen1> or maybe i should try getting a newer kernel 5.17.3 or something like that from debian unstable
<bauen1> oh boy, ripping out the sd-card while its in use leads to kernel null ptr deref
<bauen1> also seems regulator related: https://paste.debian.net/hidden/9efa5c3b/
<montjoie> bauen1: try newer kernel
<bauen1> yes, trying 5.17.0-2-arm64
<bauen1> still spamming the dummy-regulator message, but ethernet works now: https://paste.debian.net/hidden/3bee67e3/
<bauen1> thanks a lot
evgeny_boger has joined #linux-sunxi
cnxsoft has quit []
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has quit []
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
adjtm has joined #linux-sunxi
apritzel has joined #linux-sunxi
adjtm has quit [Quit: Leaving]
cnxsoft has quit []
evgeny_boger1 has joined #linux-sunxi
ftg has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
evgeny_boger1 has quit [Ping timeout: 480 seconds]
smaeul_ has quit []
smaeul has joined #linux-sunxi
<smaeul> cyrozap: looks like that U-Boot version doesn't have https://github.com/u-boot/u-boot/commit/f43312c974ea, so DRAM init will be broken with GCC 11 or newer
vagrantc has joined #linux-sunxi
apritzel has joined #linux-sunxi
indy has quit [Read error: Connection reset by peer]
indy has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hallyn has quit [Remote host closed the connection]
hallyn has joined #linux-sunxi
<bauen1> just wondering, is the `go 0xffff0020` in u-boot to enter fel only valid for some older boards (i.e. not pine64-lts) ?
<bauen1> and why is poweroff implemented in linux implemented in a way that requires me to replug the power connector to get things going again o_o
<bauen1> oh wait that probably won't work with secure/non-secure and ATF
obbardc9 has joined #linux-sunxi
obbardc has quit [Read error: Connection reset by peer]
mnemoc has quit [Remote host closed the connection]
mnemoc has joined #linux-sunxi
<gamiee> bauen1 for proper power off / on, you need power management firmware => crust
<bauen1> gamiee: thanks
<gamiee> There is a lot documentation in u-boot
<smaeul> bauen1: `go 0xffff0020` only works for SoCs that have the BROM mapped at 0xffff0000, which is some subset of 32-bit SoCs
<smaeul> you can use `go 0x00000020` on SoCs with the brom at 0, but only from aarch32 mode
<smaeul> so from 64-bit U-Boot, you would need to set the standby entry address and switch back to 32-bit, which is what https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fel_utils.S#L22 does
<smaeul> bauen1: for any A64 board with a PMIC (so AFAIK all of them), poweroff should shut down the PMIC, and you should be able to turn the board back on with the power key
JohnDoe_71Rus has quit []
<smaeul> for boards with a GPIO power key / without a PMIC, you do need crust to listen for the power key press
<bauen1> oh it does work, just need to press a bit longer
bauen1 has quit [Remote host closed the connection]
bauen1 has joined #linux-sunxi
Daanct12 is now known as Danct12
evgeny_boger has joined #linux-sunxi
apritzel has joined #linux-sunxi
<bauen1> wow, the pine64-lts installing debian with encryption to an external usb device is amazingly slow, the install has been running for 3h+ now, i guess i was expecting this as it's a very suboptimal setup, but i'm still a bit surprised
<bauen1> installing to the sd-card is probably a much better choice since iirc the speed there isn't limited as much, especially not by usb 2.0
hlauer has joined #linux-sunxi
<apritzel> bauen1: I'd say it's the other way around: if your USB device isn't one of those cheap sticks, you should get about 35 MB/s out of it
<apritzel> bauen1: whereas a 3.3V SD card is limited to around 23 MB/s
<apritzel> but I have seen many USB sticks that write awfully slow (around 5 MB/s)
<apritzel> also the encryption could be the issue, if the poor A53 has to do it manually
<apritzel> bauen1: eMMC is much faster, IIRC in the region of 120 MB/s
gsz has quit [Quit: leaving]
hlauer has quit [Ping timeout: 480 seconds]
<cyrozap> smaeul: Thanks for the suggestion, but unfortunately applying that patch to the older version of U-Boot (that I was able to build with GCC 10.3.0) didn't fix the build with GCC 12.1.0.
evgeny_boger1 has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
<apritzel> cyrozap: so to summarise: you can FEL boot U-Boot built with GCC 10.3.0, but it fails when using the same source bits with GCC 12.1.0?
<apritzel> cyrozap: Does booting from SD card work?
<cyrozap> apritzel: Yes, that's correct. And I haven't tried booting via SD--I'll test that now.
hentai has joined #linux-sunxi
evgeny_boger1 has quit [Ping timeout: 480 seconds]
hentai has quit [Quit: Leaving]
hentai has joined #linux-sunxi