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

[U-Boot] [PATCH 0/5] 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.

Alexander Graf (5):
  ls2080: Exit dpaa only right before exiting U-Boot
  ls2080: Disable dcache during ddr init
  efi_loader: AArch64: Run EFI payloads in EL2 if U-Boot runs in EL3
  ls2080ardb: Reserve DP-DDR RAM
  ls2080ardb: Convert to distro boot

 arch/arm/include/asm/armv8/mmu.h        | 19 ++++++++++++-------
 arch/arm/lib/bootm.c                    | 11 +++++++++++
 board/freescale/ls2080a/ddr.c           |  2 ++
 board/freescale/ls2080a/ls2080a.c       |  1 -
 board/freescale/ls2080aqds/ddr.c        |  2 ++
 board/freescale/ls2080aqds/ls2080aqds.c |  4 ----
 board/freescale/ls2080ardb/ddr.c        |  2 ++
 board/freescale/ls2080ardb/ls2080ardb.c | 13 +++++++++----
 cmd/bootefi.c                           | 11 +++++++++++
 drivers/net/fsl-mc/mc.c                 | 22 ++++++++++++++++++++--
 include/configs/ls2080ardb.h            | 24 +++++++++++++++++++++++-
 lib/efi_loader/efi_boottime.c           | 10 ++++++++++
 12 files changed, 102 insertions(+), 19 deletions(-)

-- 
1.8.5.6

[U-Boot] [PATCH 1/5] 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>
---
 arch/arm/lib/bootm.c                    | 11 +++++++++++
 board/freescale/ls2080a/ls2080a.c       |  1 -
 board/freescale/ls2080aqds/ls2080aqds.c |  4 ----
 board/freescale/ls2080ardb/ls2080ardb.c |  4 ----
 drivers/net/fsl-mc/mc.c                 | 22 ++++++++++++++++++++--
 lib/efi_loader/efi_boottime.c           | 10 ++++++++++
 6 files changed, 41 insertions(+), 11 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 0838d89..95037c1 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -30,6 +30,11 @@
 #include <asm/armv7.h>
 #endif
 
+#ifdef CONFIG_FSL_MC_ENET
+#include <fsl-mc/fsl_mc.h>
+#include <fsl-mc/fsl_mc_private.h>
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 static struct tag *params;
@@ -84,6 +89,12 @@ static void announce_and_cleanup(int fake)
 #ifdef CONFIG_USB_DEVICE
 	udc_disconnect();
 #endif
+
+#ifdef CONFIG_FSL_MC_ENET
+	if (!fsl_mc_ldpaa_exit(NULL))
+		mc_apply_dpl(0);
+#endif
+
 	cleanup_before_linux();
 }
 
diff --git a/board/freescale/ls2080a/ls2080a.c b/board/freescale/ls2080a/ls2080a.c
index 00337d7..ca2bcfc 100644
--- a/board/freescale/ls2080a/ls2080a.c
+++ b/board/freescale/ls2080a/ls2080a.c
@@ -127,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 b3bd40a..a8620f7 100644
--- a/board/freescale/ls2080aqds/ls2080aqds.c
+++ b/board/freescale/ls2080aqds/ls2080aqds.c
@@ -282,7 +282,6 @@ void fdt_fixup_board_enet(void *fdt)
 #ifdef CONFIG_OF_BOARD_SETUP
 int ft_board_setup(void *blob, bd_t *bd)
 {
-	int err;
 	u64 base[CONFIG_NR_DRAM_BANKS];
 	u64 size[CONFIG_NR_DRAM_BANKS];
 
@@ -298,9 +297,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 fb39af6..0cc67c1 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -261,7 +261,6 @@ void fdt_fixup_board_enet(void *fdt)
 #ifdef CONFIG_OF_BOARD_SETUP
 int ft_board_setup(void *blob, bd_t *bd)
 {
-	int err;
 	u64 base[CONFIG_NR_DRAM_BANKS];
 	u64 size[CONFIG_NR_DRAM_BANKS];
 
@@ -277,9 +276,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..d0f5e02 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,12 @@ 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)
+		mc_dpl_addr = mc_lazy_dpl_addr;
+
+	if (!mc_dpl_addr)
+		return -1;
+
 	error = load_mc_dpl(mc_ram_addr, mc_ram_size, mc_dpl_addr);
 	if (error != 0)
 		return error;
@@ -1259,6 +1266,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 +1287,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 +1315,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 9daca50..0aff793 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -18,6 +18,11 @@
 #include <inttypes.h>
 #include <watchdog.h>
 
+#ifdef CONFIG_FSL_MC_ENET
+#include <fsl-mc/fsl_mc.h>
+#include <fsl-mc/fsl_mc_private.h>
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /* This list contains all the EFI objects our payload has access to */
@@ -516,6 +521,11 @@ static efi_status_t EFIAPI efi_exit_boot_services(void *image_handle,
 {
 	EFI_ENTRY("%p, %ld", image_handle, map_key);
 
+#ifdef CONFIG_FSL_MC_ENET
+	if (!fsl_mc_ldpaa_exit(NULL))
+		mc_apply_dpl(0);
+#endif
+
 	/* Fix up caches for EFI payloads if necessary */
 	efi_exit_caches();
 
-- 
1.8.5.6

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

[Prabhakar Kushwaha]

> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
> Alexander Graf
> Sent: Friday, May 13, 2016 5:52 PM
> To: u-boot at lists.denx.de
> Subject: [U-Boot] [PATCH 1/5] 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>

With this patch.

If I does not apply MC,  I am getting following crash:-

Starting kernel ...

"Synchronous Abort" handler, esr 0x96000044
ELR:     fff4666c
LR:      fff46cc4
x0 : d51ec00010004000 x1 : 00000000ffcf9fc0
x2 : 0000000000000001 x3 : d51ec00010004000
x4 : 00000000d51ec000 x5 : 0000000000000000
x6 : 0000000000000000 x7 : 000000009fffccc7
x8 : 000000009fffd080 x9 : 000000000000000c
x10: 0000000000000003 x11: 00000000ffcf9cd8
x12: 00000000fff6cc40 x13: 00000000ffcf90e0
x14: 0000000100000000 x15: 000000009ffff9a3
x16: 00000000ffd0ad40 x17: 00000000ffd0b630
x18: 00000000ffcfbd78 x19: 0000000000000000
x20: 00000000fffba000 x21: 00000000fffba520
x22: 00000000fffba528 x23: 0000000000000000
x24: 0000000000000000 x25: 00000000ffd03878
x26: 00000000fff8fb40 x27: 0000000000000000
x28: 00000000a00000e0 x29: 00000000ffcf9f70

Resetting CPU ...

### ERROR ### Please RESET the board ###



If I apply this patch.  MC timeout happens

Starting kernel ...

Error: Timeout waiting for MC response
dpbp_open() failed: -110
dpbp_exit() failed: -110
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu


--prabhakar

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

[Alexander Graf]

On 05/18/2016 02:29 PM, Prabhakar Kushwaha wrote:
>> -----Original Message-----
>> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
>> Alexander Graf
>> Sent: Friday, May 13, 2016 5:52 PM
>> To: u-boot at lists.denx.de
>> Subject: [U-Boot] [PATCH 1/5] 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>
> With this patch.
>
> If I does not apply MC,  I am getting following crash:-
>
> Starting kernel ...
>
> "Synchronous Abort" handler, esr 0x96000044

So should we consider it a bug fix or regression then? :)


Alex

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

[Prabhakar Kushwaha]

Hi Alex,

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Friday, May 27, 2016 7:58 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> boot at lists.denx.de
> Cc: york sun <york.sun@nxp.com>
> Subject: Re: [U-Boot] [PATCH 1/5] ls2080: Exit dpaa only right before exiting
> U-Boot
> 
> On 05/18/2016 02:29 PM, Prabhakar Kushwaha wrote:
> >> -----Original Message-----
> >> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
> >> Alexander Graf
> >> Sent: Friday, May 13, 2016 5:52 PM
> >> To: u-boot at lists.denx.de
> >> Subject: [U-Boot] [PATCH 1/5] 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>
> > With this patch.
> >
> > If I does not apply MC,  I am getting following crash:-
> >
> > Starting kernel ...
> >
> > "Synchronous Abort" handler, esr 0x96000044
> 
> So should we consider it a bug fix or regression then? :)
> 
> 

Are you planning to fix it?

If not let me know I will try to  work on it. 

--prabhakar

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

[Alexander Graf]

On 07.06.16 03:28, Prabhakar Kushwaha wrote:
> Hi Alex,
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Friday, May 27, 2016 7:58 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>> boot at lists.denx.de
>> Cc: york sun <york.sun@nxp.com>
>> Subject: Re: [U-Boot] [PATCH 1/5] ls2080: Exit dpaa only right before exiting
>> U-Boot
>>
>> On 05/18/2016 02:29 PM, Prabhakar Kushwaha wrote:
>>>> -----Original Message-----
>>>> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
>>>> Alexander Graf
>>>> Sent: Friday, May 13, 2016 5:52 PM
>>>> To: u-boot at lists.denx.de
>>>> Subject: [U-Boot] [PATCH 1/5] 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>
>>> With this patch.
>>>
>>> If I does not apply MC,  I am getting following crash:-
>>>
>>> Starting kernel ...
>>>
>>> "Synchronous Abort" handler, esr 0x96000044
>>
>> So should we consider it a bug fix or regression then? :)
>>
>>
> 
> Are you planning to fix it?
> 
> If not let me know I will try to  work on it. 

