From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 03 Jun 2021 08:55:24 +0200 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by lore.white.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1lohGG-0001be-Fb for lore@lore.pengutronix.de; Thu, 03 Jun 2021 08:55:24 +0200 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lohGF-0003O5-Br for lore@pengutronix.de; Thu, 03 Jun 2021 08:55:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References: 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=tICdEBLKUwpjtuqYEUtU15TRMMVNeNBUUFPO2wbrXUw=; b=isD8p5WFQS4D1V TjzWb15WQuXW6cXFiSV896EJHdzR6FNJJ9Ha4KsAcJPiKz0gnl702mg1+4Z3fpNmnpJ2uo40167Ev zqc7iJ0eSNmtyQvyHGeFv2WPqCzeO4zbrdPG3Z1jeYQN58jCGFVOOGXkalzdc1666lYbkHiqq4qdq r2wv64CNYxC/oVImkp9fvagTKNUvBMF9nQH7cdtFTAF5HR/zez4xWvst4Kpl1KWpUkrbeK67eF2fb 1DaGhGUzT9bUs70tixR1Wn5yTIXberE6InQ7X9JcTJNvyNpQFwAXpCGGiHAMqhVQwroPASTSdMIyj ygCjrWXoWVjlFZXqxPHw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lohEm-007Nfz-Ng; Thu, 03 Jun 2021 06:53:52 +0000 Received: from mail.thorsis.com ([92.198.35.195]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lohEf-007NfZ-Md for barebox@lists.infradead.org; Thu, 03 Jun 2021 06:53:47 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.thorsis.com (Postfix) with ESMTP id 6FBEFF2F for ; Thu, 3 Jun 2021 08:53:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.thorsis.com Received: from mail.thorsis.com ([127.0.0.1]) by localhost (mail.thorsis.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uybzc2TinPoK for ; Thu, 3 Jun 2021 08:53:43 +0200 (CEST) Received: by mail.thorsis.com (Postfix, from userid 109) id 2D3F3F5C; Thu, 3 Jun 2021 08:53:41 +0200 (CEST) Date: Thu, 3 Jun 2021 08:53:32 +0200 From: Alexander Dahl To: Ahmad Fatoum Cc: barebox@lists.infradead.org, mgr@pengutronix.de, ore@pengutronix.de Message-ID: Mail-Followup-To: Ahmad Fatoum , barebox@lists.infradead.org, mgr@pengutronix.de, ore@pengutronix.de References: <20210602102524.20034-1-a.fatoum@pengutronix.de> <20210602102524.20034-2-a.fatoum@pengutronix.de> <0b45648b-cbc9-cc72-6004-f82a4909153f@pengutronix.de> Content-Disposition: inline In-Reply-To: <0b45648b-cbc9-cc72-6004-f82a4909153f@pengutronix.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210602_235346_086300_EFD25258 X-CRM114-Status: GOOD ( 39.97 ) X-BeenThere: barebox@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "barebox" X-SA-Exim-Connect-IP: 2607:7c80:54:e::133 X-SA-Exim-Mail-From: barebox-bounces+lore=pengutronix.de@lists.infradead.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.ext.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Subject: Re: [PATCH 2/3] ARM: at91: mmc-xload: allow overriding card capacity X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on metis.ext.pengutronix.de) Hello, thanks for the surprisingly detailed explanation. Am Thu, Jun 03, 2021 at 08:28:48AM +0200 schrieb Ahmad Fatoum: > Hei hei Alex, > > On 03.06.21 07:34, Alexander Dahl wrote: > > Am Wed, Jun 02, 2021 at 12:25:23PM +0200 schrieb Ahmad Fatoum: > >> The PBL MMC driver works with the assumption that the BootROM has left > >> the SD-Card in transfer mode. There seems to be no definitive way > >> to find out whether a running card is high capacity (> 2G) or not, > >> but we need this info when reading, because default capacities accept > >> their read offset in bytes while high capacity deal in 512 byte blocks. > > > > I'm a little surprised there's not. Once like ten years ago I had to > > write a SD card driver for a small microcontroller. In the firmware I > > switched to high capacity mode just based on the Card Capacity Status > > (CCS) bit in the Operation Conditions Register (OCR) of the SD card. > > Got that after sending advanced command 41 (send op cond) to the card. > > barebox proper does that in sd_send_op_cond() as well. > > > Not sure if it's that easy, or if that command was only sent under > > certain conditions, but I can not remember just guessing high capacity > > based on some heuristics nor hard code it. > > When you build at91_multi_defconfig, multiple images are generated, currently: > > barebox-at91sam9x5ek.img > barebox-at91sam9263ek.img > barebox-microchip-ksz9477-evb.img > barebox-microchip-ksz9477-evb-xload-mmc.img > barebox-sama5d27-som1-ek.img > barebox-sama5d27-som1-ek-xload-mmc.img > barebox-groboards-sama5d27-giantboard.img > barebox-groboards-sama5d27-giantboard-xload-mmc.img > barebox-skov-arm9cpu.img > > This patch here is for the xload-mmc.img's, which result from the barebox > prebootloader. The PBL sets up SDRAM and chainloads barebox proper from the > same boot medium that itself came from. Because of this limited scope, it can > reuse here the SD-card setup done by the BootROM. The BootROM leaves the > SD-Card in transfer mode, allowing the PBL to directly read blocks off the > SD-Card without a full MMC/SD-Card driver. I see. > > We certainly used low > > capacity (like 32 MB for example) and high capacity cards (4G or more) > > with that system. > > > > You probably already looked for a reliable way to detect this. I was > > just curious why this needs to be hardcoded. > > It's been a while since I wrote the sama5d27 PBL support (which the > sama5d3 support I am patching here is based on), but I recall that > the send op cond did not work in transfer mode, the card must be sent > into idle first, i.e. reset. I'd be happy if there happens to be indeed > a way to deduce high capacity mode without resetting and having to repeat > the SD-Card setup in the first boot stage. Makes sense. And yes, IIRC correctly, that register read happens while setting up the card. If you can not or don't want to reset the card again, it's probably tricky. > There are of course alternatives to this: > - build barebox twice with different configs for first and second stage: > There is already code for this (chainload code that uses barebox proper > driver that fully re-initializes card). The first stage config needs to > be small to fit into SRAM, so we can no longer generate both stages from > the same multi-image config as we already do. > > - provide full MMC support in PBL: > The objective so far was to keep PBL code to the bare minimum. Doing > full MMC setup there violates that. > > > AFAIK, all barebox platforms, except for i.MX, went for the first alternative > of having multiple configs. barebox on i.MX doesn't have this issue, because > it reads barebox from offset 0 of the SD/MMC, which works equally well whether > booting off default or high capacity cards. > > I like how the i.MX defconfig generates more than a hundred images in one go and > wanted AT91 to have something similar, but the fact that FAT needs to seek around > (offsets != 0) complicates this. > The trade off I took then was assuming high capacity cards and postpone the decision > on how to deal with default capacity cards in PBL into the future. I just had the idea of just trying to read from different small offsets and compare it with the block you get from offset 0. For example reading 500 bytes from offset 10 and reading 510 bytes from offset 0 in byte mode should match the last 500 bytes, but probably in block mode that wouldn't match. But that's obviously highly dependent on the card content and more an ugly hack, right? Greets Alex _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox