Re: [Qemu-devel] [PATCH] allwinner-a10: add config script support

[Li Guang <lig.fnst@cn.fujitsu.com>]

Peter Crosthwaite wrote:
> On Thu, Dec 26, 2013 at 10:47 AM, Peter Maydell
> <peter.maydell@linaro.org>  wrote:
>    
>> On 26 December 2013 00:39, Li Guang<lig.fnst@cn.fujitsu.com>  wrote:
>>      
>>> Peter Maydell wrote:
>>>        
>>>> On 26 December 2013 00:14, Li Guang<lig.fnst@cn.fujitsu.com>   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><default><default>
>>>>> sdc_d0 = port:PF01<2><1><default><default>
>>>>> sdc_clk = port:PF02<2><1><default><default>
>>>>> sdc_cmd = port:PF03<2><1><default><default>
>>>>> sdc_d3 = port:PF04<2><1><default><default>
>>>>> sdc_d2 = port:PF05<2><1><default><default>
>>>>>
>>>>>            
>>>> 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...