search

pftf / RPi4

Raspberry Pi 4 UEFI Firmware Images
https://rpi4-uefi.dev
Other
1.19k stars 140 forks source link

VIOMMU & ACPI DMAR Table (virtual address translation) #90

Open TheMindVirus opened 4 years ago

TheMindVirus commented 4 years ago

There are many issues being caused by the lack of virtual addressing.

This issues specifically involve I/O memory mapping for GPIO/Ethernet etc. and also System memory mapping for Virtualisation. This is usually the responsibility of a Direct Memory Access Controller (DMA), usually found on the motherboard as an FPGA.

The Pi4 has no such IOMMU (Input/Output Memory Management Unit). I propose something called a VIOMMU to be implemented in Raspberry Pi Firmware.

As the name suggests, it is a Virtual Input/Output Memory Management System for the Pi4 Address Space. When for example Windows 64-bit calls MmMapIoSpace, the firmware would be responsible for allocating a section of system memory which is directly linked to the I/O memory of the ARM SoC. This could either be a hard link or a soft link.

The system should aim to be either Bit-Agnostic or 64-bit if necessary. Issues with dual 32-bit accesses should be resolved by the use of this VIOMMU unit which sits between the hardware and the operating system to link and translate addresses.

The Operating System can be presented with a DMAR table from the ACPI specification. This table is already used to make technologies such as Intel-VT-d and AMD-V functional. It would be good to see an ARM equivalent, especially since the Cortex A72 has hardware virtualisation support.

Any corrections or additional thoughts are welcome. Alastair Cota - Embedded Firmware Developer

samerhaj commented 4 years ago

FYI the DMAR ACPI table is defined in https://software.intel.com/content/www/us/en/develop/download/intel-virtualization-technology-for-directed-io-architecture-specification.html , section 8.1

TheMindVirus commented 4 years ago

So as far as I can tell these tables are only intended as a point of reference for the firmware or operating system to then know which address to find the peripherals in I/O memory.

After further diagnosis I have found potential root causes of issues relating to lack of peripheral access to new drivers.

The conflict lies in the GPIO memory map. For a start, the base address has moved from 0x7E200000 in BCM2835-2837 to 0x7E215000 in BCM2711. This may confuse some drivers if porting UEFI/Drivers directly from previous Pi platforms.

Additional to this, GPIO on each platform have numerous functions. They can be set to 1 of the following: INPUT, OUTPUT, ALT0, ALT1, ALT2, ALT3, ALT4 or ALT5. The GPIO spans more than the 40-pin header and now in the Pi4 provides the RGMII protocol to the Broadcom Genet Network Adapter (amongst other peripherals e.g. SDIO WiFi on SD1).

My assumption is that regardless of what the UEFI is setting the boot-time values to (with a lack of Device Tree Boot), the GPIO is being overridden by the OS driver to be all INPUT in the GPIO Function Select Registers (closest to GPIO base). If so, all peripherals become disconnected as soon as the GPIO driver takes over. For future testing it is important that the correct ALT modes are set for the Pi4, both during boot and while running the OS. These cannot be the same as the Pi3 or other previous models due to the fundamental differences as listed above.

Can someone please confirm my assumptions? Alastair Cota - Embedded Firmware Developer

samerhaj commented 3 years ago

Possibly related to #105 ?