From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Fri, 25 Jan 2019 13:43:26 +0100 Subject: [U-Boot] [PATCH 2/2] arm64: zynqmp: Define distro boot commnads for qspi and nand In-Reply-To: References: <212d51b3-1440-415c-40c6-ba4815dd20fc@suse.de> <7f4f331b-57b3-46fe-9ecc-7d083ab19474@xilinx.com> Message-ID: <665ef6e6-e92e-c6e0-adbe-abd93dfd3663@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 25.01.19 13:13, Michal Simek wrote: > On 25. 01. 19 13:00, Alexander Graf wrote: >> >> >> On 25.01.19 12:56, Michal Simek wrote: >>> On 25. 01. 19 12:25, Alexander Graf wrote: >>>> >>>> >>>> On 24.01.19 16:31, Michal Simek wrote: >>>>> From: Siva Durga Prasad Paladugu >>>>> >>>>> This patch adds distro boot commands for qspi and nand. The >>>>> distro boot commands now reads the script from flash offset >>>>> of 63.5MB and executes it. >>>>> >>>>> Setup default location via script_offset_f to 63.5MB to match the most >>>>> xilinx reference boards. 512kB allocated space for script size >>>>> (script_size_f) should be more than enough to cover custom boot logic. >>>>> >>>>> Signed-off-by: Siva Durga Prasad Paladugu >>>>> Signed-off-by: Michal Simek >>>>> --- >>>>> >>>>> include/configs/xilinx_zynqmp.h | 32 ++++++++++++++++++++++++++++++++ >>>>> 1 file changed, 32 insertions(+) >>>>> >>>>> diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h >>>>> index d0515fa9bc46..5eeae6331e1c 100644 >>>>> --- a/include/configs/xilinx_zynqmp.h >>>>> +++ b/include/configs/xilinx_zynqmp.h >>>>> @@ -129,6 +129,8 @@ >>>>> "kernel_addr_r=0x18000000\0" \ >>>>> "scriptaddr=0x02000000\0" \ >>>>> "ramdisk_addr_r=0x02100000\0" \ >>>>> + "script_offset_f=0x3e80000\0" \ >>>>> + "script_size_f=0x80000\0" \ >>>>> >>>>> #if defined(CONFIG_MMC_SDHCI_ZYNQ) >>>>> # define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1) >>>>> @@ -160,8 +162,38 @@ >>>>> # define BOOT_TARGET_DEVICES_DHCP(func) >>>>> #endif >>>>> >>>>> +#if defined(CONFIG_ZYNQMP_GQSPI) >>>>> +# define BOOT_TARGET_DEVICES_QSPI(func) func(QSPI, qspi, 0) >>>>> +#else >>>>> +# define BOOT_TARGET_DEVICES_QSPI(func) >>>>> +#endif >>>>> + >>>>> +#if defined(CONFIG_NAND_ARASAN) >>>>> +# define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand, 0) >>>>> +#else >>>>> +# define BOOT_TARGET_DEVICES_NAND(func) >>>>> +#endif >>>>> + >>>>> +#define BOOTENV_DEV_QSPI(devtypeu, devtypel, instance) \ >>>>> + "bootcmd_qspi0=sf probe 0 0 0 && " \ >>>> >>>> This >>>> >>>>> + "sf read $scriptaddr $script_offset_f $script_size_f && " \ >>>>> + "source ${scriptaddr}; echo SCRIPT FAILED: continuing...;\0" >>>>> + >>>>> +#define BOOTENV_DEV_NAME_QSPI(devtypeu, devtypel, instance) \ >>>>> + "qspi " >>>>> + >>>>> +#define BOOTENV_DEV_NAND(devtypeu, devtypel, instance) \ >>>>> + "bootcmd_nand0= nand info && " \ >>>> >>>> and this will emit errors if no device was found, right? That might be >>>> confusing for a user, if all he sees is a scary "device not found" >>>> message which simply only occurs because he doesn't have nand populated. >>> >>> As you see above it is enabled only when devices are enabled. >>> For generic u-boot for all zynqmp targets it should be correct to emit >>> error message that nand is not detected if it is not present on the >>> board. :-) >>> All these boot modes will be tried if the first boot mode fails. >> >> Well, it's conditional on whether the driver is available, not whether >> the board actually exposes a flash device, right? >> >> So think about the generic case - one U-Boot binary for all targets. >> What are you going to do there? That needs to have all possible boot >> target devices enabled, but how do you know whether an actual QSPI chip >> is attached to the SPI controller? > > yes - sure all devices needs to be enabled. You don't know that. You > need to try to probe it and access it. > >> >> I also think this problem is bigger than this patch, so don't take my >> comment as a nack. I'm just trying to raise that we should start to >> think about cases where "probe fails" is not an error and thus should >> not print an error message. > > What is the current behavior if you failed to access network or SD and > images is on SATA which is the last (or different order). > I expect that scanning finds nothing. > Nand/qspi should be just behave the same. It depends on the target; some will just not complain if no device was found, others will. It's a bigger task, let's defer it to later :) Alex