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

Koen Kooi k.kooi at student.utwente.nl
Fri Feb 26 19:27:09 UTC 2010


-----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-----





More information about the Openembedded-devel mailing list