Embedded system with RAM Disk

Embedded system with RAM Disk

[Victor Wells]

*** Please excuse if you have received multiple copies of this message.
I was not
        correctly subscribed to the news group.    Thanks for everyones
patience.  ****

I am developing an embedded system that will boot from flash.
I would like to load a RAM based file system to physical memory
and then have the kernel mount the RAM disk as the Root
file system.

This is fairly straight forward using "initrd" because normal kernel
functions can accomplish it.  I would like to skip loading initrd and go



right to the final RAM disk if this is possible.

Our boot process is to:
1.) Load the kernel
2.) Load the RAM disk/Root file system
3.) Mount the RAM disk as the Root file system within the kernel

How can I hard code the kernel to know where the RAM disk will
exist in physical memory?   We do not have JTAG or any other means
to create the file system on the target platform prior to saving the
file
system to Flash.

Thanks,

Victor

RE: Embedded system with RAM Disk

[Harald Koerfgen]

On 25-Jan-00 Victor Wells wrote:

> I am developing an embedded system that will boot from flash.
> I would like to load a RAM based file system to physical memory
> and then have the kernel mount the RAM disk as the Root
> file system.
[...]
> 
> Our boot process is to:
> 1.) Load the kernel
> 2.) Load the RAM disk/Root file system
> 3.) Mount the RAM disk as the Root file system within the kernel
> 
> How can I hard code the kernel to know where the RAM disk will
> exist in physical memory?

Once upon a time I had a hack which did something similar, linking a ramdisk
image into the kernel image which resulted in a single file for kernel+ramdisk.

This is not only a nice feature for installation kernels but a must for boxes
which are only capable to boot a single file, for example via TFTP.

The current mechanism, i.e. "addinitrd", works for some boxen which boot ECOFF
kernel images, but even not for all of them. Creating an kernel+ramdisk ELF
image and converting that into ECOFF, on the other hand, even works for
DECstations. Depending on how you fiddle with the linker scripts the ramdisk
image can easily reside in ROM or flash or whatever.

Well, somehow this hack didn't make it into the mainstream kernel but came to a
new life within the LinuxCE project and I am beginning to wonder if we should
make this the default.

Opinions?

---
Regards,
Harald

Re: Embedded system with RAM Disk

[Ralf Baechle]

On Wed, Jan 26, 2000 at 08:26:34PM -0500, Charles Lepple wrote:

> The PPC board that I used would not load ELF images with extra sections,
> so I resurrected some code that would convert the ramdisk (and gzipped
> vmlinux, actually -- I'm not sure if the MIPS code does anything like
> this) into assembly 'define word' statements, assemble the resulting
> file, and link it in. The file had symbols for initrd_start & _length,
> and the assembly was surprisingly quick. The ramdisk, in effect, became
> part of the data section of the kernel image (zImage, actually).

In which case the PPC's ELF loader is hopless broken.  An ELF loader is
a quite simple thing, it only needs to process all the PT_LOAD entries
in the programm header table, done.

  Ralf

PS: negativezero.org - I thought one's complement machines are dead
    by now ;-)

Re: Embedded system with RAM Disk

[Ralf Baechle]

On Thu, Jan 27, 2000 at 09:26:50PM -0500, Charles Lepple wrote:

> Ralf Baechle wrote:
> > On Wed, Jan 26, 2000 at 08:26:34PM -0500, Charles Lepple wrote:
> > > The PPC board that I used would not load ELF images with extra sections,
> [...]
> > In which case the PPC's ELF loader is hopless broken.  An ELF loader is
> > a quite simple thing, it only needs to process all the PT_LOAD entries
> > in the programm header table, done.
> 
> sorry to spam the lists, but I just have to clear the PPC name :-)
> 
> The boot firmware was for VxWorks, which evidently uses files which
> resemble ELF binaries down to the headers. I won't name the company who
> wrote the BSP, but it was pretty weak code (a little research in the
> Linux/PPC lists may turn stuff up though...)
> 
> Most standards-compilant (PReP, CHRP) boards do load things correctly,
> however.

On the MIPS-side the price for firmware weirdness goes to SNI's ARC firmware
which always loads programs to the address specified in the address + 8
bytes.  The really sick thing is that behaviour is even allowed by the
ARC spec even though it's truly undesired behaviour for a kernel loader.

Luckily this can be fixed with objcopy :-)

  Ralf