04:44 <MoeIcenowy> apritzel: looks like building TOC0 is still not part of our Makefile

04:44 <MoeIcenowy> thus I will only update eGON.BT0

12:45 <LordKalma> Moorning :) I come back to you with my usual problems, I dunno who else to ask. So I think I'm getting close on making a basic buildroot for that radio I was trying to get a firmware going. My problem is that I can't put anything on the LCD panel. The backlight is turning on, but I can't display anything... No console, no kmscube.. This is the

12:45 <LordKalma> driver I wrote: https://github.com/ruilvo/panel-jinglitai-jlt4013a

12:45 <LordKalma> I added lots of debug messages so I could see them in the boot log. This is the buildroot: https://github.com/ruilvo/AetherX6100

12:45 <LordKalma> You can see the messages from the driver popping up (eg. "[ 3.978183] Jinglitai JLT4013A: Device found at (ptrval)"). Interestingly, when i try to run kmscube it says "[ 16.701462] Jinglitai JLT4013A: Getting modes".... So it seems the driver went to "sleep" in the meanwhile? Anyway, any pointers on how I can debug this further?

12:45 <LordKalma> This is the boot log as of now: https://gist.githubusercontent.com/ruilvo/60fa52113cad7ecbd61a07c284f81fc5/raw/ce62eb228701acf67dd601ab7dde7eea23d339f4/bootlog.txt

13:37 <apritzel> LordKalma: but that's expected, isnt' it? On boot the DT is iterated, to *register* all devices, which triggers their drivers' probe routines

13:37 <apritzel> in there you register the drm_panel_funcs, but they will only be used with the first user

13:38 <apritzel> so don't you have a framebuffer console configured in your kernel?

13:39 <LordKalma> I did try to launch ksmcube, and one of the first lines after that is the driver doing something

13:40 <LordKalma> I have fbcon in the boot arguments, which is supposed to pick up the frame buffer when it becomes available from what I read in the docs

15:46 <apritzel> smaeul: do you plan on sending an actual T113 .dtsi/.dts as well? Otherwise I could fill the gaps ...

18:05 <smaeul> apritzel: yes, I have an MQ-R I can test with

18:06 <apritzel> I see, that's the same one I have. Seemed easy enough to plug the remaining holes, but I guess you have those DT bits already

18:07 <smaeul> apritzel: funny you should bring up the DE SRAM; I was testing this yesterday. the bit in the SRAM controller still exists, but defaults to 0 (map to peripheral)

18:09 <smaeul> but I don't know what address the SRAM is at in either case, because the DSP SRAM, not the DE/VE SRAM, is used for booting

18:09 <apritzel> smaeul: yeah, was just wondering, the memory map doesn't mention an address

18:10 <smaeul> setting the bit causes IOMMU faults, so it does something, but I don't know what

18:13 <smaeul> the BSP VE driver calls it the "bootmode bit", so maybe it does something else as well, or maybe they left some remapping logic in there and assumed nobody would turn it on

22:07 <apritzel> is the wiki down? Cloudflare says "Connection timed out (error 522), Host Error"