00:11 <smaeul> if you still don't get any UART output, CONFIG_DEBUG_UART is your fallback. you'll need 0x5000000 / 24000000 / 2 / Y / Y / N / N for the options, and define a board_debug_uart_init function that sets the pinmux and enables the gate/reset using a couple of writel's.

00:12 <smaeul> you should then get at least "<debug_uart>" on the UART. if so, you can printf() your way through SPL to see where the normal driver is failing to come up

00:27 <apritzel> machinehum: changing the DTS will not do anything for the SPL, that's all hardcoded

00:28 <apritzel> machinehum: do you have sunxi-fel working? typically I try to enable the UART there first

02:46 <machinehum> sunxi-fel?

02:47 <machinehum> Also what version of uboot did you use? Getting some compiling errors

02:55 <machinehum> https://pastebin.com/raw/ugtGDc8S

03:02 <machinehum> [machinehum@whitebox u-boot-apritzel]$ git diff

03:02 <machinehum> diff --git a/configs/lindenis_v5_defconfig b/configs/lindenis_v5_defconfig

03:02 <machinehum> index 77b108f0c3..9b885aeed0 100644

03:02 <machinehum> --- a/configs/lindenis_v5_defconfig

03:02 <machinehum> +++ b/configs/lindenis_v5_defconfig

03:02 <machinehum> @@ -5,9 +5,6 @@ CONFIG_SPL=y

03:02 <machinehum> CONFIG_MACH_SUN8I_V5=y

03:02 <machinehum> CONFIG_SUNXI_DRAM_H6_LPDDR3=y

03:02 <machinehum> CONFIG_MMC0_CD_PIN="PF6"

03:02 <machinehum> -CONFIG_SPL_SPI_SUNXI=y

03:02 <machinehum> -# CONFIG_PSCI_RESET is not set

03:02 <machinehum> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set

03:02 <machinehum> -CONFIG_SUN8I_EMAC=y

03:02 <machinehum> CONFIG_USB_EHCI_HCD=y

03:02 <machinehum> CONFIG_USB_OHCI_HCD=y

03:02 <machinehum> Y

03:02 <machinehum> Builds fine now

03:04 <machinehum> Wait why did CONFIG_SPL_SPI_SUNXI get turned off I was just trying to disable the ethernet stuff...

03:14 <machinehum> No dice, here's the final patch https://gist.github.com/Machine-Hum/02fed051784a362a3ce98d323206f78d

03:14 <machinehum> aperezdc: You patch plus a few mods

08:05 <apritzel> machinehum: I was using latest mainline U-Boot, of course, and you should do the same

08:06 <apritzel> machinehum: there is little point in developing against an older version, plus you help testing new patches on the way

08:07 <apritzel> for instance the whole pinctrl code was reworked, so this would need adoption

08:08 <apritzel> machinehum: you would still need to adjust the pinmux for your serial in arch/arm/mach-sunxi/board.c, in the way you did it in your version

08:08 <apritzel> machinehum: what I posted was still running on an H6, though in 32-bit mode, because this is the only thing I could test

10:38 <MoeIcenowy> smaeul: how to handle cyclic dependency between rtc ccu and r-ccu?

10:59 <adjtm> smaeul, the last code you have for rv 86 panel is riscv/d1-wip, right?

11:00 <adjtm> do you have any documentation or notes somewhere, in addition of what's available in linux-sunxi?

11:04 <MoeIcenowy> smaeul: oh ignore me it's not a problem

11:05 <MoeIcenowy> my problem is just rtc-sun6i didn't probe for r329 at all w/o a compatible string added to it

11:05 <MoeIcenowy> even if there's match in ccu-sun6i-rtc

11:05 <MoeIcenowy> (because rtc-sun6i calls ccu-sun6i-rtc, the latter is not a independent driver

14:41 <smaeul> adjtm: yes, that's the latest I have. no, I don't have documentation. that's just a 1:1 translation of the driver from Sipeed's BSP dump. it doesn't work, and I haven't tried to investigate.

14:42 <adjtm> smaeul, thanks, I finally received the device after shenzhen's lockdown

15:36 <machinehum> I'm using 2022.04-rc5

15:36 <machinehum> Which is pretty much the latest

15:44 <apritzel> machinehum: not really, we merged Samuel's DM pinctrl driver two weeks ago, and that should be tagged as v2022.07-rc1 next week

15:45 <machinehum> Oh

15:46 <apritzel> yes, it's still within the merge window, but this requires some changes, so better hop on it now

15:56 <machinehum> How come in board.c CONFIG_CONS_INDEX == 1, but they all seem to be using uart0? Also what it this change for? https://gist.github.com/Machine-Hum/02fed051784a362a3ce98d323206f78d#file-v5-patch-L136 Also I changed board.c still nothin :/

15:56 <machinehum> I'm also thinking SUN50I_H6_GPH_UART0 is find, SUN50I_H6_GPB_UART0 should be 2 as well

15:57 <apritzel> the change was because I don't have a V5, but just a H6 in 32-bit mode, mimicking a V5

15:58 <apritzel> so for me I need to use the H6 pinctrl, even when defining (the fake) CONFIG_MACH_SUN8I_V5 symbol

15:58 <machinehum> Gotcha

15:59 <apritzel> those defines are just distractions, and just there because there have been there forever. I don't really see the point of this indirection, honestly, one could just write "2" in there

16:00 <machinehum> Yeah, it's not like "SUN50I_H6_GPH_UART0" make any more sense than the number 2

16:00 <apritzel> exactly

16:01 <apritzel> and CONS_INDEX_x is 1-based, because U-Boot defines it that way (it's a generic symbol)

16:01 <apritzel> consider it job security, we can't make it too easy to understand ;-)

16:03 <machinehum> lol

16:03 <machinehum> Thanks guys :D

16:04 <apritzel> it seems to be commonly accepted to hide every magic number behind a symbol, but I think that: "the H6 GPH UART uses the H6 GPH UART mux" does not convey much information

16:19 <jernej> apritzel: using macros for magic numbers is preferred in most areas of my work, but that assumes that you use descriptive macro name

16:19 <jernej> consider it replacement for comments

16:20 <apritzel> yeah, I understand the idea, but sometimes it doesn't really help, I think, and just requires me to look up that symbol to get the actual information

16:21 <apritzel> and in this case SUN50I_H616_GPH_UART0 doesn't really provide that comment functionality, since it misses the term "MUX" somewhere in there

16:22 <jernej> well, if you use IDE, it should give you exact number just by hoovering mouse over symbol. if not, it's just short search away

16:23 <apritzel> yes, ctags solves that problem, given that your index is up-to-date (which is often not true if you often jump between branches)

16:23 <apritzel> jernej: and I don't understand what an old hard disk interface has to do with that :-D

16:24 <jakllsch> heh

16:24 <jernej> :P

16:24 <apritzel> jernej: don't disappoint me and say you are using VS Code ;-)

16:26 <jernej> no, I use Krusader file manager and it has pretty good text editor integrated, which in turn uses standard KDE component for that...

16:26 <jernej> resolving symbols is basically the only thing that's missing

16:28 <jernej> well, that editor can be compared to trimmed version of Kate

16:30 <jernej> when I really need an IDE (for all that fancy GDB integration), I use Eclipse. But that's at work for MCU firmware development.

16:32 <apritzel> jernej: no need to apologise, I am cool with people not using vi ...

16:32 <jakllsch> heh.

16:33 <jernej> I could never use vi, but vim on the other hand, I use pretty often, just not for coding