All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Guang <lig.fnst@cn.fujitsu.com>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Edgar Iglesias <edgar.iglesias@xilinx.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [PATCH] hw/misc/blob-loader: add a generic blob loader
Date: Wed, 08 Jan 2014 15:38:46 +0800	[thread overview]
Message-ID: <52CD0086.7020304@cn.fujitsu.com> (raw)
In-Reply-To: <CAEgOgz4qxZc=42vP1xywQxby-zHchEtjgKfmGbd+FX0_hqcgFg@mail.gmail.com>

Peter Crosthwaite wrote:
> On Mon, Jan 6, 2014 at 10:13 PM, Paolo Bonzini<pbonzini@redhat.com>  wrote:
>    
>> Il 06/01/2014 08:56, Peter Crosthwaite ha scritto:
>>      
>>>> What are the guidelines for when to use one or the other?
>>>>          
>>> "-machine firmware=" if you want to load a firmware blob in a board
>>> specific way. This if you want to place a blob in memory at an
>>> arbitrary location on reset.
>>>        
>> "-machine firmware=" is also a pretty bad design because it's not
>> extensible and doesn't apply to most boards.  We really should get
>> per-board -machine options, so that you can have a less generic name
>> than "firmware".
>>
>>      
> Then we have even more divergence in boot flow between boards. It's
> already a bit of a Zoo out there when it comes to bootloaders.
>
> We expressed dislike for the Allwinner/FEX board specific bootloader
> due it its mainline Linux non-acceptance. This generic solution
> facilitates this case among many others and the reason its able to
> achieve that goal is it has no reliance on software policy. OTOH if we
> need to do everything board specific then we need to start deciding
> software policy for each and every board. For allwinner, FEX was a
> nack, which pretty much hangs out users of that linux kernel to dry.
>
> Looking at QEMU ARM, we are in a position now where you can only boot
> systems two ways:
>
> 1: Exactly as real HW (have to use your boards bootrom, BIOS, storage
> media etc).
> 2. ARM Linux exactly to the letter of the mainline boot process.
>
> With generic tools like this device, you at least let the users do a
> few flexible things for boots that do not fit these two limited use
> cases. And the device is completely unobtrusive on existing code. If
> developers in the future come along with their weird and wonderful
> board specific bootflows that we don't like we can now tell them to
> use the generic blob loader for their bits and pieces and everybody
> wins.
>
> If anything, the boards implementing -machine firware="" should
> implement it by layer ontop of this device.
>
>
>    
agree,

further more,  "-machine firmware=" is really not generic,
we may have to deprecate it.
because if use it, every boards should do specific things for it.

Thanks!

>    
>> Paolo
>>
>>      
>
>    

      reply	other threads:[~2014-01-08  7:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-02  5:35 [Qemu-devel] [PATCH] hw/misc/blob-loader: add a generic blob loader Li Guang
2014-01-02  5:50 ` Peter Crosthwaite
2014-01-02  6:51   ` Li Guang
2014-01-02  8:21   ` Paolo Bonzini
2014-01-02 10:51     ` Peter Crosthwaite
2014-01-02 12:16       ` Paolo Bonzini
2014-01-06  0:52         ` Li Guang
2014-01-06  3:55           ` Li Guang
2014-01-06  4:00             ` Peter Crosthwaite
2014-01-06  4:22               ` Li Guang
2014-01-06  4:32                 ` Peter Crosthwaite
2014-01-06  4:52                   ` Li Guang
2014-01-06  5:24                     ` Li Guang
2014-01-06  5:28                       ` Peter Crosthwaite
2014-01-06  5:36                         ` Li Guang
2014-01-06 12:11                           ` Paolo Bonzini
2014-01-06  7:41   ` Peter Maydell
2014-01-06  7:56     ` Peter Crosthwaite
2014-01-06  8:16       ` Peter Maydell
2014-01-06 12:13       ` Paolo Bonzini
2014-01-06 13:06         ` Peter Crosthwaite
2014-01-08  7:38           ` Li Guang [this message]

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=52CD0086.7020304@cn.fujitsu.com \
    --to=lig.fnst@cn.fujitsu.com \
    --cc=edgar.iglesias@xilinx.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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.