06:32 <gamiee> Lol finally a flag to kill FEL

06:32 <gamiee> Also nice adapter jernej!

06:33 <jernej> gamiee: not sure if efuse can be programmed from 0 -> 1?

06:33 <jernej> also, thanks :)

06:34 <gamiee> jernej: I think it should be okay. I sent patch to sunxi-fel with efuse write support. (that reminds me I should revisit it again)

08:19 <jernej> I made oshwlab project for JTAG adapter: https://oshwlab.com/jernej.skrabec/jtag

08:20 <jernej> It's optimized for JLCPCB assembly (it's not pcbway as I said yesterday)

10:56 <loki666> apritzel: looks like CLK_IS_CRITICAL is needed indeed

11:15 <Jookia> apritzel: I found something a little strange. UART2 on the D1 is PB0/PB1 but the T113 doesn't have those pins, instead it must use PD1/PD2

11:18 <Jookia> it doesn't support i2c0 pinmux either

14:49 <apritzel> Jookia: but that's somewhat normal, between different packages, using the same die? I mean some GPIO pins are just not connected, partly owing to the T113s3 having fewer pins in total, I guess? Or is there more?

14:50 <Jookia> apritzel: probably. i did some patches locally for it

14:51 <apritzel> Jookia: patches for what? I mean you just would not reference those pins in the DT, and then all is good?

14:51 <Jookia> i'm using uart2 for serial

14:53 <apritzel> I still don't get it. If you are using UART2 on a T113-s3, you just must use PortD, so you describe that in the DT, and don't care about other potential pinmuxes?

14:53 <apritzel> or are you talking about U-Boot?

15:05 <Jookia> apritzel: u-boot doesn't read the dt for the pinmux functions

15:05 <Jookia> or ... it does but it doesn't know its the right thing here?

15:06 <Jookia> the functions for uboot are hardcoded so i have to patch it

15:06 <Jookia> i rebased my branch against v2024.04-rc1 and USB has failed once again, so i guess it'll be time to fix that properly soon

15:11 <Jookia> so hopefully i will FINALLY get around to that :)

15:27 <loki666> apritzel: is this ok to post ? https://gist.github.com/loki666/8b2f2791b9d9f79dd39b654516c9ecd8

16:14 <jernej> apritzel: so reason why a527 falls into data abort handler is because IRQ handler after return has bogus stack pointer. in my case is 0x2020007

16:19 <jernej> in normal case (when executing sunxi-fel) is 0x45400

17:29 <apritzel> jernej: mmh, so we might need to restore SP_IRQ? But why is that not a problem for all the other boards?

17:30 <jernej> apritzel: have no idea, but note that I experienced unexplainable FEL issues on H616 too

17:31 <jernej> at that time it looked like which toolchain I used

17:31 <jernej> although I can't give you any proof

17:38 <apritzel> Jookia: yes, U-Boot has a simplified view of the pinmuxes, which comes with limitations. Read the comment at the top of drivers/pinctrl/sunxi/pinctrl-sunxi.c

17:39 <apritzel> Jookia: but I am not sure I want to rework all that because of one single out-of-tree use case

17:40 <Jookia> you've already said adding uart2 support won't get in tree so i was just mentioning this in case you didn't know. that's all

17:44 <apritzel> I am pretty sure that meant: "it won't get in without an upstream user"

17:44 <jernej> apritzel: this hack seem to work: https://gist.github.com/jernejsk/3afa89930fc0a7f67a56a24ab637f61d \o/

17:45 <Jookia> apritzel: does that apply to all patches/features?

17:46 <apritzel> I don't see any UART2 users on D1 or T113-s3 in the mainline DTs?

17:47 <apritzel> if the changes are innocent enough to not add extra churn or not break existing user: sure, why not. But that seems to be not the case for your changes

17:47 <apritzel> so can't you just upstream your DT to mainlinue Linux and U-Boot? Then we would have an official user ...

17:49 <apritzel> jernej: boy, that's a hack! ;-) but that's indeed a good lead, gives me something to follow up tonight. Cortex-A7 and later (ARMv7+virt) can access SP_IRQ directly, so the patch could be simpler and cleaner

17:50 <apritzel> jernej: thanks (to your and your board) for debugging this! Still curious how this can be explained to have worked on all the other 64-bit SoCs before

17:51 <jernej> apritzel: I just copy & pasted some code from brom and added some code on my own. I'm not well versed in armv8 intricacies, but I learned a lot :)

17:52 <Jookia> apritzel: i mean for other features too, such as display support

17:52 <jernej> apritzel: I think some by luck? as I said, I had troubles with H616 and especially T507

17:53 <jernej> although not as much as here

19:53 <jernej> so here is also A523 openocd config file if anyone is interested: https://github.com/jernejsk/allwinner-jtag/blob/master/openocd/allwinner-a523.cfg

21:24 <kuba2k2> hello, does anyone know if there have been any attempts at getting the TV encoder (CVBS output) working on the D1s/T113? It seems like it's a bit different from the one in A10 or H3, in particular due to the presence of a "TVE TOP"

21:26 <kuba2k2> I'm not an expert in driver programming, but I was able to at least get the "colorbar" output from the chip, by setting up the registers as per the datasheet (and BSP) - though only if the TCON TV0 is not running at the same time

21:27 <kuba2k2> there seems to be something wrong with clocks, because if the picture is fed from the TCON instead of the colorbar, the colors are messed up and it goes all out of sync (i.e. the picture is rolling)

21:29 <kuba2k2> so I'm wondering if anyone has perhaps tried to do the same thing before