<jclsn[m]>
Is there a way to run menuconfig on defconfigs that are inside the layer?
rob_w has joined #yocto
leon-anavi has joined #yocto
<Etheryon>
can anyone point me to a guide on how to configure grub in yocto? Or an example?
frieder has joined #yocto
goliath has joined #yocto
mvlad has joined #yocto
<Etheryon>
I've ran out of google pages :D
rfuentess has joined #yocto
NurettinTopalak has joined #yocto
<NurettinTopalak>
Do you have any suggestions for writing yocto image to more than 50 devices? Is there something like automatic image write tool available or how can i do it?
<NurettinTopalak>
I write to each device one by one with the bmaptool command. I want to automate this.
dgriego has joined #yocto
dgriego_ has quit [Ping timeout: 240 seconds]
<Etheryon>
I've been thinking about that as well, maybe boot over network? I haven't looked too much into that yet
<Etheryon>
and create an image that auto-installs (kinda like a live cd?)
<NurettinTopalak>
Google dev board's image writing technique is good but i am using cm4, SD card is embedded.
jpnurmi has joined #yocto
sergioprado has joined #yocto
sergioprado has quit [Client Quit]
<NurettinTopalak>
Writing Mendel to the SD card. Insert the SD card into the Google-Dev-Board, then you set the boot settings from the pins on the device then write the image to eMMC. After that, undo the setting you made on the board.
<NurettinTopalak>
to write an image to cm4, need to plug it into RPI-CM4-IOBOARD
tnovotny has joined #yocto
Guest22 has joined #yocto
<Guest22>
hello
<NurettinTopalak>
hi
<Guest22>
updated the recipe in our own meta-project to fetch a newer kernel, it's all working and the kernel is compiling : Kernel: arch/arm/boot/Image is ready
<Guest22>
| Kernel: arch/arm/boot/zImage is ready
<Guest22>
| Kernel: arch/arm/boot/uImage is ready
<Guest22>
However it seems, as opposed to our previous kernel version, the device tree is not created: make[1]: *** No rule to make target 'arch/arm/boot/dts/rzn1d400-db.dtb'. Stop.
<Guest22>
I must have missed something, could use a pointer ... (no pun intended)
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
mrybczyn has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
Guest22 has quit [Ping timeout: 256 seconds]
<LetoThe2nd>
yo dudX
<shoragan>
rburton, you said yesterday to Emantor that the kernel debugging symbols would be in the -dbg package
<LetoThe2nd>
What might be a good strategy for a package that comes on a dunfell branch, but is deprecated? Keep the initial version recipe around forever as PREFERRED_VERSION, albeit the really preferred version is newer?
<shoragan>
i don't see anything that linux-yocto would do differently. i don't get any kernel-dbg package, though :)
<shoragan>
there's kernel-vmlinux, which contains the unstripped vmlinux, so that's fine. but i'm still looking for the debug symbols of the kernel modules
florian has joined #yocto
NurettinTopalak has quit [Quit: Client closed]
tgamblin has joined #yocto
tgamblin_ has quit [Ping timeout: 240 seconds]
Guest22 has joined #yocto
<shoragan>
i tried with MACHINE=qemuarm on honister, with enabled features/debug/debug-kernel.scc, and i don't have a -dbg either. what am i missing?
<RP>
shoragan: it wasn't entirely straight forward
<shoragan>
yes, looks like it. another reason to move to master :)
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
mihai has joined #yocto
sstiller has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
mckoan has quit [Ping timeout: 256 seconds]
prabhakarlad has joined #yocto
<Saur[m]>
RP: I have sent the updated patches to the list now. The second patch is reworked so there should be no differences in the output except for the fixed progress bar. The patch adding a progress bar for the setscene tasks is dropped. I've also added a patch that adds the number of running tasks to the silent mode, and removes the word "currently" from the normal mode, thus unifying the outputs between the modes. I think it improves the output, but
<Saur[m]>
since we seem to have very different opinions when it comes to the UI, I'll leave it to you to decide whether you want it or not.
Lihis has quit [Quit: Quitting]
Lihis has joined #yocto
mckoan has joined #yocto
<Wouter0100>
very very slowly to commands to a point that it is nearly unresponsive. If U unplug the adapter, it starts to properly respond again. Is this a known issue or any suggestions where to look for a potential fix?
<Wouter0100>
Hello! I'm having issues with a USB 2.0 to 8 x RS-232 serial adapter. On raspbian it works like a charm, but on a custom build OS based on Poky - it slows down all our RPi's to a crawl. After I've plugged in the adapter, I'm nearly unable to login through SSH, and if I'm already logged in through SSH and I plug in the adapter - it starts to respond
florian_kc has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
<qschulz>
Wouter0100: Distros are known to carry a set of patches on top of packages and kernels. It is likely they have something fixing some issues in the kernel that they haven't upstreamed or the kernel version you build in Yocto is too old
<qschulz>
similar things could happen to one of your userspace packages too
<qschulz>
I don't know
<Guest22>
hello;-)
mckoan has quit [Ping timeout: 272 seconds]
<Guest22>
I have recently changed to dunfell from rocko, how do I determine the version of yocto/dunfell I have?
mckoan has joined #yocto
<rburton>
how did you change?
<Wouter0100>
qschulz: Yeah, we also have an userspace package which is showing performance issues. This is not really an issue, but the adapter issue is. I'll have a look which kernel version we're building into Yocto.
sgw has quit [Ping timeout: 240 seconds]
<Guest22>
rburton:git checkout dunfell
<Guest22>
simple
<Guest22>
lol
<rburton>
$ git describe origin/dunfell
<rburton>
yocto-3.1.14-102-g9426c3c83d
<rburton>
assuming you have the same commit, 3.1.14 + 102 commits
<Guest22>
yocto-3.1.14-52-gc8987e7bca
<Guest22>
brilliant thanks
florian_kc has quit [Ping timeout: 240 seconds]
sgw has joined #yocto
<barath>
hi all. is there a way to specify which version of gcc yocto should use for native recipes? googling turned up BUILD_CC, but that doesnt seem to do that and I cant find documentation for it
<rburton>
barath: for native we use the host compiler
<rburton>
if 'gcc' isn't right, set BUILD_CC and friends
dmoseley has quit [Ping timeout: 272 seconds]
dmoseley has joined #yocto
prabhakarlad has quit [Ping timeout: 256 seconds]
pasherring has joined #yocto
<RP>
Saur[m]: your patch is a nightmare to review since it is still doing things like "self.quiet == 0" -> "not self.quiet" which has no functional change but makes me wonder what else is just being changed for cosmetic reasons :(
<RP>
Saur[m]: to be honest I'd prefer a simpler patch than that, rather than rewriting so much
<rburton>
after branch we should run bitbake through black and reformat/stylize it :)
<JaMa>
4 spaces for the win
* JaMa
hides
Guest22 has quit [Quit: Client closed]
<kroon>
someone should rewrite bitbake in C
<kroon>
or, i can go sofar as rust
kevinrowland has quit [Ping timeout: 256 seconds]
camus1 has joined #yocto
dtometzki has quit [Ping timeout: 260 seconds]
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
<RP>
kroon: I once intended to do that (C). It doesn't actually make sense when you get into the details
<kroon>
RP, I believe you. But I wish I knew more about optimizing python code.
<RP>
kroon: There is a profile option to bitbake which generates reports which tell you where it spends all the time
<JaMa>
chromium.do_compile for me :)
<kroon>
RP, i did have a look at that at one point in time, but I got lost :-/
* RP
wishes he could spend more time on optimisation
<RP>
basically it comes down to spotting things which can be made more efficient or not done at all (see the recent files removal from the sysroot)
<kroon>
RP, running anonymoys python code is a big bottleneck when parsing ?
<RP>
kroon: yes, it is one of the big time sinks
<kroon>
RP, yes, those file removals are nice
<RP>
kroon: the variable dependency code is another pain point but I'm not sure what we can do about that
sakoman has joined #yocto
Schlumpf has joined #yocto
lucaceresoli has joined #yocto
lpapp has joined #yocto
lpapp has left #yocto [#yocto]
<Saur[m]>
RP: Ok, I've extracted the two minor code clean ups to a separate patch now.
kroon has quit [Quit: Leaving]
<JPEW>
JPEW
<JPEW>
paulg: IIRC the load average does include tasks waiting on Disk I/O
pgowda_ has quit [Quit: Connection closed for inactivity]
xmn has joined #yocto
rob_w has quit [Remote host closed the connection]
<rburton>
RP: qemu cpe's updated so they'll be gone next report
<RP>
rburton: awesome, thanks
<RP>
rburton: vim upgraded too
<rburton>
yeah just need to get a seatd upgrade out really
<RP>
paulg: you were offline when I replied yesterday but the scheduler in bitbake in plugable and making it pause new tasks starting shouldn't be hard
<RP>
paulg: vmeson had some interesting ideas about using some of the new load indications from recent kernels which did sound promising
<rburton>
RP: and libsolv CPEs updated too
<RP>
rburton: great, that should handle the tidal wave of this week's issues!
cb5r has quit [Quit: cb5r]
florian_kc has joined #yocto
lucaceresoli_ has joined #yocto
<moto-timo>
Life is good when you get a second set of eyes on your code.
<moto-timo>
Thank you rburton
lucaceresoli has quit [Ping timeout: 252 seconds]
<rburton>
moto-timo: <cough> about to send another series
<rburton>
and there's another bundle after that about to get the final build test
<rburton>
(which involves a world build and then diffoscope of the rpms)
<RP>
rburton: another series? :)
<moto-timo>
Lol
<RP>
moto-timo: autobuilder can't keep up!
* moto-timo
clones the AB cluster
vvn has quit [Quit: WeeChat 3.4]
vvn has joined #yocto
<paulg>
RP, maybe I'll go look at it and see how scary it is. Like I said yesterday, I need to retire to have more "chase a squirrel" time.
<paulg>
JPEW, yea I guess if the disk is busy with trying to swap, then that will be implicitly reflected in tasks in D blocked on i/o
<paulg>
I'm not sure if a task shows load if it is waiting on a page fault to be filled that is waiting on swap though.
<RP>
paulg: it is a lovely looking rabbit hole :)
<paulg>
e.g. no i/o pending - just 5 tasks blocked on malloc() waiting for a page...
<paulg>
(no task generated i/o pending that is, via read() write() or similar...)
<rburton>
RP: neither can my machine, it's build numpy about 20 times today
<JPEW>
paulg: Not sure. If the page fault make the task go into uninterruptable sleep, then yes. Can't find the answer to that, but maybe yes since other disk I/O is uninterruptable?
<JPEW>
Maybe someone with more kernel knowledge knows
camus has quit [Ping timeout: 272 seconds]
camus has joined #yocto
<paulg>
either way, since we have access to /proc/swaps - we don't really need to try and "guess" if we have dipped into the swap pool.
<JPEW>
paulg: Sure.... I'd be a little concerned about trusting that since things can get put there and never pulled out even when the load goes back down
<JPEW>
Well, not never, but on demand, and if there is no demand....
* paulg
takes note of the file/function RP has pointed at and tries to not get sucked into the rabbit hole today.
<paulg>
JPEW, yea - you wouldn't look for it to go back to zero - since unused getty and cups and other cobweb infested cruft goes out there to rot until the next reboot.
<RP>
paulg: there are some subclasses below that too FWIW
<paulg>
you'd want to watch for increases, and jitter on the used number as a simple 1st pass metric.
<paulg>
I think for now I'd be more apt to implement the COMPILE_EXCLUSIVE=1 and set that for some small subset of uber-massive turds.
<paulg>
anything that tries to have an AI aspect to it just turns out to be annoying and wrong all the time.
<paulg>
Take the hateful OOM killer as a prime example.
<JPEW>
paulg: in our devices, we always make our UI app the most preferred thing for the OOM to kill; it's annoying
<paulg>
I was talking this over with our local version of halstead here - what size of swap to configure - I tend to just add a small amount of swap (1G) so unused crap can be evicted, but with no intention for it to be in active use during a build - and we were wondering if this creates a pathologically bad case that is worse than having no swap at all once you are at 90% mem usage...
<paulg>
Kind of like having the Autobahn populated with 100m of gravel washboard every kilometre...
Schlumpf has quit [Quit: Client closed]
<rfs613>
paulg: I guess it is just certain packages causing problems? I don't have any issues with needing swap in my builds... 16 jobs running, 32G of RAM total, rarely see more than a few GBs in use during build.
<paulg>
rfs613, it depends if your build uses libsrvg - which in turn triggers rust and cargo native ; which largely stall a 16G machine and guaranteed OOM an 8G machine.
<paulg>
the theory is that *if* you don't try and build anything else while building rust, cargo .... then these "low ram" machines might be able to be used for another couple years by Joe Average out there.
<rfs613>
"Librsvg aims to be a low-footprint library [...]" -- so I guess they have a different definition of low footprint... or maybe they ignore the build aspect, and just mean runtime.
<paulg>
yea - for sure build vs. runtime. As an old fart who has been using linux since the early 1990s, I find the RSS number of rust while watching a build just mind boggling.
<paulg>
pretty sure it must be trying to compute the number of stars in the universe or something as part of the optimizer....
<rfs613>
so, after they finish rewriting everything in Rust, they only problem will be there's not enough ram or CPU in the planet to build it ;P
<paulg>
pretty much.
<paulg>
hopefully if the thing ever gets traction then some attention will turn from making it work to making it suck less.
spyre has joined #yocto
<spyre>
Hi cool people. Long shot but, anybody has any information on using u-boot on the phycore-am335x?
<rfs613>
spyre: don't have one myself, but looking at u-boot source, there seems to be a .dtsi file for it, and also MAINTAINERS has entry
<rfs613>
seems it is a SOM and it's used on some carriers, "regor" and "wega", which look like they are supported.
<spyre>
Oh okay, I see it! I think I can work with that (I use a different carrier atm). I'll probably have to write a recipe for it, right?
<rfs613>
spyre: well there are already plenty of recipes for u-boot, including in poky and in meta-ti. So probably only need to tweak it.
Etheryon has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rfs613>
spyre: but you should probably first tryi building u-boot and getting it working, manually (outside of yocto). Find out if you need to modify u-boot sources, etc. Once you have that, integrating it into yocto build is a separate step.
<spyre>
rfs613: oh okay, I see it. I think the dots connected in my head now :) I'll see if I can get this to work (and try to upstream it as well, if it does). Thanks a lot for the pointers.
spyre has quit [Ping timeout: 256 seconds]
kevinrowland has joined #yocto
dtometzki has joined #yocto
<kevinrowland>
Hello folks. Curious about this bit from the mega manual regarding `IMAGE_FSTYPES`: "Due to the way the OpenEmbedded build system processes this variable, you cannot update its contents by using _append or _prepend. You must use the += operator to add one or more options to the IMAGE_FSTYPES variable." I've got a vendor layer that uses `?=` to
<kevinrowland>
assign to `IMAGE_FSTYPES`, so when I use `+=` in my `local.conf` the vendor changes aren't applied on top of my `local.conf` changes. I _can_ use `+=` in my own machine conf and that works fine because it's applied after the vendor layer. Can someone enlighten me as to why we can't use _append though? Is it because the `IMAGECLASSES`
<kevinrowland>
definitions at the top of `image.bbclass` use `bb.utils.contains(IMAGE_FSTYPES, ...)` and so the `IMAGE_FSTYPES` variable can't use late-binding / late-expansion?
rfuentess has quit [Remote host closed the connection]
<vmeson>
paulg: thanks. As RP mentioned, the problem with loadavg limiting is that it's not updated quickly. We plan to use /prod/pressure info when it's there in newer kernels.
sstiller has quit [Quit: Leaving]
mrybczyn has quit [Quit: Client closed]
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
nateglims has quit [Quit: Client closed]
florian has quit [Quit: Ex-Chat]
tnovotny has quit [Quit: Leaving]
<kevinrowland>
My IRC client disconnected me.. did anyone respond to my question about `IMAGE_FSTYPES` above? :)