[PATCH] sunxi: Bring back SD card as MMC device 0

Andre Przywara andre.przywara at arm.com
Mon Apr 26 13:27:05 CEST 2021

On Sun, 25 Apr 2021 18:03:05 +0530
Jagan Teki <jagan at amarulasolutions.com> wrote:

Hi Jagan,

thanks for your input!

> On Sun, Apr 25, 2021 at 3:30 PM Andre Przywara <andre.przywara at arm.com> wrote:
> >
> > On Fri, 16 Apr 2021 12:08:09 +0100
> > Andre Przywara <andre.przywara at 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].

> 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?



More information about the U-Boot mailing list