<iceaway>
Good morning! I am in the process of migrating from Sumo to Dunfell, and when I have generated the SDK using bitbake -c populate_sdk <image_name>, with the Dunfell version the generated SDK toolchain claims that my CPU does not have an FPU when triyng to compile with -mfloat-abi=hard. We use both 32-bit and 64-bit applications, and this is an issue with the 32-bit toolchain. I'm a bit puzzled where to even
<iceaway>
start looking.
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
bluelightning has quit [Ping timeout: 245 seconds]
Guest3644 has joined #yocto
<barath>
iceaway: I hope someone else can chime in and give you the shortcut solution, but I'd grep through poky (?) and check where the error message about not having an FPU is generated and then work backwards to figure out on what basis it decides that
<iceaway>
barath: The error message comes from g++, so not sure there is a way to backtrace the error message itself to the Yocto build. Feels more like the 32-bit version of the toolchain is not build with FPU support, but I'm guessing here.
<Guest3644>
Hi folks, Is there anyway to use an externally buiit toolchain in yocto except meta-sorcery one?
Schlumpf has joined #yocto
<barath>
Hm. Then it almost sounds like after the version bump the GCC behavior has changed and the flag mightve changed 🤔 but I can't pretend to have much experience with exactly that, unfortunately
kpo has quit [Read error: Connection reset by peer]
goliath has joined #yocto
kpo has joined #yocto
adrian_ has joined #yocto
rob_w has joined #yocto
fleg has joined #yocto
Guest3644 has quit [Quit: Client closed]
dtometzki has quit [*.net *.split]
otavio has quit [*.net *.split]
zeddii has quit [*.net *.split]
Bardon has quit [*.net *.split]
JaMa has quit [*.net *.split]
chrfle has quit [*.net *.split]
troth has quit [*.net *.split]
wooosaii has quit [*.net *.split]
nerdboy has quit [*.net *.split]
dlan has quit [*.net *.split]
marka has quit [*.net *.split]
warthog9 has quit [*.net *.split]
tangofoxtrot has quit [*.net *.split]
mcfrisk has quit [*.net *.split]
Schlumpf has quit [Quit: Client closed]
Schlumpf has joined #yocto
g0hl1n_ has quit [Remote host closed the connection]
frieder has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
Ad0 has joined #yocto
mcfrisk has joined #yocto
dtometzki has joined #yocto
Bardon has joined #yocto
otavio has joined #yocto
JaMa has joined #yocto
zeddii has joined #yocto
troth has joined #yocto
chrfle has joined #yocto
dlan has joined #yocto
nerdboy has joined #yocto
warthog9 has joined #yocto
marka has joined #yocto
tangofoxtrot has joined #yocto
jpnurmi has quit [Remote host closed the connection]
jpnurmi has joined #yocto
rfuentess has joined #yocto
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
manuel1985 has joined #yocto
zyga has joined #yocto
pgowda_ has joined #yocto
<JosefHolzmayrThe>
yo dudx
<mckoan>
hey JosefHolzmayrThe
zyga has quit [Remote host closed the connection]
zyga has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
xmn has joined #yocto
leon-anavi has joined #yocto
gsalazar has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
frieder has quit [Ping timeout: 265 seconds]
kanavin has quit [Remote host closed the connection]
florian has joined #yocto
kanavin has joined #yocto
frieder has joined #yocto
goliath has quit [Quit: SIGSEGV]
<coldspark29[m]>
Can anyone clarify a few things on Secure Boot for me? I am currently trying to sign images following this guide https://boundarydevices.com/high-assurance-boot-hab-i-mx8m-edition/. It works for U-Boot but not for the uImage of the kernel. I can successfully complete the described signing process, but the image is not accepted by U-Boot. One possible reason I see is that we are using a uImage instead of a zImage. On the internet you find a
<coldspark29[m]>
lot of misguiding information stating that zImages can't be booted by U-Boot, but then others say you can by adding CONFIG_CMD_BOOTZ=y to the kernel configuration. Does signing not work with uImages? A zImage can be anything from what I understand, some image or a compressed uImage with the gzip compression method. Is that correct? So do I only have to change the mkimage command to -C gzip to get a zImage?
<coldspark29[m]>
s/Can anyone clarify a few things on Secure Boot for me? I am currently trying to sign images following this guide https://boundarydevices.com/high-assurance-boot-hab-i-mx8m-edition/. It works for U-Boot but not for the uImage of the kernel. I can successfully complete the described signing process, but the image is not accepted by U-Boot. One possible reason I see is that we are using a uImage instead of a zImage. On the internet you find
<coldspark29[m]>
a lot of misguiding information stating that zImages can't be booted by U-Boot, but then others say you can by adding CONFIG_CMD_BOOTZ=y to the kernel configuration. Does signing not work with uImages? A zImage can be anything from what I understand, some image or a compressed uImage with the gzip compression method. Is that correct? So do I only have to change the mkimage command to -C gzip to get a zImage?/Can anyone clarify a few things
<coldspark29[m]>
on Secure Boot for me? I am currently trying to sign images following this guide https://boundarydevices.com/high-assurance-boot-hab-i-mx8m-edition/. It works for U-Boot but not for the uImage of the kernel. I can successfully complete the described signing process, but the image is not accepted by U-Boot. One possible reason I see is that we are using a uImage instead of a zImage. On the internet you find a lot of misguiding information
<coldspark29[m]>
stating that zImages can't be booted by U-Boot, but then others say you can by adding `CONFIG_CMD_BOOTZ=y` to the kernel configuration. Does signing not work with uImages? A zImage can be anything from what I understand, some image or a compressed uImage with the gzip compression method. Is that correct? So do I only have to change the `mkimage` command to `-C gzip` to get a zImage?/
<qschulz>
coldspark29[m]: aarch64 kernel images are named Image and they are booted with booti. You can also used fitimages which is VERY likely what you will want to do for secureboot, and fitimages are booted with bootm.
camus has quit [Ping timeout: 245 seconds]
camus has joined #yocto
<coldspark29[m]>
qschulz: Ah okay, currently we are booting with bootm. I am trying to convert the image to a zImage, but just adding gzip compression, which is probably not going to work. I am very new to the whole boot process in general. Been reading a lot last week.
<coldspark29[m]>
So I guess adding the compression and booting with bootz is not going to solve my problem. Another thing I was thinking is that signing a FIT image is not going to work with the above guide, because it already contains an IVT
<coldspark29[m]>
So I need to sign somewhere in the process I guess?
<coldspark29[m]>
* sign somewhere earlier in the
<qschulz>
coldspark29[m]: this guide is only for secureboot up until U-Boot
goliath has joined #yocto
<qschulz>
coldspark29[m]: you need another guide for secureboot in and after U-boot (i.e. kernel+dtb+rootfs)
<qschulz>
All I can say is that most likely nothing is specific to imx8m at that point
<coldspark29[m]>
This is the older version for the i.MX6
<qschulz>
it's not really technical but will give you an overview of which keys are doing what and stored where
<coldspark29[m]>
They use a zImage and we have a uImage
<qschulz>
yeah no, don't use this guide
<coldspark29[m]>
Ah I love Bootlin talks. They are usually really good
<qschulz>
just use U-Boot normal fitimages, put your Image in it, put your dtb, initramfs whatever
<coldspark29[m]>
They make the boot process seem fun ^^
<qschulz>
then let U-Boot check the signature and all
<coldspark29[m]>
What is wrong with the guide?
<qschulz>
they use a SoC specific mechanism while there is no need for it
<qschulz>
though it might predate the U-Boot implementation of secureboot with fitimage or use vendor BSP
<coldspark29[m]>
So you say verification should work out of the box?
<qschulz>
anyway, in the talk you'll see, you need two sets of keys, one whose hash are in the SoC and one public key in U-Boot dtb that is used to check the fitimage signature
<qschulz>
since you validated the U-Boot with the SoC, you know you can trust the public key in it and use that one for checking the fitimage which contains the kernel and other things
<coldspark29[m]>
Hmm well I will have a look at the video. Hopefully I'll be a bit smarter then
<qschulz>
coldspark29[m]: you might need a few kconfig options selected but yeah, bootm $addr_fit_img will do the check if correctly configured
zen_coder has joined #yocto
<RP>
kanavin: any idea why libnewt-python would be non-reproducible due to linking to libpthread in one case and not another? :/
<RP>
kanavin: the empty pthread in glibc 2.34 is probably partly at fault but I don't know why we'd see this now
<RP>
kanavin: ah, it is building on debian11. I bet this is host leakage :(
nucatus has quit []
adrian__ has joined #yocto
adrian_ has quit [Ping timeout: 260 seconds]
kpo has quit [Read error: Connection reset by peer]
kpo has joined #yocto
zyga has quit [Quit: Leaving]
florian_kc has joined #yocto
<manuel1985>
I have problems executing a self-written do_patch() function after a self-written do_fetch() function.
<manuel1985>
do_fetch() mkdirs the directory and git-clones the repo, but do_patch deletes the directory
gsalazar_ has joined #yocto
<manuel1985>
( Before you have an heart attack: I'm selfcoding do_fetch and do_patch solely for explanatory purposes. )
florian_kc has quit [Quit: Ex-Chat]
gsalazar has quit [Ping timeout: 252 seconds]
<kanavin>
RP: I guess this is now sorted?
<RP>
kanavin: I'm hoping so. I now found bootchart also fails reproduce but I think I can see why too. Why so many python failures all of a sudden :/
<kanavin>
some new python3 items made it to master
<RP>
kanavin: I think its python versions changing on the stream workers
<RP>
kanavin: the bootchart issue looks like all of a sudden some versions could find a host python_compile.py script
alicef_ is now known as alicef
jwillikers has joined #yocto
tnovotny has joined #yocto
xmn has quit [Ping timeout: 246 seconds]
<coldspark29[m]>
qschulz: So I think I got a good overview. We have successfully completed the signing of the Bootloader and my colleague told me to use the same set of keys to verify the kernel. What you are suggesting is to use another set of keys for the kernel. I don't really mind about the approach as long as it works. I guess your approach is the standard U-Boot way of verifying kernels?
<coldspark29[m]>
I realized that you are actually the guy having given that talk :)
<qschulz>
coldspark29[m]: you could reuse the "same" keys in that their content is the same but they'll be duplicated in U-Boot binary too
<qschulz>
coldspark29[m]: co-presenter with Mylène yes :)
<coldspark29[m]>
You are based in Tolouse right? I was actually there this summer for one day. Really beautiful city!
<qschulz>
coldspark29[m]: not working at Bootlin and not in Toulouse anymore :)
<qschulz>
but yes, I was there. Too warm for me :p
<coldspark29[m]>
My colleague says it is alright if I try your approach. Also interesting what you said about the dependency loop in in Yocto. This is for an Android image atm which usese dm-verity, but I will have to do the same thing later for Yocto. Did you write a detailed guide for this or can you recommend one?
<coldspark29[m]>
For working it is too warm maybe. I live in Germany and like the cold days for being productive at the computer. For leisure it is better when it is warm though. Tolouse reminded me of Barcelona a lot. which I also like
<qschulz>
coldspark29[m]: I didn't upstream the custom fitimage class, nor is it publicly available somewhere and I don't have access to the sources anymore. IIRC it was really not complicated, a really stripped down version of kernel-fitimage bbclass
<qschulz>
coldspark29[m]: otherwise Bartosz from Baylibre tried to upstream something to fix this a few months ago/last year
<coldspark29[m]>
Well I will try the approach for this Android image first. I hope your presentation will be sufficient to get this working. I am still missing a lot of parts to the puzzle, but it is really an interesting topic once you start to understand a few things.
<qschulz>
The only thing that was not tackled during this talk is if you want secureboot with RW rootfs, that we didn't investigate at all
<qschulz>
the rest, I don't think there's much more to it except some vendors oddities maybe
<qschulz>
but things might click a bit better while working on it (hopefully)
<coldspark29[m]>
Yeah we will ignore dm-verity for now. First things first: I need to sign and verify the image
<qschulz>
U-Boot has some docs too, don't hesitate to read those
<coldspark29[m]>
Yeah I should really do that
<qschulz>
the fitimage is signed with `mkimage` btw, that should help you look for the right guides/docs
<coldspark29[m]>
Yeah I got that part, but how to implement it into U-Boot?
<coldspark29[m]>
U-Boot has to know about the keys
<coldspark29[m]>
Guess I have to read about U-Boot now
<coldspark29[m]>
It's time
<qschulz>
it's a special device tree which points to the dev-key, then dtc will fetch the keys and include them in the dtb which is included in the U-Boot binary
<qschulz>
In recent U-Boot, a lot of ARM boards have now a dtb, so I don't know how and where it fits in the big picture, I didn't have any device tree for the aarch32 SoC back then
<coldspark29[m]>
Yeah I already found a few things. I just wonder, when I add the CONFIG_SECURE_BOOT flag in the kernel config atm, HAB seems to try to verify the Kernel. Will this automatically be replaced if I configure this method?
<qschulz>
coldspark29[m]: all process was done with an upstream U-Boot, so if you're using a vendor one, I cannot say how it's working and if it can work
<coldspark29[m]>
Hmm we indeed use the one from boundarydevices
rob_w has quit [Quit: Leaving]
lexano has joined #yocto
sb27 has joined #yocto
<sb27>
What is the usual way to do PDF generation with yocto? Is there a latex recipe that I can use? Seems like that would be a pretty massive footprint though.
<JosefHolzmayrThe>
sb27: care to elaborate? pdf generation where, and when?
<sb27>
The yocto system is running a chrome browser with a c++-python-javascript application. I basically want to be able to convert HTML to PDF and be able to print the PDF out to a printer (whenver the user desires)
Tokamak has joined #yocto
<JosefHolzmayrThe>
just pack the stuff into the webpage. js can totally do that.
tnovotny has quit [Remote host closed the connection]
<JosefHolzmayrThe>
rendering html to pdf in anything that is not effectively a full blown browser rendering engine is basically pain.
<JosefHolzmayrThe>
more pain than in the browser, that is.
artri has joined #yocto
<JosefHolzmayrThe>
if on the other hand you're willing to leave out the "html to" part, then i'd go for some library that matches your needs in the backend. i'm sure there's some usable stuff in the python space.
atril has joined #yocto
<sb27>
JosefHolzymayrThe: Thanks! I think the reason we like latex is because it does a lot of things out of the box like table splitting, multi-page reports, embedded images, and the output is most likely going to be prettier. In this case we would directly generate latex vs convert from html to pdf. But I'm guessing the size requirements are too large.
artri has quit [Ping timeout: 265 seconds]
<JosefHolzmayrThe>
sb27: well if your target is big enough to hold a chromium frontend then latex certainly might be doable too, in terms of resources. texlilve seems to even be cross compile aware, so trying to package it up is probably not extraordinarily crazy either: https://www.tug.org/texlive/doc/tlbuild.html#Cross-compilation
Tokamak has quit [Read error: Connection reset by peer]
<sb27>
JosefHolzmayrThe: Thank you so much! Hopefully it's not too difficult to make a recipe out of that.
Tokamak has joined #yocto
<JosefHolzmayrThe>
sb27: have fun - and if you have something, send patches!
<qschulz>
please upstream it if you manage to get this to work, depending how long it takes to build everything (browser excluded) I might actually make use of it
<qschulz>
nevermind, mixing up Buildroot and Yocto, need it for a Buildroot project :|
<qschulz>
please make it public anyway, I'm sure it can be useful to some people :)
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Crofton_ is now known as Crofton
Crofton is now known as Crofton|cloud
Crofton|cloud is now known as Crofton
<zeddii>
tlwoerner: I was most out last week, but I did get a first pass at the defconfig chopper script up and running.
florian has quit [Quit: Ex-Chat]
manuel1985 has quit [Quit: Leaving]
<tlwoerner>
zeddii: nice!
<zeddii>
I'll check the initial version into the kernel-tools repo and send you some details. and we can see what it does :D
<tlwoerner>
sounds fantastic! :-D
<tlwoerner>
friendly remind to everyone that the CFP for YPS2021.11 closes in a week. please get your proposals in for lightning talks, talks, and hands-on classes
frieder has quit [Remote host closed the connection]
goliath has joined #yocto
rfuentess has quit [Remote host closed the connection]
<zeddii>
ahah. running out of time
* zeddii
makes a note to submit a few options.
mckoan is now known as mckoan|away
gsalazar_ has quit [Ping timeout: 245 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
lexano has quit [Remote host closed the connection]
lexano has joined #yocto
jmiehe has quit [Ping timeout: 260 seconds]
Tokamak has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<wCPO>
hmm, yoctoproject.org got blacklisted (https://admin.uribl.com/), so that's why all the lists mail are suddenly in spam
sb27 has quit [Quit: Client closed]
dev1990 has joined #yocto
pabigot has joined #yocto
<wCPO>
maybe, rspamd just shouldn't use that list, hm
florian has joined #yocto
goliath has quit [Quit: SIGSEGV]
<override>
whats the best way to make a recipe start referring to custom configs
<override>
without touching the recipe itself, trying to do it using bbappend kind of mechanisms
goliath has joined #yocto
pabigot has quit [Remote host closed the connection]
jmiehe has joined #yocto
pabigot has joined #yocto
Wouter0100 has quit [Ping timeout: 245 seconds]
lexano has quit [Remote host closed the connection]
adrian_ has joined #yocto
adrian__ has quit [Ping timeout: 265 seconds]
<khem>
override: write a bbappend and create the dropin files parallel to bbappend in a directory and hook them up into right locations via do_install:append
lexano has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
Wouter0100 has joined #yocto
xmn has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
xmn has quit [Ping timeout: 245 seconds]
xmn has joined #yocto
zen_coder has quit [Ping timeout: 256 seconds]
<RP>
halstead: ^^^ ?
leon-anavi has quit [Quit: Leaving]
atril has quit [Ping timeout: 264 seconds]
GillesM has joined #yocto
wberrier has joined #yocto
<wberrier>
any suggestions about having an additional golang version where various recipes can pick which version of go to use?
WadeBerrier[m] has joined #yocto
<WadeBerrier[m]>
any suggestions about having an additional golang version where various recipes can pick which version of go to use?
florian has quit [Ping timeout: 260 seconds]
GillesM has quit [Remote host closed the connection]
Ad0 has quit [Ping timeout: 268 seconds]
<halstead>
wCPO: thank you for the report. I've been messing with a new mail relay today and may have caused an issue