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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B6484EB64D9 for ; Sat, 17 Jun 2023 20:59:53 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D9A6A85D8B; Sat, 17 Jun 2023 22:59:50 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="caO5swrM"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 24DEB862E7; Sat, 17 Jun 2023 22:59:48 +0200 (CEST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id BE34D846A5 for ; Sat, 17 Jun 2023 22:59:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=cfsworks@gmail.com Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-340b8d6aabbso5883495ab.0 for ; Sat, 17 Jun 2023 13:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687035584; x=1689627584; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NI6YN9dIJG6eRdtJKsQc6VbqeVY1FWqwwC90bzyk88M=; b=caO5swrMAPFs6z3EObiB6umz0x1vZgC6s+cInCTCFrWbW+UEPJZ91EAH3jZwfmknYC MVjqX5FmgAbTTAC7jufe/wXARp9VrXvDUfsHt8yBCYNrqef2sEgpQhtzVl4dE7t8eEdl ldDs5UM4ALZRlrEpAdD+FU9dInQ2zw4y9AJj1+uo4X99UNeR58rNHE2tF3+h7qZVapP3 PH9y32Kq5CNIP7jSoeHpiW71A807Civ/d+u320hcNx5v8RLLf20mvBHG+P5PSyVuv7yA hNonkeMT/XmxZGpUAYZSzIx5YwqpUbeOaljaC+aNzaPjc+8zVF6T/4/0biZ+5KIkKPQL Ndow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687035584; x=1689627584; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NI6YN9dIJG6eRdtJKsQc6VbqeVY1FWqwwC90bzyk88M=; b=WS0Vr9dJIIZ2Pmrr4LpEyOHOfkyqKCtgoJYhfgHdaEm4QhaB0EUp7ILGHnuoGEiMBW obvI5y97Bp+LdgQef3cOfZRq+LHRi8+CLDVLEpXenNNDW5q/+5AvIMHnsO4lLhAKeqXX DAY82gqXSLOyOE0SRnbJPtFG9gGuBzGCyi6XgF2xkBDjJN2qfbMjyAlRcAgOGYxXjRij RS8FhQ742bpTDgsj98Ju8hiAXV5NAjQ5afJNjNnoxRDhDJIdTqZkRGCAxpFE4BVgOZqg n4miL48MDD+pfPBQ3uso0QZUgcUSfzxZwrAwH8dufgpgVQj1P8D92avcT0GYZxLDaPtX Jj2w== X-Gm-Message-State: AC+VfDwI0NjJ1it5Umdd1kIki1JPhSHdjucP5y63tsgEX7RBX4+Rsem1 CMcJWJ8bssl9LXL6Q9ZARgq/iFk5g5nFtw== X-Google-Smtp-Source: ACHHUZ7F5DkyWjUHSFiPU5NCXg5+k6TjZsksTZjm7W9+kE1XImRNrhcFH5KrYGjGZ2v27o22jlAAvA== X-Received: by 2002:a05:6e02:48c:b0:340:6e65:896b with SMTP id b12-20020a056e02048c00b003406e65896bmr1986704ils.15.1687035584276; Sat, 17 Jun 2023 13:59:44 -0700 (PDT) Received: from ?IPV6:2001:470:42c4:101:6623:622f:4fd3:b1a9? ([2001:470:42c4:101:6623:622f:4fd3:b1a9]) by smtp.gmail.com with ESMTPSA id r13-20020a92d44d000000b0032ca1426ddesm7505814ilm.55.2023.06.17.13.59.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Jun 2023 13:59:43 -0700 (PDT) Message-ID: <8034158c-03ab-7488-6afa-a67f04264705@gmail.com> Date: Sat, 17 Jun 2023 14:59:42 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 0/8] SUNIV SPI NAND support in SPL Content-Language: en-US From: Sam Edwards To: Icenowy Zheng , u-boot@lists.denx.de Cc: Andre Przywara References: <20221014030520.3067228-1-uwu@icenowy.me> <2bd3c41aafb918d545f666d7cf7136b8b21df5fb.camel@icenowy.me> <574e7234-b3a7-3e25-06bf-76902c802275@gmail.com> In-Reply-To: <574e7234-b3a7-3e25-06bf-76902c802275@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.103.8 at phobos.denx.de X-Virus-Status: Clean Hi again Icenowy, On 6/6/23 17:09, Sam Edwards wrote: > Still, I believe it's sensible that, when we know for sure we're coming > from SPI-NAND (because it's a newer sunxi that reports 0x04, or we know > from the suniv stack-checking hack), we should call that its own SPL > load method, which does not fall back to SPI-NOR. The SPI(-NOR) load > method naturally has to implement the try-NAND-first logic for some of > these SoCs, but perhaps we could call it a "quirk" and only do that for > chips that aren't known to report SPI-NAND directly? Since other methods that care about flash type (e.g. env_get_location) don't understand BOOT_DEVICE_SPI to mean "SPI, but the actual flash type is ambiguous," I'm starting to think we need to resolve the ambiguity *before* the load method runs. What are your thoughts on this: 1. Introduce SUNXI_BOOTED_FROM_SPI_NAND, value 4 (matching the value used by Allwinner's newer BROMs). 2. Map SUNIV_BOOTED_FROM_NAND to SUNXI_BOOTED_FROM_SPI_NAND. 3. Map SUNXI_BOOTED_FROM_SPI_NAND to BOOT_DEVICE_NAND (and not _SPI). 4. Implement the SPI-NAND stuff to provide `nand_spl_load_image` (so that the common SPL framework's NAND loader can take care of it). Possibly go even further and implement the methods needed by the UBI loader too. 5. On sunxis (e.g. V3s) which are known to report SUNXI_BOOTED_FROM_SPI for SPI-NAND, add a small check to sunxi_get_boot_device() which disambiguates this situation by probing for SPI-NAND. If #4 isn't really feasible, we might instead want to introduce a BOOT_DEVICE_SPI_NAND, but I don't know if adding sunxi to the list of platforms that have their own BOOT_DEVICE_ names is a great call. In any case, I'd hope also to see some kind of bad block handling in here -- a simple check for a bad block each time we get to page 0 (which skips to the next block) should be pretty easy, don't you think? Any thoughts? Any other way I can be of service? (Feel free to delegate some of these ideas to me if you think they're good but don't have the time to execute them!) Warm regards, Sam