[U-Boot] [PATCH v5 0/7] LS2080ARDB: Enable EFI boot support

[U-Boot] [PATCH v5 0/7] LS2080ARDB: Enable EFI boot support

[Alexander Graf]

We now have EFI support in U-Boot which worked out of the box on all systems
that I tried it on so far. Except for the LS2080ARDB. With this patch set
I can successfully boot grub2 and Linux from there on such a system - even
using PXE.

This patch set depends on the efi-next queue and the efi runtime rename patch.
For easy pulling, you can find the fully applied tree here:

  https://github.com/agraf/u-boot.git ls2085-efi-support-v5


v3 -> v4:

  - Add CONFIG_CMD_FS_GENERIC to defconfig
  - Move code into generic quiesce weak function
  - Exit device for real when going to Linux
  - Only apply DPL if we have something to apply
  - New: armv8: ls2080a: Declare spin tables as reserved for efi loader
  - New: efi_loader: Allow boards to implement get_time and reset_system
  - New: armv8: fsl-layerscape: Add support for efi_loader RTS reset
  - New: efi_loader: Declare secure memory as reserved
  - New: efi_loader: Allow bouncing for network

v4 -> v5:

  - Drop patches that are in the efi queue already
    - efi_loader: Allow boards to implement get_time and reset_system
    - efi_loader: Allow bouncing for network
  - Remove manual ttbr / tcr copy
  - Regenerate page tables in EL2, getting us non-secured page tables
  - Add qspi board
  - Don't overwrite ethact
  - Use __efi_runtime tags
  - Use gd->arch.secure_ram

Alexander Graf (7):
  ls2080: Exit dpaa only right before exiting U-Boot
  efi_loader: AArch64: Run EFI payloads in EL2 if U-Boot runs in EL3
  ls2080ardb: Reserve DP-DDR RAM
  ls2080ardb: Convert to distro boot
  armv8: ls2080a: Declare spin tables as reserved for efi loader
  armv8: fsl-layerscape: Add support for efi_loader RTS reset
  efi_loader: Declare secure memory as reserved

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c  | 33 ++++++++++++++++++++++++++++++--
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c  |  6 ++++++
 arch/arm/include/asm/u-boot-arm.h        |  1 +
 arch/arm/lib/bootm.c                     |  7 +++++++
 board/freescale/ls2080a/ls2080a.c        |  6 +++++-
 board/freescale/ls2080aqds/ls2080aqds.c  | 11 +++++------
 board/freescale/ls2080ardb/ls2080ardb.c  | 20 +++++++++++++------
 cmd/bootefi.c                            | 11 +++++++++++
 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/ls2080aqds_qspi_defconfig        |  1 +
 configs/ls2080ardb_SECURE_BOOT_defconfig |  1 +
 configs/ls2080ardb_defconfig             |  1 +
 configs/ls2080ardb_nand_defconfig        |  1 +
 drivers/net/fsl-mc/mc.c                  | 24 +++++++++++++++++++++--
 include/configs/ls2080ardb.h             | 25 +++++++++++++++++++++++-
 lib/efi_loader/efi_boottime.c            |  2 ++
 lib/efi_loader/efi_memory.c              | 15 +++++++++++++++
 21 files changed, 152 insertions(+), 18 deletions(-)

-- 
1.8.5.6

[U-Boot] [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot

[Alexander Graf]

On ls2080 we have a separate network fabric component which we need to
shut down before we enter Linux (or any other OS). Along with that also
comes configuration of the fabric using a description file.

Today we always stop and configure the fabric in the boot script and
(again) exit it on device tree generation. This works ok for the normal
booti case, but with bootefi the payload we're running may still want to
access the network.

So let's add a new fsl_mc command that defers configuration and stopping
the hardware to when we actually exit U-Boot, so that we can still use
the fabric from an EFI payload.

For existing boot scripts, nothing should change with this patch.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v3 -> v4:

  - Move code into generic quiesce weak function
  - Exit device for real when going to Linux
  - Only apply DPL if we have something to apply
---
 arch/arm/include/asm/u-boot-arm.h       |  1 +
 arch/arm/lib/bootm.c                    |  7 +++++++
 board/freescale/ls2080a/ls2080a.c       |  6 +++++-
 board/freescale/ls2080aqds/ls2080aqds.c | 11 +++++------
 board/freescale/ls2080ardb/ls2080ardb.c | 11 +++++------
 drivers/net/fsl-mc/mc.c                 | 24 ++++++++++++++++++++++--
 lib/efi_loader/efi_boottime.c           |  2 ++
 7 files changed, 47 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/u-boot-arm.h b/arch/arm/include/asm/u-boot-arm.h
index 414042d..023daf5 100644
--- a/arch/arm/include/asm/u-boot-arm.h
+++ b/arch/arm/include/asm/u-boot-arm.h
@@ -37,6 +37,7 @@ int	arch_early_init_r(void);
 /* board/.../... */
 int	board_init(void);
 void	dram_init_banksize (void);
+void    board_quiesce_devices(void);
 
 /* cpu/.../interrupt.c */
 int	arch_interrupt_init	(void);
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 53c3141..dedcd1e 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -64,6 +64,10 @@ void arch_lmb_reserve(struct lmb *lmb)
 		    gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size - sp);
 }
 
+__weak void board_quiesce_devices(void)
+{
+}
+
 /**
  * announce_and_cleanup() - Print message and prepare for kernel boot
  *
@@ -84,6 +88,9 @@ static void announce_and_cleanup(int fake)
 #ifdef CONFIG_USB_DEVICE
 	udc_disconnect();
 #endif
+
+	board_quiesce_devices();
+
 	cleanup_before_linux();
 }
 
diff --git a/board/freescale/ls2080a/ls2080a.c b/board/freescale/ls2080a/ls2080a.c
index d0a88d4..4f9b9c8 100644
--- a/board/freescale/ls2080a/ls2080a.c
+++ b/board/freescale/ls2080a/ls2080a.c
@@ -102,6 +102,11 @@ void fdt_fixup_board_enet(void *fdt)
 	else
 		fdt_status_fail(fdt, offset);
 }
+
+void board_quiesce_devices(void)
+{
+	fsl_mc_ldpaa_exit(gd->bd);
+}
 #endif
 
 #ifdef CONFIG_OF_BOARD_SETUP
@@ -122,7 +127,6 @@ int ft_board_setup(void *blob, bd_t *bd)
 
 #ifdef CONFIG_FSL_MC_ENET
 	fdt_fixup_board_enet(blob);
-	fsl_mc_ldpaa_exit(bd);
 #endif
 
 	return 0;
diff --git a/board/freescale/ls2080aqds/ls2080aqds.c b/board/freescale/ls2080aqds/ls2080aqds.c
index d07ca18..73a61fd 100644
--- a/board/freescale/ls2080aqds/ls2080aqds.c
+++ b/board/freescale/ls2080aqds/ls2080aqds.c
@@ -292,14 +292,16 @@ void fdt_fixup_board_enet(void *fdt)
 	else
 		fdt_status_fail(fdt, offset);
 }
+
+void board_quiesce_devices(void)
+{
+	fsl_mc_ldpaa_exit(gd->bd);
+}
 #endif
 
 #ifdef CONFIG_OF_BOARD_SETUP
 int ft_board_setup(void *blob, bd_t *bd)
 {
-#ifdef CONFIG_FSL_MC_ENET
-	int err;
-#endif
 	u64 base[CONFIG_NR_DRAM_BANKS];
 	u64 size[CONFIG_NR_DRAM_BANKS];
 
@@ -317,9 +319,6 @@ int ft_board_setup(void *blob, bd_t *bd)
 
 #ifdef CONFIG_FSL_MC_ENET
 	fdt_fixup_board_enet(blob);
-	err = fsl_mc_ldpaa_exit(bd);
-	if (err)
-		return err;
 #endif
 
 	return 0;
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c b/board/freescale/ls2080ardb/ls2080ardb.c
index 83d9e7e..fab44b9 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -256,14 +256,16 @@ void fdt_fixup_board_enet(void *fdt)
 	else
 		fdt_status_fail(fdt, offset);
 }
+
+void board_quiesce_devices(void)
+{
+	fsl_mc_ldpaa_exit(gd->bd);
+}
 #endif
 
 #ifdef CONFIG_OF_BOARD_SETUP
 int ft_board_setup(void *blob, bd_t *bd)
 {
-#ifdef CONFIG_FSL_MC_ENET
-	int err;
-#endif
 	u64 base[CONFIG_NR_DRAM_BANKS];
 	u64 size[CONFIG_NR_DRAM_BANKS];
 
@@ -281,9 +283,6 @@ int ft_board_setup(void *blob, bd_t *bd)
 
 #ifdef CONFIG_FSL_MC_ENET
 	fdt_fixup_board_enet(blob);
-	err = fsl_mc_ldpaa_exit(bd);
-	if (err)
-		return err;
 #endif
 
 	return 0;
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 1811b0f..46b8a6b 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -40,6 +40,7 @@ int child_dprc_id;
 struct fsl_dpbp_obj *dflt_dpbp = NULL;
 struct fsl_dpio_obj *dflt_dpio = NULL;
 struct fsl_dpni_obj *dflt_dpni = NULL;
+static u64 mc_lazy_dpl_addr;
 
 #ifdef DEBUG
 void dump_ram_words(const char *title, void *addr)
@@ -572,6 +573,9 @@ int mc_apply_dpl(u64 mc_dpl_addr)
 	u64 mc_ram_addr = mc_get_dram_addr();
 	size_t mc_ram_size = mc_get_dram_block_size();
 
+	if (!mc_dpl_addr)
+		return -1;
+
 	error = load_mc_dpl(mc_ram_addr, mc_ram_size, mc_dpl_addr);
 	if (error != 0)
 		return error;
@@ -1156,6 +1160,11 @@ int fsl_mc_ldpaa_exit(bd_t *bd)
 {
 	int err = 0;
 
+	if (bd && mc_lazy_dpl_addr && !fsl_mc_ldpaa_exit(NULL)) {
+		mc_apply_dpl(mc_lazy_dpl_addr);
+		mc_lazy_dpl_addr = 0;
+	}
+
 	/* MC is not loaded intentionally, So return success. */
 	if (bd && get_mc_boot_status() != 0)
 		return 0;
@@ -1259,6 +1268,7 @@ static int do_fsl_mc(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 		}
 		break;
 
+	case 'l':
 	case 'a': {
 			u64 mc_dpl_addr;
 
@@ -1279,8 +1289,17 @@ static int do_fsl_mc(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 				return -ENODEV;
 			}
 
-			if (!fsl_mc_ldpaa_exit(NULL))
-				err = mc_apply_dpl(mc_dpl_addr);
+			if (argv[1][0] == 'l') {
+				/*
+				 * We will do the actual dpaa exit and dpl apply
+				 * later from announce_and_cleanup().
+				 */
+				mc_lazy_dpl_addr = mc_dpl_addr;
+			} else {
+				/* The user wants it applied now */
+				if (!fsl_mc_ldpaa_exit(NULL))
+					err = mc_apply_dpl(mc_dpl_addr);
+			}
 			break;
 		}
 	default:
