Re: [gentoo-embedded] gentoo-embedded buildroot utility

[Christopher Friedt]

Hi Cliff,

Cliff Brake wrote:
> Sounds interesting.  I use OE extensively and it works well for what I
> do.  How does this solution handle cross compiling (for example ARM
> architectures)?  Can you point me to some reading or Google search
> phrases.  How is it different/similar to OE or scratchbox?

I always had portage in mind as soon as i started my embedded job about 
1 year ago - I looked at OpenEmbedded but found that compiling bitbaker 
always failed - Then I (and others) tried to get my board 
(embeddedarm.com) supported in OpenWRT, but the developer never ended up 
doing anything with the boards we gave him.

What my solution does, is create a chroot environment (much like how one 
goes about a stage1 gentoo installation), and installs crossdev.

When the actually building takes place, it simply enters the chroot, and 
you use 'xmerge' (see gentoo docs) to install the package, automatically 
generating a binary tarball.

I haven't used OE or scratchbox actually, but I knew what my own 
requirements were:

1) support multiple configurations

    - varies on a per-client or per-application basis
      which basically means you can use your embedded
      system to run several different applications
      customized for various clients, including varying
      default configuration files, source patches, and
      service definitions (through portage overlays)

    - you can copy configuration to a different target
      (i.e. the same app on different hardware)

    - a configuration is basically the same as an overlay
    - developers are free to impose a strict group of
      GENTOO_MIRRRORS with their specific overlays and
      portage trees.

2) support multiple targets (architectures)

    - program creates a directory called 'toolchains'
      and each toolchain resides in its own directory.
    - support toolchain version numbers, so the above
      directories would be called something like

'arm-softfloat-gnu__${binutilsver}__${libcver}__${kernelver}__${gccver}

    - You can share the same toolchain between
      configurations
      (i.e. multiple applications can run on the same hardware)
    - you can copy a configuration to a different target.

3) support a devel and stable profile for each configuration


This might not be so obvious, but a new embedded root filesystem image 
is generated based on the active profile in the selected configuration, 
not just on the configuration itself.


As i mentioned earlier, the above list only partially accounts for the 
complexit of the app. Another big job is deciphering the way that 
crossdev installs the libraries and the way that gcc-config deals with 
cross-compiling (i.e. where are the compiler profiles for gcc-config, 
where is the c library, where are the headers & asm files, where do we 
store application libraries, etc).

This is due to the fact that the system should support more than one 
toolchain - that is a requirement that I imposed myself. However, the 
reason for this complexity, is because this app exploits a sort of 
backdoor within portage that I'm not sure has been leveraged yet.

That is, the mechanism for entering and exiting the chroot is really the 
key - and also the __really__ complicated part.

This app is intended to mount -o bind and unmount the necessary 
directories, create / copy / destroy the necessary files, and perform 
all sanity checks to ensure that _inside_ the buildroot all functions as 
expected - for the selected target, configuration, and profile. It goes 
without saying that something done with one profile should be completely 
independent of something done with another profile.


The installation directory would look something like this:

$BR_HOME/

   toolchains/
     x86/
       arm-9tdmi-linux-gnu__${binutilsver}__ ...
       arm-softfloat-linux-uclibc__${binutilsver}__ ...
     x86_64/
       arm-9tdmi-linux-gnu__${binutilsver}__ ...
     sparc/
       arm-softfloat-linux-gnu__${binutilsver}__ ...

   buildroots/
     x86/
       /bin
       /usr
*       portage/
*       target -> arm-9tdmi-linux-gnu
*       arm-9tdmi-linux-gnu
       ...
*     /sysroot
*     /binpkgs
     x86_64/
     sparc/

   portage/


I hope that offers a bit more information. There is still a lot of work 
to do here, but at least it's contained, portable, etc.

Likely, a non-interactive mode will also be developed, where commands like

cp config <src_target> <dest_target>
rm profile <target> <config> <profile>
make sysroot <target> <config> <profile>

will be parsed and so on... allowing lots of possibilities ;-)


~/Chris
-- 
gentoo-embedded@g.o mailing list