Minimal x86 memory requirements

I'm looking to build a bare minimum x86 kernel that will boot and run busybox, nothing else (and eventually less than that). Assuming I do need USB-HID, IDE, and basic TCP/IP, what should I expect to be the least RAM I could get away with just to boot off flash, get a getty, login, and take a few directory listings.

If anyone would like to point me where to RTFM, that would be appreciated as well :-)

Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

On a nommu system, if you configure out most of the PRINTK strings, you can run a reasonably useful system in 4 megabytes. However, that's using a small flash-based initramfs with the block layer disabled. I don't know if you can fit everything you need in there (USB, the block layer, and networking stack). And if you want a MMU system, you'll add the overhead of page tables in there.

So while you _might_ still be able to trim it down to 4 megabytes, I'd budget somewhere in the 6 to 8 megs range. Don't forget to statically link your busybox binary so you don't dirty physical pages with relocations. (Against uClibc of course, Ulrich Drepper deprecated static linking in glibc because they suck at it so badly.)

I note that the Linux kernel (last I checked, circa 2006) no longer booted in 2 megabytes of ram due to the relocations required to extract the thing when it gunzips it, it simply wouldn't let the mappings be that close. Maybe that's been addressed, but I doubt it.

Something people were spending time on a while back was mapping the kernel directly out of flash (I can never keep NAND and NOR straight but the one that works more like normal memory) since the code segment is just a big read-only mapping block anyway. I think these days it works fine, but I haven't tried it. Doing that saves DRAM, but it needs actual mappable flash or ROM, and not a block device that faults pages into DRAM under under the covers when mapped. All that XIP work (execute-in-place and binflat and such) was related to that as well. Note that flash may not be as FAST as dram so you take a performance hit, but they were worrying about the power consumption of requiring less DRAM to refresh.

Does this help? (Play with QEMU. QEMU is awesome. I have system images at http://landley.net/downloads/binaries which provide a static uClibc defconfig busybox binary you can try tweaking the kernel .config and such for. It's defconfig so it's pretty big, but it should give you a reasonable idea. If you want the busybox binaries by themselves, I copied them to http://busybox.net/downloads/binaries. Remind me to update that for the new release...)

Rob

Hello,

OpenWrt runs currently on a RDC R-321x System-on-Chip which is i486 based [1] and usually designed with 16MB of RAM, the bzImage itself is around 768KB w/ the following features built-in:

- TCP/IP networking
- MTD support for CFI compatible NOR flashes
- JFFS2/squashfs filesystem

When I load additionnal modules to be able to do NAT/USB/FAT filesystems for instance, plus having must have daemons running (dnsmasq, dropbear, busybox, hostapd ...), I still have around 3MB of available RAM (for a 16MB RAM device). The filesystem itself is compressed using squashfs+lzma, and fits within 3MB (loadable modules are inside, usable image at [2]).

So from my perspective, you should be able to do all of this with a 16MB RAM device, plus 4 to 8MB of Flash to be confortable with storing your filesystem.

Hope that helps.

[1]: http://wiki.openwrt.org/oldwiki/openwrtdocs/hardware/airlink101/ar525w
[2]: http://downloads.openwrt.org/backfire/10.03.1-rc4/rdc/openwrt-rdc-
squashfs-ar525w.img
--
Florian