00:37 <Jookia> tokyovigilante: oh! that reminds me

00:37 <Jookia> my WIP LCD patches are available here: https://github.com/Jookia/u-boot/tree/jookia_testing

00:38 <tokyovigilante> nice, thanks! getting the panel working with u-boot for good splash screen support definitely on my list.

01:31 <tokyovigilante> looks great at first glance, will plug in my panel's timing/regs and give it a roll

02:19 <Jookia> tokyovigilante: you will probably need to adapt https://lore.kernel.org/all/20240420-d1_de2-v1-0-297efca674ba@jookia.org/

02:19 <Jookia> this supports the D1 and H6, but not H616

02:20 <Jookia> it shouldn't be too hard

02:20 <tokyovigilante> great, should be able to based on the Linux drivers

02:20 <Jookia> yeah

02:20 <Jookia> if you want to merge patchsets or something that could be cool :)

02:20 <Jookia> the biggest criticism of it is that it needs to do clocking better

02:21 <Jookia> but if you have changes to make it work on H616 i am happy to carry them in my patchset

02:22 <tokyovigilante> nice, will see how much work/change is required, a lot of the linux stuff in the DE33 driver is to support YUV for video, so probably not so relevant in u-boot

02:23 <Jookia> yeah

02:23 <Jookia> i am tracking down an issue with my LCD patches- the LCD has a brighter black in linux

10:50 <tokyovigilante> apritzel: just noticed something interesting regarding the cpufreq driver on the H700, seeing this in the log with a 6.10rc2 build -

10:51 <tokyovigilante> [ 1.193545] sun50i_cpufreq_nvmem: sun50i-cpufreq-nvmem: unknown speed bin 0x6c00, using default bin 0

10:53 <tokyovigilante> I see this speedbin didn't make it into the final driver, is it worth putting it back in?

11:00 <tokyovigilante> oh sorry you did mention that during the test series, but it does seem to not then run up to 1.4GHz.

11:00 <tokyovigilante> I might add it back and do some debugging

11:02 <apritzel> tokyovigilante: yes, originally I had the 0x6c00 bin in, with the values you reported, including the 1.5 GHz

11:02 <apritzel> but as you said, this wasn't stable, so I removed it again, knowing that it would fall back to the default bin 0

11:02 <apritzel> which should give you up to 1.4 GHz

11:11 <tokyovigilante> ok, I'm only getting up to 900mhz, but I seem to have kept an old opp table around, will do some experimenting

11:16 <tokyovigilante> I may also be doing something silly as I don't have proper cpufreq nodes under /sys.

11:16 <tokyovigilante> Should I have any particular governor selected?

11:31 <tokyovigilante> sorted, needed the basic cpufreq support configured in kernel as well

11:32 <tokyovigilante> looks good, thanks

11:32 <tokyovigilante> 1416000

11:32 <tokyovigilante> localhost:/sys/devices/system/cpu/cpufreq/policy0$ cat scaling_max_freq

11:36 <tokyovigilante> in fact looks great

11:36 <tokyovigilante> 1512000

11:36 <tokyovigilante> localhost:~$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq

11:36 <tokyovigilante> localhost:~$ ./mhz

11:36 <tokyovigilante> 1511 MHz, 0.6618 nanosec clock

11:53 <apritzel> tokyovigilante: you should really rebase your branch on top of v6.10-rc2 now

11:57 <tokyovigilante> I have locally, sorry it’s just not pushed anywhere yet. it seems that either regulator improvements or the further work on the cpufreq has improved stability, or perhaps I had something miscondigured during testing previously.

11:58 <tokyovigilante> I couldn’t even reach a console prompt at 1.5GHz before, but it has run for about 5mins now with that speedbin enabled.

13:36 <apritzel> I am afraid we need a longer running test than 5 mins :-P Also I wonder if the transitions are the problem, not the frequency per se

14:45 <macromorgan> sorry... been busy but want to respond to the RTC question. We have 5 total devices (the 35XX+, the 35XXH, the 35XX-2024, the 28XX, and the 35XXSP). The 35XXSP and 28XX appear to have the external RTC, the other 3 devices do not. I was proposing we switch all 5 to the I2C bus from the RSB bus so they're more or less homogenous. That way we can use the RTC on the 2 devices that do and keep all 5 of them more or less the same.

14:45 <macromorgan> At a worst case scenario I'd like to run the 28XX and 35XXSP on I2C, and make sure in U-Boot I can run I2C to probe for the RTC for device detection.

14:46 <macromorgan> By querying MMC1, the RTC presence, and the status of GPIO110 I think I can runtime differentiate all 5 devices allowing the use of a single bootloader and image for all 5.

14:47 <apritzel> sounds ok to me. Do you really need MMC1? I guess that's the second SD card, right?

14:47 <macromorgan> MMC1 is the WiFi

14:47 <macromorgan> MMC0 is the first SD and mmc2 is the second SD

14:47 <apritzel> it's a bit tricky to access more than one MMC device from the SPL, I think

14:48 <macromorgan> I don't need wifi to work in U-Boot, it's enough to boot all 5 devices with the same devicetree in U-Boot and simply tell Linux to load the right one

14:48 <apritzel> U-Boot doesn't support WiFi anyway ;-)

14:49 <macromorgan> right, there's that too

