mmind00 changed the topic of #linux-rockchip to: Rockchip development discussion | public log at https://libera.irclog.whitequark.org/linux-rockchip
Daanct12 has joined #linux-rockchip
Daanct12 has quit [Ping timeout: 264 seconds]
Daanct12 has joined #linux-rockchip
Daanct12 has quit [Quit: WeeChat 4.2.1]
Daanct12 has joined #linux-rockchip
Daanct12 has quit [Ping timeout: 268 seconds]
Daanct12 has joined #linux-rockchip
urja has quit [Read error: Connection reset by peer]
dlg has quit [Ping timeout: 255 seconds]
urja has joined #linux-rockchip
dlg has joined #linux-rockchip
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-rockchip
warpme has joined #linux-rockchip
raster has joined #linux-rockchip
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
crabbedhaloablut has quit []
ungeskriptet has joined #linux-rockchip
crabbedhaloablut has joined #linux-rockchip
ungeskriptet3 has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 268 seconds]
ungeskriptet3 is now known as ungeskriptet
crossdev has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
crabbedhaloablut has quit []
crabbedhaloablut has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 240 seconds]
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #linux-rockchip
warpme has joined #linux-rockchip
dsimic has quit [Ping timeout: 268 seconds]
dsimic has joined #linux-rockchip
Danct12 has quit [Quit: ZNC 1.9.0 - https://znc.in]
Danct12 has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Client Quit]
stikonas has joined #linux-rockchip
stikonas has quit [Client Quit]
stikonas has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
naoki has quit [Quit: naoki]
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #linux-rockchip
warpme has joined #linux-rockchip
Daanct12 has quit [Quit: WeeChat 4.2.1]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
<macromorgan> mmind00: I noticed that there aren't any boards with overlay support enabled. Is that on purpose/desired? Otherwise there's at least a few boards I'd like to enable it for in mainline... ones with GPIO headers.
<qschulz> diederik: I would assume that this patch is working? So while there aren't DTC_FLAGS in rockchip's DT makefile, I assume we get it from somewhere else?
<diederik> I can't (quickly) find a related discussion where setting that globally was still not recommended/done, but enabling it on directory (rockchip) or board level was no longer frowned upon
<diederik> It was related to a reorganisation of the arm (not arm64) dts files
<qschulz> but the Makefile syntax hurts my brain
<diederik> qschulz: I haven't tried it myself, but I assume that patch is working
<diederik> (the revival of it in 2023)
<qschulz> macromorgan: we've talked with mmind00 to add support for DTBO mainline for our boards, so DTBO support is very much welcome upstream... Just that the DTBO we want to upstream require a few more fixes (and also because we need to change our documentation/processes/workflows internally to use DTBOs :) )
<qschulz> diederik: the "issue" is that the DTSO patch I sent is for a rockchip board, and I don't see a DTC_FLAGS in rockchip's Makefile for it to work, so it must work, but through a different mechanism :)
<diederik> qschulz: I'm completely *un*familiar with the last patch you linked
<qschulz> diederik: ahah! I think I got it
<qschulz> +# Base DTB that overlay is applied onto (each first word of $(*-dtbs) expansion)
<qschulz> +base-dtb-y := $(foreach m, $(multi-dtb-y), $(firstword $(call suffix-search, $m, .dtb, -dtbs)))
<diederik> ah, ok.
<qschulz> +# Set -@ if the target is a base DTB that overlay is applied onto
<qschulz> +DTC_FLAGS += $(if $(filter $(patsubst $(obj)/%,%,$@), $(base-dtb-y)), -@)
<qschulz> so provided your dtso has a filename that starts the same as a a dtb would have -@ flag?
<diederik> TBF: I don't really/fully understand this material, I just remembered the discussion
System_Error has quit [Remote host closed the connection]
<qschulz> so I guess a common "root" in the filename would make any dtb with that common root string (but maybe longer) compile with -@?
System_Error has joined #linux-rockchip
<diederik> Or the alternative, like it's done in Aurelien's patch is to add the `DTC_FLAGS := -@` in an appropriate place in the Makefile.
<diederik> Doing it for all rockchip devices may not be the best, but you could also specify it on specified boards. At least that's how I understood it
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<diederik> qschulz: I think you're correct. If there's a .dtso file then the DTC_FLAGS get set on similarly named .dts file
<diederik> But this would only work on overlays which are part of the kernel, not external ones
<qschulz> diederik: absolutely
stikonas has quit [Quit: Konversation terminated!]
stikonas has joined #linux-rockchip
<macromorgan> yes, I mean like that broadcom commit
<macromorgan> maybe we simply have something in the top of the Makefile for rockchip's SoCs that enable overlays for certain boards if CONFIG_OF_OVERLAY is also defined?
<macromorgan> to me the demarcation would be whether or not there are exposed GPIO pins, but that's obviously up to the maintainers
<macromorgan> for example I'd enable overlays for things like the Odroid Go Advance/Advance BE (which both have exposed pins) as well as some dev boards I'm messing with; but things like the Anbernic devices would not be added to the overlay list since no exposed pins
<macromorgan> hmm, but then we'd have to completely segregate it within the Makefile
<macromorgan> note that when tested for the Indiedroid Nova and Rock 5B the DTB files were twice as large
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<qschulz> I tried to check if this DTC_FLAGS autorequirement based on filename works by decompiling the dtb and dtbo but I clearly don't understand how this works
<qschulz> macromorgan: I assume the point is to allow out-of-tree DTBOs?
<macromorgan> yes, correct
<macromorgan> it only makes sense for "tinker" boards though. Otherwise we're doubling filesizes for no reason.
<macromorgan> ohh, duh... it can be done for individual boards by doing the following: `DTC_FLAGS_rk3588s-indiedroid-nova := -@`
<qschulz> macromorgan: not really no, for example, our devkit has a custom connector which accepts whatever you develop for it, we already support two adapters for PX30 Ringneck for example
<qschulz> we also have an adapter board we connect to the GPIO headers for end of production line testing
<qschulz> all those could (should) be overlays
<macromorgan> I guess then what I'm asking is "would it be acceptable to add stuff like `DTC_FLAGS_rk3588s-indiedroid-nova := -@` to the Makefile, or should I do it differently?"
<qschulz> while it's a devkit and I could agree this is a "tinker" board, we also have an SBC with a proprietary connector with multiple adapter boards today for example
<macromorgan> that's fine... I guess I'm really saying its up to the board maintainer to enable it. Some devices it makes no sense but other devices that have external connectors it does.
<qschulz> macromorgan: it's a trivial patch to send, so I'd recommend to send it and see what Heiko thinks of it whenever he has time :)
<macromorgan> yep, think that's what I'll do. I'll enable it for boards that I own and where it makes sense (so none of those handheld gaming devices excluding the Odroid ones with the external connector).
<macromorgan> worst they can do is say no :-)
<qschulz> absolutely :)
vagrantc has joined #linux-rockchip
<macromorgan> for now I'll just enable it for Rock 5B and Indiedroid Nova. I'll let other board maintainers do as they see fit.
<macromorgan> filesize for the DTB went from 68k to 134k with overlays enabled
<qschulz> macromorgan: can you do a diff on the output of dtc -I dtb -O dts rock5b.dtb ?
<qschulz> that should tell you what actually increase the size
<qschulz> if I'm not mistaken, what could be increasing the size could be that we have too many labels?
<macromorgan> the increase is phandle references which are not present in the non-overlay version, a boatload of unused pincfgs (this is the main driver of size growth), and a symbols list
<macromorgan> given the size growth I'd be loathe to enable it for all rk3588 and rk3588s boards like I was planning on (all but the nanopi r6s which curiously enough is the only rk3588 based board without external expansion connectors)
<macromorgan> so I'll just push it upstream for the two I can test... the Indiedroid and the Rock 5B
<qschulz> yeah, so we would likely have this big size increase for all rockchip boards, regardless of the SoC
<qschulz> since rockchip-pinconf.dtsi is SoC-agnostic
<macromorgan> I'm okay with that, 60kb isn't much of a concern to me, but I have no idea if someone's bootloader config only has a set amount of memory set aside for the dtb
<macromorgan> so I'll just do these two for now
<qschulz> macromorgan: the "issue" is that there are some people who are trying to use the same dtb binary for U-Boot and the kernel, so that may become an issue :)
<qschulz> in any case, start with your two boards and we'll tackle that whenever we need to :)
<macromorgan> well that's the other reason why I'm only doing it for these two boards. Rock 5B is already supported in mainline U-Boot and I'm trying my best to figure out the bloblist stuff so I can get the Indiedroid there as well. As long as we don't do something silly and allow overlay support in U-Boot SPL pre relocation we'd probably be okay.
vagrantc has quit [Ping timeout: 256 seconds]
vagrantc has joined #linux-rockchip
CounterPillow has quit [Quit: Bye.]
CounterPillow has joined #linux-rockchip
psydroid has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
vagrantc has joined #linux-rockchip
Livio has joined #linux-rockchip
werdahias has joined #linux-rockchip
werdahias has quit [Quit: werdahias]
werdahias has joined #linux-rockchip
werdahias has quit [Client Quit]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
<mmind00> macromorgan: "from 68k to 134k with overlays enabled" ... I guess with board measuring memory in the gigabytes that doesn't really matter that much ;-)
<macromorgan> the one wild card is how does the BSP U-Boot handle it, since if I recall correctly it's rigged somehow to use the kernel's DTB and we're now doubling it in size
<CounterPillow> there's an old rockchip ATF floating around where large DTBs (>64k) caused it to crash but they've since fixed that iirc
psydroid has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
Livio has quit [Ping timeout: 268 seconds]
Livio has joined #linux-rockchip
<vagrantc> 23
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
sL1pKn07 has quit [Ping timeout: 245 seconds]
System_Error has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
System_Error has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
Livio has quit [Ping timeout: 255 seconds]
sL1pKn07 has joined #linux-rockchip
stikonas has quit [Quit: Konversation terminated!]
naoki has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery