[U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[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.

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] [PATCH 1/2] efi_loader: Add bounce buffer support

[Alexander Graf]

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 <agraf@suse.de>
---
 include/efi_loader.h        |  5 ++++
 lib/efi_loader/Kconfig      |  9 ++++++
 lib/efi_loader/efi_disk.c   | 70 +++++++++++++++++++++++++++++++++++++++------
 lib/efi_loader/efi_memory.c | 16 +++++++++++
 4 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 8005454..b1ca4ba 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -139,6 +139,11 @@ uint64_t efi_add_memory_map(uint64_t start, uint64_t pages, int memory_type,
 /* Called by board init to initialize the EFI memory map */
 int efi_memory_init(void);
 
+#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
+extern void *efi_bounce_buffer;
+#define EFI_LOADER_BOUNCE_BUFFER_SIZE (64 * 1024 * 1024)
+#endif
+
 /* Convert strings from normal C strings to uEFI strings */
 static inline void ascii2unicode(u16 *unicode, char *ascii)
 {
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 14c99ec..37a0dd6 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -7,3 +7,12 @@ config EFI_LOADER
 	  on top of U-Boot. If this option is enabled, U-Boot will expose EFI
 	  interfaces to a loaded EFI application, enabling it to reuse U-Boot's
 	  device drivers.
+
+config EFI_LOADER_BOUNCE_BUFFER
+	bool "EFI Applications use bounce buffers for DMA operations"
+	depends on EFI_LOADER && ARM64
+	default n
+	help
+	  Some hardware does not support DMA to full 64bit addresses. For this
+	  hardware we can create a bounce buffer so that payloads don't have to
+	  worry about platform details.
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 28e5b7f..ffce286 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -75,9 +75,6 @@ static efi_status_t EFIAPI efi_disk_rw_blocks(struct efi_block_io *this,
 	int blocks;
 	unsigned long n;
 
-	EFI_ENTRY("%p, %x, %"PRIx64", %lx, %p", this, media_id, lba,
-		  buffer_size, buffer);
-
 	diskobj = container_of(this, struct efi_disk_obj, ops);
 	if (!(desc = blk_get_dev(diskobj->ifname, diskobj->dev_index)))
 		return EFI_EXIT(EFI_DEVICE_ERROR);
@@ -94,10 +91,11 @@ static efi_status_t EFIAPI efi_disk_rw_blocks(struct efi_block_io *this,
 	if (buffer_size & (blksz - 1))
 		return EFI_EXIT(EFI_DEVICE_ERROR);
 
-	if (direction == EFI_DISK_READ)
+	if (direction == EFI_DISK_READ) {
 		n = desc->block_read(desc, lba, blocks, buffer);
-	else
+	} else {
 		n = desc->block_write(desc, lba, blocks, buffer);
+	}
 
 	/* We don't do interrupts, so check for timers cooperatively */
 	efi_timer_check();
@@ -115,16 +113,70 @@ static efi_status_t efi_disk_read_blocks(struct efi_block_io *this,
 			u32 media_id, u64 lba, unsigned long buffer_size,
 			void *buffer)
 {
-	return efi_disk_rw_blocks(this, media_id, lba, buffer_size, buffer,
-				  EFI_DISK_READ);
+	void *real_buffer = buffer;
+	efi_status_t r;
+
+#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
+	if (buffer_size > EFI_LOADER_BOUNCE_BUFFER_SIZE) {
+		r = efi_disk_read_blocks(this, media_id, lba,
+			EFI_LOADER_BOUNCE_BUFFER_SIZE, buffer);
+		if (r != EFI_SUCCESS)
+			return r;
+		return efi_disk_read_blocks(this, media_id, lba +
+			EFI_LOADER_BOUNCE_BUFFER_SIZE / this->media->block_size,
+			buffer_size - EFI_LOADER_BOUNCE_BUFFER_SIZE,
+			buffer + EFI_LOADER_BOUNCE_BUFFER_SIZE);
+	}
+
+	real_buffer = efi_bounce_buffer;
+#endif
+
+	EFI_ENTRY("%p, %x, %"PRIx64", %lx, %p", this, media_id, lba,
+		  buffer_size, buffer);
+
+	r = efi_disk_rw_blocks(this, media_id, lba, buffer_size, real_buffer,
+			       EFI_DISK_READ);
+
+	/* Copy from bounce buffer to real buffer if necessary */
+	if ((r == EFI_SUCCESS) && (real_buffer != buffer))
+		memcpy(buffer, real_buffer, buffer_size);
+
+	return EFI_EXIT(r);
 }
 
 static efi_status_t efi_disk_write_blocks(struct efi_block_io *this,
 			u32 media_id, u64 lba, unsigned long buffer_size,
 			void *buffer)
 {
-	return efi_disk_rw_blocks(this, media_id, lba, buffer_size, buffer,
-				  EFI_DISK_WRITE);
+	void *real_buffer = buffer;
+	efi_status_t r;
+
+#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
+	if (buffer_size > EFI_LOADER_BOUNCE_BUFFER_SIZE) {
+		r = efi_disk_write_blocks(this, media_id, lba,
+			EFI_LOADER_BOUNCE_BUFFER_SIZE, buffer);
+		if (r != EFI_SUCCESS)
+			return r;
+		return efi_disk_write_blocks(this, media_id, lba +
+			EFI_LOADER_BOUNCE_BUFFER_SIZE / this->media->block_size,
+			buffer_size - EFI_LOADER_BOUNCE_BUFFER_SIZE,
+			buffer + EFI_LOADER_BOUNCE_BUFFER_SIZE);
+	}
+
+	real_buffer = efi_bounce_buffer;
+#endif
+
+	EFI_ENTRY("%p, %x, %"PRIx64", %lx, %p", this, media_id, lba,
+		  buffer_size, buffer);
+
+	/* Populate bounce buffer if necessary */
+	if (real_buffer != buffer)
+		memcpy(real_buffer, buffer, buffer_size);
+
+	r = efi_disk_rw_blocks(this, media_id, lba, buffer_size, real_buffer,
+			       EFI_DISK_WRITE);
+
+	return EFI_EXIT(r);
 }
 
 static efi_status_t EFIAPI efi_disk_flush_blocks(struct efi_block_io *this)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 71a3d19..9e669f5 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -27,6 +27,10 @@ struct efi_mem_list {
 /* This list contains all memory map items */
 LIST_HEAD(efi_mem);
 
+#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
+void *efi_bounce_buffer;
+#endif
+
 /*
  * Sorts the memory list from highest address to lowest address
  *
@@ -349,5 +353,17 @@ int efi_memory_init(void)
 	efi_add_memory_map(runtime_start, runtime_pages,
 			   EFI_RUNTIME_SERVICES_CODE, false);
 
+#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
+	/* Request a 32bit 64MB bounce buffer region */
+	uint64_t efi_bounce_buffer_addr = 0xffffffff;
+
+	if (efi_allocate_pages(1, EFI_LOADER_DATA,
+			       (64 * 1024 * 1024) >> EFI_PAGE_SHIFT,
+			       &efi_bounce_buffer_addr) != EFI_SUCCESS)
+		return -1;
+
+	efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
+#endif
+
 	return 0;
 }
-- 
1.8.5.6

[U-Boot] [PATCH 2/2] efi_loader: Select bounce buffers for known-bad boards

[Alexander Graf]

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 <agraf@suse.de>
---
 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 +
 14 files changed, 14 insertions(+)

diff --git a/configs/ls2080a_emu_defconfig b/configs/ls2080a_emu_defconfig
index 30a6381..56922dc 100644
--- a/configs/ls2080a_emu_defconfig
+++ b/configs/ls2080a_emu_defconfig
@@ -26,3 +26,4 @@ CONFIG_CMD_CACHE=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
 CONFIG_BOOTP_VCI_STRING="U-Boot.LS2080A-EMU"
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080a_simu_defconfig b/configs/ls2080a_simu_defconfig
index a095b8a..f27fbb7 100644
--- a/configs/ls2080a_simu_defconfig
+++ b/configs/ls2080a_simu_defconfig
@@ -29,3 +29,4 @@ CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
 CONFIG_BOOTP_VCI_STRING="U-Boot.LS2080A-SIMU"
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig b/configs/ls2080aqds_SECURE_BOOT_defconfig
index 216559c..04a84ab 100644
--- a/configs/ls2080aqds_SECURE_BOOT_defconfig
+++ b/configs/ls2080aqds_SECURE_BOOT_defconfig
@@ -30,3 +30,4 @@ CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_FSL_DSPI=y
 CONFIG_RSA=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080aqds_defconfig b/configs/ls2080aqds_defconfig
index 854630a..3b6504b 100644
--- a/configs/ls2080aqds_defconfig
+++ b/configs/ls2080aqds_defconfig
@@ -29,3 +29,4 @@ CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_FSL_DSPI=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080aqds_nand_defconfig b/configs/ls2080aqds_nand_defconfig
index 4f385a1..1302313 100644
--- a/configs/ls2080aqds_nand_defconfig
+++ b/configs/ls2080aqds_nand_defconfig
@@ -23,3 +23,4 @@ CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080ardb_SECURE_BOOT_defconfig b/configs/ls2080ardb_SECURE_BOOT_defconfig
index 41d30a6..f974d88 100644
--- a/configs/ls2080ardb_SECURE_BOOT_defconfig
+++ b/configs/ls2080ardb_SECURE_BOOT_defconfig
@@ -30,3 +30,4 @@ CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_FSL_DSPI=y
 CONFIG_RSA=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080ardb_defconfig b/configs/ls2080ardb_defconfig
index 2b775cd..0168dbb 100644
--- a/configs/ls2080ardb_defconfig
+++ b/configs/ls2080ardb_defconfig
@@ -29,3 +29,4 @@ CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_FSL_DSPI=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080ardb_nand_defconfig b/configs/ls2080ardb_nand_defconfig
index 0f184c0..718a651 100644
--- a/configs/ls2080ardb_nand_defconfig
+++ b/configs/ls2080ardb_nand_defconfig
@@ -23,3 +23,4 @@ CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_ep_defconfig b/configs/xilinx_zynqmp_ep_defconfig
index b185593..2ca6fe5 100644
--- a/configs/xilinx_zynqmp_ep_defconfig
+++ b/configs/xilinx_zynqmp_ep_defconfig
@@ -55,3 +55,4 @@ CONFIG_G_DNL_MANUFACTURER="Xilinx"
 CONFIG_G_DNL_VENDOR_NUM=0x03fd
 CONFIG_G_DNL_PRODUCT_NUM=0x0300
 # CONFIG_REGEX is not set
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index cc08b03..b86edfd 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -50,3 +50,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Xilinx"
 CONFIG_G_DNL_VENDOR_NUM=0x03FD
 CONFIG_G_DNL_PRODUCT_NUM=0x0300
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
index 14d24a0..4b8ac1c 100644
--- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
@@ -47,3 +47,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Xilinx"
 CONFIG_G_DNL_VENDOR_NUM=0x03FD
 CONFIG_G_DNL_PRODUCT_NUM=0x0300
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
index e1e11b7..e2ee634 100644
--- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
@@ -29,3 +29,4 @@ CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_DM_ETH=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_zcu102_defconfig b/configs/xilinx_zynqmp_zcu102_defconfig
index 6f1cff8..75c53af 100644
--- a/configs/xilinx_zynqmp_zcu102_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_defconfig
@@ -48,3 +48,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Xilinx"
 CONFIG_G_DNL_VENDOR_NUM=0x03FD
 CONFIG_G_DNL_PRODUCT_NUM=0x0300
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig b/configs/xilinx_zynqmp_zcu102_revB_defconfig
index a8982a0..3438bd9 100644
--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
@@ -48,3 +48,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Xilinx"
 CONFIG_G_DNL_VENDOR_NUM=0x03FD
 CONFIG_G_DNL_PRODUCT_NUM=0x0300
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
-- 
1.8.5.6

[U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[York Sun]

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.

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

> 
> 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(-)
> 

[U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[Alexander Graf]

> Am 11.05.2016 um 18:33 schrieb York Sun <york.sun@nxp.com>:
> 
>> 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.
> 
> 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

> 
> York
> 
>> 
>> 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(-)
> 

[U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[York Sun]

On 05/11/2016 10:04 AM, Alexander Graf wrote:
> 
> 
>> Am 11.05.2016 um 18:33 schrieb York Sun <york.sun@nxp.com>:
>>
>>> 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.
>>
>> 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.

York

> 
> 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
> 
>>
>> York
>>
>>>
>>> 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(-)
>>
> 
> 

[U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[Alexander Graf]

> Am 11.05.2016 um 19:09 schrieb York Sun <york.sun@nxp.com>:
> 
>> On 05/11/2016 10:04 AM, Alexander Graf wrote:
>> 
>> 
>>>> Am 11.05.2016 um 18:33 schrieb York Sun <york.sun@nxp.com>:
>>>> 
>>>> 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.
>>> 
>>> 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.

Yes, I remember the discussion and I think it's a great idea. In Linux we shouldn't have any issue at all, since we have full SMMU support there, so a device can always just see everything inside its 32bit addressable space.

But in U-Boot things are not quite as clear to me. I don't think we configure any smmu mapping today, do we? So in that scenario, what's the plan to get it working? The simplest thing I could come up with were simple prepopulated iommu tables that just give us an offset, preferably one that allows us to just cut off the upper 32bits for addresses.


Alex

[U-Boot] [U-Boot,1/2] efi_loader: Add bounce buffer support

[Tom Rini]

On Wed, May 11, 2016 at 06:25:48PM +0200, Alexander Graf wrote:

> 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 <agraf@suse.de>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160530/3b294b7a/attachment.sig>

[U-Boot] [U-Boot, 2/2] efi_loader: Select bounce buffers for known-bad boards

[Tom Rini]

On Wed, May 11, 2016 at 06:25:49PM +0200, Alexander Graf wrote:

> 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 <agraf@suse.de>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160530/cdd83814/attachment.sig>