qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] arm: add fw_cfg to "virt" board


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v2] arm: add fw_cfg to "virt" board
Date: Fri, 05 Dec 2014 19:53:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

On 12/05/14 19:42, Peter Maydell wrote:
> On 30 November 2014 at 16:59, Laszlo Ersek <address@hidden> wrote:
>> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
>> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
>> board.
>>
>> The mmio register block of fw_cfg is advertized in the device tree. As
>> base address we pick 0x09020000, which conforms to the comment preceding
>> "a15memmap": it falls in the miscellaneous device I/O range 128MB..256MB,
>> and it is aligned at 64KB. The DTB properties follow the documentation in
>> the Linux source file "Documentation/devicetree/bindings/arm/fw-cfg.txt".
>>
>> fw_cfg automatically exports a number of files to the guest; for example,
>> "bootorder" (see fw_cfg_machine_reset()).
>>
>> Signed-off-by: Laszlo Ersek <address@hidden>
>> ---
>>
>> Notes:
>>     v2:
>>     - use a single mmio region of size 0x1000
>>     - set "compatible" property to "qemu,fw-cfg-mmio"
>>
>>  hw/arm/virt.c | 21 +++++++++++++++++++++
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 314e55b..af794ea 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -68,6 +68,7 @@ enum {
>>      VIRT_UART,
>>      VIRT_MMIO,
>>      VIRT_RTC,
>> +    VIRT_FW_CFG,
>>  };
>>
>>  typedef struct MemMapEntry {
>> @@ -107,6 +108,7 @@ static const MemMapEntry a15memmap[] = {
>>      [VIRT_GIC_CPU] =    { 0x08010000, 0x00010000 },
>>      [VIRT_UART] =       { 0x09000000, 0x00001000 },
>>      [VIRT_RTC] =        { 0x09010000, 0x00001000 },
>> +    [VIRT_FW_CFG] =     { 0x09020000, 0x00001000 },
> 
> Where does this 0x1000 size come from? It's not the size
> of the memory region the fw_cfg device exports, and it
> means we'll end up telling the f/w in the dtb that the
> accessible region is bigger than it really is.

This has been specifically requested in

http://thread.gmane.org/gmane.linux.drivers.devicetree/101173/focus=101176

See also the list of changes in

http://thread.gmane.org/gmane.linux.drivers.devicetree/101276/focus=101277

> Otherwise this patch looks good to me.
> 
> -- PMM
> 

Thanks
Laszlo



reply via email to

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