<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?