efi_loader: Add bounce buffers

Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a safe way.

This patch implements EFI specific bounce buffers. For non-EFI cases, this apparently was no issue so far, since we can just define our environment variables conveniently.

Signed-off-by Alexander Graf <[email protected]>

We know for certain that we have 32bit DMA hardware, but 64bit addresses on LS2085A and ZynqMP, so let's enable EFI bounce buffers for all defconfigs on these SoCs.

Signed-off-by Alexander Graf <[email protected]>

While testing our shiny new EFI support, I stumbled across systems that have disk I/O hardware that can only access the lower 32bits of our physical address space.

This is not a problem when running with the normal U-Boot flow, since we define all "pointers" that get in use in our environment, so we can just put them inside the lower 32bits.

But when a higher level application such as an EFI payload comes across, it doesn't know about these constraints. So we need to allocate bounce buffers for the payload and use them instead.

Alexander Graf (2):
efi_loader: Add bounce buffer support
efi_loader: Select bounce buffers for known-bad boards

 configs/ls2080a_emu_defconfig                    |  1 +
 configs/ls2080a_simu_defconfig                   |  1 +
 configs/ls2080aqds_SECURE_BOOT_defconfig         |  1 +
 configs/ls2080aqds_defconfig                     |  1 +
 configs/ls2080aqds_nand_defconfig                |  1 +
 configs/ls2080ardb_SECURE_BOOT_defconfig         |  1 +
 configs/ls2080ardb_defconfig                     |  1 +
 configs/ls2080ardb_nand_defconfig                |  1 +
 configs/xilinx_zynqmp_ep_defconfig               |  1 +
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |  1 +
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig |  1 +
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig |  1 +
 configs/xilinx_zynqmp_zcu102_defconfig           |  1 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig      |  1 +
 include/efi_loader.h                             |  5 ++
 lib/efi_loader/Kconfig                           |  9 +++
 lib/efi_loader/efi_disk.c                        | 70 +++++++++++++++++++++---
 lib/efi_loader/efi_memory.c                      | 16 ++++++
 18 files changed, 105 insertions(+), 9 deletions(-)

Am 11.05.2016 um 18:33 schrieb York Sun <[email protected]>:

Quoted 5 lines · Alexander Graf

While testing our shiny new EFI support, I stumbled across systems that have disk I/O hardware that can only access the lower 32bits of our physical address space.

Quoted 7 lines

This is not a problem when running with the normal U-Boot flow, since we define all "pointers" that get in use in our environment, so we can just put them inside the lower 32bits.

But when a higher level application such as an EFI payload comes across, it doesn't know about these constraints. So we need to allocate bounce buffers for the payload and use them instead.

Alexander,

The low 32-bit physical memory is required for this to work, isn't it? There was a discussion to move to high memory for LS2080 so the memory can be continuous for OS.

York

Quoted 24 lines

Alexander Graf (2):
efi_loader: Add bounce buffer support
efi_loader: Select bounce buffers for known-bad boards

configs/ls2080a_emu_defconfig                    |  1 +
configs/ls2080a_simu_defconfig                   |  1 +
configs/ls2080aqds_SECURE_BOOT_defconfig         |  1 +
configs/ls2080aqds_defconfig                     |  1 +
configs/ls2080aqds_nand_defconfig                |  1 +
configs/ls2080ardb_SECURE_BOOT_defconfig         |  1 +
configs/ls2080ardb_defconfig                     |  1 +
configs/ls2080ardb_nand_defconfig                |  1 +
configs/xilinx_zynqmp_ep_defconfig               |  1 +
configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |  1 +
configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig |  1 +
configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig |  1 +
configs/xilinx_zynqmp_zcu102_defconfig           |  1 +
configs/xilinx_zynqmp_zcu102_revB_defconfig      |  1 +
include/efi_loader.h                             |  5 ++
lib/efi_loader/Kconfig                           |  9 +++
lib/efi_loader/efi_disk.c                        | 70 +++++++++++++++++++++---
lib/efi_loader/efi_memory.c                      | 16 ++++++
18 files changed, 105 insertions(+), 9 deletions(-)