The checks that determine whether we really want to exit ldpaa only work
if the argument to the function is non-NULL.

Can you please check if the patch below fixes it for you?


Alex

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 95037c1..233c94f 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -91,7 +91,7 @@ static void announce_and_cleanup(int fake)
 #endif

 #ifdef CONFIG_FSL_MC_ENET
-	if (!fsl_mc_ldpaa_exit(NULL))
+	if (!fsl_mc_ldpaa_exit(gd->bd))
 		mc_apply_dpl(0);
 #endif

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 8d3943f..c1209b0 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -529,7 +529,7 @@ static efi_status_t EFIAPI
efi_exit_boot_services(void *image_handle,
 	EFI_ENTRY("%p, %ld", image_handle, map_key);

 #ifdef CONFIG_FSL_MC_ENET
-	if (!fsl_mc_ldpaa_exit(NULL))
+	if (!fsl_mc_ldpaa_exit(gd->bd))
 		mc_apply_dpl(0);
 #endif

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

[Alexander Graf]

On 07.06.16 03:28, Prabhakar Kushwaha wrote:
> Hi Alex,
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Friday, May 27, 2016 7:58 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>> boot at lists.denx.de
>> Cc: york sun <york.sun@nxp.com>
>> Subject: Re: [U-Boot] [PATCH 1/5] ls2080: Exit dpaa only right before exiting
>> U-Boot
>>
>> On 05/18/2016 02:29 PM, Prabhakar Kushwaha wrote:
>>>> -----Original Message-----
>>>> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
>>>> Alexander Graf
>>>> Sent: Friday, May 13, 2016 5:52 PM
>>>> To: u-boot at lists.denx.de
>>>> Subject: [U-Boot] [PATCH 1/5] 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>
>>> With this patch.
>>>
>>> If I does not apply MC,  I am getting following crash:-
>>>
>>> Starting kernel ...
>>>
>>> "Synchronous Abort" handler, esr 0x96000044
>>
>> So should we consider it a bug fix or regression then? :)
>>
>>
> 
> Are you planning to fix it?
> 
> If not let me know I will try to  work on it. 

Sorry, wrong fix. Please try this one instead.

Alex


diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 95037c1..c5e6bbd 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -91,7 +91,7 @@ static void announce_and_cleanup(int fake)
 #endif

 #ifdef CONFIG_FSL_MC_ENET
-	if (!fsl_mc_ldpaa_exit(NULL))
+	if (mc_lazy_dpl_addr && !fsl_mc_ldpaa_exit(NULL))
 		mc_apply_dpl(0);
 #endif

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index d0f5e02..4d2d8a7 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -40,7 +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;
+u64 mc_lazy_dpl_addr;

 #ifdef DEBUG
 void dump_ram_words(const char *title, void *addr)
diff --git a/include/fsl-mc/fsl_mc.h b/include/fsl-mc/fsl_mc.h
index ffe6da5..16d7af8 100644
--- a/include/fsl-mc/fsl_mc.h
+++ b/include/fsl-mc/fsl_mc.h
@@ -61,4 +61,6 @@ u64 mc_get_dram_addr(void);
 unsigned long mc_get_dram_block_size(void);
 int fsl_mc_ldpaa_init(bd_t *bis);
 int fsl_mc_ldpaa_exit(bd_t *bd);
+
+extern u64 mc_lazy_dpl_addr;
 #endif
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 8d3943f..bda2a84 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -529,7 +529,7 @@ static efi_status_t EFIAPI
efi_exit_boot_services(void *image_handle,
 	EFI_ENTRY("%p, %ld", image_handle, map_key);

 #ifdef CONFIG_FSL_MC_ENET
-	if (!fsl_mc_ldpaa_exit(NULL))
+	if (mc_lazy_dpl_addr && !fsl_mc_ldpaa_exit(NULL))
 		mc_apply_dpl(0);
 #endif

[U-Boot] [PATCH 2/5] ls2080: Disable dcache during ddr init

[Alexander Graf]

While trying something completely different I saw the DDR probe hang on
boot reliably depending on how big my code ended up. Adding simple "nop"
instructions in my code (completely unrelated) flow made the DDR probe
work again.

So we're accessing some RAM - probably the page table - and rely on the
cache to give us a correct view of the world while DRAM gets initialized.

This patch just disables dcache while we're initializing the memory controller,
resolving all system hangs for me so far.

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

---

I guess the "real" solution would be to find out what exactly gets accessed in
such a case and then just map whatever it is into SRAM. Or maybe qixis_reset
doesn't fully reset something in the cache tolopogy and that wants to get
flushed out when we don't have ram yet? I don't know...
---
 board/freescale/ls2080a/ddr.c    | 2 ++
 board/freescale/ls2080aqds/ddr.c | 2 ++
 board/freescale/ls2080ardb/ddr.c | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/board/freescale/ls2080a/ddr.c b/board/freescale/ls2080a/ddr.c
index 1827ddc..a02aa64 100644
--- a/board/freescale/ls2080a/ddr.c
+++ b/board/freescale/ls2080a/ddr.c
@@ -165,7 +165,9 @@ phys_size_t initdram(int board_type)
 	puts("Initializing DDR....");
 
 	puts("using SPD\n");
+	dcache_disable();
 	dram_size = fsl_ddr_sdram();
+	set_sctlr(get_sctlr() | (CR_C|CR_M));
 
 	return dram_size;
 }
diff --git a/board/freescale/ls2080aqds/ddr.c b/board/freescale/ls2080aqds/ddr.c
index fcb0366..99f4736 100644
--- a/board/freescale/ls2080aqds/ddr.c
+++ b/board/freescale/ls2080aqds/ddr.c
@@ -164,7 +164,9 @@ phys_size_t initdram(int board_type)
 #else
 	puts("Initializing DDR....using SPD\n");
 
+	dcache_disable();
 	dram_size = fsl_ddr_sdram();
+	set_sctlr(get_sctlr() | (CR_C|CR_M));
 #endif
 
 	return dram_size;
diff --git a/board/freescale/ls2080ardb/ddr.c b/board/freescale/ls2080ardb/ddr.c
index a04d21b..7160d97 100644
--- a/board/freescale/ls2080ardb/ddr.c
+++ b/board/freescale/ls2080ardb/ddr.c
@@ -164,7 +164,9 @@ phys_size_t initdram(int board_type)
 #else
 	puts("Initializing DDR....using SPD\n");
 
+	dcache_disable();
 	dram_size = fsl_ddr_sdram();
+	set_sctlr(get_sctlr() | (CR_C|CR_M));
 #endif
 
 	return dram_size;
-- 
1.8.5.6

[U-Boot] [PATCH 2/5] ls2080: Disable dcache during ddr init

[York Sun]

On 05/13/2016 05:21 AM, Alexander Graf wrote:
> While trying something completely different I saw the DDR probe hang on
> boot reliably depending on how big my code ended up. Adding simple "nop"
> instructions in my code (completely unrelated) flow made the DDR probe
> work again.
> 
> So we're accessing some RAM - probably the page table - and rely on the
> cache to give us a correct view of the world while DRAM gets initialized.
> 
> This patch just disables dcache while we're initializing the memory controller,
> resolving all system hangs for me so far.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> 
> ---
> 
> I guess the "real" solution would be to find out what exactly gets accessed in
> such a case and then just map whatever it is into SRAM. Or maybe qixis_reset
> doesn't fully reset something in the cache tolopogy and that wants to get
> flushed out when we don't have ram yet? I don't know...
> ---
>  board/freescale/ls2080a/ddr.c    | 2 ++
>  board/freescale/ls2080aqds/ddr.c | 2 ++
>  board/freescale/ls2080ardb/ddr.c | 2 ++
>  3 files changed, 6 insertions(+)
> 
> diff --git a/board/freescale/ls2080a/ddr.c b/board/freescale/ls2080a/ddr.c
> index 1827ddc..a02aa64 100644
> --- a/board/freescale/ls2080a/ddr.c
> +++ b/board/freescale/ls2080a/ddr.c
> @@ -165,7 +165,9 @@ phys_size_t initdram(int board_type)
>  	puts("Initializing DDR....");
>  
>  	puts("using SPD\n");
> +	dcache_disable();
>  	dram_size = fsl_ddr_sdram();
> +	set_sctlr(get_sctlr() | (CR_C|CR_M));

Alex,

I can't agree with the proposed change. Having dcache has major speed boost
during initializing, especially when we run it on an emulator. As you suggested
in the note, the root cause needs to be identified. Qixis_reset has nothing to
do with cache. It is a board-level FPGA control.

York

[U-Boot] [PATCH 2/5] ls2080: Disable dcache during ddr init

[Alexander Graf]

