From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vvzgl-0006RB-JM for qemu-devel@nongnu.org; Wed, 25 Dec 2013 20:24:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vvzge-0002N9-18 for qemu-devel@nongnu.org; Wed, 25 Dec 2013 20:24:39 -0500 Received: from [222.73.24.84] (port=7606 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vvzgd-0002Lo-LQ for qemu-devel@nongnu.org; Wed, 25 Dec 2013 20:24:31 -0500 Message-ID: <52BB84E1.1000902@cn.fujitsu.com> Date: Thu, 26 Dec 2013 09:22:41 +0800 From: Li Guang MIME-Version: 1.0 References: <1387960503-11838-1-git-send-email-lig.fnst@cn.fujitsu.com> <52BB74E5.8010602@cn.fujitsu.com> <52BB7AC0.5080909@cn.fujitsu.com> In-Reply-To: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Subject: Re: [Qemu-devel] [PATCH] allwinner-a10: add config script support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , QEMU Developers Peter Crosthwaite wrote: > On Thu, Dec 26, 2013 at 10:47 AM, Peter Maydell > wrote: > >> On 26 December 2013 00:39, Li Guang wrote: >> >>> Peter Maydell wrote: >>> >>>> On 26 December 2013 00:14, Li Guang wrote: >>>> >>>>> it's the approach sunxi-linux kernel config hardware, >>>>> the binary is actually a transformed text script, >>>>> and context of script is like: >>>>> >>>>> [card0_boot_para] >>>>> card_ctrl = 0 >>>>> card_high_speed = 1 >>>>> card_line = 4 >>>>> sdc_d1 = port:PF00<2><1> >>>>> sdc_d0 = port:PF01<2><1> >>>>> sdc_clk = port:PF02<2><1> >>>>> sdc_cmd = port:PF03<2><1> >>>>> sdc_d3 = port:PF04<2><1> >>>>> sdc_d2 = port:PF05<2><1> >>>>> >>>>> >>>> So what sets this up on real hardware? Is this part of >>>> a firmware blob? Is it in ROM or flash? >>>> >> >>> it's generally in /boot, bootloader will load it >>> into ram address 0x43000000, kernel will find it >>> at this fixed address, and parse it, learn the hardware >>> related configuration, mostly property of devices, and >>> GPIOes used. >>> >> Weird. Why isn't this just using devicetree? >> I'd rather not have to add support to QEMU's bootloader >> for weird things like this if I can avoid it... >> >> > Can you just provide a generic solution to the "blob some random data > into RAM" problem (If one doesn't exist already)? I toyed with the > Idea of a bootloader as a device a while back, which would allow you > to implement multiple bootloaders unaware of each other, with > arbitrary command line args: > > http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00858.html > > That patch demonstrates creating a bootloader as a QOM object. Its > ancient, so the style is way out of date, but the idea is still there. > > So you could use the ARM linux loader as is, then blob your firmware > in on the side something like: > > qemu-system-arm -device blob-loader,addr=0x43000000,file=/path/to/blob > -kernel ... > > that's a good option. > I think your binary file here can then just be treated as any other > binary boot product and kept outside of QEMU. > Yes, I would like to keep it outside of QEMU, what's about directly add an abstract device called "blob"? and the device has it's properties like path, address...