[Buildroot] initramfs, busybox init, switch_root and ARM

[Buildroot] initramfs, busybox init, switch_root and ARM

[Thomas Koster]

Hi list,

I am starting out with buildroot and have managed to build a minimal
environment with an initramfs for qemu's versatilepb ARM target.
Firstly I would like to thank everyone for making it so easy thus far!

Using a post-build script I compile and install a simple "hello world"
program into the target directory to be picked up by buildroot when it
makes the initramfs. The system boots in qemu and I can run my hello
program inside. My next step is to make a graphical "hello world"
using directfb, but I have concerns about the size of the kernel
growing too large for flash ROM if I start heaping binaries into the
initramfs. Additionally, at runtime the applications will be
generating files that clearly can't go in the initramfs. After several
hours of reading through tutorials and list posts, I'm a bit confused
about how to deal with this.

Question one: If the requisite drivers are included in the kernel
(e.g. ext2, or nfs + kernel network auto-configuration if I want an
NFS root), is an initramfs even necessary? Can I get away with the
'real' root filesystem being mounted from the start? In this case,
should I take advantage of buildroot's support for building directfb
et al. after all, build my apps (or even write my own buildroot
'packages' for them) and augment the root filesystem in a post-build
script as before, finally to have buildroot make an ext2 image for my
MMC card or NFS export? If going down the NFS path, how is /dev
handled?