@@ -1298,5 +1317,6 @@ U_BOOT_CMD(
 	"DPAA2 command to manage Management Complex (MC)",
 	"start mc [FW_addr] [DPC_addr] - Start Management Complex\n"
 	"fsl_mc apply DPL [DPL_addr] - Apply DPL file\n"
+	"fsl_mc lazyapply DPL [DPL_addr] - Apply DPL file on exit\n"
 	"fsl_mc start aiop [FW_addr] - Start AIOP\n"
 );
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 1fdddf4..51080cb 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -538,6 +538,8 @@ static efi_status_t EFIAPI efi_exit_boot_services(void *image_handle,
 {
 	EFI_ENTRY("%p, %ld", image_handle, map_key);
 
+	board_quiesce_devices();
+
 	/* Fix up caches for EFI payloads if necessary */
 	efi_exit_caches();
 
-- 
1.8.5.6

[U-Boot] [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot

[york sun]

On 10/15/2016 03:03 AM, Alexander Graf wrote:
> On ls2080 we have a separate network fabric component which we need to
> shut down before we enter Linux (or any other OS). Along with that also
> comes configuration of the fabric using a description file.
>
> Today we always stop and configure the fabric in the boot script and
> (again) exit it on device tree generation. This works ok for the normal
> booti case, but with bootefi the payload we're running may still want to
> access the network.
>
> So let's add a new fsl_mc command that defers configuration and stopping
> the hardware to when we actually exit U-Boot, so that we can still use
> the fabric from an EFI payload.
>
> For existing boot scripts, nothing should change with this patch.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v3 -> v4:
>
>   - Move code into generic quiesce weak function
>   - Exit device for real when going to Linux
>   - Only apply DPL if we have something to apply
> ---
>  arch/arm/include/asm/u-boot-arm.h       |  1 +
>  arch/arm/lib/bootm.c                    |  7 +++++++
>  board/freescale/ls2080a/ls2080a.c       |  6 +++++-
>  board/freescale/ls2080aqds/ls2080aqds.c | 11 +++++------
>  board/freescale/ls2080ardb/ls2080ardb.c | 11 +++++------
>  drivers/net/fsl-mc/mc.c                 | 24 ++++++++++++++++++++++--
>  lib/efi_loader/efi_boottime.c           |  2 ++
>  7 files changed, 47 insertions(+), 15 deletions(-)

Reviewed-by: York Sun <york.sun@nxp.com>

[U-Boot] [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot

[Prabhakar Kushwaha]

Hi Alex,

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Saturday, October 15, 2016 3:33 PM
> To: u-boot at lists.denx.de
> Cc: york sun <york.sun@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>
> Subject: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
> 
> On ls2080 we have a separate network fabric component which we need to
> shut down before we enter Linux (or any other OS). Along with that also
> comes configuration of the fabric using a description file.
> 
> Today we always stop and configure the fabric in the boot script and
> (again) exit it on device tree generation. This works ok for the normal
> booti case, but with bootefi the payload we're running may still want to
> access the network.
> 
> So let's add a new fsl_mc command that defers configuration and stopping
> the hardware to when we actually exit U-Boot, so that we can still use
> the fabric from an EFI payload.
> 
> For existing boot scripts, nothing should change with this patch.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> 

Can we get one small modification in this patch to include env variable.
So if a user **always** want " lazyapply", this info can be stored in env variable. This env variable will be used after reset without explicit u-boot command.

--prabhakara

[U-Boot] [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot

[Alexander Graf]

Hi Prabhakara,

On 17.10.16 05:42, Prabhakar Kushwaha wrote:
> Hi Alex,
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Saturday, October 15, 2016 3:33 PM
>> To: u-boot at lists.denx.de
>> Cc: york sun <york.sun@nxp.com>; Prabhakar Kushwaha
>> <prabhakar.kushwaha@nxp.com>
>> Subject: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
>>
>> On ls2080 we have a separate network fabric component which we need to
>> shut down before we enter Linux (or any other OS). Along with that also
>> comes configuration of the fabric using a description file.
>>
>> Today we always stop and configure the fabric in the boot script and
>> (again) exit it on device tree generation. This works ok for the normal
>> booti case, but with bootefi the payload we're running may still want to
>> access the network.
>>
>> So let's add a new fsl_mc command that defers configuration and stopping
>> the hardware to when we actually exit U-Boot, so that we can still use
>> the fabric from an EFI payload.
>>
>> For existing boot scripts, nothing should change with this patch.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>
> 
> Can we get one small modification in this patch to include env variable.
> So if a user **always** want " lazyapply", this info can be stored in env variable. This env variable will be used after reset without explicit u-boot command.

I'm not sure I understand your suggestion. We use "lazyapply" because
EFI payloads need to be able to use the fabric for network I/O which is
impossible after a normal apply.

Because we don't know in bootcmd whether we will end up in the old bootm
path or in the fallback distro path (which again potentially means
efi_loader), we have to play safe (lazyapply) by default.


Alex

[U-Boot] [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot

[Prabhakar Kushwaha]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Monday, October 17, 2016 12:28 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> boot at lists.denx.de
> Cc: york sun <york.sun@nxp.com>
> Subject: Re: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
> 
> Hi Prabhakara,
> 
> On 17.10.16 05:42, Prabhakar Kushwaha wrote:
> > Hi Alex,
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf at suse.de]
> >> Sent: Saturday, October 15, 2016 3:33 PM
> >> To: u-boot at lists.denx.de
> >> Cc: york sun <york.sun@nxp.com>; Prabhakar Kushwaha
> >> <prabhakar.kushwaha@nxp.com>
> >> Subject: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
> >>
> >> On ls2080 we have a separate network fabric component which we need to
> >> shut down before we enter Linux (or any other OS). Along with that also
> >> comes configuration of the fabric using a description file.
> >>
> >> Today we always stop and configure the fabric in the boot script and
> >> (again) exit it on device tree generation. This works ok for the normal
> >> booti case, but with bootefi the payload we're running may still want to
> >> access the network.
> >>
> >> So let's add a new fsl_mc command that defers configuration and stopping
> >> the hardware to when we actually exit U-Boot, so that we can still use
> >> the fabric from an EFI payload.
> >>
> >> For existing boot scripts, nothing should change with this patch.
> >>
> >> Signed-off-by: Alexander Graf <agraf@suse.de>
> >>
> >
> > Can we get one small modification in this patch to include env variable.
> > So if a user **always** want " lazyapply", this info can be stored in env
> variable. This env variable will be used after reset without explicit u-boot
> command.
> 
> I'm not sure I understand your suggestion. We use "lazyapply" because
> EFI payloads need to be able to use the fabric for network I/O which is
> impossible after a normal apply.
> 
> Because we don't know in bootcmd whether we will end up in the old bootm
> path or in the fallback distro path (which again potentially means
> efi_loader), we have to play safe (lazyapply) by default.
> 
If I understand correctly, this patch defines a variable mc_lazy_dpl_addr.  It is set via " fsl_mc lazyapply DPL" u-boot command. 
If this variable set
  - Apply DPL file during bootm (no user intervention)
Else
 - Assume user to apply dpl manually by " fsl_mc apply DPL" before running bootm.

One modification can be done to store value mc_lazy_dpl_addr in env so that " fsl_mc lazyapply DPL " will not be required to run after every reset.

--prabhakar

[U-Boot] [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot

[Alexander Graf]

On 10/17/2016 10:56 AM, Prabhakar Kushwaha wrote:
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Monday, October 17, 2016 12:28 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>> boot at lists.denx.de
>> Cc: york sun <york.sun@nxp.com>
>> Subject: Re: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
>>
>> Hi Prabhakara,
>>
>> On 17.10.16 05:42, Prabhakar Kushwaha wrote:
>>> Hi Alex,
>>>
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf at suse.de]
>>>> Sent: Saturday, October 15, 2016 3:33 PM
>>>> To: u-boot at lists.denx.de
>>>> Cc: york sun <york.sun@nxp.com>; Prabhakar Kushwaha
>>>> <prabhakar.kushwaha@nxp.com>
>>>> Subject: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
>>>>
>>>> On ls2080 we have a separate network fabric component which we need to
>>>> shut down before we enter Linux (or any other OS). Along with that also
>>>> comes configuration of the fabric using a description file.
>>>>
>>>> Today we always stop and configure the fabric in the boot script and
>>>> (again) exit it on device tree generation. This works ok for the normal
>>>> booti case, but with bootefi the payload we're running may still want to
>>>> access the network.
>>>>
>>>> So let's add a new fsl_mc command that defers configuration and stopping
>>>> the hardware to when we actually exit U-Boot, so that we can still use
>>>> the fabric from an EFI payload.
>>>>
>>>> For existing boot scripts, nothing should change with this patch.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>
>>> Can we get one small modification in this patch to include env variable.
>>> So if a user **always** want " lazyapply", this info can be stored in env
>> variable. This env variable will be used after reset without explicit u-boot
>> command.
>>
>> I'm not sure I understand your suggestion. We use "lazyapply" because
>> EFI payloads need to be able to use the fabric for network I/O which is
>> impossible after a normal apply.
>>
>> Because we don't know in bootcmd whether we will end up in the old bootm
>> path or in the fallback distro path (which again potentially means
>> efi_loader), we have to play safe (lazyapply) by default.
>>
> If I understand correctly, this patch defines a variable mc_lazy_dpl_addr.  It is set via " fsl_mc lazyapply DPL" u-boot command.
> If this variable set
>    - Apply DPL file during bootm (no user intervention)
> Else
>   - Assume user to apply dpl manually by " fsl_mc apply DPL" before running bootm.
>
> One modification can be done to store value mc_lazy_dpl_addr in env so that " fsl_mc lazyapply DPL " will not be required to run after every reset.

Ah, I see what you're getting at. I like the idea, but I'm not sure this 
is what users would expect. So imagine you do

   # fsl_mc lazyapply ...
   # <attempt boot, fails>
   # <modify environment for next time
   # saveenv

then suddenly you have the lazyapply in your environment. In *most* 
parts of U-Boot environment variables are not used for state transfer 
(one function sets it, another one reads it). So having it here would be 
pretty unnatural and potentially confusing to users.

I'd leave the decision up to York though, it's his command :). Changing 
it to be env based instead is trivial.


Alex

[U-Boot] [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot

[york sun]

On 10/17/2016 04:45 AM, Alexander Graf wrote:
>
>
> On 10/17/2016 10:56 AM, Prabhakar Kushwaha wrote:
>>> -----Original Message-----
>>> From: Alexander Graf [mailto:agraf at suse.de]
>>> Sent: Monday, October 17, 2016 12:28 PM
>>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>>> boot at lists.denx.de
>>> Cc: york sun <york.sun@nxp.com>
>>> Subject: Re: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
>>>
>>> Hi Prabhakara,
>>>
>>> On 17.10.16 05:42, Prabhakar Kushwaha wrote:
>>>> Hi Alex,
>>>>
>>>>> -----Original Message-----
>>>>> From: Alexander Graf [mailto:agraf at suse.de]
>>>>> Sent: Saturday, October 15, 2016 3:33 PM
>>>>> To: u-boot at lists.denx.de
>>>>> Cc: york sun <york.sun@nxp.com>; Prabhakar Kushwaha
>>>>> <prabhakar.kushwaha@nxp.com>
>>>>> Subject: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
>>>>>
>>>>> On ls2080 we have a separate network fabric component which we need to
>>>>> shut down before we enter Linux (or any other OS). Along with that also
>>>>> comes configuration of the fabric using a description file.
>>>>>
>>>>> Today we always stop and configure the fabric in the boot script and
>>>>> (again) exit it on device tree generation. This works ok for the normal
>>>>> booti case, but with bootefi the payload we're running may still want to
>>>>> access the network.
>>>>>
>>>>> So let's add a new fsl_mc command that defers configuration and stopping
>>>>> the hardware to when we actually exit U-Boot, so that we can still use
>>>>> the fabric from an EFI payload.
>>>>>
>>>>> For existing boot scripts, nothing should change with this patch.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>
>>>> Can we get one small modification in this patch to include env variable.
>>>> So if a user **always** want " lazyapply", this info can be stored in env
>>> variable. This env variable will be used after reset without explicit u-boot
>>> command.
>>>
>>> I'm not sure I understand your suggestion. We use "lazyapply" because
>>> EFI payloads need to be able to use the fabric for network I/O which is
>>> impossible after a normal apply.
>>>
>>> Because we don't know in bootcmd whether we will end up in the old bootm
>>> path or in the fallback distro path (which again potentially means
>>> efi_loader), we have to play safe (lazyapply) by default.
>>>
>> If I understand correctly, this patch defines a variable mc_lazy_dpl_addr.  It is set via " fsl_mc lazyapply DPL" u-boot command.
>> If this variable set
>>    - Apply DPL file during bootm (no user intervention)
>> Else
>>   - Assume user to apply dpl manually by " fsl_mc apply DPL" before running bootm.
>>
>> One modification can be done to store value mc_lazy_dpl_addr in env so that " fsl_mc lazyapply DPL " will not be required to run after every reset.
>
> Ah, I see what you're getting at. I like the idea, but I'm not sure this
> is what users would expect. So imagine you do
>
>    # fsl_mc lazyapply ...
>    # <attempt boot, fails>
>    # <modify environment for next time
>    # saveenv
>
> then suddenly you have the lazyapply in your environment. In *most*
> parts of U-Boot environment variables are not used for state transfer
> (one function sets it, another one reads it). So having it here would be
> pretty unnatural and potentially confusing to users.
>
> I'd leave the decision up to York though, it's his command :). Changing
> it to be env based instead is trivial.
>
Prabhakar,

I believe you are trying to address another related issue for applying 
DPL. Please submit a patch on top of Alex's. You can wait a little bit 
after his set is settled.

York

[U-Boot] [PATCH v5 2/7] efi_loader: AArch64: Run EFI payloads in EL2 if U-Boot runs in EL3

[Alexander Graf]

Some boards decided not to run ATF or other secure firmware in EL3, so
they instead run U-Boot there. The uEFI spec doesn't know what EL3 is
though - it only knows about EL2 and EL1. So if we see that we're running
in EL3, let's get into EL2 to make payloads happy.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v4 -> v5:

  - Remove manual ttbr / tcr copy
  - Regenerate page tables in EL2, getting us non-secured page tables
---
 cmd/bootefi.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 8714666..32148d7 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -224,6 +224,17 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
 		return status == EFI_SUCCESS ? 0 : -EINVAL;
 	}
 
+#ifdef CONFIG_ARM64
+	/* On AArch64 we need to make sure we call our payload in < EL3 */
+	if (current_el() == 3) {
+		smp_kick_all_cpus();
+		dcache_disable();	/* flush cache before switch to EL2 */
+		armv8_switch_to_el2();
+		/* Enable caches again */
+		dcache_enable();
+	}
+#endif
+
 	return entry(&loaded_image_info, &systab);
 }
 
-- 
1.8.5.6

[U-Boot] [PATCH v5 2/7] efi_loader: AArch64: Run EFI payloads in EL2 if U-Boot runs in EL3

[york sun]

On 10/15/2016 03:03 AM, Alexander Graf wrote:
> Some boards decided not to run ATF or other secure firmware in EL3, so
> they instead run U-Boot there. The uEFI spec doesn't know what EL3 is
> though - it only knows about EL2 and EL1. So if we see that we're running
> in EL3, let's get into EL2 to make payloads happy.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v4 -> v5:
>
>   - Remove manual ttbr / tcr copy
>   - Regenerate page tables in EL2, getting us non-secured page tables
> ---
>  cmd/bootefi.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 8714666..32148d7 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -224,6 +224,17 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
>  		return status == EFI_SUCCESS ? 0 : -EINVAL;
>  	}
>
> +#ifdef CONFIG_ARM64
> +	/* On AArch64 we need to make sure we call our payload in < EL3 */
> +	if (current_el() == 3) {
> +		smp_kick_all_cpus();
> +		dcache_disable();	/* flush cache before switch to EL2 */
> +		armv8_switch_to_el2();
> +		/* Enable caches again */
> +		dcache_enable();
> +	}
> +#endif
> +
>  	return entry(&loaded_image_info, &systab);
>  }
>
>

