howto? Build something but not deploy in root image

howto? Build something but not deploy in root image

[Tom Walsh]

I know, this has come up before.  Reading through some of the old 
messages I see this discussed, but, I do not see any solution(s) mentioned?

I have several parts to this project that must be built during the 
bitbake process (bootstrap-image), but are not part of the target 
filesystem image.  The total system parts are:

* bootloader - ARM - resides in Flash.
* kernel - ARM - resides in Flash.
* target rootfs image - ARM - resides on MMC card.
* Flash Utility - native (x86) - runs on host computer.

The concept for the system is that the bootloader starts the RAM and 
other hardware up.  It then copies the kernel image into RAM and 
launches it.  The kernel is configured to look for its root filesystem 
on the MMC card.  Essentially, I boot the kernel from Flash, but the 
kernel boots from the MMC card.

The only thing that I need in the root filesystem (tmp/rootfs/) is the 
packages I named from the local conf files.  The kernel does need to be 
there, it soaks up space uselessly.

As to the bootloader, it comes in two sections (files), these are 
programmed by the Flash Utility into the target system.  The bootloader 
is not needed in the root filesystem.

The problem is not getting these things built, but preventing them from 
being installed in the tmp/rootfs/ filesystem or tarball.  They should 
only go into tmp/deploy/image/, which  I currently have them going 
into...  However, the bitbake system assumes that anything that is 
packaged, must be deployed into the root filesystem!?

How do you build a bootloader that resides in Flash and doesn't get 
stuck into the filesystem image?  The same would hold true for the 
native (linux PC) app which flashes the target memory.

Regards,

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: howto? Build something but not deploy in root image

[Justin Patrin]

On 7/4/07, Tom Walsh <tom@openhardware.net> wrote:
> I know, this has come up before.  Reading through some of the old
> messages I see this discussed, but, I do not see any solution(s) mentioned?
>
> I have several parts to this project that must be built during the
> bitbake process (bootstrap-image), but are not part of the target
> filesystem image.  The total system parts are:
>
> * bootloader - ARM - resides in Flash.
> * kernel - ARM - resides in Flash.
> * target rootfs image - ARM - resides on MMC card.
> * Flash Utility - native (x86) - runs on host computer.
>
> The concept for the system is that the bootloader starts the RAM and
> other hardware up.  It then copies the kernel image into RAM and
> launches it.  The kernel is configured to look for its root filesystem
> on the MMC card.  Essentially, I boot the kernel from Flash, but the
> kernel boots from the MMC card.
>
> The only thing that I need in the root filesystem (tmp/rootfs/) is the
> packages I named from the local conf files.  The kernel does need to be
> there, it soaks up space uselessly.
>
> As to the bootloader, it comes in two sections (files), these are
> programmed by the Flash Utility into the target system.  The bootloader
> is not needed in the root filesystem.
>
> The problem is not getting these things built, but preventing them from
> being installed in the tmp/rootfs/ filesystem or tarball.  They should
> only go into tmp/deploy/image/, which  I currently have them going
> into...  However, the bitbake system assumes that anything that is
> packaged, must be deployed into the root filesystem!?

This isn't quite true. Bitbake installs whatever packages are in the
RDEPENDS of the image. I think what you would do it make sure that
your bootloader, etc are in the DEPENDS but not the RDEPENDS.

>
> How do you build a bootloader that resides in Flash and doesn't get
> stuck into the filesystem image?  The same would hold true for the
> native (linux PC) app which flashes the target memory.
>

-- 
Justin Patrin

Re: howto? Build something but not deploy in root image

[Paul Sokolovsky]

Hello Tom,

Thursday, July 5, 2007, 8:01:05 AM, you wrote:

> I know, this has come up before.  Reading through some of the old 
> messages I see this discussed, but, I do not see any solution(s) mentioned?

  Well, until recently, OE had issues with building truly minimal and
well-polished images. This yet needs to be described in howto-like
manner, that's on my todo.

> I have several parts to this project that must be built during the 
> bitbake process (bootstrap-image), but are not part of the target 
> filesystem image.  The total system parts are:

> * bootloader - ARM - resides in Flash.
> * kernel - ARM - resides in Flash.
> * target rootfs image - ARM - resides on MMC card.
> * Flash Utility - native (x86) - runs on host computer.

> The concept for the system is that the bootloader starts the RAM and 
> other hardware up.  It then copies the kernel image into RAM and 
> launches it.  The kernel is configured to look for its root filesystem
> on the MMC card.  Essentially, I boot the kernel from Flash, but the 
> kernel boots from the MMC card.

> The only thing that I need in the root filesystem (tmp/rootfs/) is the
> packages I named from the local conf files.

  This is one feature which is possible now. You name exact and
complete list of packages you want to install into image, and nothing
else gets installed, not even dependencies. This is of course highly
special-purpose feature, and you don't want to use it on realistic
rootfs with dozens of packages, it is indtended for initrds/initramfs,
which consist of few packages and where each KB counts.

>  The kernel does need to be
> there, it soaks up space uselessly.

  Kernel is indeed special case, and there was some kind of adhoc
support for doing what you want all the time in OE. Couple of months
ago Richard Purdie implemented more scalable support for this though,
so search archives for his RFC.

> As to the bootloader, it comes in two sections (files), these are 
> programmed by the Flash Utility into the target system.  The bootloader
> is not needed in the root filesystem.

  Besides two special cases above, when you really need to subvert
