|
Install on 16MB storage (flash card)
Hello.
I need to install Linux on a 16 MB (sixteen mega byte) flash card (some kind of... it is detected as an "IDE drive")! The problem is that I have no idea on how to accomplish this. The installation should give me TCP/IP and SERIAL / LPT supoort (this is very important, but i guess the installation part is more important for now). I assume I would need a special kernel build (but I'm not sure about this... please,please tell me I don't :rolleyes: ). Anyways, this is what I've got so far: 1. RedHat Linux 7.0/8.0 (bootable cd's, "the whole 9 yards") 2. A "black box" with 16MB flash card as storage, 32MB RAM, 4 serial ports, sound card (wich i DON'T intend to use), video card (have no ideea what kind of, but i don't need it... well, except for the installation process)... 3. A lot of pacience... but this might end. Please help me out on this one (at least on the installation process, i.e. make this "black box" boot my linux from the 16 MB flash card; the TCP/IP, SERIAL / LPT support could be installed later... i guess). Thank you. |
On the off chance of it working for you, I know a site that has designed Linux around mesh wireless networking with CF cards. They have the linux software/roms etc and instructions. They come with TCP/IP ready and a host of other things...
Maybe this will get you started.. http://www.locustworld.com/ and then the download section (its based on Nuke style website) Good luck my penguin friend. John. England. |
Here is another list of possibilities:
http://lwn.net/Distributions/index.php3#embed Note that many of these are designed for specific purposes, and often are not well documented, but it quite likely that you'll find something that can be made to work for you in this list. |
Making a bare-bones bootable Linux on a 16 MB CF-card may be something of a challenge.
IMHO you have two choices: 1: Grab an existing bootdisk-image off one of the sites mentioned above and modify it to suit your needs. If you're lucky, you can get hold of one that doesn't need exhaustive alterations. 2: Do a complete Roll-your-own thing. Which way you choose to go is up to you and may depend on eg. how much time you want to put into the process and how much you want to "be in control" of the final outcome. I have a few comments on the two options, to hopefully help you 'choose wisely' - as someone in an old Indiana Jones-movie once said ;) Ad 1: Perhaps this option present the smallest workload, but you'll be less in control, and you'll be exposed to the "Wrong kernel version"-problem if you want to add eg. a specific networking module to support your hardware. I for one have had lots of trouble with that one. I also think it will be harder to maintain this solution, as you are depending on someone elses work. Ad 2: "Whoooa", you might think - sounds like a lot of work! Actually, this solution presents a rare chance to "get under the skin" of your solution. Okay, you'll need to figure out how to do a kernel-compile, how to create a bootable disk-image and how to transfer it to your CF-card. Doing the kernel-compile is actually no big thing: Get hold of the sources to your running kernel and take a close look at the "README" file. Thange the VERSION info in the MakeFile (to generate a new kernel instead of overwriting your existing one) and do a make xconfig! Choosing to configure your custom kernel via a *graphical* interface under X is the key to getting it done right. Also, take advantage of the fact that configurations can be *saved* and *retrieved*, because you're gonna do the kernel-config-thing many times before you get it right. And then you go read this document on making bootdisks: http://www.linuxlots.com/~fawcett/Bo...WTO/index.html You can take it from me: it's actually fun building a bootable disk-image. You create a file, mount it as if it were a disk-drive, format it and manually put the files in your target filesystem into it, getting loads of insight on the workings of a booting Linux-system underway. Once finished, you unmount the disk-file, compress it and stuff it onto the CF-card along with your kernel. This is where i am right now. I'm in the same situation as you, only my requirements are not the same. My project requires IP networking, VGA support and a browser to implement a kiosk-thing. I'm in the process of generating a functioning filesystem with all the library dependencies in place, reasonably configured (read "removed" or "cut-down-to-almost-nothing") initialization-files. Done the kernel-thing, done the transfer-to-CFcard-thing, doing the filesystem and can't wait to put it all together ;) You need to dispense with the thought of doing anything later. To make this fit into 16MB, i believe you can just forget about anything in the direction of flexibility. Read the Bootdisk-HOWTO, do a kernel-compile and strip the kernel image of ANYTHING you don't absolutely need. Write a boot-floppy and try it out on your own PC. What happened? Iterate and iron out errors. Kernel boots OK off of the floppy but can't find a filesystem? Then go make a separate partition (dev/hda?) on your harddisk, format it and put a miniscule filesystem on it. Make the boot-floppy try to load this filesystem and perform a nice, complete and well-functioning boot-process. Keep iterating until it works. Finally, generating a complete boot-image should be no problem. Doing like this leaves you in complete control and dispenses with the "Version mismatch"-problem too. One final note: do you intend to run the system directly off of the CF-card, or from a RAM-disk? I ask, because CF-cards have limited lifespan when it comes to writing and thus, you need to deal with this issue. Yours, Martin |
I don't know whether or not you have a floppy drive in your machine, but you can get linux environments that run from a floppy without any need for a hard drive. I'm not sure how up-to -date these distros are though.
Also you mentioned having bootable CDs...if this means you have a CD-ROM drive in the machine, you could use Knoppix for the operating system (it's a bootable CD) and the CF card for any data you need to store. Knoppix is apparently quite easy to customise, though i have never done so. MN |
I have to agree with "mafiltenborg". Building your own is a lot of fun, and it is not too much work at all.
I would suggest however, that you get hold of a USB<->compact flash adapter. This way you can plug the flash onto your host system, write it, and then put it on your target system and boot the target. If something goes wrong, all you need to do is plug it in again and write something else. With a USB adapter the steps into building something bootable are: - download kernel 2.6.2 (or whatever is the latest stable version) - do "make xconfig" and select all the options you want for your kernel (networking, network drivers, etc, etc) - do "make bzImage" - prepare your CF filesystem: - fdisk /dev/sda, to create only one partition with everything (mark it as bootable or some BIOS won't like it) - mke2fs (if you go for ext2) /dev/sda1 - mount /dev/sda1 /mnt/target (/mnt/target is the dir where your compact flash will appear) - mkdir /mnt/target/boot - mkdir /mnt/target/sbin - mkdir /mnt/target/lib - copy arch/i386/boot/bzImage onto /mnt/target/boot - build a lilo.conf file to install the bootloader into the compact flash (read "man lilo.conf") - now all you need is some "/sbin/init" for the kernel to run after it boots. Maybe a shell prompt to start with, is a good thing, so copy "bash" into "/mnt/target/sbin/init" and do a "ldd bash" to check bash dependencies on libraries and copy all those to /mnt/target/lib - it's ready to boot :) This setup should about 4Mb of flash (most of it comes from the bash libraries). Since you have 16Mb of flash, i wouldn't worry about it. This is a very simple configuration, but you can expand it to suit your needs. You can use "busybox" to get a lot of shell functionality and ocupy as little flash as possible. The main advantage of this approach, instead of using a standard distro, is that you know *exactly* what is going on, i.e., you're in control :) |
"pmarques":
Thanks for the good advice. I sense you've been there :) But __declspec probably has a blackbox with no USB, forcing him to do it this way: Grab a Flash-card-reader and plug it into your computer - assuming you use a standard PC for developing the image-file, and assuming this PC runs eg. RedHat. It'll appear as /dev/sda? and you can then do the usual mount-thingy. Transfer the image file to flash using dd if=yourfile of=dev/sda blablabla... Physically move the now ready-to-run flash memory card to the target system, power on and test. Iterate until satisfied with target functionality, then secure the lid and handover the device to customer. Remember to document and keep a copy of the firmware and source files. "__declspec": Am i right in assuming your target is some sort of industrial-grade gadget destined for harsh or hard-to-reach environments? You know; more like a "device" than like a "computer"... For your reference i'm working on a device you can read about here: http://www.kontron.com/products/pdpr...ctCategory=236 Mine's an ETX-MGX on a ETX-EVAL baseboard, holding 128 MB flash & 256 MB RAM total. A leftover from another project, now forming a possible basis for something different :) |
Sorry if I wasn't clear enough about the "host system" and "target system" in my explanation :(
I was actually assuming that the target system had a IDE<->compact flash adapter and that "__declspec" should use a USB<->compact flash adapter for the host system where the image was going to be developed. The only thing that I was trying to simplify was the "build an image file, and compress it" step, because "__declspec" has a 16Mb CF card that should be much more than enough to include TCP/IP, serial and LPT support, like he requested. This way he could write directly into the CF card, without more intermediate steps. However I have a feeling that after he gets this system to work, he won't resist starting to compress the image to get a X server, and a HTTP server, and SSH, and ...., and ... into a 16Mb flash :) Once, just for fun, I installed a Mandrake distro into a 256 Mb flash, with KDE3.1, konqueror, control centers, etc. by simply compressing the "/usr" directory. |
Which instantly makes me feel better about the job i've got to do: squeeze it all into 128 MB o' flash.
BTW, do you have any comments on the flash-disks-wear-out-over-time-issue and my proposal to run it all out of ram? Only problem i see is need for more RAM (cheap) and extended boot-time. Devices can't afford to boot. Only computers may have that luxury - and if your device is somehow recognized as being "a computer", just show 'em a "Booting Windows 98"-bitmap if you think this timing issue may once become a problem. People all over the world will go "Ah, it's a Win98 thing - better be patient..." :) Martin |
PLEASE DISCARD THIS PART IF YOU HAVE A LOT OF WORK TO DO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Well, I was writing this reply for all of you (with all those "thank you very much") when suddenly i made this opera mouse gesture (i'm "under" win2000 now... :jawa: ).... you should know: RIGHT CLICK + MOVE DOWN and it...... closed the window! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OK. Thank you very much. I was convinced that noone ever did this before and noone is interested in helping me out... it seems that i believed wrong. mafiltenborg gave me an interesting answer. I must say that i did a kernel recompile this weekend at my home computer (i have RedHat 8.0 with kernel version=I_DONT_KNOW) and it went just fine (except for the part of booting from the created bzImage... :study: ) I did the sequence: make xconfig <do the config> make bzImage <change grub (i did not install lilo) configuration file> <..... reboot> I must say that pmarques's list of commands should help me out, but i don't have the chance to test it right now, so i'll come back after testing those out. And, yes, I will stay up one night and will try to get the most out of my precious (copyright (c) The Lord of The Rings: The Return of The King :rolleyes: ) The flash card actually it's "some kind of flash" (i'm not sure about this and this said - i'l shout my mouth before i'll start looking like an idiot). I don't think it has any problems with the read/write operations... i think :study: mafiltenborg - yep, it's a "industrial box". It will sit in a "room" full of hard workers and we'll attach a set of scanners to the COM ports (thats the COM / LPT port support) and it will read the data and send it through an open socket to the server application (here comes the TCP/IP support). I was unable to open the link you gave me... will try later. Having all this these said, i'm going home to do some testing. Tomorrow should be a great day (testing day). P.S.: The "black box" doesn't have cdrom / floppy attached - we attached a cdrom using a non-christian method (read "hard-core"). "If something goes wrong - don't blame the computer, it didn't pressed the 'any key' :)" __declspec |
Quote:
|
If you want to "roll your own" Linux distro for this purpose, check out Linux From Scratch (LFS) It is how I learned about the internals of how a linux system works. If you want to check out BSD, I gave you a link to a 5mb CF FreeBSD firewall distro that I have used and toy with.
Link: http://www.linuxfromscratch.org/ http://www.m0n0.ch/wall |
Just a couple of things about wear of compact flash cards.
wartstew is right about putting /tmp and /var in RAM, this really helps reduce the writes to flash. One thing you should be careful though, is to mount the root filesystem with the "noatime" option. Without this option, every time you *read* a file, the access time gets modified and the filesystem must write the new metadata, producing more writes to flash. With this option, the access time doesn't get updated, but I don't think this is a problem for an embedded system. Besides, the modification time continues to get written anyway, so you still know when a file as been written to. CF card's have an internal wear leveling algorithm, that maps logical (what the host sees) into physical (address in flash) sectors, so that if a sector gets written a lot, it will be moved somewhere else inside the flash. From what I gathered (I might be wrong here) the algorithms that exist don't move blocks that are not written to. So, if you have a 64Mb flash, but 32Mb are static data that you never write to, the algorithm can only use the rest of the 32Mb to do wear leveling. Anyway, the card's manufacturer can play an important role here, also. I never had problems wuth SanDisk's, Feiya, Apacer, etc. but card from kingmax die (or at least start reporting bad sectors) after a few weeks use. My favorites for now are SanDisk's. Usually benchmarks test speed not endurance, so we really can't be sure what are the best cards out there :( I hope this helps. |
CF memory wear countermeasures
Hmmm...
Info on the "noawrite" thing duly noted. Thanks! To get better endurance, one might do a complete copy-to-ramdisk of the entire root-filesystem, which as far as i can see, can be stored in a compressed state on flash. This way, flash-size can be significantly reduced (rootfs now stored in a compressed state), leaving room to buy more RAM and thus maintain unit cost. Only penalty i can see, is the added time required to unpack the rootfilesystem into RAM. Or am i all wrong when i have this view of things: Compressed kernel stored at the beginning of CF-memory, unpacking itself (at boottime) to RAM, followed by Kernel-driven unpacking of compressed rootfilesystem - also into RAM. Go! This way, running OS & software may write all they wish, doing no harm to the flash since writing is done to the ramdisk-based rootfilesystem. Indirect benefit: Everytime the device is powered on, it has no memory of the past. It's like newborn ;) Should any NV logging be needed, one may mount part of the flash as a disk and do logging onto that. |
Sorry, "noatime" :)
Errare humanum est! |
| All times are GMT -5. The time now is 02:49 PM. |