05:12 <Soupborsh> apritzel: Thank you but unfortunately I get 'usb_bulk_send() ERROR -7: Operation timed out' after executing it with spl and in UART it outputs this: https://pastebin.com/raw/QCZqX75s

07:19 <fraolt> anarsoul, apritzel: It's been a while with the tcon0 change on A64 and I'm really confused why it breaks things *now* on pinebook.

07:20 <fraolt> IIRC, some time ago Shane on Conduit.rs ⚡️ and Fractal 🦀️ has reported that vanilla kernel works on Teres-I. That was after 6.5 (where the referenced patch landed).

07:27 <fraolt> For reference, also this thread complained about the patch: https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw

07:28 <fraolt> In the end, it was a missing limit on max rate of one of the clocks.

07:28 <fraolt> Could you paste your clk_summary somewhere?

07:52 <anarsoul> broken: https://gist.github.com/anarsoul/03c950b0833f21175e8138a70d2737aa

07:52 <anarsoul> working 6.1: https://gist.github.com/anarsoul/92e11ebe646b79bf1e2e87fc6d7adf27

07:54 <anarsoul> broken 6.13-rc: https://gist.github.com/anarsoul/8fcc9747ed9691fc9127dadfba06dee3

07:54 <anarsoul> working 6.13-rc (with my fixes): https://gist.github.com/anarsoul/e05ac667987d930a70973c4aa8b1cfea

07:59 <Soupborsh> I wrote some C bare metal code to output characters to uart for B288. https://pastebin.com/JZx2D91b

07:59 <Soupborsh> It works.

08:10 <fraolt> anarsoul: Ok, as far as I can tell the clocks look fine.

08:10 <fraolt> So, when your patch lands, we'll need to update the pinephone DT as well.

08:11 <anarsoul> fraolt: my patches update sun50i-a64.dtsi to use pll-mipi for tcon0 clock by default, so pinephone should be covered

08:12 <fraolt> Ah, that's awesome! Can you please cc me on the patches. I'll try to test over the holidays.

08:16 <anarsoul> fraolt: I'll CC you on the next revision, meanwhile the first revision is here: https://lore.kernel.org/linux-sunxi/CAGb2v65odTCjkC493e=q57ikeKHWrKYS26N7-0Hjc=S_d6ELyQ@mail.gmail.com/T/#t

08:17 <anarsoul> I can also push it to my github repo if you prefer to grab it this way

08:20 <fraolt> anarsoul: lore is fine, thanks!

11:11 <apritzel> Soupborsh: I am getting confused as to what happens exactly, can you please confirm:

11:12 <apritzel> you can enter FEL mode via button presses upon the device starting, and then you can do your UART tricks

11:13 <apritzel> and when you upload the original boot0, via "sunxi-fel spl ....", you get all the DRAM init output, but then it hangs somewhere and does not return to FEL

11:13 <apritzel> but you don't get any output about DRAM init when you upload my patched version?

11:14 <Soupborsh> It seems to jump to FEL but it succeed sometimes.

11:14 <Soupborsh> If I get "sunxi-fel: fel_lib.c:158: aw_read_usb_response: Assertion `strcmp(buf, "AWUS") == 0' failed.

11:14 <Soupborsh> fish: Job 1, 'sudo ./sunxi-fel readl 0x1C20508' terminated by signal SIGABRT (Abort)"

11:15 <Soupborsh> When trying to readl or writel after spl boot0, it wont enter FEL mode.

11:16 <Soupborsh> If I get "usb_bulk_send() ERROR -7: Operation timed out" after some time it is in DRAM initalized FEL mode.

11:16 <Soupborsh> Also boot0 source in BSP u-boot works

11:17 <Soupborsh> I will update in in my fork now

11:22 <Soupborsh> I can boot extracted or built BSP U-Boot when I am lucky and get to FEL with initialized dram.

11:24 <Soupborsh> To boot built BSP U-Boot I have to "dd if=u-boot.img of=u-boot-dtb.bin bs=1 skip=2048" to remove header IG.

11:25 <Soupborsh> Same with exctracted U-Boot, however it does not have appended device tree.

11:33 <apritzel> to be clear: those libusb errors you get (usb_bulk_send() ERROR) from sunxi-fel mean you are *not* in FEL mode anymore

11:34 <apritzel> with the SPL command, sunxi-fel uses the FEL mode to upload the code, then does some memory copying to preserve the BootROM's FEL stack, then executes the uploaded code

11:34 <apritzel> then sunxi-fel waits till that code returns

11:35 <apritzel> if that code doesn't, because for instance it never intended to (normal boot0 code), you get those libusb errors

11:36 <apritzel> those are basically timeouts: sunxi-fel waits for some time, and if it cannot communicate via FEL after that time again, it gives up

11:38 <apritzel> and btw: there is no UART_VALUE_TX_MODE bit, this seems snake oil, you can just remove it. The UART hardware knows whether you are reading or writing, so doesn't need an extra bit

11:39 <apritzel> also: your simple C runtime example papers over two things any C runtime needs to do: set up the stack and clear BSS

11:40 <apritzel> for the stack you just keep using the BootROM FEL stack, and since you don't use any static variables, your simple code doesn't have any BSS, so you are fine

11:41 <apritzel> also you completely skip the UART pinmux and clock setup, which just works because boot0 did that already

11:41 <apritzel> for the full story refer to uart0-helloworld-sdboot.c in the sunxi-tools sources

19:18 <BroderTuck> Well, after all this time, I managed to solve a mystery. Seems my dts tweak to activate the wifi chip on my H3 box worked after all, it was just a small error in my wpa_supplicant command that kept it from working fully

19:20 <BroderTuck> This section: &reg_usb2_vbus { gpio = <&r_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7, for the rtl8723as chip */ status = "okay"; }; and in &usbphy { this line: usb2_vbus-supply = <&reg_usb2_vbus>;

19:22 <BroderTuck> Otherwise my dts is more or less a straight copy of the OrangePi PC dts

19:50 <hlauer> <apritzel> "hlix: lit by the kernel, or by U..." <- the LED is also on the V1.0 board - I saw it never lit while using mainline kernel. And the cause for the PH23 reset seems to be hidden in the axp221s difference of register 0x30 (seen at my pastebin). So ATM it look like powering through micro USB is limited to 900mA, which seems not enough to enable USB-A power

19:50 <BroderTuck> Bah, too long since I messed with this last. In the u-boot dts I apparently did it another way, and specified the PL7 gpio as a led instead.

19:58 <hlauer> Tried powering through the barrel plug but have to experiment more, as I got inconclusive results. i2c dev 0; i2c mw 34 30 63 if anybody has a m2ultra V1.1 and likes to experiment. Additionally mmc2 needs still to be disabled in DT