Reviewed-by: York Sun <york.sun@nxp.com>

[U-Boot] [PATCH v5 3/7] ls2080ardb: Reserve DP-DDR RAM

[Alexander Graf]

The DP-DDR shouldn't be exposed as conventional memory to an OS, so let's
rather claim it's a reserved region in the EFI memory map

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 board/freescale/ls2080ardb/ls2080ardb.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/board/freescale/ls2080ardb/ls2080ardb.c b/board/freescale/ls2080ardb/ls2080ardb.c
index fab44b9..55199ca 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -15,6 +15,7 @@
 #include <libfdt.h>
 #include <fsl-mc/fsl_mc.h>
 #include <environment.h>
+#include <efi_loader.h>
 #include <i2c.h>
 #include <asm/arch/soc.h>
 #include <fsl_sec.h>
@@ -201,6 +202,14 @@ int misc_init_r(void)
 	if (adjust_vdd(0))
 		printf("Warning: Adjusting core voltage failed.\n");
 
+#ifdef CONFIG_EFI_LOADER
+	if (soc_has_dp_ddr() && gd->bd->bi_dram[2].size) {
+		efi_add_memory_map(gd->bd->bi_dram[2].start,
+				   gd->bd->bi_dram[2].size >> EFI_PAGE_SHIFT,
+				   EFI_RESERVED_MEMORY_TYPE, false);
+	}
+#endif
+
 	return 0;
 }
 
-- 
1.8.5.6

[U-Boot] [PATCH v5 3/7] ls2080ardb: Reserve DP-DDR RAM

[york sun]

On 10/15/2016 03:03 AM, Alexander Graf wrote:
> The DP-DDR shouldn't be exposed as conventional memory to an OS, so let's
> rather claim it's a reserved region in the EFI memory map
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  board/freescale/ls2080ardb/ls2080ardb.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/board/freescale/ls2080ardb/ls2080ardb.c b/board/freescale/ls2080ardb/ls2080ardb.c
> index fab44b9..55199ca 100644
> --- a/board/freescale/ls2080ardb/ls2080ardb.c
> +++ b/board/freescale/ls2080ardb/ls2080ardb.c
> @@ -15,6 +15,7 @@
>  #include <libfdt.h>
>  #include <fsl-mc/fsl_mc.h>
>  #include <environment.h>
> +#include <efi_loader.h>
>  #include <i2c.h>
>  #include <asm/arch/soc.h>
>  #include <fsl_sec.h>
> @@ -201,6 +202,14 @@ int misc_init_r(void)
>  	if (adjust_vdd(0))
>  		printf("Warning: Adjusting core voltage failed.\n");
>
> +#ifdef CONFIG_EFI_LOADER
> +	if (soc_has_dp_ddr() && gd->bd->bi_dram[2].size) {
> +		efi_add_memory_map(gd->bd->bi_dram[2].start,
> +				   gd->bd->bi_dram[2].size >> EFI_PAGE_SHIFT,
> +				   EFI_RESERVED_MEMORY_TYPE, false);
> +	}
> +#endif
> +
>  	return 0;
>  }
>
>
Reviewed-by: York Sun <york.sun@nxp.com>

