Does FVP_Base_RevC-2xAEMvA platform model support fully for address translation at PL2 stage 1 MMU in aarch32?

Does FVP_Base_RevC-2xAEMvA platform model support fully for address translation at PL2 stage 1 MMU in aarch32?

[Marek]

Have you ever succeeded in performing a Stage-1 MMU translation using
LPAE (Long Physical Address Extension) on the FVP_Base_RevC-2xAEMvA
platform model running in AArch32 Hyp mode (CONFIG64=0)?

I use for that the fvp-base-arm32 SW stack you dropped support in
meta-arm the other time ago.

I have tried it in u-boot running in pl2 (Hyp mode) without success.
Whichever attributes I assign to the region, Normal Memory with Inner
or Outer Cacheability, Write-Through, or Write-Back,  or Non-cacheable
I always end up with Strongly-Ordered.

I inspected the MMU code thoroughly there, compared with the other
codes for MMU, from trusted-firmware-a, xen, and Linux kernel and it
seems u-boot does it correct. Here is the brief execution steps it
goes through:
#1 Set up the 2M-block at the 2nd level table with attributes
- block descriptor: 0x8000044d
  - bits[1:0] = 0b01 -> valid descriptor, descriptor type: block
  - bits[4:2] = 0b011 ->  AttrIndx[2:0] points to MAIR0[3] . MAIR0[3] is 0xff
  - bits[5] = 0b0 - Non-secure
  - bits[7:6] = 0b01 - Access Permission: Read/write
  - bits[9:8] = 0b00 -> Shareability: non-shareable

#2 Set up 1st level table descriptor pointing to the descriptor shown
above. Its attributes are on bits[1:0] = 0b11 meaning it is valid and
its type is: table
#3 Set control registers as follows

HTCR is: 0x80000500 so
  - bits[9:8] = 0b01 -> Inner Cacheability to Normal memory, Outer
Write-Back Write-Allocate Cacheable
  - bits[11:10] = 0b01 -> Outer Cacheability to Normal memory, Outer
Write-Back Write-Allocate Cacheable
  - bits[13:12] = 0b00 -> Non-shareable
HTTBR is: -x00000000feff4000 -> points to 1st lavel table set in #2
HMAIR0 is: 0xffeeaa00 -> as shown above AttrIndx[2:0] points to MAIR0
and the four nibble being 0xff. 0xff is Normal memory, Inner
Write-Back Cacheablea, Non-transientb
HMAIR1 is: 0x00000000 - I set it to zero as not used.

#4 Then it sets the M and C bits in HSCTLR registers

And inspecting the page tables with amrds Strongly-Ordered
0x80000000 | L2 Block | NP:0x0000000080000000 | XN=0, PXN=0,
Contiguous=0, nG=0, AF=1, SH=0x0, AP=0x1, AttrIndx=0x3
H:0x80000000-0xFEFFFFFF | NP:0x80000000-0xFEFFFFFF | Strongly-ordered
| NA | False | True | True

Could it be that FVP_Base_RevC-2xAEMvA doesn't support the feature?

Thanks,
Marek