qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 06/14] sam460ex: Don't size flash


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 06/14] sam460ex: Don't size flash memory to match backing image
Date: Fri, 8 Mar 2019 15:34:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/8/19 3:27 PM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé <address@hidden> writes:
> 
>> On 3/7/19 2:03 PM, Markus Armbruster wrote:
>>> Machine "sam460ex" maps its flash memory at address 0xFFF00000.  When
>>> no image is supplied, its size is 1MiB (0x100000), and 512KiB of ROM
>>> get mapped on top of its second half.  Else, it's the size of the
>>> image rounded up to the next multiple of 64KiB.
>>>
>>> The rounding is actually useless: pflash_cfi01_realize() fails with
>>> "failed to read the initial flash content" unless it's a no-op.
>>>
>>> I have no idea what happens when the pflash's size exceeds 1MiB.
>>> Useful outcomes seem unlikely.
>>
>> You now have! [*] "Hardwiring address lines leaves part of the hardware
>> unaddressable." Anything bigger than 1MiB mapped at 0xFFF00000 only has
>> the first MiB addressable. IOW anything above 1MiB is unaddressable, but
>> you still can map a such bigger flash.
>>
>> [*] https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg01380.html
> 
> Well, that's what would happen with real hardware.  But this device
> model doesn't actually model address lines.  It simply asks
> pflash_cfi01_register() to map blk_getlength() bytes at the base
> address.  If you ask it to map gigabytes, it'll happily do so (as long
> as malloc plays along).

Ah, I misunderstood your commit message then. About the QEMU crippled
model, your commit description makes sense. Thus:

Reviewed-by: Philippe Mathieu-Daudé <address@hidden>



reply via email to

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