PC104 board boot off compact flash, load initrd, and execute out of ramdisk

Need some help here if anyone can spare a minute.

I have been working (ok struggling) with this project for some time. It is a PC/104 industrial board running Linux. The board is basically a normal computer (AMD Geode 300mhz x86 processor, SODIMM memory, 2 IDE channels, usb, ethernet, etc), all normal stuff. Currently I have a hard-drive and CDROM connected to one IDE channel and the other IDE channel is dedicated to a on-board compact-flash socket. With this setup I installed Gentoo Linux onto the hard-drive, got it all working fine and honestly it's pretty slick for a 3.5"x3.5" computer.

Now, I need to get this to the customer, which means the hard-drive and CDROM go away, it needs to boot entirely off the compact-flash card, load a initial ramdisk (initrd) and execute out of that.

I have read everything I can find about this and it certainly appears do-able. I created my initrd image file using the 'dd' command then 'mount -o loop...' etc, I stripped down alot of stuff from my actual system here since I'm using about 1.8gig on the hard-drive, but compact-flash card is only 512meg, and more importantly RAM is only

256meg on this board (although that could be upped easily if needed). The CF card shows up as /dev/hdc according to Linux, I can read/write to it happily, it appears Linux doesn't know or care it's a CF card (the BIOS shows it as a hard-drive also).

So I have it starting to boot, have the CF card formatted, a kernel on it (2.6.9 that I compiled). I am using syslinux as the boot loader and it starts up, finds the image file (lite.gz) and says it finds the kernel, and starts uncompressing the kernel. Works for 10-15 seconds, then halts with a "Kernel Panic - Not Syncing: VFS: Unable to mount root fs on unknown (0,0)". I looked that error up and usually it's because of a "root=" or "boot=" directive wrong in the boot loader, so it's not passing the correct info to the kernel. Soooo, I'm trying to learn what is a 'correct' way to pass argument to the kernel, I have grub and lilo both I can use (grub seems to have issues though, I just compiled lilo because most examples I've seen use it, I know any should work, but monkey see, monkey do, I'm happy to copy a working system).

I would greatly appreciate it if someone could post what either their grub.conf, or lilo.conf, or syslinux.cfg files are to load a initrd at startup, then change-root, or switch-root or whatever it's called where you make the root file-system the ramdisk you just created. I read that I need a /linuxrc file which will be executed immediately after the initrd is created/expanded, I'm alittle lost with that however. I have read many versions of /etc/fstab files, some using /dev/ram0, some /dev/ram1, some /dev/rd/0/, some /dev/mem...a ton of variations, I just am looking for what will load a initrd then run out of it, with no hard-drive or cdrom or anything around.

I found one other writeup which has helped some (not enough or I wouldn't be here), in that example the initrd was mounted as the root drive, but then the CF card was remounted as /etc or something like that, so in the running program you could write out to real storage (writing to the initrd does no good for keeping anything ofcourse), and you could specify a program to run at startup which wouldn't have to be in that image, so you could say always run /etc/MyProgram, so then to update your program, you'd just over-write that file on the flash-card with a new version, never touching the actual file system image.

The compact-flash card ideally needs to stay as a FAT16 card, as we have plans of using Windows computers with USB CF readers to load these in the field.

So that is the plan, any help is greatly appreciated. I'm not a linux guru, never worked much with this at all, know almost nothing, yet I am the most knowledable person (linux-wise) working on this project...eeeek...

Thanks in advance! Mark Brodis

Reply to
Mark
Loading thread data ...

Read about the "rdev" tool to plug in the root device information directly; no kernel command line needed.

Reply to
Tommy Reynolds

...

If your PC-104 board can boot off USB device, then you might be interested in

formatting link

It's designed as Linux thin-client, but you can use it in any way you want. At the momemt, it's 256MB with no room to spare. So, if you use

1GB USB key, then you have 750MB leftover.

By the way, - what brand of PC-104 are you using? - how much does it cost? - any URL?

--
William Park , Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
 Click to see the full signature
Reply to
William Park

I think it can boot off a USB device although we are not using any USB stuff and therefore did not purchase the little pigtails that would go onto this board.

The board is made by Kontron, it was in the neighborhood of $300 with

256meg of SO-DIMM (std laptop memory) installed in the one memory slot, I didn't decide on this model, but this is what was purchased.

Here is the URL to the board:

formatting link

It's a cute little board, and pretty powerful, basically a full desktop system, minus the drives in a 3.5"x3.5" computer, also no fan is needed for the CPU and the whole board runs off 5v.

With the help of some major linux gurus I have almost gotten this thing to reliably boot, it is very odd how it works and extremely frustrating, a big problem has been with bootloaders. They seem inheriently flawed to me, when I'm in a running system (off the HD) the CF card shows up as /dev/hdc, however with a newer kernel a buddy gave me it *should* showup as /dev/discs/disc0/disc, but it doesn't, well it kinda does, to get it to boot you HAVE to pass "root=/dev/hdc1 rw" to the kernel, even on the newer kernel that when fully booted does not have /dev/hdc in it's /dev directory, then it apparently sees the partiion as /dev/discs/disc0/part1 which is should...it is very odd and there is something fishy going on between the bios and the bootloader and kernel...it's been a total mess to be honest with you and I would never do this again without some more help. Every writeup I have found that gave nice clear instructions on how to do this would not work, simple as that, enter this command, the root drive should be here, etc...didn't happen that way. Cute board but not a fun project...

Reply to
Mark

/dev/hdc as a kernel argument is for pointing the kernel to the correct driver; your filesystem image itself must contain the necessary block special file to point to the correct driver...

formatting link

Reply to
Joseph Chiu

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.