From: Mario Domenech Goulart <mario@ossystems.com.br>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: "meta-freescale@yoctoproject.org" <meta-freescale@yoctoproject.org>
Subject: Re: IMAGE_BOOTLOADER vs. PREFERRED_PROVIDER_virtual/bootloader
Date: Tue, 22 Apr 2014 19:59:27 +0000 [thread overview]
Message-ID: <87fvl5kue8.fsf@parenteses.org> (raw)
In-Reply-To: <CAP9ODKo6vqWsxdLT1crYyjAhJfQThVpNmJBEBfmdYt_8g+p3fQ@mail.gmail.com> (Otavio Salvador's message of "Sun, 20 Apr 2014 16:44:15 -0300")
Hi,
On Sun, 20 Apr 2014 16:44:15 -0300 Otavio Salvador <otavio@ossystems.com.br> wrote:
> On Tue, Apr 15, 2014 at 3:23 PM, Mario Domenech Goulart
> <mario@ossystems.com.br> wrote:
>> I'm making a script to extract data out of bitbake's cache metadata and
>> stumbled upon IMAGE_BOOTLOADER.
>>
>> Is there any special reason to use IMAGE_BOOTLOADER instead of
>> PREFERRED_PROVIDER_virtual/bootloader?
>
> Very good point. I think when I did the class, for SD card
> generation, we hadn't this around (or I missed it).
>
> Looking at it, this should indeed be dropped but it is going to need
> some work as we need to provide a u-boot-dummy for the cases when we
> don't need a bootloader in the SD card image, as it is the case for
> Nitrogen boards for example.
>
> We can discuss how to address it for 1.7 later.
Ok.
There are also boards which set PREFERRED_PROVIDER_u-boot. As far as I
understand, PREFERRED_PROVIDER_virtual/bootloader would do the trick for
those cases too.
Best wishes.
Mario
--
http://www.ossystems.com.br
next prev parent reply other threads:[~2014-04-22 19:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 18:23 IMAGE_BOOTLOADER vs. PREFERRED_PROVIDER_virtual/bootloader Mario Domenech Goulart
2014-04-16 17:56 ` Daiane Angolini
2014-04-20 19:44 ` Otavio Salvador
2014-04-22 19:59 ` Mario Domenech Goulart [this message]
2014-04-22 20:09 ` Otavio Salvador
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=87fvl5kue8.fsf@parenteses.org \
--to=mario@ossystems.com.br \
--cc=meta-freescale@yoctoproject.org \
--cc=otavio@ossystems.com.br \
/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.