So you want to build an embedded Linux system? • Hacker News Board

Re: So you want to build an embedded Linux system?

#101

Post by jaydcarlson » Sat, Oct 17, 2020, 3:59 PM UTC

contingencies wrote: post #78

The article really seems to be more about "so you want to design a custom PCB for a given embedded Linux capable application processor". While it is full of useful information and candid findings, there is usually negative business value in this approach as Jay admits lower down the article: I don’t think most people design PCBs around these raw parts anyway — the off-the-shelf SOMs are so ridiculously cheap (even on…

Please don't quote me out of context: "these raw parts" referred to the MediaTek parts specifically, not all the parts in this review.

The only thing that SOMs provide is a processor + DRAM + PMIC. If you practice and become proficient at designing around application processors, it should take you no longer than 3-4 hours to get this component of the system (the processor, DRAM, and PMIC) laid out when working with these entry-level parts.

SOMs aren't some magical remedy to all the problems. It's still up to you to design the actual system, which takes hundreds of hours. The difference between using a SOM or a raw-chip design is negligible at this point.

I have no problem prototyping on EVKs --- in fact, I link to EVKs for each platform in my review. But a lot of these evaluation boards are pretty crummy to prototype with; some don't have all the pins of the CPU brought out, others use proprietary connectors that are a hassle to adapt to your hardware. You shouldn't be afraid to spend an 8-hour day designing a little breakout board for a part if you're interested in using it in a product that's going to span 6-months' worth of development time.

Of course there are caveats. I'm entirely focused on entry-level parts; if you need a Cortex-A72 with a 128-bit-wide dual-rank DRAM bus, sure, go buy a SOM. Also, it should go without saying that it completely depends on you and your company's core competencies. This article is aimed at embedded designers who are usually working on hardware and software for microcontroller-based platforms. If you work at a pure software shop with no in-house EE talent then this article is likely not relevant to you.

Re: So you want to build an embedded Linux system?

#102

Post by spatular » Sat, Oct 17, 2020, 4:10 PM UTC

vitaminCPP wrote: post #99

> Because Linux-capable application processors have a memory management unit, *alloc() calls execute swiftly and reliably. Physical memory is only reserved (faulted in) when you actually access a memory location. Memory fragmentation is much less an issue since Linux frees and reorganizes pages behind the scenes. This paragraph is confusing to me. - How would a MMU help for malloc to execute "swiftly and reliably" ?…

MMU allows linux to provide a "flat" memory space to each userspace process. This memory space is assembled from 4KB pages that can be randomly dispersed throughout physical memory. Say, you want to malloc() 1MB of memory on a system that's been up for some time. Physical memory may not have a fitting continuos chunk of memory, but virtual memory of a newly created process will always have one, provided that there is enough free pages available.

In other words without MMU all programs share the same memory space, and if it get fragmented, generally you'd have to reboot. With MMU fragmentation can still be an issue, but it's greatly reduced, since each process has its own memory map. And if memory of the process gets framgmented, you can just restart it. If runtime supports object compaction/relocation, then fragmentation may be not an issue at all.

Re access to memory locations -- mostly any direct access to instruction or data memory in userspace program automatically goes through MMU remapping.

Re: So you want to build an embedded Linux system?

#103

Post by joezydeco » Sat, Oct 17, 2020, 4:23 PM UTC

bshanks wrote: post #88

joezydeco wrote: post #13

Standing ovation! This is a decade's worth of knowledge in a single article. I'll be forwarding this one to coworkers and acquaintances when they ask about how to do this kind of stuff. I can understand why the author focuses on cheap entry-level parts. It's cheap and it's fun. He also kind of dismisses the major SOMs for this reason so maybe there can be a more comprehensive review of those (I build almost exclusive…

Just out of curiosity, in your opinion, which are the major SOMs that you would consider for a 5+ year expected run lifetime?

It’s two-pronged. You need to find a chip line that has manufacturer guarantees for a long span, then a SOM integrator that will also guarantee a time span using that part.

I’ve been happy with NXP (Freescale) for the former, obviously being a large automotive supplier has a benefit.

For the SOM I’ve recently been using Toradex. They do a great job of making their SOMs comply to a common signal layout at the connector. I also recommend Boundary Devices. TechNexion is also interesting if you need a smaller footprint. They’re the group that also ships as WandBoard.

Re: So you want to build an embedded Linux system?

#104

Post by iainctduncan » Sat, Oct 17, 2020, 9:51 PM UTC

Wow, what a resources. Thanks so much!

Does anyone have suggestions if one wanted a super fast single core? i.e. to make something for a software synth where the bottleneck is likely to be speed of a single core?

Re: So you want to build an embedded Linux system?

#105

Post by hifly » Sat, Oct 17, 2020, 11:22 PM UTC

Why no mention of gentoo (or funto)? I concede very little experience of yocto, etc, but I’ve a fairly complex system I maintain for both x86 and amd64 custom boards, all with quite heavily patched packages. I was challenged to add an imx6 board to the mix but I concede it was rather straight forward... for kicks I also switched out uclinux-ng for musl and switched up binutils versions, but it was all fairly painless...??

If you are familiar with gentoo it has a package manager called portage. You type “emerge packagename” and it installs it. Prepend ROOT=blah and it installs it in that dir instead!

So your build scripts are pretty trivial. Just write a bunch of emerge lines and you are done. Install in your new root, then package that ROOT. Simples!

Building from source could be slow, so cache binaries once built. Subsequent binaries will be used by adding “-k” to emerge above.

Profiles allow you to build target versions of software, E.g. customising compile flags or software versions. I use both a libc and a processor profile. The arch profile is also split between host and target, so for example static libs might be installed on host but not in target.

I used an overlayfs system to trim the delivery.

I think the big difference is I can rely on this huge distribution. Yet if I need some platform patch I need only drop it in my patches directory and hit rebuild. Put the patches dir in git and I’ve got a trackable distribution!

Comments?

Re: So you want to build an embedded Linux system?

#106

Post by rcxdude » Sun, Oct 18, 2020, 11:37 AM UTC

hifly wrote: post #105

Why no mention of gentoo (or funto)? I concede very little experience of yocto, etc, but I’ve a fairly complex system I maintain for both x86 and amd64 custom boards, all with quite heavily patched packages. I was challenged to add an imx6 board to the mix but I concede it was rather straight forward... for kicks I also switched out uclinux-ng for musl and switched up binutils versions, but it was all fairly painless…

Sounds like gentoo has improved their cross-compilation story. I had several attempts at getting a cross compilation toolchain running on gentoo and they all failed. yocto was actually the first time I succeeded at building a cross compiler in any form, but this was a fair few years ago at this point.

To be honest, bitbake mostly seems to be a less principled/polished version of portage or nix. I would much prefer an embedded toolchain based on either of them than dealing with bitbake's syntax and quirks. The one thing that seems relatively unique to bitbake is layers, which essentially mean you can avoid making modifications to the base layer while still being able to patch/tweak just about anything in the build. For embedded stuff, where you're basically almost always working off of someone else's patches to an upstream project which you are then patching yourself, and all of them can update independently, it's the only way of keeping somewhat sane (but the action-at-a-distance can make for difficult debugging, which is something I would wish bitbake was better at: there's no way to query e.g. 'what statement in what file added this compiler flag?', and the set of possible files can be huge).

Re: So you want to build an embedded Linux system?

#107

Post by rcxdude » Sun, Oct 18, 2020, 11:50 AM UTC

stefan_ wrote: post #86

fullstop wrote: post #69

Earlier quoted context omitted.

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 c…

These are all excellent points, it just saddens me that embedded has still not moved past the "recursive Makefile" phase. Part of that fault lies with the hardware manufacturers. They are invariably hardware companies that don't value software. They pick an open-source project like OpenWRT or Buildroot and literally hack at it until the resulting monster can build an image for a reference system that can stay up just…

Bitbake is a bit further than 'recursive makefile', it's much more along the lines of a package manager like nix or portage (though it's less well designed in most aspects, the build file syntax is insane and debugging it is a nightmare. I think it's grown the necessary features instead of stepping back and understanding the problem). And it's important to realise it's mostly focused on building packages like a linux distribution, even if the systems are rarely managed by installing/uninstalling packages. This is where the whole idea of taking an upstream tar or repo and patching it together comes from, and it makes perfect sense when 90% of your workflow is 'take someone else's code and modify it slightly to integrate into your system', especially when that code gets updated (it's still not painless, but you have some hope of doing it). When you're google and can afford to rewrite huge parts of the system and have no need for compatibility then you can make a more nicely integrated system, but most embedded applications cannot afford this.

Re: So you want to build an embedded Linux system?

#108

Post by vitaminCPP » Sun, Oct 18, 2020, 1:30 PM UTC

spatular wrote: post #102

vitaminCPP wrote: post #99

> Because Linux-capable application processors have a memory management unit, *alloc() calls execute swiftly and reliably. Physical memory is only reserved (faulted in) when you actually access a memory location. Memory fragmentation is much less an issue since Linux frees and reorganizes pages behind the scenes. This paragraph is confusing to me. - How would a MMU help for malloc to execute "swiftly and reliably" ?…

MMU allows linux to provide a "flat" memory space to each userspace process. This memory space is assembled from 4KB pages that can be randomly dispersed throughout physical memory. Say, you want to malloc() 1MB of memory on a system that's been up for some time. Physical memory may not have a fitting continuos chunk of memory, but virtual memory of a newly created process will always have one, provided that there is…

Thanks. I realized that there are several types of MMU. I was thinking of the simple MMU (on 32bit MCU) that limit memory access. Not the one that provides the illusion of virtual addressing.

Re: So you want to build an embedded Linux system?

#109

Post by contingencies » Sun, Oct 18, 2020, 8:26 PM UTC

jaydcarlson wrote: post #101

contingencies wrote: post #78

The article really seems to be more about "so you want to design a custom PCB for a given embedded Linux capable application processor". While it is full of useful information and candid findings, there is usually negative business value in this approach as Jay admits lower down the article: I don’t think most people design PCBs around these raw parts anyway — the off-the-shelf SOMs are so ridiculously cheap (even on…

Please don't quote me out of context: "these raw parts" referred to the MediaTek parts specifically, not all the parts in this review. The only thing that SOMs provide is a processor + DRAM + PMIC. If you practice and become proficient at designing around application processors, it should take you no longer than 3-4 hours to get this component of the system (the processor, DRAM, and PMIC) laid out when working with t…

Hi Jay, that wasn't my intent. Thanks for clarifying your scoped comment. Your post is very interesting. However, I believe the core point regarding the potential commercial questionability of embarking on EE design work with a processor part-centric mentality still stands. As you point out, it is sometimes justified. Few people outside of Asia have competent "in-house EE talent" idling in their organization.

Re: So you want to build an embedded Linux system?

#110

Post by sorisos » Sun, Oct 18, 2020, 8:57 PM UTC

pjbk wrote: post #80

nickysielicki wrote: post #34

> 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…

IMHO with modern architectures these days, and from the last couple of years in particular, if you start feeling the need for something like Yocto I'd rather use a full blown distribution like Debian or Arch Linux if its available for your platform. I have tried Yocto through the years and deployed a bunch of projects with it. Although it gives you the sense that it has a more coherent environment than Buildroot, I f…

Using a slow release distro as debian (either directly or as a reference) also have the benefit of compatible versions. I.e. no need trying to figure out how to get both $A and $B compile against a common library.