<jclsn>
So this oelint-adv tool is telling me to place FILES before RDEPENDS. My colleague is complaining about this. I don't see anything about this in the OE Styleguide. Does anyone know where the oelint-dev gets this from?
<jclsn>
How is Qualcomm support looking in general? Is it a good idea to use one of their SoCs? The BSPs seem closed-source to me, since I can't find much about them
ehussain has quit [Remote host closed the connection]
ehussain has joined #yocto
crazy_imp has joined #yocto
<crazy_imp>
hi, is there a way to get the targets (kernel) page size during compile time of userland applications?
<mckoan>
jclsn: my past experiences with Qualcomm were not good
<jclsn>
mckoan: Can you elaborate?
<mckoan>
jclsn: no, I can't sorry. All depends on your real need on QC system. Maybe you can describe your scenario
enok has quit [Ping timeout: 240 seconds]
<jclsn>
We are developing a system for a highly-regulated industry. We already have an NXP-based solution, but are looking for more performance and a more modern SoC than the i.MX8. So we would need to port our existing system to a Qcom SoC. I don't see it used much in the industry. It is more of an Android SoC for imo. That is why I am asking.
<jclsn>
I would think of other performant SoCs like the RK3588, but I doubt anyone would accept an SoC from a Chinese manufacturer in our industry.
ehussain has quit [Ping timeout: 268 seconds]
xmn has quit [Ping timeout: 246 seconds]
altru has joined #yocto
enok has joined #yocto
alessioigor has quit [Quit: Client closed]
<jclsn>
I also see an issue with our DRM setup. This is currently based on NXP's OP-TEE. We would probably have to change a lot here
<Xogium>
well if you switch vendor pretty much everything in the boot chain will change for sure
<jclsn>
Xogium: Sure, I am just asking about how well the Yocto support is. I wouldn't want to write half the BSP myself or be completely dependent of official Qcom support
<BhsTalel>
mckoan I confirm.
<jclsn>
mckoan: Isn't NXP weird in this regard already?
<jclsn>
I guess Qcom is such a big player in the Android market, that they don't care about Yocto much
florian has joined #yocto
mvlad has joined #yocto
Jones42 has joined #yocto
Jones42_ has joined #yocto
Jones42 has quit [Ping timeout: 246 seconds]
florian has quit [Ping timeout: 272 seconds]
mbulut has joined #yocto
Jones42__ has joined #yocto
Jones42_ has quit [Ping timeout: 256 seconds]
<rburton>
crazy_imp: no, because you're not running inside the kernel
<qschulz>
khem: I know, I'm trying to work this issue out but it's **really** difficult right now
<qschulz>
khem: so, iris gallium driver is now requiring lbclc
<qschulz>
however, if I add libclc to DEPENDS of PACKAGECONFIG[gallium] when iris is part of GALLIUMDRIVERS, I get a conflict in sysroot of mesa-native because llvm and clang both install the same static library
<qschulz>
this is because gallium-llvm is forced in PACKAGECONFIG for the native recipe
enok has quit [Ping timeout: 240 seconds]
<qschulz>
so it can either be gallium-llvm or gallium for now (or I move iris gallium to gallium-llvm, something I'll try today)
<qschulz>
jclsn: if that can help, i'll personally never work on any product based on Qcom, that's bad enough to make me quit my job if i'm forced to work on SoCs from that vendor
<qschulz>
I know people who worked on Qcom products and they basically said never again
<qschulz>
on SW side
<crazy_imp>
rburton: yes i know. hoped there's some variable inside the build system exposing it :|. even within the kernel it's kinda messy because for x86_64 there's no config parameter declaring tha page size while for arm64, there's CONFIG_ARM64_4K_PAGES
<qschulz>
on HW side, i only know one person who had some experience with them and it wasn't a good experience as well, with the same conclusion: no product on Qcom
<qschulz>
jclsn: this may have changed though, since Linaro is working a lot with upstream on Qcom products but this may be aiming only the very high performance SoCs (the ones you find in PCs or flagship smartphones)
florian has joined #yocto
<Xogium>
qschulz: which vendors are you ok with, out of curiosity ?
<qschulz>
Xogium: I've worked on Amlogic, Allwinner, Mediatek, NXP and Rockchip for now. Amlogic has virtually no documentation and their BSP is really meh, Baylibre did upstream a few SoCs but I was told they weren't given any more documentation than I had.
<qschulz>
Xogium: Allwinner, it was ten years ago when it was in cheap tablets/phones. Doc a bit better than Amlogic, I never had a BSP with DT support (I worked on a 4.9 but they did some very weird thing with the DT)
<qschulz>
Mediatek was not great, didn't get access to docs IIRC, and the kernel was really not great. But Baylibre has been working a lot on Mtk SoCs as well with upstream, so maybe that has improved as well
<qschulz>
Rockchip is quite OK on the doc side, much better than the other mentioned Chinese vendors but you still have some incorrect info or IPs entirely not mentioned
<qschulz>
The kernel is... not great but it feels a bit better than the other CHinese vendors
<qschulz>
The best experience I had was with NXP
<qschulz>
Amazing doc, really nice support the only time I needed it (an issue in assembly code when entering suspend to RAM I could have never found by myself)
<qschulz>
they sometimes upstream stuff themselves, but they also keep updating their downstream repos often
<Xogium>
interesting !
<qschulz>
their doc is so good (or at least used to be, have been a couple of years I have worked on those) that this is actually used to understand how the same IP in SoCs from other vendors work
<qschulz>
In the end, you pay for what you get (in both directions)
<Xogium>
indeed
<qschulz>
The only surprise is Qcom, which I think isn't that affordable, and the quality of the BSP we received was abysmal
<Xogium>
damn
<Xogium>
that does sound very bad indeed
<qschulz>
For Qcom stuff, you can ask Linaro and specifically caleb, they have done a lot of awesome work on products from that vendor, so they would know much more than I do what the current state is
<BhsTalel>
I had good experience also with NXP, their documentation is very good, and even for free support they did help me on a MIPI DSI kernel driver for a panel that is not theirs, their support is also good.
<Xogium>
I've not yet done lots of bsp, mostly because I'm quite comfortable with st so far... And I'll admit, outside of bsp things, I only did allwinner and amlogic, and they were both absolutely awful. Here, catch ! It's a patch for your board to make it work better ! ... thanks, sochip. That's not a patch. It's a binary file I have no idea what it is used for, where to even put it, what to even do with it in the
<Xogium>
first place
<Xogium>
they sent me this when the SoC we were using at the time got EOL... They replaced it with a supposedly compatible pin-to-pin version that is low power
<Xogium>
needless to say I wasn't impressed
<BhsTalel>
Xogium I noticed that lot of companies are switching to ST SoCs specially the MP1 processor, and they offer well detailed documents and good support.
<Xogium>
BhsTalel: yeah I definitely agree on doc and support, they're very nice. They even helped us with a board that wasn't of their own design in understanding why we had problem with the i2c controller from the dev board
florian_kc has joined #yocto
<Xogium>
their bsp isn't, like, the worst, probably. It's just very very weird and doing of things it shouldn't be doing
<Xogium>
*lots of things
<BhsTalel>
ST invest alot in support, we have ST here and they have like an entire departement just for handling support and forum questions
<Xogium>
carrying bbappend for pulseaudio, mesa, systemd, etc.
<BhsTalel>
What I only hate about ST is that they over engineer alot when its coming to BSP and Yocto, cyou can compare meta-st-stm32mp and meta-nxp and see the difference, but they did a pretty good job on Yocto side
<Xogium>
yeah they really overdone stuff
<Xogium>
but I'm sure there's far worse out there
enok has joined #yocto
<Xogium>
I actually had plans of starting my own proper bsp for st to have only what a bsp should do in there... Hardware support and bringup, nothing more
<Xogium>
but well, something called real life got in my way for the moment
<BhsTalel>
I am working with a company that designed a custom board based on MP1 and since they know ST has overdone their Yocto BSP layer, the company created a wrapper layers with simpler variables and explaination for their clients
<Xogium>
that said I'm very interested to see how the stm32mp2 sries will be like
<Xogium>
oooh wow that is nice !
<Xogium>
is that bsp kept private ? Probably is but... If not, I'd sure like to check it out and see how they've done things
<BhsTalel>
I remember once I tried to simplify the env setup of ST layers with KAS yaml files and they rejected the pull request saying that the internal team did not agree on this LOL https://github.com/STMicroelectronics/meta-st-stm32mp/pull/62
<qschulz>
BhsTalel: it's a third party tool not part of Yocto/OE, so I wouldn't throw them under the bus for this choice
<BhsTalel>
Yeah, I totally understand that
<Xogium>
shame though it would have made the setup quite a bit easier
<Xogium>
because their scripts are SO BAD
<qschulz>
we have some bitbake tool now to setup layers and whatnot, so maybe there's something to do there
<Xogium>
like the one that generates sd card images from a flashlayout file for example. Oh my. It's full of hardcoded things, and full of shellcheck warnings and errors :D
<BhsTalel>
Their tools are very specific to their boards, I think there is someone there that wants everything to be very tight to ST.
<BhsTalel>
qschulz Good contribution diea
<BhsTalel>
idea*
<BhsTalel>
I am still working on a Rust tool that will be an alternative for KAS, I hope it will be ready before the next 2024.11 Summit
Saur_Home5 has quit [Quit: Client closed]
Saur_Home5 has joined #yocto
enok has quit [Ping timeout: 240 seconds]
<rburton>
BhsTalel: does it offer anything beyond kas/repo/tuxbake/bitbake-setup apart from being written in a different language?
Jones42__ is now known as Jones42
BhsTalel has quit [Quit: Client closed]
Saur_Home5 has quit [Quit: Client closed]
Saur_Home5 has joined #yocto
BhsTalel has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
alessioigor has quit [Quit: Client closed]
<BhsTalel>
rburton It does the same needed job ofc which is setting up layers and build environment, but what I tried to add is the following features:
<BhsTalel>
- Support different types of input files (thanks to serde crate): YAML, JSON, TOML and RON are supported
<BhsTalel>
- Reverse: generate a build configuration based of an existing build environment
<BhsTalel>
- Repo: this is like google repo
<BhsTalel>
- Theme: which has lot of themes config files like ROS2 and RPI for example, if you type: easyocto theme -t rpi --setup , then it will setup a build environment automatically based on a predefiend rpi theme config, ... (BTW, its called easyocto)
<BhsTalel>
- Also, I have included what I called core and third party layers config files, so in the config file you don't need to specify every layer again like in KAS, for example you can specify directly the layer name.
<BhsTalel>
- Also, meta, meta-poky are automatically selected as they are required, so with just: easyocto build , with no config input, you can get a setup ready
<BhsTalel>
- Also, I started a CLI support to edit and create a config file, because it s quite complicated.
<BhsTalel>
- Also, Git2 crate is used and not a system git command
<BhsTalel>
NOTE: I started this for me as a big project to learn Rust.
<BhsTalel>
it could be usefull somehow, we will see
<BhsTalel>
I am going for lunch, I will check with you if you sent something I didnt received
jmiehe has joined #yocto
florian has quit [Quit: Ex-Chat]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
BhsTalel has quit [Quit: Client closed]
BhsTalel has joined #yocto
<BhsTalel>
rburton I got disconnected, did you reply on my message ?
<Xogium>
BhsTalel: they didn't
<BhsTalel>
Xogium BTW, what do you think about it ?
<Xogium>
BhsTalel: that sounds like it definitely could be useful, from what you've described. Kas here just broke so I can't actually use it, and so I resorted to manually setting up everything currently
florian has joined #yocto
<qschulz>
BhsTalel: meta-poky is for sure not required :)
<BhsTalel>
My tool checks if default config is set for local.conf and bblayers.conf, if it is the case (which is the default) it sets up the templates from meta-poky.
<jclsn>
qschulz: Well, guess I will have to make my own experiences here. If our architects decide to use this SoC, I won't be able to do much about it
ablu has quit [Ping timeout: 260 seconds]
ablu has joined #yocto
<qschulz>
jclsn: hardware people and marketing people sometimes do not realize that the SW cost of a choice can be vastly different
<qschulz>
if someone tells them before they make the choice, they cannot complain afterwards they didn't know :)
sgw has joined #yocto
ablu has quit [Ping timeout: 260 seconds]
<jclsn>
Sure, I also forwarded what I heard
<jclsn>
I just think it would be interesting to work with a Qcom SoC
<jclsn>
Their chips are super efficient. It would make our product ready for years to come
<jclsn>
So it may be worth the effort. NXP does not have an SoC that can compete unfortunately
ablu has joined #yocto
xmn has joined #yocto
<mckoan>
jclsn: however our company offer support even for YP projects based on Qcom ;-)
<jclsn>
mckoan: We are already working with Linaro anyway. So it is convenient that they maintain the layer
<qschulz>
jclsn: if it takes you years to have parity with your NXP SoC... :)
Jones42_ has joined #yocto
Jones42 has quit [Ping timeout: 268 seconds]
Jones42_ has quit [Ping timeout: 240 seconds]
<smurray>
jclsn: in my experience, for product Qualcomm will want you to use one of their SDKs, which includes a massive repo of stuff. They don't provide a separate BSP layer for most of their chips, their model is you work in their environment
<jclsn>
smurray: That is disgusting
<jclsn>
Maybe Linaro can do that part for us :D
<smurray>
jclsn: it's not fun, that's for sure. In theory you could pick stuff apart out of their SDK, I'm not sure if anyone does, I imagine it would lead to troublesome support discussions
altru has quit [Quit: Client closed]
<smurray>
jclsn: afaik the Linaro work is pretty much only for SoCs that go into stuff like Chromebooks or potentially now the new Windows ARM PCs. I'll admit I've not looked at meta-qcom that recently, though
<jclsn>
Alright, thanks for the input guys
<jclsn>
Nothing is set in stone yet anyway
<qschulz>
I concur, I've looked at their Yocto SDK for about an hour and I had to take a two-week holidays to try to forget about it
<qschulz>
IIRC, they replaced the base bbclass
<qschulz>
It's probably more fair to say it's a Bitbake SDK than a Yocto SDK at that point honestly
rob_w has quit [Quit: Leaving]
<jclsn>
qschulz: Don't be so dramatique
MrCryo has joined #yocto
Guest68 has joined #yocto
<jclsn>
But yeah it is quite bad :D
schtobia has quit [Quit: Bye!]
Guest68 has quit [Client Quit]
schtobia has joined #yocto
alessioigor has quit [Quit: Client closed]
rfuentess has quit [Remote host closed the connection]
alessioigor has joined #yocto
ehussain has joined #yocto
ehussain has quit [Client Quit]
enok has joined #yocto
<JPEW>
RP: you can drop the image.bbclass hooks patch. I did it better per the call yesterday
<zeddii>
gettext isn't building for me this morning after an update. anyone else seeing that ?
<zeddii>
a libtool version mismatch in a header.
BhsTalel has quit [Quit: Client closed]
<zeddii>
clearly I can blame RP, since he's the main contributor to libtool now! ;)
alessioigor has quit [Quit: Client closed]
alessioigor has joined #yocto
sgw has quit [Quit: Leaving.]
enok has quit [Ping timeout: 240 seconds]
Saur_Home5 has quit [Quit: Client closed]
Saur_Home5 has joined #yocto
<khem>
qschulz: is it just one library of a set of libs which are conflicting ?
alessioigor has quit [Quit: Client closed]
alessioigor has joined #yocto
alessioigor has quit [Quit: Client closed]
alessioigor has joined #yocto
vthor has joined #yocto
<qschulz>
khem: only have this error message, maybe it would complain for more if we resolve this one?
<RP>
zeddii: clean it and it will build fine. autotools is a bit dense at times
<RP>
zeddii: I did see it myself but assumed I'd corrupted something when testing
<zeddii>
I tried cleansstate and cleanall still blowing up, but I went away from it for a bit and will try again.
zpfvo has quit [Remote host closed the connection]
mbulut has joined #yocto
enok has joined #yocto
BhsTalel has quit [Quit: Client closed]
Guest3753 has joined #yocto
nerdboy has quit [Ping timeout: 252 seconds]
npk32 has joined #yocto
npk32 has left #yocto [#yocto]
Saur_Home5 has quit [Quit: Client closed]
Saur_Home5 has joined #yocto
npk has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
Guest3753 has quit [Quit: Connection closed]
florian has quit [Ping timeout: 264 seconds]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
npk has quit [Quit: Client closed]
mattsm has joined #yocto
<mattsm>
what is the preferred way of doing local fast kernel builds these days? ideally bypassing the fetch + full recompile if a commit is made or even just using the local changes to iterate quickly.
florian has joined #yocto
leon-anavi has quit [Quit: Leaving]
<khem>
RP: is that only happening on musl targets ?
<khem>
thats a LTO fat object, so I am guessing we never generated it with musl before perhaps or its now in different path is expected
Dracos-Carazza has quit [Quit: ZNC 1.9.0 - https://znc.in]
<Guest3738>
anybody use git depencencies in a rust project instead of crates.io dependencies?
Haxxa has joined #yocto
alessioigor has quit [Quit: Client closed]
Dracos-Carazza has joined #yocto
Dracos-Carazza has quit [Client Quit]
florian_kc has joined #yocto
Ad0 has quit [Ping timeout: 268 seconds]
<Guest3738>
oh it looks like rust git dependencies need a tweak to allow workspace git dependencies
Dracos-Carazza has joined #yocto
enok has quit [Ping timeout: 240 seconds]
Ad0 has joined #yocto
<khem>
RP: I am locally getting the python bits installed right - packages-split/libpython3-staticdev/usr/lib/python3.12/config-3.12-x86_64-linux-musl/libpython3.12.a
<khem>
RP: I think the issue is that the test that upstream added to compute PLATFORM_TRIPLET is working with clang but not with gcc
<khem>
the build-renamed/ dir on AB has the workdir for python3 but I could not run the compiler inside it. perhaps some issues when the dirs are renamed
mvlad has quit [Remote host closed the connection]
<Guest3738>
where do i need to submit patches for poky?
mbulut has quit [Ping timeout: 255 seconds]
mbulut has joined #yocto
<khem>
Guest3738: usually if you are chaning things under meta/ then send to openembedded-core list
<khem>
things under meta-poky go to poky ml and under bitbake/ dir go to bitbake list
Saur_Home5 has quit [Quit: Client closed]
<khem>
since poky is composed of multiple git repositories
<khem>
RP: I can see the problem, its actually the platform test is failing for musl+gcc and works for musl+clang and the reason is a compiler issue where for musl it should look into sysroot for std headers before it looks into compiler headers dirs, I have fixed clang for that few years ago but not gcc
<khem>
for glibc order is reverse
<khem>
which is gcc's default too so it works
<khem>
on glibc systems
<RP>
khem: glad you at least understand the problem
<Guest3738>
how do i build an image for an image type specifying CONVERSION_CMD ?
alperak has quit [Quit: Connection closed for inactivity]
florian_kc has quit [Ping timeout: 264 seconds]
<rburton>
Guest3738: IMAGE_TYPES="ext4.gz" would be a gzip-compressed ext4 image
<Guest3738>
rburton: ok that what i thought, im just seeing a problem where .enc for swupdate isnt recognized even though i did inherit swupdate-enc
mbulut has quit [Ping timeout: 246 seconds]
<Guest3738>
bitbake -e (my-image-name-here) | grep CONVERSION_CMD shows that enc is an entry for CONVERSION_CMD as expected