[PATCH v2] zynqmp: Dynamic setting mmcdev and mmcroot

[Michal Simek]

On 2/3/25 13:19, Szőke Benjamin wrote:
> 2025. 02. 03. 9:01 keltezéssel, Michal Simek írta:
>> Hi,
>>
>> On 2/1/25 15:06, egyszeregy at freemail.hu wrote:
>>> From: Benjamin Szőke <egyszeregy at freemail.hu>
>>>
>>> Dynamic setting mmcdev and mmcroot.
>>> Then when boot linux, we can have correct "root=/dev/mmcblk[x]p2"
>>
>> This is source of the problem. That root partition is second is only your 
>> choice and doesn't need to be choice for others.
>>
>> There is no reason to write this logic to C code.
>>
>> We are exporting variable bootseq which you can use to determine which 
>> controller was used by boot device and can be used for rootfs.
>>
>> Here is how you can compose your bootargs.
>>
>> ZynqMP> setenv bootseq 50
>> ZynqMP> setenv bootargs root=/dev/mmcblk${bootseq}p2
>> ZynqMP> pri bootargs
>> bootargs=root=/dev/mmcblk50p2
>>
>> Or you should look at devnum which is setup when mmc boot is called.
>>
>> bootcmd_mmc0=devnum=0; run mmc_boot
>> bootcmd_mmc1=devnum=1; run mmc_boot
>>
>> Thanks,
>> Michal
> 
> Thanks the details. Usually i use extlinux.conf to provide kernel arguments for 
> root mounting.
> 
> Does it mean "bootseq" contains the real mmc blk index number what is really 
> need in this situation when we like to get it work dynamically?

I do normally using aliases for sdhci that's why number is read from aliases 
node and it's position. U-Boot is also using this number and bootseq is aligned 
with it.
You can test it.
Setup
aliases {
	mmc9 = &sdhci1;
};

And if this is your boot device you should get bootseq as 9.



> 
> As i understand, in extlinux.conf, there are two possbile easy solution which 
> will provide the same what i thought.
> 
>      "APPEND root=/dev/mmcblk${bootseq}p2 rw rootwait"
> 
> or
> 
>      "APPEND root=/dev/mmcblk${devnum}p2 rw rootwait"
> 

yes. It depends what you want to do. In our systems we have only 2 sdhci 
controllers that's why only boot from mmc0 or mmc1 is created. And that's likely 
distro boot limitation. With stdboot I think it shouldn't really matter.

And this code is prioritizing boot device by changing boot_targets variable.
It means bootseq/bootnum should be the same but doesn't need to be based on 
above test.

> 
> But i have a little confusion about "bootseq" env variable. Why is it good to 
> save it as a hex env variable?
> https://elixir.bootlin.com/u-boot/v2025.01/source/board/xilinx/zynqmp/zynqmp.c#L491
> 
> To use it as a varibale for mmc blk it would be more safe/fit to save it in a 
> normal decimal number.
> 
> Wont be it better to save it also as a more verbosable name ("mmcblk") in a 
> ulong decimal format? It would be more clear for all people that it is usable to 
> use for mmc blk number also.
> 
>      env_set_ulong("mmcblk", (unsigned long)bootseq);

As above these values are pretty much 0 or 1 all the time. And value above 9 was 
never tested. I think there is a small mess in U-Boot in general if value should 
be dec or hex and it is command dependent.
In this particular case likely switching it from hex to dec make sense because 
mmc dev command also treat that value as dec.
And dt specification is not talking if it is hex or dec but likely it is dec.

Thanks,
Michal




-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs