qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 6/7] xilinx_zynq: add pl353


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v1 6/7] xilinx_zynq: add pl353
Date: Sat, 20 Oct 2012 09:00:59 +1000

On Fri, Oct 19, 2012 at 8:32 PM, Peter Maydell <address@hidden> wrote:
> On 19 October 2012 07:40, Peter Crosthwaite
> <address@hidden> wrote:
>> Add the pl353 memory controller with both NAND and parallel flashes
>> attached.
>>
>> Signed-off-by: Peter Crosthwaite <address@hidden>
>> ---
>>
>>  hw/xilinx_zynq.c |   49 +++++++++++++++++++++++++++++++++++++++++--------
>>  1 files changed, 41 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
>> index fd46ba2..7f6faf0 100644
>> --- a/hw/xilinx_zynq.c
>> +++ b/hw/xilinx_zynq.c
>> @@ -120,14 +120,47 @@ static void zynq_init(ram_addr_t ram_size, const char 
>> *boot_device,
>>      vmstate_register_ram_global(ocm_ram);
>>      memory_region_add_subregion(address_space_mem, 0xFFFC0000, ocm_ram);
>>
>> -    DriveInfo *dinfo = drive_get(IF_PFLASH, 0, 0);
>> -
>> -    /* AMD */
>> -    pflash_cfi02_register(0xe2000000, NULL, "zynq.pflash", FLASH_SIZE,
>> -                          dinfo ? dinfo->bdrv : NULL, FLASH_SECTOR_SIZE,
>> -                          FLASH_SIZE/FLASH_SECTOR_SIZE, 1,
>> -                          1, 0x0066, 0x0022, 0x0000, 0x0000, 0x0555, 0x2aa,
>> -                              0);
>> +    /* pl353 */
>> +    dev = qdev_create(NULL, "arm.pl35x");
>> +    /* FIXME: handle this somewhere central */
>> +    object_property_add_child(container_get(qdev_get_machine(), 
>> "/unattached"),
>> +                              "pl353", OBJECT(dev), NULL);
>
> So, er, what's this for? Whatever it is, as you say it needs to be
> done properly, not randomly in the board model...
>

This is the well known link with no canonical path issue, that has
already been discussed on list a few times now. Im under the imression
that sone of the Qdev/QOM people are already on the case here. Andreas
in all the qdev QOM re-factorings going on is there a clear resolution
to this planned?

Regards,
Peter


> -- PMM
>



reply via email to

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