Quoted 17 lines

Am 11.05.2016 um 18:33 schrieb York Sun <[email protected]>:

Quoted 12 lines · Alexander Graf

While testing our shiny new EFI support, I stumbled across systems that have disk I/O hardware that can only access the lower 32bits of our physical address space.

This is not a problem when running with the normal U-Boot flow, since we define all "pointers" that get in use in our environment, so we can just put them inside the lower 32bits.

But when a higher level application such as an EFI payload comes across, it doesn't know about these constraints. So we need to allocate bounce buffers for the payload and use them instead.

Quoted 5 lines

Alexander,

The low 32-bit physical memory is required for this to work, isn't it? There was a discussion to move to high memory for LS2080 so the memory can be continuous for OS.

So how would that work in the non-efi case? Do you configure the smmu statically to give you an offset between device memory view and physical?

In that case we can probably extend the patch to make the config variable a max addr instead of bool. Then the bounce buffer would be inside the shifted 32bit window.

Alex

Quoted 28 lines

York

Quoted 24 lines

Alexander Graf (2):
efi_loader: Add bounce buffer support
efi_loader: Select bounce buffers for known-bad boards

configs/ls2080a_emu_defconfig                    |  1 +
configs/ls2080a_simu_defconfig                   |  1 +
configs/ls2080aqds_SECURE_BOOT_defconfig         |  1 +
configs/ls2080aqds_defconfig                     |  1 +
configs/ls2080aqds_nand_defconfig                |  1 +
configs/ls2080ardb_SECURE_BOOT_defconfig         |  1 +
configs/ls2080ardb_defconfig                     |  1 +
configs/ls2080ardb_nand_defconfig                |  1 +
configs/xilinx_zynqmp_ep_defconfig               |  1 +
configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |  1 +
configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig |  1 +
configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig |  1 +
configs/xilinx_zynqmp_zcu102_defconfig           |  1 +
configs/xilinx_zynqmp_zcu102_revB_defconfig      |  1 +
include/efi_loader.h                             |  5 ++
lib/efi_loader/Kconfig                           |  9 +++
lib/efi_loader/efi_disk.c                        | 70 +++++++++++++++++++++---
lib/efi_loader/efi_memory.c                      | 16 ++++++
18 files changed, 105 insertions(+), 9 deletions(-)

Am 11.05.2016 um 19:09 schrieb York Sun <[email protected]>:

Quoted 18 lines · Alexander Graf

Quoted 17 lines

Quoted 16 lines

Am 11.05.2016 um 18:33 schrieb York Sun <[email protected]>:

On 05/11/2016 09:25 AM, Alexander Graf wrote:
While testing our shiny new EFI support, I stumbled across systems that have disk I/O hardware that can only access the lower 32bits of our physical address space.

This is not a problem when running with the normal U-Boot flow, since we define all "pointers" that get in use in our environment, so we can just put them inside the lower 32bits.

But when a higher level application such as an EFI payload comes across, it doesn't know about these constraints. So we need to allocate bounce buffers for the payload and use them instead.

Quoted 7 lines

Quoted 5 lines

Alexander,

The low 32-bit physical memory is required for this to work, isn't it? There was a discussion to move to high memory for LS2080 so the memory can be continuous for OS.

So how would that work in the non-efi case? Do you configure the smmu statically to give you an offset between device memory view and physical?

Alex,

We are still waiting for more thorough testing on all drivers. This was an effort to provide continuous memory for OS. As you know, only 2GB memory is available under 32-bit space. All other memory shows up at above 39-bit space. Limited tests proved Linux can boot with the high memory. However, some drivers may not be happy with the missing 32-bit memory space. The final call is not made yet.