[U-Boot] [PATCH v5 4/7] ls2080ardb: Convert to distro boot

[Alexander Graf]

Most new systems in U-Boot these days make use of the generic "distro"
framework which allows a user to have U-Boot scan for a bootable OS
on all available media types.

This patch extends the LS2080ARDB board to use that framework if the
hard coded NOR flash location does not contain a bootable image.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v1 -> v2:

  - Boot NOR flash before distro boot

v2 -> v3:

  - Actually run distro boot (s/&&/||/ after bootm)

v3 -> v4:

  - Add CONFIG_CMD_FS_GENERIC to defconfig

v4 -> v5:

  - Add qspi board
  - Don't overwrite ethact
---
 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/ls2080aqds_qspi_defconfig        |  1 +
 configs/ls2080ardb_SECURE_BOOT_defconfig |  1 +
 configs/ls2080ardb_defconfig             |  1 +
 configs/ls2080ardb_nand_defconfig        |  1 +
 include/configs/ls2080ardb.h             | 25 ++++++++++++++++++++++++-
 10 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/configs/ls2080a_emu_defconfig b/configs/ls2080a_emu_defconfig
index e3c02fb..293e682 100644
--- a/configs/ls2080a_emu_defconfig
+++ b/configs/ls2080a_emu_defconfig
@@ -29,3 +29,4 @@ CONFIG_CMD_CACHE=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/configs/ls2080a_simu_defconfig b/configs/ls2080a_simu_defconfig
index 081f810..6af6a66 100644
--- a/configs/ls2080a_simu_defconfig
+++ b/configs/ls2080a_simu_defconfig
@@ -32,3 +32,4 @@ CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig b/configs/ls2080aqds_SECURE_BOOT_defconfig
index 31e69b4..6eac575 100644
--- a/configs/ls2080aqds_SECURE_BOOT_defconfig
+++ b/configs/ls2080aqds_SECURE_BOOT_defconfig
@@ -38,3 +38,4 @@ CONFIG_USB_STORAGE=y
 CONFIG_RSA=y
 CONFIG_SPL_RSA=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/configs/ls2080aqds_defconfig b/configs/ls2080aqds_defconfig
index af52818..64d90e8 100644
--- a/configs/ls2080aqds_defconfig
+++ b/configs/ls2080aqds_defconfig
@@ -36,3 +36,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/configs/ls2080aqds_nand_defconfig b/configs/ls2080aqds_nand_defconfig
index f09809d..6431d92 100644
--- a/configs/ls2080aqds_nand_defconfig
+++ b/configs/ls2080aqds_nand_defconfig
@@ -45,3 +45,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/configs/ls2080aqds_qspi_defconfig b/configs/ls2080aqds_qspi_defconfig
index 2b24a94..edcab88 100644
--- a/configs/ls2080aqds_qspi_defconfig
+++ b/configs/ls2080aqds_qspi_defconfig
@@ -37,3 +37,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/configs/ls2080ardb_SECURE_BOOT_defconfig b/configs/ls2080ardb_SECURE_BOOT_defconfig
index a62d864..fe217a4 100644
--- a/configs/ls2080ardb_SECURE_BOOT_defconfig
+++ b/configs/ls2080ardb_SECURE_BOOT_defconfig
@@ -38,3 +38,4 @@ CONFIG_USB_STORAGE=y
 CONFIG_RSA=y
 CONFIG_SPL_RSA=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/configs/ls2080ardb_defconfig b/configs/ls2080ardb_defconfig
index bbf2a74..e26ae23 100644
--- a/configs/ls2080ardb_defconfig
+++ b/configs/ls2080ardb_defconfig
@@ -36,3 +36,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/configs/ls2080ardb_nand_defconfig b/configs/ls2080ardb_nand_defconfig
index 98a00e2..112fcc9 100644
--- a/configs/ls2080ardb_nand_defconfig
+++ b/configs/ls2080ardb_nand_defconfig
@@ -41,3 +41,4 @@ CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index ee0f5fc..045cee6 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -318,10 +318,24 @@ unsigned long get_board_sys_clk(void);
 #define CONFIG_USB_MAX_CONTROLLER_COUNT         2
 #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS      2
 
+#undef CONFIG_CMDLINE_EDITING
+#include <config_distro_defaults.h>
+
+#define BOOT_TARGET_DEVICES(func) \
+	func(MMC, mmc, 0) \
+	func(SCSI, scsi, 0) \
+	func(DHCP, dhcp, na)
+#include <config_distro_bootcmd.h>
+
 /* Initial environment variables */
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS		\
 	"hwconfig=fsl_ddr:bank_intlv=auto\0"	\
+	"scriptaddr=0x80800000\0"		\
+	"kernel_addr_r=0x81000000\0"		\
+	"pxefile_addr_r=0x81000000\0"		\
+	"fdt_addr_r=0x88000000\0"		\
+	"ramdisk_addr_r=0x89000000\0"		\
 	"loadaddr=0x80100000\0"			\
 	"kernel_addr=0x100000\0"		\
 	"ramdisk_addr=0x800000\0"		\
@@ -331,8 +345,10 @@ unsigned long get_board_sys_clk(void);
 	"kernel_start=0x581100000\0"		\
 	"kernel_load=0xa0000000\0"		\
 	"kernel_size=0x2800000\0"		\
+	"fdtfile=fsl-ls2080a-rdb.dtb\0"		\
 	"mcinitcmd=fsl_mc start mc 0x580300000"	\
-	" 0x580800000 \0"
+	" 0x580800000 \0"			\
+	BOOTENV
 
 #undef CONFIG_BOOTARGS
 #define CONFIG_BOOTARGS		"console=ttyS1,115200 root=/dev/ram0 " \
@@ -340,6 +356,13 @@ unsigned long get_board_sys_clk(void);
 				"ramdisk_size=0x2000000 default_hugepagesz=2m" \
 				" hugepagesz=2m hugepages=256"
 
+#undef CONFIG_BOOTCOMMAND
+/* Try to boot an on-NOR kernel first, then do normal distro boot */
+#define CONFIG_BOOTCOMMAND "run mcinitcmd && fsl_mc lazyapply dpl 0x580700000" \
+			   " && cp.b $kernel_start $kernel_load $kernel_size" \
+			   " && bootm $kernel_load" \
+			   " || run distro_bootcmd"
+
 /* MAC/PHY configuration */
 #ifdef CONFIG_FSL_MC_ENET
 #define CONFIG_PHYLIB_10G
-- 
1.8.5.6

[U-Boot] [PATCH v5 4/7] ls2080ardb: Convert to distro boot

[york sun]

On 10/15/2016 03:03 AM, Alexander Graf wrote:
> Most new systems in U-Boot these days make use of the generic "distro"
> framework which allows a user to have U-Boot scan for a bootable OS
> on all available media types.
>
> This patch extends the LS2080ARDB board to use that framework if the
> hard coded NOR flash location does not contain a bootable image.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v1 -> v2:
>
>   - Boot NOR flash before distro boot
>
> v2 -> v3:
>
>   - Actually run distro boot (s/&&/||/ after bootm)
>
> v3 -> v4:
>
>   - Add CONFIG_CMD_FS_GENERIC to defconfig
>
> v4 -> v5:
>
>   - Add qspi board
>   - Don't overwrite ethact

Alex,

Don't we have an issue to run distro boot right after this patch? I 
think this patch should be the last in this set. Don't you agree?

For this patch itself,
Reviewed-by: York Sun <york.sun@nxp.com>

