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

[Philippe Mathieu-Daudé]

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.