* Embedded system with RAM Disk
@ 2000-01-25 22:52 Victor Wells
2000-01-26 19:15 ` Harald Koerfgen
0 siblings, 1 reply; 4+ messages in thread
From: Victor Wells @ 2000-01-25 22:52 UTC (permalink / raw
To: linux
*** 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: Embedded system with RAM Disk
2000-01-25 22:52 Embedded system with RAM Disk Victor Wells
@ 2000-01-26 19:15 ` Harald Koerfgen
[not found] ` <388F9ECA.DBFCED9D@negativezero.org>
0 siblings, 1 reply; 4+ messages in thread
From: Harald Koerfgen @ 2000-01-26 19:15 UTC (permalink / raw
To: Victor Wells; +Cc: linux, linux-mips
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Embedded system with RAM Disk
[not found] ` <388F9ECA.DBFCED9D@negativezero.org>
@ 2000-01-28 0:03 ` Ralf Baechle
[not found] ` <3890FE6A.B0A8B25@negativezero.org>
0 siblings, 1 reply; 4+ messages in thread
From: Ralf Baechle @ 2000-01-28 0:03 UTC (permalink / raw
To: Charles Lepple; +Cc: Harald Koerfgen, Victor Wells, linux, linux-mips
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 ;-)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Embedded system with RAM Disk
[not found] ` <3890FE6A.B0A8B25@negativezero.org>
@ 2000-01-28 18:37 ` Ralf Baechle
0 siblings, 0 replies; 4+ messages in thread
From: Ralf Baechle @ 2000-01-28 18:37 UTC (permalink / raw
To: Charles Lepple; +Cc: Ralf Baechle, linux, linux-mips
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-01-29 0:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-01-25 22:52 Embedded system with RAM Disk Victor Wells
2000-01-26 19:15 ` Harald Koerfgen
[not found] ` <388F9ECA.DBFCED9D@negativezero.org>
2000-01-28 0:03 ` Ralf Baechle
[not found] ` <3890FE6A.B0A8B25@negativezero.org>
2000-01-28 18:37 ` Ralf Baechle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.