[U-Boot] [PATCH v5 4/7] ls2080ardb: Convert to distro boot

[Alexander Graf]

On 15.10.16 18:56, york sun wrote:
> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>> Most new systems in U-Boot these days make use of the generic "distro"
>> framework which allows a user to have U-Boot scan for a bootable OS
>> on all available media types.
>>
>> This patch extends the LS2080ARDB board to use that framework if the
>> hard coded NOR flash location does not contain a bootable image.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>
>> ---
>>
>> v1 -> v2:
>>
>>   - Boot NOR flash before distro boot
>>
>> v2 -> v3:
>>
>>   - Actually run distro boot (s/&&/||/ after bootm)
>>
>> v3 -> v4:
>>
>>   - Add CONFIG_CMD_FS_GENERIC to defconfig
>>
>> v4 -> v5:
>>
>>   - Add qspi board
>>   - Don't overwrite ethact
> 
> Alex,
> 
> Don't we have an issue to run distro boot right after this patch? I 
> think this patch should be the last in this set. Don't you agree?

Distro boot is much more than just efi_loader boot. It also has extlinux
support for example. So while at this point efi_loader doesn't work yet,
the other bits do indeed work :).

It doesn't hurt to move this patch at the end of the queue though, so
I'll do that nevertheless.


Alex

[U-Boot] [PATCH v5 5/7] armv8: ls2080a: Declare spin tables as reserved for efi loader

[Alexander Graf]

The efi loader code has its own memory map, so it needs to be aware where
the spin tables are located, to ensure that no code writes into those
regions.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 1a8321b..facfcca 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -5,6 +5,7 @@
  */
 
 #include <common.h>
+#include <efi_loader.h>
 #include <libfdt.h>
 #include <fdt_support.h>
 #include <phy.h>
@@ -105,6 +106,11 @@ remove_psci_node:
 
 	fdt_add_mem_rsv(blob, (uintptr_t)&secondary_boot_code,
 			*boot_code_size);
+#ifdef CONFIG_EFI_LOADER
+	efi_add_memory_map((uintptr_t)&secondary_boot_code,
+			   ALIGN(*boot_code_size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT,
+			   EFI_RESERVED_MEMORY_TYPE, false);
+#endif
 }
 #endif
 
-- 
1.8.5.6

[U-Boot] [PATCH v5 5/7] armv8: ls2080a: Declare spin tables as reserved for efi loader

[york sun]

On 10/15/2016 03:03 AM, Alexander Graf wrote:
> The efi loader code has its own memory map, so it needs to be aware where
> the spin tables are located, to ensure that no code writes into those
> regions.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index 1a8321b..facfcca 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -5,6 +5,7 @@
>   */
>
>  #include <common.h>
> +#include <efi_loader.h>
>  #include <libfdt.h>
>  #include <fdt_support.h>
>  #include <phy.h>
> @@ -105,6 +106,11 @@ remove_psci_node:
>
>  	fdt_add_mem_rsv(blob, (uintptr_t)&secondary_boot_code,
>  			*boot_code_size);
> +#ifdef CONFIG_EFI_LOADER
> +	efi_add_memory_map((uintptr_t)&secondary_boot_code,
> +			   ALIGN(*boot_code_size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT,
> +			   EFI_RESERVED_MEMORY_TYPE, false);
> +#endif
>  }
>  #endif
>
>
Alex,

Does it make more sense to use __spin_table instead of 
secondary_boot_code (even they happen to have the same value here)?

York

[U-Boot] [PATCH v5 5/7] armv8: ls2080a: Declare spin tables as reserved for efi loader

[Alexander Graf]

On 15.10.16 18:57, york sun wrote:
> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>> The efi loader code has its own memory map, so it needs to be aware where
>> the spin tables are located, to ensure that no code writes into those
>> regions.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
>> index 1a8321b..facfcca 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
>> @@ -5,6 +5,7 @@
>>   */
>>
>>  #include <common.h>
>> +#include <efi_loader.h>
>>  #include <libfdt.h>
>>  #include <fdt_support.h>
>>  #include <phy.h>
>> @@ -105,6 +106,11 @@ remove_psci_node:
>>
>>  	fdt_add_mem_rsv(blob, (uintptr_t)&secondary_boot_code,
>>  			*boot_code_size);
>> +#ifdef CONFIG_EFI_LOADER
>> +	efi_add_memory_map((uintptr_t)&secondary_boot_code,
>> +			   ALIGN(*boot_code_size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT,
>> +			   EFI_RESERVED_MEMORY_TYPE, false);
>> +#endif
>>  }
>>  #endif
>>
>>
> Alex,
> 
> Does it make more sense to use __spin_table instead of 
> secondary_boot_code (even they happen to have the same value here)?

I'm reasonably indifferent, but I wanted to make sure we're using the
same values as the fdt_add_mem_rsv() line above :).


Alex

[U-Boot] [PATCH v5 5/7] armv8: ls2080a: Declare spin tables as reserved for efi loader

[york sun]

On 10/17/2016 02:01 AM, Alexander Graf wrote:
>
>
> On 15.10.16 18:57, york sun wrote:
>> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>>> The efi loader code has its own memory map, so it needs to be aware where
>>> the spin tables are located, to ensure that no code writes into those
>>> regions.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>> ---
>>>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
>>> index 1a8321b..facfcca 100644
>>> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
>>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
>>> @@ -5,6 +5,7 @@
>>>   */
>>>
>>>  #include <common.h>
>>> +#include <efi_loader.h>
>>>  #include <libfdt.h>
>>>  #include <fdt_support.h>
>>>  #include <phy.h>
>>> @@ -105,6 +106,11 @@ remove_psci_node:
>>>
>>>  	fdt_add_mem_rsv(blob, (uintptr_t)&secondary_boot_code,
>>>  			*boot_code_size);
>>> +#ifdef CONFIG_EFI_LOADER
>>> +	efi_add_memory_map((uintptr_t)&secondary_boot_code,
>>> +			   ALIGN(*boot_code_size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT,
>>> +			   EFI_RESERVED_MEMORY_TYPE, false);
>>> +#endif
>>>  }
>>>  #endif
>>>
>>>
>> Alex,
>>
>> Does it make more sense to use __spin_table instead of
>> secondary_boot_code (even they happen to have the same value here)?
>
> I'm reasonably indifferent, but I wanted to make sure we're using the
> same values as the fdt_add_mem_rsv() line above :).

OK, then.

York

[U-Boot] [PATCH v5 6/7] armv8: fsl-layerscape: Add support for efi_loader RTS reset

[Alexander Graf]

When implementing efi loader support, we can expose runtime services
for payloads. One such service is CPU reset.

This patch implements RTS CPU reset support for layerscape systems.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v4 -> v5:

  - Use __efi_runtime tags
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 33 +++++++++++++++++++++++++++++++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index b7a2e0c..0b516e3 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -17,6 +17,7 @@
 #ifdef CONFIG_MP
 #include <asm/arch/mp.h>
 #endif
+#include <efi_loader.h>
 #include <fm_eth.h>
 #include <fsl-mc/fsl_mc.h>
 #ifdef CONFIG_FSL_ESDHC
@@ -462,9 +463,10 @@ int timer_init(void)
 	return 0;
 }
 
-void reset_cpu(ulong addr)
+__efi_runtime_data u32 __iomem *rstcr = (u32 *)CONFIG_SYS_FSL_RST_ADDR;
+
+void __efi_runtime reset_cpu(ulong addr)
 {
-	u32 __iomem *rstcr = (u32 *)CONFIG_SYS_FSL_RST_ADDR;
 	u32 val;
 
 	/* Raise RESET_REQ_B */
@@ -473,6 +475,33 @@ void reset_cpu(ulong addr)
 	scfg_out32(rstcr, val);
 }
 
