On 3/8/19 3:27 PM, Markus Armbruster wrote: > Philippe Mathieu-Daudé <phi...@redhat.com> 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é <phi...@redhat.com>
