8 ms·

So you want to build an embedded Linux system? (2020)

233 points by sebg 5y ago

deleted 5y ago
[deleted]
nickysielicki 5y ago
Previous thread, 2020: https://news.ycombinator.com/item?id=24800037 https://news.ycombinator.com/item?id=24800037 This article is awesome and has a ton of great knowledge, but it’s a little dismissive of openembedded, and if you click through to the previous thread you’ll see a lot of people come to it’s defense.
- pmorici 5y ago
  The authors description of the two has been consistent with my experience. Buildroot is a lot easier to get going with. There might be good reasons to use yacto but if you are new to all this I wouldn’t start their.
  - deleted 5y ago
    [deleted]
- voakbasda 5y ago
  Lots of good replies on that thread. I have been doing embedded development for 30 years, and Yocto is the best build system that I have used for managing large embedded systems. If you need to professionally manage multiple distributions across menagerie of different host and target machines, there simply is no other meaningful choice that operates at its scale. I first encountered BitBake before either the OpenEmbedded or Yocto projects existed. Since then, I have done professional embedded systems consulting for dozens of platforms, using Yocto almost exclusively in recent years. I have done everything with it, from simple board bring ups to implementing re-usable BSP layers used by multiple product families. I might be a little biased here, but I have used all of the other popular embedded build systems too. Other choices still have their place for smaller and simpler projects, just as one might choose something smaller than Linux for the kernel. However, Yocto and Linux have attracted unparalleled open source development and support resources. Other projects simply cannot hope to match their established output. These projects will not go away any time soon, which means LTS releases and stable infrastructure to host them, regardless of individual players or projects coming or going. What other choice exists with that kind of backing? For commercial projects that grow beyond a certain scope (i.e. most modern full-featured embedded systems), other choices simply do not match its existing capabilities. Of course, you can always fork a full server/desktop Linux distribution like Debian, but dressing up a standard distribution in embedded clothing often requires more customization. That comes with develop and maintenance costs, though I admit the lines do start to blur at a certain point. The BitBake/OpenEmbedded/Yocto/Poky ecosystem is huge and poses a long and steep learning curve, but it offers customization and extensibility unparalleled by any other offering that I have had the (mis)fortune of using in my career. The same is true for the Linux kernel ecosystem, right? Them's the trade-offs we make.
  - eschneider 5y ago
    Yocto is fantastic and well documented but getting started is hard and nothing makes much sense until you fully understand it. Once it clicks, though, it’s great. Totally worth the effort.
  - synergy20 5y ago
    I have been doing embedded linux for 22 years and sadly Openembedded/Yocto has been the worst build system ever. It's the Gentoo for embedded(where is Gentoo nowadays), over-engineered so much for most use cases unless you work at Windriver or Amazon that deals with lots of different boards from different vendors and you have unlimited resource to work with the complexity. If I got a codebase that uses Yocto/Openembedded, the first thing I do is to find the related patches there and convert them to buildroot/debian/openwrt/LTIB(old stuff)/etc depends on the hardware spec. I wasted too much time when there is a bug in Openembedded that could take forever to debug, layer over layer, override over override on those meta mazes, it always feels like you're fighting with openembedded/yocto itself instead of getting your work done. I since have been avoiding openembedded/yocto at all costs.
    - dgfitz 5y ago
      There is a learning curve, but when crossed, it’s a beautiful system.
      - synergy20 5y ago
        same could be said to gentoo, from experience over 2 decades and at least 5 projects involved yocto(back then it was openembedded), for the same project, yocto will take 5x more time/efforts per my measurement. yes adding stuff is fine, building is the slowest but I can wait, however if something went wrong, be prepared to debug openembdded/yocto-itself for days, this does not exist in other alternatives: you debug your own code, not the framework there. It's over engineered, over rated, great for consultants to charge hours, terrible for companies(except for big guns) to deliver product fast. Sorry I have a strong opinion here but it just wasted too much of my time in the past.
- PragmaticPulp 5y ago
  > but it’s a little dismissive of openembedded I don't really see it in the article. I use OpenEmbedded for my projects, but I never recommend it to beginners as the place to start. Buildroot is unquestionably easier to get started with and use for one-off projects (unless you're trying to use vendor-provided Yocto/OE layers, in which case obviously it's not an option). The article's conclusion about Yocto is spot-on, in my opinion: If you're quickly iterating, Buildroot is the way to go.
