Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sugoi has joined #yocto
sugoi has quit [Ping timeout: 252 seconds]
jclsn has quit [Ping timeout: 248 seconds]
jclsn has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
ablu has quit [Ping timeout: 245 seconds]
ablu has joined #yocto
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
sugoi has joined #yocto
sugoi1 has joined #yocto
sugoi has quit [Ping timeout: 265 seconds]
sugoi1 is now known as sugoi
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 252 seconds]
Xagen has joined #yocto
steelswords9 has quit [Read error: Connection reset by peer]
steelswords9 has joined #yocto
sugoi has quit [Ping timeout: 265 seconds]
sugoi has joined #yocto
amitk has joined #yocto
sugoi1 has joined #yocto
sugoi has quit [Ping timeout: 248 seconds]
sugoi1 is now known as sugoi
jmd has joined #yocto
sugoi has quit [Ping timeout: 248 seconds]
sugoi has joined #yocto
sugoi has quit [Ping timeout: 252 seconds]
pbsds30 has joined #yocto
pbsds3 has quit [Ping timeout: 276 seconds]
pbsds30 is now known as pbsds3
vThor has quit [Excess Flood]
vThor has joined #yocto
vThor has quit [Changing host]
vThor has joined #yocto
CrazyGecko has joined #yocto
vthor_ has joined #yocto
jmd has quit [Remote host closed the connection]
vThor has quit [Ping timeout: 246 seconds]
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
Saur_Home4 has quit [Quit: Client closed]
Saur_Home4 has joined #yocto
rfuentess has joined #yocto
leon-anavi has joined #yocto
Vonter has quit [Ping timeout: 272 seconds]
vthor_ is now known as vthor
Vonter has joined #yocto
vthor has quit [Quit: kill -9 $pid]
vthor has joined #yocto
Kubu_work has joined #yocto
DixitP has joined #yocto
xmn has quit [Ping timeout: 264 seconds]
Granjow has joined #yocto
Vonter has quit [Quit: WeeChat 4.4.2]
xmn has joined #yocto
enok has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
sugoi has joined #yocto
enok has quit [Ping timeout: 252 seconds]
sugoi has quit [Ping timeout: 265 seconds]
xmn has joined #yocto
xmn has quit [Client Quit]
Vonter has joined #yocto
prabhakalad has joined #yocto
florian has joined #yocto
enok has joined #yocto
enok has quit [Ping timeout: 265 seconds]
florian_kc has joined #yocto
alperak has joined #yocto
rfuentess has quit [Remote host closed the connection]
ThomasRoos has joined #yocto
<ThomasRoos>
Hi, any idea how to mask a image if a layer is not present. Eg. meta-virtualization? Cause bitbake will complain when scanning this image that it does not know about "inherit image-oci"
rfuentess has joined #yocto
<jdiez>
i had an idea for alleviating cross-compiling difficulties with complex applications based on ros2: is it possible to build the application inside an $TARGET_ARCH container, export the filesystem, and create a yocto package that puts the container chroot in a directory that I choose?
<jdiez>
I mean, I guess that is possible - my question is if someone has done something like this before and whether it is a good idea in general or not
Saur_Home4 has quit [Quit: Client closed]
mbulut_ has joined #yocto
Saur_Home4 has joined #yocto
enok has joined #yocto
belsirk has joined #yocto
rfuentess has quit [Ping timeout: 264 seconds]
belsirk is now known as rfuentess
<ThomasRoos>
guess it is something like: BBMASK:append = " ${@bb.utils.contains('BBFILE_COLLECTIONS', 'virtualization-layer', '', 'xxx-image.bb', d)}"
ThomasRoos has quit [Quit: Client closed]
<DixitP>
Hi, If I want to submit patches 1) for a recipe(resides in poky/meta/) and 2) its source code(hosted separately on the git.yoctoproject.org. Which mailing list should I send out the patches on?
<qschulz>
DixitP: poky is a collection of layers, coming from other git repos
<rburton>
DixitP: patches for the panel, blimey :) yocto-patches@lists.yoctoproject.org and use --subject-prefix to put matchbox-panel-2 in the subject. thanks!
<qschulz>
DixitP: would be nice if you could also send another patch to update the README to add this information so people know how to contribute in the future :)
<Granjow>
I managed to add Marvell support for the marvell network adapter in my image, only as a module (in-kernel somehow did not work), I can load it with modprobe, but it just loads, shouldn't it also detect the ethernet hardware at that time, or is that only happening on boot time?
belsirk has joined #yocto
<qschulz>
Granjow: an Ethernet PHY is always behind an Ethernet MAC, on some MDIO bus
<qschulz>
so you need support for the Ethernet MAC, as well as the MDIO bus
<qschulz>
often they come in pair from the same driver, but not necessarily (e.g. it could be MDIO via GPIO bit banging)
<qschulz>
so check that your Ethernet MAC controller is enabled and loaded
* Granjow
goes using $searchengine to understand these terms
rfuentess has quit [Ping timeout: 252 seconds]
<DixitP>
qschulz: Sure! Will do.
belsirk is now known as rfuentess
<DixitP>
qschulz: Any specific README or the one which is there under poky?
<qschulz>
DixitP: no, the README in matchbox-panel2 :)
<qschulz>
DixitP: we don't really want to document how to contribute to source code of recipes within a layer, in the layer's README
<qschulz>
Granjow: packets are flowing from CPU, to MAC, to PHY, to the connector and the other way
<qschulz>
they are exchanged between the MAC and PHY using MII, RMII, RGMII or SGMII, etc....
<qschulz>
the configuration of the PHY goes through MDIO
<qschulz>
the MAC is basically a HW-specialized block for network packets
<qschulz>
the PHY is just a fancy ADC for Ethernet stuff I guess
<Granjow>
Thanks. I was first a bit confused whether these relate to separate hardware components. But they don't, right? There is the physical adapter with the RJ45 plug, and the marvell driver is there to tell it to send or receive a packet, then MAC does the whole MAC part in the running Linux system and decides when to send, and MII etc. are interfaces
<Granjow>
because nobody can agree on one standard?
<Granjow>
* interfaces so the probably rather generic MAC can use any PHY driver
<Granjow>
And now I have to figure out somehow which other modules I need so I can actually internet with the Linux
alperak has quit [Quit: Connection closed for inactivity]
<qschulz>
Granjow: they are separate hardware components in terms of IP (most of the time, maybe there are combo-chips with an Ethernet MAC+PHY mixed but that's very likely very niche)
<qschulz>
Granjow: though, you can have systems where the different IPs are in the same silion
<qschulz>
Rockchip for example have some SoCs with a MAC and PHY in it (different IP blocks, but they are inside the SoC silicon)
<qschulz>
the RJ45 plug very likely does nothing more than getting the signals from your cable on the PCB with fancy LEDs
<qschulz>
the LEDs being handled by the Ethernet PHY
<qschulz>
which is another component
<qschulz>
then the PHY translates those signals from analog to digital for MAC consumption over xMII
<qschulz>
essentially, we started with MII and then more and more features and bandwidth was necessary
dmoseley has joined #yocto
<qschulz>
and that wouldn't fit with MII anymore, so then you got RMII for less signals to route (IIRC), RGMII for higher bandwidths, etc...
<qschulz>
I won't go into how this works with fiber optic cables because I don't know
dmoseley_ has quit [Ping timeout: 244 seconds]
<qschulz>
as far as i've been told, things are easier with very very fast fiber optic
guest92 has joined #yocto
<qschulz>
the PHYs are getting smarter too because you can now inject some info into packets (c.f. PTP and hardware time stamping) and the likes
<qschulz>
it's been a while since I worked with Ethernet MACs and PHYs so not sure everything is correct or up-to-date
<guest92>
[ 1.442470] imx-sdma 30bd0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 I am getting this error with yocto scarpthead and kernel 6.1.36. In kernel recipe I hava a task to add firmware
vmeson has quit [Quit: Konversation terminated!]
<guest92>
cp -f ${WORKDIR}/firmware/sdma-imx7d.bin ${WORKDIR}/git/firmware/imx/sdma/sdma-imx7d.bin this is being done in kernel recipe. Does anyone have any clue?
gvmeson has joined #yocto
<qschulz>
guest92: you probably want to install linux-firmware-imx-sdma-imx7d ?
<DixitP>
qschulz: Got it. Will update matchbox-panel-2's README.
<Granjow>
qschulz: Oh, nice! I didn't know the hardware itself does MAC, but it makes sense, probably removes a lot of load and timing requirements from the host system. However then I don't get where MII and co. come into play, because if it is two hardware components talking to each other, why would the kernel have to know about it and why do I need a
<Granjow>
driver for it?
<guest92>
qschulz yes exactly
<qschulz>
guest92: if you REALLY want it in the kernel image, that's a different topic though and I wouldn't know how to do it (but you would still probably have your kernel recipe depend on the linux-firmware recipe to have access to the imx7d sdma firwmare from there)
<qschulz>
Granjow: because you may have more than one PHY on a MAC, or more than one Ethernet port on your whole system
<qschulz>
so you want to be able to tell exactly which PHY to configure with which settings
<guest92>
qschulz I don't have any extra linux-fimware recipe. I just have only kernel-recipe in which I have a task to add imx7d sdma
<qschulz>
(e.g. the link speed, autoneg, duplex, etc...)
<qschulz>
guest92: linux-firmware comes from openembedded-core, so except if you're doing bare bitbake (why???) it should be available
<qschulz>
Granjow: you also need to tell the MAC and PHY how to communicate between each other
<qschulz>
Granjow: for example, some PHYs are capable of multiple MII standards... which one are they supposed to use with the MAC, of which they have no prior knowledge
<qschulz>
same for the MAC, it needs to be able to adapt to other PHYs, but it doesn't have prior knowledge either
<qschulz>
so you create links between the two devices, with their respective drivers, and let the kernel configure them via the CPU (where the kernel is running)
<guest92>
qschulz I am not appending openembeded recipe for linux-firmware at all. I have in my bsp kernel recipe in that in task do_unpack I have task do_move_firmware(), which copies firmware files. so it is bit puzzeling
<qschulz>
guest92: I'm telling you that linux-firmware is providing the fw file directly, so there's not necessarily any more need than just adding linux-firmware-imx-sdma-imx7d package to your image recipe via IMAGE_INSTALL for example
<qschulz>
if you want the firmware within the kernel image directly, instead of the more usual location (in the rootfs), then you can still get the firmware from that recipe as a dependency of your kernel and put it in the right place, configure the kernel defconfig to copy the firmware inside the kernel Image
<guest92>
qschulz I understand. Thanks for explaining
<rburton>
guest92: if you've an initramfs then you need to put the firmware in the initramfs too of course
<qschulz>
if you have it in the rootfs, the error message may still appear, and once the driver is being reloaded after the rootfs has been mounted, then it should find it
<qschulz>
may still appear early in boot log*
<guest92>
rburton yes I have initramfs
<rburton>
then the driver is probably being loaded in the initramfs and that doesn't have your firmware in
<guest92>
rburton qschulz I am doing the same step of copying firmware with different kernels 4.19, 6.6.23 and 6.1.36. Having this problem only with kernel 6.136
<qschulz>
guest92: mmmmm, could be a naming issue, I've seen vendor kernels and upstream kernels use different names for the firmware
<qschulz>
and sometimes upstream changes the name of the firmware too (beats me why they do it :) )
alperak has joined #yocto
<qschulz>
rburton: jonmason: do we want to add trusted-firmware-a git variant to the CI? if yes, do we want an AUTOREV variant too? I wouldn';t be able to test though I guess, so it's a bit of a shot in the dark :)
<rburton>
qschulz: i'd really like to have an autorev version fired periodically but don't worry about adding support for that straight away :)
<qschulz>
rburton: git variant built by CI though? or do i just send the new recipe and then you take care of that whenever you have time/interest :) ?
<rburton>
to be honest, the latter is fine
<Granjow>
qschulz: Thanks, I understand it better now. This means that I now have to figure out which MAC they are using in that IPC (the data sheet does not mention it) because Marvell does not care as long as the MAC supports one of their protocols (they support RGMII and SGMII), or maybe ask them (as you already suggested) to just tell me which drivers to
<Granjow>
use?
<qschulz>
Granjow: which SoC are you using?
<qschulz>
The MAC is typically in the SoC, so that would be more a question for your SoC vendor
<qschulz>
the product page says Intel Atom® x6413E
goliath has joined #yocto
<qschulz>
Granjow: you could try to enable all symbols from drivers/net/ethernet/intel/Kconfig and see where this leads you
<qschulz>
Granjow: you could also have a look at the symbols enabled in arch/x86/configs/x86_64_defconfig
<qschulz>
it's probably enabled there
DixitP has quit [Quit: Client closed]
<Granjow>
qschulz: The Atom is the CPU, is the MAC running on the CPU then? Will try enabling the symbols now!
guest92 has quit [Quit: Client closed]
<qschulz>
Granjow: so... If I'm not mistaken, it is kind of a misnomer, what people believe are Intel/AMD CPUs are actually SoCs
<qschulz>
so I would say (have never worked with Intel stuff before) the MAC is integrated inside the SoC but it'sown separate IP in the SoC (like the CPU is its own IP as well)
<Granjow>
IP means what in this context? Integrated Package? Inntellectual Property? :)
<qschulz>
but... there could also be a lot of things handled by the motherboard's chipset as is customary for x86 designs
<qschulz>
Granjow: Intellectual Property in that context
<qschulz>
basically anything immaterial
<qschulz>
the vendors (especially in the ARM world) buy those from big companies (e.g. Synospsys, Imagination, DesignWare, etc...) and integrate those into their SoC design
<qschulz>
and this whole thing results in something material, which I call silicon (maybe wrong term, who knows)
LocutusOfBorg has joined #yocto
<Granjow>
Ok!
<Granjow>
Building now, will I also have to modprobe all these drivers to find out which one is the right one? Would I get a dmesg entry if it can talk to the MAC?
olani- has quit [Remote host closed the connection]
enok has quit [Ping timeout: 252 seconds]
olani has quit [Remote host closed the connection]
olani has joined #yocto
<qschulz>
Granjow: if you build them as modules, you may have to modprobe them, but maybe the autoprobe mechanism will find the appropriate one, I don't know how it works sadly
<qschulz>
Granjow: you don't necessarily have a dmesg entry
<qschulz>
the kernel driver doesn't necessarily print anything
<qschulz>
BUT at some point it will probably print that it detected an Ethernet PHY and the driver it used for it
<Granjow>
Okay, looking forward to that moment! :) Thanks for all your help, I learned a lot today!
<qschulz>
Granjow: come back and let us know when you get that working so we can celebrate with you ;)
<Granjow>
qschulz: I will, either in a few minutes (just installing the image) or next week :)
<Granjow>
So, the marvell module is loaded, but no ethernet yet. That's okay. At least the module is loaded automatically, even though I have no idea where yocto put it :)
<qschulz>
Granjow: it'd probably make sense to contact Siemens at some point so they can assist you or provide you with a defconfig and/or kernel
<Granjow>
Yes, will do!
<qschulz>
I don't know how to find out which HW component is connected where on ACPI-based systems so that's as far as I could help :/
<Granjow>
It helped a lot! :) Thank you so much! (Siemens support portal is offline, so also this will not happen anymore today :D)
Granjow has quit [Quit: thanks!]
Tyaku has joined #yocto
sugoi has joined #yocto
<frosteyes>
rburton: I have send a RFC patch for the SDK issue I mentioned at oss
<qschulz>
frosteyes: the documentation/ patches needs to go through yocto-docs mailing list as a separate patch
Saur_Home4 has quit [Quit: Client closed]
<qschulz>
(but I appreciate there's some doc already :) )
Saur_Home4 has joined #yocto
<frosteyes>
Thanks. I will split the changes in documentation.conf and variables.rst out from the rest, and send to yocto-docs, if the other parts is acceptected.
<qschulz>
yeah, it's an RFC so I don't expect it to be merged directly maybe?
sugoi has quit [Ping timeout: 248 seconds]
<frosteyes>
Let see. I got a problem when I need to upgrade from kirkstone to scarthgap for a project. So was missing this :)
reatmon_ has quit [Remote host closed the connection]
<Tyaku>
Hello, some days ago we talk here about the possibility to make the same image for different boards, without using MACHINE. The idea was to have multiple DTS, to load the good one on startup, depending on a U-Boot variable set during production.
reatmon_ has joined #yocto
<ak77_>
my my, what has broken: "ERROR: adwaita-icon-theme-45.0-r0 do_create_spdx: Cannot find any SPDX file for recipe gdk-pixbuf" all layers on scarthap
<rburton>
frosteyes: thanks!
<qschulz>
Tyaku: if you have a way to detect the product at runtime without depending on something set during production, it's even better :)
<qschulz>
(e.g. an EEPROM, some ADC channel with different value for different boards, etc...)
Saur_Home4 has quit [Quit: Client closed]
Saur_Home4 has joined #yocto
xmn has joined #yocto
drkhsh has quit [Quit: WeeChat 4.4.2]
drkhsh has joined #yocto
rfuentess has quit [Remote host closed the connection]
Scorpi has joined #yocto
<Scorpi>
Hi, my build setup always rebuilds the kernel when running for the first a build environment. What can I do to find the reason for this?
<Scorpi>
s/first/first time/
<qschulz>
Scorpi: bitbake -S diffsigs should help you if I remember correctly
<Scorpi>
qschulz: thanks. Can you point me to documentation how I use this? The options for -S seem to be somewhat high level and not described in the bitbake manual.
<Scorpi>
qschulz: -S printdiff seems to tell me something useful
<qschulz>
i've only used diffsigs and dumpsig :)
<qschulz>
and that was long time ago
CrazyGecko has quit [Ping timeout: 252 seconds]
Saur_Home4 has quit [Quit: Client closed]
Saur_Home4 has joined #yocto
<Scorpi>
qschulz: looks like extended fun with a multiconfig for initramfs
<Scorpi>
qschulz: and if the initramfs was rebuilt, the kernel also needs to be rebuilt with the new initramfs, I assume
<qschulz>
Scorpi: it depends, if it's an initrd yes, if it's an initramfs no
<qschulz>
Scorpi: basically, the initrd is INSIDE the kernel, while the initramfs is just a rootfs stored in RAM that is separate from the kernel (but can be in a fitimage for example)
<Scorpi>
qschulz: initramfs can be both, IMHO
<Scorpi>
qschulz: At least I have a build where the initramfs is part of the kernel image
Minvera has joined #yocto
<qschulz>
if your rootfs is part of the kernel image, it obviously needs to be rebuilt whenever the rootfs changes
<qschulz>
that's the part I wanted to highlight
<qschulz>
if it's not part of it, then there should be no reason for this to happen
jmiehe has joined #yocto
mbulut_ has quit [Ping timeout: 245 seconds]
alperak has quit [Quit: Connection closed for inactivity]
<moto-timo>
qschulz: yeah, my point is out of the box docker and kernel are not working with current docker.scc and meta-virt
<zeddii>
that's not quite true
<zeddii>
I run nightly tests "out of the box"
* zeddii
detects he is in a bad mood and moves off
sugoi has joined #yocto
<khem>
zeddii:its the codee not you :)
<qschulz>
khem: I posted some patches for meta-rockchip and meta-arm to support upstream TF-A on RK356x and RK3588, maybe you want to start a build with clang to catch some issues since I know you "like" catching those
<khem>
heh, I have couple of rockpi's sitting here, I had a reason once to use them more frequently, I would like to checkout the gst h/w accel changes sometime, perhaps the 25th hr of day
<qschulz>
khem: i'll remind you on the 32nd of the month then
<yudjinn>
hey all, seeing an issue where it seems the combination of using `buildhistory` and building `meta-toolchain` on either kirkstone or scarthgap produces a very strange error:
<yudjinn>
```
<yudjinn>
| DEBUG: Executing shell function buildhistory_list_pkg_files
<yudjinn>
| find: ‘[REDACTED]/build/tmp/work/armv8a_tegra-poky-linux/meta-toolchain/1.0/packages-split/*’: No such file or directory
<yudjinn>
| WARNING: exit code 1 from a shell command.
<yudjinn>
```
jrodgers has joined #yocto
jrodgers has quit [Client Quit]
yudjinn has left #yocto [#yocto]
yudjinn has joined #yocto
enok has quit [Ping timeout: 260 seconds]
goliath has quit [Quit: SIGSEGV]
tepperson has joined #yocto
<tepperson>
anybody try to build for nios2 processor? Im getting a problem with the gcc-runtime recipe where "Link tests are not allowed after GCC_NO_EXECUTABLES"
florian_kc is now known as florian
<khem>
hmm its a less tested but it should work
<khem>
tepperson:are you using master ?
<khem>
if you can post config.log files from gcc-runtime build area that can shed some light on the issue