14:49 <macromorgan> I was thinking just make a U-Boot image for the 35XX+ since it was the first device, then have a board specific function that populates the $fdt_file_name variable

14:49 <macromorgan> or whatever the variable is called

14:49 <apritzel> I understand and support that plan, but not like this

14:49 <macromorgan> then boot.scr or extlinux.conf or whatever can just use that variable

14:49 <macromorgan> okay, what would you rather do?

14:50 <apritzel> put all DTs into the FIT image, and select the right one in the SPL

14:50 <apritzel> as we do for the Pine64 and Pine64+

14:50 <macromorgan> okay

14:50 <apritzel> we might want to think about patching the DTs instead, since five DTBs blow up the image considerably

14:51 <apritzel> but this way U-Boot just naturally sees the right device tree, and we can ditch this whole "load some DTB from somewhere" completely

14:52 <macromorgan> for me I don't care which of the 5 devicetrees U-Boot uses though... as long as Linux gets the right one

14:52 <apritzel> I understand that, but that's conceptually a problem. There is one devicetree for each device, and it should be naturally bundled with the firmware

14:53 <apritzel> (having five DTBs in one image and select one of them is fine)

14:53 <macromorgan> if it's compressed it shouldn't matter too much though right? Since all 5 trees are 90%+ identical?

14:54 <macromorgan> I'll start an upstream for the 35XX+ device, then work on the code to add the other 4 devices to it

14:54 <apritzel> not sure what it would take to include decompression support in the SPL

14:55 <macromorgan> alternatively we could runtime patch the name only, assuming Linux will still load its own tree

15:03 <apritzel> Linux will not load anything

15:04 <apritzel> I understand that for more than a decade this "the bootloader loads a .dtb file alongside the kernel image" was the canonical way of doing this, but we should get away from this

15:04 <macromorgan> fair enough

15:04 <apritzel> there is *one* DT file, and that lives in U-Boot's FIT image, and gets amended and handed down through the firmware stages

15:05 <apritzel> TF-A for instance changes the DT, to add its loads address to the protected memory section

16:31 <Jookia> apritzel: unfortunately u-boot doesn't have a nice way of loading a nice signed image while preserving a DT... does it? like fit images must contain a dt, even if its just a kernel dt

16:51 <Jookia> the docs seem to heavily imply shipping a dt with the kernel image is the correct thing to do

17:36 <loki666> I never understood the U-boot / kernel dtb thing, at some point, I had an image where uboot failed to load the kernel dtb, but kernel boot just fine

17:45 <gnarface> i think someone told me that u-boot and the kernel each load the dtb separately but u-boot can also hand off some of its data to the kernel at boot?

17:46 <gnarface> seems to be so that the kernel and u-boot dtb can be different but they never are in any of our cases, do i have that right?

17:58 <Jookia> u-boot passes a dtb to the kernel

17:58 <Jookia> that dtb has to come from somewhere, maybe it's the dtb that's built in to u-boot, or maybe it's loaded from a place near the kernel

18:45 <loki666> ok thanks for the clarifications

18:48 <loki666> tokyovigilante: could you push your rebased lcd branch? I'd like to give it a try

21:38 <apritzel_> gnarface: we regularly sync the kernel DT files into U-Boot, so they are basically identical

21:39 <apritzel_> now a U-Boot build is by design device specific, so already contains the devicetree for that device

21:40 <apritzel_> so it sounds a bit odd to load a device specific file again, if we already have that available

21:41 <apritzel_> the arm64 kernel is single image, so the same kernel binary can run on every arm64 machine, it's just the DT that differs

21:41 <apritzel_> so if you just use the DT that's already part of U-Boot, and hand that to the kernel, by simply using $fdtcontroladdr, you don't need anything device specific on the kernel side anymore

21:43 <apritzel_> that means we behave like real computers: there is firmware (and the DT is part of it), and there is *any* kernel, could be a stable one, could be a new one, could be FreeBSD

21:44 <apritzel_> in the beginning of the DT story (>10 years ago) U-Boot didn't have a DT, and most bootloaders didn't even support DT, so it was required to ship the right DTB with the kernel

21:46 <apritzel_> but those days are fortunately gone, so we should catch up and stop shipping and loading DTB with the kernel

21:48 <apritzel_> and I see that there are rough edges with that approach, but I'd rather fix them than revert back to the stupid approach of the old days

21:49 <apritzel_> loki666: ^^^

21:50 <apritzel_> Jookia: do you mean a kernel packed and signed in a FIT image?

22:04 <gnarface> apritzel_: thanks for the explanation

22:56 <loki666> thanks apritzel_ l didn't knew all the details but kind of figured this was how it should works, since my kernel was able to boot without the external dtb

23:43 <Jookia> apritzel_: yes

23:44 <apritzel_> Jookia: how do you create the signed image? Through some Yocto or OpenEmbedded scripts? Or do you use mkimage directly?

23:47 <Jookia> apritzel_: mkimage with an .its. then call bootm on it. it would be nice to optionally have a dtb in the image loaded but if there's no dtb then fall back to using the controladdr

23:48 <apritzel_> I see, so does bootm complain atm if there is not .dtb in there?

23:49 <apritzel_> and do you put an initramfs in there as well, or do you just use the FIT for having a signature?

23:49 <Jookia> no, it just loads and crashes i think

23:49 <Jookia> no initrd yet