Re: Question about (and problem with) pflash data access

[Guenter Roeck]

On Wed, Feb 12, 2020 at 10:39:30PM +0100, Philippe Mathieu-Daudé wrote:
> Cc'ing Jean-Christophe and Peter.
> 
> On 2/12/20 7:46 PM, Guenter Roeck wrote:
> > Hi,
> > 
> > I have been playing with pflash recently. For the most part it works,
> > but I do have an odd problem when trying to instantiate pflash on sx1.
> > 
> > My data file looks as follows.
> > 
> > 0000000 0001 0000 aaaa aaaa 5555 5555 0000 0000
> > 0000020 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > 0002000 0002 0000 aaaa aaaa 5555 5555 0000 0000
> > 0002020 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > 0004000 0003 0000 aaaa aaaa 5555 5555 0000 0000
> > 0004020 0000 0000 0000 0000 0000 0000 0000 0000
> > ...
> > 
> > In the sx1 machine, this becomes:
> > 
> > 0000000 6001 0000 aaaa aaaa 5555 5555 0000 0000
> > 0000020 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > 0002000 6002 0000 aaaa aaaa 5555 5555 0000 0000
> > 0002020 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > 0004000 6003 0000 aaaa aaaa 5555 5555 0000 0000
> > 0004020 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > ...
> > 
> > pflash is instantiated with "-drive 
> > file=flash.32M.test,format=raw,if=pflash".
> > 
> > I don't have much success with pflash tracing - data accesses don't
> > show up there.
> > 
> > I did find a number of problems with the sx1 emulation, but I have no clue
> > what is going on with pflash. As far as I can see pflash works fine on
> > other machines. Can someone give me a hint what to look out for ?
> 
> This is specific to the SX1, introduced in commit 997641a84ff:
> 
>  64 static uint64_t static_read(void *opaque, hwaddr offset,
>  65                             unsigned size)
>  66 {
>  67     uint32_t *val = (uint32_t *) opaque;
>  68     uint32_t mask = (4 / size) - 1;
>  69
>  70     return *val >> ((offset & mask) << 3);
>  71 }
> 
> Only guessing, this looks like some hw parity, and I imagine you need to
> write the parity bits in your flash.32M file before starting QEMU, then it
> would appear "normal" within the guest.
> 
I thought this might be related, but that is not the case. I added log
messages, and even ran the code in gdb. static_read() and static_write()
are not executed.

Also,

    memory_region_init_io(&cs[0], NULL, &static_ops, &cs0val,
                          "sx1.cs0", OMAP_CS0_SIZE - flash_size);
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^
    memory_region_add_subregion(address_space,
                                OMAP_CS0_BASE + flash_size, &cs[0]);
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^

suggests that the code is only executed for memory accesses _after_
the actual flash. The memory tree is:

memory-region: system
  0000000000000000-ffffffffffffffff (prio 0, i/o): system
    0000000000000000-0000000001ffffff (prio 0, romd): omap_sx1.flash0-1
    0000000000000000-0000000001ffffff (prio 0, rom): omap_sx1.flash0-0
    0000000002000000-0000000003ffffff (prio 0, i/o): sx1.cs0

I thought that the dual memory assignment (omap_sx1.flash0-1 and
omap_sx1.flash0-0) might play a role, but removing that didn't make
a difference either (not that I have any idea what it is supposed
to be used for).

Thanks,
Guenter