11:23 <CornflakeDeath> i've managed to get uart working in u-boot, but all it sends is its version, dram size, cpu frequency and "trying to boot from fel"

11:38 <CornflakeDeath> no matter which loglevel i choose in menuconfig. i tried enabling low-level debugging functions but that changed nothing. i also tried to "enable an early debug uart for debugging" but that needs more information like base address, input clock, register shift. when i entered some values i found it would just timeout instead of booting

11:39 <CornflakeDeath> what do i even do with this?

12:03 <smaeul> CornflakeDeath: if it says "trying to boot from FEL", it is returning control to the boot ROM, so you can execute more FEL commands

12:04 <smaeul> what is your sunxi-fel command line?

12:04 <smaeul> if you didn't tell it to do anything after the "spl" subcommand, then it's just sitting there waiting

12:05 <smaeul> but now you have DRAM initialized, so you can upload/execute some binary like U-Boot proper (and the "uboot" subcommand will do this automatically)

12:06 <CornflakeDeath> my commandline is sunxi-fel -v uboot u-boot-sunxi-with-spl.bin write 0x42000000 zImage write 0x43000000 <board>.dtb write 0x43100000 boot.scr

12:06 <smaeul> did you get any error from sunxi-fel?

12:07 <CornflakeDeath> none at all, it says it's writing image "u-boot...", then "starting u-boot" and exits

12:09 <CornflakeDeath> so it's just spl sending stuff over uart and u-boot is staying silent?

12:09 <smaeul> right

12:10 <smaeul> if you get to "Starting U-Boot (0x%08X).\n" then both SPL and all of the remaining FEL commands executed successfully

12:11 <CornflakeDeath> could u-boot's and spl's uart configs be different?

12:11 <smaeul> yes. U-Boot proper will use the devicetree for its console

12:11 <smaeul> both for choosing a UART and its pinmux

12:13 <smaeul> you need both CONFIG_UART0_PORT_F=y and referencing uart0_pf_pins from the uart0 node

12:17 <smaeul> U-Boots "debug UART" options can be helpful, but they're annoying because you have to write some C code to set up the clock/reset/pinmux... unless you cheat and use U-Boot with CONFIG_DEBUG_UART=y but SPL with CONFIG_DEBUG_UART=n, and rely on SPL leaving the UART already set up for you

12:23 <CornflakeDeath> i switched the device tree to a device that's more similar and still nothing, maybe there's something else going wrong

12:24 <CornflakeDeath> sometimes spl sends nothing over uart if i don't run uart0-helloworld-sdboot first

12:26 <smaeul> "more similar" doesn't help if that other device doesn't use port F UART

12:26 <smaeul> and there are no A13 devices in the U-Boot tree that do at the moment

12:27 <smaeul> in fact, the A13 devicetree doesn't have a uart0_pf_pins node, so you'll need to copy that from another SoC

12:28 <smaeul> I'm not sure why uart0-helloworld-sdboot would make a difference -- If SPL is configured right, then uart0-helloworld-sdboot won't be necessary, and if SPL is configured wrong, it should break whatever uart0-helloworld-sdboot set up

12:29 <CornflakeDeath> i don't get this now. inet 86vs has uart on pf2 and pf4, why would its device tree be set to something else?

12:30 <smaeul> any board _can_ have UART on PF2/PF4, but they don't, because they use port F for the microSD card

12:30 <smaeul> so arch/arm/dts/sun5i-a13-inet-86vs.dts says to use UART1 on port G for the console

12:34 <smaeul> you'd need something like `sed -e s/uart1/uart0/ -e s/pg/pf/ arch/arm/dts/sun5i-a13-inet-86vs.dts`, plus copying the uart0_pf_pins node from arch/arm/dts/sun4i-a10.dtsi to arch/arm/dts/sun5i.dtsi

12:52 <CornflakeDeath> okay, now it does get to u-boot, which sends an error: ns16550_serial serial@1c28000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19

13:13 <smaeul> CornflakeDeath: did you put the uart0_pf_pins node inside the pio node, like it is on the other SoCs?

13:15 <smaeul> that error means U-Boot is missing a UCLASS_PINCONFIG device instance for that DT node, but pinconfig_post_bind() should have created such an instance for every node inside the pio node

13:21 <CornflakeDeath> sun5i-a13.dtsi has "&pio {" and i pasted that node under there

13:22 <CornflakeDeath> under the "compatible" line, is that correct?

13:22 <smaeul> yes, that should work

13:33 <CornflakeDeath> i tried recompiling it from a completely clean source tree except for these changes and i keep getting the same error

13:35 <CornflakeDeath> what even is the issue? it does use uart0 as i wanted it to

13:40 <smaeul> CornflakeDeath: does that error prevent U-Boot from getting to a prompt? can you run the `dm tree` command from a prompt?

13:42 <smaeul> if not, add a call to `dm_dump_tree(false);` from where the error gets printed in drivers/pinctrl/pinctrl-uclass.c

13:47 <smaeul> you could also add some debugging to pinconfig_post_bind()

15:27 <jernej> montjoie: regarding https://oftc.irclog.whitequark.org/linux-sunxi/2023-07-12#32301836

15:28 <jernej> did you measure time between first and second regulator enablement

15:28 <jernej> I suspect that DT workaround isn't good

15:28 <jernej> delay is applied after regulator is enabled, at least from what I see

15:29 <jernej> montjoie_ ^

15:34 <jernej> hm... maybe ramp delay needs to be moved to reg_gmac_2v5

15:47 <jernej> oh, core also needs additional 20 ms to become ready

15:47 <jernej> so probably 2 delays are needed

15:51 <CornflakeDeath> smaeul: so, the issue was… *drum roll* i was just pressing arrow up and enter to launch it without actually reading the command, so it was running the wrong build every time. it works. thank you again

16:08 <jernej> montjoie_: another possibility why you might have issue with powering up PHY on OPi3, is that you need TF-A hack or disabling regulators in it altogether. PHY regulators must be powered off at least 100 ms before powering on again, but that can't be described in DT yet.

16:10 <jernej> apritzel: maybe we can add DT regulator property for powering down delay?

16:55 <montjoie> jernej: did you want to take leadership on this ? I have a slow down of my kerneltime for a least some months

16:56 <jernej> montjoie: hasn't been your regulator patch for net subsystem already accepted?

16:57 <jernej> I'm a bit confused what's the state here

16:57 <jernej> but yes, I can try push forward

16:58 <montjoie> only one has been accepter it remains dt and phy patch

16:58 <montjoie> i will try to push the current state with some fix added

17:01 <jernej> great, please add me in cc

17:01 <jernej> montjoie: is https://github.com/montjoie/linux/commits/opi3-v5 ok or does it need any fix?

17:03 <jernej> montjoie: interesting observation on my board: initially it works quite slow with scp (17 MB/s), but if you disable and enable interface, it works much faster (47 MB/s)

17:03 <montjoie> I need to compare my last next branch, probably the public one is obsolete

18:43 <montjoie> jernej: I found nothing more than this branch, go with it

19:04 <smaeul> jernej: fwiw, regulator subsystem has a concept of minimum off time as "off_on_delay", and fixed-regulator has it in DT as "off-on-delay-us", but there's no generic binding

19:10 <jernej> I've noticed off_on_delay, but I didn't dig enough to see where is it set

19:10 <jernej> but fixed regulator is completely fine here

19:10 <jernej> as it is the first regulator that has to be enabled

19:11 <jernej> I need to test that theory

19:43 <jernej> doesn't work

20:44 <jernej> regulator tracepoints show that AXP regulators are not powered off at boot, if left enabled by bootloader