Re: Remapping Flash into VM address space

[Peter Maydell]

On Sat, 21 Sep 2019 at 22:23, Branden Sherrell <address@hidden> wrote:
>
> Hi all,
>
> I've been prototyping EL3 firmware using the virt device lately. After 
> successfully initializing the page tables I was met with a particularly 
> strange issue: I am unable to map the Flash memory range into the VM address 
> space. At first I was identity mapping everything. I considered it might be a 
> strange issue related to using address "zero", so I tried moving it above 
> where I mapped RAM. However I'm always met with the same result: Data Abort.
>
> All other translations work, including the UART and RAM. I've tested my 
> translation table configuration in many ways, including several VA mappings 
> to the same PA and non-identity mappings. Everything works except those 
> destined to hit the emulated Flash hardware. Is this a known issue? Is Flash 
> handled differently than other emulated hardware in QEMU?

Not really, at least not for these purposes. The main interesting
thing about the flash device at address 0 is that it is one of
the few devices in the 'virt' machine which are mapped only
into the Secure address space and not the Non-secure
address space. So if you're not doing the access from
the Secure world or if your page tables are not correctly
setting the NS and NSTable bits in the descriptors then
the CPU will perform the access to the NS address space
where there is no device (and you get a data abort).

(The other devices which are secure-address-space only
are the secure-only RAM at 0x0e000000 and the secure-only
UART at 0x09040000. Everything else is visible to both
S and NS, including the 2nd bank of flash at 0x08000000.)

> I tried enabling MMU debugging with `-d mmu` but, after looking through the 
> code, it appears to not be implemented for this target.

No, it isn't. You could run QEMU under gdb and arrange to
single-step through the relevant calls to get_phys_addr().

thanks
-- PMM