On 13.05.16 18:28, York Sun wrote:
> On 05/13/2016 05:21 AM, Alexander Graf wrote:
>> While trying something completely different I saw the DDR probe hang on
>> boot reliably depending on how big my code ended up. Adding simple "nop"
>> instructions in my code (completely unrelated) flow made the DDR probe
>> work again.
>>
>> So we're accessing some RAM - probably the page table - and rely on the
>> cache to give us a correct view of the world while DRAM gets initialized.
>>
>> This patch just disables dcache while we're initializing the memory controller,
>> resolving all system hangs for me so far.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>
>> ---
>>
>> I guess the "real" solution would be to find out what exactly gets accessed in
>> such a case and then just map whatever it is into SRAM. Or maybe qixis_reset
>> doesn't fully reset something in the cache tolopogy and that wants to get
>> flushed out when we don't have ram yet? I don't know...
>> ---
>>  board/freescale/ls2080a/ddr.c    | 2 ++
>>  board/freescale/ls2080aqds/ddr.c | 2 ++
>>  board/freescale/ls2080ardb/ddr.c | 2 ++
>>  3 files changed, 6 insertions(+)
>>
>> diff --git a/board/freescale/ls2080a/ddr.c b/board/freescale/ls2080a/ddr.c
>> index 1827ddc..a02aa64 100644
>> --- a/board/freescale/ls2080a/ddr.c
>> +++ b/board/freescale/ls2080a/ddr.c
>> @@ -165,7 +165,9 @@ phys_size_t initdram(int board_type)
>>  	puts("Initializing DDR....");
>>  
>>  	puts("using SPD\n");
>> +	dcache_disable();
>>  	dram_size = fsl_ddr_sdram();
>> +	set_sctlr(get_sctlr() | (CR_C|CR_M));
> 
> Alex,
> 
> I can't agree with the proposed change. Having dcache has major speed boost
> during initializing, especially when we run it on an emulator. As you suggested
> in the note, the root cause needs to be identified. Qixis_reset has nothing to
> do with cache. It is a board-level FPGA control.

Yes, this patch is mostly FYI. I'm more than happy to not have it
applied - FWIW it's sheer luck that my compiler happened to emit the
instructions in the right place for things to work without any of the
other patches ;). So we might as well rely on luck with the others applied.


Alex

[U-Boot] [PATCH 2/5] ls2080: Disable dcache during ddr init

[Prabhakar Kushwaha]

Hi Alex,


> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of
> Alexander Graf
> Sent: Friday, May 13, 2016 5:52 PM
> To: u-boot at lists.denx.de
> Subject: [U-Boot] [PATCH 2/5] ls2080: Disable dcache during ddr init
> 
> While trying something completely different I saw the DDR probe hang on
> boot reliably depending on how big my code ended up. Adding simple "nop"
> instructions in my code (completely unrelated) flow made the DDR probe
> work again.
> 
> So we're accessing some RAM - probably the page table - and rely on the
> cache to give us a correct view of the world while DRAM gets initialized.
> 
> This patch just disables dcache while we're initializing the memory controller,
> resolving all system hangs for me so far.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> 

While testing Linux with your patch set, I found Linux boot crashing. 

I tried git-bisect and find out this patch is creating problem
It is very strange!!

--prabhakar


[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 4.1.8+ (prabhu_kush at OptiPlex-790) (gcc version 4.8.3 20131202 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.12 - Linaro GCC 2013.11) ) #1 SMP PREEMPT Wed May 18 17:10:46 IST 2016
[    0.000000] CPU: AArch64 Processor [411fd071] revision 1
[    0.000000] Detected PIPT I-cache on CPU0
[    0.000000] alternatives: enabling workaround for ARM erratum 832075
[    0.000000] alternatives: enabling workaround for ARM erratum 834220
[    0.000000] earlycon: Early serial console at MMIO 0x21c0600 (options '')
[    0.000000] bootconsole [uart0] enabled
[    0.000000] Bad mode in Error handler detected, code 0xbf000000 -- SError
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.8+ #1
[    0.000000] Hardware name: Freescale Layerscape 2080a RDB Board (DT)
[    0.000000] task: ffff800000b38fc0 ti: ffff800000b2c000 task.ti: ffff800000b2c000
[    0.000000] PC is at setup_arch+0x294/0x5cc
[    0.000000] LR is at setup_arch+0x290/0x5cc
[    0.000000] pc : [<ffff800000aa8610>] lr : [<ffff800000aa860c>] pstate: 000002c5
[    0.000000] sp : ffff800000b2ff30
[    0.000000] x29: ffff800000b2ff30 x28: 00000000a00000e0
[    0.000000] x27: ffff800000081210 x26: 0000000080c70000
[    0.000000] x25: 0000000080c6d000 x24: 0000000080000000
[    0.000000] x23: ffff800000b32000 x22: 0000000000000000
[    0.000000] x21: ffff800000b2ffe8 x20: ffff800000b32000
[    0.000000] x19: ffff800000080000 x18: 0000000001002222
[    0.000000] x17: 0000000000000000 x16: 0000000003010066
[    0.000000] x15: ffffffffffffffff x14: 0ffffffffffffffe
[    0.000000] x13: 0000000000000020 x12: 0000000000000008
[    0.000000] x11: 0000000000000004 x10: 0101010101010101
[    0.000000] x9 : fefefefefefefeff x8 : 7f7f7f7f7f7f7f7f
[    0.000000] x7 : 6466606f64667467 x6 : 0b1a09161f0d0265
[    0.000000] x5 : 65020d1f16091a0b x4 : 0000000000000000
[    0.000000] x3 : 36f6e736f6c65000 x2 : 0000000000000087
[    0.000000] x1 : 0000000000000000 x0 : 0000000000000001
[    0.000000]
[    0.000000] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.8+ #1
[    0.000000] Hardware name: Freescale Layerscape 2080a RDB Board (DT)
[    0.000000] task: ffff800000b38fc0 ti: ffff800000b2c000 task.ti: ffff800000b2c000
[    0.000000] PC is at setup_arch+0x294/0x5cc
[    0.000000] LR is at setup_arch+0x290/0x5cc
[    0.000000] pc : [<ffff800000aa8610>] lr : [<ffff800000aa860c>] pstate: 000002c5
[    0.000000] sp : ffff800000b2ff30
[    0.000000] x29: ffff800000b2ff30 x28: 00000000a00000e0
[    0.000000] x27: ffff800000081210 x26: 0000000080c70000
[    0.000000] x25: 0000000080c6d000 x24: 0000000080000000
[    0.000000] x23: ffff800000b32000 x22: 0000000000000000
[    0.000000] x21: ffff800000b2ffe8 x20: ffff800000b32000
[    0.000000] x19: ffff800000080000 x18: 0000000001002222
[    0.000000] x17: 0000000000000000 x16: 0000000003010066
[    0.000000] x15: ffffffffffffffff x14: 0ffffffffffffffe
[    0.000000] x13: 0000000000000020 x12: 0000000000000008
[    0.000000] x11: 0000000000000004 x10: 0101010101010101
[    0.000000] x9 : fefefefefefefeff x8 : 7f7f7f7f7f7f7f7f
[    0.000000] x7 : 6466606f64667467 x6 : 0b1a09161f0d0265
[    0.000000] x5 : 65020d1f16091a0b x4 : 0000000000000000
[    0.000000] x3 : 36f6e736f6c65000 x2 : 0000000000000087
[    0.000000] x1 : 0000000000000000 x0 : 0000000000000001
[    0.000000]
[    0.000000] Process swapper (pid: 0, stack limit = 0xffff800000b2c020)
[    0.000000] Stack: (0xffff800000b2ff30 to 0xffff800000b30000)
[    0.000000] ff20:                                     00b2ffa0 ffff8000 00aa5684 ffff8000
[    0.000000] ff40: 00000001 00000000 00adfb20 ffff8000 9fff9000 00000000 00000000 00000000
[    0.000000] ff60: 00b32000 ffff8000 80000000 00000000 80c6d000 00000000 80c70000 00000000
[    0.000000] ff80: ffffffff ffffffff 00000000 00000000 00000080 00000000 fefefefe fefefefe
[    0.000000] ffa0: 00000000 00000000 800826a0 00000000 fff9e7c0 00000000 00000e12 00000000
[    0.000000] ffc0: 9fff9000 00000000 00000000 00000000 00000000 00000000 80000000 00000000
[    0.000000] ffe0: 00000000 00000000 00ae0348 ffff8000 00000000 00000000 00000000 00000000
[    0.000000] Call trace:
[    0.000000] [<ffff800000aa8610>] setup_arch+0x294/0x5cc
[    0.000000] [<ffff800000aa5680>] start_kernel+0x94/0x3bc
[    0.000000] Code: 940009db 94000957 97fff3e4 d50344ff (9400066f)
[    0.000000] ---[ end trace cb88537fdc8fa200 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

[U-Boot] [PATCH 3/5] 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>
---
 arch/arm/include/asm/armv8/mmu.h | 19 ++++++++++++-------
 cmd/bootefi.c                    | 11 +++++++++++
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index 0d08ed3..876a2b2 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -116,19 +116,24 @@
 static inline void set_ttbr_tcr_mair(int el, u64 table, u64 tcr, u64 attr)
 {
 	asm volatile("dsb sy");
-	if (el == 1) {
+	switch (el) {
+	case 1:
 		asm volatile("msr ttbr0_el1, %0" : : "r" (table) : "memory");
 		asm volatile("msr tcr_el1, %0" : : "r" (tcr) : "memory");
 		asm volatile("msr mair_el1, %0" : : "r" (attr) : "memory");
-	} else if (el == 2) {
-		asm volatile("msr ttbr0_el2, %0" : : "r" (table) : "memory");
-		asm volatile("msr tcr_el2, %0" : : "r" (tcr) : "memory");
-		asm volatile("msr mair_el2, %0" : : "r" (attr) : "memory");
-	} else if (el == 3) {
+		break;
+	case 3:
 		asm volatile("msr ttbr0_el3, %0" : : "r" (table) : "memory");
 		asm volatile("msr tcr_el3, %0" : : "r" (tcr) : "memory");
 		asm volatile("msr mair_el3, %0" : : "r" (attr) : "memory");
-	} else {
+
+		/* We may switch to EL2 later, so set those too; fall through */
+	case 2:
+		asm volatile("msr ttbr0_el2, %0" : : "r" (table) : "memory");
+		asm volatile("msr tcr_el2, %0" : : "r" (tcr) : "memory");
+		asm volatile("msr mair_el2, %0" : : "r" (attr) : "memory");
+		break;
+	default:
 		hang();
 	}
 	asm volatile("isb");
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index d3a2331..79dbd15 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -205,6 +205,17 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
 		loaded_image_info.device_handle = nethandle;
 #endif
 
+#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 */
+		set_sctlr(get_sctlr() | (CR_C|CR_M));
+	}
+#endif
+
 	/* Call our payload! */
 #ifdef DEBUG_EFI
 	printf("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry);
-- 
1.8.5.6

[U-Boot] [PATCH 4/5] 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 0cc67c1..33e8c99 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -16,6 +16,7 @@
 #include <fsl_debug_server.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>
@@ -198,6 +199,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 5/5] 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 converts the LS2080ARDB board to use that framework instead
of booting from a hard coded flash offset.

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

---

This obviously means that we can no longer boot from said offset. Is
that a reasonable thing to do or should I put the bootm back into the
default boot command and only do distro boot if it fails?
---
 include/configs/ls2080ardb.h | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 5bec509..6ee6c87 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -323,10 +323,25 @@ unsigned long get_board_sys_clk(void);
 #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS      2
 #define CONFIG_USB_STORAGE
 
+#undef CONFIG_CMDLINE_EDITING
+#undef CONFIG_BOOTDELAY
+#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"		\
@@ -336,8 +351,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 " \
@@ -345,6 +362,11 @@ unsigned long get_board_sys_clk(void);
 				"ramdisk_size=0x2000000 default_hugepagesz=2m" \
 				" hugepagesz=2m hugepages=256"
 
+#undef CONFIG_BOOTCOMMAND
+#define CONFIG_BOOTCOMMAND "run mcinitcmd && fsl_mc lazyapply dpl 0x580700000" \
+			   " && setenv ethact DPMAC5 at xgmii" \
+			   " && run distro_bootcmd"
+
 /* MAC/PHY configuration */
 #ifdef CONFIG_FSL_MC_ENET
 #define CONFIG_PHYLIB_10G
-- 
1.8.5.6

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Stuart Yoder]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Friday, May 13, 2016 7:22 AM
> To: u-boot at lists.denx.de
> Cc: Stuart Yoder <stuart.yoder@nxp.com>; york sun <york.sun@nxp.com>
> Subject: [PATCH 5/5] ls2080ardb: Convert to distro boot
> 
> 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 converts the LS2080ARDB board to use that framework instead
> of booting from a hard coded flash offset.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> 
> ---
> 
> This obviously means that we can no longer boot from said offset. Is
> that a reasonable thing to do or should I put the bootm back into the
> default boot command and only do distro boot if it fails?

To date all armv8 FSL/NXP sdk releases, field engineers, etc have been using
bootm.  I'm a little concerned about changing the default boot command
right now...as I assume things will unexpectedly appear to just stop
working.  Or, is booting from the NOR flash one of the distro boot
"media" types?

Stuart

> ---
>  include/configs/ls2080ardb.h | 24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
> index 5bec509..6ee6c87 100644
> --- a/include/configs/ls2080ardb.h
> +++ b/include/configs/ls2080ardb.h
> @@ -323,10 +323,25 @@ unsigned long get_board_sys_clk(void);
>  #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS      2
>  #define CONFIG_USB_STORAGE
> 
> +#undef CONFIG_CMDLINE_EDITING
> +#undef CONFIG_BOOTDELAY
> +#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"		\
> @@ -336,8 +351,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 " \
> @@ -345,6 +362,11 @@ unsigned long get_board_sys_clk(void);
>  				"ramdisk_size=0x2000000 default_hugepagesz=2m" \
>  				" hugepagesz=2m hugepages=256"
> 
> +#undef CONFIG_BOOTCOMMAND
> +#define CONFIG_BOOTCOMMAND "run mcinitcmd && fsl_mc lazyapply dpl 0x580700000" \
> +			   " && setenv ethact DPMAC5 at xgmii" \
> +			   " && run distro_bootcmd"
> +
>  /* MAC/PHY configuration */
>  #ifdef CONFIG_FSL_MC_ENET
>  #define CONFIG_PHYLIB_10G
> --
> 1.8.5.6

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Alexander Graf]

