
On Mon, Apr 26, 2021 at 4:57 PM Andre Przywara andre.przywara@arm.com wrote:
On Sun, 25 Apr 2021 18:03:05 +0530 Jagan Teki jagan@amarulasolutions.com wrote:
Hi Jagan,
thanks for your input!
On Sun, Apr 25, 2021 at 3:30 PM Andre Przywara andre.przywara@arm.com wrote:
On Fri, 16 Apr 2021 12:08:09 +0100 Andre Przywara andre.przywara@arm.com wrote:
Hi,
Commit 2243d19e5618 ("mmc: mmc-uclass: Use dev_seq() to read aliases node's index") now actually enforces U-Boot's device enumeration policy, where explicitly named devices come first, then any other non-named devices follow, without filling gaps.
For quite a while we have had an "mmc1 = &mmc2;" alias in our sunxi-u-boot.dtsi, which now leads to the problem that the SD card (which was always mmc device 0) now gets to be number 2. I guess this breaks quite some boot scripts, and is confusing at least.
Just add an explicit mmc0 alias in the very same file to fix this and restore the old behaviour.
Can someone please say if this is the right solution? I think the SD card has always been mmc device 0 in U-Boot, so I think it's worth keeping that. Just not sure if this is the right way of fixing that?
Playing with aliases always gets confused and might get a different behavior, IMHO.
I am not so sure about that, since aliases force a fixed numbering, so it should be less confusing. We have the same problem in the kernel now, and Samuel sent some patches to have aliases in the mainline DTs as well [1].
Okay.
Detect the dev number by U-Boot itself and look at traverse bootenv by all possible dev numbers in sunxi-common.h, but
OK, I will have a look at how the automatic distro boot behaves with this change. My concern was more the interactive user, who is used to have the SD card at device 0 (I certainly am).
this has one slide effect that we mark mmc2 as devnum 1 for the sake of fastboot so if we mark fastboot number for specific board properly (by static or runtime) then explicit aliases wouldn't required.
Ah, good point, thanks for the heads up. I guess this is the actual reason for the alias in our -u-boot.dtsi? Maybe we find a different way to let fastboot find the eMMC? Then we can drop the extra mmc1 alias, get our numbering back, and can cope with the incoming aliases from the mainline DTs as well?
Agreed.