[U-Boot] [PATCH] ARM64: zynqmp: Add support for standard distro boot commands

[Michal Simek <michal.simek@xilinx.com>]

On 1.6.2016 16:12, Alexander Graf wrote:
> 
> 
> On 01.06.16 15:08, Michal Simek wrote:
>> Nand and QSPI are not defined now but this will be extended.
>> Based on selected bootmode boot_targets are rewritten.
>> Patch also contains detection if variables are saved. If yes don't
>> rewrite boot_targets variable.
>>
>> Also move variable setup to the end of file because SCSI needs to be
>> defined before others macros are using it.
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>>
>> Patch depends on
>> "env: Setup GD_FLG_ENV_DEFAULT flag when default environment are used"
>>
>> ---
>>  board/xilinx/zynqmp/zynqmp.c    | 20 +++++++++-----
>>  include/configs/xilinx_zynqmp.h | 59 ++++++++++++++++++++++++++++++-----------
>>  2 files changed, 57 insertions(+), 22 deletions(-)
>>
>> diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
>> index 4623cd49e9c7..46c332215b6b 100644
>> --- a/board/xilinx/zynqmp/zynqmp.c
>> +++ b/board/xilinx/zynqmp/zynqmp.c
>> @@ -215,6 +215,11 @@ int board_late_init(void)
>>  	u32 reg = 0;
>>  	u8 bootmode;
>>  
>> +	if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
>> +		debug("Saved variables - Skipping\n");
>> +		return 0;
>> +	}
>> +
>>  	reg = readl(&crlapb_base->boot_mode);
>>  	bootmode = reg & BOOT_MODES_MASK;
>>  
>> @@ -222,31 +227,32 @@ int board_late_init(void)
>>  	switch (bootmode) {
>>  	case JTAG_MODE:
>>  		puts("JTAG_MODE\n");
>> -		setenv("modeboot", "jtagboot");
>> +		setenv("boot_targets", "pxe dhcp");
> 
> Is there a particular reason you're overwriting the boot_targets rather
> than prepending them?
> 
> If I plug in an SD card with U-Boot on it, but my OS is on a SATA
> attached disk (which is how I currently use the ZynqMP), this would set
> the boot_targets to SD rather than "SD first, default list later".
> 
> If we instead do something like
> 
>   boot_targets = "pxe dhcp " + getenv(boot_targets);
> 
> we would maintain a workable fallback path. Yes, we might check a target
> device twice, but since we know that it fails I don't think it's too
> much of a problem.

No problem to do it but maybe in mmc0 case we should also remove mmc0
from boot_targets which is already there.

Thanks,
Michal