[Buildroot] Creating a filesystem for Real Time Linux using QEMU

Chris Packham judge.packham at gmail.com
Mon Nov 16 19:44:48 UTC 2009


It depends what you want to do. Normally (in the way I use it)
buildroot generates a root file system which I can then load onto an
embedded (or emulated) target. I generally leave this as my software
image for that device, that way I can guarantee what the device boots
up with.

The contents of the generated file system are determined by what I've
configured buildroot to install for me. Any additions/changes to the
contents of that image I make by changing my buildroot config and
recompiling. I generally consider that file system readonly or at the
very least not persistent.

If I want to store something on my target I do this on some other
mounted media (usually flash). Others might write the image into the
devices flash and allow changes to be saved into flash. Both
approaches have their pros and cons.

When using qemu you can use the qemu-img utility to generate a fake
hard drive and feed it to qemu.

On your host PC do this once to create a new image

    qemu-img create -f raw flash.img 32M

Invoke qemu feeding it the -hdb option for a second hard drive

    qemu -kernel $LOCATION/bzImage \
        -hda $LOCATION/rootfs.i686.ext2 \
        -hdb flash.img \
        -append "root=/dev/sda"

On the emulated target you can mount it
    mount -t ext2 /dev/hdb /mnt/writeable

You can play with various files in buildroot to have it mounted
automatically e.g. target/generic/target_skeleton/etc/fstab or
target/device/<company>/<board>/target_skeleton/etc/fstab

It may also be worth looking at qemu's copy-on-write or snapshot
capabilities. I've never used it but it sounds neat and will probably
allow you to start with an image generated by buildroot and make
modifications to that image from the emulated target.

---
Regards,
Chris


More information about the buildroot mailing list