On 13/02/2020 10:50, Philippe Mathieu-Daudé wrote:
> Cc'ing Paolo and Alexey.
>
> On 2/13/20 12:09 AM, Guenter Roeck wrote:
>> 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
>
> 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. Thanks,
>
> (qemu) info mtree -f -d
> FlatView #0
> AS "memory", root: system
> AS "cpu-memory-0", root: system
> Root memory region: system
> 0000000000000000-0000000001ffffff (prio 0, romd): omap_sx1.flash0-1
> 0000000002000000-0000000003ffffff (prio 0, i/o): sx1.cs0
> 0000000004000000-0000000007ffffff (prio 0, i/o): sx1.cs1
> 0000000008000000-000000000bffffff (prio 0, i/o): sx1.cs3
> 0000000010000000-0000000011ffffff (prio 0, ram): omap1.dram
> 0000000020000000-000000002002ffff (prio 0, ram): omap1.sram
> ...
> Dispatch
> Physical sections
> #0 @0000000000000000..ffffffffffffffff (noname) [unassigned]
> #1 @0000000000000000..0000000001ffffff omap_sx1.flash0-1 [not dirty]
> #2 @0000000002000000..0000000003ffffff sx1.cs0 [ROM]
> #3 @0000000004000000..0000000007ffffff sx1.cs1 [watch]
> #4 @0000000008000000..000000000bffffff sx1.cs3
> #5 @0000000010000000..0000000011ffffff omap1.dram
> #6 @0000000020000000..000000002002ffff omap1.sram
> ...
> Nodes (9 bits per level, 6 levels) ptr=[3] skip=4
> [0]
> 0 skip=3 ptr=[3]
> 1..511 skip=1 ptr=NIL
> [1]
> 0 skip=2 ptr=[3]
> 1..511 skip=1 ptr=NIL
> [2]
> 0 skip=1 ptr=[3]
> 1..511 skip=1 ptr=NIL
> [3]
> 0 skip=1 ptr=[4]
> 1 skip=1 ptr=[5]
> 2 skip=2 ptr=[7]
> 3..13 skip=1 ptr=NIL
> 14 skip=2 ptr=[9]
> 15 skip=2 ptr=[11]
> 16..511 skip=1 ptr=NIL
> [4]
> 0..63 skip=0 ptr=#1
> 64..127 skip=0 ptr=#2
> 128..255 skip=0 ptr=#3
> 256..383 skip=0 ptr=#4
> 384..511 skip=1 ptr=NIL
>
> So the romd wins.
>
>> 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
>>
>
--
Alexey