anthk 5y ago
>. In Linux, you get a first-class network stack, plus tons of rock-solid userspace libraries that sit on top of that stack and provide application-level network connectivity. JimTCL is very fun for that, and it would run on limited machines. Ok, not totally TCL compatible, and no TK, but you have (WIP) SDL2 bindings, and SDL2 would work perfectly on a display handled by fbdev/KMS. > but blending and other advanced 2D graphics technology can really bog things down SDL2 can be really fast at low res displays such as 320x240. If not, EFL from Enlightenment for sure could that fast enough.
- gaze 5y ago
  EFL should never be recommended as a serious option.
  - pjmlp 5y ago
    Depends, maybe when the recommender is serious about being exploited. /s
lsllc 5y ago
I'm curious how the landscape has changed with the chip shortages since this was written. My all time favorite SoM was the CHIP Pro, but sadly at $7 (or was it $13?) it was indeed too good to be true and the company went out of business.
- joezydeco 5y ago
  Do you mean: have new readily-available parts been introduced in the wake of the current supply shortages? The answer is no.
- bigiain 5y ago
  I have a pile of them in my drawer, as many as I could get my hands on (maybe 8 or 12?) They're great. In my head they were "something that had the stuff that annoyed me about RaspberryPis fixed". I should dig some out and see if there's a way to update the OS to something recent-ish. I think I've still got a cluster of 4 of them, 3 running RTL SDR and one analysing the signals and pulling interesting data out. (Last data file I have here from that is Dec 2018...)
- PragmaticPulp 5y ago
  Most of the SoCs in the article were already several years old when it was written. The article focuses on parts that are (relatively speaking) easily solderable by hand. Most new SoCs focus on small size and will come in 0.5mm pitch BGA packages or smaller, where PCBs start becoming sharply more expensive and placement requires a decent amount of skill. > My all time favorite SoM was the CHIP Pro, but sadly at $7 (or was it $13?) it was indeed too good to be true and the company went out of business. The CHIP was just a cheap board based on the Allwinner R8, which is basically an Allwinner A13, which is in the same product family as the Allwinner A33 in the article. There are actually a lot of cheap SBCs based on the cheap Allwinner parts out there. The CHIP had great execution and some novel in-browser upgrade features, but I don't know how they planned to make money by selling things basically at cost. Apparently they didn't have any idea either, because they spontaneously went out of business and disappeared.
  - rasz 5y ago
blueflow 5y ago
I have issues with the section "Microcontroller vs Microprocessor: Differences" Microprocessors are just the CPU, usually with the system bus wired out. Microcontrollers are combined systems, which include a processor and usually some kind of firmware storage and RAM. You can usually differentiate them by whether their pins are address/data lines or gpio-like. > microprocessors have a memory management unit The 8086 didn't. Having an MMU seems unrelated to the MCU/MPU distinction... At least, this was my knowledge until now. Is this like "crypto" where the meaning changed while i was not paying attention?
- seniorivn 5y ago
  a lot of people have been calling desktop computers "processors", does it mean that the meaning of the word has changed?
  - blueflow 5y ago
    because thats correct for most x86-compatible computers, x86 is or was the dominant desktop architecture.
- marcan_42 5y ago
  Microprocessors in the traditional sense no longer exist. All modern microprocessors are actually SoCs (yes, even Intel ones at least to a partial extent). And all microcontrollers are SoCs by strict definition, but we don't usually call them that. So really the more practical terminology difference should be SoC vs. microcontroller.
  - phlipski 5y ago
    Agreed. To add to that - I think what Jay was trying to highlight is the difference between chips that can generally run Linux (which generally requires an MMU) and those that run an RTOS. Is this an exact line of demarcation with no blurry edges? No. But it seems to work for me. Maybe a better way to think of this is - does the system have external DRAM (if so run linux) or not - if so run RTOS. Our of curiosity - does anyone still sell a (by strict definition) a true "micro-processor"?
shaicoleman 5y ago
(Oct 2020)
smartineng 5y ago
Why to build Linux you always have to start with Linux, is there anyone who bootrapped it from freebsd or any other OS, minimalistic systems like https://niedzejkob.p4.team/bootstrap/ https://niedzejkob.p4.team/bootstrap/ , etc?
- cyberbanjo 5y ago
  good question, arch build scripts require very miniminal dependencies, I wouldn't be surprised if it's very easy to install from a BSD https://github.com/archlinux/arch-install-scripts https://github.com/archlinux/arch-install-scripts
  - smartineng 5y ago
    Comparing to https://github.com/fosslinux/live-bootstrap https://github.com/fosslinux/live-bootstrap your pseudo minimalistic arch pacstrap or Debian debootstrap are over fat of binary seeds and still you cannot get rid of Linux env in building the crusial packages.

