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(-) -- 1.8.5.6 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
