<khem>
zeddii: why was v6.1.20 reverted to v5.15.103 on yocto-6.1 branch
<khem>
fury: blank screen is not expected for graphical images like sato images. I dont have a rpi0w locally so I personally do not test it not for graphics so I relent there might be a bug lurking something like wrong device tree being used etc. try core-image-base or some other console image first and see if you get login on serial console
goliath has quit [Quit: SIGSEGV]
brazuca has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
seninha has quit [Quit: Leaving]
sakoman has joined #yocto
xmn has quit [Quit: xmn]
vmeson has quit [Ping timeout: 246 seconds]
vmeson has joined #yocto
Guest2465 has joined #yocto
<Guest2465>
hey team, i had a quick question about this video: https://youtu.be/u1rzYRz83kc?t=1781 specifically, why did the program not work when compiled with c++? I ask because I'm getting the same errors on my board
<paulg>
khem, yes that does look suspicious. $2 says it was a rogue script.
<paulg>
I just checked the yocto-5.15 branch to see if it contained v6.1 version. :-P It looks ok.
<khem>
Guest2465: its because your target is missing C++ runtime library
<khem>
when you cross-compile the program the SDK has it and links it as it has to. But making the runtime available on image is also needed. Other option is to do static linking
<khem>
but static linking you have to know what the limitation might be e.g. exceptions etc. might not work
<khem>
easiest is to install libstdc++ into image
<khem>
maybe IMAGE_INSTALL += "libstdc++" would do it
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
Thorn has joined #yocto
alessioigor has quit [Remote host closed the connection]
<barath>
have people tried using uninative + runqemu & co before? it seems like things like tunctl are built natively in yocto but then not called such that they use uninative?
alessioigor has joined #yocto
brazuca has quit [Quit: Client closed]
zpfvo has joined #yocto
<RP>
khem: sorry, when I last used that it was applied unconditionally, which did frustrate me a bit at the time
Schlumpf has joined #yocto
pope has joined #yocto
<pope>
Hello everyone, can someone tell me where I've to configure the earlyprintk option for my kernel? I try to debug a kernel that doesn't seem to boot. Can I directly do this from uboot or do I have to re-compile the kernel?
brazuca has joined #yocto
<landgraf>
pope: you may want to take a look into boot.scr
<pope>
But speaking of the boot.scr, is yocto creating this or is this already pre-built with the uboot that is provided? Cause I couldn't find a raw boot.txt file anywhere
<landgraf>
pope: it most likely was created by buildsystem
<pope>
Okay, content of boot.scr is not what I expected, I might could need some help here :/
<landgraf>
pope: raw boot.scr is called boot.source usualy
<pope>
My problem is, if I boot from mmc, everything works fine. I try to boot from tftp instead but then the kernel isn't booting
<pope>
It seems like this boot.scr provides the boot instructions to load the image from mmc and the boot the kernel, correct?
<pope>
So if I load the kernel "manually" and then execute the booti command, this script never gets executed. How can I add the bootargs in that case? And what does "fdt get value bootargs /chosen bootargs" do?
<landgraf>
pope: you can point uboot to tftp server
<landgraf>
pope: ignore xen part, and read only uboot/tftp related one
<pope>
Okay I'll do, but getting the image from tftp is not the problem... at least I think so
<landgraf>
pope: there's bootargs example too (iirc you needed to specify it)
<pope>
reading through it
<landgraf>
pope: Ctrl-F boot2.scr
<pope>
May I ask you some probably very basic questions regarding this procedure? :/
Guest18 has joined #yocto
<pope>
So it says in config.txt the kernel=u-boot.img should be set. I assume this is because the first stage bootloader uses this to figure out what to boot in this injects u-boot instead of the kernel, right? But in my current config.txt I don't have anything set for kernel, so from where does the information come to boot into uboot?
GillesM has quit [Quit: Leaving]
AdrianF has joined #yocto
<landgraf>
pope: dunno. from the firmware? you know your hardware better than I do =)
<pope>
I just find it difficult to understand the detailed boot process and cannot find the appopriate information to explain it...
<pope>
For example, on the sd card I have a file Image and a file kernel8.img, can you tell me what those are? I'd assume kernel8.img is the kernel, but when uboot loads the kernel it actually load Image
frieder has joined #yocto
<pope>
My problem is that I read so many tutorials with different instructions that I need to go one step back and actually try to understand the process... but that's difficult with the given documentation :)
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
<landgraf>
pope: been there few weeks ago...
brazuca has joined #yocto
<pope>
landgraf: How did you get out? :)
<pope>
Or what even more confuses me, I don't have a uboot.bin on my sdcard...
ptsneves has joined #yocto
<landgraf>
pope: you have to download one. read the article carefully
<landgraf>
pope: or build one using meta-raspberrypi
AKN has quit [Ping timeout: 240 seconds]
<landgraf>
and rpi3 may differ from rpi4
<landgraf>
so just read documentation and/or recipes in the mentioned meta-raspberrypi
vladest has quit [Ping timeout: 240 seconds]
<pope>
I did that, as mentioned, regular booting works just fine. It's when I want to step outside the box when it starts to get complicated :)
<pope>
But I have the feeling it shouldn't be, just difficult to find the right information. E.g. why do I get no Image but Image.bin when running bitbake, and it this the correct kernel image
AKN has joined #yocto
<landgraf>
pope: KERNEL_IMAGETYPE is the answer
prabhakarlad has joined #yocto
vladest has joined #yocto
vvmeson has joined #yocto
vmeson has quit [Ping timeout: 276 seconds]
vladest has quit [Quit: vladest]
vladest1 has joined #yocto
vladest1 is now known as vladest
florian_kc has joined #yocto
vmeson has joined #yocto
invalidopcode1 has quit [Ping timeout: 240 seconds]
vvmeson has quit [Ping timeout: 240 seconds]
vmeson has quit [Ping timeout: 246 seconds]
vvmeson has joined #yocto
invalidopcode1 has joined #yocto
vmeson has joined #yocto
vvmeson has quit [Ping timeout: 252 seconds]
azcraft has joined #yocto
Guest3669 has joined #yocto
Guest3669 has quit [Quit: Client closed]
GuestXYZ has joined #yocto
<GuestXYZ>
Hi folks. I am trying to debug an issue with a yocto BSP build with sstate cache enabled. The problem I have is that when 'virtual/kernel' is being rebuilt (-c cleanall), out-of-tree modules are not rebuilt. This leads to modules/kernel 'module_layout' CRC mismatch on a running system (kernel conf modversions). I wounder, in a normal vanilla yocto
<GuestXYZ>
case, does rebuilding 'virtual/kernel' triggers rebuild all modules?
<rburton>
GuestXYZ: if you rebuild the image and the image depends on the modules they should be rebuilt
rob_w has joined #yocto
<rburton>
easier reproducer would be bitbake external-module ; change kernel somehow; bitbake external-module: if the second bitbake doesn't do anything then there's a dependency issue and please file a bug
<rburton>
in a vanilla yocto, there are no out-of-tree modules
<GuestXYZ>
Aha, meaning deps going other way round. (I was searching starting from kernel.) I my case, bsp does have some vendor modification and I am trying to understand where it broke.
seninha has joined #yocto
tlwoerner has quit [Read error: Connection reset by peer]
brazuca has quit [Quit: Client closed]
vvmeson has joined #yocto
vmeson has quit [Ping timeout: 276 seconds]
AKN has quit [Ping timeout: 276 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
AKN has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
GuestXYZ has quit [Quit: Client closed]
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
<Ablu[m]>
Are there some scripts that help with automatically parsing a kernel panic, calling addr2line and mapping it to a source line?
seninha has quit [Ping timeout: 240 seconds]
Guest18 has quit [Ping timeout: 260 seconds]
vvmeson is now known as vmeson
<landgraf>
Ablu[m]: crash ?
<Ablu[m]>
landgraf: is that a tool or a question? I am referring to kernel crashes, yes. Is there something that given a yocto environment, finds me all the bits and pieces in order to help with translating the offsets back?
<JPEW>
And the "command" and "foo" aren't consumed in the string format so it errors
<JPEW>
rburton: I'm not sure how it could know
<rburton>
parse the string, look at the types of the arguments. it knows cmd is a tuple of 3 items because it was created two lines above. mypy takes so long it should do something useful!
Thorn has quit [Ping timeout: 240 seconds]
Thorn has joined #yocto
thomasd13 has quit [Ping timeout: 276 seconds]
otavio has quit [Ping timeout: 264 seconds]
otavio has joined #yocto
brazuca has quit [Quit: Client closed]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
diego_r has quit [Ping timeout: 250 seconds]
<pope>
How can I figure out what kernel source yocto is using?
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<JaMa>
pope: bitbake-getvar knows almost everything and is always right
* RP
should ask bitbake-getvar why his buildbot javascript is breaking
<JaMa>
:)
linex[m] has quit [Quit: You have been kicked for being idle]
* landgraf
has too many question to ask bitbake-getvar...
<paulg>
waiting over an hour, and re-downloading the whole turd, just 'cause a one-line CVE was merged -- just insane.
nemik has joined #yocto
<khem>
yeah mesa 23.0.0 is in wedlock with llvm
<paulg>
of course I update master fairly regularly - someone who just parked on say kirkstone and stayed there for a year won't suffer the same pain.
<paulg>
I think RP mentioned to me a developer option which favoured git - I'm sure I saved the info to a text file which I'll never find ever again...
<khem>
275.00 KiB/s is not gonna cut it in modern world 🙂 I am sorry
<paulg>
not much I can do if limited at the server side. In any case, it kinda goes back to sth I've been concerned about before. If you need 48core server with 64+GB RAM and a fat fibre pipe, we've effectively excluded all hobbyist contributions to the project. Which would be unfortunate.
<paulg>
I'm not thrilled when people complain about me trying to remove ancient turds from the kernel, but it is valid input they are still using it. And it can keep some of us more commercially driven folks more honest.
<fury>
khem: i got a serial port hooked up to a pi 0 w, how do i go about checking to see why the desktop isn't showing? matchbox desktop is running according to top
<fury>
here's a full boot log before the login prompt showed
<rburton>
do you even get a pointer, or just nothing?
<rburton>
if X is running correctly you'll get a cursor, even if nothing else is working
<fury>
no pointer, just blank black screen (briefly a text cursor at the top left, but that goes away)
<rburton>
sounds like X is drawing to the wrong hdmi or something
<rburton>
never tried on a pi, can't help more, sorry
<rburton>
if you're not tied to X11 try core-image-weston, might work better
<rburton>
(mainly as its not technology from the 80s)
<fury>
eventually i'll be using neither X nor weston, will be going straight to a Qt EGLFS app, so i don't mind a console for now, as long as all the rest of the stuff i need is there
<paulg>
\dev\ice, if you want to copy random build artifacts onto the target, then you are probably looking at a do_rootfs bbappend in your layer. Should give you a starting point to google from
<rburton>
fury: core-image-base is "just boot to a small login prompt" that isn't too minimal to be hard to use
<\dev\ice>
paulg: thanks
<rburton>
though weston will test the same codepaths you'll be hitting if you're using eglfs
<fury>
sounds good
<fury>
i'll see if the weston image works first
<paulg>
rburton, don't be hatin' on the 80s. :-P X11 and xfree86 carried us through many years.
<rburton>
paulg: don't feed the troll ;)
<paulg>
:)
<rburton>
and they did surprisingly well, but really need to be let out to pasture now
vmeson has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<paulg>
Can't argue that. I've been doing (trying?) that with the kernel for over a decade.