[U-Boot] [PATCH 0/5] LS2080ARDB: Enable EFI boot support
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(-)
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();
-----Original Message----- From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Alexander Graf Sent: Friday, May 13, 2016 5:52 PM To: u-boot@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
On 05/18/2016 02:29 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Alexander Graf Sent: Friday, May 13, 2016 5:52 PM To: u-boot@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
Hi Alex,
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Friday, May 27, 2016 7:58 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@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@lists.denx.de] On Behalf Of Alexander Graf Sent: Friday, May 13, 2016 5:52 PM To: u-boot@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
On 07.06.16 03:28, Prabhakar Kushwaha wrote:
Hi Alex,
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Friday, May 27, 2016 7:58 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@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@lists.denx.de] On Behalf Of Alexander Graf Sent: Friday, May 13, 2016 5:52 PM To: u-boot@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
On 07.06.16 03:28, Prabhakar Kushwaha wrote:
Hi Alex,
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Friday, May 27, 2016 7:58 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@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@lists.denx.de] On Behalf Of Alexander Graf Sent: Friday, May 13, 2016 5:52 PM To: u-boot@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
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;
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
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
Hi Alex,
-----Original Message----- From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Alexander Graf Sent: Friday, May 13, 2016 5:52 PM To: u-boot@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@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!
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);
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; }
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@xgmii" \ + " && run distro_bootcmd" + /* MAC/PHY configuration */ #ifdef CONFIG_FSL_MC_ENET #define CONFIG_PHYLIB_10G
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Friday, May 13, 2016 7:22 AM To: u-boot@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@xgmii" \" && run distro_bootcmd"/* MAC/PHY configuration */ #ifdef CONFIG_FSL_MC_ENET
#define CONFIG_PHYLIB_10G
1.8.5.6
Am 13.05.2016 um 16:26 schrieb Stuart Yoder stuart.yoder@nxp.com:
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Friday, May 13, 2016 7:22 AM To: u-boot@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
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@suse.de] Sent: Friday, May 13, 2016 7:22 AM To: u-boot@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
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@suse.de] Sent: Friday, May 13, 2016 7:22 AM To: u-boot@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
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@suse.de] Sent: Friday, May 13, 2016 7:22 AM To: u-boot@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
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@suse.de] Sent: Friday, May 13, 2016 7:22 AM To: u-boot@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@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@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
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@suse.de] > Sent: Friday, May 13, 2016 7:22 AM > To: u-boot@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@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@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
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@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@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
> > > >> -----Original Message----- >> From: Alexander Graf [mailto:agraf@suse.de] >> Sent: Friday, May 13, 2016 7:22 AM >> To: u-boot@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@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@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
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
-----Original Message----- From: Alexander Graf [mailto:agraf@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@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
On 16.05.16 14:04, Bhupesh Sharma wrote:
-----Original Message----- From: Alexander Graf [mailto:agraf@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@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
From: Alexander Graf [mailto:agraf@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@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@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
From: Alexander Graf [mailto:agraf@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@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@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@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.
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@xgmii" \ + " && run distro_bootcmd" + /* MAC/PHY configuration */ #ifdef CONFIG_FSL_MC_ENET #define CONFIG_PHYLIB_10G
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@xgmii" \ + " && run distro_bootcmd" + /* MAC/PHY configuration */ #ifdef CONFIG_FSL_MC_ENET #define CONFIG_PHYLIB_10G
participants (7)
-
Alexander Graf -
Amit Tomer -
Bhupesh Sharma -
Peter Newton -
Prabhakar Kushwaha -
Stuart Yoder -
York Sun