qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
aw-cloud has quit [Ping timeout: 252 seconds]
tgamblin_ is now known as tgamblin
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
frgo has joined #yocto
frgo has quit [Ping timeout: 272 seconds]
frgo has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
frgo has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
frgo has joined #yocto
frgo has quit [Ping timeout: 265 seconds]
tlwoerner_ has quit [Quit: Leaving]
tlwoerner has joined #yocto
<tlwoerner>
qschulz: i can build mesa successfully for all rockchip MACHINEs if, on top of your patch i also have:
<tlwoerner>
PACKAGECONFIG:append = " libclc"
<tlwoerner>
i don't know if that's something that should be in mesa.inc
frgo has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
frgo has joined #yocto
frgo has quit [Ping timeout: 260 seconds]
rfuentess has joined #yocto
rob_w has joined #yocto
frgo has joined #yocto
jmd has joined #yocto
goliath has joined #yocto
Kubu_work has joined #yocto
<RP>
khem: do_testimage[number_threads] = "X" would work
Kubu_work has quit [Ping timeout: 265 seconds]
zeemate has joined #yocto
sakman has quit [Ping timeout: 252 seconds]
sakman has joined #yocto
ptsneves has joined #yocto
leon-anavi has joined #yocto
florian_kc has joined #yocto
berton has joined #yocto
<qschulz>
tlwoerner: do the other machines build WITHOUT libclc in the PACKAGECONFIG or is that specific to panthor (rk3588)?
florian_kc is now known as florian
florian_kc has joined #yocto
mbulut has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
LainIwakura has joined #yocto
ablu has quit [Ping timeout: 276 seconds]
ablu has joined #yocto
ederibaucourt has quit [Ping timeout: 260 seconds]
usvi has quit [Remote host closed the connection]
usvi has joined #yocto
ederibaucourt has joined #yocto
usvi has quit [Ping timeout: 244 seconds]
usvi has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<rburton>
in case anyone saw it, there's a new automake 1.18 upgrade. the pre-releases had subtle "issues" so don't just blindly update and post, I've a branch in testing now.
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
frieder has joined #yocto
Kubu_work has joined #yocto
LainIwakura has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
BCMM has joined #yocto
<tlwoerner>
qschulz: with the libclc PACKAGECONFIG they all build successfully
<tlwoerner>
without it only the following build mesa successfully: marsboard-rk3066, radxarock, nanopi-r2s, roc-rk3308-cc roc-rk3328-cc, rock-pi-e, rock-pi-s, and rock64
<tlwoerner>
but looking at that list, my guess is they're probably succeeding for other reasons
<tlwoerner>
iow: rk3308 and rk3328 don't need it (and some 32-bit boards that don't even build images)
<qschulz>
tlwoerner: now I'm really puzzled
<qschulz>
because we configure mesa the exact same way for all of them (well, the ones we support in our mesa_%.bbappend)
<qschulz>
tlwoerner: ah wait, we don't actually build panfrost for the boards you listed I assume?
<qschulz>
tlwoerner: only rk3288, rk3328, rk3399, rk356x, rk3588 and px30 should matter
<qschulz>
as those are the only ones we configure mesa for
<qschulz>
sorry, omit rk3328 as that is using lima and not panfrost
<qschulz>
tlwoerner: ok, so all the machiens you mentioned are NOT using panfrost at all
<qschulz>
so I'm tempted to say we should always have libclc when building panfrost
<qschulz>
in mesa
<qschulz>
the question is which of the drivers actually require libclc in mesa?
<qschulz>
because we have vulkan and gallium drivers
<qschulz>
and also this TOOLS thingy
<qschulz>
ok, so if I'm reading the mesa recipe appropriately
<qschulz>
I think we probably want to add libclc to the PACKAGECONFIG check for panfrost, similarly to asahi/intel (see VULKAN_DRIVERS_ASAHI/VULKAN_DRIVERS_INTEL)
<qschulz>
and then our bbappend needs both panfrost and libclc to work
<qschulz>
maybe we need opencl (rusticl) too, c.f. 2d251863fc069c36d07ef00119e0c38e216640a0 in poky
* qschulz
shrugs
<qschulz>
but let's start with libclc :)
zkrx has quit [Killed (NickServ (GHOST command used by zkrx_))]
<tlwoerner>
qschulz: sounds good. are you going to send a v3 (not that v2 was wrong when you sent it)?
<tlwoerner>
my *guess* is that anyone building panfrost will need this, so it *probably* should go in oe-core (?)
<qschulz>
I can look into it :)
<qschulz>
long weekend here starting tonight so not soon :)
<tlwoerner>
nice! no worries, like i said i'm not using graphics so it doesn't affect me
<qschulz>
and I'm not (unfortunately) using master, "stuck" on scarthgap
<qschulz>
there's only so much I can do, and maintaining more than one branch when I don't have automated testing is not reasonable :/
<qschulz>
(because I'm not on master, it'll take me some time to adapt my BSP and build not from cache, that's all I'm "complaining" about to be clear :) )
<tlwoerner>
qschulz: yep, understood
<tlwoerner>
i could take a stab at it too, what do you think if i created a panfrost machine override and then appended the packageconfig to the override?
<tlwoerner>
or is that overkill?
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
tgamblin has quit [Ping timeout: 252 seconds]
tgamblin has joined #yocto
zkrx has joined #yocto
frgo has quit [Remote host closed the connection]
frgo has joined #yocto
tgamblin_ has joined #yocto
tgamblin_ has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 252 seconds]
tgamblin_ has joined #yocto
Vonter has joined #yocto
tgamblin has quit [Ping timeout: 245 seconds]
tgamblin_ is now known as tgamblin
<qschulz>
tlwoerner: what would be the benefit?
frgo has quit [Ping timeout: 272 seconds]
<qschulz>
i'm not sure to follow what you want to do :)
<qschulz>
avoid having to update the mesa.bbappend every time we add support for a new SoC and just have to set PANFROST=1 in the SoC conf file?
wooosaiiii has quit [Remote host closed the connection]
<tlwoerner>
and that looks kinda ugly to me. over time more and more machines/socs get added and as we add a new soc we simply set the GPU type in its rkXXXX.inc file and be done
tgamblin has joined #yocto
<qschulz>
you don't need an override for that, you could simply have a variable in your machine conf for example
<thomas_34>
Hi, a short question: I have a recipe (r1) with an custom do_compile()-task, which produces ${S}/out/artefact1 and ${S}/out/artefact2 in one go. I would like to control via OVERRIDES which of these (either artefact1 or artefact2) should be installed to the image on the SAME path ${D}/path.
<thomas_34>
I got it working by using a variable with override in do_install() task, but I fail when referring that recipe r1 as rdependency.
<thomas_34>
What is the proper way to do this in yocto?
<tlwoerner>
qschulz: seeing how the GPU is an immutable component of a device's silicon, a MACHINEOVERRIDE feels like the right place for this. are there deeper differences between an override and a variable that you're thinking about?
rfuentess has quit [Remote host closed the connection]
dgriego has quit [Ping timeout: 248 seconds]
Tyaku has joined #yocto
<tlwoerner>
hmm... i think i see your point. in theory someone might want to use a different driver. with a variable the user can choose
<tlwoerner>
(and i should stop calling panfrost a gpu :-) )
dgriego has joined #yocto
<rburton>
thomas_34: one recipe, two packages
<rburton>
thomas_34: then overrides to pick what package to install
<Tyaku>
Hello, There is something strange about FIT / Yocto configuration that I would like to understand: 'The address where the kernel image is to be loaded by U-Boot is specified by UBOOT_LOADADDRESS and the entrypoint by UBOOT_ENTRYPOINT'. Why is there two variables ? In which case the two addresses are different ?
<Tyaku>
My understanding is that these variables are set in ITB file, and finally fitImage, When Uboot calls "bootm", it parse the fitimage, extract these information and extract the kernel at correct place (because gziped), then it 'jump' to the entry address to boot.
<Tyaku>
But why LOADADDRESS != ENTRYPOINT, and how to know where entrypoint is ?
<tgamblin>
Has anyone encountered problems building scarthgap on Fedora 42?
SandeepRaju has joined #yocto
<SandeepRaju>
Hi All, Does anyone know if we have any channel to post questions related to meta-zephyr?
cyxae has joined #yocto
zkrx has quit [Ping timeout: 268 seconds]
<Crofton>
tgamblin: are you suggesting I shouldn't update yet
<thomas_34>
rburton thank you, that was my plan. I just don't get my head around how to do that: This was my approach: https://pastebin.com/m0qTwvuj
<thomas_34>
How do I achieve, that I define two packages, which install different files into the same target directory?
<tgamblin>
Crofton: maybe not - my Fedora install is fresh and I'm running into issues compiling unzip, possibly other stuff (network issues so I can't check right now)
zkrx has joined #yocto
cyxae has quit [Remote host closed the connection]
Kubu_work has quit [Quit: Leaving.]
cyxae has joined #yocto
cyxae has quit [Remote host closed the connection]
cyxae has joined #yocto
cyxae has left #yocto [#yocto]
cyxae has joined #yocto
cyxae has quit [Remote host closed the connection]
cyxae has joined #yocto
cyxae has quit [Client Quit]
cyxae has joined #yocto
<qschulz>
tlwoerner: not directly PACKAGECONFIG:append, but PACKAGECONFIG:append:rockchip even though it's unlikely a non-rockchip machine would have RK_MESA_DRIVER set :)
<qschulz>
tlwoerner: my gut is telling me the more OVERRIDES you have, the longer parsing will take
cyxae has quit [Remote host closed the connection]
cyxae has joined #yocto
cyxae has quit [Client Quit]
cyxae has joined #yocto
<tlwoerner>
qschulz: ok, thanks i'll send a patch sometime (no rush)
<qschulz>
tlwoerner: yeah I think we anyway need an update with libclc ion the PACKAGECONFIG in meta-rockchip
<qschulz>
but we should patch mesa as well
<qschulz>
Panfrost/panthor is not Rockchip specific after all, it's the open source driver for some Arm Mali GPU you can find in other SoCs as well I assume
florian has quit [Quit: Ex-Chat]
josuedhg has joined #yocto
mkazantsev has joined #yocto
thomas_34 has quit [Ping timeout: 240 seconds]
tgamblin_ has joined #yocto
tgamblin has quit [Ping timeout: 248 seconds]
tgamblin_ is now known as tgamblin
npcomp has quit [Ping timeout: 244 seconds]
dgriego has quit [Read error: Connection reset by peer]
dgriego_ has joined #yocto
dgriego_ is now known as dgriego
florian_kc has joined #yocto
florian_kc is now known as florian
Kubu_work has joined #yocto
mbulut has quit [Ping timeout: 265 seconds]
npcomp has joined #yocto
frieder has quit [Remote host closed the connection]
josuedhg has quit [Ping timeout: 240 seconds]
leon-anavi has quit [Quit: Leaving]
druppy has joined #yocto
pilonsi has quit [Ping timeout: 248 seconds]
mkazantsev has quit [Remote host closed the connection]