LS2080ARDB: Enable EFI boot support

-----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 <[email protected]>

Quoted 23 lines

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

Quoted 1 line

Signed-off-by Alexander Graf <[email protected]>

With this patch.

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

Starting kernel ...

"Synchronous Abort" handler, esr 0x96000044

-----Original Message-----
From: Alexander Graf [mailto:agraf at suse.de]
Sent: Friday, May 27, 2016 7:58 PM
To: Prabhakar Kushwaha <[email protected]>; u-
boot at lists.denx.de
Cc: york sun <[email protected]>
Subject: Re: [U-Boot] [PATCH 1/5] ls2080: Exit dpaa only right before exiting U-Boot

Quoted 26 lines · Prabhakar Kushwaha

Quoted 17 lines

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

Quoted 7 lines

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 <[email protected]>

With this patch.

Quoted 5 lines

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? :)

Hi Alex,

Quoted 42 lines

-----Original Message-----
From: Alexander Graf [mailto:agraf at suse.de]
Sent: Friday, May 27, 2016 7:58 PM
To: Prabhakar Kushwaha <[email protected]>; u-
boot at lists.denx.de
Cc: york sun <[email protected]>
Subject: Re: [U-Boot] [PATCH 1/5] ls2080: Exit dpaa only right before exiting U-Boot

Quoted 31 lines · Prabhakar Kushwaha

Quoted 17 lines

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

Quoted 7 lines

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 <[email protected]>

With this patch.

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

Starting kernel ...

"Synchronous Abort" handler, esr 0x96000044

Quoted 3 lines

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.

Hi Alex,

Quoted 42 lines

-----Original Message-----
From: Alexander Graf [mailto:agraf at suse.de]
Sent: Friday, May 27, 2016 7:58 PM
To: Prabhakar Kushwaha <[email protected]>; u-
boot at lists.denx.de
Cc: york sun <[email protected]>
Subject: Re: [U-Boot] [PATCH 1/5] ls2080: Exit dpaa only right before exiting U-Boot

Quoted 31 lines · Prabhakar Kushwaha

Quoted 17 lines

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

Quoted 7 lines

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 <[email protected]>

With this patch.

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

Starting kernel ...

"Synchronous Abort" handler, esr 0x96000044

Quoted 3 lines

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.

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 <[email protected]>

---

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

board/freescale/ls2080a/ddr.c +0 -0

index 1827ddc..a02aa64 100644

Quoted 30 lines · 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 <[email protected]>

---

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

board/freescale/ls2080a/ddr.c +0 -0

index 1827ddc..a02aa64 100644

board/freescale/ls2080a/ddr.c phys_size_t initdram(int board_type) · line 170

Quoted 6 lines

board/freescale/ls2080a/ddr.c +2 -0

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

-----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 <[email protected]>

-----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 <[email protected]>; york sun <[email protected]>
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 <[email protected]>

---

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

include/configs/ls2080ardb.h +23 -2

index 5bec509..6ee6c87 100644
@@ -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

Am 13.05.2016 um 16:26 schrieb Stuart Yoder <[email protected]>:

Quoted 14 lines

-----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 <[email protected]>; york sun <[email protected]>
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.

Quoted 7 lines

Signed-off-by Alexander Graf <[email protected]>

---

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?

Quoted 27 lines

Am 13.05.2016 um 16:26 schrieb Stuart Yoder <[email protected]>:

Quoted 14 lines

-----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 <[email protected]>; york sun <[email protected]>
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.

Quoted 7 lines

Signed-off-by Alexander Graf <[email protected]>

---

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?

Quoted 5 lines

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.

Am 13.05.2016 um 18:21 schrieb York Sun <[email protected]>:

Quoted 38 lines · Alexander Graf

Quoted 27 lines

Am 13.05.2016 um 16:26 schrieb Stuart Yoder <[email protected]>:

Quoted 14 lines

-----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 <[email protected]>; york sun <[email protected]>
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.

Quoted 7 lines

Signed-off-by Alexander Graf <[email protected]>

---

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?

Quoted 5 lines

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.

Quoted 1 line

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.

Quoted 42 lines

Am 13.05.2016 um 18:21 schrieb York Sun <[email protected]>:

Quoted 38 lines · Alexander Graf

Quoted 27 lines

Am 13.05.2016 um 16:26 schrieb Stuart Yoder <[email protected]>:

Quoted 14 lines

-----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 <[email protected]>; york sun <[email protected]>
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.

Quoted 7 lines

Signed-off-by Alexander Graf <[email protected]>

---

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?

Quoted 5 lines

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.

Quoted 7 lines

Quoted 1 line

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.

Quoted 2 lines

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.

Quoted 53 lines · Alexander Graf

Quoted 42 lines

Am 13.05.2016 um 18:21 schrieb York Sun <[email protected]>:

Quoted 38 lines · Alexander Graf

Quoted 27 lines

Am 13.05.2016 um 16:26 schrieb Stuart Yoder <[email protected]>:

Quoted 14 lines

-----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 <[email protected]>; york sun <[email protected]>
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.

Quoted 7 lines

Signed-off-by Alexander Graf <[email protected]>

---

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?

Quoted 5 lines

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.

Quoted 7 lines

Quoted 1 line

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.

Quoted 1 line

Quoted 4 lines

Quoted 1 line

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.

Quoted 54 lines · York Sun

Quoted 53 lines · Alexander Graf

Quoted 42 lines

