bielpa_ has quit [Remote host closed the connection]
bielpa_ has joined #yocto
pbiel has quit [Ping timeout: 272 seconds]
bielpa__ has joined #yocto
enok71 has joined #yocto
<RP>
yocton: 47 -> 37 is a decent drop!
<JaMa>
I wish my age would do that :)
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
<simonew>
yocton: This makes me look forward to tmrw CVE reports :D
<yocton>
simonew: Sorry for the false joy but this work only align https://autobuilder.yocto.io/pub/non-release/patchmetrics/ to what we get in the weekly report. The weekly report should not be impacted. But now, you can have accurate daily preview :D
simonew has quit [Remote host closed the connection]
simonew has joined #yocto
florian_kc has joined #yocto
enok71 has quit [Ping timeout: 260 seconds]
florian_kc has quit [Ping timeout: 260 seconds]
jmiehe has quit [Quit: jmiehe]
jpuhlman- has quit [Read error: Connection reset by peer]
jpuhlman has joined #yocto
mulk has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
mulk has joined #yocto
Kubu_work has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
enok71 has joined #yocto
florian_kc has joined #yocto
enok71 has quit [Ping timeout: 256 seconds]
<simonew>
yocton: Well then let's wait and see :) Maybe some can be fixed
Kubu_work has quit [Ping timeout: 268 seconds]
florian_kc has quit [Ping timeout: 260 seconds]
Kubu_work has joined #yocto
lexano has joined #yocto
florian_kc has joined #yocto
enok71 has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
ptsneves has joined #yocto
bielpa__ has quit [Remote host closed the connection]
bielpa_ has quit [Remote host closed the connection]
sakman has joined #yocto
amitk_ has joined #yocto
enok71 has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
leon-anavi has joined #yocto
<RP>
khem: any chance you can add scarthgap to the layer.conf for meta-oe please?
<khem>
I have staged one in master-next
<RP>
khem: I'd merge the one to master but it breaks things on the AB. I guess if I merge, you can merge? :)
simonew has quit [Read error: Connection reset by peer]
florian_kc has quit [Ping timeout: 272 seconds]
ptsneves has quit [Ping timeout: 255 seconds]
enok71 has joined #yocto
leon-anavi has quit [Quit: Leaving]
zenstoic has joined #yocto
<khem>
yes we can merge in tandem
amitk_ has quit [Ping timeout: 272 seconds]
<khem>
I have merged one which supports both nanbield and scarthgap
<khem>
so you can merge now and then I will remove the crutch
<khem>
above patch maybe fine, since we do not have data, how it impacts performance of tools which will demand pthreads unconditionally, it impacts distros with older glibc ( before pthread and libc merge )
<khem>
uninative it becoming like a poor man's container
ptsneves has joined #yocto
ptsneves has quit [Ping timeout: 272 seconds]
florian_kc has joined #yocto
berton has quit [Quit: Connection closed for inactivity]
jmd has quit [Remote host closed the connection]
<mischief>
something pulled in -dev packages to my image and i don't know what it is. is there an easy way to find out?
florian_kc has quit [Ping timeout: 260 seconds]
<RP>
khem: done
Vonter has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
jmd has joined #yocto
simone has joined #yocto
<JaMa>
armpit: can you please update meta-security layer.conf as well or do you want me to send patch for it?
amitk_ has joined #yocto
amitk has quit [Read error: Connection reset by peer]
vladest has quit [Remote host closed the connection]
<enok71>
Can anyone please help me understand what exactly what u-boot does with a FIT image when using "standard boot"? I understand it attempts to use a default "configuration" section which refers to a kernel image and a dtb image both contained in the FIT image. But are there any more options? Can there be a bootscript in a fitimage that gets executed? I succeeded making yocto add a uEnv.txt u-boot environment file to the FIT, but
<rbox>
i used to put fpga images in my fits
vladest has joined #yocto
<enok71>
@rbox and what happened? Did you find any way to add any u-boot commands that gets executed at any point?
<rbox>
it would lod it
<rbox>
never t ired
<rbox>
yo ucould read the esource to see what type of things i can parse out of it
<rbox>
i would load my fit and then run a custom command i added to uboot
<rbox>
to do my magic
<enok71>
Ugh. Yes I will have to read sourcecode. Cause I already read through the latest documentation, and it's stil very unclear how this works or how to do basic stuff.
<enok71>
When you say "load my fit", do you mean having a bootscript running e.g. bootm?
<rbox>
my bootcommand was actually 'myspecialcommand && bootm'
<rbox>
myspecialcommand would load the fit into memory, and then bootm would boot it
<enok71>
cause the preferred way nowadays seems to be without bootscripts, just "bootflow scan" which performs everything.
<rbox>
and do abunch of other special stuff
<rbox>
the loading from memory and special stuff was the tricky part, because i was doing funky stuff with placing my kernel iamge in relation to my system partition
<enok71>
And where did you define 'myspecialcommand'? uboot environment variable? or sourcecodepatch?
florian_kc has joined #yocto
<rbox>
source code
<rbox>
i can't imagine doing that in uboot script
<enok71>
Ok. I used to feel I was able to do anything in a uboot script, but with this "bootflow scan" and "extlinux.conf" there is suddenly no way of doing anything except going back to modifying u-boot sourcecode. Seems like a step backwards.
simone has quit [Remote host closed the connection]
<enok71>
Unless I'm missing something.
<enok71>
Perhaps some way in extlinux.conf to refer to a bootscript or some u-boot commands that I missed. Or something.
jmd has quit [Remote host closed the connection]
simone has joined #yocto
<rbox>
well you could read the extlinux parser
<rbox>
or just not use bootflow
<rbox>
lol
<rbox>
i lost track of how many years they'v ebeen saying 'sf' is deprecated
<rbox>
but it still works
<enok71>
There seems to be no way of adding dtbo overlays anymore, with "standard boot" (bootflow), it's just missing functionality. At least that's stated in the u-boot documentation: "todo: overlays".
<enok71>
Yes good point.
<rbox>
to be honest, i really hate how uboot works with their environment nonsnese
<rbox>
i dont want to save logic to my env block
<rbox>
i want to save v ariables there
<enok71>
True.
<rbox>
i would even patch the code to remove useless crap that was ending up there by default
<enok71>
Ok will try to disregard the "deprecated" text and select bootscript in the u-boot config, ditching bootflow and "standard boot". And be less afraid of modifying the sourcecode.
<rbox>
oh, patching uboot sucks
<enok71>
The way to go apparently.
<enok71>
But patching uboot was what you did to implement "myspecialcommand" right?
<rbox>
i think you can put binary blobs in a fit
<rbox>
can't you run a script from a location in memroy?
<rbox>
well yeha, but it still sucks to patch uboot
<rbox>
lol
<rbox>
especially when it comes to updating
<enok71>
If I interrupt the boot and get a uboot prompt I can do anything. But I find no way to do anything automatically without bootscript.
<rbox>
well you cuold make your bootcommand a mile long
<enok71>
True. That's one way.
<rbox>
i had a complciated one... it would check if netboot varialbe was set, if it did, it would dhcp && bootm otherwise it would myspecialload && bootm
<enok71>
Nice.
<rbox>
i also patched the code that would modify the fdt beforing handing it off to the os
<enok71>
I would like to add overlays in the fitimage to the dtb, and then boot with bootm. Could perhaps be done with a looong bootcommand line.
<rbox>
i only got a little into overlays, but i handled that in a systemd service on boot
<rbox>
it would figure out which fpga id it was running on and load the correct overlay for that, then figure out the hardware version, and load the correct overlay for that
<enok71>
Then you had your kernel patched and configured to be able to modify the devicetree at runtime?
<rbox>
the kernel supports overlays?
<rbox>
nothign to patch
<rbox>
actually, maybe i read once it was a vendor patch
<rbox>
i dont know how that worked
<rbox>
i thought it was a base feature
<enok71>
If you have "CONFIG_OF_CONFIGFS=y" in /proc/config.gz then you have a patched kernel adding this feature.
<rbox>
overlay stuff was in my xilinx kernel ,adn it looks liek its in my rpi kernel
<rbox>
but i'll be damned, its not in mainline
<enok71>
Maybe I'm wrong, maybe it's in mainline kernel nowadays.