+#ifdef CONFIG_EFI_LOADER
+
+void __efi_runtime EFIAPI efi_reset_system(
+		       enum efi_reset_type reset_type,
+		       efi_status_t reset_status,
+		       unsigned long data_size, void *reset_data)
+{
+	switch (reset_type) {
+	case EFI_RESET_COLD:
+	case EFI_RESET_WARM:
+		reset_cpu(0);
+		break;
+	case EFI_RESET_SHUTDOWN:
+		/* Nothing we can do */
+		break;
+	}
+
+	while (1) { }
+}
+
+void efi_reset_system_init(void)
+{
+       efi_add_runtime_mmio(&rstcr, sizeof(*rstcr));
+}
+
+#endif
+
 phys_size_t board_reserve_ram_top(phys_size_t ram_size)
 {
 	phys_size_t ram_top = ram_size;
-- 
1.8.5.6

[U-Boot] [PATCH v5 6/7] armv8: fsl-layerscape: Add support for efi_loader RTS reset

[york sun]

On 10/15/2016 03:03 AM, Alexander Graf wrote:
> When implementing efi loader support, we can expose runtime services
> for payloads. One such service is CPU reset.
>
> This patch implements RTS CPU reset support for layerscape systems.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v4 -> v5:
>
>   - Use __efi_runtime tags
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 33 +++++++++++++++++++++++++++++++--
>  1 file changed, 31 insertions(+), 2 deletions(-)

Reviewed-by: York Sun <york.sun@nxp.com>

[U-Boot] [PATCH v5 7/7] efi_loader: Declare secure memory as reserved

[Alexander Graf]

Some systems may implemente TrustZone (EL3) in U-Boot. Those systems
reserve some memory that U-Boot is aware of as secure.

For those systems, mask out that secure memory in the EFI memory map,
as it's not usable from EL2 or EL1.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v4 -> v5:

  - Use gd->arch.secure_ram
---
 lib/efi_loader/efi_memory.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 95aa590..4966e48 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -474,5 +474,20 @@ int efi_memory_init(void)
 	efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
 #endif
 
+#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
+	/* Declare secure ram as reserved */
+        if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
+		uint64_t secure_start = gd->arch.secure_ram;
+		uint64_t secure_pages = CONFIG_SYS_MEM_RESERVE_SECURE;
+
+		secure_start &= MEM_RESERVE_SECURE_ADDR_MASK;
+		secure_start &= ~EFI_PAGE_MASK;
+		secure_pages = (secure_pages + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
+
+		efi_add_memory_map(secure_start, secure_pages,
+				   EFI_RESERVED_MEMORY_TYPE, false);
+        }
+#endif
+
 	return 0;
 }
-- 
1.8.5.6

[U-Boot] [PATCH v5 7/7] efi_loader: Declare secure memory as reserved

[york sun]

On 10/15/2016 03:03 AM, Alexander Graf wrote:
> Some systems may implemente TrustZone (EL3) in U-Boot. Those systems
> reserve some memory that U-Boot is aware of as secure.
>
> For those systems, mask out that secure memory in the EFI memory map,
> as it's not usable from EL2 or EL1.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v4 -> v5:
>
>   - Use gd->arch.secure_ram
> ---
>  lib/efi_loader/efi_memory.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 95aa590..4966e48 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -474,5 +474,20 @@ int efi_memory_init(void)
>  	efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
>  #endif
>
> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
> +	/* Declare secure ram as reserved */
> +        if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
> +		uint64_t secure_start = gd->arch.secure_ram;
> +		uint64_t secure_pages = CONFIG_SYS_MEM_RESERVE_SECURE;
> +
> +		secure_start &= MEM_RESERVE_SECURE_ADDR_MASK;
> +		secure_start &= ~EFI_PAGE_MASK;
> +		secure_pages = (secure_pages + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
> +
> +		efi_add_memory_map(secure_start, secure_pages,
> +				   EFI_RESERVED_MEMORY_TYPE, false);
> +        }
> +#endif
> +
>  	return 0;
>  }
>

Alex,

Do you see any issue without this patch? The secure memory is not 
visible to OS. gd->ram_size is reduced to hide the secure memory.

York

[U-Boot] [PATCH v5 7/7] efi_loader: Declare secure memory as reserved

[Alexander Graf]

On 15.10.16 18:58, york sun wrote:
> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>> Some systems may implemente TrustZone (EL3) in U-Boot. Those systems
>> reserve some memory that U-Boot is aware of as secure.
>>
>> For those systems, mask out that secure memory in the EFI memory map,
>> as it's not usable from EL2 or EL1.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>
>> ---
>>
>> v4 -> v5:
>>
>>   - Use gd->arch.secure_ram
>> ---
>>  lib/efi_loader/efi_memory.c | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>> index 95aa590..4966e48 100644
>> --- a/lib/efi_loader/efi_memory.c
>> +++ b/lib/efi_loader/efi_memory.c
>> @@ -474,5 +474,20 @@ int efi_memory_init(void)
>>  	efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
>>  #endif
>>
>> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
>> +	/* Declare secure ram as reserved */
>> +        if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
>> +		uint64_t secure_start = gd->arch.secure_ram;
>> +		uint64_t secure_pages = CONFIG_SYS_MEM_RESERVE_SECURE;
>> +
>> +		secure_start &= MEM_RESERVE_SECURE_ADDR_MASK;
>> +		secure_start &= ~EFI_PAGE_MASK;
>> +		secure_pages = (secure_pages + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
>> +
>> +		efi_add_memory_map(secure_start, secure_pages,
>> +				   EFI_RESERVED_MEMORY_TYPE, false);
>> +        }
>> +#endif
>> +
>>  	return 0;
>>  }
>>
> 
> Alex,
> 
> Do you see any issue without this patch? The secure memory is not 
> visible to OS. gd->ram_size is reduced to hide the secure memory.

We're building the memory map out of gd->bd->bi_dram rather than
ram_size, because it's perfectly reasonable for systems to have memory
holes.

So even if we're adjusting gd->ram_size, the OS will still see secure
memory. In fact, doesn't bootm do that as well?

arch/arm/lib/bootm-fdt.c:       ret = fdt_fixup_memory_banks(blob,
start, size, CONFIG_NR_DRAM_BANKS);

On armv7, arch_fixup_fdt() removes the secure memory region from the
edge of a memory bank. But on armv8 I don't see anything like it?


Alex

[U-Boot] [PATCH v5 7/7] efi_loader: Declare secure memory as reserved

[york sun]

