RFC; Building multiple u-boot images for a single board

RFC; Building multiple u-boot images for a single board

[Ulf Samuelsson]

If you want to support multiple boot memories, you have to
have multiple boards in the conf/machine directory

I currently testing a change to at91bootstrap, where a defconfig
is not provided by openembedded.
Instead you provide a list of defconfig's in your machine description:

I.E: in conf/machien/at91sam9g45ek.conf you have:

AT91BOOTSTRAP_BOARD = "at91sam9g45df at91sam9g45ek at91sam9g45nf"

when at91bootstrap is built it will loop through all the boards.
and build three versions.

I think it would make sense to do the same for u-boot,
so that you can build u-boot for several configurations.

This change would happen from u-boot-2009.11 an onwards.

In your machine conf you would supply:
UBOOT_MACHINES = "at91sam9g45ekes_nandflash at91sam9g45ekes_dataflash"

A loop goes through the list
and runs make on each element in the list.

make at91sam9g45ekes_nandflash_config
make
make at91sam9g45ekes_dataflash_config
make

if UBOOT_MACHINES is not set, then a single build is done using
UBOOT_MACHINE as usual.

This will allow u_boot to be built for every boot configuration
without having to add a lot of files.

-- 
Best Regards
Ulf Samuelsson

Re: RFC; Building multiple u-boot images for a single board

[Marcin Juszkiewicz]

+1 on it as it really saves times. 

I have at91sam9263ek board which can boot (read: load u-boot) from dataflash 
or from nand (if you have newer revision of board then I) so two uboots needs 
to be built for it.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: RFC; Building multiple u-boot images for a single board

[Frans Meulenbroeks]

2010/2/26 Ulf Samuelsson <ulf.samuelsson@atmel.com>:
> If you want to support multiple boot memories, you have to
> have multiple boards in the conf/machine directory
>
> I currently testing a change to at91bootstrap, where a defconfig
> is not provided by openembedded.
> Instead you provide a list of defconfig's in your machine description:
>
> I.E: in conf/machien/at91sam9g45ek.conf you have:
>
> AT91BOOTSTRAP_BOARD = "at91sam9g45df at91sam9g45ek at91sam9g45nf"
>
> when at91bootstrap is built it will loop through all the boards.
> and build three versions.
>
> I think it would make sense to do the same for u-boot,
> so that you can build u-boot for several configurations.
>
> This change would happen from u-boot-2009.11 an onwards.
>
> In your machine conf you would supply:
> UBOOT_MACHINES = "at91sam9g45ekes_nandflash at91sam9g45ekes_dataflash"
>
> A loop goes through the list
> and runs make on each element in the list.
>
> make at91sam9g45ekes_nandflash_config
> make
> make at91sam9g45ekes_dataflash_config
> make
>
> if UBOOT_MACHINES is not set, then a single build is done using
> UBOOT_MACHINE as usual.
>
> This will allow u_boot to be built for every boot configuration
> without having to add a lot of files.
>

I fully agree (as I also need two different versions for my board, one
for flash, one for sd).

Re: RFC; Building multiple u-boot images for a single board

[Koen Kooi]

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

On 26-02-10 12:37, Ulf Samuelsson wrote:
> If you want to support multiple boot memories, you have to
> have multiple boards in the conf/machine directory
> 
> I currently testing a change to at91bootstrap, where a defconfig
> is not provided by openembedded.
> Instead you provide a list of defconfig's in your machine description:
> 
> I.E: in conf/machien/at91sam9g45ek.conf you have:
> 
> AT91BOOTSTRAP_BOARD = "at91sam9g45df at91sam9g45ek at91sam9g45nf"
> 
> when at91bootstrap is built it will loop through all the boards.
> and build three versions.
> 
> I think it would make sense to do the same for u-boot,
> so that you can build u-boot for several configurations.

Not about u-boot, but slightly related:

I need something similar for uImages due to hardware limitations
(daughtercards requiring conflicting pinmux) and I have created this for
kernel builds:

