ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at
<Jookia> tokyovigilante: oh! that reminds me
<Jookia> my WIP LCD patches are available here:
<tokyovigilante> nice, thanks! getting the panel working with u-boot for good splash screen support definitely on my list.
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
<tokyovigilante> looks great at first glance, will plug in my panel's timing/regs and give it a roll
<Jookia> tokyovigilante: you will probably need to adapt
<Jookia> this supports the D1 and H6, but not H616
<Jookia> it shouldn't be too hard
<tokyovigilante> great, should be able to based on the Linux drivers
<Jookia> yeah
<Jookia> if you want to merge patchsets or something that could be cool :)
<Jookia> the biggest criticism of it is that it needs to do clocking better
<Jookia> but if you have changes to make it work on H616 i am happy to carry them in my patchset
<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
<Jookia> yeah
<Jookia> i am tracking down an issue with my LCD patches- the LCD has a brighter black in linux
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has quit []
bauen1 has joined #linux-sunxi
<tokyovigilante> apritzel: just noticed something interesting regarding the cpufreq driver on the H700, seeing this in the log with a 6.10rc2 build -
<tokyovigilante> [ 1.193545] sun50i_cpufreq_nvmem: sun50i-cpufreq-nvmem: unknown speed bin 0x6c00, using default bin 0
<tokyovigilante> I see this speedbin didn't make it into the final driver, is it worth putting it back in?
<tokyovigilante> oh sorry you did mention that during the test series, but it does seem to not then run up to 1.4GHz.
<tokyovigilante> I might add it back and do some debugging
<apritzel> tokyovigilante: yes, originally I had the 0x6c00 bin in, with the values you reported, including the 1.5 GHz
<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
<apritzel> which should give you up to 1.4 GHz
<tokyovigilante> ok, I'm only getting up to 900mhz, but I seem to have kept an old opp table around, will do some experimenting
<tokyovigilante> I may also be doing something silly as I don't have proper cpufreq nodes under /sys.
<tokyovigilante> Should I have any particular governor selected?
<tokyovigilante> sorted, needed the basic cpufreq support configured in kernel as well
<tokyovigilante> looks good, thanks
<tokyovigilante> 1416000
<tokyovigilante> localhost:/sys/devices/system/cpu/cpufreq/policy0$ cat scaling_max_freq
<tokyovigilante> in fact looks great
<tokyovigilante> 1512000
<tokyovigilante> localhost:~$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
<tokyovigilante> localhost:~$ ./mhz
<tokyovigilante> 1511 MHz, 0.6618 nanosec clock
Schimsalabim has quit [Read error: No route to host]
Schimsalabim has joined #linux-sunxi
dsimic is now known as Guest8579
dsimic has joined #linux-sunxi
Guest8579 has quit [Ping timeout: 480 seconds]
<apritzel> tokyovigilante: you should really rebase your branch on top of v6.10-rc2 now
<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.
<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.
loki666 has quit [Quit: The Lounge -]
loki666 has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar]
warpme has joined #linux-sunxi
<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
JohnDoe_71Rus has joined #linux-sunxi
warpme has quit []
<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.
<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.
<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.
<apritzel> sounds ok to me. Do you really need MMC1? I guess that's the second SD card, right?
<macromorgan> MMC1 is the WiFi
<macromorgan> MMC0 is the first SD and mmc2 is the second SD
<apritzel> it's a bit tricky to access more than one MMC device from the SPL, I think
<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
<apritzel> U-Boot doesn't support WiFi anyway ;-)
<macromorgan> right, there's that too
<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
<macromorgan> or whatever the variable is called
<apritzel> I understand and support that plan, but not like this
<macromorgan> then boot.scr or extlinux.conf or whatever can just use that variable
<macromorgan> okay, what would you rather do?
<apritzel> put all DTs into the FIT image, and select the right one in the SPL
<apritzel> as we do for the Pine64 and Pine64+
<macromorgan> okay
<apritzel> we might want to think about patching the DTs instead, since five DTBs blow up the image considerably
<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
<macromorgan> for me I don't care which of the 5 devicetrees U-Boot uses though... as long as Linux gets the right one
<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
<apritzel> (having five DTBs in one image and select one of them is fine)
<macromorgan> if it's compressed it shouldn't matter too much though right? Since all 5 trees are 90%+ identical?
halal-beef_ has joined #linux-sunxi
halal-beef_ has quit []
halal-beef_ has joined #linux-sunxi
<macromorgan> I'll start an upstream for the 35XX+ device, then work on the code to add the other 4 devices to it
<apritzel> not sure what it would take to include decompression support in the SPL
halal-beef_ has quit []
<macromorgan> alternatively we could runtime patch the name only, assuming Linux will still load its own tree
cyrevolt has joined #linux-sunxi
AntoniAloyTorrens[m]1 has joined #linux-sunxi
aedancullen has joined #linux-sunxi
<apritzel> Linux will not load anything
aerospace[m] has joined #linux-sunxi
chuang[m] has joined #linux-sunxi
cmeerw[m] has joined #linux-sunxi
cperon has joined #linux-sunxi
<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
dickenhobelix[m] has joined #linux-sunxi
<macromorgan> fair enough
dittid[m] has joined #linux-sunxi
error2[m] has joined #linux-sunxi
<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
KNULLNoNeAll[m] has joined #linux-sunxi
exkc has joined #linux-sunxi
<apritzel> TF-A for instance changes the DT, to add its loads address to the protected memory section
GrantM11235[m] has joined #linux-sunxi
JosephWatson[m] has joined #linux-sunxi
JuniorJPDJ has joined #linux-sunxi
mripard1 has joined #linux-sunxi
triskit|away has joined #linux-sunxi
Newbyte has joined #linux-sunxi
obbardc has joined #linux-sunxi
oliv3r[m] has joined #linux-sunxi
pgwipeout[m] has joined #linux-sunxi
psydroid[m] has joined #linux-sunxi
exkcmoeadmin[m] has joined #linux-sunxi
rsglobal[m] has joined #linux-sunxi
sajattack[m] has joined #linux-sunxi
t4h4[m] has joined #linux-sunxi
Tooniis[m] has joined #linux-sunxi
MatrixTravelerbot[m] has joined #linux-sunxi
vulpes2[m] has joined #linux-sunxi
movedon5b2z4xywybidzannet[m] has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
vagrantc has joined #linux-sunxi
halal-beef has quit [Quit: Page closed]
electricworry has joined #linux-sunxi
electricworry_ has joined #linux-sunxi
electricworry has quit [Ping timeout: 480 seconds]
electricworry_ has quit [Read error: Connection reset by peer]
<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
electricworry has joined #linux-sunxi
electricworry_ has joined #linux-sunxi
electricworry has quit [Ping timeout: 480 seconds]
electricworry__ has joined #linux-sunxi
electricworry_ has quit [Ping timeout: 480 seconds]
electricworry__ has quit [Read error: Connection reset by peer]
<Jookia> the docs seem to heavily imply shipping a dt with the kernel image is the correct thing to do
<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
<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?
<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?
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<Jookia> u-boot passes a dtb to the kernel
<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
ftg has joined #linux-sunxi
electricworry has joined #linux-sunxi
<loki666> ok thanks for the clarifications
<loki666> tokyovigilante: could you push your rebased lcd branch? I'd like to give it a try
mripard has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.2 Quasar]
apritzel_ has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
apritzel_ has left #linux-sunxi [Leaving]
apritzel_ has joined #linux-sunxi
<apritzel_> gnarface: we regularly sync the kernel DT files into U-Boot, so they are basically identical
<apritzel_> now a U-Boot build is by design device specific, so already contains the devicetree for that device
<apritzel_> so it sounds a bit odd to load a device specific file again, if we already have that available
<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
<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
<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
<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
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel_> but those days are fortunately gone, so we should catch up and stop shipping and loading DTB with the kernel
<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
<apritzel_> loki666: ^^^
<apritzel_> Jookia: do you mean a kernel packed and signed in a FIT image?
<gnarface> apritzel_: thanks for the explanation
electricworry has quit [Ping timeout: 480 seconds]
AntoniAloyTorrens[m]1 has quit []
MatrixTravelerbot[m] has quit []
<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
psydroid[m] has quit []
hentai has joined #linux-sunxi
aedancullen has quit []
hentai has quit [Quit: SIGTERM]
vagrantc has quit [Quit: leaving]
<Jookia> apritzel_: yes
<apritzel_> Jookia: how do you create the signed image? Through some Yocto or OpenEmbedded scripts? Or do you use mkimage directly?
<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
<apritzel_> I see, so does bootm complain atm if there is not .dtb in there?
<apritzel_> and do you put an initramfs in there as well, or do you just use the FIT for having a signature?
<Jookia> no, it just loads and crashes i think
<Jookia> no initrd yet
ftg has quit [Read error: Connection reset by peer]