Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jaycarlson.net

Post reply on HN
Print view View original

41–50 of 80 posts

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

#41

Post by blueflow »

monocasa wrote: post #32
blueflow wrote: post #13

Earlier quoted context omitted.

The distinction used to be "Whether the bus is exposed externally". > Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Which microprocessor architecture does this?

Just about any with cache will let you pin last level cache to assist boot up. I've done this with PowerPC cores that no one would call microcontrollers.

I respect you for writing the first substantiable conter in this whole thread. Signal-Noise ratio isn't good for me today.

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

#42

Post by foxfluff »

blueflow wrote: post #13
foxfluff wrote: post #11

Earlier quoted context omitted.

It's a pointless distinction by and large. Microcontrollers may or may not have storage for firmware. Requiring an off-chip flash is nothing new. Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Microcontrollers may include a bunch of peripherals, but so do processors. Especially so if you refer to SoCs as processors, like the article here does. And SoC…

The distinction used to be "Whether the bus is exposed externally". > Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Which microprocessor architecture does this?

> Which microprocessor architecture does this?

As far as I know, all of them. It's possible that there are historical systems where DRAM configuration is fixed, but I wouldn't know about it. Any modern system requires rather complicated configuration to get the DRAM going.

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

#43

Post by spfzero »

blueflow wrote: post #17
AlotOfReading wrote: post #16

Earlier quoted context omitted.

Most of them? Pretty much every ARM board supports an SRAM boot stage, for example. If you're using U-Boot, it's pretty likely that there's a SPL running out of SRAM somewhere in there.

ARM is a microcontroller architecture.

If you look at two examples, they may have the same "architecture", but on one, more of the architectural blocks are on-chip, and on the other, less. I don't think what is on or off the chip really changes the architecture, though it would probably change the performance, and the pin boundaries do drive other system considerations. But otherwise, the architecture is the architecture, or am I looking at it wrong?

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

#44

Post by blueflow »

detaro wrote: post #40
blueflow wrote: post #37

Earlier quoted context omitted.

What about the slots i plug my RAM sticks into? Do they not count because it goes over the north bridge?

Modern x86 CPUs integrate the DRAM controller directly (e.g. with Intel ever since Nehalem, ~2008) and not over a bus through the northbridge. From that point on I wouldn't count it if you insist on a strict definition, no - it's roughly the same as if you put a socket between a current higher-end ARM chip with external memory and the connected DRAM chips. Chipset is relegated to dealing with I/O to peripherals mostl…

This is a useful explanation.

For the article, i don't want to leave it standing as it is. Redefining "Microprocessors" as "having an MMU" is making communication about these topics very unpleasant, especially when its about Retrocomputing. Same pains as i ranted about in https://news.ycombinator.com/item?id=30278936 .

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

#45

Post by foxfluff »

blueflow wrote: post #41
monocasa wrote: post #32

Earlier quoted context omitted.

Just about any with cache will let you pin last level cache to assist boot up. I've done this with PowerPC cores that no one would call microcontrollers.

I respect you for writing the first substantiable conter in this whole thread. Signal-Noise ratio isn't good for me today.

If you want some reading about boot flow, see e.g.

https://www.coreboot.org/images/2/23/Apollolake_SoC.pdf

https://blogs.coreboot.org/blog/2019/07/17/gsoc-how-to-run-c...

https://9esec.io/blog/open-source-cache-as-ram-with-intel-bo...

The TLDR is that you need to get DRAM running before you can use it (e.g. by poking at DRAM controller's registers until it knows how to talk to your stick of RAM reliably and at a comfortable speed). Until then, you're stuck with SRAM. On ARM SoCs and Intel Apollo Lake, you use addressable SRAM. On most other x86 systems you use cache as RAM. Cache is just SRAM though, and the only difference between ARM and typical x86's case is that the latter doesn't let you directly address it.

You can find examples of DDR DRAM configuration in u-boot sources, and presumably in coreboot too.

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

#46

Post by voakbasda »

nickysielicki wrote: post #2

Previous thread, 2020: 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.

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.

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

#47

Post by foxfluff »

blueflow wrote: post #13
foxfluff wrote: post #11

Earlier quoted context omitted.

It's a pointless distinction by and large. Microcontrollers may or may not have storage for firmware. Requiring an off-chip flash is nothing new. Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Microcontrollers may include a bunch of peripherals, but so do processors. Especially so if you refer to SoCs as processors, like the article here does. And SoC…

The distinction used to be "Whether the bus is exposed externally". > Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Which microprocessor architecture does this?

> The distinction used to be "Whether the bus is exposed externally".

Which bus is "the bus"? SoCs and microcontrollers alike expose a bunch of different buses.

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

#48

Post by blueflow »

foxfluff wrote: post #42
blueflow wrote: post #13

Earlier quoted context omitted.

The distinction used to be "Whether the bus is exposed externally". > Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Which microprocessor architecture does this?

> Which microprocessor architecture does this? As far as I know, all of them. It's possible that there are historical systems where DRAM configuration is fixed, but I wouldn't know about it. Any modern system requires rather complicated configuration to get the DRAM going.

Counterexample: The IBM PC was a microprocessor system which does not do it - the BIOS runs from ROM only and sets up the DMA controller for the refreshes. No DRAM, no RAM used.

Excluding the caches, this is how x86 functioned for quite a while, i don't know until when.

Microprocessors don't require internal RAM to bootstrap, because they expose their bus and its simple to map a ROM to the starting address, which can be executed from directly.

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

#49

Post by blueflow »

foxfluff wrote: post #47
blueflow wrote: post #13

Earlier quoted context omitted.

The distinction used to be "Whether the bus is exposed externally". > Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Which microprocessor architecture does this?

> The distinction used to be "Whether the bus is exposed externally". Which bus is "the bus"? SoCs and microcontrollers alike expose a bunch of different buses.

https://en.wikipedia.org/wiki/System_bus

I'm assuming Naumann arch, with instructions and data on a single bus.

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

#50

Post by jlokier »

blueflow wrote: post #13
foxfluff wrote: post #11

Earlier quoted context omitted.

It's a pointless distinction by and large. Microcontrollers may or may not have storage for firmware. Requiring an off-chip flash is nothing new. Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Microcontrollers may include a bunch of peripherals, but so do processors. Especially so if you refer to SoCs as processors, like the article here does. And SoC…

The distinction used to be "Whether the bus is exposed externally". > Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Which microprocessor architecture does this?

Modern x86 does this.

The BIOS starts running on the x86's internal SRAM.

https://stackoverflow.com/questions/63159663/how-does-bios-i...

Post reply on HN