linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* embedded linux: initrd root file-system in flash.
@ 1999-09-06  0:34 Brendan Simon
  0 siblings, 0 replies; 2+ messages in thread
From: Brendan Simon @ 1999-09-06  0:34 UTC (permalink / raw)
  To: linux-embedded, linuxppc-dev



I want to boot linux on a PowerPC embedded system WITHOUT using NFS.
>From what I can tell, initrd seems to be the best way of doing this.
All the docs I have read regarding initrd refer to LOADLIN or LILO.  I
am not using either as they assume some kind of disk like filesystem.
There are two methods that I can think of to use an initrd image stored
in flash.

1) Store it at a known location seperate from the kernel.  eg.
0x400000.  I think I like this option as the root filesystem can be
updated without touching the kernel/boot code and the start address is
always fixed.  Does anyone know how to tell the kernel where the
location of the initrd image is and how big it is ?  I assume that the
initrd image has to be uncompressed first or does the kernel assume it
is compressed if the root filesystem is /dev/ram ?

2) Store it as a seperate section in the kernel image.  This is what is
done with the mbx boot code.  The compressed kernel is stored as a
separate section of the boot code image.  I guess same questions for 1)
apply for this method.  The build processes can work out where to store
the initrd image in the resultant loadable image.  This information
would have to be passed to the kernel.  Any idea how this would be done
?

Thanks,
Brendan Simon.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: embedded linux: initrd root file-system in flash.
@ 1999-09-06  7:37 Joel Vallier
  0 siblings, 0 replies; 2+ messages in thread
From: Joel Vallier @ 1999-09-06  7:37 UTC (permalink / raw)
  To: brendan; +Cc: linuxppc-dev


Brendan Simon wrote:
> 
> 1) Store it at a known location seperate from the kernel.  eg.
> 0x400000.  I think I like this option as the root filesystem can be
> updated without touching the kernel/boot code and the start address is
> always fixed. Does anyone know how to tell the kernel where the
> location of the initrd image is and how big it is ?  I assume that the
> initrd image has to be uncompressed first or does the kernel assume it
> is compressed if the root filesystem is /dev/ram ?
> 
At the Linux boot time, the Linux Loader gives the initrd start address 
in register R4, initrd end address in register R5 and register R6 points 
to a command line string "root=/dev/ram".
(See arch/ppc/kernel/head.S file for more details).

If the inird is compressed, the Linux Loader have to uncompressed it first.

> 
> 2) Store it as a seperate section in the kernel image.  This is what is
> done with the mbx boot code.  The compressed kernel is stored as a
> separate section of the boot code image.  I guess same questions for 1)
> apply for this method.  The build processes can work out where to store
> the initrd image in the resultant loadable image.  This information
> would have to be passed to the kernel.  Any idea how this would be done
> ?
> 
In this case initrd is included in the vmlinux. So, It's uncompressed by 
the Linux Loader with the vmlinux image. The initrd location and size are 
defined at the compilation time. See INITRD_OFFSET and INIT_SIZE in the 
arch/ppc/boot/Makefile.

Joel Vallier

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1999-09-06  7:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-09-06  7:37 embedded linux: initrd root file-system in flash Joel Vallier
  -- strict thread matches above, loose matches on Subject: below --
1999-09-06  0:34 Brendan Simon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).