http://dominion.thruhere.net/git/cgit.cgi/openembedded/tree/recipes/linux/multi-kernel.inc?h=ti/staging

It's working nicely for my usecase (validate hardware configs with
multiple kernels, validate software with only one kernel).

regards,

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

iD8DBQFLh8VOMkyGM64RGpERAi62AKCMoAAQyfLYmsU9NfD7+MI7o3m4bwCdHqS6
Ub+2N46Sd2Q/t+nHlfzjDE8=
=9/62
-----END PGP SIGNATURE-----

Re: RFC; Building multiple u-boot images for a single board

[Tom Rini]

On Fri, 2010-02-26 at 13:57 +0100, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 26-02-10 12:37, Ulf Samuelsson wrote:
> > If you want to support multiple boot memories, you have to
> > have multiple boards in the conf/machine directory
> > 
> > I currently testing a change to at91bootstrap, where a defconfig
> > is not provided by openembedded.
> > Instead you provide a list of defconfig's in your machine description:
> > 
> > I.E: in conf/machien/at91sam9g45ek.conf you have:
> > 
> > AT91BOOTSTRAP_BOARD = "at91sam9g45df at91sam9g45ek at91sam9g45nf"
> > 
> > when at91bootstrap is built it will loop through all the boards.
> > and build three versions.
> > 
> > I think it would make sense to do the same for u-boot,
> > so that you can build u-boot for several configurations.
> 
> Not about u-boot, but slightly related:
> 
> I need something similar for uImages due to hardware limitations
> (daughtercards requiring conflicting pinmux) and I have created this for
> kernel builds:
> 
> http://dominion.thruhere.net/git/cgit.cgi/openembedded/tree/recipes/linux/multi-kernel.inc?h=ti/staging
> 
> It's working nicely for my usecase (validate hardware configs with
> multiple kernels, validate software with only one kernel).

That indeed looks useful.  Any chance it'll go in soon?  Or what's left
to cleanup before it can?  Aside from some shellfile for pstaging that
is.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: RFC; Building multiple u-boot images for a single board

[Denys Dmytriyenko]

On Fri, Feb 26, 2010 at 11:45:44AM -0700, Tom Rini wrote:
> On Fri, 2010-02-26 at 13:57 +0100, Koen Kooi wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 26-02-10 12:37, Ulf Samuelsson wrote:
> > > If you want to support multiple boot memories, you have to
> > > have multiple boards in the conf/machine directory
> > > 
> > > I currently testing a change to at91bootstrap, where a defconfig
> > > is not provided by openembedded.
> > > Instead you provide a list of defconfig's in your machine description:
> > > 
> > > I.E: in conf/machien/at91sam9g45ek.conf you have:
> > > 
> > > AT91BOOTSTRAP_BOARD = "at91sam9g45df at91sam9g45ek at91sam9g45nf"
> > > 
> > > when at91bootstrap is built it will loop through all the boards.
> > > and build three versions.
> > > 
> > > I think it would make sense to do the same for u-boot,
> > > so that you can build u-boot for several configurations.
> > 
> > Not about u-boot, but slightly related:
> > 
> > I need something similar for uImages due to hardware limitations
> > (daughtercards requiring conflicting pinmux) and I have created this for
> > kernel builds:
> > 
> > http://dominion.thruhere.net/git/cgit.cgi/openembedded/tree/recipes/linux/multi-kernel.inc?h=ti/staging
> > 
> > It's working nicely for my usecase (validate hardware configs with
> > multiple kernels, validate software with only one kernel).
> 
> That indeed looks useful.  Any chance it'll go in soon?  Or what's left
> to cleanup before it can?  Aside from some shellfile for pstaging that
> is.

It is also being used in Arago. Hope to see it merged to oe-dev soon! :)

