[Buildroot] [RFC] How to handle targets that need more than one file system to boot?
Yann E. MORIN
yann.morin.1998 at free.fr
Mon Dec 24 00:00:17 UTC 2012
Hello All!
Some systems require a specific partition layout to be able to boot.
For example:
- the RaspberryPi:
- the first, primary partition, and vfat-formatted, with the bootloader
files and the kernel
- the rest of the filesystem hierarchy can be dispatched at will
- on i.MX:
- the first, (primary?) partition must be non-FAT (special type?), with
the bootloader raw-binary inside
- the rest of the filesystem hierarchy can be whatever
- on OMAP paltforms:
- similar to the PI, but the kernel can be on ext2/3/4 (as wel as VFAT?)
For now, buildroot can build a single filesystem image. This is not useable
for these systems. The only possibility as of today is to configure BR to
generate a tarball, and have a custom script that does the required split up
of the different components.
It would be nice to have buildroot smoothly handle these cases.
After a quick talk on IRC with Thomas, here are a few proposals.
0) Keep as-is
Buildroot can not handle all possibilities, we can't even *think* about
all such possibilities. This is the easiest for buildroot, and pushes the
complexity down to the users.
1) Known, simple cases
Provision for a few select, known-simple cases (such as /boot on VFAT with
bootloader and kernel). This can be done rather easily, but is not worth
the effort only if it does not address most cases.
2) Use a descriptive, versatile framework
We could add an option in the menuconfig where the user could specify a
description (in a file) of the required layout, a bit like fs/ubi/ubinize
we have today. This would be in addition to the existing options, not a
replacement.
For example (syntax is just a first draft):
[defaults]
part.type=ext
part.align=1MiB
fs.size=auto
fstab=yes
fstab.mount=boot
raw.content=file
[bootloader]
part.type=pri
part.nb=1
part.align=4MiB # Mandatory by design
fs.type=raw
raw.file=/boot/boot.raw
fstab=no
[boot]
fs.dir=/boot
fs.type=fat
fstab.mount=no
fs.label=boot
part.type=pri
fat.bits=32
[root]
fs.type=squashfs
fs.label=root
fs.size=64MiB
fs.dir=/
squashfs.comp=xz
[home]
fs.dir=/home
fs.type=ext4
fs.size=+1GiB
fs.label=home
[swap]
fs.type=raw
part.size=128MiB
raw.content=gen
raw.gen=exec:scripts/generate-swap 128MiB
fstab.mount=no
Of course, this is far from being exhaustive, but the basics are visible:
- syntax is .ini-like
- order is not significant
- missing fields are guessed or computed (eg. partition type/number),
or use default values (to be documented)
- sizes can be automatic ('auto'), enforced ('64MiB'), or free space
('+1GiB')
- filesystem-agnostic options (eg. 'fs.label'), and filesystem-specific
options (eg. 'fat.bits')
- content can be generated
- # starts a comment
So, what are your comments on this?
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list