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

[Alexander Graf <agraf@suse.de>]

On 04/26/2018 10:20 AM, Michal Simek wrote:
> On 26.4.2018 09:08, Alexander Graf wrote:
>>
>>> Am 26.04.2018 um 08:25 schrieb Michal Simek <michal.simek@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@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.

Well, instead of the current "mmc0 mmc1" boot targets you would 
introduce an "mmc" boot target that probably needs to call C code to do 
the device walking. That way the environment would be unchanged 
regardless of the target system.

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

I'm not sure EBBR is going to help here.

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

Yes, I think as a first approximation it's fine to have mmc0/mmc1 
entries in the static boot target list and just blank/remove the 
bootcmd_mmc{0,1} ones that don't exist on boot.


Alex