Am 13.05.2016 um 18:21 schrieb York Sun <[email protected]>:

Quoted 38 lines · Alexander Graf

Quoted 27 lines

Am 13.05.2016 um 16:26 schrieb Stuart Yoder <[email protected]>:

Quoted 14 lines

-----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 <[email protected]>; york sun <[email protected]>
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.

Quoted 7 lines

Signed-off-by Alexander Graf <[email protected]>

---

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?

Quoted 5 lines

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.

Quoted 7 lines

Quoted 1 line

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.

Quoted 1 line

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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

-----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 <[email protected]>
Cc: u-boot at lists.denx.de; Peter Newton <[email protected]>
Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

Quoted 11 lines · Alexander Graf

Quoted 8 lines · York Sun

Quoted 7 lines · Alexander Graf

Quoted 7 lines

Am 13.05.2016 um 18:21 schrieb York Sun <[email protected]>:

Quoted 3 lines · Alexander Graf

Quoted 2 lines

Am 13.05.2016 um 16:26 schrieb Stuart Yoder

<[email protected]>:

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

-----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 <[email protected]>; york sun <[email protected]>
Subject: [PATCH 5/5] ls2080ardb: Convert to distro boot

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Most new systems in U-Boot these days make use of the generic

"distro"

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

framework which allows a user to have U-Boot scan for a

bootable

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Signed-off-by Alexander Graf <[email protected]>

---

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?

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

To date all armv8 FSL/NXP sdk releases, field engineers, etc

have

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 4 lines

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.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Ok, will do.

Quoted 2 lines

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

source.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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.

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

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:

Quoted 11 lines

=> 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}

Quoted 47 lines

${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

Quoted 8 lines

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

Quoted 5 lines

${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:

Quoted 4 lines

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:

Quoted 4 lines

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

Quoted 11 lines

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

Quoted 7 lines

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

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

Am 16.05.2016 um 08:58 schrieb Amit Tomer <[email protected]>:

Quoted 3 lines · Bhupesh Sharma

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 ?

-----Original Message-----
From: Alexander Graf [mailto:agraf at suse.de]
Sent: Monday, May 16, 2016 1:09 PM
To: Amit Tomer <[email protected]>
Cc: Bhupesh Sharma <[email protected]>; york sun <[email protected]>; u-boot at lists.denx.de; Peter Newton <[email protected]>
Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

Quoted 3 lines

Am 16.05.2016 um 08:58 schrieb Amit Tomer <[email protected]>:

Quoted 1 line

On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma

Quoted 8 lines · <[email protected]> wrote:

Quoted 2 lines

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.

Quoted 30 lines

-----Original Message-----
From: Alexander Graf [mailto:agraf at suse.de]
Sent: Monday, May 16, 2016 1:09 PM
To: Amit Tomer <[email protected]>
Cc: Bhupesh Sharma <[email protected]>; york sun <[email protected]>; u-boot at lists.denx.de; Peter Newton <[email protected]>
Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

Quoted 3 lines

Am 16.05.2016 um 08:58 schrieb Amit Tomer <[email protected]>:

Quoted 1 line

On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma

Quoted 8 lines · <[email protected]> wrote:

Quoted 2 lines

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.

Quoted 6 lines

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.

From: Alexander Graf [mailto:agraf at suse.de]
Sent: Monday, May 16, 2016 5:51 PM

Quoted 13 lines · Bhupesh Sharma

Quoted 13 lines

-----Original Message-----
From: Alexander Graf [mailto:agraf at suse.de]
Sent: Monday, May 16, 2016 1:09 PM
To: Amit Tomer <[email protected]>
Cc: Bhupesh Sharma <[email protected]>; york sun <[email protected]>; u-boot at lists.denx.de; Peter Newton <[email protected]>
Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

Quoted 5 lines

Quoted 5 lines

Quoted 3 lines

Am 16.05.2016 um 08:58 schrieb Amit Tomer <[email protected]>:

Quoted 1 line

On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma

Quoted 1 line · <[email protected]> wrote:

Quoted 1 line

Note that UEFI firmware support is already available on LS2080A-

RDB

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

and allows Booting distributions like CentOS on the same.

Sorry to intervene here but it's about having the EFI support

inside

Quoted 1 line

Quoted 1 line

Quoted 1 line

u-boot itself that may *not* required to have separate UEFI

firmware

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 6 lines

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.

Quoted 2 lines

EFI application support in u-boot doesn't present a solution to

things

Quoted 3 lines

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.

From: Alexander Graf [mailto:agraf at suse.de]
Sent: Monday, May 16, 2016 7:21 AM
To: Bhupesh Sharma <[email protected]>; Amit Tomer <[email protected]>
Cc: york sun <[email protected]>; u-boot at lists.denx.de; Peter Newton <[email protected]>
Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

Quoted 37 lines · Bhupesh Sharma

Quoted 30 lines

-----Original Message-----
From: Alexander Graf [mailto:agraf at suse.de]
Sent: Monday, May 16, 2016 1:09 PM
To: Amit Tomer <[email protected]>
Cc: Bhupesh Sharma <[email protected]>; york sun <[email protected]>; u-boot at lists.denx.de; Peter Newton <[email protected]>
Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

Quoted 3 lines

Am 16.05.2016 um 08:58 schrieb Amit Tomer <[email protected]>:

Quoted 1 line

On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma

Quoted 8 lines · <[email protected]> wrote:

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 6 lines

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.