Question two (if the answer to question one is mostly "no"): Else, I
expect the kernel will be installed to flash ROM with its initramfs
and the 'real' root filesystem will be on an MMC device (or on an NFS
export while I'm still working with qemu) and switch_root will be
used. Then I imagine I would build directfb together with my apps as a
target in my own build system, rather than have buildroot build such
things for the initramfs. Does this make sense or have I got this
wrong?

Question three (also if the answer to question one is mostly "no"):
Since buildroot installs busybox's init as /init in the initramfs, and
not some script, what is the correct procedure for configuring
busybox's init to do a switch_root? My first guess would be to use the
post-build script to replace /etc/inittab with a new one that includes
the requisite switch_root command, but what would such an inittab look
like? There are existing lines that look like they ought to run in the
new root. When should the switch_root happen?

In either case, I expect to be using busybox and uClibc throughout
(that is, I won't be using GNU libc or a debian root unless I hit a
major roadblock with uClibc). One day I might try compiling a java or
mono runtime for it but that is over the horizon.

Bonus question if you work with ARM boards: At some point I plan on
transitioning to a development board like the PandaBoard but one day
this environment might have to run on a less powerful device. Is this
a valid paradigm for this kind of target?

Thanks in advance,
Thomas

[Buildroot] initramfs, busybox init, switch_root and ARM

[Luca Ceresoli]

Thomas Koster wrote:
> ...
> Question one: If the requisite drivers are included in the kernel
> (e.g. ext2, or nfs + kernel network auto-configuration if I want an
> NFS root), is an initramfs even necessary?

No.

> Can I get away with the
> 'real' root filesystem being mounted from the start?

Yes!
If your kernel has all the drivers needed to mount the root filesystem
compiled in statically (=not as modules), there is usually no need to
have an initramfs.
This is frequent on embedded systems that have no or little variations
of hardware configuration.

Luca

[Buildroot] initramfs, busybox init, switch_root and ARM

[Thomas Petazzoni]

Hi Thomas,

On Mon, 18 Apr 2011 19:31:52 +1000
Thomas Koster <tkoster@gmail.com> wrote:

> Hi list,
> 
> I am starting out with buildroot and have managed to build a minimal
> environment with an initramfs for qemu's versatilepb ARM target.
> Firstly I would like to thank everyone for making it so easy thus far!
> 
> Using a post-build script I compile and install a simple "hello world"
> program into the target directory to be picked up by buildroot when it
> makes the initramfs. The system boots in qemu and I can run my hello
> program inside. My next step is to make a graphical "hello world"
> using directfb, but I have concerns about the size of the kernel
> growing too large for flash ROM if I start heaping binaries into the
> initramfs.

Yeah, typically initramfs is used for fairly small systems. But
theorically, the mechanism allows for initramfs of arbitrary size. As
long as you accept the longer boot time (because everything must be
loaded in RAM prior to starting the kernel) and the additional memory
consumption, initramfs are fine. But granted, when you start having
graphical applications, initramfs is probably no longer suited.

> Additionally, at runtime the applications will be generating files
> that clearly can't go in the initramfs.

You can still have an initramfs for application and static things, and
a special partition mounted for your generated data.

> After several hours of reading through tutorials and list posts, I'm
> a bit confused about how to deal with this.

> Question one: If the requisite drivers are included in the kernel
> (e.g. ext2, or nfs + kernel network auto-configuration if I want an
> NFS root), is an initramfs even necessary?

No.

> Can I get away with the 'real' root filesystem being mounted from the
> start?

Yes, just pass "root=/dev/something" in the kernel command line,
with /dev/something being the device containing your root filesystem.

> In this case, should I take advantage of buildroot's support
> for building directfb et al. after all, build my apps (or even write
> my own buildroot 'packages' for them) and augment the root filesystem
> in a post-build script as before, finally to have buildroot make an
> ext2 image for my MMC card or NFS export?

Yes, correct.

> If going down the NFS path, how is /dev handled?

As Buildroot doesn't run as root, it cannot create device files
directly in your filesystem. Therefore, to do NFS, what you need to do
is to tell Buildroot to generate a tarball as the image of your root
filesystem (menuconfig -> Target filesystem options), and then once
Buildroot has generated this tarball, extract it as root in some
directory exported by your NFS server.

> Question two (if the answer to question one is mostly "no"): Else, I
> expect the kernel will be installed to flash ROM with its initramfs
> and the 'real' root filesystem will be on an MMC device (or on an NFS
> export while I'm still working with qemu) and switch_root will be
> used. Then I imagine I would build directfb together with my apps as a
> target in my own build system, rather than have buildroot build such
> things for the initramfs. Does this make sense or have I got this
> wrong?

Well, as the answer to the question above is 'yes', I don't know if you
care. But yes, you can have the following boot sequence :

 * Kernel starts
 * Kernel uncompresses the initramfs and executes the /init script or
   application inside the initramfs
 * The /init script or application loads some drivers, do some stuff,
   and ultimately mounts the final root filesystem, and switch_root to
   it, and then finally starts the /sbin/init application of the real
   root filesystem.

Buildroot is not directly capable of generating *both* an initramfs and
a real root filesystem in a single build. You'd have to create two
separate Buildroot configurations and builds, one for the initramfs,
and one for the real root filesystem.

> Question three (also if the answer to question one is mostly "no"):
> Since buildroot installs busybox's init as /init in the initramfs, and
> not some script, what is the correct procedure for configuring
> busybox's init to do a switch_root? My first guess would be to use the
> post-build script to replace /etc/inittab with a new one that includes
> the requisite switch_root command, but what would such an inittab look
> like? There are existing lines that look like they ought to run in the
> new root. When should the switch_root happen?

In the initramfs, most likely, /init wouldn't be a symlink to Busybox,
but rather a shell script of your own that does everything needed to
switch to the real root filesystem.

> In either case, I expect to be using busybox and uClibc throughout
> (that is, I won't be using GNU libc or a debian root unless I hit a
> major roadblock with uClibc). One day I might try compiling a java or
> mono runtime for it but that is over the horizon.

Ouch, Java and Mono runtime are probably not the easiest things to get
running on non-x86 platforms. Definitely possible, but probably not
easy.

> Bonus question if you work with ARM boards: At some point I plan on
> transitioning to a development board like the PandaBoard but one day
> this environment might have to run on a less powerful device. Is this
> a valid paradigm for this kind of target?

Which paradigm ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] initramfs, busybox init, switch_root and ARM

[Anders Darander]

On Wed, Apr 20, 2011 at 00:04, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Mon, 18 Apr 2011 19:31:52 +1000
> Thomas Koster <tkoster@gmail.com> wrote:
>> In either case, I expect to be using busybox and uClibc throughout
>> (that is, I won't be using GNU libc or a debian root unless I hit a
>> major roadblock with uClibc). One day I might try compiling a java or
>> mono runtime for it but that is over the horizon.
>
> Ouch, Java and Mono runtime are probably not the easiest things to get
> running on non-x86 platforms. Definitely possible, but probably not
> easy.

Well, it can be a little bit tricky, but it's manageable.

1 - 1 1/2 year ago, I got a few JavaVM's up and running (at least one
of them were in buildroot at that time). Unfortunately, our Java-guy
insisted that GNU's Classpath was unsuitable for our project; thus, we
had to change the JavaVM. Ultimately, we used the PhoneME JavaVM (with
the advanced profile, not the feature profile) up and running. At that
time, it required a few patches to the build and configuration
scripts.

This was all done for an ARM9-platform (at91sam9260).

/Anders