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

[Guenter Roeck]

On 2/13/20 1:51 AM, Paolo Bonzini wrote:
> On 13/02/20 08:40, Alexey Kardashevskiy wrote:
> > > > 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
> > > Eh two memory regions with same size and same priority... Is this legal?
> >
> > I'd say yes if used with memory_region_set_enabled() to make sure only
> > one is enabled. Having both enabled is weird and we should print a
> > warning.
>
> Yeah, it's undefined which one becomes visible.

I have a patch fixing that, resulting in

(qemu) info mtree -f
FlatView #0
 AS "I/O", root: io
 Root memory region: io
  0000000000000000-000000000000ffff (prio 0, i/o): io

FlatView #1
 AS "memory", root: system
 AS "cpu-memory-0", root: system
 Root memory region: system
  0000000000000000-0000000001ffffff (prio 0, romd): omap_sx1.flash0
  0000000002000000-0000000003ffffff (prio 0, i/o): sx1.cs0
  0000000004000000-0000000007ffffff (prio 0, i/o): sx1.cs1
  0000000008000000-000000000bffffff (prio 0, i/o): sx1.cs2
  000000000c000000-000000000fffffff (prio 0, i/o): sx1.cs3
  ...

but unfortunately that doesn't fix my problem. The data in the
omap_sx1.flash0 region is as wrong as before.

What really puzzles me is that there is no trace output for
flash data accesses (trace_pflash_data_read and trace_pflash_data_write),
meaning the actual flash data access must be handled elsewhere.
Can someone give me a hint where that might be ?
Clearly I am missing something about inner workings of qemu.

Thanks,
Guenter