headers
Brenden Walker | 6 Aug 22:19

newbie - building bootable image for ARM target on I686 host

I'm new to embedded linux, but been using Gentoo for a long time.. I'd like to use gentoo embedded of course.

I'm working on a project that will likely be deployed on an ARM processor, the application will most likely
be written in java so I need to be able to create a bootable ARM *nix image with a JVM installed on it.  Our
application would likely reside on writable media, the OS probably RO.

I've setup a Gentoo system for cross dev to arm-unknown-linux-gnu and that all works.  I've setup a seperate
root and can emerge packages there.

What I'm stumped on it how to make a bootable disk image.  At this time the plan was to use QEMU to demonstrate
the basic process and for use in developing our application, so a disk image suitable for QEMU is what I'm
hoping for.

Hope what I'm trying to do is clear, I found a lot of resources on the net (allowed me to get cross compiling up
and running with no hassle) just can't seem to find anything that puts it all together.  I've already
traveled down a couple of dead end paths (GNAP, which doesn't seem to support ARM..?) hoping someone here
could point me in the correct direction.

Thanks!
Permalink | Reply | 4 comments |
headers
Karl Hiramoto | 7 Aug 13:09
Gravatar

Re: newbie - building bootable image for ARM target on I686 host

Brenden Walker wrote:
> I'm new to embedded linux, but been using Gentoo for a long time.. I'd like to use gentoo embedded of course.
>
> I'm working on a project that will likely be deployed on an ARM processor, the application will most likely
be written in java so I need to be able to create a bootable ARM *nix image with a JVM installed on it.  Our
application would likely reside on writable media, the OS probably RO.
>
> I've setup a Gentoo system for cross dev to arm-unknown-linux-gnu and that all works.  I've setup a
seperate root and can emerge packages there.
>
> What I'm stumped on it how to make a bootable disk image.  At this time the plan was to use QEMU to demonstrate
the basic process and for use in developing our application, so a disk image suitable for QEMU is what I'm
hoping for.
>   
The concept of bootable disk doesn't really exist.  On most ARM HW i've 
worked with the way the boot process works is you have a boot loader 
(redboot, uboot, etc) that loads the kernel, then the kernel paramaters 
tell it how to mount the root FS.

QEMU works kinda the same.  QEMU is the boot loader and you tell it the 
kernel image name, then pass the kernel args to mount the root for example:

qemu-system-arm -M versatilepb -hda sda.img -kernel zImage -append 
"root=/dev/sda1 clock=pit"

If your interested in the kernel details theres a general doc in 
<linux>/Documentation/arm/Booting

I have an old (kernel 2.6.19) qemu image, based on one somebody on this 
list posted a long time ago,  that you can boot:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brenden Walker | 7 Aug 14:24

Re: newbie - building bootable image for ARM target on I686 host

On Fri, 07 Aug 2009 13:09:56 +0200 Karl Hiramoto <karl@...> wrote:
> Brenden Walker wrote:
> > I'm new to embedded linux, but been using Gentoo for a long time..
<snip>
> > time the plan was to use QEMU to demonstrate the basic process and
> > for use in developing our application, so a disk image suitable for
> > QEMU is what I'm hoping for. 
> The concept of bootable disk doesn't really exist.  On most ARM HW
> i've worked with the way the boot process works is you have a boot
> loader (redboot, uboot, etc) that loads the kernel, then the kernel
> paramaters tell it how to mount the root FS.
> 
> QEMU works kinda the same.  QEMU is the boot loader and you tell it
> the kernel image name, then pass the kernel args to mount the root
> for example:
> 
> qemu-system-arm -M versatilepb -hda sda.img -kernel zImage -append 
> "root=/dev/sda1 clock=pit"
> 
> 
> If your interested in the kernel details theres a general doc in 
> <linux>/Documentation/arm/Booting
> 
> 
> I have an old (kernel 2.6.19) qemu image, based on one somebody on
> this list posted a long time ago,  that you can boot:
> http://karl.hiramoto.org/embedded/qemu-arm.tar.lzma

Thanks for the help, I think my main issues are what boot loader, how to get it into an image and what to use to
build the image.  If I can get that figured out, I've got a gentoo setup for building arm binaries... I could
(Continue reading)

Permalink | Reply | 2 comments |
headers
wireless | 7 Aug 19:30
Picon

Re: newbie - building bootable image for ARM target on I686 host

Brenden Walker wrote:
> On Fri, 07 Aug 2009 13:09:56 +0200 Karl Hiramoto <karl@...> wrote:
>> Brenden Walker wrote:
>>> I'm new to embedded linux, but been using Gentoo for a long time..
> <snip>
>>> time the plan was to use QEMU to demonstrate the basic process and
>>> for use in developing our application, so a disk image suitable for
>>> QEMU is what I'm hoping for. 
>> The concept of bootable disk doesn't really exist.  On most ARM HW
>> i've worked with the way the boot process works is you have a boot
>> loader (redboot, uboot, etc) that loads the kernel, then the kernel
>> paramaters tell it how to mount the root FS.
>>
>> QEMU works kinda the same.  QEMU is the boot loader and you tell it
>> the kernel image name, then pass the kernel args to mount the root
>> for example:
>>
>> qemu-system-arm -M versatilepb -hda sda.img -kernel zImage -append 
>> "root=/dev/sda1 clock=pit"
>>
>>
>> If your interested in the kernel details theres a general doc in 
>> <linux>/Documentation/arm/Booting
>>
>>
>> I have an old (kernel 2.6.19) qemu image, based on one somebody on
>> this list posted a long time ago,  that you can boot:
>> http://karl.hiramoto.org/embedded/qemu-arm.tar.lzma
> 
> Thanks for the help, I think my main issues are what boot loader, how to get it into an
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ed W | 9 Aug 19:03

root on squashfs+aufs

Hi, I'm interested in hearing how others have managed a root filesystem 
based on squashfs (or similar) with layering using aufs (or unionfs)?

I am building an embedded box and it looks like it would work well to 
have a simple package manager based around a bunch of squashfs 
partitions which layer on new functionality for certain builds (and it 
would allow some versioning).  On the top of that we need a writeable 
bunch of configuration files which we might do either with symlinks or a 
writeable top level partition (still undecided).

Mainly interested to hear how others have managed the boot process and 
built their initrd/linuxrc?  I'm sure I read about at least one person 
on this list calling a similar setup "squashfs packages"?

Thanks

Ed W
Permalink | Reply | 5 comments |
headers
joerg.faschingbauer | 9 Aug 19:30
Picon

Re: root on squashfs+aufs

>>>>> "Ed" == Ed W <lists@...> writes:

Ed> Hi, I'm interested in hearing how others have managed a root
Ed> filesystem based on squashfs (or similar) with layering using aufs (or
Ed> unionfs)?

Ed> I am building an embedded box and it looks like it would work well to
Ed> have a simple package manager based around a bunch of squashfs
Ed> partitions which layer on new functionality for certain builds (and it
Ed> would allow some versioning).  On the top of that we need a writeable
Ed> bunch of configuration files which we might do either with symlinks or
Ed> a writeable top level partition (still undecided).

Ed> Mainly interested to hear how others have managed the boot process and
Ed> built their initrd/linuxrc?  I'm sure I read about at least one person
Ed> on this list calling a similar setup "squashfs packages"?

I did a setup using aufs. Not squashfs, but iso9660 instead (people
like to use Windows to create packages). Anyway, it shouldn't make a
real difference which filesystem is used.

It starts with an initramfs containing busybox, /init, and a few
helper scripts that implement the stacking of the packages. init and
the scripts interpret a bunch of custom kernel commandline parameters
of their own, like 'Where are my packages?' (ISOs are files on a FAT32
partition on the compact flash), and 'Where will I write to?'  (this
can be either another directory on a filesystem, or a ramfs instance).

When all packages have been stacked, hook scripts that come with the
packages are run in a chroot. For example, packages can add their own
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ed W | 9 Aug 19:36

Re: root on squashfs+aufs


Hi, this seems extremely similar to what I am targeting!

joerg.faschingbauer@... wrote:
> When all packages have been stacked, hook scripts that come with the
> packages are run in a chroot. For example, packages can add their own
> init scripts by calling rc-update, or add users, or whatnot.
>   

I assume you run these hook scripts each time you boot then?  This seems 
like a good idea, I had been thinking about putting that on the writable 
partition and dreaming up some way to ensure that the scripts were only 
run once - I think your design is cleaner (although need to watch boot 
speeds)

I would be very interested to pick over your implementation details if 
you were willing to share (offlist if you don't think it's sensible to 
post publically?).  I'm quite interested in how you picked the package 
list and ordered them and exactly how you implemented the hook scripts 
and failure conditions?

> What I am extremely excited about is that everything worked right out
> of the box. Not even one single problem. I expected aufs to fail with
> many branches (currently we have some 50 of them), busybox to be not
> compatible enough with the shell, initramfs to impose too many
> restrictions ... - nothing.
>   

That's really good to hear!  I am currently only planning about 3-4 
packages, but based on what you say I might look to split my packages
(Continue reading)

Permalink | Reply | 3 comments |
headers
joerg.faschingbauer | 9 Aug 20:02
Picon

Re: root on squashfs+aufs

>>>>> "Ed" == Ed W <lists@...> writes:

>> When all packages have been stacked, hook scripts that come with the
>> packages are run in a chroot. For example, packages can add their own
>> init scripts by calling rc-update, or add users, or whatnot.
>> 

Ed> I assume you run these hook scripts each time you boot then?  This
Ed> seems like a good idea, I had been thinking about putting that on the
Ed> writable partition and dreaming up some way to ensure that the scripts
Ed> were only run once - I think your design is cleaner (although need to
Ed> watch boot speeds)

You definitely have to. Although our platform is "embedded" in a sense
that it has no keyboard and mouse, and that it has to "just work", it
has a dual core 2GHz Intel. This is not to say that boot is slow
(rc-update does not crunch numbers), it's just that it is fast enough
and we didn't invest much to speed it up.

Ed> I would be very interested to pick over your implementation details if
Ed> you were willing to share (offlist if you don't think it's sensible to
Ed> post publically?).  I'm quite interested in how you picked the package
Ed> list and ordered them and exactly how you implemented the hook scripts
Ed> and failure conditions?

Unfortunately I did the work for my employer, so I cannot share it
with you, at least not character by character.

One package (one ISO) contains several directories which become aufs
branches during boot, and a dedicated single directory that contains
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ed W | 9 Aug 20:18

Re: root on squashfs+aufs

Hi

> One package (one ISO) contains several directories which become aufs
> branches during boot, and a dedicated single directory that contains
> links like
>
>  00base-os -> ../base-os
>  10core-modules -> ../blah
>
> It's these links that give the order of the stack, and it's actually
> the links that are being stacked. You need this order because (at
> least) the base OS install has to come first. 

Hmm, I think I need to read up on the aufs mount options.  I'm still at 
the planning stage, but if aufs is really this flexible then it will 
help a lot.  Sounds like you can pretty much do "ls -1 | sort" in your 
case and use the result as your mount command?

Perhaps you don't even need your hook scripts then?  They could just 
become normal /etc/init.d scripts and would get run normally as part of 
the standard boot process?

> Definitely. What I did was to keep things separate when they are not
> related to each other. Some of the directories have a tree structure
> that hosts only one single file. I don't have 50 ISO files around
> though - I aggregate many directories into one ISO.
>
>   

Did you consider gpg signing stuff?  I can see this would make a lot of
(Continue reading)

Permalink | Reply | 1 comment |
headers
joerg.faschingbauer | 9 Aug 23:14
Picon

Re: root on squashfs+aufs

>>>>> "Ed" == Ed W <lists@...> writes:

Ed> Hmm, I think I need to read up on the aufs mount options.  I'm still
Ed> at the planning stage, but if aufs is really this flexible then it
Ed> will help a lot.  Sounds like you can pretty much do "ls -1 | sort" in
Ed> your case and use the result as your mount command?

That's basically what I do.

Ed> Perhaps you don't even need your hook scripts then?  They could just
Ed> become normal /etc/init.d scripts and would get run normally as part
Ed> of the standard boot process?

They don't run just because they are there. Well, I could add the
symlinks in /etc/runlevels/default which is what rc-update does, but
that's no fun.

We enjoy the flexibility of the scripts because they provide a
convenient way to glue the system together. For example, several
packages contribute kernel modules, and it's a hook script where we
call 'depmod -a' to create a consistent view of the entire
system. Much like env-update is called from a hook to gather
environment settings from different packages.

Ed> Did you consider gpg signing stuff?  I can see this would make a lot
Ed> of sense for my app, but worried this is going to add a ton of time to
Ed> the boot process...

We sign ISO files, this involves ECDSA and smartcards. I cannot tell
you more, or I'll have to kill you. (Honestly, I don't quite
(Continue reading)

Permalink | Reply | 0 comments |

Gmane