I need to seriosly look into package_stagefile_shell, as it breaks my setup 
with DEPLOY_DIR outside of TMPDIR - there are some wrong assumptions in that 
function... :(

-- 
Denys

Re: RFC; Building multiple u-boot images for a single board

[Koen Kooi]

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

On 26-02-10 19:45, Tom Rini wrote:
> On Fri, 2010-02-26 at 13:57 +0100, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 26-02-10 12:37, Ulf Samuelsson wrote:
>>> If you want to support multiple boot memories, you have to
>>> have multiple boards in the conf/machine directory
>>>
>>> I currently testing a change to at91bootstrap, where a defconfig
>>> is not provided by openembedded.
>>> Instead you provide a list of defconfig's in your machine description:
>>>
>>> I.E: in conf/machien/at91sam9g45ek.conf you have:
>>>
>>> AT91BOOTSTRAP_BOARD = "at91sam9g45df at91sam9g45ek at91sam9g45nf"
>>>
>>> when at91bootstrap is built it will loop through all the boards.
>>> and build three versions.
>>>
>>> I think it would make sense to do the same for u-boot,
>>> so that you can build u-boot for several configurations.
>>
>> Not about u-boot, but slightly related:
>>
>> I need something similar for uImages due to hardware limitations
>> (daughtercards requiring conflicting pinmux) and I have created this for
>> kernel builds:
>>
>> http://dominion.thruhere.net/git/cgit.cgi/openembedded/tree/recipes/linux/multi-kernel.inc?h=ti/staging
>>
>> It's working nicely for my usecase (validate hardware configs with
>> multiple kernels, validate software with only one kernel).
> 
> That indeed looks useful.  Any chance it'll go in soon?  Or what's left
> to cleanup before it can?  Aside from some shellfile for pstaging that
> is.

The goal is "next wednesday" provided the tests on monday/tuesday pass,
but see Denys' respone about shellfile assumptions.

regards,

Koen


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

iD8DBQFLiCCNMkyGM64RGpERAsmhAJ9gxCksjNChcO0XetYCagaRKGZIUwCeK2m8
1ySucR0YlvS+CYMA++vIsdI=
=Ms5c
-----END PGP SIGNATURE-----

Re: RFC; Building multiple u-boot images for a single board

[Tom Rini]

On Fri, 2010-02-26 at 20:27 +0100, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 26-02-10 19:45, Tom Rini wrote:
> > On Fri, 2010-02-26 at 13:57 +0100, Koen Kooi wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 26-02-10 12:37, Ulf Samuelsson wrote:
> >>> If you want to support multiple boot memories, you have to
> >>> have multiple boards in the conf/machine directory
> >>>
> >>> I currently testing a change to at91bootstrap, where a defconfig
> >>> is not provided by openembedded.
> >>> Instead you provide a list of defconfig's in your machine description:
> >>>
> >>> I.E: in conf/machien/at91sam9g45ek.conf you have:
> >>>
> >>> AT91BOOTSTRAP_BOARD = "at91sam9g45df at91sam9g45ek at91sam9g45nf"
> >>>
> >>> when at91bootstrap is built it will loop through all the boards.
> >>> and build three versions.
> >>>
> >>> I think it would make sense to do the same for u-boot,
> >>> so that you can build u-boot for several configurations.
> >>
> >> Not about u-boot, but slightly related:
> >>
> >> I need something similar for uImages due to hardware limitations
> >> (daughtercards requiring conflicting pinmux) and I have created this for
> >> kernel builds:
> >>
> >> http://dominion.thruhere.net/git/cgit.cgi/openembedded/tree/recipes/linux/multi-kernel.inc?h=ti/staging
> >>
> >> It's working nicely for my usecase (validate hardware configs with
> >> multiple kernels, validate software with only one kernel).
> > 
> > That indeed looks useful.  Any chance it'll go in soon?  Or what's left
> > to cleanup before it can?  Aside from some shellfile for pstaging that
> > is.
> 
> The goal is "next wednesday" provided the tests on monday/tuesday pass,
> but see Denys' respone about shellfile assumptions.

Yeah, DEPLOY_DIR outside of TMPDIR needs some special thought.
DEPLOY_DIR_PSTAGING outside of TMPDIR is fine, happily.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation