<wyre>
could I use this also to flash in the nand?
<LetoThe2nd>
wyre: you're totally reading things into that document that are not there.
<wyre>
what do you mean? things that aren't currently in that way?
<LetoThe2nd>
wyre: the config you stated does not affect the generated image type, it just configures uboot for a certain boot strategy. and one paragraph um, there is a link to a section that should tell you how to flash to nand.
<LetoThe2nd>
wyre: "when I set UBOOT_CONFIG="nand" I should have an image with extension .ubifs" is what you wrote. and thats just not written there, AFAICS
<wyre>
oh, sure, that's right, I was just doing the assumption
<wyre>
but then I'm not sure what have I to do to generate that .ubifs file 🤔
<LetoThe2nd>
wyre: probably set a different IMAGE_FSTYPE+
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
bps has joined #yocto
<wyre>
hmm... I've set IMAGE_FSTYPES += "ubifs" in conf/local.conf but it cannot produce the ubifs file because I'm having "Error: min. I/O unit was not specified (use -h for help)" should I do something more?
<LetoThe2nd>
yep, you should read up on how ubifs works, and what you actually need to configure in order to use it for your specific board. if you don't know or are missing relevant information, please consult engicam.
<wyre>
yep, the point is that I can't see anything about ubifs in the manual I linked 😞
leon-anavi has joined #yocto
<qschulz>
you need some ubinize parameters specific to the NAND chip you
<qschulz>
you need arguments specific to your NAND IIRC
<qschulz>
and if you want to create a ubi image, you need ubinize parameters too
mc__ has joined #yocto
tnovotny has joined #yocto
goliath has joined #yocto
mcc_ has quit [Ping timeout: 265 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
hpsy has joined #yocto
florian has joined #yocto
<wyre>
qschulz, I don't get the point of ubinize parameters, is not enough by setting the MKUBIFS_ARGS?
<qschulz>
ubinize and kmfs.ubifs are different tools, therefore different purposes and different parameters
<qschulz>
it's all explained in the first link I sent
<mcfrisk>
hi, is anyone else seeing negative build performance from hashequiv? In our case a full build without sstate cache or mirrors takes 4½ hours but a large dunfell update with sstate mirror and local cache and hashequiv takes 6½ to 7 hours. Difference seems to be the delayed tasks and hash checks
BCMM has joined #yocto
ant__ has joined #yocto
hpsy has quit [Quit: Leaving.]
hpsy has joined #yocto
jmiehe has joined #yocto
jmiehe1 has joined #yocto
jmiehe has quit [Ping timeout: 268 seconds]
jmiehe1 is now known as jmiehe
ant__ has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
<JaMa>
zeddii: ping for friday :) I can send a fix for that do_patch, I'm just wondering what might trigger it just now (possibly by suddenly including it in "bitbake world")
davidinux has quit [Ping timeout: 240 seconds]
rob_w has quit [Quit: Leaving]
jwillikers has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
davidinux has joined #yocto
override has joined #yocto
<override>
hey, lets say I have two machine.conf files with the same name under different meta layers, how can I specify whcih one to use in local.conf can I give explict path for MACHINE ?= "" in local.conf?
<override>
I'm sure MACHINE ?="" cant take exlicit paths
<override>
so what might be a solution here?
<qschulz>
override: don't have two machines with the same name
<override>
qschulz: got some scripts using the MACHINE variable which would break if I changed the name
<qschulz>
The order in which your layers appear in bblayers.conf will be the order in which your conflicting bbclasses and conf files will be "resolved" (first found is first taken)
<override>
and I dont have control over some of the meta-layers
<qschulz>
(well, technically it's because of BBPATH variable default "value" in conf/layer.conf that makes it rely on order in bbalyers.conf)
<override>
oh, so I can just maybe use the order in bblayers.conf. thanks
<qschulz>
override: which is a terrible idea
<qschulz>
you should never rely on layer order for something to work
<JaMa>
not sure, but maybe BBMASK would work as well
<rburton>
override: virtual/foo are virtual recipe names, multiple recipes may PROVIDE that name and your machine/distro/soemthing uses PREFERRED_PROVIDER to pick one
<qschulz>
JaMa: that's an option for bb/bbappends but I'm not sure this works with conf files?
<qschulz>
JaMa: but I'm curious now :)
<JaMa>
doesn't seem to work
<override>
rburton: are u saying I can possibly use the PREFERRED_PROVIDER name to let local.conf select what layer to get the machine.conf from?
<rburton>
no
<rburton>
you were asking about virtual/dtb earlier
<override>
oh, ok I figured. thanks
<override>
I got over those troubles somehow last night
<override>
now im hitting this same machine different meta-layers crap
<qschulz>
override: also, depending how MACHINE is used, you could use overrides instead and set MACHINEOVERRIDES correctly in your machine configuration file
jwillikers has quit [Remote host closed the connection]
<override>
ill lookup MACHONEOVERRIDES and overrides quick, unless someone just wants to beat me to it and explain
<override>
ive used MACHINE)VERRIDES =. "user-head-next" before , cant remeber what that was doing tho
<JaMa>
RP: would it make sense to extend BBMASK (or some new variable) to filter BBPATH as well (I don't want to give any bad ideas, but evil BSP with nasty package.bbclass would be difficult to work with)
<override>
cool, thanks guys - guess I'd have to do something better than use the bblayes ordering now
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
<override>
qschulz: I get the content specific bit, but my issue here is that the MAchine names are the same, I some how want local.cong to fetch them machine from a particualr meta-layer..
<JaMa>
zeddii: I've sent a fix for recipes-extended/uxen/uxen-guest-tools_4.1.7.bb, it was triggered in my world builds for first time, just because of missing "export MACHINE" :) and this was first qemux86-64 build which included meta-virtualization (normally I test this only with qemux86 and qemux86-64 world builds on the other hand don't include meta-virtualization)
jmiehe has quit [Quit: jmiehe]
<JaMa>
and now with do_patch fixed it fails in do_compile a bit later (so it probably wasn't building well before if ever):
<JaMa>
| /OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/uxen-guest-tools/4.1.7-r0/uxen-vmsupport-linux-4.1.7/uxenhc/hypercall.c:127:24: error: too many arguments to function '__vmalloc'
<JaMa>
| /OE/build/oe-core/tmp-glibc/work-shared/qemux86-64/kernel-source/include/linux/module.h:182:43: error: expected ',' or ';' before 'KBUILD_MODFILE'
<override>
qschulz: all these different methods let you assign values to a varaible - I dont see how I can use them to select what meta-layer to get the machine from (when the name of the machine is the same in both the meta-layers)
<tortoisedoc>
excuse the intrusion; would someone be able to forward me to the right channel? I have questions pertaining RDK
<qschulz>
override: you're not supposed to have two machine conf files with the same name
<qschulz>
and you didn't want to change the name because recipes were using MACHINE, I gave you a way to not make them depend on that
<qschulz>
by using MACHINEOVERRIDES
<override>
oh, think I see what you mean now.
<qschulz>
just create your own machine conf file which has a different name. The content can even be the same if you want
<override>
but like my recipes with be able to use something for the MACHINE varaible, different from what the actual machine is called
<override>
using MACHINEOVERRIDES or something ok
<zeddii>
JaMa: ack'd I see the patch. I'll ping Christopher on #meta-virt to see if he can fix the build issue .. since he's the Xen expert. Otherwise, I'll have a look later today.
jwillikers has joined #yocto
florian_kc has joined #yocto
<JaMa>
never leave your IT dep people near your build servers without supervision! they are capable of anything and unfortunately even have permissions to do so.... sigh
<tortoisedoc>
JaMa isnt devops meant to keep it & sw dev close?
ant__ has joined #yocto
* tortoisedoc
ducks
<JaMa>
9400 km between me and it is still too close for what they are doing recently :)
<tortoisedoc>
few more km and theyll come in from the backdoor :D
<JaMa>
yeah, need to beg Musk for free ticket soon
hpsy has quit [Quit: Leaving.]
hpsy1 has joined #yocto
<JaMa>
zeddii: it builds ok with 5.4 in dunfell now, only gatesgarth 5.8 and newer with 5.10 kernel are broken
* zeddii
nods.
<zeddii>
I'll just try a version update on it. My build just broke the same way. clearly not built all that often :)
jwillikers has quit [Read error: Connection reset by peer]
paulg has joined #yocto
jwillikers has joined #yocto
hpsy1 has quit [Ping timeout: 240 seconds]
Guest9810 has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<Guest9810>
I was making a build when I ran into a uninative fetcher failure, which surprised me as I have the BB_GENERATE_MIRROR_TARBALLS set, however it seems this doesn't apply to uninative. I've tried to search for a solution, but I haven't found anything so far. So I'm hoping someone can help me or at least point me in the right direction. Any help would
<Guest9810>
be appreciated
sakoman has joined #yocto
Guest4 has joined #yocto
Guest4 has quit [Client Quit]
linums has joined #yocto
<linums>
Hi
<linums>
I've found mage-mklibs.bbclass in the hardknott branch, but not in master or dunfell
<linums>
I guess it is dropped, but not just everywhere right?
<linums>
it was just weird to find it on a newer branch than dunfell, but not on dunfell
<smurray>
it's still in dunfell
<override>
so i think my bsp is setting me up for failure by using ${MACHINE} in multiple bbclasses. I dont want to bring them all into my own meta-layer. is this something I just have to live with, or what should be my plan of action here?
<linums>
smurray wow, how did I miss that :D
<override>
bsp pulls the device tree etc from git and appends the ${MACHINE} to uri's in a couple of bbclasses and then theres a few other places too. So when I define my own MACHINE, things dont build very well..
<vd>
hi all -- If I need to build independent variants of images, what are the pros and cons for multiconfig vs local.conf? (Cc: JPEW)
<vd>
I currently use kas which supports both (multiconfig files in the repo or one kas yml file per build), but there's also whisk which is designed over multiconfig. I cannot decide between both.
<vd>
Where I'm heading is having vanilla image recipes for my product, that I bbappend or customize in a build config file (local or multiconfig) for each customer variants.
<vd>
I guess if one day a customer provides its own application layer, then a kas yml file would be more appropriate.
<vd>
damn, whisk supports layer customization, back to square 1...
<vd>
I'd love rburton and JPEW input on this <3
argonautx has quit [Quit: Leaving]
<JPEW>
multiconfig is useful if you need to build different configs at the same time
<JPEW>
Also, one of many ways to check product config into git in an easy to consume manner
ant__ has quit [Remote host closed the connection]
<vd>
JPEW with whisk, does each product or variant have its own file or should a single file be edited to include the variant?
<JPEW>
vd: Each gets it's own config fragment in the `conf` key. You can make that `require` whatever you want
<JPEW>
e.g. all of our `conf` keys are a single line that `requires` another file (as opposed to doing the config inline in the YAML file
<vd>
JPEW I can unfortunately have a very complex set of variants, so ideally long term I would like to write an external graphical tool for non-technical people to click-click in a form to generate a new firmware (in my scenario a given firmware version usually fixes versions for in-house packages)
bps has quit [Ping timeout: 268 seconds]
<vd>
JPEW would whisk make this easy? (I'd imaging the tool pushing a PR to a CI/CD whisk project to override or add a single file, validated with the `validate` whisk command before triggering builds)
<JPEW>
You could probably do that with whisk.... I don't know exactly what you need to customize, but we have a similar usecase where we have a "standard" image that each product customizes
<vd>
exactly this
<JPEW>
vd: Ya, we do IMAGE_INSTALL_pn-main-image = "..." in each product's multiconfig
<vd>
JPEW mainly different variants in my case would be minor image customization for the customer (changing title variables), including or excluding a package, or fixing packages versions.
<JPEW>
Yep
<vd>
JPEW this is what I'm heading to, regardless the tool. SUMMARY_pn-vanilla-image = "Customer image" ;-)
<vd>
the best would be the `require` key to allow a glob or pattern so that I don't need to edit the main whisk config, but that might not be big of a deal anyway.
* vd
discovered whisk *after* working around all his issues with kas..
<vd>
JPEW your CI/CD compile all-targets every time?
linums has quit [Ping timeout: 246 seconds]
<JPEW>
Ya, usually for CI we compile each in it's own instance in parallel
<JPEW>
But for releases, we can build multiple products at the same time (since they e.g. need to be packaged together in the same software updates)
<JPEW>
Which is where using multiconfig is really helpful
dgriego has joined #yocto
<vd>
like co-processor products
<JPEW>
Exactly
<JPEW>
Except at a higher level
florian has joined #yocto
<vd>
yeah I guess if your high-end products is composed of multiple embedded devices paired together, it's neat to package all their firmwares together, hence building in the same instance with multiconfig
<JPEW>
Yep. Most our products are network together and we don't support mixed versions
<vd>
we actually might have this in the future, so better have a setup supporting this use case
<vd>
actually what I have is microcontroller versions not built by yocto, but potato-potato mostly. version-1.2 must have micro controller version x, while version-1.3 must have micro controller version y, etc.
<vd>
this kind of boring mapping that I want non-technical persons to manage and be able to trigger such builds themselves
<vd>
in fact, the external click-click tool I'm describing would simply be a front-end for the main yaml file
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
TundraMan has joined #yocto
marka has quit [Ping timeout: 255 seconds]
ncaidin_lf has joined #yocto
leon-anavi has quit [Quit: Leaving]
ncaidin_lf has quit [Quit: Client closed]
TundraMan is now known as marka
linums has joined #yocto
<vd>
JPEW does whisk handle layer patches?
<JPEW>
Not currently. It's on my TODO list; we deal with them by having internal mirrors of the layers (although I realize this may not be for everyone)
dmoseley has quit [Ping timeout: 240 seconds]
<vd>
indeed, hosting a fork for a single patch in a layer is a bit overkill.
<JPEW>
vd: Ya. We have a strict policy to only backport existing upstream fixes, which helps
<vd>
Can the `commands` section include an additional `git am` command after the fetch maybe?
<JPEW>
Yes, you can do that
<vd>
perfect then, I can handle the patch on my own, might be cleaner
<JPEW>
But that does mean all your users would need to fetch using whisk, which may or may not be what you want
<vd>
kas do it for you which is kinda nice, but can be confusing.
<JPEW>
The other thing we do a lot is have parallel "fixes" layers for each upstream later where we can bbappend things
<JPEW>
which reduces the need to fork
bps has joined #yocto
bps has joined #yocto
dmoseley has joined #yocto
linums has quit [Quit: Ping timeout (120 seconds)]
jwillikers has quit [Remote host closed the connection]
linums has joined #yocto
Sansveni has joined #yocto
linums has quit [Quit: Client closed]
jwillikers has joined #yocto
LetoThe2nd has joined #yocto
jsandman has quit [Quit: Ping timeout (120 seconds)]
jsandman has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
mranostaj has quit [Ping timeout: 252 seconds]
mranostaj has joined #yocto
marka has quit [Ping timeout: 252 seconds]
bps has quit [Ping timeout: 268 seconds]
marka has joined #yocto
zyga__ has joined #yocto
roussinm has joined #yocto
yates_home has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
<yates_home>
if i understand the message correctly, there is a dependency named 'u-boot' in the dependency chain for core-image-minimal: http://paste.ubuntu.com/p/4NKyQPFbyq/
<yates_home>
how do i change that to 'u-boot-csky'?
<vd>
yates_home maybe set the preferred u-boot provider with PREFERRED_PROVIDER_u-boot = "u-boot-csky"
<yates_home>
doh!
<yates_home>
that makes sense
zyga__ is now known as zyg
zyg is now known as zyga
Tokamak has joined #yocto
bps has joined #yocto
bps has joined #yocto
whuang0389 has joined #yocto
whuang0389 has quit [Quit: Client closed]
Vonter has quit [Ping timeout: 256 seconds]
zyga has quit [Ping timeout: 276 seconds]
ant__ has joined #yocto
ant__ has quit [Quit: Leaving]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 250 seconds]
ant__ has joined #yocto
marka has quit [Ping timeout: 252 seconds]
Tokamak has quit [Ping timeout: 255 seconds]
mc__ has quit [Quit: Leaving]
marka has joined #yocto
jwillikers has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
<yates_home>
vd: that worked. thank you.
<yates_home>
when buildling an image, what defines the top-level steps? my immediate issue os that, sometime after virtual/bootloader is build (which completes successfully), i am getting a ERROR: Task (/mnt/hdd/EDG/dachuan-research/gs500/poky/meta-csky/recipes-kernel/linux/linux-csky_5.12.bb:do_uboot_mkimage) failed with exit code '1'
<yates_home>
there must be some mkimage task in the top-level steps?
<yates_home>
ok i get it: this is part of the kernel build
jwillikers has joined #yocto
ant__ has quit [Quit: Leaving]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
jwillikers has quit [Remote host closed the connection]