ndec changed the topic of #yocto to: "Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.05) May 17 - 19, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec"
GLumen_ has quit [Ping timeout: 272 seconds]
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
qschulz has quit [Quit: qschulz]
qschulz has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
alex88 has joined #yocto
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
fitzsim has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
Vonter has joined #yocto
kroon has joined #yocto
sakoman has quit [Quit: Leaving.]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
amitk has joined #yocto
kranzo has joined #yocto
thomasd13 has joined #yocto
goliath has joined #yocto
mvlad has joined #yocto
rob_w has joined #yocto
lexano has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
Schlumpf has joined #yocto
frieder has joined #yocto
lexano has joined #yocto
tomzy_0 has joined #yocto
lexano has quit [Ping timeout: 272 seconds]
amahnui1 has joined #yocto
mckoan|away is now known as mckoan
lexano has joined #yocto
rfuentess has joined #yocto
<thomasd13> Good morning, just a short question for debugging an bbclass (metadata_scm.bbclass): https://zerobin.net/?d568b0abec744007#wMEgT1pKNUwk2iqOA1UCW//+AizrV4FlRAFvIbtOSjU=
<thomasd13> It seems, I got an exception, because "rev" is returned as <unknown> which later causes some changed signatures. It is possible to "debug print" this exception for further analysis?
dev1990 has joined #yocto
rfuentess_ has joined #yocto
rfuentess has quit [Ping timeout: 256 seconds]
xmn has quit [Quit: ZZZzzz…]
Schiller has joined #yocto
<qschulz> @all: congrats on the Kirkstone 4.0 release \o/ \o/ \o/
* LetoThe2nd throws confetti
Schiller has quit [Quit: Client closed]
ecdhe_ has quit [Read error: Connection reset by peer]
<michaelo> qschulz: indeed! I'm very impressed. \o/
florian has joined #yocto
<michalkotyla> Hi, I sent a patch to the meta-security exactly like it was described in README to yocto@lists.yoctoproject.org via git send-email, but I do not see it in mailing list topics: https://lists.yoctoproject.org/g/yocto/topics. It needs more time (more than an hour), or patch was rejected automatically for some reason?
<mcfrisk> yay, new LTS, long live the old LTS dunfell! Update from dunfell to kirkstone in preparation...
ecdhe has joined #yocto
<qschulz> michalkotyla: are you subscribed to the mailing list?
<qschulz> michalkotyla: https://lists.yoctoproject.org/g/yocto/ clikc on the "join this group" blue button
<qschulz> michalkotyla: your mail address linked to your account needs to be the same as the one you'll send your patch from
<michalkotyla> qschulz: yes, I subscribe mailing list and it is confirmed here: https://lists.yoctoproject.org/g/yocto/editsub, I see the date when I join. But I have set email delivery as a daily summary - it may be the reason?
<qschulz> michalkotyla: yes that probably is
<qschulz> I don't know, I don't have this enabled :/
<qschulz> well no
<qschulz> it should appear in the archives
<qschulz> did you send the mail before subscribing?
<michalkotyla> qschulz: I response to some topics but via web browswer, at lists.yoctoproject.org. I will try with disabling summary and I send patch again
kanavin has quit [Remote host closed the connection]
selff has joined #yocto
Schiller has joined #yocto
<svuorela> is there some FILES_EXCLUDED like variable to list files explicitly selected to not be installed, or is the only way to rm them after install ?
<Saur[m]> svuorela: There is no FILES_EXCLUDED variable or similar. Your options are to either remove the files in do_install(), or to package them in a separat package that you don't install. The latter is generally the better option as it allows the files to be installed in some other image if wanted, the former option is simpler.
<selff> hi everyone. im trying to set up autossh and sshpass. i was able to successfully install sshpass but not autossh.
<selff> After running the command(autossh), i get an error like this on the log side:
<selff> autossh[809]: /build/tmp/hosttools/ssh: No such file or directory
<selff> I share the rest of the errors as pastebin. https://pastebin.com/2mSAnwAm
<svuorela> Saur[m]: thanks. Will just remove them then. I just felt a bit de ja vu .. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423394 :)
<Saur[m]> selff: Are you building autossh as a native tool? Because the "build/tmp/hosttools/ssh" is the path to ssh within the hosttools directory that bitbake sets up to limit what host tools are available during the build, but I assume that you are using autossh outside the build.
<Saur[m]> Or are you building it for target? Then its configuration tool has incorrectly determined the path to ssh based on the host path, not the target path.
<Saur[m]> You probably need add some option like `--with-ssh-path=${bindir}/ssh` or something like that to `EXTRA_OECONF`.
florian_kc has joined #yocto
<Saur[m]> Or if there is no option to tell the configuration process the path to ssh, then you will have to patch it in.
kanavin has joined #yocto
<rburton> khem: musl-locales is failing for us: /bin/sh: 1: MSGFMT_EXECUTABLE-NOTFOUND: not found
<selff> Saur[m] thank you. i added "EXTRA_OECONF="--with-ssh=/usr/bin/ssh" and problem gone. now i am getting "host key verification" failed error after running the command(autossh). most likely this is not an error related to the yocto side.
Tyaku has joined #yocto
<Tyaku> Hi, We have a project where we need to control a WS2812B RGB led strip from imx8mn. Currently we made some changes in DTS (to enable ecspi2 and use spidev) and we drive it using spidev.
<Tyaku> But, I would like to know if it's possible to enable the SPI from userspace with "sysfs" instead of changing the DTS files ?
<Tyaku> If it's possible, what is the best option and why should we use one instead of other ? (configuring hardware with .dts files or playing with /sys/)
<qschulz> Tyaku: HW description is stored in the dts
<qschulz> what's the issue with creating DTS nodes?
<qschulz> you could patch the devicetree at runtime with device tree overlays runtime application (which is NOT upstream)
<Tyaku> In fact I have a collegue that ask me "i see that peoples configure the SPI using sysfs on raspberry PI, why you are not using it?". In fact in my searchs I found the solution that consist about changing dts files and it works but
<qschulz> Tyaku: RasperryPi folks are doing LOTS of things that are specific to the RPi
<qschulz> I assume RPi distros have support for runtime patching or some weird stuff
<qschulz> if you have some tutorials, I could check quickly
<Tyaku> He gives me this: https://community.silabs.com/s/article/build-an-ezsp-spi-host-application-on-a-raspberry-pi?language=es_MX where it says "Use these example commands to configure SPI GPIOs"
<Tyaku> But what i see is just initialisation of some GPIO not really SPI. (or i'm missing something)
<qschulz> LoL
<qschulz> I assume they're doing SPI transfers with GPIO bitbanging
<Tyaku> LOL
<Tyaku> Maybe not, silicon labs is serious thing.
<Tyaku> But I think they just configure GPIO used for example as chip_select or something like this.
<qschulz> my bad, misread, they configured the host_inst, wake, reset
<qschulz> which is fine IMO
<qschulz> don't see how they would configure the SPI_CS, SPI_MISO/SPI_MOSI/ SPI_SCLK
<qschulz> you'd need to check what the ./build/exe/EZSP_SPI_Host is doing
<qschulz> but again, what's wrong with the DTS node?
<qschulz> also, if you want to use SPI on the device, you'll need the SPI controller to be enabled
<qschulz> (ecspi for you)
<qschulz> so that's a change already
<Tyaku> My collegue was asking me this question to prevent changing dts files if we can do it "at runtime".
<Tyaku> Also I did some changes in the SPI driver (spi-imx.c), for example in "imx51_ecspi_devtype_data" I set "fifo_size" from 64 to 128 because I think it doesn't seems to be configurable (and we need it to transfer more than 64 bytes at once)
<LetoThe2nd> qschulz: guess they just to hard register poking somewhere
<LetoThe2nd> *do, even.
<LetoThe2nd> Tyaku: maybe check, with your colleague if devmem is also involved in his "approach"
<qschulz> please no devmem...
<qschulz> using devmem to avoid modifying a DTS (which you modify so little in the product lifetime...) is a very bad idea
<qschulz> first because it's a security vulnerability
<qschulz> second because it's reinventing the wheel of things that are in the kernel already
<OutBackDingo> PACKAGECONFIG_append_pn-qemu-system-native ughhh here we go again
<OutBackDingo> using the old override syntax. Please convert this layer/metadata
<OutBackDingo> is there an easy way to convert layers
<Tyaku> I just read about devmem because you write it. I like your trolling message :D. It also give me one of the responses: Yes we can configure/control hardware from userland (as we can read/write registers with it). But yeah it's bulls**t
<LetoThe2nd> OutBackDingo: script/contrib/convert-something or close enough it should be.
<Tyaku> Yeah I agree about devmem it's not good practice to use it to configure/control a hardware peripheral. For the reasons that you said.
<Tyaku> So devmem is more for "debug" maybe.
<Tyaku> or to make some tests.
<qschulz> Tyaku: devmem is extremely useful during bringup
<qschulz> or to reverse engineer vendor BSPs you don't have the sources of
<qschulz> but it breaks the security layer of the kernel by allowing to write in any memory address space
<qschulz> (and read!)
<qschulz> you CAN give access to specific memory address regions by using uio IIRC
<qschulz> but still.. requires changes in the DTS :)
<Tyaku> And that's where come another remark/question: To drive my LED strip, i need the MOSI IDLE state as LOW instead of HIGH. This thing is not configured by imx-spi.c (The register "ECSPIx_CONFIGREG" is read in "mx51_ecspi_prepare_message()", then they apply some bitchange according to some options and they write the new register value. But they don't change the field "DATA_CTL")
<Tyaku> So currently I also had to make a change in this function to set the field "DATA_CTL" at the correct value to make sure "MOSI IDLE is LOW for my SPI channel".
<Tyaku> In that case, is devmem a better option to prevent doing changes like that in spi-imx.c file (which is in "tmp/work-shared/imx8mnevk/kernel-source/drivers/spi")
<qschulz> Tyaku: the kernel never ends being updated. Someone finds a usecase that is not covered, they add support
<Tyaku> *And that's where another remark/question comes*
<qschulz> first check that upstream Linux kernel does not support that
<qschulz> otherwise, just write your own patch
<qschulz> this is common practice
<qschulz> almost no one uses a vanilla kernel at first
<Tyaku> Yeah we are new to yocto in my company, we don't really have the "good practices", only peoples with years of experiences have it.
<Tyaku> what is vanilla kernel ?
<Tyaku> I don't understand when you say "the kernel never ends being updated" what do you mean ?
<Saur[m]> A "vanilla kernel" is the kernel source as published on kernel.org by Linus or Greg.
<thomasd13> Has someone else problems with "fatal: unsafe repository *** is owned by someone else" ?
<kanavin> RP: can you save the logs and attach them to the bug?
<kanavin> (or link to the bug)
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<RP> kanavin: the testimage log?
<rburton> thomasd13: that's the new git being 'secure', there are patches heading into the branches to work around it
<rburton> thomasd13: downgrading git is an acceptable workaround in the short-term
<rburton> RP: https://git.yoctoproject.org/poky/tree/documentation/migration-guides/release-notes-4.0.rst?h=kirkstone doesn't appear on the rendered website. what's michael's nick on irc?
<RP> rburton: michaelo
<rburton> thanks
<RP> rburton: how do you mean doesn't appear rendered ?
<rburton> can't find that page on docs.yoctoproject.org anywhere
<rburton> ah it's not on the kirkstone branch, missing at https://docs.yoctoproject.org/4.0/migration-guides/migration-4.0.html
<RP> rburton: this is what I was talking about yesterday and why the main page is at 4.0.999
<rburton> RP: i suspected this was a known thing, but I wasn't paying attention
<RP> rburton: the problem is that I don't get the docs until late and people rightly tag what we tested as release
<rburton> yeah fair
Schiller has quit [Ping timeout: 252 seconds]
<thomasd13> rburton, thanks for that information. I'm just wondering why I am hit by this "feature". I didn't upgrade my local git client?!
<thomasd13> Does oe/bitbake uses their own git instance, which they do update automatically?
<rburton> nope
<rburton> that error really does suggest you upgraded your git recently
<rburton> (or you're using a container which has the new git in)
rfuentess_ is now known as rfuentess
<thomasd13> interesting. My local version is "git version 2.25.1". I think I need to debug that specific do_package task.
<thomasd13> Thanks for that hint, that saves me a lot of time
Schiller has joined #yocto
<rburton> thomasd13: https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9 <-- you're definitely running another git somewhere then
<rburton> thomasd13: maybe you have a recipe with a git-native dependency?
<thomasd13> git-"native" dependency means, a package which requires git on the target system?
<thomasd13> ahhhh
<thomasd13> i try to create the extended pdk. I'm sure there is a git inside it
<rburton> eSDKs most likely ship the git we built
<thomasd13> Task (/home/ewdt/oe/arago/sources/meta-ibg/recipes/images/viop-image.bb:do_populate_sdk_ext. Thats the task. I didn't post that earlier since I assumed that this information is not important
<rburton> surprised it runs the git inside the sdk during building it, as it won't work if the sdk is for a different architecture
selff has quit [Quit: Client closed]
<Schiller> YPAutobuilder first buildstep  (1. Clobber build dir) throws Error: Directory is busy, as i map the Directory into my Docker-Container. I can't really understand it as this shouldn't really be a problem.
olani has joined #yocto
<Schiller> Any suggestions? Is it safe to change the buildstep into just removing the subdirectories?
<thomasd13> The eSDK targets A72 (Arm v8 AARCH64). The git command got invoked by bb.process.run(), so I assume the environment of the bb.process is somehow modified to use a updated version of git
<qschulz> Tyaku: I meant the kernel is endlessly being updated (otherwise you wouldn't get newer versions). It includes fixes but also new features, brought by users who needed them
<thomasd13> When I open a devpyshell for the the image "viop-image" (which I try to build a eSDK for), the output of "pydevshell> bb.process.run('git --version')" is also 2.25.1
<kanavin> RP: thanks I'll see if there are any clues in there I haven't seen yet, but i suspect we can only report upstream and hope they manage to figure it out
<thomasd13> How can I find the root reason, why do_populate_pdk_ext task uses a newer git instance?
rob_w has quit [Remote host closed the connection]
<RP> kanavin: I would love to hear upstream's view on it
<RP> rburton: eSDKs don't work on another arch :(
xmn has joined #yocto
<Schiller> is it possible to remove the build and yocto-auto-helper folders in a meta-x builddirectory during runtime of a build? In the clobberdir script the hole meta-x seems to get removed with no problem but i can't remove subdirectories.
<thomasd13> Is the package "git-native" something special? I search for a recipe, but cannot find anything
<thomasd13> I just wanted to check if this is using a version between 2.36 and 2.30.3
argonautx has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<RP> thomasd13: so places in the code may use git from git-native or nativesdk-git
nemik has quit [Ping timeout: 240 seconds]
<RP> thomasd13: eSDK probably uses nativesdk-git
nemik has joined #yocto
<thomasd13> thanks RP!
<rburton> RP: aah
<thomasd13> Omg! I debugged bit further: https://zerobin.net/?a25e6909ea353de7#7zJ4bF5IvTOhkGfc+WXdaCLPItvMU0lvHz4hnQRTn8k= so that I see which git version has been used when the error occurs
<thomasd13> Its not the git version which is wrong, the user is ROOT
<RP> thomasd13: it is running under pseudo
<RP> i.e. fakeroot emulation
<thomasd13> When I execute the same command as root (here on my yocto build machine), I get the same error as bitbake does
<rburton> you have a new git then :)
<RP> rburton: or patched
<thomasd13> rburton, https://zerobin.net/?f0f7a2cd59d5e9e6#2hV9pk3+9uQMgLtpkE+FzFfiifQxY4+C1l1AcwhMZlM=
<thomasd13> This is the output of my task, with the modified bbclass code
<thomasd13> RP thank you so much! :D But I still don't understand. My debug output prints that it seems to use git 2.25.1
<thomasd13> And I thought the first git version, which complains about it is 2.30.x
otavio has quit [Remote host closed the connection]
ilunev has joined #yocto
<rburton> thomasd13: your distro might have backported the patch
<thomasd13> ahhh yes, that could be the reason *facepalm
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
kroon has quit [Quit: Leaving]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<thomasd13> If you don't mind, I would redirect that commit to TI people. There are more people which have issues with their arago distribution. I am sure they have the same issue
<Schiller> how can i confirm that my Hash Equivalency Server is running. Also is this the correct way to start it on the host: bitbake-hashserv --bind 172.18.0.2:9987
ak77 has joined #yocto
hcg has joined #yocto
thomasd13 has quit [Ping timeout: 256 seconds]
otavio has joined #yocto
<sielicki> https://www.yoctoproject.org/software-overview/downloads/ still has `git clone -b honister git://git.yoctoproject.org/poky.git`, fyi
sakoman has joined #yocto
<qschulz> ndec: or halstead? ^
GLumen has joined #yocto
<Tyaku> I come back with my driver customisation issue. Here is the file that I am editing: https://pastebin.com/XLEZbsNR in this file I change two things:
<Tyaku> 1. Change the fifo_size from 64 to 128 (line 1047). This modification should be shared for each devices with "fsl,imx51-ecspi" (and it's not a problem)
<Tyaku> 2. Set the MOSI IDLE state to LOW (line 568). This modification is shared for each spi-bus, idealy it will be better to do it only for one spi-bus.
kranzo has quit [Quit: Client closed]
<Tyaku> In "mx51_ecspi_prepare_message" I don't have access to the bus number, so I can't but a "brutal" condition (if bus_num == 1) { // Set the MOSI IDLE state as LOW }
<qschulz> Tyaku: create a new device tree property for this driver
<qschulz> read it during the probe, save it in a boolean or something in the spi_imx_data and read it from within mx51_ecspi_prepare_message
<Tyaku> So this change is maybe not good "here". The unique solution I see is to create a custom .compatible (like "fsl,imx51-ecspi" and redefine the functions for my custom dt and update the dts to use this custom
<Tyaku> But it's possibly overkill ?
<qschulz> Tyaku: for the idle state to low, a property makes sense
<Tyaku> Oh yeah
<qschulz> for the fifo_size... probably a different compatible indeed as this does not seem like the intent was to make this configurable
<qschulz> not sure why you have a bigger fifo_size
<qschulz> than the one originally in the kernel driver
<Tyaku> It's because when I send more than 64 bytes, the result on MOSI line is like highly corrupted
<qschulz> I assume the message shouldn't just be sent?
<Tyaku> (the signal is completly different as it is supposed to be)
<Tyaku> Increasing it to 128 solved the issue.
<Tyaku> No a message is really sent but it's really like "fully corrupted" .
<qschulz> just to be clear, you're talking on #yocto and it's probably not the best place to get advice on how to make in-kernel changes
<Tyaku> Yep I understand, but your responses are pretty clear.
<qschulz> but I don't have another channel to suggest
<Tyaku> #linux is probably too generic.
<Tyaku> Or NXP forums :D
<LetoThe2nd> linux-imx? i think it exists somewhere.
nemik has quit [Ping timeout: 276 seconds]
<Schiller> anyone with any knowledge about the Hash Equivalency Server?
nemik has joined #yocto
Schlumpf has quit [Quit: Client closed]
<JPEW> Schiller: I might be able to help you with that
nemik has quit [Ping timeout: 240 seconds]
<Schiller> JPEW: Thx for reply. I actually just want to confirm if the Hash Equivalency Server is up and running or see when some worker is connecting.
<JPEW> Are you running a central server over TCP, or just a local one over a Unix Domain Socket?
nemik has joined #yocto
<JPEW> (the default is the Unix Domain Socket unless you explicitly told bitbake to connect to a central one)
<Schiller> JPEW: i run the default one
<Schiller> JPEW: local copy from poky-repo / sourced it / and ran bitbake-hashserv --bind <IP>:<PORT>
<JPEW> Oh, sorry. By default poky will start/stop a local server for you, which is what I meant
<JPEW> Schiller: Running a server manually like that is fine, but bitbake won't use it unless you tell it to with BB_HASHSERVE
<Schiller> JPEW yeah i did edit that part
<Schiller> JPEW: i am also pretty sure that the worker in some other container does use it i can't just confirm it anywhere. Are there any logs or smth.
BWhitten has quit [Ping timeout: 246 seconds]
<JPEW> Schiller: OK. Bitbake has a tools called `bitbake-hashclient` you can use to try connecting to the server; `bitbake-hashclient stats` might be useful to see if it's recorded any hashes
<Schiller> JPEW: thanks will try
<JPEW> Make sure to use the --address option to connect to the correct instance
<rburton> khem: looks like musl-locale and poky-tiny are not friends
<rburton> poky-tiny nukes gettext
BWhitten has joined #yocto
manuel1985 has joined #yocto
manuel_ has joined #yocto
<_angelo_> hi, to avoid issues, can i rise priority of a single bbappend/recipe ?
manuel1985 has quit [Ping timeout: 272 seconds]
<qschulz> _angelo_: try to use PREFERRED_VERSION in one of your configuration files
<qschulz> otherwise, layer priority
<qschulz> and/or recipe version bigger than other
<_angelo_> qschulz: thanks. Issue is that i have 2 bbappends in 2 different layers but i would invert the process order
<_angelo_> without any risk to corrupt other stuff
<_angelo_> ok, i can create a new recipe in case. thanks
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hcg has quit [Quit: Ping timeout (120 seconds)]
<qschulz> _angelo_: bbappend priority is based on the layer priority
<qschulz> so just put it in another layer just for that onbe bbappend I guess
<_angelo_> qschulz: great, thanks
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<Schiller> i have a fundamental question about the ypautobuilder-project. i got one container with the controller / worker / autobuilderhelper and various containers with workers. Now i removed the worker from the controller container which also removed the buildbot.tacs from the other container. Are those other workers just instances of the worker on the
<Schiller> host system?
florian has quit [Quit: Ex-Chat]
OutBackDingo has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
frieder has quit [Remote host closed the connection]
OutBackDingo has joined #yocto
florian_kc has quit [Ping timeout: 276 seconds]
OutBackDingo has quit [Ping timeout: 276 seconds]
OutBackDingo has joined #yocto
goliath has quit [Ping timeout: 276 seconds]
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
ross[m] has quit [Quit: You have been kicked for being idle]
mckoan is now known as mckoan|away
Schiller has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
goliath has joined #yocto
manuel_ has quit [Quit: Leaving]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<Tyaku> qschulz: This is just to say that for my kernel driver customization I finally decided to configure in .dts a "compatible = "xxxx,ws2812b"" and in spi-imx.c file I just add this custom compatibility. This custom compatibilty mostly use the same functions as "classic SPI" except the function to prepare the transmission. I think this option is perfect in my case. As the SPI line is dedicated to the RGB LED
<Tyaku> strip. It works like a charm. my final spi-imx.c file: https://pastebin.com/H9imYSUJ and my .dts customisation: https://pastebin.com/Ha76eA2J
<Tyaku> Thanks for help.
Guest22 has joined #yocto
Guest22 has quit [Client Quit]
TimBo93 has joined #yocto
rfuentess has quit [Remote host closed the connection]
Tyaku has quit [Quit: Lost terminal]
<vvn> when the soc your machine is based on has features like alsa or usbgadget, but your product based on this soc doesn't have audio nor usbgadget feature, would you MACHINE_FEATURES:remove:myproduct = "alsa usbgadget" or not?
<vvn> or would you do something like DISTRO_FEATURES:remove:myproduct = "alsa usbgadget" maybe?
<kergoth> you shouldn' thave to remove the machine features, that'll control what packagegroups are created, but the distro's corresponding features controls what's actually installed
<kergoth> see packagegroup-base.bb in oe-core
<vvn> I know how the features affect the packagegroups, my question is more of a design choice, whether you tweak the SoC features that are not usable on the final product, or not
<vvn> kergoth: to give an example, imagine you have a beaglebone based product without sound, and another product with sound, both using your own distro. The alsa packages on the first product aren't needed, so would you remove the 'alsa' feature from your machine conf (because it is added to the TI soc configuration) or do you tweak the machine/distro features elsewhere?
florian_kc has joined #yocto
<michaelo> Cool, LWN.net is announcing our new release too: https://lwn.net/Articles/892825/
TundraMan is now known as marka
TimBo93 has quit [Quit: Client closed]
ardo has quit [Remote host closed the connection]
ardo has joined #yocto
kevinrowland has joined #yocto
florian_kc has quit [Ping timeout: 272 seconds]
<kergoth> vvn: ahh, i see. If you have a machine for it, and you know it won't be on the product or available via an expansion bus, i'd say probably remove it from the machine features. i guess its a question of capability vs support, for machine vs distro, respectively
lrusak[m] has joined #yocto
<lrusak[m]> Hello! I’m looking at using RAUC as an updated for our embedded system, I have a question about using wic to create the desired partition layout. Ideally we just want rootfsA, rootfsB, and userdata partitions. I can’t seem to get wic to create a combined boot + rootfs partition though. It seems the boot partition is required when using u-boot. Ideas?
<shoragan[m]> lrusak: that depends on what you mean by root partition. you need a no-A/B partition for the bootloader. in most cases, /boot (which contains kernel, dtb and perhaps initramfs) can be part of the rootfs.
<shoragan[m]> * mean by <del>root, * root</del>, * boot partition. you
<lrusak[m]> Basically I don’t want a separate boot partition, but with my wks file I seem to need to use —source bootimg-partition in order to create a bootable image
<shoragan[m]> Take a look at: https://github.com/rauc/meta-rauc-community
<shoragan[m]> so you want the bootloader in an unpartitioned region?
<lrusak[m]> Ah interesting
<shoragan[m]> all of these examples should have their kernels in the rootfs partitions
<lrusak[m]> This is u-boot for my device without using a partition... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/526f5ac705397c9d201b69cdab4cfa444735a6d0)
<shoragan[m]> I'm not an wic expert. :) But it would be logical to allow two rawcopy entries with --no-table.
<tlwoerner> thank you to everyone who got a CFP in, yps2022.05 is looking very exciting!
<lrusak[m]> shoragan[m]: Cheers, I’ll give that a go and report back
kevinrowland has quit [Ping timeout: 252 seconds]
<tlwoerner> OEHH in 2.5 hours from now: https://www.openembedded.org/wiki/Happy_Hours
<shoragan[m]> lrusak: also join us in #rauc:matrix.org :)
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<vvn> kergoth: I guess that's the grey area for machine configurations, where for a SoC you really expect the features to describes the capabilities, while for the configuration of the final product, you may describe the intended usage
<vvn> lrusak[m]: no you don't have to use bootimg-partition to create a bootable image. That is just a partition containing the files described as IMAGE_BOOT_FILES. Some machine use it, some don't. You can create a --no-table --source rawcopy --sourceparams "file=path/to/my/raw/bootloader.img" for example as shoragan[m] suggested
<lrusak[m]> Cheers
<vvn> What does the release note mean by "rawcopy: Add support for packed images"?
<Saur[m]> vvn: Search for "rawcopy" in the git log and you should find it.
<vvn> Saur[m]: OE-Core?
<Saur[m]> Yes, or poky.
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<vvn> meh, okay not what I was hoping for
florian_kc has quit [Ping timeout: 276 seconds]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<halstead> sielicki: qschulz: I tracked down the error are corrected it. This slipped by both Chee Yang and I during the release. Thank you for the report.
kevinrowland has joined #yocto
Minvera has joined #yocto
Chaul-Jhin-Kim has joined #yocto
amitk has quit [Ping timeout: 272 seconds]
<Chaul-Jhin-Kim> Has anyone tried compiling Kirkstone on arm?
florian_kc has joined #yocto
<abelloni> Chaul-Jhin-Kim: the autobuilders should have done that, yes
<Chaul-Jhin-Kim> ok cool
<Chaul-Jhin-Kim> Dear GOD/GODS and/or anyone else who can HELP ME (e.g. TIME TRAVELERS or MEMBERS OF SUPER-INTELLIGENT ALIEN CIVILIZATIONS):
<Chaul-Jhin-Kim> The next time I wake up, please change my physical form to that of FINN MCMILLAN formerly of SOUTH NEW BRIGHTON at 8 YEARS OLD and keep it that way FOREVER.
<Chaul-Jhin-Kim> I am so sick of this chubby Asian man body!
<Chaul-Jhin-Kim> Thank you!
<Chaul-Jhin-Kim> - CHAUL JHIN KIM (a.k.a. A DESPERATE SOUL)
Chaul-Jhin-Kim has left #yocto [#yocto]
<abelloni> wtf
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
kroon has joined #yocto
Starfoxxes has quit [Ping timeout: 240 seconds]
<zeddii> I'm thinking someone left their screen unlocked.
<smurray> zeddii: I thought that for a second, but the time gap was pretty small
<zeddii> true
<zeddii> but a good troll moves quickly. ask paulg
* paulg whistles innocently
Starfoxxes has joined #yocto
<paulg> unless you are dismantling a phone - that shit takes time.
argonautx has quit [Quit: Leaving]
Starfoxxes has quit [Ping timeout: 240 seconds]
kroon has quit [Quit: Leaving]
amahnui1 has quit [Quit: Connection closed for inactivity]
florian_kc is now known as florian
Starfoxxes has joined #yocto
BWhitten has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
florian has quit [Ping timeout: 260 seconds]
amahnui1 has joined #yocto
olani has quit [Remote host closed the connection]
Minvera has quit [Remote host closed the connection]
olani has joined #yocto
<vvn> should we clean the SSTATE_DIR after bumping to 4.0 or nah?
042AAD573 has joined #yocto
011AAEXVF has joined #yocto
mvlad has quit [Remote host closed the connection]
<hushmoney> after calling tinfoil.parse_recipes() should i be able to get at each recipe's environment datastore and varhistory somehow, or do i still need to call tinfoil.parse_recipe()?
florian_kc has quit [Ping timeout: 276 seconds]
<hushmoney> i'm trying to write handy bblayers plugin to help manage our codebase
<Saur[m]> vvn: Shouldn't be needed.
042AAD573 has quit [Remote host closed the connection]
011AAEXVF has quit [Remote host closed the connection]
olani has quit [Remote host closed the connection]
olani has joined #yocto
olani has quit [Remote host closed the connection]
olani has joined #yocto
<vvn> So I've added RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = "" to my machine config to exclude kernel artifacts from all images
<vvn> it works fine
<vvn> But my images still end up with /boot/foo.dtb
<vvn> rburton: ^
mckoan|away has quit [Ping timeout: 250 seconds]
mckoan|away has joined #yocto
ardo has quit [Ping timeout: 272 seconds]
ardo has joined #yocto
mckoan|away has quit [Ping timeout: 276 seconds]
mckoan|away has joined #yocto
florian_kc has joined #yocto
bluelightning has quit [Ping timeout: 250 seconds]
bluelightning has joined #yocto
prabhakarlad has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 260 seconds]
Herrie has quit [Quit: ZNC 1.8.0 - https://znc.in]
hmw[m] has quit [Ping timeout: 240 seconds]
khem has quit [Ping timeout: 240 seconds]
shoragan[m] has quit [Ping timeout: 240 seconds]
Herrie has joined #yocto
khem has joined #yocto
hmw[m] has joined #yocto
shoragan[m] has joined #yocto