Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #yocto
ctraven has joined #yocto
Daanct12 has quit [Ping timeout: 248 seconds]
GillesM has joined #yocto
enok has joined #yocto
GillesM has quit [Client Quit]
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
Daanct12 has joined #yocto
goliath has joined #yocto
rfuentess has joined #yocto
druppy has joined #yocto
Chaser has joined #yocto
davidinux has joined #yocto
enok has quit [Ping timeout: 252 seconds]
bhstalel has joined #yocto
rob_w has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
zeemate has joined #yocto
druppy has quit [Ping timeout: 252 seconds]
frieder has joined #yocto
Chaser has joined #yocto
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok71 has joined #yocto
Articulus has joined #yocto
jclsn has joined #yocto
enok71 is now known as enok
mckoan|away is now known as mckoan
leon-anavi has joined #yocto
skandigraun has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Articulus has quit [Read error: Connection reset by peer]
Articulus5 has joined #yocto
jpuhlman has quit [Ping timeout: 252 seconds]
ello- has joined #yocto
ello_ has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
jpuhlman has joined #yocto
florian_kc has quit [Ping timeout: 244 seconds]
rfuentess has quit [Remote host closed the connection]
eduter has joined #yocto
<eduter>
Hi everyone. Quick question. Can I run using the quick emulator "qemu", a rootfs ext4 generated from my Yocto build which was targeting a vendor machine phygate-tauri-l-imx8mm-2?
<eduter>
Or the emulator only works when one targets qemu machines?
rfuentess has joined #yocto
savolla has joined #yocto
belsirk has joined #yocto
rfuentess has quit [Ping timeout: 244 seconds]
<yocton>
eduter: It should theoreticaly be possible but my guess is that it does not work out-of-the-box and will require work
<eduter>
yocton Ok Yocto thanks! I will give it a try and see how far I get :-)
<mcfrisk>
eduter: it should be possible to boot your kernel and tune settings, with correct qemu machine/cpu setup, but the peripherals will be different so some virtualization or block device drivers may need to be enabled in you kernel for this to work. And/or which firmware you use, booting u-boot with qemu is possible and that enables also using similar kernel load mechanisms as real target, except the backend
<mcfrisk>
drivers may be different on qemu.
paulg has quit [Ping timeout: 260 seconds]
<eduter>
mcfrisk thanks for sharing your wisdom! Ok understood :-)
<mcfrisk>
"runqemu slirp nographic novga $your_image" is a starting point, then adjust the QB variables so that needed arguments are given to qemu-system to select correct CPU etc to emulate
<eduter>
mcfrisk Ok. I will try to gather as many specific info as possible to try to have the emulator running as close as possible machine to my real physical target.
Chaser has joined #yocto
vthor_ has quit [Excess Flood]
vthor_ has joined #yocto
enok has quit [Quit: enok]
enok71 has joined #yocto
enok71 has quit [Ping timeout: 252 seconds]
<kanavin>
eduter, unless you want to emulate specific features of the target, you're better off using qemux86-64 with kvm (or qemuarm64 if your build host is arm).
<kanavin>
You'll be able to run target userspace apps at native speed
<kanavin>
if your host and target architecure don't match, qemu will resort to software emulation, which is not quick at all.
<eduter>
kanavin my build host is x86_64. So in my local.conf I should maybe consider setting MACHINE="qemuxarm64"? My host build machine is x86_64 but my target machine is ARM64 (AARCH64)
<kanavin>
eduter, MACHINE='qemux86=64'
<kanavin>
and then use kvm parameter with runqemu
<kanavin>
this way qemu will not emulate target cpu instructions, but rather just execute them directly on the host cpu, because they match
<eduter>
kanavin ok... the recommendation here is to match the architecture of my build host machine... so I should set MACHINE='qemux86-64' and then use the kvm parameter
<kanavin>
yeah
<eduter>
kanavin ok!!! I thought "ideally" I should target the machine of the real hardware! I did not know about the performance... ok will try that kanavin. thanks :-)
<rburton>
eduter: emulating the real hardware is hard, and qemu doesn't have full emulations of many modern systems, especially a specific arm board. its often easier to just port your image explicitly to qemu (so it doesn't assume certain hardware the real target board has) and then you can run it with kvm for speed.
<kanavin>
'port your image' == 'ensure that userspace can function in useful ways and not immediately fail due to missing sensors or peripherals'
<kanavin>
depends on what your stack actually does
<eduter>
ok :-) I am learning here, thanks for explaining things in detail
<mcfrisk>
for real products, I've found that qemu and emulation, and evaluation kits are useful in early rampup when HW is being prepared. Then later on all focus needs to switch to real HW. In major transitions, like yocto updates, booting an image in qemu for quick sanity checks can be faster than working with real HW but again at some point the switch to real target HW must happen
<eduter>
mcfrisk Yes of course the best is to try in real hardware.
skandigraun has quit [Quit: Client closed]
<kanavin>
the golden standard is to have a CI pipeline that builds the image with yocto, flashes it on the hardware, and runs tests
<kanavin>
then you can plug it into various process points, maybe even do it with every proposed change to the master branch, etc.
eduter has quit [Quit: Client closed]
enok has joined #yocto
enok has quit [Quit: enok]
enok71 has joined #yocto
enok71 is now known as enok
enok has quit [Ping timeout: 265 seconds]
eduter has joined #yocto
zeemate_ has joined #yocto
zeemate has quit [Ping timeout: 248 seconds]
enok has joined #yocto
<LetoThe2nd>
concerning SPDX, with SPDX_INCLUDE_SOURCES = "1", where would I actually go digging for a list of source files which were used to generate a specific file/binary on the target?
belsirk is now known as rfuentess
<LetoThe2nd>
when digging into the per recipe spdx files I just find lists of cross references, but how to actually trace that back to real file names?
frgo has quit [Read error: Connection reset by peer]
frgo has joined #yocto
<LetoThe2nd>
Ok, it seems to be expanded in the final per-image spdx.json, but not anywhere else AFAICS.
ablu has quit [Ping timeout: 248 seconds]
ablu has joined #yocto
eduter has quit [Quit: Client closed]
eduter has joined #yocto
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #yocto
mbulut has joined #yocto
cyxae has quit [Quit: cyxae]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cyxae has joined #yocto
enok has quit [Ping timeout: 245 seconds]
Articulus5 has quit [Ping timeout: 268 seconds]
florian has quit [Quit: Ex-Chat]
Daanct12 has quit [Read error: Connection reset by peer]
enok has joined #yocto
paulg has joined #yocto
AatirManzur has joined #yocto
florian has joined #yocto
Daanct12 has joined #yocto
eduter has quit [Ping timeout: 240 seconds]
GillesM has joined #yocto
AatirManzur has quit [Remote host closed the connection]
sotaoverride_ has joined #yocto
rob_w has quit [Remote host closed the connection]
sotaoverride has quit [Quit: Lost terminal]
sotaoverride_ is now known as sotaoverride
sotaoverride has quit [Remote host closed the connection]
sotaoverride__ has joined #yocto
sotaoverride__ has quit [Remote host closed the connection]
sotaoverride has joined #yocto
Xagen has joined #yocto
skandigraun has joined #yocto
tortoise has quit [Ping timeout: 276 seconds]
avocadosand has quit [Read error: Connection reset by peer]
tortoise has joined #yocto
avocadosand has joined #yocto
nohit has quit [Ping timeout: 252 seconds]
rsalveti has quit [Read error: Connection reset by peer]
NishanthMenon has quit [Read error: Connection reset by peer]
rsalveti has joined #yocto
NishanthMenon has joined #yocto
smurray has quit [Ping timeout: 276 seconds]
bradfa has quit [Ping timeout: 252 seconds]
awafaa has quit [Ping timeout: 252 seconds]
rfuentess has quit [Remote host closed the connection]
salahaldeen has quit [Ping timeout: 252 seconds]
awafaa has joined #yocto
nohit has joined #yocto
smurray has joined #yocto
bradfa has joined #yocto
salahaldeen has joined #yocto
mbulut has quit [Ping timeout: 272 seconds]
Daanct12 has quit [Quit: WeeChat 4.6.0]
<tgamblin>
how does one prevent a package from being installed in an image? isn't there a way to do it that doesn't involve tweaking the RDEPENDS of recipes that pull it in?
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
savolla has quit [Client Quit]
savolla has joined #yocto
<smurray>
tgamblin: there's PACKAGE_EXCLUDE
goliath has quit [Quit: SIGSEGV]
<tgamblin>
smurray: thanks - I was getting stuck on IMAGE_INSTALL:remove not working
dgriego has quit [Ping timeout: 260 seconds]
<smurray>
tgamblin: BAD_RECOMMENDATIONS is also another option if it's specifically a recommends that's pulling something
<tgamblin>
smurray: in this case I've got a packagegroup that's including a recipe, which I don't want in the image
<tgamblin>
smurray: it's arago-gpl-notice in meta-arago-distro (don't need it in the image for debug purposes, and it only seems to add init scripts)
dgriego has joined #yocto
<smurray>
tgamblin: yeah, if you don't want to bbappend the packagegroup, then likely PACKAGE_EXCLUDE is it
vmeson has quit [Quit: Konversation terminated!]
<tgamblin>
smurray: alright, thanks
042ABCBFN has joined #yocto
042ABCBFN is now known as vmeson
zeemate_ has quit [Ping timeout: 260 seconds]
frieder has quit [Remote host closed the connection]
christner has quit [Read error: Connection reset by peer]
Saur has quit [Read error: Connection reset by peer]
christner has joined #yocto
Tartarus has quit [Read error: Connection reset by peer]
Saur has joined #yocto
LetoThe2nd has quit [Read error: Connection reset by peer]
Tartarus has joined #yocto
LetoThe2nd has joined #yocto
Chaser_ has joined #yocto
Chaser has quit [Ping timeout: 248 seconds]
goliath has quit [Quit: SIGSEGV]
Chaser_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bhstalel has quit [Quit: Client closed]
Chaser has joined #yocto
skandigraun has quit [Quit: Client closed]
Ad0 has quit [Ping timeout: 252 seconds]
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Chaser has joined #yocto
reatmon_ has quit [Remote host closed the connection]
zeemate_ has joined #yocto
reatmon_ has joined #yocto
florian has quit [Ping timeout: 248 seconds]
Chaser has quit [Ping timeout: 252 seconds]
florian has joined #yocto
druppy has joined #yocto
leon-anavi has quit [Quit: Leaving]
Ad0 has joined #yocto
<khem>
kanavin:gold standard! been there and done that :) however it hits bottlenecks as you scale the teams and products, emulation is powerful to leverage all along the life cycle of products because you have to separate components into their own CI loops
<khem>
careful s/w architecture for products will let you do that effectively e.g. networking products can be tested using topology crafted with containers right on dev's box
<khem>
e.g. have layers well defined and create OCI images for components under test - launch the containers for n/w topologies needed to be tested, start test
druppy has quit [Ping timeout: 265 seconds]
prabhakalad has quit [Ping timeout: 244 seconds]
enok has quit [Quit: enok]
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
sotaover1ide has joined #yocto
sotaover1ide has quit [Client Quit]
sotaoverride is now known as Guest7433
Guest7433 has quit [Killed (silver.libera.chat (Nickname regained by services))]
sotaoverride_ has joined #yocto
sotaoverride_ is now known as sotaoverride
goliath has joined #yocto
sotaoverride is now known as Guest5089
Kubu_work has quit [Quit: Leaving.]
florian has quit [Ping timeout: 276 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enok has quit [Quit: enok]
cyxae has quit [Quit: cyxae]
reatmon_ has quit [Remote host closed the connection]
Marmottus11 has quit [Quit: Ping timeout (120 seconds)]
reatmon_ has joined #yocto
Marmottus11 has joined #yocto
bjdooks has quit [Remote host closed the connection]
bjdooks has joined #yocto
gmorell has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
olani- has joined #yocto
zeemate_ has quit [Ping timeout: 248 seconds]
tlwoerner_ has joined #yocto
tlwoerner has quit [Remote host closed the connection]