From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: RFC; Building multiple u-boot images for a single board
Date: Fri, 26 Feb 2010 20:27:09 +0100 [thread overview]
Message-ID: <hm97ae$bvo$2@dough.gmane.org> (raw)
In-Reply-To: <1267209944.18176.575.camel@trini-m4400>
-----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-----
next prev parent reply other threads:[~2010-02-26 19:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-26 11:37 RFC; Building multiple u-boot images for a single board Ulf Samuelsson
2010-02-26 12:16 ` Marcin Juszkiewicz
2010-02-26 12:20 ` Frans Meulenbroeks
2010-02-26 12:57 ` Koen Kooi
2010-02-26 18:45 ` Tom Rini
2010-02-26 18:53 ` Denys Dmytriyenko
2010-02-26 19:27 ` Koen Kooi [this message]
2010-02-26 19:45 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='hm97ae$bvo$2@dough.gmane.org' \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.