[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about (and problem with) pflash data access
From: |
Guenter Roeck |
Subject: |
Re: Question about (and problem with) pflash data access |
Date: |
Wed, 12 Feb 2020 15:09:18 -0800 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
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
- Re: Question about (and problem with) pflash data access, Philippe Mathieu-Daudé, 2020/02/12
- Re: Question about (and problem with) pflash data access,
Guenter Roeck <=
- Re: Question about (and problem with) pflash data access, Philippe Mathieu-Daudé, 2020/02/12
- Re: Question about (and problem with) pflash data access, Alexey Kardashevskiy, 2020/02/13
- Re: Question about (and problem with) pflash data access, Paolo Bonzini, 2020/02/13
- Re: Question about (and problem with) pflash data access, Guenter Roeck, 2020/02/13
- Re: Question about (and problem with) pflash data access, Peter Maydell, 2020/02/13
- Re: Question about (and problem with) pflash data access, Philippe Mathieu-Daudé, 2020/02/13
- Re: Question about (and problem with) pflash data access, Guenter Roeck, 2020/02/13