From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5AD2672 for ; Fri, 30 Apr 2021 10:56:38 +0000 (UTC) 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 32134113E; Fri, 30 Apr 2021 03:56:32 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE4243F70D; Fri, 30 Apr 2021 03:56:30 -0700 (PDT) Date: Fri, 30 Apr 2021 11:55:45 +0100 From: Andre Przywara To: Maxime Ripard Cc: Chen-Yu Tsai , Samuel Holland , Jernej Skrabec , devicetree , linux-arm-kernel , linux-sunxi@lists.linux.dev, linux-kernel Subject: Re: [PATCH 0/2] sunxi: Enforce consistent MMC numbering Message-ID: <20210430115545.6a45d1dc@slackpad.fritz.box> In-Reply-To: <20210430091035.i4zoyzb4c2l22msb@gilmour> References: <20210419025246.21722-1-samuel@sholland.org> <20210419095443.1548432e@slackpad.fritz.box> <20210430091035.i4zoyzb4c2l22msb@gilmour> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 30 Apr 2021 11:10:35 +0200 Maxime Ripard wrote: Hi Maxime, > On Mon, Apr 19, 2021 at 09:54:43AM +0100, Andre Przywara wrote: > > On Mon, 19 Apr 2021 11:17:19 +0800 > > Chen-Yu Tsai wrote: > > > > Hi, > > > > > On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland wrote: > > > > > > > > Dealing with the inconsistent numbering has been a major pain, and > > > > there is a solution with (as far as I can tell) no tangible downsides. > > > > So let's use it. > > > > Thanks Samuel for sending this! > > > > > > Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help > > > > when referencing the whole, unpartitioned device, like is needed for > > > > updating the bootloader and firmware. So for the use case of "write a > > > > bootloader to the SD card, regardless of where the board is currently > > > > booted from", I know of two options: > > > > - Dig around in sysfs to find the mmc number from the MMIO address, > > > > which means I have to know the MMIO addresses for every SoC, or > > > > - Apply patches like these. > > > > > > > > Samuel Holland (2): > > > > ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering > > > > arm64: dts: allwinner: Enforce consistent MMC numbering > > > > > > > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++++++ > > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++ > > > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 6 ++++++ > > > > > > At least with Rockchip this is now done at the board level. IIRC it was > > > a request from other people to not do it at the SoC level. I don't recall > > > exactly who though. > > > > FWIW, I am very much in favour of these patches, at a SoC level: > > The *SoC* BootROM imposes an order, by probing the first (by MMIO > > address order) MMC controller first for boot devices. IIRC that's a > > different story for Rockchip? > > And if people really don't care about the order, then having a certain > > order doesn't hurt, so we could as well use the "natural" order, as it > > was before. > > This doesn't have anything to do with the BootRom though but what we > provide to the userspace? My argument was that there is a "natural" order, not only by the location in the MMIO space, but on a more logical level: the "first" SD controller is first checked by the BootROM, so the SoC puts a "number 0" tag on this particular one. This is just because I heard the (reasonable) argument that location in MMIO space should not be significant, and deriving an order from that is arbitrary. > The userspace has no guarantee about the > kernel enumeration order for any bus (but UART for some reason), I'm not > really sure why MMC would be an exception. Userspace is one thing, but arguably there are ways to find the partition you are looking for, because you have all the kernel *and* userlevel tools at hand. The question is whether this needs to be overly complicated and harder for the user. But the other, more pressing problem is the kernel-only code in init/do_mounts.c, which has very limited means to find a certain partition (see below). > Especially since the kernel will not try to catch up, this will be > bound to be broken on a regular basis. What do you mean with "will not try to catch up"? Do you mean there might be other kernel changes that spoil the numbering again, in the future? > And that aside, assuming that a device only has an eMMC this would > create the mmc2 device, which is completely weird and inconsistent > with how any other bus behaves. You have a point there, but I don't see how this would be a problem. I think one advantage is *consistent* numbering across reboots, so it will always be mmc2, even if you add a WiFi chip later (some boards have that as an option). Also those SD-card less system could surely override the labels in their board .dts files? > > Also UUIDs only help if you boot with an initramfs to resolve them, > > which proves to be extra pain if you don't compile kernels on the > > device, or not inside a distribution environment. > > I'm not sure what you mean? The kernel is perfectly able to resolve > them. You can also use PARTLABEL if you want something more user > friendly. init/do_mounts.c supports PARTUUID only, but most people/distributions use UUID, which is filesystem metadata, so not easily accessible for the kernel early and on a partition level only. And IIRC PARTLABEL is only available on GPT partitioned disks. Also PARTUUID is set at partition time, so a user formatting her own SD card (or just changing the partition table) will have a unique PARTUUID, and it cannot be used from within a filesystem image or prefabricated boot script to reference its own partition (in /etc/fstab). And in general UUIDs are not very human friendly, so their main domain is to be handled by code. I definitely don't memorise a single one of them, but I do remember root=/dev/mmcblk0p2. I find it *very* annoying to load my development kernel over TFTP, then booting them with the rootfs from SD card or eMMC, and seeing it fail about 50% of the time, because the numbering is off. Cheers, Andre 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=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable 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 1E580C433ED for ; Fri, 30 Apr 2021 10:58:48 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 73AF961400 for ; Fri, 30 Apr 2021 10:58:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 73AF961400 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Q+0+RCiJuKFoiGPC3K1OaPPH4msJ+PYcQZWM6nXiMWM=; b=IbqpN4ecWGyp4U/X7VCJ5S+jj cOGwLI3MonMScfrp+9+2M+p8IyIw5XNNVqGIPlENpZAPk5dsLjXbq5doL7OuU+VYnQ6XJFkvrwq7K G6Rl5vdCLdCopEymZY58hKYs/3WrKlXlCr0kixc+RLvRaZQTKGBifHy+PkgyXlTr67i/Q45jlQxR6 dugjxax/Nq7E5JC2SVyT9W6J/zQV8xZi2xkC0wGkMCNod3ndFIIUoUa6kw6oyJsWC5NOa8VY0ncIq PpvtTNfI0XHvyYbg16OTP23hoZGM/mWqGKwLRQSIAaJk6jtptevh8D2MfDs5dmIxnFK6REm5+YLcs TopjdAzcw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lcQpB-007hxG-Cw; Fri, 30 Apr 2021 10:56:45 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lcQp8-007hx2-G6 for linux-arm-kernel@desiato.infradead.org; Fri, 30 Apr 2021 10:56:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Sender:Reply-To:Content-ID:Content-Description; bh=Ul9y9dXHnqax8rUPYDZWwjdwuCiCUBKvS3mALX7ekac=; b=jq4uxoYtEED53eliVdc1PoM0UB Z1yt7NhQrlVvBYqm1g6kbr6molurc9RQ6s7DLVdfOmdUYrpa4EESVzzBrs8E3jHThqdD7X2HSRKLl KDmmR8732r2khl8iaYz5wfnPNe6IMjEzBfhfRNE4xFGOC3csR+RhkzRy2UYP7cOoHAUSEWrEsypCB Rp6Tk1gpRxRv7DxVh/NNp/rQvjJ1UpIVqZMyGrid0oq3Dsg/6BhKJERMufjulL3VwRSqFXd9oCY34 +uPCsOajTmHFOAG4epw7o17kO3vLLNx39SuKWhQA/XBOJghkE6KNOnfiXrACJ8pf3LBQHPkbn1ehD A+ynxuWA==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lcQp5-001JDr-5y for linux-arm-kernel@lists.infradead.org; Fri, 30 Apr 2021 10:56:40 +0000 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 32134113E; Fri, 30 Apr 2021 03:56:32 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE4243F70D; Fri, 30 Apr 2021 03:56:30 -0700 (PDT) Date: Fri, 30 Apr 2021 11:55:45 +0100 From: Andre Przywara To: Maxime Ripard Cc: Chen-Yu Tsai , Samuel Holland , Jernej Skrabec , devicetree , linux-arm-kernel , linux-sunxi@lists.linux.dev, linux-kernel Subject: Re: [PATCH 0/2] sunxi: Enforce consistent MMC numbering Message-ID: <20210430115545.6a45d1dc@slackpad.fritz.box> In-Reply-To: <20210430091035.i4zoyzb4c2l22msb@gilmour> References: <20210419025246.21722-1-samuel@sholland.org> <20210419095443.1548432e@slackpad.fritz.box> <20210430091035.i4zoyzb4c2l22msb@gilmour> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210430_035639_356193_D262BB1E X-CRM114-Status: GOOD ( 48.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 30 Apr 2021 11:10:35 +0200 Maxime Ripard wrote: Hi Maxime, > On Mon, Apr 19, 2021 at 09:54:43AM +0100, Andre Przywara wrote: > > On Mon, 19 Apr 2021 11:17:19 +0800 > > Chen-Yu Tsai wrote: > > > > Hi, > > > > > On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland wrote: > > > > > > > > Dealing with the inconsistent numbering has been a major pain, and > > > > there is a solution with (as far as I can tell) no tangible downsides. > > > > So let's use it. > > > > Thanks Samuel for sending this! > > > > > > Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help > > > > when referencing the whole, unpartitioned device, like is needed for > > > > updating the bootloader and firmware. So for the use case of "write a > > > > bootloader to the SD card, regardless of where the board is currently > > > > booted from", I know of two options: > > > > - Dig around in sysfs to find the mmc number from the MMIO address, > > > > which means I have to know the MMIO addresses for every SoC, or > > > > - Apply patches like these. > > > > > > > > Samuel Holland (2): > > > > ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering > > > > arm64: dts: allwinner: Enforce consistent MMC numbering > > > > > > > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++++++ > > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++ > > > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 6 ++++++ > > > > > > At least with Rockchip this is now done at the board level. IIRC it was > > > a request from other people to not do it at the SoC level. I don't recall > > > exactly who though. > > > > FWIW, I am very much in favour of these patches, at a SoC level: > > The *SoC* BootROM imposes an order, by probing the first (by MMIO > > address order) MMC controller first for boot devices. IIRC that's a > > different story for Rockchip? > > And if people really don't care about the order, then having a certain > > order doesn't hurt, so we could as well use the "natural" order, as it > > was before. > > This doesn't have anything to do with the BootRom though but what we > provide to the userspace? My argument was that there is a "natural" order, not only by the location in the MMIO space, but on a more logical level: the "first" SD controller is first checked by the BootROM, so the SoC puts a "number 0" tag on this particular one. This is just because I heard the (reasonable) argument that location in MMIO space should not be significant, and deriving an order from that is arbitrary. > The userspace has no guarantee about the > kernel enumeration order for any bus (but UART for some reason), I'm not > really sure why MMC would be an exception. Userspace is one thing, but arguably there are ways to find the partition you are looking for, because you have all the kernel *and* userlevel tools at hand. The question is whether this needs to be overly complicated and harder for the user. But the other, more pressing problem is the kernel-only code in init/do_mounts.c, which has very limited means to find a certain partition (see below). > Especially since the kernel will not try to catch up, this will be > bound to be broken on a regular basis. What do you mean with "will not try to catch up"? Do you mean there might be other kernel changes that spoil the numbering again, in the future? > And that aside, assuming that a device only has an eMMC this would > create the mmc2 device, which is completely weird and inconsistent > with how any other bus behaves. You have a point there, but I don't see how this would be a problem. I think one advantage is *consistent* numbering across reboots, so it will always be mmc2, even if you add a WiFi chip later (some boards have that as an option). Also those SD-card less system could surely override the labels in their board .dts files? > > Also UUIDs only help if you boot with an initramfs to resolve them, > > which proves to be extra pain if you don't compile kernels on the > > device, or not inside a distribution environment. > > I'm not sure what you mean? The kernel is perfectly able to resolve > them. You can also use PARTLABEL if you want something more user > friendly. init/do_mounts.c supports PARTUUID only, but most people/distributions use UUID, which is filesystem metadata, so not easily accessible for the kernel early and on a partition level only. And IIRC PARTLABEL is only available on GPT partitioned disks. Also PARTUUID is set at partition time, so a user formatting her own SD card (or just changing the partition table) will have a unique PARTUUID, and it cannot be used from within a filesystem image or prefabricated boot script to reference its own partition (in /etc/fstab). And in general UUIDs are not very human friendly, so their main domain is to be handled by code. I definitely don't memorise a single one of them, but I do remember root=/dev/mmcblk0p2. I find it *very* annoying to load my development kernel over TFTP, then booting them with the rootfs from SD card or eMMC, and seeing it fail about 50% of the time, because the numbering is off. Cheers, Andre _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel