| Message ID | 1463142095-182586-6-git-send-email-agraf@suse.de |
|---|---|
| State | Superseded |
| Delegated to: | York Sun |
| Headers | show |
> -----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 > <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 > > _______________________________________________ > 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.
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
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(-)