rpi3: UEFI + Windows requires alternate memory mapping

[pbatard]

The current memory mapping of ATF on the Raspberry Pi 3 is geared towards the use of uboot + Linux.

This creates a major incompatibility when using an UEFI payload, as required for running Windows on ARM64.

For UEFI + Windows to run on the Raspberry Pi, we need the following memory mapping:

    0x00000000 +-----------------+
               |       ROM       | BL1
    0x00010000 +-----------------+
               |       DTB       | (Loaded by the VideoCore)
    0x00020000 +-----------------+
               |       FIP       |
    0x00030000 +-----------------+
               |                 |
               |  UEFI PAYLOAD   |
               |                 |
    0x00200000 +-----------------+
               |   Secure SRAM   | BL2, BL31
    0x00300000 +-----------------+
               |   Secure DRAM   | BL32 (Secure payload)
    0x00400000 +-----------------+
               |                 |
               |                 |
               | Non-secure DRAM | BL33
               |                 |
               |                 |
    0x01000000 +-----------------+
               |                 |
               |       ...       |
               |                 |
    0x3F000000 +-----------------+
               |       I/O       |

Especially, as far was we could see, it appears that Windows does require to see some DRAM @ 0x00400000 and/or have memory above 0x01000000 unencumbered, which the current rpi3 memory mapping cannot provide.

This is quite different from the default rpi3 mapping that can be seen in rpi3.rst

We therefore propose the introduction of a new build option, RPI3_USE_UEFI_MAP, that would be off by default and that, when enabled, would make the rpi3 build process use the memory map proposed above.

We have validated that, when the mapping above is used along with an UEFI payload, we can successfully run Windows 10 (17134) on the Raspberry Pi 3 Model B and Pi 3 Model B+ (as well as Linux, such as Ubuntu, including the optional provision of a Device Tree @ 0x00010000).

We will therefore create a pull request with this option.

Note: Along with #647, this is the very last item we need from ATF, to be able to submit an UEFI firmware for the Raspberry Pi 3 to edk2-platforms that would include vanilla (i.e. non "dirty") bl1.bin & fip.bin files.