1

I've gotten virtual memory working on ARMv8 after crafting the page tables. Oddly, most of my translations are working (identity mapped) save for Flash which sits at physical address zero. I use a single function that edits the page tables, so the fact that some work and some do not is strange to me. Specifically I have only a few ranges mapped:

Flash       [0x00000000, len = 0x08000000]
UART        [0x09000000, len = 0x1000    ]
RAM         [0x40000000, len = 0x0fe00000]
Secure RAM  [0x4fe00000, len = 0x00200000]

And again, they all work except for Flash. My mapping function also works for non-identity maps. There is just something strange about that Flash range.

I have an exception handler in place that I'm using to dissect the issue. I found two interesting cases when catching Data Abort exceptions. I encountered two Data Abort sub-types depending on the type of memory being accessed:

    - [1] Flash address range (e.g. 0x00000000)
            - ESR.ISS = 0x10 (ISS.DFSC = 0x10)
                - Synchronous External abort, not on translation table walk 

    - [2] An expected unmapped address (e.g. 0x50000000)
            - ESR.ISS = 0x06 (ISS.DFSC = 0x06)
                - Synchronous External abort, on translation table walk, level 2

When attempting to handle the exception for accessing an address I do not expect to be in the table I get a [2] (fault at level 2 because some nearby addresses were mapped).

When I attempt to handle the exception for accessing Flash which I do expect to be in the table I get [1] (not in table walk).

So, I am confused on what these two cases represent. What is the difference between [1] and [2]? They seem to represent the same thing. Does [1] somehow represent the case that translation failed before it tried? There are defined level 0 faults I would expect to handle if that were the case. I was expecting the "Not in table" fault for the address I was not expecting to be in the table but instead received the other.

artless noise
  • 21,212
  • 6
  • 68
  • 105
sherrellbc
  • 4,650
  • 9
  • 48
  • 77
  • Off the top of my head, 'Synchronous External abort, no table' is saying the backing memory is not responding. Ie, bus error on other systems. Maybe your flash needs clocking, it is protected by some AXI mechanism, etc. Flash comes in many flavour, SPI, NAND, NOR, etc. Also it usually doesn't support **WRITE** even if it is memory addressable (except maybe SPI variants?). The ARM CPU expects a response to an (AXI?) bus request. If there is an 'error' response, then it is a `synchronous abort` (external means not in the CPU). Generally, synchronous means the device (flash) gave an error. – artless noise Sep 22 '19 at 14:01
  • @artlessnoise So it seems to be behaving like it found the PA translation after walking the table but ... the external device is not responding? In that case it may just be corrupted table entries that send the real read request to the wrong address (where nothing is listening). But identity mapping PA 0x0 is about as easy as it gets, most bits in the entries are just zero. – sherrellbc Sep 22 '19 at 15:28
  • @artlessnoise Turns out my specific issue was related to Flash being hardware mapped only in the Secure address space. So I had to ensure that my tables/blocks were not marked as Non-Secure accesses. – sherrellbc Sep 22 '19 at 17:26
  • 1
    That is exactly what 'Synchronous external abort' means. As you said, the PA is not responding and TZ is making restricted access look like the device is not there. It was the bus controller and not the flash itself that returned the error... or **it is protected by some AXI mechanism, etc** That was the `NS` bit of trustzone. – artless noise Sep 22 '19 at 20:32
  • @artlessnoise Thanks for the help. I've answered the question but will leave it open for others to chime in. – sherrellbc Sep 23 '19 at 15:26

1 Answers1

1

As it turned out, the issue I was seeing was due to Flash being mapped as a Secure-only device, so only secure accesses will make it through the MMU (i.e. NSTable=0 on table entries and NS=0 on the block entries).

After realizing this, and with help from @artlessnoise regarding "External Aborts" in the comments I've come to the following distinction between the two subtypes of Data Abort:

"Not on translation table walk"

Does not mean, as I was reading it, that "The exception occurred because the requested memory address was not found 'on the translation table walk'". But rather it means that the exception occurred while "not on the translation table walk" (i.e. before or after the operation). In this case the Flash PA was mapped in the tables but my accesses were Non-Secure, so the device was not responding (MMU was not routing them through to the device). This lack of response caused the external abort. As such, ARM may have more succinctly defined this exception as, for example:

"Not on translation table walk" -> "Not as a result of translation table walk"

The other subtype:

"On translation table walk, level 2"

Is what one should expect to receive during a page fault. In other words, an attempt was made to read memory that does not have a VA->PA mapping in the translation tables. the level observed reflects how far the MMU walks the tables before stopping.

Note that I removed the "Synchronous External abort" part of the definitions. Both are considered External aborts because both are raised as a result of operations outside of the CPU while attempting to read memory or directly from the MMU.

sherrellbc
  • 4,650
  • 9
  • 48
  • 77