Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!newsfeed.direct.ca!portc01.blue.aol.com!news-peer.gsl.net!news.gsl.net!uwm.edu!www.nntp.primenet.com!nntp.primenet.com!arclight.uoregon.edu!pith.uoregon.edu!Symiserver2.symantec.com!news From: tedm@agora.rdrop.com Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Embedded FreeBSD Date: 21 Dec 1996 08:28:58 GMT Organization: Symantec Corp. Lines: 108 Message-ID: <59g74a$8q2@Symiserver2.symantec.com> References: <32B744C0.2DA9@wdc.net> Reply-To: tedm@agora.rdrop.com NNTP-Posting-Host: shiva3.central.com X-Newsreader: IBM NewsReader/2 v1.2.5 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:32898 In <32B744C0.2DA9@wdc.net>, Darren Bordelon <darren@wdc.net> writes: >Hi, > >We would like to try and use FreeBSD in an embedded system, but [deleted] >First, we would like to have about 4megs of ram. What are the best >methods of minimizing kernel usage? Of course, we will not be using No problem for this application, in fact you can probably use a 386. To minimize kernel usage you obviously will need to compile a custom kernel with just about every device driver stripped, except those absolutely required. This includes the console driver, which you won't need unless your embedded system requires user interaction with a screen. You can use the driver that speaks out the PC com port for the console. Beyond this the next thing is fiddling with the MAXUSER parameter to further decrease kernel table size. I'd drop this parameter gradually. You will need to run all the applications that you will be using in the system, and run various incarnations of ps to figure out what they are consuming as far as system resource utilization You will need to greatly restrict the number of simultaneous network sessions (such as telnet daemons) that can be run. My guess is that after fiddling, you might possibly be able to get the kernel size down to a half-meg. >most of the normal daemons. Also, we would be removing all of the >device drivers that we don't need. Are there other ways to further >decrease system usage? > Only if you have an embedded application that is internally limited in the total system resources it can consume. For example, many Unixes allocate memory for stuff, and internal calls to free() simply make the allocated memory unavailable, but don't actually return it to the operating system. If you were to monitor memory utilization for such a program you might see it gradually increase over time. You will need to carefully determine all of the decision paths that your embedded app can be taken through, and make sure that you know the maximum amount of resources such as disk space, and memory, that the app will consume under any operation. Once you get this figure, you can reduce the internal kernel data tables down to where they are just able to run this app and no more. >On the booting issue, can Freebsd be made into some sort of a system >image, whereby a small boot loader program could put it from rom into >ram, and then jump to the right instruction in the kernel? If so, what >are the initialization concerns? > >There would be 0 swap. Is this going to be a problem? > >We would like to have the the file system in flash ram at some address >beyond the normal ram memory. Can the kernel be configured, perhaps with >the ram disk driver, to use such a memory space for a ram disk, or would >a completely new device driver be needed in this situation? > The kernel queries BIOS for the amount of ram in the system, so if the flash ram is not seen by BIOS the kernel won't grab it. In that case your probably talking non-standard hardware to begin with which would certainly require a custom device driver. >We would not need most of the stuff under /etc. What is required, if >anything, by the kernel in this dir? > Depends on the programs that will be run. You can probably write your own /etc/rc and toss most of the stuff in /etc, as well as most stuff in /bin and the other directories. For an idea, mount the installation floppy and look through how that was set up. >We could also use a rom floppy to boot, would this make things much >easier? Are there other ways that we might used to "boot" the system? > Actually, if you gziped everything and your requirements were small enough you might be able to stuff the entire operating system onto a single floppy. >What other issues might we need to consider, and what other methods >might >be useful in embedding FreeBSD? Any pointers, thoughts, musings, etc. on >this subject will be greatly appreciated. Again, we will post a >compilation of suggestions, techniques, and our own successes once we >have >gotten an embedded FreeBSD working. > >Darren >darren@wdc.net I'd start by carefully looking through the boot.flp installation image diskette, that's going to be a great source of ideas. This would also greatly help the kernel size, if you could run the system off a floppy controller, you could remove the device drivers for a hard disk controller, which will save you yet more space. The one thing about an embedded FreeBSD is that it is not going to be useful for real-time timing and other stuff, you will need a fancy embedded OS for that.