OE's dependency handling, for all other cases you just need to get it
right. The only reason why bootloader is installed into image is that
something RDEPENDS on it (or it listed as top-level package to install
;-) ). So, fix your dependencies, and it will be ok.

> The problem is not getting these things built, but preventing them from
> being installed in the tmp/rootfs/ filesystem or tarball.  They should
> only go into tmp/deploy/image/, which  I currently have them going 
> into...  However, the bitbake system assumes that anything that is 
> packaged, must be deployed into the root filesystem!?

> How do you build a bootloader that resides in Flash and doesn't get 
> stuck into the filesystem image?  The same would hold true for the 
> native (linux PC) app which flashes the target memory.

> Regards,

> TomW




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: howto? Build something but not deploy in root image

[Marcin Juszkiewicz]

Dnia czwartek, 5 lipca 2007, Tom Walsh napisał:

> I have several parts to this project that must be built during the
> bitbake process (bootstrap-image), but are not part of the target
> filesystem image.  The total system parts are:
>
> * bootloader - ARM - resides in Flash.
> * kernel - ARM - resides in Flash.
> * target rootfs image - ARM - resides on MMC card.
> * Flash Utility - native (x86) - runs on host computer.

In machine config add:

IMAGEDEPENDS = "bootloader flash-utility-native"

Basically it should be MACHINE_EXTRA_DEPENDS but we do not support it yet 
properly.

> The only thing that I need in the root filesystem (tmp/rootfs/) is the
> packages I named from the local conf files. 

Create own image recipe and add those packages to RDEPENDS and 
PACKAGE_INSTALL.

> As to the bootloader, it comes in two sections (files), these are
> programmed by the Flash Utility into the target system.  The bootloader
> is not needed in the root filesystem.

> The problem is not getting these things built, but preventing them from
> being installed in the tmp/rootfs/ filesystem or tarball.  They should
> only go into tmp/deploy/image/, which  I currently have them going
> into...  

Look at uboot/u-boot* recipes and their do_deploy() tasks which copy 
bootloader into tmp/deploy/images/ dir.

> However, the bitbake system assumes that anything that is 
> packaged, must be deployed into the root filesystem!?

No. Image is built from packages, but from selected ones only.

> How do you build a bootloader that resides in Flash and doesn't get
> stuck into the filesystem image?  The same would hold true for the
> native (linux PC) app which flashes the target memory.

In their recipes add do_deploy() task which copies them to 
tmp/deploy/images/ dir.


-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

     Free speech includes the right not to listen, if not interested 
                                                [Robert A. Heinlein]

Re: howto? Build something but not deploy in root image

[Tom Walsh]

Marcin Juszkiewicz wrote:
> Dnia czwartek, 5 lipca 2007, Tom Walsh napisał:
>
>   
>> I have several parts to this project that must be built during the
>> bitbake process (bootstrap-image), but are not part of the target
>> filesystem image.  The total system parts are:
>>
>> * bootloader - ARM - resides in Flash.
>> * kernel - ARM - resides in Flash.
>> * target rootfs image - ARM - resides on MMC card.
>> * Flash Utility - native (x86) - runs on host computer.
>>     
>
> In machine config add:
>
> IMAGEDEPENDS = "bootloader flash-utility-native"
>
> Basically it should be MACHINE_EXTRA_DEPENDS but we do not support it yet 
> properly.
>
>   
>> The only thing that I need in the root filesystem (tmp/rootfs/) is the
>> packages I named from the local conf files. 
>>     
>
> Create own image recipe and add those packages to RDEPENDS and 
> PACKAGE_INSTALL.
>
>   

Yes, that is what I was trying to avoid: building a custom image 
recipe.  It just seemed that it should be possible to thwart the copy of 
the kernel image into /boot from setting a variable or something.  The 
OE system changes quite frequently and I found myself in trouble with my 
own image recipe where I was "away" for several months and "returned".

Adding a DEPENDS for the bootloader and utils within the kernel recipe 
did resolve the issue of having the  image recipe attempting to install 
those two packages into the IMAGE.  I still have a 1.3Meg kernel in the 
/boot directory, though, I guess half a loaf is better than none?  At 
least OE now builds the entire project without stopping along the way to 
complain about "iconv.h" and other such things.

Regards,

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: howto? Build something but not deploy in root image

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Walsh schreef:

> Yes, that is what I was trying to avoid: building a custom image 
> recipe.  It just seemed that it should be possible to thwart the copy of 
> the kernel image into /boot from setting a variable or something.  The 
> OE system changes quite frequently and I found myself in trouble with my 
> own image recipe where I was "away" for several months and "returned".

You are highlighting the exact reason why not submitting your work for inclusion into OE
is bad.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGmiITMkyGM64RGpERAok3AJ9oXLOIVJaL1E9S/Dj3RousCPNY7QCdHHL1
wtaaFQRvQ8pwr9XCTLmdgR4=
=eKIP
-----END PGP SIGNATURE-----

Re: howto? Build something but not deploy in root image

[Holger Freyther]

Am 15.07.2007 um 15:33 schrieb Koen Kooi:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tom Walsh schreef:
>
>> Yes, that is what I was trying to avoid: building a custom image
>> recipe.  It just seemed that it should be possible to thwart the  
>> copy of
>> the kernel image into /boot from setting a variable or something.   
>> The
>> OE system changes quite frequently and I found myself in trouble  
>> with my
>> own image recipe where I was "away" for several months and  
>> "returned".
>
> You are highlighting the exact reason why not submitting your work  
> for inclusion into OE
> is bad.

And that a meaningful ChangeLog could help as well.

z.