From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0nk7-0007YA-Id for qemu-devel@nongnu.org; Wed, 08 Jan 2014 02:40:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0nk1-0007Wc-K3 for qemu-devel@nongnu.org; Wed, 08 Jan 2014 02:39:59 -0500 Received: from [222.73.24.84] (port=8595 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0nk1-0007WU-8T for qemu-devel@nongnu.org; Wed, 08 Jan 2014 02:39:53 -0500 Message-ID: <52CD0086.7020304@cn.fujitsu.com> Date: Wed, 08 Jan 2014 15:38:46 +0800 From: Li Guang MIME-Version: 1.0 References: <1388640940-12782-1-git-send-email-lig.fnst@cn.fujitsu.com> <52CA9DD0.7010401@redhat.com> In-Reply-To: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Subject: Re: [Qemu-devel] [PATCH] hw/misc/blob-loader: add a generic blob loader List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Edgar Iglesias , Paolo Bonzini , "qemu-devel@nongnu.org Developers" , Peter Maydell Peter Crosthwaite wrote: > On Mon, Jan 6, 2014 at 10:13 PM, Paolo Bonzini 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 >> >> > >