> Am 13.05.2016 um 16:26 schrieb Stuart Yoder <stuart.yoder@nxp.com>:
> 
> 
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Friday, May 13, 2016 7:22 AM
>> To: u-boot at lists.denx.de
>> Cc: Stuart Yoder <stuart.yoder@nxp.com>; york sun <york.sun@nxp.com>
>> Subject: [PATCH 5/5] ls2080ardb: Convert to distro boot
>> 
>> 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 converts the LS2080ARDB board to use that framework instead
>> of booting from a hard coded flash offset.
>> 
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> 
>> ---
>> 
>> This obviously means that we can no longer boot from said offset. Is
>> that a reasonable thing to do or should I put the bootm back into the
>> default boot command and only do distro boot if it fails?
> 
> To date all armv8 FSL/NXP sdk releases, field engineers, etc have been using
> bootm.  I'm a little concerned about changing the default boot command
> right now...as I assume things will unexpectedly appear to just stop
> working.  Or, is booting from the NOR flash one of the distro boot
> "media" types?

The problem with boot from NOR is that we have no source of information on what lies where. So distro boot can't have it in its target list, as you have to know magical offsets.

We could put the magical bootm after tge distro list, but that would mean that field engineers get pxe boot with long timeouts first and then their NOR bootm booted.

So the only option left that I can see is to always try magical offset NOR bootm and do distro boot if it fails. Then just tell people to write zeros to the NOR kernel offset and they get distro boot automatically.


Alex

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[York Sun]

On 05/13/2016 07:32 AM, Alexander Graf wrote:
> 
>> Am 13.05.2016 um 16:26 schrieb Stuart Yoder <stuart.yoder@nxp.com>:
>>
>>
>>
>>> -----Original Message-----
>>> From: Alexander Graf [mailto:agraf at suse.de]
>>> Sent: Friday, May 13, 2016 7:22 AM
>>> To: u-boot at lists.denx.de
>>> Cc: Stuart Yoder <stuart.yoder@nxp.com>; york sun <york.sun@nxp.com>
>>> Subject: [PATCH 5/5] ls2080ardb: Convert to distro boot
>>>
>>> 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 converts the LS2080ARDB board to use that framework instead
>>> of booting from a hard coded flash offset.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>
>>> ---
>>>
>>> This obviously means that we can no longer boot from said offset. Is
>>> that a reasonable thing to do or should I put the bootm back into the
>>> default boot command and only do distro boot if it fails?
>>
>> To date all armv8 FSL/NXP sdk releases, field engineers, etc have been using
>> bootm.  I'm a little concerned about changing the default boot command
>> right now...as I assume things will unexpectedly appear to just stop
>> working.  Or, is booting from the NOR flash one of the distro boot
>> "media" types?
> 
> The problem with boot from NOR is that we have no source of information on what lies where. So distro boot can't have it in its target list, as you have to know magical offsets.
> 
> We could put the magical bootm after tge distro list, but that would mean that field engineers get pxe boot with long timeouts first and then their NOR bootm booted.
> 
> So the only option left that I can see is to always try magical offset NOR bootm and do distro boot if it fails. Then just tell people to write zeros to the NOR kernel offset and they get distro boot automatically.
> 

Alex,

I suggest to attempt current boot method before moving on to other sources. I
presume booting from NOR would check the image header first. If the image is
valid, go ahead to boot it. Otherwise, move on.

Beside, it would be helpful to define a list and order of boot source.

York

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Alexander Graf]

> Am 13.05.2016 um 18:21 schrieb York Sun <york.sun@nxp.com>:
> 
>> On 05/13/2016 07:32 AM, Alexander Graf wrote:
>> 
>>> Am 13.05.2016 um 16:26 schrieb Stuart Yoder <stuart.yoder@nxp.com>:
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf at suse.de]
>>>> Sent: Friday, May 13, 2016 7:22 AM
>>>> To: u-boot at lists.denx.de
>>>> Cc: Stuart Yoder <stuart.yoder@nxp.com>; york sun <york.sun@nxp.com>
>>>> Subject: [PATCH 5/5] ls2080ardb: Convert to distro boot
>>>> 
>>>> 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 converts the LS2080ARDB board to use that framework instead
>>>> of booting from a hard coded flash offset.
>>>> 
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>> 
>>>> ---
>>>> 
>>>> This obviously means that we can no longer boot from said offset. Is
>>>> that a reasonable thing to do or should I put the bootm back into the
>>>> default boot command and only do distro boot if it fails?
>>> 
>>> To date all armv8 FSL/NXP sdk releases, field engineers, etc have been using
>>> bootm.  I'm a little concerned about changing the default boot command
>>> right now...as I assume things will unexpectedly appear to just stop
>>> working.  Or, is booting from the NOR flash one of the distro boot
>>> "media" types?
>> 
>> The problem with boot from NOR is that we have no source of information on what lies where. So distro boot can't have it in its target list, as you have to know magical offsets.
>> 
>> We could put the magical bootm after tge distro list, but that would mean that field engineers get pxe boot with long timeouts first and then their NOR bootm booted.
>> 
>> So the only option left that I can see is to always try magical offset NOR bootm and do distro boot if it fails. Then just tell people to write zeros to the NOR kernel offset and they get distro boot automatically.
> 
> Alex,
> 
> I suggest to attempt current boot method before moving on to other sources. I
> presume booting from NOR would check the image header first. If the image is
> valid, go ahead to boot it. Otherwise, move on.

