Peter Maydell <peter.mayd...@linaro.org> writes: > On Tue, 19 Feb 2019 at 16:07, Philippe Mathieu-Daudé <phi...@redhat.com> > wrote: >> >> On 2/18/19 1:56 PM, Markus Armbruster wrote: >> Good news: when you read (0x0000, 0x0000, 0x0000, 0x0000) pflash IDs, >> that means the code uses the "Virt PFlash".
Which code? >> IOW this is not a physical >> model, since the guest obviously doesn't care about checking the flash >> model. >> The "VirtPFlash" only has 64KiB sectors. >> >> I suggest we add a pflash_cfi02_create_virt(reduced args) helper to make >> this obvious: >> >> pflash_cfi02_create_virt(paddr, name, size_bytes, mapping?). > > What would this be, and when would you use it without a > /* FIXME this is not what the real hardware does */ ? For a purely virtual machine such as ARM virt, perhaps? Funnily, we use IDs 0x89, 0x18, 0x00, 0x00 there. Which first appeared in the microblaze petalogix-s3adsp1800 machine (commit 2548de3a343, Jan 2010), then got copied to ppc virtex-ml507 (commit 2c50e26efdb, Sep 2010), microblaze petalogix-ml605 (commit 00914b7d970, Mar 2011), ppc sam460ex (commit 4b387f9ee16, Feb 2018), arm vexpress-* in different form (commit b8433303fbc and 0163a2dc80, Dec 2013), and finally arm virt (commit acf82361c61, Sep 2014). Which ones match physical hardware is anybody's guess. > The real problem with most of these pflash creation calls > is that they're using bogus data for the flash device > (wrong IDs, wrong width, using the legacy weird implementation, > etc etc) Even better news: when we replace the helper function by longhand, many of the (bogus) qdev_prop_set_FOO() become no-ops (because the default is identically bogus), so we can sweep more of this under the carpet! > because nobody cares much about the boards or has > real hardware to see what the hardware really is doing. Remind me, why are we shipping stuff nobody cares much about?
