[U-Boot] [RFC PATCH 1/2] arm64: zynqmp: Setup the first boot_target at run time

Michal Simek michal.simek at xilinx.com
Thu Apr 26 08:20:32 UTC 2018


On 26.4.2018 09:08, Alexander Graf wrote:
> 
> 
>> Am 26.04.2018 um 08:25 schrieb Michal Simek <michal.simek at xilinx.com>:
>>
>>> On 26.4.2018 08:14, Alexander Graf wrote:
>>>
>>>
>>>> On 25.04.18 14:38, Michal Simek wrote:
>>>> Detect mmc alias at run time for setting up proper boot_targets sequence.
>>>> The first target has to correspond with boot mode.
>>>>
>>>> The purpose of this patch is to get rid of CONFIG_ZYNQ_SDHCI0/1
>>>> parameters in full U-Boot.
>>>> Unfortunately this patch can't remove it because there is missing
>>>> mmc implementation for SPL_DM_SEQ_ALIAS.
>>>>
>>>> Also xilinx_zynqmp.h only setup boot commands for mmc0 and mmc1.
>>>> It means using aliases with higher number won't work. But switching
>>>> between mmc0 and mmc1 should work properly.
>>>>
>>>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
>>>> ---
>>>>
>>>> Not sure how exactly to tune BOOT_TARGET_DEVICES_MMC to have functions
>>>> for different aliases ID. I can simply setup devnum based on dev->seq
>>>> and also generate the whole bootcmd_mmc0
>>>>
>>>> bootcmd_mmc0=setenv devnum 0; run mmc_boot
>>>> bootcmd_mmc1=setenv devnum 1; run mmc_boot
>>>>
>>>> The second patch is doing that.
>>>> But still if you setup alias to higher number mmc core is not mmc dev
>>>> command is not able to work with it.
>>>
>>> I don't understand this sentence.
>>
>> Imagine case that you have mmc1000 = &sdhci0;
>> That 1000 is integer and u-boot is in hex that's why 1000 = 0x3e8.
>>
>> It means boot_targets will start with "mmc3e8 +static one"
>>
>> That's why
>> bootcmd_mmc3e8=setenv devnum 3e8; run mmc_boot
>>
>> needs to be generated. But xilinx_zynqmp.h is only setting these lines
>> for mmc0 and mmc1.
> 
> Ok, so what we really want is a distro.c file and corresponding boot_target lines that generate boot target variables for every device enumerated in the system on boot.
> 
> The reason we don‘t have that yet I guess is because most targets target one SoC/board that has a known set of devices. The more generic we make things, the more we have to enumerate at runtime.
> 

yes, and do this only in case of when variables are not restored. It
means only when default one are used.

And it is really a question if make sense to change current distro
default or just wait for EBBR.

For zynqmp device itself using mmc0/mmc1 should be enough.

Thanks,
Michal



More information about the U-Boot mailing list