Re: Remapping Flash into VM address space

[Branden Sherrell]

Hi Peter,

Thanks for the quick response. That was absolutely the problem. I just unset NSTable and NS in the block entries and it worked as expected. I did noticed this in the code but I was unsure of the implications. I am not a QEMU developer, so sometimes the answer can be right in front of you face but you do not quite understand it. I should have considered the comment more closely.

https://github.com/qemu/qemu/blob/master/hw/arm/virt.c#L937-L956

Thanks again.

Branden

On Sun, Sep 22, 2019 at 12:38 PM Peter Maydell <address@hidden> wrote:

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