At Mon, 29 Jul 2019 13:18:14 -0400 beagleboard@googlegroups.com wrote: > > On Mon, 29 Jul 2019 05:56:00 -0700 (PDT), Jani > <amern2...@gmail.com> declaimed the > following: > > >A traditional embedded system boots from flash memory and code runs from > >flash memory. Usually application isn't copied to RAM, only read/write > >variables are copied to RAM. > > Define "traditional embedded system" <G> > > In the readily available market, what you describe above falls into the > Arduino, Tiva-C, Adafruit Metro, Parallax Propeller cards -- which are > classed as "microCONTROLLER" boards. The closest they get to having an OS > might be applications using something like FreeRTOS (or TI-RTOS for the > Tiva-C) -- ie: the application /is/ the OS. The Flash memory on such > systems is directly mapped into the processor address space along with the > RAM and any memory-mapped I/O devices/ports. > > >Does system running embedded Linux execute from RAM? > > > > Once you specify Linux, you mostly are talking "microCOMPUTER" with a > full up OS and related file system, "ad-hoc" process creation (in an RTOS, > all processes tend to be predefined and created on start-up), etc. Any > Flash memory tends to be configured as an I/O device and is part of the > file-system, not part of the processor memory address space.
I think the OP is talking about "appliance" systems. This would include most home Internet Routers, it would include Internet-ready Sony Blu-Ray players (go visit the System Copyright screen from the Setup Menu: it is GPL, BusyBox is mentioned, etc.). These "embedded Linux" systems run a stripped down O/S. It really is Linux and do have a flash boot ROM (I expect probably much like the BBB's eMMC). These "appliance" systems are somewhere between the Arduino-ish MCUs and the BBB and Raspberry Pi type machines. > > This does not preclude designing a board in which some of the processor > address space is Flash memory. It may even be possible to build a Linux > kernel (or whatever that binary file that is used during booting -- I'm not > an OS developer) image that can be stored in flash and directly jumped to > during booting (it would probably offer much faster start-up if the boot > load just has to set up processor registers/zero RAM and can jump directly > into the OS -- rather than copying a core image file into RAM and jumping > to it). I have seen a card which did have memory-mapped Flash (I had to > port benchmarks to it some years ago, and the benchmarks ran as pure > start-up code from Flash). > > BeagleBone and Raspberry-PI, however, do not have memory-mapped Flash; > they run from RAM and load the core image from a defined file-system on I/O > device Flash. > > >I need to know what size DRAM I need for my embedded Linux system? If > >Linux distribution takes up 3GB in SD card. Then, does this mean I need > >3GB DRAM? > > BBB has a 4GB eMMC (or use SDHC up to 32GB) but only 512MB of RAM. The > R-Pi3B doesn't have on-board eMMC, so uses SDHC up to 32GB, and has 1GB of > RAM (it also has a quad-core processor). The latest R-Pi4B can be had with > 1, 2, or 4GB of RAM. > > Also take into account that, if you have external storage (disk), these > systems can be configured with a swap partition/file and could move idle > data/code out to swap. OTOH; once you start swapping you lose much of any > realtime capabilities -- you could be caught with swapping latency if, say, > a very rare interrupt occurs and the handler is not in core. > > > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/20190729180415.B88D426C0162%40sharky3.deepsoft.com.