qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH] allwinner-a10: add config script support
Date: Thu, 26 Dec 2013 11:09:17 +1000

On Thu, Dec 26, 2013 at 10:47 AM, Peter Maydell
<address@hidden> wrote:
> On 26 December 2013 00:39, Li Guang <address@hidden> wrote:
>> Peter Maydell wrote:
>>>
>>> On 26 December 2013 00:14, Li Guang<address@hidden>  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 ...

I think your binary file here can then just be treated as any other
binary boot product and kept outside of QEMU.

Regards,
Peter

> Who provides this file? The board manufacturer?
> Where's the source? How do you create the blob?
> What license are the sources under?
>
> thanks
> -- PMM
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]