<RP>
jaskij[m]: I can see what you mean about the collapsed dependencies. If you have "cd -> f" then you do lose info as you can't tell if c depends on f directly or not. That probably isn't an issue though, it just depends what you're trying to show
<ad__>
RP, X_machine = "2" correct ?
<RP>
ad__: depends which project version as the override syntax changed for honister
<zpfvo>
Is there a way to create two different images using wic and wks files? I have two different versions of a raspberry pi (one 16GB and one 8GB) and I want to create an image for both of them in one go. At the moment i set the WKS_FILE in the <MACHINE>.conf. But i really dont want to create a new machine just because of this.
<JosefHolzmayrThe>
zpfvo: depending on your pipeline, you could inject WKS_FILE through either environment or local.conf
rob_w has quit [Remote host closed the connection]
<zpfvo>
JosefHolzmayrThe: ah yes! Injecting throught environment would work
<JosefHolzmayrThe>
zpfvo: please note that I recommend this only if it works for a CI/CD pipeline. if it is something that you ship as a bsp to customers or similar, PLEASE make machine configurations!
<zpfvo>
JosefHolzmayrThe: yes its in our CI/CD. Won't be shipped :)
deurzen has joined #yocto
leon-anavi has joined #yocto
jorschulko has joined #yocto
prabhakarlad has joined #yocto
pgowda_ has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
tnovotny has joined #yocto
kroon has quit [Ping timeout: 260 seconds]
florian has joined #yocto
kroon has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
sb27 has joined #yocto
tnovotny has quit [Quit: Leaving]
<qschulz>
otherwise, just use the same image and expand the fs at first boot
Schlumpf has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
<jorschulko>
Hi, I am trying to modify qemu confs as described here: https://docs.yoctoproject.org/3.1.11/singleindex.html#runqemu-ported-to-python. As far as I understand, the *.qemuboot.conf, which gets autogenerated when building the qemu image, can be populated using a "bsp.conf" file. However, adding a bsp.conf file to $layer/conf/bsp.conf did not work and this is the only mention of this ominous bsp.conf file.
<jorschulko>
Can anyone tell me how this is supposed to work?
<jorschulko>
Thanks :)
gsalazar_ is now known as gsalazar
gsalazar has quit [Quit: Leaving]
gsalazar has joined #yocto
angolini has joined #yocto
<sb27>
My cmake project builds in about 30 seconds. The equivalent bitbake command: bitbake <image> -c do_compile, compiles in 30 minutes. Is there an easy/documented way to directly use the cross-compiler with cmake, without using bitbake? Or will I have to modify my project's cmake based on the cmake bbclass? Is this sufficient and is this process
<sb27>
documented on the internet anywhere?
<qschulz>
bitbake <cmake-recipe> -c devshell I think? this will put you in the workdir of the recipe and have everything setup in the environment to build your cmake project from that terminal
<qschulz>
sb27: you can also bake JUST your cmake project by running `bitbake <cmake-recipe>`
<qschulz>
otherwise just set CC/CXX env variable to the path to the toolchain in the yocto build dir, but I'm not sure to understand what your question is exactly
<rburton>
sb27: sounds like you should debug why that happens instead of working around. look at the configure log to see if there's any glaring differences? cmake.bbclass has a toolchain file which might be making a setting that causes a different build.
<jorschulko>
ok, I was able to reconfigure qemu via the localconf. :)
jorschulko has quit [Quit: leaving]
chep has quit [Ping timeout: 264 seconds]
<qschulz>
rburton: they mention bitbake <image> and not bitbake <cmake-project> so I'm not sure it's the same thing that takes 30min to build in Bitbake?
<jaskij[m]>
<RP> "jaskij: I can see what you..." <- Not if the label for cd says "c -> d" and I ensure that collapsing only ever happens if d is c's only dependency. Or am I missing something?
chep has joined #yocto
<qschulz>
jaskij[m]: what would happen for do_configure -> do_compile -> do_install ?
<qschulz>
I think those are direct and single dependencies?
<jaskij[m]>
Unless there's ptest, usually yes
<jaskij[m]>
And would end up as a single node
<jaskij[m]>
It kinda conflicts with your idea, but would dramatically cut down the number of nodes
<jaskij[m]>
Unless I do that DEPENDS guess before collapsing
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<jaskij[m]>
It should also dramatically cut down on render times
<qschulz>
I think the DEPENDS guess wasn't really a good idea as per rburton's reaction to the suggestion :)
<qschulz>
jaskij[m]: I guess if you have a good label for this new node, it could be ok? But not convinced it's not going to introduce confusion
<jaskij[m]>
Come to think of it, I should probably make it default not to collapse across recipe lines
<qschulz>
jaskij[m]: IMO, default should be something beginner-valuable
<jaskij[m]>
What I mean is that, say, `-c` only collapses within recipe and `-cc` enables doing it across recipes
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<qschulz>
jaskij[m]: what's the usecase for -c ?
<jaskij[m]>
qschulz: True. I think for now I'll add the options and then we can figure a beginner friendly set of flags which will be included in the README or added as a --beginner flag or ship as an included config file.
<qschulz>
jaskij[m]: no optional flags should be the beginner friendly configuration
<qschulz>
then you can have a --fast that is an alias to all things that makes things faster to the cost of potential confusion?
<jaskij[m]>
qschulz: The graphs can, and often will, end up large. This will dramatically cut down the graph size, hopefully without losing much, if any, information
gsalazar_ has joined #yocto
<jaskij[m]>
I'm hoping it will reduce the note count on the order of 50%
gsalazar has quit [Ping timeout: 265 seconds]
<jaskij[m]>
<qschulz> "jaskij: no optional flags should..." <- That would probably mean adding negative flags. Also, most of the stuff is too dependent on what you're looking for. IMO the only stuff that could be on by default is short labels, removing -native and -cross dependencies and *maybe* clusters
<jaskij[m]>
Sidenote: I forgot -c is already used for clusters, collapsing needs a different flag. Maybe -m for --merge?
<qschulz>
jaskij[m]: --hide or --collapse with choices/coma-separated list?
<qschulz>
I don't know honestly, I don't like one letter aliases :p
<qschulz>
it's IMO more important to have a meaningful full length option name, even if the one letter alias is not the first letter of the full length option name, but that's personal taste
<jaskij[m]>
qschulz: What would be the use of a list here?
<jaskij[m]>
qschulz: Kind of true, especially if you keep around scripts or something. I'm thinking of adding the option of loading the command line from a file (iirc argparse supports this?) and maybe shipping some predefined configs with the script.
<qschulz>
jaskij[m]: if you plan to have more than one collapsible thing than one recipe/all recipes
<qschulz>
e.g., collapse multiple recipes but not all and list them
xmn has quit [Ping timeout: 265 seconds]
otavio has joined #yocto
<jaskij[m]>
Not for now, I think. There would be two options: collapse within recipes and collapse across recipes
<jaskij[m]>
I don't really see the need to add filtering here
<jaskij[m]>
OTOH, there could be an option to only collapse the common chains (eg do_install -> do compile -> do_configure)
kroon has quit [Quit: Leaving]
chep has quit [Ping timeout: 250 seconds]
rob_w has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
chep has joined #yocto
zpfvo has joined #yocto
<jaskij[m]>
Hmm.... Come to think of it qschulz RP rburto In want to default to removing -native and -cross recipes, would it make sense to also remove \*ptest\* tasks by default? As said earlier, the default no flags config would be meant to be beginner friendly and IMO the primary use case would be analyzing why something is included in the image. Would add a single flag to show all tasks.
<Saur>
jaskij[m]: If you want to clean up task-depends.dot for rendering then you should post-process it using the tools from graphviz. E.g., use gvpr to filter the nodes that you want, and use tred to reduce the graph (removing redundant edges). gvpr is extremely powerful when it comes to making huge graphs like the one from OE renderable.
<jaskij[m]>
Saur: didn't know it existed. Either way, I've already started on my own script, which uses pygraphviz to parse and plan to include some Yocto specific stuff. https://gitlab.com/jaskij/oe-dependency-tool
<Saur>
jaskij[m]: Here is an example of a filter for removing all native tasks, and add some coloring: https://pastebin.com/j4SE2piH
jwillikers has joined #yocto
<jaskij[m]>
Neat. Does it allow for filtering by node? Say, I give it a node name and it only shows nodes up or down from the selected node?
jwillikers has quit [Remote host closed the connection]
alejandrohs has quit [Ping timeout: 264 seconds]
hpsy has joined #yocto
kroon has joined #yocto
<jaskij[m]>
Seems I *could* rewrite my Python script in gpvr, but it's growing biggish (even if we exclude the stuff which gpvr handles by itself) *and* I'd prefer to use a more well-known language. Not to mention there are some requirements on the structure of the `.dot` file that I'm not sure gpvr *can* handle (mainly for the mode which outputs human readable and diffable files).
rob_w has quit [Quit: Leaving]
sakoman has joined #yocto
<jaskij[m]>
qschulz: I'm back to my conundrum of SoM with vs without WiFi. I think I have figured it out - FIT images support overlays, so I'll just drop the WiFi overlay into the FIT image and then just enable the overlay via a dedicated file in rootfs.
<qschulz>
jaskij[m]: how do you detect which board is booting your fitimage?
gsalazar has joined #yocto
gsalazar__ has joined #yocto
gsalazar__ has quit [Client Quit]
gsalazar has quit [Client Quit]
gsalazar has joined #yocto
gsalazar has quit [Client Quit]
gsalazar has joined #yocto
gsalazar_ has quit [Ping timeout: 250 seconds]
<jaskij[m]>
qschulz: I don't. There's no sane way to do it, so I gave up. This would have come down to flashing the correct image anyway, but at least this way I cut down the number of machines in my BSP.
Tokamak has joined #yocto
<jaskij[m]>
I can't probe the pins, since they're also present on the edge connector and routed to an extension header on the baseboard (unused at the moment, but still)
<qschulz>
jaskij[m]: ok, so what do you mean by "enable the overlay via a dedicated file in rootfs."?
Tokamak has quit [Client Quit]
<jaskij[m]>
Essentially, a renamed `env.txt`
<qschulz>
jaskij[m]: you can just run a fw_setenv dtbo 'name-of-dtbo.dtbo' and read this dtbo variable from U-Boot
<jaskij[m]>
I could just dump this in env.txt, but I think separating it might make it easier to work with, I'll have to think it through
<jaskij[m]>
And fw_setenv will work with env.txt, won't it?
<qschulz>
jaskij[m]: no idea, i've never used env.txt until now
<jaskij[m]>
Mhm. I don't have a dedicated environment section in the flash, `saveenv` dumps to `/boot/env.txt`
<jaskij[m]>
I probably could have a fixed location on the eMMC for this, but for internal reasons I'm winding down the development on this board and have to move on.
<sb27>
@qschThank you for the responses. How would I extract the SDK tools
<qschulz>
sb27: if you use bitbake <cmake-project-recipe> -c devshell, there's nothing to be done for you, the env variables are set up correctly so if you don't override them in your cmakelists.txt, you should be good to go
<qschulz>
you just need to run your usual command as if it were a normal local build, just within the devhsell "environment"
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
<qschulz>
if you want a full SDK so that other devs can build without using bitbake, follow what jaskij[m] just said
<jaskij[m]>
qschulz: I think there's a need to give CMake the toolchain file for dependency lookup. So running bare `cmake` in dev shell might not work. Unless CMake allows setting all of it's variables (CMAKE_TOOLCHAIN_FILE in this case) via environment?
<sb27>
qschulz jaskij[m] Thanks for the responses. Sorry, I hit enter too quickly. Basically, I think my real question is, is it possible to extract the SDK tools outside the bitbake environment to use it on a different host (bitbake)? I can use populate_sdk to generate the sh file, copy this to a different host, and then load the dev environment on that
<sb27>
host. Then the problem becomes actually using these tools (arm-poky-linux-gnueabi-*) with cmake on the other host, correct?
<sb27>
on a different host (WITHOUT bitbake)*
<qschulz>
sb27: if you source the sh, the environment should be set correctly with PATH and all
<jaskij[m]>
sb27: The .sh file is a makeself installer. Once you install it, the toolchain directory will include a toolchain file you can pass to CMake via `-DCMAKE_TOOLCHAIN_FILE`
<qschulz>
but I assume if you knew already all this, you have an issue, so why not share the issue :)
<jaskij[m]>
qschulz: sourcing the file in an IDE is not really viable. But iirc the toolchain files work without that, or they do with a slight modification.
zpfvo has quit [Ping timeout: 250 seconds]
<qschulz>
jaskij[m]: I would have assumed that to be already set correctly by the shell script sourced
<qschulz>
since I'd have assumed that the cmake from the toolchain would be used
<qschulz>
s/toolchain/SDK/
<qschulz>
jaskij[m]: vim is my IDE so no problem on that side :D
akica has joined #yocto
adrian_ has quit [Remote host closed the connection]
adrian_ has joined #yocto
<jaskij[m]>
qschulz: I don't think you can set all the necessary variables via environment. Apart from compilers and linker paths and arguments, CMake also needs sysroot door as it does some dependency lookup using pkgconfig and it's own modules.
<jaskij[m]>
There's an `${SDK_DIR}/sysroots/${SDKMACHINE}/usr/share/OEToolchainConfig.cmake` but the one I'm reading makes little sense, like something was missing.
<jaskij[m]>
or not
<jaskij[m]>
misread it
<qschulz>
jaskij[m]: I can't argue or discuss this further as I really only know some parts of Yocto SDK, and only in theory. So I trust you :)
<jaskij[m]>
*set all the necessary CMake variables
zpfvo has joined #yocto
codavi has joined #yocto
<ad__>
what coud be the reason of a recipe git directory empty on do_compile ?
<jaskij[m]>
sb27: once you install the SDK, there will be an `${SDK_DIR}/sysroots/${SDKMACHINE}/usr/share/OEToolchainConfig.cmake` - copy it, replace the $ENV variables with values from `${SDK_DIR}/environment-setup-${TARGET}`, remove the last section with GLOB if you're so inclined, and feed the new toolchain file to CMake with `-DCMAKE_TOOLCHAIN_FILE=${YOUR_SDK_FILE}`
<ad__>
do_compile claims sources are missing, not clear why they are not downloaded
akica has quit [Ping timeout: 265 seconds]
<qschulz>
ad__: missing S = "${WORKDIR}/git" in your recipe I assume
<jaskij[m]>
RP: would you be opposed to SDK including additional CMake toolchain files with baked-in variable values (as opposed to sourcing environment-setup-${TARGET} and using $ENV inside)? This would greatly simplify setup for using big IDEs which are usually not launched from CLI.
kiran has joined #yocto
marc1 has quit [Ping timeout: 268 seconds]
<ad__>
S = "${WORKDIR}/git" is inside a "require recipe_git.inc" so seems ok
<ad__>
ok solved, sry, was accessig a git/subdir that was not existing
<jaskij[m]>
<jaskij[m]> "RP: would you be opposed to..." <- I agree that it's most likely not necessary, but would greatly simplify IDE setup.
<RP>
jaskij[m]: I'm not opposed to it, just not everyone uses cmake...
<qschulz>
also means people will probably expect from us to maintain this but if not many people from the (contributing) community uses it, it's difficult to guarantee it's working ok?
<jaskij[m]>
The only thing that needs to be done is take the existing OEtoolchain.cmake and replace calls to ENV with hard coded values.
<jaskij[m]>
Which, come to think of it, would probably be relative to the toolchain file, or need to be generated in the install script.
<jaskij[m]>
At least I think so. I'll probably spend most of my Sunday digging either in CMake support in SDK or with that dependency graph script
<jaskij[m]>
<RP> "jaskij: I'm not opposed to it..." <- I can be quite oblivious (especially on chats) and the second part of your message flew right over my head.
vd has joined #yocto
<jaskij[m]>
I'm not proposing sacrificing anything, just adding a few more files to the SDK. Nor am I criticizing anything.
aleblanc has joined #yocto
<RP>
jaskij[m]: The tricky thing is more hardcoded paths in the SDK - we deliberately tried to minimise the number of places the installer has to change the installed location iirc
leon-anavi has quit [Quit: Leaving]
leon-anavi has joined #yocto
<jaskij[m]>
RP I believe I could solve this by making the hard coded paths relative to the toolchain file (CMake makes all the paths absolute early on regardless). So the only hardcoded things would be the toolchain prefix and target name. This should be fine unless the SDK directory structure changes.
zpfvo has quit [Ping timeout: 268 seconds]
dev1990 has joined #yocto
zpfvo has joined #yocto
marc1 has joined #yocto
<RP>
jaskij[m]: that could work
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
<jaskij[m]>
Ah, one more thing to hardcode: CFLAGS, CXXFLAGS and maybe LDFLAGS
<jaskij[m]>
RP: I dug out a toolchain file I've created for my older project and added annotations on what would need to be filled, everything can be done at SDK generation https://gitlab.com/-/snippets/2207506
kroon has quit [Quit: Leaving]
<jaskij[m]>
OEToolchainConfig.cmake comes from `cmake-native`, I'd either have to patch it or add an SDK-only recipe, or something?
<jaskij[m]>
Is there an SDK overload?
<qschulz>
class-nativesdk OVERRIDES IIUC your question
<jaskij[m]>
Okay, I'll work on both the extra toolchain files and a CMake section for the SDK manual.
<jaskij[m]>
Code generation in recipe itself isn't anything awkward, is it?
chep has quit [Ping timeout: 265 seconds]
chep has joined #yocto
florian_kc has joined #yocto
adrian_ has quit [Ping timeout: 268 seconds]
<smurray>
RP: to extend what Tim just said, I think there's currently a bit of a gap for the image in image workflow with multiconfig, atm everyone is stuck hacking up how to figure out where the child multiconfig images are to pull them in
<smurray>
RP: I've no good idea on how that could be addressed right off, though
adrian_ has joined #yocto
<smurray>
RP: I usually end up with ideally wanting to be able to know the value of some of the image variables from a different config, which seems intractable
chep has quit [Ping timeout: 265 seconds]
chep has joined #yocto
aleblanc has quit [Remote host closed the connection]
aleblanc has joined #yocto
zpfvo has quit [Quit: Leaving.]
sb27 has quit [Quit: Client closed]
adrian_ has quit [Ping timeout: 250 seconds]
troth has quit [Ping timeout: 265 seconds]
<RP>
smurray: We could add an API to do that, we'd just have to ensure it couldn't be abused as it would be a slow operation
nerdboy has quit [Ping timeout: 250 seconds]
<RP>
smurray: I think the understanding was always that the multiconfig itself would configure this so it could work
chep has quit [Ping timeout: 265 seconds]
chep has joined #yocto
<smurray>
RP: the issue I've see there is then you're having to hard-code things after some trial and error, it's not really something someone new to OE is going to understand
adrian_ has joined #yocto
<smurray>
RP: as an example of a wrinkle I've hit, I had to code up special-casing for a BSP that changes IMAGE_LINK_NAME to be able to figure out what the image filename to copy over would be
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
<RP>
smurray: that is a valid point and yes, having some API to do it would be nicer
aleblanc has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 250 seconds]
aleblanc has joined #yocto
troth has joined #yocto
mckoan is now known as mckoan|away
leon-anavi has quit [Quit: Leaving]
rfuentess has quit [Remote host closed the connection]