Ok, will do.

> 
> Beside, it would be helpful to define a list and order of boot source.

That's what the patch does, no? See the BOOT_TARGET_DEVICES define. It's probably incomplete, but describes the boot order and boot sources.


Alex

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[York Sun]

On 05/13/2016 10:03 AM, Alexander Graf wrote:
> 
> 
>> Am 13.05.2016 um 18:21 schrieb York Sun <york.sun@nxp.com>:
>>
>>> On 05/13/2016 07:32 AM, Alexander Graf wrote:
>>>
>>>> Am 13.05.2016 um 16:26 schrieb Stuart Yoder <stuart.yoder@nxp.com>:
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Alexander Graf [mailto:agraf at suse.de]
>>>>> Sent: Friday, May 13, 2016 7:22 AM
>>>>> To: u-boot at lists.denx.de
>>>>> Cc: Stuart Yoder <stuart.yoder@nxp.com>; york sun <york.sun@nxp.com>
>>>>> Subject: [PATCH 5/5] ls2080ardb: Convert to distro boot
>>>>>
>>>>> 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 converts the LS2080ARDB board to use that framework instead
>>>>> of booting from a hard coded flash offset.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>
>>>>> ---
>>>>>
>>>>> This obviously means that we can no longer boot from said offset. Is
>>>>> that a reasonable thing to do or should I put the bootm back into the
>>>>> default boot command and only do distro boot if it fails?
>>>>
>>>> To date all armv8 FSL/NXP sdk releases, field engineers, etc have been using
>>>> bootm.  I'm a little concerned about changing the default boot command
>>>> right now...as I assume things will unexpectedly appear to just stop
>>>> working.  Or, is booting from the NOR flash one of the distro boot
>>>> "media" types?
>>>
>>> The problem with boot from NOR is that we have no source of information on what lies where. So distro boot can't have it in its target list, as you have to know magical offsets.
>>>
>>> We could put the magical bootm after tge distro list, but that would mean that field engineers get pxe boot with long timeouts first and then their NOR bootm booted.
>>>
>>> So the only option left that I can see is to always try magical offset NOR bootm and do distro boot if it fails. Then just tell people to write zeros to the NOR kernel offset and they get distro boot automatically.
>>
>> Alex,
>>
>> I suggest to attempt current boot method before moving on to other sources. I
>> presume booting from NOR would check the image header first. If the image is
>> valid, go ahead to boot it. Otherwise, move on.
> 
> Ok, will do.
> 
>>
>> Beside, it would be helpful to define a list and order of boot source.
> 
> That's what the patch does, no? See the BOOT_TARGET_DEVICES define. It's probably incomplete, but describes the boot order and boot sources.
> 

Yes I saw it. Would it be possible to use environmental variable for this
purpose, so users can specify the list and order? If it is too complicated, we
can live with the macro and recompile as needed.

York

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Alexander Graf]

On 13.05.16 19:05, York Sun wrote:
> On 05/13/2016 10:03 AM, Alexander Graf wrote:
>>
>>
>>> Am 13.05.2016 um 18:21 schrieb York Sun <york.sun@nxp.com>:
>>>
>>>> On 05/13/2016 07:32 AM, Alexander Graf wrote:
>>>>
>>>>> Am 13.05.2016 um 16:26 schrieb Stuart Yoder <stuart.yoder@nxp.com>:
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alexander Graf [mailto:agraf at suse.de]
>>>>>> Sent: Friday, May 13, 2016 7:22 AM
>>>>>> To: u-boot at lists.denx.de
>>>>>> Cc: Stuart Yoder <stuart.yoder@nxp.com>; york sun <york.sun@nxp.com>
>>>>>> Subject: [PATCH 5/5] ls2080ardb: Convert to distro boot
>>>>>>
>>>>>> 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 converts the LS2080ARDB board to use that framework instead
>>>>>> of booting from a hard coded flash offset.
>>>>>>
>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> This obviously means that we can no longer boot from said offset. Is
>>>>>> that a reasonable thing to do or should I put the bootm back into the
>>>>>> default boot command and only do distro boot if it fails?
>>>>>
>>>>> To date all armv8 FSL/NXP sdk releases, field engineers, etc have been using
>>>>> bootm.  I'm a little concerned about changing the default boot command
>>>>> right now...as I assume things will unexpectedly appear to just stop
>>>>> working.  Or, is booting from the NOR flash one of the distro boot
>>>>> "media" types?
>>>>
>>>> The problem with boot from NOR is that we have no source of information on what lies where. So distro boot can't have it in its target list, as you have to know magical offsets.
>>>>
>>>> We could put the magical bootm after tge distro list, but that would mean that field engineers get pxe boot with long timeouts first and then their NOR bootm booted.
>>>>
>>>> So the only option left that I can see is to always try magical offset NOR bootm and do distro boot if it fails. Then just tell people to write zeros to the NOR kernel offset and they get distro boot automatically.
>>>
>>> Alex,
>>>
>>> I suggest to attempt current boot method before moving on to other sources. I
>>> presume booting from NOR would check the image header first. If the image is
>>> valid, go ahead to boot it. Otherwise, move on.
>>
>> Ok, will do.
>>
>>>
>>> Beside, it would be helpful to define a list and order of boot source.
>>
>> That's what the patch does, no? See the BOOT_TARGET_DEVICES define. It's probably incomplete, but describes the boot order and boot sources.
>>
> 
> Yes I saw it. Would it be possible to use environmental variable for this
> purpose, so users can specify the list and order? If it is too complicated, we
> can live with the macro and recompile as needed.

With the patches applied as is, the environment looks like this:

