14 ms·
So you want to build an embedded Linux system?
- pjc50 6y ago> 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!
- drran 6y agoNo, I don't want. I want to use mature distro, with thousands of packages, with known bugs fixed, with fresh software, like Fedora.
- rfrey 6y agoThis comment doesn't make any sense to me - it's like responding to an article titled "So, you want to build a transistor radio from scratch?" with "No, I want the latest iPod Touch".
- drran 6y agoArticle title doesn't contain "from scratch", so I will rewrite your example as "So, you want to build AM radio?" and my response will be "No, I want to build FM radio, because of tons of FM radio stations available to listen".
- rfrey 6y agoThe article isn't even close to being about building a linux distribution. It's about embedded electronics engineers moving from microcontrollers with custom embedded firmware to SBCs using minimal linux for embedded systems. So accepting your revision, the response would be "no, I want to buy a stereo system".
- bryanlarsen 6y agoThere are lots of embedded systems beefy enough that Fedora is an appropriate choice.
- jnwatson 6y agoNot really. Fedora IoT only supports x86_64, aarch64, and armhfp, which has some intersection with this space, but not a lot. Regardless, that wasn't really the point of the article.
- bryanlarsen 6y agoThere is lots of embedded that uses x86 or arm. Lots of embedded isn't significantly power or size constrained and volumes are very low so software development costs dominate over hardware costs. But agreed, those aren't the point of the article. "Embedded" is a big space.
- admax88q 6y agoSomething that is not power nor size constrained doesn't really fit most people's definition of "Embedded."
- bryanlarsen 6y agoExample: the computer in a CNC machine.
- NikolaeVarius 6y agoJust because you can doesn't mean you should
- m4r35n357 6y agoYou want "to use mature distro, with thousands of packages, with known bugs fixed, with fresh software, like Fedora." on an embedded system. Really?
- drran 6y agoYep. 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.
- ausjke 6y agoIt really depends on your hardware, there are many systems with limited storage and memory where Fedora is impossible to fit. I do believe Yocto is the Gentoo for embedded linux, which is over-engineered to hell. The good news is that, unless you have some very special requirement, just use buildroot, which is 1/100 of the complexity and get the job done well. KISS.
- 05 6y agoUsing a package manager on an embedded system is just asking for trouble. Or read-write rootfs, for that matter.
- fullstop 6y agoI usually have a r/o rootfs as squashfs with overlayfs for changes. It makes it easy to wipe things back to factory defaults.
- devthrowawy 6y agoWell you can have that, those are the repositories mostly, which you have access to when building your linux. So you have a mature source of code, but what makes a distro 'mature' isn't really of any value in the embedded space. Kernel, core utils, init system, some packages and you custom code, and your done. You now have your own distro, code is mature, boots really fast and is probably more stable and secure that the mature distro which is trying to be everything under the sun. When you only need the linux to do one specific thing you can make something that is really rock solid and actually have a sense of everything that is going on under the hood. Having some guy whose, honestly mostly uneducated, solution is to just throw fedora on there is going to create a crap system.
- joezydeco 6y agoThen you want a small desktop system, not an embedded one.
- drran 6y agoWhat 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?
- varjag 6y agoWhat does it have to do with outdated software? You still use kernel version and userspace libraries of your choice - arguably more flexibly and up to date than on any mainstream distro.
- tenebrisalietum 6y agoUm .... OpenWRT?
- drran 6y agoYep. Good choice for systems with 16-64Mb of RAM.
- cushychicken 6y agoJay also did a great rundown of $1 microcontrollers a few years ago: https://jaycarlson.net/microcontrollers/ https://jaycarlson.net/microcontrollers/ This embedded Linux article is a really worthy followup!
- jtuente 6y agoPrevious discussions on that: https://news.ycombinator.com/item?id=15633785 https://news.ycombinator.com/item?id=15633785 https://news.ycombinator.com/item?id=19851744 https://news.ycombinator.com/item?id=19851744 https://news.ycombinator.com/item?id=24426882 https://news.ycombinator.com/item?id=24426882
- ngold 6y agoThanks for the link on microcontrollers. Embedded writeups and microcontrollers are super fascinating.
- an_d_rew 6y agoWow, what a great write up – thank you, Jay! I have seen this exact confusion with many friends and colleagues in the past who don’t understand just how different a micro controller is from an application processor, and what a difference it makes and even simple things (ha ha simple) like circuit board layout. And application programmers are so used to things like virtual memory and thinking or hoping the system, never mind an application garbage collector, will manage memory that when you suddenly tell them their stack is limited to a few kilobytes and please please limit your heap usage, too they’re … Cast adrift!
- corty 6y agoI especially liked the section on DDR memory PCB routing and how it is less complicated than people make it out to be. At least for this application. Makes one want to try something like this
- ianhowson 6y agoHuh. I almost missed that, but can confirm. On a past project we had two DDR RAMs and a NOR Flash on the same bus. There was one hardware engineer, and he laid out the memory subsystem in about a day. (The power supplies were dramatically more complicated.) It almost worked first time. I noticed about one memory error per day per device, which I repro'd with repeated `md5sum /tmp/largefile`. We just dropped the clock rate in U-Boot. Failed devices? Heat it up with a hot air gun for a while. Fixed 90% of them. Still doesn't work? Throw it away. There are no mysteries, just stuff you don't know yet.
- joezydeco 6y agoThe part not discussed is how many PCB layers (signal, ground, more signal, more ground, etc) you need when laying down DDR. If you are playing with a 2x2" EVK then 8 or 10 layers isn't a budgetary problem. When the board starts getting larger it's now it's a huge cost adder as opposed to low speed 2-layer PCB. This is why designers switch to doing it with SOMs. The SOM can be a high-speed part and the carrier PCB is cheap and slow.
- rcxdude 6y agoHe mentioned all the PCB designs were using 4 layer, which is pretty cheap even in prototype quantities.
- cushychicken 6y agoChoosing 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 impedance return loop for whatever you end up routing on layer 3. (Typically DQs, in my experience.) You can avoid this entirely by building with a six layer stackup, and routing your DRAM signals on layers 1/2/3, keeping layer 2 as an unbroken ground plane. The result: nice, low impedance return tracks. Yes, Jay is right - most of the time, this doesn't create problems. But when it does, it's pretty challenging to fix without a board spin, and when you're doing this professionally, that loses you time, creates risk, and is generally hella stressful.
- joezydeco 6y agoStanding 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 exclusively with these), but that's probably out of his view. Going with a mystery AllWinner part is really compelling, but I can't go into production (with a 5+ year expected run lifetime) on that.
- bshanks 6y agoJust out of curiosity, in your opinion, which are the major SOMs that you would consider for a 5+ year expected run lifetime?
- Cerium 6y agoI'm working on a project that is using Nvidia Jetson modules. The Jetson TX2i is supported to 2028.
- PragmaticPulp 6y agoIf product lifetime is a concern, it's important to pick a vendor that guarantees product availability through a certain date. Either that, or you need to be prepared to do a lifetime buy of all of the parts you'll ever need when the EOL is announced. Companies like NXP will guarantee certain parts for at least 10 years after launch date. Search for 'i.MX' on this page to see their date guarantees: https://www.nxp.com/products/product-information/product-longevity:PRDCT_LONGEVITY_HM https://www.nxp.com/products/product-information/product-lon...
- joezydeco 6y agoIt’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.
- karmicthreat 6y agoI have been doing embedded for a number of years. I'm the only fulltime SWE at my company and it just gets exhausting managing 5 different products on completely different code bases/technologies. Plus a web portal that does device management and reporting. So a big thing people should consider when building something to scratch. Am I making something I can use again when I make my next product. Its a much higher mental load if you have no commonality between products. Also it can cause problems for sales, support and management when they have to remember nitty gritty details about each of your very divergent products.
- jpm_sd 6y agoSounds like a nightmare. At a casual glance it looks like your products are mostly [processor] connected to a network of CAN and/or 4-20mA devices. Not possible to back-port newer control modules to older product lines? That said, impressive that you are handling all of it on your own. Hire somebody!
- karmicthreat 6y agoI have a couple contractors I bring in part time when I need some heavy lifting on the embedded or web side. I have back-ported somethings, but really a large chunk of the products had terrible technical decisions before I started. I spent the first couple years just dragging the company back from the technical and financial brink. I'm slowly eliminating old products from our sales sheet in favor of ones I engineered. So it will eventually be ok.
- creeble 6y agoSounds like my day job of the last 10 years or so. Although I'm mostly focused on the app code, I spent about four months this year debugging various wifi stacks (one for each generation of product). Only to have most of the problems fixed by moving all products to a 5.7 kernel base. Which was no easy project in itself, but mostly not my work. In my experience, the processor, memory, flash, and all other things combined are trivial compared to getting reliable wifi.
- 6y ago
- Squonk42 6y agoSame here! I am forwarding this article to all my coworkers! I am currently using the Allwinner V3s, and the review is covering this part accurately.
- jpm_sd 6y agoGreat article. He sings the praises of Linux memory management and virtual memory, which are unavailable on a microcontroller. Would be interested in comments on the downsides of swapping in a system with a small amount of onboard Flash that may wear out.
- seppel 6y agoWhy would you enable swap?
- jsmith45 6y agoI assume he sees "virtual memory", and jumps to thinking "swap". Which is rather common, but arguably a mistake. Virtual memory is what allows for copy on write pages when forking. It is the preferred basis for implementing memory mapped files. It allows for sharing a single copy of shared library in ram, without causing everything to break if one program decides it wants to patch "its" copy of the library in memory. Yeah sure it allows for paging out anonymous memory too, but that is hardly its sole function.
- jpm_sd 6y agoCorrect, this was my (apparently very widespread) misconception that I just corrected with a bit o' googlin'
- joezydeco 6y agoSwapping to EEPROM is a bad idea - not just on wear but it's a massive I/O bottleneck. If you're out of RAM on an embedded project, rethink your design or add more RAM (if time and budget allow)
- hak8or 6y agoThis is an absurdly impressive writeup, and it's great that it shows that there are SIP's out there for such low pricing (sub $5 for a ic whuch includes a decent few MB of dram is great, albeit single core). Many years back, I also did a writeup (much less intense) that goes more so into what it took for me to get Linux running on an IMX6 based Soc on the software end, including how I found a bug in the USB clock tree in the kernel for the IMX6, how I debugged it, and how I mainlined it (my first and only kernel commit to mainline). https://brainyv2.hak8or.com/ https://brainyv2.hak8or.com/ Such projects are increadibly satisfying to work on, it makes you feel much more competent when working with embedded systems. There is much less "black magic" going on.
- Const-me 6y agoIf you want Wi-Fi, FCC certification is hard and expensive. For an off-the-shelf SBC you don’t have to, only need to place a sticker with FCC ID of the SBC. When embedding an SBC, you can fork the firmware from whatever Debian/Android/etc. variant is best supported by that SBC. Stripping down working and well tested Linux image is much easier than building a new OS image from scratch.
- joezydeco 6y agoThere are precertified laydown modules that can also do this. Laird (LSResearch), Telit, Redpine, and Murata are big producers of these.
- nickysielicki 6y ago> 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 second is the set of base packages, and the third is the… nope, I still don’t know. Someone complain in the comments and clarify, please. Bitbake is the generic build system around which openembedded recipes (for particular packages) were implemented. Anyone could create a distro using those recipes, dates to the early to mid 2000s. Yocto was/is a project of the Linux Foundation, basically a working group, where they looked at the state of embedded linux and said, "We want to contribute to this project with documentation and more recipes", starting externally but with hopes to get it mainlined. Poky was/is their reference distro for this effort. Nowadays all the packages contributed by the Yocto project have been consolidated into openembedded, but poky remains the reference distro. tl;dr: Yocto is first and foremost an organization of people. Bitbake is the build system. OpenEmbedded is a community of distro-agnostic build system recipes. Poky is a distro maintained by the Yocto organization utilizing OpenEmbedded recipes.
- creeble 6y agoFWIW, I still use ltib (originally a Freescale open-source build environment) and it's mostly great. Fewer layers of abstraction, builds all the source modules using essentially the "linux-from-scratch" system, with .rpm intermediaries that get installed to a rootfs. I played with Bitbake, but the learning curve seemed much worse than ltib. Edit: s/yocto/Bitbake/
- fullstop 6y agoI'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.
- trashedpanda 6y agoGood read! Some others that I have enjoined in the embedded Linux realm are the posts by George Hilliard, Mastering Embedded Linux series and the Designing my Linux-powered Business Card. https://www.thirtythreeforty.net/posts/2019/08/mastering-embedded-linux-part-1-concepts/ https://www.thirtythreeforty.net/posts/2019/08/mastering-emb... https://www.thirtythreeforty.net/posts/2019/12/designing-my-linux-business-card/ https://www.thirtythreeforty.net/posts/2019/12/designing-my-...
- vitaminCPP 6y agothanks for sharing
- 0xdeadbeefbabe 6y ago> Because C doesn’t have good programming constructs for asynchronous calls or exceptions, code tends to contain either a lot of weird state machines or tons of nested branches. It’s horrible to debug problems that occur. Linux is in C though. So, what is really going on?
- rcxdude 6y agoLinux uses a lot of kernel threads (as well as a lot of code which runs on application threads). It's pretty synchronous in style for the most part.
- gspr 6y agoCan 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?
- magicalhippo 6y agoI 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 features also make microcontrollers a lot slower, and I'm guessing he's thinking about cost/watts per MIPS or something like that. Yes the application processors draw more power overall, but (I assume) they are so much faster it more than makes up for it in dollars per MIPS or watts per MIPS. So it appears more of a symptom than a cause. But again, I might be wrong. [1]: https://en.wikipedia.org/wiki/ARM_Cortex-M#Silicon_customization https://en.wikipedia.org/wiki/ARM_Cortex-M#Silicon_customiza...
- jaydcarlson 6y agoNone 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).
- magicalhippo 6y ago> None of these application processors I reviewed have out-of-order execution. You're right, I was thinking of the A8, A9 and similar. > the MMU is the big dividing line in my opinion I'm no expert, but seems like a reasonable line in the sand to me.
- 6y ago
- jeffreyrogers 6y agoIf you don't have time to read the whole article, the conclusion is worth reading on its own. Has some great advice on the importance of practice for improving skills.
- schultetwin1 6y agoI just started a job working on embedded Linux devices, coming from a microcontroller world. This was extremely helpful, what a great writeup. Thank you!!
- andi999 6y agoShouldnt you avoid malloc and free (after the startup phase of your application) completely in long running applications?
- zwieback 6y agoHow does he find the time? I thought maybe it was very surface evaluation given the number of parts but I scrolled down to the part I have recent experience with (STM32MP1) and his summary was spot on. Bookmarked!
- cushychicken 6y agoGuessing from his update frequency: in fits and spurts, over many, many months. He's posted some stuff on twitter that alluded to this work - lots of debugging DRAM and swapped bit signals.
- PaulDavisThe1st 6y agoThs 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.
- watersb 6y agoHOW DO WE THROW MONEY AT JAY for this epic write-up?
- ww520 6y agoVery 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.
- deleted 6y ago[deleted]
- contingencies 6y agoThe 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 ones that plausibly are FCC certified) that even relatively high-volume products I've seen in the wild use the solder-down modules. It is, however, necessary sometimes. Zooming out to a broader management context, non-trivial systems usually comprise multiple processors. In these circumstances production volumes are generally lower and subsystem iteration more likely, therefore it makes more sense for managers to worry about overall architecture (eg. bus selection, microntroller vs application processor, application processor architecture) and consider factors such as speed of prototyping, availability of talent, longevity/market-stability of vendor's platform, feature-set and nature of software toolchain(s), etc. rather than worry about optimizing specific processor part selection. The management priority generally only flips closer to the article's fine-grained approach in the event that you are designing a consumer electronics widget or otherwise very high production run product with a low change expectation, where individual processor selection and BOM optimization become greater concerns. Conclusion: For most people, for most products, most of the time, you don't want to start by worrying about specific processor part selection. Further, prototyping should be done on third party dev boards/SOMs and when production volumes justify it, final PCB design can be handed to an outside EE. This is not always a viable strategy (eg. due to form factor or other application constraints), but it's fast, cheap and hard to go too far wrong.
- bshanks 6y agoJust out of curiosity, what are the some off-the-shelf SOMs that you would tend to reach for/recommend?
- jaydcarlson 6y agoPlease 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.
- jzer0cool 6y agoNot sure if this is right place but thought I could ask here with regards to embedded development. 1. I once had a temperature/humidity sensor, but never figured out if it was analog or digital (it had three prong. someone in field thought it could be digital). What would be some ways/tooling needed you could use to independently test this out? 2. In/Out on embedded boards is any suggested way to capture reads (or write), for example raw data? What about the other way around? 3. Which board here might be good to practice (or something else) doing a hello world on making device drivers. Something on easy, learning side and possibly practical that interacts with a real device. Thx!
- CamperBob2 6y agoThose questions are all too open-ended to lead to specific answers, but in general, if you don't actually need a serious OS in your project, I'd suggest getting your feet wet with Arduino and then moving on to ARM-based platforms such as Teensy when you need more power (which you eventually will.) The advantage of Arduino is that it will give you a good introduction to embedded development and I/O principles. Working with Arduino, you'll find that the CPU is reasonably capable but that the programming abstractions are clunky, and that'll give you the excuse you need to get comfortable with direct I/O port access. What you learn along the way will apply on more sophisticated platforms. As for the temperature sensor, it's most likely digital (I2C or similar interface). Without the part number it may be difficult to get it working. If you don't have the part number, it's best to chuck it and order one from Adafruit or Sparkfun that comes with the necessary documentation and support code. Reusing salvaged parts isn't the cost/productivity win that it used to be. If you need more horsepower for your project than an Arduino or Teensy-class board can provide, then you would want to look at Raspberry Pi or Beaglebone Black. If you aren't already comfortable with *nix development, you have a massive learning curve ahead, for better or worse, and you're going to be spending a lot of time in Professor Google's classroom.
- boznz 6y agoGreat writeup Jay. Been working in embedded since 8031 and one of these days I will find a need for project that is not just main(){ sleep(); } with interrupts and when I do this will be my goto document, already saved it off-line just in case :-)
- sabujp 6y agoyou really want a rock pi s : https://lemariva.com/blog/2019/09/rock-pi-s-tinier-version-raspberry-pi-alexa https://lemariva.com/blog/2019/09/rock-pi-s-tinier-version-r...
- vitaminCPP 6y ago> 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" ? - What does "actually access a memory location" implies exactly? - "since Linux frees and reorganizes pages behind the scenes": Is this not what people dislike from malloc? That it's none deterministic?
- spatular 6y agoMMU 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.
- vitaminCPP 6y agoThanks. 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.
- spatular 6y agoTo be precise, that'd be called MPU -- memory protection unit.
- iainctduncan 6y agoWow, 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?
- hifly 6y agoWhy 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?
- rcxdude 6y agoSounds 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).