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

[Guenter Roeck]

On Thu, Feb 13, 2020 at 04:24:24PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/13/20 3:39 PM, Peter Maydell wrote:
> > On Thu, 13 Feb 2020 at 14:26, Guenter Roeck <address@hidden> wrote:
> > > 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 ?
> 
> If you can share built kernel/dtb/rootfs for this machine I can have a look
> at it.
> 
> > > Clearly I am missing something about inner workings of qemu.
> 
> You can see all the pflash events using '-trace pflash*'.
> 
Yes, I got that much ;-).

> > 
> > Probably the device is in 'romd' mode. A QEMU MemoryRegion
> > can be:
> >   * RAM (includes ROM for these purposes) -- backed by host
> >     memory, reads and writes (if permitted) go straight to
> >     the host memory via fastpath accesses
> 
> No tracing here.
> 
> >   * MMIO -- backed by a read and write accessor function,
> >     all accesses go to these functions
> >   * "ROM device" -- a mix of the above where there is a
> >     backing bit of host memory but also accessor functions.
> >     When the device is in "romd" mode, reads go direct to
> >     host memory, and writes still go to the accessor function.
> >     When the device is not in "romd" mode, reads also go
> >     to the accessor function.
> > 
> > We use this in the pflash devices to make the common case
> > ("just read the flash") fast. When the guest makes a write
> > to flash that puts it into programming mode, we call
> > memory_region_rom_device_set_romd(..., false) so we can
> > intercept reads and make them do the right thing for
> > programming mode.
> > 

Disabling the calls to memory_region_rom_device_set_romd(..., true)
got me the trace output I was looking for. Turns out that reads
which supposedly are from the beginning of the flash start at offset
0x180000 instead of 0. This explains the "corruption", since that is
exactly the data in my test file at that offset. Adding debug output
to the Linux kernel confirms that this offset originates from the Linux
kernel.

Taking a closer look into the kernel source shows that the flash partitions
for SX1 indeed start at offset 0x180000 in the flash, not at 0. Bummer.

Sorry for all the noise. I should have paid closer attention to the
kernel source. Oh well, at least I learned a lot about qemu.

Thanks,
Guenter