From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D1E2C47082 for ; Mon, 24 May 2021 00:49:15 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D11BF6105A for ; Mon, 24 May 2021 00:49:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D11BF6105A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id BD0BC82E39; Mon, 24 May 2021 02:49:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 5110E82E3E; Mon, 24 May 2021 02:49:08 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id AFCC381CE7 for ; Mon, 24 May 2021 02:49:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 29BAC31B; Sun, 23 May 2021 17:49:04 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1F2573F73D; Sun, 23 May 2021 17:49:03 -0700 (PDT) Date: Mon, 24 May 2021 01:48:38 +0100 From: Andre Przywara To: Jagan Teki Cc: Simon Glass , Jernej Skrabec , Samuel Holland , U-Boot-Denx , linux-sunxi Subject: Re: [PATCH] sunxi: Bring back SD card as MMC device 0 Message-ID: <20210524014838.0b313b40@slackpad.fritz.box> In-Reply-To: References: <20210416110809.25421-1-andre.przywara@arm.com> <20210425105933.7345f9d7@slackpad.fritz.box> <20210426122705.41904045@slackpad.fritz.box> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.102.4 at phobos.denx.de X-Virus-Status: Clean On Mon, 26 Apr 2021 17:52:51 +0530 Jagan Teki wrote: Hi Jagan, > On Mon, Apr 26, 2021 at 4:57 PM Andre Przywara wrote: > > > > On Sun, 25 Apr 2021 18:03:05 +0530 > > Jagan Teki wrote: > > > > Hi Jagan, > > > > thanks for your input! > > > > > On Sun, Apr 25, 2021 at 3:30 PM Andre Przywara wrote: > > > > > > > > On Fri, 16 Apr 2021 12:08:09 +0100 > > > > Andre Przywara 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. So I had a look at fastboot, and posted an RFC[1] to try and fix this properly. This seems to somewhat work, but there are more assumptions in (sunxi) U-Boot about the eMMC being device 1 (boot source, distro_boot scripts, ...). I agree that we should remove this assumption, but this requires more work and scrutiny to find all those cases. For now the change in numbering breaks right, left, and centre: boot.scr cannot be found anymore, fastboot cannot find the SD card, custom scripts stop working. So I would very much like to merge this patch here, to fix the currently bad user experience and get a clean v2021.07 release. We can meanwhile look into a proper solution for this problem, to become more robust against enumeration changes (for instance due to aliases). Thanks, Andre