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....@nxp.com>:
>>>
>>>> On 05/13/2016 07:32 AM, Alexander Graf wrote:
>>>>
>>>>> Am 13.05.2016 um 16:26 schrieb Stuart Yoder <stuart.yo...@nxp.com>:
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alexander Graf [mailto:ag...@suse.de]
>>>>>> Sent: Friday, May 13, 2016 7:22 AM
>>>>>> To: u-boot@lists.denx.de
>>>>>> Cc: Stuart Yoder <stuart.yo...@nxp.com>; york sun <york....@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 <ag...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
