qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 1/1] xlnx-zynqmp: Add support for high DDR me


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v4 1/1] xlnx-zynqmp: Add support for high DDR memory regions
Date: Tue, 12 Jan 2016 14:00:53 -0800

On Tue, Jan 12, 2016 at 1:59 PM, Alistair Francis
<address@hidden> wrote:
> On Tue, Jan 12, 2016 at 1:01 AM, Peter Maydell <address@hidden> wrote:
>> On 12 January 2016 at 00:24, Alistair Francis
>> <address@hidden> wrote:
>>> On Mon, Jan 11, 2016 at 8:04 AM, Peter Maydell <address@hidden> wrote:
>>>> There are a couple of problems you're running into:
>>>>
>>>> (1) machine->ram_size is a ram_addr_t so might be 32 bit; you
>>>> can do what virt.c does to avoid the warning and use a local
>>>> uin64_t variable for the comparison
>>>
>>> Ok, I now create a uint64_t variable to store the value.
>>>
>>>>
>>>> (2) complaint about reassigning back to ram_size. this is spurious
>>>> but you can avoid it by making this board behave the same way as
>>>> virt.c, vexpress.c etc do if presented with an unsupported
>>>> ram_size -- you should fail, rather than truncating and continuing.
>>>
>>> If I'm using a 64-bit variable to store the value won't this no longer
>>> be a problem?
>>
>> I think you should do the same thing the other boards do anyway.
>
> Ok, I have changed it to exit instead of resize.
>
>>
>>>> (3) %llx is not the correct format string for a ram_addr_t:
>>>> use RAM_ADDR_FMT. (This isn't making the compiler complain,
>>>> but I noticed it looking at the code.)
>>>
>>> Again, isn't this fixed by changing to a variable?
>>
>> %llx isn't right for uint64_t either :-)
>
> I still have a %llx for the macro as it isn't a ram_addr_t.
>

Should be PRIx64 though.

Regards,
Peter

> Re sending now.
>
> Thanks,
>
> Alistair
>
>>
>> thanks
>> -- PMM
>>



reply via email to

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