|
Do you like Linux, but also think to yourself: - I want to work with embedded hardware - I hate myself - I enjoy pain - I enjoy figgies more than the pain of working with embedded Linux? Then Embedded Linux may be a thing you want to work with. There are a few embedded Linux SDK's out there, the two biggest players are: Yocto/Openembedded https://www.yoctoproject.org/: Pros: - Every company that provides embedded hardware usually provides a yocto recipe - It has a ton of packages. - It's flexible and extensible. - Tons of corporate backing - It's very clever Cons: Phobeste posted:here's some bad stuff about yocto: Buildroot https://buildroot.org/: Pros: - It's far simpler to get a build going. - Uses kconfig from the kernel, which means a menuconfig system for selecting packages. - Tons of packages are built-in and maintained by the developers and volunteers (myself included). To date, there are 2900 packages included in the latest release of Buildroot. - Packages are written with GNU Make. Cons: - Packages are written with GNU Make. - Not as clever as Yocto - Having more than one config means nothing to Buildroot, and both are built independently of each other, so no host-tool sharing. - You can't easily overwrite package .mk files with other packages .mk files. (this is by design.) Feel free to bitch about Yocto and Buildroot or just ignore the thread. 
|
#
?
Nov 1, 2021 22:16
|
|
|
|
| # ? Apr 20, 2024 04:24 |
|
|
My irl name is Steve Yocto, inventer of Yocto Linux. I named it after myself, not very creative I know. Anyhow, if you do a Linux I recommend Yocto Linux - it's the bees' nuts. Poopernickel fucked around with this message at 22:27 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 22:24
|
|
|
Poopernickel posted:My irl name is Steve Yocto, inventer of Yocto Linux. I named it after myself, not very creative I know. My name is Adam Buildroot, inventor of Buildroot Linux. If you do an embedded Linux, I recommend Buildroot, as I have submitted way too many patches to Buildroot over the years.
|
|
#
?
Nov 1, 2021 22:28
|
|
|
Linux is named after Linux Torvalds
|
|
#
?
Nov 1, 2021 22:29
|
|
|
i only used yocto on one project, and it was to build an embedded version of linux. the company hired some lawyers to go over all the licenses are were drooling at the possible billable hours they were going to have going through all the packages. i ran a single command and dumped the entire license package and sent it to them, probably nearly a 1000 licenses. they only got a small handful of billable hours. thats my yocto experience.
|
|
#
?
Nov 1, 2021 22:31
|
|
|
CRIP EATIN BREAD posted:i only used yocto on one project, and it was to build an embedded version of linux. yeah both buildroot and yocto are pretty good at doing this although yocto takes a more... proactive approach with a bunch of runtime checks that a license is present (whereas with buildroot, since it's more centralized, it's more of a "nobody's going to apply your patch into trunk if it doesn't have a license with it")
|
|
#
?
Nov 1, 2021 22:34
|
|
|
Yocto's license management is legit if you want to make sure you're compliant and that your licenses don't change out from under you. I like that I can set a "don't ever install gplv3" setting, and then be secure that it won't unless somebody intentionally forges license data on a package.
|
|
#
?
Nov 1, 2021 22:35
|
|
|
linux schminux
|
|
#
?
Nov 1, 2021 22:36
|
|
|
attempting to do a custom linux once frustrated me enough to start writing a new kernel instead
|
|
#
?
Nov 1, 2021 22:36
|
|
|
Poopernickel posted:Yocto's license management is legit if you want to make sure you're compliant and that your licenses don't change out from under you. There has been a lot of discussion on how to implement this in Buildroot. It's a highly requested feature! I have been poking at this kind of thing off and on for a while now!
|
|
#
?
Nov 1, 2021 22:42
|
|
|
Poopernickel posted:Yocto's Bithc
|
|
#
?
Nov 1, 2021 22:44
|
|
|
i used to do embedded linux things and would like to again
|
|
#
?
Nov 1, 2021 22:45
|
|
|
DoomTrainPhD posted:There has been a lot of discussion on how to implement this in Buildroot. It's a highly requested feature! Model it after Yocto's with some changes. Add a config option that enables a build step after patch. The step checks to see if a recipe's license hash matches the license hash in the source tree, to ensure the recipe info is still correct. Trust the recipe author to be accurate about the license name. Fail the step if the license matches a blacklisted value (or if it's not whitelisted). Make this different for host packages, where it generally doesn't matter.
|
|
#
?
Nov 1, 2021 22:46
|
|
|
If you're a "gently caress it, the defaults are probably fine" kind of guy then Buildroot is your jam. If you want to control everything then Yocto is what you want. Yocto has a much steeper learning curve IMO and it takes more time to get started. But it's a lot more powerful. Sometimes that's the right tradeoff, sometimes not. Also it has broad vendor support which is nice, because they can just ship a layer which will probably be a pain in the rear end for you to integrate. Poopernickel fucked around with this message at 22:54 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 22:52
|
|
|
here's my current (least) favorite embedded linux thing problem: let's say that you want an embedded linux device that has a predefined system on it so you want to use something like buildroot or yocto. let's also say that one thing you want running on it is a modern interpreted-language app. maybe it's javascript, maybe it's python, whatever (i know, i know, just come on this voyage of discovery with me). what do such "modern apps" all have in common? a shitload, an absolute shitload, of dependencies, often for a bad reason, sometimes for a good reason. here's the thing with buildroot and yocto: they weren't written for that at all. they're written for applications that don't have that many deps, and also don't have that many unique deps. and the expectation is that those deps aren't really unified by anything so they'll all need their own build handling. so the expectation is that any shared library or header file or python module or node module has a recipe that's in your system's recipe layer, and all your recipes mark their deps, and then you enable your end application and write down the deps and it activates all the transitive ones and you've got nice hash locked versioned dependencies. cool the thing is that python and js (again, work with me here) both already have that in terms of their language dependency ecosystem: npm and pypi. those places already have all those libraries with their dependencies marked. they have tooling bundled with the standard library or standard project tools to pull them and change them and add them and remove them, and all those deps are stored in some language specific metadata. so yocto and buildroot all expect recipes for every individual project dependency and for all those deps to be linked, and you've got a nodejs app with a package.json and yarn.lock or a python app with a setup.py or pyproject.toml or Pipfile or whatever and they're just completely different and so you get to pick one of: - manually maintain your recipe store and dependency links to correspond to the app's normal dependency management. just keep an eye on prs that change deps and make sure you do it on the target config too. simple as. i recommend this only if you bill by the hour. - autogenerate one from the other but then do the above - sidestep the language ecosystem's dependency management somehow. all the app devs will now commence ripping your guts out - sidestep the entire, like, point of buildroot or yocto and just hack some poo poo up to have the right cross flags set in some build environment and just call pipenv or yarn or whatever and then copy poo poo from the right magic dir to the right magic dir. you've just broken the smart is-a-build-necessary logic in some way or another, the library gathering logic, probably any build hermeticity you had up to this point seriously if one or another of this group would make it possible and ideally easy to add a python or js project or whatever and not have to write a recipe for every dep, while still being able to fetch all licenses and do smart rebuilds, so many nightmares would end
|
|
#
?
Nov 1, 2021 22:53
|
|
|
Poopernickel posted:Model it after Yocto's with some changes. Add a config option that enables a build step after patch. The step checks to see if a recipe's license hash matches the license hash in the source tree, to ensure the recipe info is still correct. Trust the recipe author to be accurate about the license name. Fail the step if the license matches a blacklisted value (or if it's not whitelisted). Make this different for host packages, where it generally doesn't matter. All packages have a .hash file with sha256sums (or whatever is provided there) for both the tarballs and license files specified in the .mk file. What needs to happen is a bit... more complicated. - Parse every package for their respective ${PKG_LICENSE} macro and add them to a global list which can be used in Config.in and Config.in.host files - Add the dependency macros to every single packages Config.{in,in.host} file. It's not a small patch to add!
|
|
#
?
Nov 1, 2021 23:03
|
|
|
Phobeste posted:words I solved a similar problem (manage a build tool that manages its own deps) with some black fucken Yocto magic at my last job. I added a manually triggered recipe action that downloaded all deps using the custom tool, and then updated the .bb file's license and src_uri sections based on the result. The recipe action was called manually or by CI job whenever somebody wanted to update the package's contents. It's nice having Python available to run arbitrary tasks, with full access to internal metadata. 
Poopernickel fucked around with this message at 23:15 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 23:09
|
|
|
Funny enough, there's straight up a line in the NodeJS package in Buildroot that lets a user download packages via NPM during the build. For Python, there's `utils/scanpypi` that you can use to import a package and it's dependencies, or you can build host-python-pip and run pip install during the build.
|
|
#
?
Nov 1, 2021 23:19
|
|
|
right, both those things are various workaround options, right. like the node package in buildroot's workaround is the opting-out-of-buildroot thing. scanpypi is the recipe generation thing where you still have to manually sync there's just a tool to do it (yocto has something similar at least for python). poopernickel your way sounds like the best way. what i ended up doing was using a weird little python library to parse a pipenv lockfile and generate requirements and then install them with pip (didn't want to just edit SRC_URI because i also wanted some different install opts to basically install virtualenv blobs) for python, and just call yarn and say fuckit for the js thing. neither of these are terribly good though. it's kind of a fundamental problem: yocto/buildroot and yarn/npm/poetry/pypi/pip overlap in the domain of dependency management, and they just straight up don't nest. the only answer is integration on a deep level and nobody wants to deal with that poo poo particularly for js
|
|
#
?
Nov 1, 2021 23:23
|
|
|
like IMO the actual answer here is that yocto at least, because it has a one-phase rather than two-phase model, should probably be able to let you specify a dep spec like a yarn.lock or pipfile.lock or whatever in your SRC_URI and generate (in yocto terms) RDEPENDS and DEPENDS from it. ideally it should also generate recipe content using the (de-facto standardized) install tools. maybe there's some carveouts, that's fine. this is of course a little harder with buildroot because it's two-phase and it's just kconfig so you'd have to do a loooot more work
|
|
#
?
Nov 1, 2021 23:27
|
|
|
It comes down to how often you want to update the dependencies and for what reason. At least for python packages buildroot has 431 python packages built-in and scanpy works quite well to import more. It's always interesting to see people who freak out that their embedded device must have all of the latest packages at all times.  Edit* I can't speak for node, even though I recently updated the NodeJS package in Buildroot to 14.x. The only reason I touched the NodeJS package is that I am actively working on removing all traces of Python2 from Buildroot, and NodeJS 12.x's build system requires Python2.
FlapYoJacks fucked around with this message at 23:34 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 23:31
|
|
|
you know how every python installation is supposed to have certain modules available as part of the “core” language? yocto doesn’t
|
|
#
?
Nov 2, 2021 00:12
|
|
|
hobbesmaster posted:you know how every python installation is supposed to have certain modules available as part of the “core” language? agreed, splitting up the stdlib was a very questionable design choice on Yocto's part. And by "questionable" I mean "dumb as hell"
|
|
#
?
Nov 2, 2021 00:14
|
|
|
yoctdon't
|
|
#
?
Nov 2, 2021 00:15
|
|
|
btw how common is msdos in embedded environments these days my most recent msdos experience was it controlling a building-sized telescope in 2007 or so. probably still trucking
|
|
#
?
Nov 2, 2021 00:16
|
|
|
Poopernickel posted:agreed, splitting up the stdlib was a very questionable design choice on Yocto's part. i guess it depends on what made or didn't make the cut like the tkinter stuff could probably be cut for example
|
|
#
?
Nov 2, 2021 00:17
|
|
|
Progressive JPEG posted:btw how common is msdos in embedded environments these days specifically the msdos controller was what made sure that the telescope didn't accidentally swing into the walls/ceiling of the observatory or into the control room at ground level that you were sitting in
|
|
#
?
Nov 2, 2021 00:20
|
|
|
Progressive JPEG posted:i guess it depends on what made or didn't make the cut a lot of the stdlib modules are split into different Yocto packages. Like if you just install "python3", you don't get some stdlib sections like multiprocessing, io, etc. Those all live in their own packages, or can all be installed with a meta-package called "python3-modules". Usually you find this out when you're working on some new Python script on-target, and then you find out that chunks of the stdlib are missing for no apparent reason. Poopernickel fucked around with this message at 00:47 on Nov 2, 2021 |
|
#
?
Nov 2, 2021 00:45
|
|
|
Progressive JPEG posted:btw how common is msdos in embedded environments these days pretty uncommon, Linux has mostly pushed it out. I'm sure somebody's still rocking freedos on an industrial PC somewhere though.
|
|
#
?
Nov 2, 2021 00:46
|
|
|
Progressive JPEG posted:i guess it depends on what made or didn't make the cut pip is it’s own separate package this is as bad as it seems
|
|
#
?
Nov 2, 2021 01:01
|
|
|
i never used any p-langs with yocto so i cant help but built-in toolchain and debug symbol stripping made development/debugging suuuuuper easy our application was just some kernel drivers and a c++ application, though.
|
|
#
?
Nov 2, 2021 01:24
|
|
|
CRIP EATIN BREAD posted:i never used any p-langs with yocto so i cant help This is controllable on a per-package basis in Yocto, if you ever find yourself having to deal with it again.
|
|
#
?
Nov 2, 2021 01:26
|
|
|
Phobeste posted:here's my current (least) favorite embedded linux thing problem: let's say that you want an embedded linux device that has a predefined system on it so you want to use something like buildroot or yocto. let's also say that one thing you want running on it is a modern interpreted-language app. maybe it's javascript, maybe it's python, whatever (i know, i know, just come on this voyage of discovery with me). what do such "modern apps" all have in common? a shitload, an absolute shitload, of dependencies, often for a bad reason, sometimes for a good reason. i hate to say it but use docker. or podman or w/e. qemu-build your p-lang crap into an oci container and then deploy it on fedora iot or similar.
|
|
#
?
Nov 2, 2021 01:59
|
|
|
yeah, the problem is that yocto is designed into being very explicit about dependencies and their licenses. bringing in the free-for-all nightmare that is python and node dependencies is a nightmare.
|
|
#
?
Nov 2, 2021 02:20
|
|
|
Poopernickel posted:This is controllable on a per-package basis in Yocto, if you ever find yourself having to deal with it again. Same with Buildroot as well.
|
|
#
?
Nov 2, 2021 02:28
|
|
|
ah but if you create a platform then licensing can be someone else’s problem! I’m an FAE at a company that makes IoT gateways and in certain use cases customers need like 10 lines of code for protocol translation and there’s problems with every way to do that.
|
|
#
?
Nov 2, 2021 02:30
|
|
|
I once made a tiny midi synth that received midi data via usb and played sounds over a connected speaker. It was built on a raspberry pi platform with raspbian as the OS. As an exercise, I'd like to convert the OS to one that could either store all program data in memory, or on a read only partition on the SD card. At any rate, nothing on the sd card would be writable and I would just mount a ramdisk on /tmp and /var. I'm quite experienced in embedded linux (I used to use montavista when it was a thing) and did some contracting work on buildroot (which I knew pretty well at the time). Is it worth giving yocto a try for a hobbyist project? Or should I stick to buildroot for this project?
|
|
#
?
Nov 2, 2021 03:18
|
|
|
more like yuckto
|
|
#
?
Nov 2, 2021 04:54
|
|
|
do you want to learn yocto? anything with an rpi is going to be how to explore it, there’s already a nice bsp so you just have to put together your puzzle pieces.
|
|
#
?
Nov 2, 2021 05:11
|
|
|
|
| # ? Apr 20, 2024 04:24 |
|
|
here's a nickel kid, buy yourself a real computer
|
|
#
?
Nov 2, 2021 05:37
|
|
