olani_ has quit [Remote host closed the connection]
olani_ has joined #yocto
olani_ has quit [Remote host closed the connection]
ThomasRoos has joined #yocto
leon-anavi has joined #yocto
Kubu_work has joined #yocto
florian has joined #yocto
olani_ has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
xmn has quit [Ping timeout: 246 seconds]
rfuentess has joined #yocto
rber|res has joined #yocto
<rber|res>
Hey - I am playing with the yocto-check-layer tool and it looks like if you change a signature in your layer (e.g. bbappend) your layer fails. Why?
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 246 seconds]
prabhakalad has quit [Quit: Konversation terminated!]
<mcfrisk_>
RP: do the master-next test runs look good? no more failures from systemd uki changes?
<rburton>
mcfrisk_: RP is away this week, i'll dig out the latest -next build shortly and see what broke
<mcfrisk_>
rburton: ok, thanks
ThomasRoos has quit [Quit: Client closed]
Saur_Home17 has joined #yocto
* rob_w
finally back to setup some fancy fresh new toolchains,,, love that part the most
Saur_Home16 has quit [Ping timeout: 256 seconds]
belsirk has joined #yocto
rfuentess has quit [Ping timeout: 260 seconds]
<LetoThe2nd>
rob_w: feeling like android much?
<rob_w>
not in a long time, no
Granjow has joined #yocto
<rob_w>
why ur asking ?
<LetoThe2nd>
rob_w: "fancy toolchains" has basically been the android theme (in our tiny embedded bubble) at OSS+LPC :)
<rob_w>
ah sorry
<LetoThe2nd>
:-)
<rob_w>
i actually love yocto in the positiv way of my wording
<LetoThe2nd>
rob_w: all good!
<Granjow>
Hello again. I'm trying to generate custom GRUB menu entries with LABELS and APPEND, but I need different kernel parameters for different entries. Looking at grub-efi-cfg.bbclass, it looks like this is not possible, and I wonder if either I don't understand it or if there generally is no point in having multiple labels because they would all do the
<Granjow>
same anyway?
<rob_w>
doing the same thing again , sounds generally doubtfull
<Granjow>
Follow-up question is: how do I create a GRUB configuration with different menu entries AND different kernel parameters? Do I have to change grub-efi-cfg.bbclass, or is there a different way?
<rob_w>
Granjow, maybe check how poky/meta/recipes-bsp/grub/grub-bootconf_1.00.bb does it and bbappend to that ?
<Granjow>
rob_w: It does an inherit on grub-efi-cfg.bbclass, and from what I know, I cannot un-inherit and I cannot override the .bbclass unless I patch poky directly, but I need to modify the .bbclass to fix it?
<rob_w>
what i ses is that grub-bootconf is to create a grub.cfg , if that isnt what u want
<Granjow>
rob_w: It does, but it does not generate it in a useful way
<Granjow>
It can generate multiple entries, but they are all the same except for the name, which is useless
<qschulz>
tlwoerner: ah, well... starting gst-launch with video decoding on weston in scarthgap crashes with a segfault
<mcfrisk_>
Granjow: I know the pain, had to patch grub-efi quite heavily to do what we wanted.
<mcfrisk_>
not sure if adding extra boot entries with different kernel command lines is any easier with systemd-boot
starblue1 has quit [Ping timeout: 260 seconds]
starblue1 has joined #yocto
Ad0 has quit [Ping timeout: 260 seconds]
goliath has quit [Quit: SIGSEGV]
rber|res has quit [Remote host closed the connection]
Piraty_ is now known as Piraty
sstiller has joined #yocto
Ad0 has joined #yocto
kalj has joined #yocto
belsirk is now known as rfuentess
<Granjow>
mcfrisk_: Thank you! Gives me some inspiration! And maybe I'll send a patch for poky …
Granjow has quit [Quit: Client closed]
Granjow has joined #yocto
Saur_Home17 has quit [Quit: Client closed]
Saur_Home17 has joined #yocto
sstiller has quit [Quit: Leaving]
<qschulz>
does anyone else have atrocious git clone download speed for linux-yocto?
<qschulz>
i'm at 26kbps
<qschulz>
kBps sorry
<Granjow>
qschulz: I get 11 MB/s when running it now
<qschulz>
Granjow: which timezone/continent are you? I just restarted it and it's still 32KBps from Europe
<qschulz>
are you in :)
mbulut_ has quit [Ping timeout: 244 seconds]
mbulut_ has joined #yocto
<qschulz>
Granjow: mmmmmm, 30MBps from my office's server
<Granjow>
qschulz: Switzerland
kalj has quit [Ping timeout: 256 seconds]
rber|res has joined #yocto
* qschulz
shrugs
<Granjow>
I'm trying to install a yocto from USB stick, but as soon as the live system boots, it finds neither keyboard nor the usb stick it booted from. How can I debug this? The serial console is not of much help without a keyboard
<rob_w>
where would i hack to get DL_DIR include the downloads/ dir again when i use file:// SRC_URIs ? scarthgap seems to miss that path on those
xmn has joined #yocto
<qschulz>
rob_w: i don't understand what you're trying to do, can you provide the actual thing you want to do?
<qschulz>
Granjow: very likely a kernel issue? maybe you have built the USB drivers as modules and they aren't installed in the initramfs/rootfs?
<rob_w>
on kirkstone, i had me recipes use a simple SRC_URI like file://my.tar.bz2 and just have that package in my build/download/ dir
<rob_w>
scarthgap seems to only include meta-layer paths for my tar.bz2 and miss out the download dir
Granjow has quit [Quit: Client closed]
Granjow has joined #yocto
<qschulz>
there usually is a .done file associated with every file in DL_DIR
<qschulz>
it contains some data (463B according to ls)
Minvera has joined #yocto
<Granjow>
qschulz: We actually disabled some USB_XHCI features in the kernel to support the Siemens 227E, just testing if that broke USB on the new hardware. How can I check if the USB drivers are in initramfs, can I just extract the initrd file and see it there?
<qschulz>
Granjow: you can check with lsmod if some modules are loaded
<Granjow>
When I look at usr/lib/modules/6.6.30-intel-pk-standard/modules.builtin in the initrd, there are some usb drivers, not sure if that is relevant and if it is, which one is the right one
<qschulz>
Granjow: I don't think the modules are supposed to be in /usr/lib rather in /lib
<Granjow>
qschulz: how can I check that … without keyboard … ok, I'll just put it into the 80-setup-live which runs in the boot phase
<qschulz>
Granjow: ssh? serial?
<Granjow>
qschulz: I dont have a serial interface, and it stops at “waiting for removable media”
<Granjow>
so no IP and ssh yet
<Granjow>
lib/modules/6.6.30-intel-pk-standard/modules.builtin also contains some usb drivers, again no idea what they are good for :)
<qschulz>
Granjow: won't be able to tell myself either :)
ecdhe has quit [Ping timeout: 276 seconds]
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
<rburton>
Granjow: definitely you either don't have an initrd, you're kernel isn't using the initrd, or the initrd is missing a load of modules. if you're really unlucky you've managed to build an initrd that can't load modules, master was like that for a few weeks but is fixed now.
goliath has joined #yocto
<Granjow>
rburton: I'm on poky scarthgap-5.0.3, was it affected as well? I think the kernel is using the initrd, because I can extract it with unmkinitramfs on my host and there is a script in /init.d/ which I modified, and the modified version is also started when booting from USB stick.
<rburton>
the easy fix is to just put the needed drivers into the kernel instead of as modules
<Granjow>
I have almost no clue about kernel modules unfortunately, can I check if it fails loading modules and how do I generally know which module I would need?
<Granjow>
Ok :) how do I know which drivers I need?
<Granjow>
My new image is about to complete its build, so I can add an lsmod in the startup file, and if it is not too long, I can still see it on the screen
<rburton>
an actual serial port is usually easier than usb if your board has one of those
<Granjow>
Using Siemens BX-21A, 3 Ethernet ports, but no serial port :(
mbulut_ has quit [Ping timeout: 248 seconds]
<Granjow>
Oh. Cool. It was the drivers we disabled for the old hardware which are now required for this hardware. The image I just built includes these again. It boots so much!
Xagen has joined #yocto
<Granjow>
Though, it does not detect any of the 3 ethernet adapters, so I anyway have to look into kernel drivers :D
<rburton>
if your hardware vendor doesn't provide a list of all the hardware and the kernel options they need to work then ask them for that list
<rburton>
i was so pleased with i found a board that actually had that in the hardware overview
<Granjow>
rburton: That sounds like something that would make my life much easier in that regard. Will do!
zpfvo has quit [Remote host closed the connection]
<qschulz>
rburton: people complain about Device Tree but at least I have a way of figuring out what kind of drivers I need based on the compatibles :)
<qschulz>
wondering if there's something similar for the ACPI world
<rburton>
it would be nice
<qschulz>
(especially since there seems to be Aarch64 systems now support ACPI?
<qschulz>
supporting*
<rburton>
some, yeah
<rburton>
has anyone written a tool to scan a devicetree and automatically list the modules that match?
<qschulz>
rburton: likely
<qschulz>
I have one of my thousands open tabs which explains how they added runtime checks for driver probing based on device tree
<qschulz>
collabora or linaro folks are working on this
<Granjow>
Just to still understand the approach. There is a manual which says Marwell 88E1512 is used. According to $searchengine it is spelled Marvell and not Marwell. There is e.g. https://github.com/torvalds/linux/blob/master/drivers/net/phy/marvell.c and I found out that there is a kernel configuration reference which lists marvell drivers:
<rburton>
qschulz: i also want to glue the module metadata that lists the firmware it loads into package dependencies, so if you install a kernel module it pulls in the firmware automatically
<rburton>
(does need rewriting linux-firmware first though)
<qschulz>
Granjow: it is possible your PHY simply isn't supported yet
<qschulz>
though.... if marvell have done their job properly and it is compliant with one of the ieee standards for Ethernet PHYs, the generic driver could handle it
guest92 has joined #yocto
<qschulz>
if you want more features that aren't part of the standard, or it simply doesn't work, then you'll need driver support
<qschulz>
try to figure out the ID of the PHY through mii/mdio tools
<qschulz>
or if you have access to some datasheet you can get it from there
guest92 has quit [Killed (ozone (No Spam))]
<qschulz>
Granjow: seems like your PHY could be compatible with the 88E1510
<qschulz>
they don't seem to say anything about a different identifier for the PHYs in that datasheet
<rburton>
love that its 2024 and people are still having to google and read data sheets to figure out if hardware is supported on linux and if so what the modules to use are
<qschulz>
rburton: i'm actually surprised there was a publicly available datasheet for a marvell PHY )
<qschulz>
:)
<qschulz>
rburton: let's take a moment to thank vendors to provide job security to the whole industry
<Granjow>
qschulz: Cool, will try! So if the PHY identifier is identical, that means the driver should be compatible because hardware detection is done based on this identifier?
guest92 has quit [Ping timeout: 256 seconds]
<qschulz>
Granjow: correct, it's reading the PHY Identifier as part of the standard, applying a mask (defined in the driver) and if it matches, it uses that driver
<rber|res>
is there any good reason why we pull tarballs via http and not https in some of the recipes?
<qschulz>
Granjow: interesting is what happens when you have two drivers matching :D
guest92 has joined #yocto
<Granjow>
qschulz: lol – what happens? Random? Alphabetic? Nuclear Fusion?
<qschulz>
Granjow: I actually do not know, I hit this once when migrating support of one PHY to another driver but didn't investigate
<Granjow>
ok :)
<qschulz>
considering the probe order isn't guaranteed to be deterministic, I would assume that the PHY drivers registering in the subsystem are not necessarily in a guaranteed order and thus, chaos ensues
<qschulz>
one boot one driver, another boot another driver (not necessarily 50/50 :) )
<qschulz>
(i have nothing to back this claim though)
<Granjow>
Though, if both drivers work, would it really be an issue? :)
mbulut_ has joined #yocto
<qschulz>
Granjow: very unlikely they both work, at least the same way with the same set of features, bugs, etc...
<NishanthMenon>
^^ I mean to work on yocto-kernel-cache
<Granjow>
qschulz and rburton, thanks for your help! Will try the new driver on Friday, kernel ignores my configuration today :)
Granjow has quit [Quit: Granjow]
gspbirel1 has joined #yocto
gspbirel1 is now known as gspbirel56
ecdhe has joined #yocto
Saur_Home21 has joined #yocto
rfuentess has quit [Remote host closed the connection]
ecdhe__ has joined #yocto
Saur_Home17 has quit [Ping timeout: 256 seconds]
astlep5504018066 has joined #yocto
leon-anavi has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
ecdhe has quit [Ping timeout: 246 seconds]
ecdhe__ has quit [Ping timeout: 252 seconds]
Saur_Home12 has joined #yocto
druppy has joined #yocto
Saur_Home21 has quit [Ping timeout: 256 seconds]
CrazyGecko has joined #yocto
mbulut_ has quit [Ping timeout: 276 seconds]
Kubu_work has quit [Quit: Leaving.]
Articulus has quit [Quit: Leaving]
jmd has joined #yocto
druppy has quit [Ping timeout: 252 seconds]
<qschulz>
rburton: re: tf-a recipe before v2.12 is released... shouldn't we just add a _git.bb recipe in meta-arm?
<rburton>
maaaybe
<qschulz>
if yes, AUTOREV, no AUTOREV?
<rburton>
not autorev by default
<qschulz>
I know you mentioned devupstream
<qschulz>
but I don't see it applying here
<khem>
autorev throws whole build under the bus
<qschulz>
well... actually, probably for the lts branches it could make sense
<qschulz>
khem: care to give a few more bits on that?
<qschulz>
for context, there's RK356x and RK3588 (initial) support in TF-A
<qschulz>
no release yet, and I know migrating meta-rockchip to it will take some time as I need to rework a few recipes with a few assumptions we made to make things easy
<qschulz>
so I want to test before the v2.12 is released
<qschulz>
or at least have the opportunity to do so
<qschulz>
I imagine i'm not the only one who would ever want to build a non-release build of TF-A to prepare for stuff
<qschulz>
(after all, TF-A is releasing like twice a year?)
<rburton>
yeah, i'd like to be able to throw a 'git head' build in our CI occasionally
<qschulz>
so, instead of keeping this on my disk, I asked rburton if he was open to contributions on meta-arm :)
<qschulz>
rburton: I guess we could have a _git which is stable and a devupstream in _git that is autorev?
<khem>
do it via a config metadata
<khem>
it will be parsed and bitbake will puke if it can not access
<rburton>
yeah i think even as a default in devupstream it will still cause a network op
<qschulz>
ah, that I didn't know... mmm that's bad
<rburton>
but you can set a sha and if you want autorev its easily changed from local.conf or similar
<rburton>
paging jonmason as we're talking about meta-arm :)
reboji has joined #yocto
<jonmason>
if there are going to be two recipes that are _git, one with and one without autorev, then why not keep a versioned one and do the devupstream in the git.bb?
<qschulz>
not sure to follow, are you suggesting renaming v2.11 recipe into _git and have devupstream in there?
<reboji>
hii, i tried adding libgpiod to my yocto build, and i have the (libgpiod) v2.1.2, but when i try to use gpioset and so, this message comes up: gpioset: invalid line value: 'gpiochip2' . does anyone know if I have to add another package or change version?
<jonmason>
qschulz: your proposal was " _git which is stable and a devupstream in _git that is autorev", that is 2 recipes, right?
<qschulz>
jonmason: one file but two recipes from bitbake PoV yes
rob_w has quit [Quit: Leaving]
<jonmason>
Okay, I think I'm missing something fundamental
<jonmason>
So, this seems to be a problem of everything git based
<jonmason>
should they all be _git.bb's, so that people can run the latest code?
<jonmason>
said differently, why is this something that is unique to tfa?
<qschulz>
jonmason: recipe_version.bb with _version being _git isn't a requirement
<qschulz>
I would say it makes sense when a project doesn't go releases and is versioned by git
<qschulz>
or if you're in between versions
<jonmason>
I understand that, but if everything is "free float" that is git, even if it's versioned, then why not switch to it
<qschulz>
we already have multiple recipes in meta-arm for tf-a, the lts variant and the latest version
<qschulz>
jonmason: failing to get the argument but it's getting late so maybe a case of brainfarting :)
<jonmason>
I think the disconnect is on my end
<qschulz>
considering we already have 2 versions of the same recipe, adding a third one and handling all of this in one recipe file seems like some very difficult to maintain recipe
<qschulz>
and **I** wouldn't even know how to do this properly
<jonmason>
meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.10.4.bb is really just SHAs with a common inc file
<qschulz>
(there's devupstream BBCLASSEXTEND but even that isn't that entirely clear to me how to properly make use of it, seems to be very permissive)
<qschulz>
jonmason: correct, same for 2.11.0
<jonmason>
so the maintenance of multiple isn't hard for versioned
<jonmason>
and you want a 3rd that is a _git.bb?
<qschulz>
I want to be able to build something that isn't a release
<jonmason>
and devtool is too much?
<jonmason>
like, you want it in your layer or something?
<jonmason>
and bbappend with SHA is not good?
<qschulz>
ok I see :)
<jonmason>
again, I'm probably just not understanding
<qschulz>
now we can start talking since I understood your point :)
<qschulz>
so, it essentially boils down to "i'll do it once, does anyone want that in some layer or do I just keep this to myself"
<jonmason>
gotcha, you are already going to do this...
<qschulz>
AND, I assume meta-arm **MIGHT** have some interest in automatically testing before the release happens
<qschulz>
hence why I was suggesting this to rburton during the YP Dev Day last week
<jonmason>
he tells me nothing
<jonmason>
just makes fun of my new flowing locks of hair
<qschulz>
well, he paged you just now ;) :D
<qschulz>
rburton: how dare you
<jonmason>
oh crap, oe happy hour
<qschulz>
will sign off then, let's discuss some more another day :)
<jonmason>
naa, just joining now
<jonmason>
I mean, I'd be happy to see the patch and am not necessarily against it
Kubu_work has joined #yocto
<qschulz>
it's not because someone does some work that it's valuable to other people though ;)
<qschulz>
and I also understand that adding one more recipe (or a variant of it) is adding some more work to already busy maintainers ;)