Embedded system with RAM Disk
*** 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
Quoted 4 lines · 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.
[...]
Quoted 8 lines
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 kernelHow 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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Charles Lepple
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 ;-)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Charles Lepple
Quoted 2 lines · Ralf Baechle
Quoted 1 line · Charles Lepple
The PPC board that I used would not load ELF images with extra sections,
[...]
Quoted 3 lines
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_LOADentries in the programm header table, done.sorry to spam the lists, but I just have to clear the PPC name :-)
Quoted 7 lines
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