=> printenv
arch=arm
baudrate=115200
board=ls2080ardb
board_name=ls2080ardb
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr}
${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart}
${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then
bootefi ${kernel_addr_r} ${fdt_addr_r};elsebootefi ${kernel_addr_r}
${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any
${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc0 scsi0 dhcp
bootargs=console=ttyS1,115200 root=/dev/ram0
earlycon=uart8250,mmio,0x21c0600 ramdisk_size=0x2000000
default_hugepagesz=2m hugepagesz=2m hugepages=256
bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x580700000 && setenv
ethact DPMAC5 at xgmii && run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr}
${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile
${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch
${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv
bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r}
dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi
${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r}
${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv
bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv
efi_old_vci;
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_scsi0=setenv devnum 0; run scsi_boot
bootdelay=2
cpu=armv8
distro_bootcmd=setenv scsi_need_init; for target in ${boot_targets}; do
run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
ethact=DPMAC1 at xgmii
ethprime=DPNI1
fdt_addr_r=0x88000000
fdt_high=0xa0000000
fdtcontroladdr=ffcfd498
fdtfile=fsl-ls2080a-rdb.dtb
hwconfig=fsl_ddr:bank_intlv=auto
initrd_high=0xffffffffffffffff
kernel_addr=0x100000
kernel_addr_r=0x81000000
kernel_load=0xa0000000
kernel_size=0x2800000
kernel_start=0x581100000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r}
${prefix}${efi_fdtfile}
loadaddr=0x80100000
mcinitcmd=fsl_mc start mc 0x580300000 0x580800000
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run
scan_dev_for_boot_part; fi
pxefile_addr_r=0x81000000
ramdisk_addr=0x800000
ramdisk_addr_r=0x89000000
ramdisk_size=0x2000000
scan_dev_for_boot=echo Scanning ${devtype}
${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run
scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable
devplist; env exists devplist || setenv devplist 1; for distro_bootpart
in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart}
bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in
${efi_dtb_prefixes}; do if test -e ${devtype}
${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run
load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart}
efi/boot/bootaa64.efi; then echo Found EFI removable media binary
efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED:
continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart}
${prefix}extlinux/extlinux.conf; then echo Found
${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED:
continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e
${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo
Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT
FAILED: continuing...; fi; done
scriptaddr=0x80800000
scsi_boot=run scsi_init; if scsi dev ${devnum}; then setenv devtype
scsi; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then setenv scsi_need_init false; scsi
scan; fi
scsidevs=0
soc=fsl-layerscape
stderr=serial
stdin=serial
stdout=serial
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run
scan_dev_for_boot_part; fi
vendor=freescale

#################

In there you can see a variable called "boot_targets" which contains the
values "mmc0 scsi0 dhcp".

That's basically what falls out of the BOOT_TARGET_DEVICES define. If a
user wants a different boot order, they can change that variable and the
script will process booting in a different order.

Also please always keep in mind that distro boot only provides default
variables for the default environment. Once you do saveenv, you can do
whatever you like. You can still override bootcmd to only boot your boot
target. Or you can define a different boot order.


Alex

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[York Sun]

On 05/13/2016 12:36 PM, Alexander Graf wrote:
> 
> 
> On 13.05.16 19:05, York Sun wrote:
>> On 05/13/2016 10:03 AM, Alexander Graf wrote:
>>>
>>>
>>>> Am 13.05.2016 um 18:21 schrieb York Sun <york.sun@nxp.com>:
>>>>
>>>>> On 05/13/2016 07:32 AM, Alexander Graf wrote:
>>>>>
>>>>>> Am 13.05.2016 um 16:26 schrieb Stuart Yoder <stuart.yoder@nxp.com>:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Alexander Graf [mailto:agraf at suse.de]
>>>>>>> Sent: Friday, May 13, 2016 7:22 AM
>>>>>>> To: u-boot at lists.denx.de
>>>>>>> Cc: Stuart Yoder <stuart.yoder@nxp.com>; york sun <york.sun@nxp.com>
>>>>>>> Subject: [PATCH 5/5] ls2080ardb: Convert to distro boot
>>>>>>>
>>>>>>> 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 converts the LS2080ARDB board to use that framework instead
>>>>>>> of booting from a hard coded flash offset.
>>>>>>>
>>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> This obviously means that we can no longer boot from said offset. Is
>>>>>>> that a reasonable thing to do or should I put the bootm back into the
>>>>>>> default boot command and only do distro boot if it fails?
>>>>>>
>>>>>> To date all armv8 FSL/NXP sdk releases, field engineers, etc have been using
>>>>>> bootm.  I'm a little concerned about changing the default boot command
>>>>>> right now...as I assume things will unexpectedly appear to just stop
>>>>>> working.  Or, is booting from the NOR flash one of the distro boot
>>>>>> "media" types?
>>>>>
>>>>> The problem with boot from NOR is that we have no source of information on what lies where. So distro boot can't have it in its target list, as you have to know magical offsets.
>>>>>
>>>>> We could put the magical bootm after tge distro list, but that would mean that field engineers get pxe boot with long timeouts first and then their NOR bootm booted.
>>>>>
>>>>> So the only option left that I can see is to always try magical offset NOR bootm and do distro boot if it fails. Then just tell people to write zeros to the NOR kernel offset and they get distro boot automatically.
>>>>
>>>> Alex,
>>>>
>>>> I suggest to attempt current boot method before moving on to other sources. I
>>>> presume booting from NOR would check the image header first. If the image is
>>>> valid, go ahead to boot it. Otherwise, move on.
>>>
>>> Ok, will do.
>>>
>>>>
>>>> Beside, it would be helpful to define a list and order of boot source.
>>>
>>> That's what the patch does, no? See the BOOT_TARGET_DEVICES define. It's probably incomplete, but describes the boot order and boot sources.
>>>
>>
>> Yes I saw it. Would it be possible to use environmental variable for this
>> purpose, so users can specify the list and order? If it is too complicated, we
>> can live with the macro and recompile as needed.
> 
> With the patches applied as is, the environment looks like this:
> 
> => printenv
> arch=arm
> baudrate=115200
> board=ls2080ardb
> board_name=ls2080ardb
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr}
> ${prefix}${script}; source ${scriptaddr}
> boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart}
> ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then
> bootefi ${kernel_addr_r} ${fdt_addr_r};elsebootefi ${kernel_addr_r}
> ${fdtcontroladdr};fi
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any
> ${scriptaddr} ${prefix}extlinux/extlinux.conf
> boot_net_usb_start=usb start
> boot_prefixes=/ /boot/
> boot_script_dhcp=boot.scr.uimg
> boot_scripts=boot.scr.uimg boot.scr
> boot_targets=mmc0 scsi0 dhcp
> bootargs=console=ttyS1,115200 root=/dev/ram0
> earlycon=uart8250,mmio,0x21c0600 ramdisk_size=0x2000000
> default_hugepagesz=2m hugepagesz=2m hugepages=256
> bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x580700000 && setenv
> ethact DPMAC5 at xgmii && run distro_bootcmd
> bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr}
> ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile
> ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch
> ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv
> bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r}
> dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi
> ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r}
> ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv
> bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv
> efi_old_vci;
> bootcmd_mmc0=setenv devnum 0; run mmc_boot
> bootcmd_scsi0=setenv devnum 0; run scsi_boot
> bootdelay=2
> cpu=armv8
> distro_bootcmd=setenv scsi_need_init; for target in ${boot_targets}; do
> run bootcmd_${target}; done
> efi_dtb_prefixes=/ /dtb/ /dtb/current/
> ethact=DPMAC1 at xgmii
> ethprime=DPNI1
> fdt_addr_r=0x88000000
> fdt_high=0xa0000000
> fdtcontroladdr=ffcfd498
> fdtfile=fsl-ls2080a-rdb.dtb
> hwconfig=fsl_ddr:bank_intlv=auto
> initrd_high=0xffffffffffffffff
> kernel_addr=0x100000
> kernel_addr_r=0x81000000
> kernel_load=0xa0000000
> kernel_size=0x2800000
> kernel_start=0x581100000
> load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r}
> ${prefix}${efi_fdtfile}
> loadaddr=0x80100000
> mcinitcmd=fsl_mc start mc 0x580300000 0x580800000
> mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run
> scan_dev_for_boot_part; fi
> pxefile_addr_r=0x81000000
> ramdisk_addr=0x800000
> ramdisk_addr_r=0x89000000
> ramdisk_size=0x2000000
> scan_dev_for_boot=echo Scanning ${devtype}
> ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run
> scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
> scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable
> devplist; env exists devplist || setenv devplist 1; for distro_bootpart
> in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart}
> bootfstype; then run scan_dev_for_boot; fi; done
> scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in
> ${efi_dtb_prefixes}; do if test -e ${devtype}
> ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run
> load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart}
> efi/boot/bootaa64.efi; then echo Found EFI removable media binary
> efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED:
> continuing...; fi; setenv efi_fdtfile
> scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart}
> ${prefix}extlinux/extlinux.conf; then echo Found
> ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED:
> continuing...; fi
> scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e
> ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo
> Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT
> FAILED: continuing...; fi; done
> scriptaddr=0x80800000
> scsi_boot=run scsi_init; if scsi dev ${devnum}; then setenv devtype
> scsi; run scan_dev_for_boot_part; fi
> scsi_init=if ${scsi_need_init}; then setenv scsi_need_init false; scsi
> scan; fi
> scsidevs=0
> soc=fsl-layerscape
> stderr=serial
> stdin=serial
> stdout=serial
> usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run
> scan_dev_for_boot_part; fi
> vendor=freescale
> 
> #################
> 
> In there you can see a variable called "boot_targets" which contains the
> values "mmc0 scsi0 dhcp".
> 

Ah, thanks. I didn't realize the macro ends up in the boot_targets.

York

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Bhupesh Sharma]

Note that UEFI firmware support is already available on LS2080A-RDB and allows
Booting distributions like CentOS on the same.

Regards,
Bhupesh

> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of York
> Sun
> Sent: Saturday, May 14, 2016 1:23 AM
> To: Alexander Graf <agraf@suse.de>
> Cc: u-boot at lists.denx.de; Peter Newton <peter.newton@nxp.com>
> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> 
> On 05/13/2016 12:36 PM, Alexander Graf wrote:
> >
> >
> > On 13.05.16 19:05, York Sun wrote:
> >> On 05/13/2016 10:03 AM, Alexander Graf wrote:
> >>>
> >>>
> >>>> Am 13.05.2016 um 18:21 schrieb York Sun <york.sun@nxp.com>:
> >>>>
> >>>>> On 05/13/2016 07:32 AM, Alexander Graf wrote:
> >>>>>
> >>>>>> Am 13.05.2016 um 16:26 schrieb Stuart Yoder
> <stuart.yoder@nxp.com>:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Alexander Graf [mailto:agraf at suse.de]
> >>>>>>> Sent: Friday, May 13, 2016 7:22 AM
> >>>>>>> To: u-boot at lists.denx.de
> >>>>>>> Cc: Stuart Yoder <stuart.yoder@nxp.com>; york sun
> >>>>>>> <york.sun@nxp.com>
> >>>>>>> Subject: [PATCH 5/5] ls2080ardb: Convert to distro boot
> >>>>>>>
> >>>>>>> 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 converts the LS2080ARDB board to use that framework
> >>>>>>> instead of booting from a hard coded flash offset.
> >>>>>>>
> >>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
> >>>>>>>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> This obviously means that we can no longer boot from said
> >>>>>>> offset. Is that a reasonable thing to do or should I put the
> >>>>>>> bootm back into the default boot command and only do distro
> boot if it fails?
> >>>>>>
> >>>>>> To date all armv8 FSL/NXP sdk releases, field engineers, etc
> have
> >>>>>> been using bootm.  I'm a little concerned about changing the
> >>>>>> default boot command right now...as I assume things will
> >>>>>> unexpectedly appear to just stop working.  Or, is booting from
> >>>>>> the NOR flash one of the distro boot "media" types?
> >>>>>
> >>>>> The problem with boot from NOR is that we have no source of
> information on what lies where. So distro boot can't have it in its
> target list, as you have to know magical offsets.
> >>>>>
> >>>>> We could put the magical bootm after tge distro list, but that
> would mean that field engineers get pxe boot with long timeouts first
> and then their NOR bootm booted.
> >>>>>
> >>>>> So the only option left that I can see is to always try magical
> offset NOR bootm and do distro boot if it fails. Then just tell people
> to write zeros to the NOR kernel offset and they get distro boot
> automatically.
> >>>>
> >>>> Alex,
> >>>>
> >>>> I suggest to attempt current boot method before moving on to other
> >>>> sources. I presume booting from NOR would check the image header
> >>>> first. If the image is valid, go ahead to boot it. Otherwise, move
> on.
> >>>
> >>> Ok, will do.
> >>>
> >>>>
> >>>> Beside, it would be helpful to define a list and order of boot
> source.
> >>>
> >>> That's what the patch does, no? See the BOOT_TARGET_DEVICES define.
> It's probably incomplete, but describes the boot order and boot
> sources.
> >>>
> >>
> >> Yes I saw it. Would it be possible to use environmental variable for
> >> this purpose, so users can specify the list and order? If it is too
> >> complicated, we can live with the macro and recompile as needed.
> >
> > With the patches applied as is, the environment looks like this:
> >
> > => printenv
> > arch=arm
> > baudrate=115200
> > board=ls2080ardb
> > board_name=ls2080ardb
> > boot_a_script=load ${devtype} ${devnum}:${distro_bootpart}
> > ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
> > boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart}
> > ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r};
> > then bootefi ${kernel_addr_r} ${fdt_addr_r};elsebootefi
> > ${kernel_addr_r} ${fdtcontroladdr};fi boot_extlinux=sysboot
> ${devtype}
> > ${devnum}:${distro_bootpart} any ${scriptaddr}
> > ${prefix}extlinux/extlinux.conf boot_net_usb_start=usb start
> > boot_prefixes=/ /boot/ boot_script_dhcp=boot.scr.uimg
> > boot_scripts=boot.scr.uimg boot.scr
> > boot_targets=mmc0 scsi0 dhcp
> > bootargs=console=ttyS1,115200 root=/dev/ram0
> > earlycon=uart8250,mmio,0x21c0600 ramdisk_size=0x2000000
> > default_hugepagesz=2m hugepagesz=2m hugepages=256 bootcmd=run
> > mcinitcmd && fsl_mc lazyapply dpl 0x580700000 && setenv ethact
> > DPMAC5 at xgmii && run distro_bootcmd bootcmd_dhcp=run
> > boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then
> > source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv
> > efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv
> > bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv
> > bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r}
> > dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi
> > ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r}
> > ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv
> > bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv
> > efi_old_arch;setenv efi_old_vci; bootcmd_mmc0=setenv devnum 0; run
> > mmc_boot bootcmd_scsi0=setenv devnum 0; run scsi_boot
> > bootdelay=2
> > cpu=armv8
> > distro_bootcmd=setenv scsi_need_init; for target in ${boot_targets};
> > do run bootcmd_${target}; done efi_dtb_prefixes=/ /dtb/ /dtb/current/
> > ethact=DPMAC1 at xgmii
> > ethprime=DPNI1
> > fdt_addr_r=0x88000000
> > fdt_high=0xa0000000
> > fdtcontroladdr=ffcfd498
> > fdtfile=fsl-ls2080a-rdb.dtb
> > hwconfig=fsl_ddr:bank_intlv=auto
> > initrd_high=0xffffffffffffffff
> > kernel_addr=0x100000
> > kernel_addr_r=0x81000000
> > kernel_load=0xa0000000
> > kernel_size=0x2800000
> > kernel_start=0x581100000
> > load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart}
> > ${fdt_addr_r} ${prefix}${efi_fdtfile}
> > loadaddr=0x80100000
> > mcinitcmd=fsl_mc start mc 0x580300000 0x580800000 mmc_boot=if mmc dev
> > ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
> > pxefile_addr_r=0x81000000
> > ramdisk_addr=0x800000
> > ramdisk_addr_r=0x89000000
> > ramdisk_size=0x2000000
> > scan_dev_for_boot=echo Scanning ${devtype}
> > ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do
> > run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run
> > scan_dev_for_efi; scan_dev_for_boot_part=part list ${devtype}
> > ${devnum} -bootable devplist; env exists devplist || setenv devplist
> > 1; for distro_bootpart in ${devplist}; do if fstype ${devtype}
> > ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot;
> > fi; done scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix
> in
> > ${efi_dtb_prefixes}; do if test -e ${devtype}
> > ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run
> > load_efi_dtb; fi;done;if test -e ${devtype}
> > ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found
> > EFI removable media binary efi/boot/bootaa64.efi; run
> boot_efi_binary; echo EFI LOAD FAILED:
> > continuing...; fi; setenv efi_fdtfile
> > scan_dev_for_extlinux=if test -e ${devtype}
> > ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then
> > echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo
> SCRIPT FAILED:
> > continuing...; fi
> > scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e
> > ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo
> > Found U-Boot script ${prefix}${script}; run boot_a_script; echo
> SCRIPT
> > FAILED: continuing...; fi; done
> > scriptaddr=0x80800000
> > scsi_boot=run scsi_init; if scsi dev ${devnum}; then setenv devtype
> > scsi; run scan_dev_for_boot_part; fi scsi_init=if ${scsi_need_init};
> > then setenv scsi_need_init false; scsi scan; fi
> > scsidevs=0
> > soc=fsl-layerscape
> > stderr=serial
> > stdin=serial
> > stdout=serial
> > usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb;
> run
> > scan_dev_for_boot_part; fi vendor=freescale
> >
> > #################
> >
> > In there you can see a variable called "boot_targets" which contains
> > the values "mmc0 scsi0 dhcp".
> >
> 
> Ah, thanks. I didn't realize the macro ends up in the boot_targets.
> 
> York
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Amit Tomer]

On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma <bhupesh.sharma@nxp.com> wrote:
> Note that UEFI firmware support is already available on LS2080A-RDB and allows
> Booting distributions like CentOS on the same.
>

Sorry to intervene here but it's about having the EFI support inside
u-boot itself that
may *not* required to have separate UEFI firmware to boot various distributions.

Please correct, if it's not right ?

Thanks,
Amit

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Alexander Graf]

> Am 16.05.2016 um 08:58 schrieb Amit Tomer <amittomer25@gmail.com>:
> 
>> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma <bhupesh.sharma@nxp.com> wrote:
>> Note that UEFI firmware support is already available on LS2080A-RDB and allows
>> Booting distributions like CentOS on the same.
> 
> Sorry to intervene here but it's about having the EFI support inside
> u-boot itself that
> may *not* required to have separate UEFI firmware to boot various distributions.
> 
> Please correct, if it's not right ?

It's correct. The idea is to allow everyone to boot using the uEFI entry point in Linux (or any other OS), regardless of whether they want to run U-Boot or a TianoCore based formware.

This might seem useless today for embedded use cases, but some features are only available via an EFI entry, such as kASLR. You can also invoke Linux directly using the "bootefi" command, as Linux is an EFI binary itself. That way the boot path doesn't become much longer than with booti today.


Alex

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Bhupesh Sharma]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Monday, May 16, 2016 1:09 PM
> To: Amit Tomer <amittomer25@gmail.com>
> Cc: Bhupesh Sharma <bhupesh.sharma@nxp.com>; york sun
> <york.sun@nxp.com>; u-boot at lists.denx.de; Peter Newton
> <peter.newton@nxp.com>
> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> 
> 
> 
> > Am 16.05.2016 um 08:58 schrieb Amit Tomer <amittomer25@gmail.com>:
> >
> >> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
> <bhupesh.sharma@nxp.com> wrote:
> >> Note that UEFI firmware support is already available on LS2080A-RDB
> >> and allows Booting distributions like CentOS on the same.
> >
> > Sorry to intervene here but it's about having the EFI support inside
> > u-boot itself that may *not* required to have separate UEFI firmware
> > to boot various distributions.
> >
> > Please correct, if it's not right ?
> 
> It's correct. The idea is to allow everyone to boot using the uEFI
> entry point in Linux (or any other OS), regardless of whether they want
> to run U-Boot or a TianoCore based formware.
> 
> This might seem useless today for embedded use cases, but some features
> are only available via an EFI entry, such as kASLR. You can also invoke
> Linux directly using the "bootefi" command, as Linux is an EFI binary
> itself. That way the boot path doesn't become much longer than with
> booti today.
> 

The default firmware being offered by NXP to boot distros on LS2080A and variants is UEFI.

EFI application support in u-boot doesn't present a solution to things like run-time variable/service
support that is required by distros to update firmware components on the go. And there are several
other services being offered by UEFI to help distro boot e.g. secure uefi boot through x.509 certifications
compliant to UEFI specifications.

Regards,
Bhupesh

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Alexander Graf]

On 16.05.16 14:04, Bhupesh Sharma wrote:
> 
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Monday, May 16, 2016 1:09 PM
>> To: Amit Tomer <amittomer25@gmail.com>
>> Cc: Bhupesh Sharma <bhupesh.sharma@nxp.com>; york sun
>> <york.sun@nxp.com>; u-boot at lists.denx.de; Peter Newton
>> <peter.newton@nxp.com>
>> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
>>
>>
>>
>>> Am 16.05.2016 um 08:58 schrieb Amit Tomer <amittomer25@gmail.com>:
>>>
>>>> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
>> <bhupesh.sharma@nxp.com> wrote:
>>>> Note that UEFI firmware support is already available on LS2080A-RDB
>>>> and allows Booting distributions like CentOS on the same.
>>>
>>> Sorry to intervene here but it's about having the EFI support inside
>>> u-boot itself that may *not* required to have separate UEFI firmware
>>> to boot various distributions.
>>>
>>> Please correct, if it's not right ?
>>
>> It's correct. The idea is to allow everyone to boot using the uEFI
>> entry point in Linux (or any other OS), regardless of whether they want
>> to run U-Boot or a TianoCore based formware.
>>
>> This might seem useless today for embedded use cases, but some features
>> are only available via an EFI entry, such as kASLR. You can also invoke
>> Linux directly using the "bootefi" command, as Linux is an EFI binary
>> itself. That way the boot path doesn't become much longer than with
>> booti today.
>>
> 
> The default firmware being offered by NXP to boot distros on LS2080A and variants is UEFI.
> 
> EFI application support in u-boot doesn't present a solution to things like run-time variable/service
> support that is required by distros to update firmware components on the go. And there are several
> other services being offered by UEFI to help distro boot e.g. secure uefi boot through x.509 certifications
> compliant to UEFI specifications.

Don't get me wrong - I think it's great if there is a TianoCore based
firmware for LS2080A. But I didn't get the impression that there is a
TianoCore based firmware for every NXP SoC out there, so enabling all of
them to use the U-Boot provided uEFI implementation is still a win.