233 points by sebg 5y ago

deleted 5y ago

[deleted]

Previous thread, 2020: https://news.ycombinator.com/item?id=24800037 https://news.ycombinator.com/item?id=24800037 This article is awesome and has a ton of great knowledge, but it’s a little dismissive of openembedded, and if you click through to the previous thread you’ll see a lot of people come to it’s defense.

pmorici 5y ago
The authors description of the two has been consistent with my experience. Buildroot is a lot easier to get going with. There might be good reasons to use yacto but if you are new to all this I wouldn’t start their.
- deleted 5y ago
  [deleted]
voakbasda 5y ago
Lots of good replies on that thread. I have been doing embedded development for 30 years, and Yocto is the best build system that I have used for managing large embedded systems. If you need to professionally manage multiple distributions across menagerie of different host and target machines, there simply is no other meaningful choice that operates at its scale. I first encountered BitBake before either the OpenEmbedded or Yocto projects existed. Since then, I have done professional embedded systems consulting for dozens of platforms, using Yocto almost exclusively in recent years. I have done everything with it, from simple board bring ups to implementing re-usable BSP layers used by multiple product families. I might be a little biased here, but I have used all of the other popular embedded build systems too. Other choices still have their place for smaller and simpler projects, just as one might choose something smaller than Linux for the kernel. However, Yocto and Linux have attracted unparalleled open source development and support resources. Other projects simply cannot hope to match their established output. These projects will not go away any time soon, which means LTS releases and stable infrastructure to host them, regardless of individual players or projects coming or going. What other choice exists with that kind of backing? For commercial projects that grow beyond a certain scope (i.e. most modern full-featured embedded systems), other choices simply do not match its existing capabilities. Of course, you can always fork a full server/desktop Linux distribution like Debian, but dressing up a standard distribution in embedded clothing often requires more customization. That comes with develop and maintenance costs, though I admit the lines do start to blur at a certain point. The BitBake/OpenEmbedded/Yocto/Poky ecosystem is huge and poses a long and steep learning curve, but it offers customization and extensibility unparalleled by any other offering that I have had the (mis)fortune of using in my career. The same is true for the Linux kernel ecosystem, right? Them's the trade-offs we make.
- eschneider 5y ago
  Yocto is fantastic and well documented but getting started is hard and nothing makes much sense until you fully understand it. Once it clicks, though, it’s great. Totally worth the effort.
- synergy20 5y ago
  I have been doing embedded linux for 22 years and sadly Openembedded/Yocto has been the worst build system ever. It's the Gentoo for embedded(where is Gentoo nowadays), over-engineered so much for most use cases unless you work at Windriver or Amazon that deals with lots of different boards from different vendors and you have unlimited resource to work with the complexity. If I got a codebase that uses Yocto/Openembedded, the first thing I do is to find the related patches there and convert them to buildroot/debian/openwrt/LTIB(old stuff)/etc depends on the hardware spec. I wasted too much time when there is a bug in Openembedded that could take forever to debug, layer over layer, override over override on those meta mazes, it always feels like you're fighting with openembedded/yocto itself instead of getting your work done. I since have been avoiding openembedded/yocto at all costs.
  - dgfitz 5y ago
    There is a learning curve, but when crossed, it’s a beautiful system.
    - synergy20 5y ago
      same could be said to gentoo, from experience over 2 decades and at least 5 projects involved yocto(back then it was openembedded), for the same project, yocto will take 5x more time/efforts per my measurement. yes adding stuff is fine, building is the slowest but I can wait, however if something went wrong, be prepared to debug openembdded/yocto-itself for days, this does not exist in other alternatives: you debug your own code, not the framework there. It's over engineered, over rated, great for consultants to charge hours, terrible for companies(except for big guns) to deliver product fast. Sorry I have a strong opinion here but it just wasted too much of my time in the past.
PragmaticPulp 5y ago
> but it’s a little dismissive of openembedded I don't really see it in the article. I use OpenEmbedded for my projects, but I never recommend it to beginners as the place to start. Buildroot is unquestionably easier to get started with and use for one-off projects (unless you're trying to use vendor-provided Yocto/OE layers, in which case obviously it's not an option). The article's conclusion about Yocto is spot-on, in my opinion: If you're quickly iterating, Buildroot is the way to go.

anthk 5y ago

