Ths section on "Why not just use an RPi?" is a model of clarity and economy of writing. Incredibly clear, amazingly authoritative. So much to learn here.
So you want to build an embedded Linux system?
61–70 of 113 posts
Re: So you want to build an embedded Linux system?
#62Can someone more knowledgeable than me elaborate on this statement? > when compared to application processors, MMUless microcontrollers are horribly expensive, power-hungry, and slow. What is it about the lack of an MMU that causes a hunger for power?
I might be wrong, but the key point between a microcontroller and a application processor is deterministic execution. When controlling a motor say, it might be vital that your interrupt handler finishes in less than 100 clock cycles. A microcontroller usually[1] doesn't have fancy out-of-order execution, fancy caches etc as that would make the execution less deterministic in time. A MMU would as well. Lacking these f…
None of these application processors I reviewed have out-of-order execution. Cortex-M7 microcontrollers have icache/dcache. You can run bare-metal code on any of these application processors and it will behave more or less like a microcontroller. The lines are really pretty blurry, but the MMU is the big dividing line in my opinion (but it's obviously open for discussion).
Re: So you want to build an embedded Linux system?
#63Earlier quoted context omitted.
He mentioned all the PCB designs were using 4 layer, which is pretty cheap even in prototype quantities.
Choosing a four layer stackup was a really instructive point for the purposes of his blog post, but kind of a bad rule of thumb to carry forward on a professional level. PCBs are built in a sandwich stack. The middle dielectric layer, or "prepreg", is way thicker than the dielectric layers in the outer layers. This doesn't seem like a big deal, but for the speeds that a DDR interface runs at, it creates a higher impe…
Well said. And we're not even mentioning what happens when you start adding other criss-crossing traces for parallel LCDs and cameras into the mix. Those usually creep into the 30-40 MHz range, 18-24 lines per device with no differential lines. And I haven't even thought about USB-C yet.
And you still need to pass radiated emissions testing. Even those right-angle DIMM connectors for the SOMs spray RF noise everywhere when you put video on them.
Re: So you want to build an embedded Linux system?
#64> To this end, I designed a dev board from scratch for each application processor reviewed. Well, actually, many dev boards for each processor: roughly 25 different designs in total. This is an astonishing amount of effort!
The hardware design effort aside: one article to demonstrate why the ARM ecosystem is such a garbage fire. UEFI, anyone?
Re: So you want to build an embedded Linux system?
#65Earlier quoted context omitted.
Yep. I used Fedora and Yocto on iMX6 SoloLite. Both use rpm&dnf. Fedora is much better. In fedora, I feel like at desktop: everything is the same, zero issues. In yocto, I feel like I returned in time for about 20 years: same f *ing bugs, which I reported or fixed years ago, again and again.
Using a package manager on an embedded system is just asking for trouble. Or read-write rootfs, for that matter.
I usually have a r/o rootfs as squashfs with overlayfs for changes. It makes it easy to wipe things back to factory defaults.
Re: So you want to build an embedded Linux system?
#66HOW DO WE THROW MONEY AT JAY for this epic write-up?
Re: So you want to build an embedded Linux system?
#67Very impressive article with lots of knowledge on the metal and OS. Good to know for people who want to work between the OS and the hardware.
Re: So you want to build an embedded Linux system?
#68No, I don't want. I want to use mature distro, with thousands of packages, with known bugs fixed, with fresh software, like Fedora.
Then you want a small desktop system, not an embedded one.
What wrong with that? My first Linux (SuSE) system had 16MB of RAM. I successfully compiled X on it in just few days. Why I should use outdated software on embedded chip with say 256MB of LPDDR?
Re: So you want to build an embedded Linux system?
#69> Yocto is totally the opposite. Buildroot was created as a scrappy project by the BusyBox/uClibc folks. Yocto is a giant industry-sponsored project with tons of different moving parts. You will see this build system referred to as Yocto, OpenEmbedded, and Poky, and I did some reading before publishing this article because I never really understood the relationship. I think the first is the overall head project, the…
I've used Buildroot for the last 8 years and Yocto/OE for the last year.
There is a significantly steeper learning curve for Yocto when compared to Buildroot. Buildroot is faster for the initial build, but often slower than Yocto after the initial build.
Here's what I like about Yocto:
1. It forces you to be organized, everything has a home and things can't conflict with each other.
2. By using Yocto's shared state cache, you can have one central build server and automatically fetch pre-built artifacts on other computers. With this I can get a developer hooked up with everything that they need to build a full system image on their computer in just a few minutes -- and completely build the image at that time.
3. I am confident that incremental changes are built correctly. If you change a build-time parameter of a package in Buildroot, things which depend on that package are not rebuilt. This is not the case with Yocto. This can also result in unfortunate rebuilds of many packages just because of a minor change to, say, glibc. I know that they do not need to be rebuilt but Yocto does not.
4. Buildroot puts built items in a single staging directory. Package install order differences mean that you can overwrite files accidentally. Consider /usr/include/debug.h in two different packages, or something like that.
If you are not explicit with dependencies, the build may actually succeed but it may not be deterministic. If package A happens to be built before package B, you're golden. This does not always happen, and sometimes this is not found until you do a clean and a rebuild. Yocto forces you to be explicit -- the build tree only includes artifacts for recipes which have explicitly been defined.
5. Yocto can use the same tree and shared state cache to build multiple images for a given product without having to clean the world.
I loved buildroot -- it was fast, nimble, and easy to use. It also lets you cut corners and find yourself in situations where builds would unexpectedly fail after a clean. I am also very happy that I took the time to learn how to effectively use Yocto.