On 10/17/2016 02:11 AM, Alexander Graf wrote:
>
>
> On 15.10.16 18:58, york sun wrote:
>> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>>> Some systems may implemente TrustZone (EL3) in U-Boot. Those systems
>>> reserve some memory that U-Boot is aware of as secure.
>>>
>>> For those systems, mask out that secure memory in the EFI memory map,
>>> as it's not usable from EL2 or EL1.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>
>>> ---
>>>
>>> v4 -> v5:
>>>
>>>   - Use gd->arch.secure_ram
>>> ---
>>>  lib/efi_loader/efi_memory.c | 15 +++++++++++++++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>>> index 95aa590..4966e48 100644
>>> --- a/lib/efi_loader/efi_memory.c
>>> +++ b/lib/efi_loader/efi_memory.c
>>> @@ -474,5 +474,20 @@ int efi_memory_init(void)
>>>  	efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
>>>  #endif
>>>
>>> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
>>> +	/* Declare secure ram as reserved */
>>> +        if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
>>> +		uint64_t secure_start = gd->arch.secure_ram;
>>> +		uint64_t secure_pages = CONFIG_SYS_MEM_RESERVE_SECURE;
>>> +
>>> +		secure_start &= MEM_RESERVE_SECURE_ADDR_MASK;
>>> +		secure_start &= ~EFI_PAGE_MASK;
>>> +		secure_pages = (secure_pages + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
>>> +
>>> +		efi_add_memory_map(secure_start, secure_pages,
>>> +				   EFI_RESERVED_MEMORY_TYPE, false);
>>> +        }
>>> +#endif
>>> +
>>>  	return 0;
>>>  }
>>>
>>
>> Alex,
>>
>> Do you see any issue without this patch? The secure memory is not
>> visible to OS. gd->ram_size is reduced to hide the secure memory.
>
> We're building the memory map out of gd->bd->bi_dram rather than
> ram_size, because it's perfectly reasonable for systems to have memory
> holes.
>
> So even if we're adjusting gd->ram_size, the OS will still see secure
> memory. In fact, doesn't bootm do that as well?
>
> arch/arm/lib/bootm-fdt.c:       ret = fdt_fixup_memory_banks(blob,
> start, size, CONFIG_NR_DRAM_BANKS);
>
> On armv7, arch_fixup_fdt() removes the secure memory region from the
> edge of a memory bank. But on armv8 I don't see anything like it?
>

Alex,

For ARMv8, our SoCs have several regions. Depends on the board 
implementation, the memory may end up in different banks. See 
board/freescale/ls2080ardb/ddr.c for example. The secure ram is already 
carved out.

York

[U-Boot] [PATCH v5 7/7] efi_loader: Declare secure memory as reserved

[Alexander Graf]

On 18/10/2016 17:46, york sun wrote:
> On 10/17/2016 02:11 AM, Alexander Graf wrote:
>>
>>
>> On 15.10.16 18:58, york sun wrote:
>>> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>>>> Some systems may implemente TrustZone (EL3) in U-Boot. Those systems
>>>> reserve some memory that U-Boot is aware of as secure.
>>>>
>>>> For those systems, mask out that secure memory in the EFI memory map,
>>>> as it's not usable from EL2 or EL1.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>
>>>> ---
>>>>
>>>> v4 -> v5:
>>>>
>>>>   - Use gd->arch.secure_ram
>>>> ---
>>>>  lib/efi_loader/efi_memory.c | 15 +++++++++++++++
>>>>  1 file changed, 15 insertions(+)
>>>>
>>>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>>>> index 95aa590..4966e48 100644
>>>> --- a/lib/efi_loader/efi_memory.c
>>>> +++ b/lib/efi_loader/efi_memory.c
>>>> @@ -474,5 +474,20 @@ int efi_memory_init(void)
>>>>  	efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
>>>>  #endif
>>>>
>>>> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
>>>> +	/* Declare secure ram as reserved */
>>>> +        if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
>>>> +		uint64_t secure_start = gd->arch.secure_ram;
>>>> +		uint64_t secure_pages = CONFIG_SYS_MEM_RESERVE_SECURE;
>>>> +
>>>> +		secure_start &= MEM_RESERVE_SECURE_ADDR_MASK;
>>>> +		secure_start &= ~EFI_PAGE_MASK;
>>>> +		secure_pages = (secure_pages + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
>>>> +
>>>> +		efi_add_memory_map(secure_start, secure_pages,
>>>> +				   EFI_RESERVED_MEMORY_TYPE, false);
>>>> +        }
>>>> +#endif
>>>> +
>>>>  	return 0;
>>>>  }
>>>>
>>>
>>> Alex,
>>>
>>> Do you see any issue without this patch? The secure memory is not
>>> visible to OS. gd->ram_size is reduced to hide the secure memory.
>>
>> We're building the memory map out of gd->bd->bi_dram rather than
>> ram_size, because it's perfectly reasonable for systems to have memory
>> holes.
>>
>> So even if we're adjusting gd->ram_size, the OS will still see secure
>> memory. In fact, doesn't bootm do that as well?
>>
>> arch/arm/lib/bootm-fdt.c:       ret = fdt_fixup_memory_banks(blob,
>> start, size, CONFIG_NR_DRAM_BANKS);
>>
>> On armv7, arch_fixup_fdt() removes the secure memory region from the
>> edge of a memory bank. But on armv8 I don't see anything like it?
>>
> 
> Alex,
> 
> For ARMv8, our SoCs have several regions. Depends on the board 
> implementation, the memory may end up in different banks. See 
> board/freescale/ls2080ardb/ddr.c for example. The secure ram is already 
> carved out.

Ok, I think you're right. I'll remove this patch. See below for
"lsefimmap" output from grub2 with and without the patch applied.


Alex


With patch:

Type      Physical start  - end             #Pages        Size Attributes
MMIO      0000000001e60000-0000000001e60fff 00000001      4KiB RT
conv-mem  0000000080000000-0000000087ffffff 00008000    128MiB WB
BS-data   0000000088000000-0000000088003fff 00000004     16KiB WB
conv-mem  0000000088006000-00000000fab33fff 00072b2e 1879224KiB WB
RT-data   00000000fab34000-00000000fab34fff 00000001      4KiB RT WB
ldr-data  00000000fab35000-00000000fad0dfff 000001d9   1892KiB WB
ldr-data  00000000fad0e000-00000000fed0dfff 00004000     64MiB WB
ldr-data  00000000fed0e000-00000000fff14fff 00001207  18460KiB WB
reserved  00000000fff156b0-00000000fff166af 00000001      4KiB WB
ldr-data  00000000fff166b0-00000000fffa46af 0000008e    568KiB WB
RT-code   00000000fffa5000-00000000fffa5fff 00000001      4KiB RT WB
ldr-data  00000000fffa6000-00000000ffffffff 0000005a    360KiB WB
reserved  0000006000000000-00000060ffffffff 00100000      4GiB WB
conv-mem  0000008080000000-000000835bff9fff 002dbffa 11993064KiB WB
ldr-data  000000835bffa000-00000083bfff9fff 00064000   1600MiB WB
conv-mem  00000083bfffa000-00000083bfffffff 00000006     24KiB WB
reserved  00000083ffe00000-00000083ffffffff 00000200      2MiB WB

Without patch:

Type      Physical start  - end             #Pages        Size Attributes
MMIO      0000000001e60000-0000000001e60fff 00000001      4KiB RT
conv-mem  0000000080000000-0000000087ffffff 00008000    128MiB WB
BS-data   0000000088000000-0000000088003fff 00000004     16KiB WB
conv-mem  0000000088006000-00000000fab34fff 00072b2f 1879228KiB WB
RT-data   00000000fab35000-00000000fab35fff 00000001      4KiB RT WB
ldr-data  00000000fab36000-00000000fad0efff 000001d9   1892KiB WB
ldr-data  00000000fad0f000-00000000fed0efff 00004000     64MiB WB
ldr-data  00000000fed0f000-00000000fff15fff 00001207  18460KiB WB
reserved  00000000fff166b0-00000000fff176af 00000001      4KiB WB
ldr-data  00000000fff176b0-00000000fffa46af 0000008d    564KiB WB
RT-code   00000000fffa5000-00000000fffa5fff 00000001      4KiB RT WB
ldr-data  00000000fffa6000-00000000ffffffff 0000005a    360KiB WB
reserved  0000006000000000-00000060ffffffff 00100000      4GiB WB
conv-mem  0000008080000000-000000835bff9fff 002dbffa 11993064KiB WB
ldr-data  000000835bffa000-00000083bfff9fff 00064000   1600MiB WB
conv-mem  00000083bfffa000-00000083bfffffff 00000006     24KiB WB