>. In Linux, you get a first-class network stack, plus tons of rock-solid userspace libraries that sit on top of that stack and provide application-level network connectivity. JimTCL is very fun for that, and it would run on limited machines. Ok, not totally TCL compatible, and no TK, but you have (WIP) SDL2 bindings, and SDL2 would work perfectly on a display handled by fbdev/KMS. > but blending and other advanced 2D graphics technology can really bog things down SDL2 can be really fast at low res displays such as 320x240. If not, EFL from Enlightenment for sure could that fast enough.

gaze 5y ago
EFL should never be recommended as a serious option.
- pjmlp 5y ago
  Depends, maybe when the recommender is serious about being exploited. /s

lsllc 5y ago

I'm curious how the landscape has changed with the chip shortages since this was written. My all time favorite SoM was the CHIP Pro, but sadly at $7 (or was it $13?) it was indeed too good to be true and the company went out of business.

joezydeco 5y ago
Do you mean: have new readily-available parts been introduced in the wake of the current supply shortages? The answer is no.
bigiain 5y ago
I have a pile of them in my drawer, as many as I could get my hands on (maybe 8 or 12?) They're great. In my head they were "something that had the stuff that annoyed me about RaspberryPis fixed". I should dig some out and see if there's a way to update the OS to something recent-ish. I think I've still got a cluster of 4 of them, 3 running RTL SDR and one analysing the signals and pulling interesting data out. (Last data file I have here from that is Dec 2018...)
PragmaticPulp 5y ago
Most of the SoCs in the article were already several years old when it was written. The article focuses on parts that are (relatively speaking) easily solderable by hand. Most new SoCs focus on small size and will come in 0.5mm pitch BGA packages or smaller, where PCBs start becoming sharply more expensive and placement requires a decent amount of skill. > My all time favorite SoM was the CHIP Pro, but sadly at $7 (or was it $13?) it was indeed too good to be true and the company went out of business. The CHIP was just a cheap board based on the Allwinner R8, which is basically an Allwinner A13, which is in the same product family as the Allwinner A33 in the article. There are actually a lot of cheap SBCs based on the cheap Allwinner parts out there. The CHIP had great execution and some novel in-browser upgrade features, but I don't know how they planned to make money by selling things basically at cost. Apparently they didn't have any idea either, because they spontaneously went out of business and disappeared.
- rasz 5y ago

blueflow 5y ago

I have issues with the section "Microcontroller vs Microprocessor: Differences" Microprocessors are just the CPU, usually with the system bus wired out. Microcontrollers are combined systems, which include a processor and usually some kind of firmware storage and RAM. You can usually differentiate them by whether their pins are address/data lines or gpio-like. > microprocessors have a memory management unit The 8086 didn't. Having an MMU seems unrelated to the MCU/MPU distinction... At least, this was my knowledge until now. Is this like "crypto" where the meaning changed while i was not paying attention?

seniorivn 5y ago
a lot of people have been calling desktop computers "processors", does it mean that the meaning of the word has changed?
- blueflow 5y ago
  because thats correct for most x86-compatible computers, x86 is or was the dominant desktop architecture.
marcan_42 5y ago
Microprocessors in the traditional sense no longer exist. All modern microprocessors are actually SoCs (yes, even Intel ones at least to a partial extent). And all microcontrollers are SoCs by strict definition, but we don't usually call them that. So really the more practical terminology difference should be SoC vs. microcontroller.
- phlipski 5y ago
  Agreed. To add to that - I think what Jay was trying to highlight is the difference between chips that can generally run Linux (which generally requires an MMU) and those that run an RTOS. Is this an exact line of demarcation with no blurry edges? No. But it seems to work for me. Maybe a better way to think of this is - does the system have external DRAM (if so run linux) or not - if so run RTOS. Our of curiosity - does anyone still sell a (by strict definition) a true "micro-processor"?

shaicoleman 5y ago

(Oct 2020)

smartineng 5y ago

Why to build Linux you always have to start with Linux, is there anyone who bootrapped it from freebsd or any other OS, minimalistic systems like https://niedzejkob.p4.team/bootstrap/ https://niedzejkob.p4.team/bootstrap/ , etc?

cyberbanjo 5y ago
good question, arch build scripts require very miniminal dependencies, I wouldn't be surprised if it's very easy to install from a BSD https://github.com/archlinux/arch-install-scripts https://github.com/archlinux/arch-install-scripts
- smartineng 5y ago
  Comparing to https://github.com/fosslinux/live-bootstrap https://github.com/fosslinux/live-bootstrap your pseudo minimalistic arch pacstrap or Debian debootstrap are over fat of binary seeds and still you cannot get rid of Linux env in building the crusial packages.