That said, there's nothing that keeps us from implementing the bits you
mentioned in U-Boot either. There is support for RTS in U-Boot, we just
didn't convert any drivers (RTC comes to mind first) yet.

There's also no support for uEFI environment variables, but mostly
because most systems I've used this code on so far just didn't have any
storage to put them.

Certification checks also shouldn't be an issue if someone cared enough
about them.

But I don't think we need a discussion of TianoCore vs U-Boot. What
everyone really wants is to have things "just work". And some customers
just prefer U-Boot for various reasons that are outside of my control.
If they can run the same boot path as everyone else, it makes life for
me as distribution vendor easier. And unlike other people in the
community, I don't think being a TianoCore+ACPI messiah is any helpful
for that goal.


Alex

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Bhupesh Sharma]

> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Monday, May 16, 2016 5:51 PM
> On 16.05.16 14:04, Bhupesh Sharma wrote:
> >
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf at suse.de]
> >> Sent: Monday, May 16, 2016 1:09 PM
> >> To: Amit Tomer <amittomer25@gmail.com>
> >> Cc: Bhupesh Sharma <bhupesh.sharma@nxp.com>; york sun
> >> <york.sun@nxp.com>; u-boot at lists.denx.de; Peter Newton
> >> <peter.newton@nxp.com>
> >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> >>
> >>
> >>
> >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer <amittomer25@gmail.com>:
> >>>
> >>>> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
> >> <bhupesh.sharma@nxp.com> wrote:
> >>>> Note that UEFI firmware support is already available on LS2080A-
> RDB
> >>>> and allows Booting distributions like CentOS on the same.
> >>>
> >>> Sorry to intervene here but it's about having the EFI support
> inside
> >>> u-boot itself that may *not* required to have separate UEFI
> firmware
> >>> to boot various distributions.
> >>>
> >>> Please correct, if it's not right ?
> >>
> >> It's correct. The idea is to allow everyone to boot using the uEFI
> >> entry point in Linux (or any other OS), regardless of whether they
> >> want to run U-Boot or a TianoCore based formware.
> >>
> >> This might seem useless today for embedded use cases, but some
> >> features are only available via an EFI entry, such as kASLR. You can
> >> also invoke Linux directly using the "bootefi" command, as Linux is
> >> an EFI binary itself. That way the boot path doesn't become much
> >> longer than with booti today.
> >>
> >
> > The default firmware being offered by NXP to boot distros on LS2080A
> and variants is UEFI.
> >
> > EFI application support in u-boot doesn't present a solution to
> things
> > like run-time variable/service support that is required by distros to
> > update firmware components on the go. And there are several other
> > services being offered by UEFI to help distro boot e.g. secure uefi
> boot through x.509 certifications compliant to UEFI specifications.
> 
> Don't get me wrong - I think it's great if there is a TianoCore based
> firmware for LS2080A. But I didn't get the impression that there is a
> TianoCore based firmware for every NXP SoC out there, so enabling all
> of them to use the U-Boot provided uEFI implementation is still a win.
> 
> That said, there's nothing that keeps us from implementing the bits you
> mentioned in U-Boot either. There is support for RTS in U-Boot, we just
> didn't convert any drivers (RTC comes to mind first) yet.
> 
> There's also no support for uEFI environment variables, but mostly
> because most systems I've used this code on so far just didn't have any
> storage to put them.
> 
> Certification checks also shouldn't be an issue if someone cared enough
> about them.
> 
> But I don't think we need a discussion of TianoCore vs U-Boot. What
> everyone really wants is to have things "just work". And some customers
> just prefer U-Boot for various reasons that are outside of my control.
> If they can run the same boot path as everyone else, it makes life for
> me as distribution vendor easier. And unlike other people in the
> community, I don't think being a TianoCore+ACPI messiah is any helpful
> for that goal.

Alex - that's exactly my point. UEFI is currently planned as the default
firmware on all QorIQ-LS ARMv8 SoCs for supporting distros. It's good to have a
u-boot based solution for SoCs which don't support UEFI, but having both supported to boot distros 
causes confusion to the end user (IMHO), as the capabilities would vary drastically.

Regarding adding support for run-time variable/services, we can always port
everything over from the UEFI specifications - ACPI, run-time variable/services
into u-boot. I think it's a great alternative on SoCs which don't have UEFI support available.

But LS2080A and friends (LS1043A) already have UEFI support available and support
distros like CentOS to be installed and boot'ed. So, these SoCs would not require
an equivalent u-boot + EFI_Application like environment to boot distro.

Regards,
Bhupesh

[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Peter Newton]

> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Monday, May 16, 2016 7:21 AM
> To: Bhupesh Sharma <bhupesh.sharma@nxp.com>; Amit Tomer <amittomer25@gmail.com>
> Cc: york sun <york.sun@nxp.com>; u-boot at lists.denx.de; Peter Newton <peter.newton@nxp.com>
> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> 
> 
> 
> On 16.05.16 14:04, Bhupesh Sharma wrote:
> >
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf at suse.de]
> >> Sent: Monday, May 16, 2016 1:09 PM
> >> To: Amit Tomer <amittomer25@gmail.com>
> >> Cc: Bhupesh Sharma <bhupesh.sharma@nxp.com>; york sun
> >> <york.sun@nxp.com>; u-boot at lists.denx.de; Peter Newton
> >> <peter.newton@nxp.com>
> >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> >>
> >>
> >>
> >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer <amittomer25@gmail.com>:
> >>>
> >>>> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
> >> <bhupesh.sharma@nxp.com> wrote:
> >>>> Note that UEFI firmware support is already available on LS2080A-RDB
> >>>> and allows Booting distributions like CentOS on the same.
> >>>
> >>> Sorry to intervene here but it's about having the EFI support inside
> >>> u-boot itself that may *not* required to have separate UEFI firmware
> >>> to boot various distributions.
> >>>
> >>> Please correct, if it's not right ?
> >>
> >> It's correct. The idea is to allow everyone to boot using the uEFI
> >> entry point in Linux (or any other OS), regardless of whether they
> >> want to run U-Boot or a TianoCore based formware.
> >>
> >> This might seem useless today for embedded use cases, but some
> >> features are only available via an EFI entry, such as kASLR. You can
> >> also invoke Linux directly using the "bootefi" command, as Linux is
> >> an EFI binary itself. That way the boot path doesn't become much
> >> longer than with booti today.
> >>
> >
> > The default firmware being offered by NXP to boot distros on LS2080A and variants is UEFI.
> >
> > EFI application support in u-boot doesn't present a solution to things
> > like run-time variable/service support that is required by distros to
> > update firmware components on the go. And there are several other
> > services being offered by UEFI to help distro boot e.g. secure uefi boot through x.509 certifications compliant to UEFI specifications.
> 
> Don't get me wrong - I think it's great if there is a TianoCore based firmware for LS2080A. But I didn't get the impression that there is a
> TianoCore based firmware for every NXP SoC out there, so enabling all of them to use the U-Boot provided uEFI implementation is still
> a win.
> 
> That said, there's nothing that keeps us from implementing the bits you mentioned in U-Boot either. There is support for RTS in U-
> Boot, we just didn't convert any drivers (RTC comes to mind first) yet.
> 
> There's also no support for uEFI environment variables, but mostly because most systems I've used this code on so far just didn't have
> any storage to put them.
> 
> Certification checks also shouldn't be an issue if someone cared enough about them.
> 
> But I don't think we need a discussion of TianoCore vs U-Boot. What everyone really wants is to have things "just work". And some
> customers just prefer U-Boot for various reasons that are outside of my control.
> If they can run the same boot path as everyone else, it makes life for me as distribution vendor easier. And unlike other people in the
> community, I don't think being a TianoCore+ACPI messiah is any helpful for that goal.

Agreed, this should not become a U-Boot vs UEFI thread.  And just to be sure it is clear to everyone, NXP currently offers both U-Boot and is starting to have UEFI firmware releases also.  We are not dropping U-Boot just because we begin to have UEFI.

[U-Boot] [PATCH v2 5/5] 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>
---
 include/configs/ls2080ardb.h | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 5bec509..f3f2ebd 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -323,10 +323,25 @@ unsigned long get_board_sys_clk(void);
 #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS      2
 #define CONFIG_USB_STORAGE
 
+#undef CONFIG_CMDLINE_EDITING
+#undef CONFIG_BOOTDELAY
+#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"		\
@@ -336,8 +351,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 " \
@@ -345,6 +362,14 @@ 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" \
+			   " && setenv ethact DPMAC5 at xgmii" \
+			   " && run distro_bootcmd"
+
 /* MAC/PHY configuration */
 #ifdef CONFIG_FSL_MC_ENET
 #define CONFIG_PHYLIB_10G
-- 
1.8.5.6

[U-Boot] [PATCH v3 5/5] 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)
---
 include/configs/ls2080ardb.h | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 5bec509..bb88847 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -323,10 +323,25 @@ unsigned long get_board_sys_clk(void);
 #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS      2
 #define CONFIG_USB_STORAGE
 
+#undef CONFIG_CMDLINE_EDITING
+#undef CONFIG_BOOTDELAY
+#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"		\
@@ -336,8 +351,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 " \
@@ -345,6 +362,14 @@ 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" \
+			   " || setenv ethact DPMAC5 at xgmii" \
+			   " && run distro_bootcmd"
+
 /* MAC/PHY configuration */
 #ifdef CONFIG_FSL_MC_ENET
 #define CONFIG_PHYLIB_10G
-- 
1.8.5.6