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 2472DEB64D7 for ; Tue, 20 Jun 2023 22:11:59 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6F79E8609B; Wed, 21 Jun 2023 00:11:57 +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="Pfb/XouM"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6D4BE860AC; Wed, 21 Jun 2023 00:11:55 +0200 (CEST) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 E4D97847D5 for ; Wed, 21 Jun 2023 00:11:51 +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-x131.google.com with SMTP id e9e14a558f8ab-3422b25556dso16556825ab.2 for ; Tue, 20 Jun 2023 15:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687299110; x=1689891110; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vW6P5ozJfcwGkN9MBKSThsP0bpgR6dW6HOAjxEcAED0=; b=Pfb/XouMMaY4Wuhhyd7cH+NMEtP49hPpVBTU6a/KuPlnGcF0bDhpX044lIedt5t8cb wFPjKcBeuJLf1N3wUjfFCs6+eCw2BwWq95n7KayW6eVSWEXoe/u2pA1BVeJpgPHLgfnx WpE3rUNetBUQvkX/kkFyQF11Cw/DMxD5cfdwskfPYuJcDNpjNJ+X/Zu4GN2UA6Zt5Lcc 0GM4nPsm6C30/C6mJRVeN3UNgomtCsUbYjUVYecFFw3xVfhtmqAWmdmG1hzGMTbswLpZ nue3dBYirJjUOpwS00ML0vSHV3KRhPXuIruWxgHZgjazIQo6jKz3BdAnizsoBjl7jPbk vw9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687299110; x=1689891110; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vW6P5ozJfcwGkN9MBKSThsP0bpgR6dW6HOAjxEcAED0=; b=QnDbpXxDFQ9nV94+3Sr1INpP8+lVMBU7UlEsvnnphw9qEFdRCr/UuLE1+4cJwAlo2o eYlGkvd3Su5OV2jDTi1dnjimZLyAqk4VWg+Q5DEZajNYvIQIiAFSMwM9Cw5duD71pBFx hk7eXEPIk+4ED0LQdvgVr5mmEJbyo9kfqDCJkafFcjpdL6N2xPwQ4TWr6cLtJzZzIDrO O4Y6DofPPZnEITg9n7irBw9slQJKi0x0bAPXUQOhmwU43CdkrCedIGTOxoDx3iqR6GSd 6L91pcUcaNUAAfkPcet0uk9sVB1RL5tb/UulqL7CJtOR0FJzzfi8YAMwU9ZygWYhW5tD XXCQ== X-Gm-Message-State: AC+VfDxGlVTrMjQWUJ8/2+h7QS8f27o1IwOEmuUgc4HeuLuJZEjkIkmp uipLCKcSkFMuUGLr7Pp0idOoeXoP/ao= X-Google-Smtp-Source: ACHHUZ5HAyUErXNdRZtA42zjEyH0MS+30NB90DECsAawhif3Z7+GbuhoGXP/6yAd+e0kB2MOsVmoog== X-Received: by 2002:a92:dc4d:0:b0:33b:363d:27eb with SMTP id x13-20020a92dc4d000000b0033b363d27ebmr9104855ilq.30.1687299110270; Tue, 20 Jun 2023 15:11:50 -0700 (PDT) Received: from ?IPV6:2001:470:42c4:101:2cfd:d8b2:d8cf:2d95? ([2001:470:42c4:101:2cfd:d8b2:d8cf:2d95]) by smtp.gmail.com with ESMTPSA id l15-20020a92280f000000b00341f8926cecsm860378ilf.73.2023.06.20.15.11.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jun 2023 15:11:49 -0700 (PDT) Message-ID: Date: Tue, 20 Jun 2023 16:11:48 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support Content-Language: en-US To: Andre Przywara Cc: u-boot@lists.denx.de References: <20221206004549.29015-1-andre.przywara@arm.com> <04c52801-a6d0-033b-c7f4-613e0b789d96@gmail.com> <20230612012056.65883683@slackpad.lan> <20230615010754.503f4912@slackpad.lan> <71369065-8727-c011-0f29-fa33e0eb785c@gmail.com> <20230620134243.3af983b8@donnerap.cambridge.arm.com> From: Sam Edwards In-Reply-To: <20230620134243.3af983b8@donnerap.cambridge.arm.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 Andre, On 6/20/23 06:42, Andre Przywara wrote: > So yeah, the request of a "Enter FEL" command came up multiple times, but > so far no one could be bothered to implement this properly. The idea would > be to have a generic command (more like "fel-reset" than efex), and > allow each SoC (family) to implement this differently, as every > SoC requires something a bit different here (32-bit vs. 64-bit, having an > RTC vs not, etc). > > If you could post your solution somewhere, we could start this effort. > There was some patch for the H3 already, and it's relatively > straight-forward on the newer SoCs (H616, IIRC), so if at least two > popular, but different SoCs would be supported, we could make sure to have > the right abstractions in place. I already have a "go_to_fel()" that does the right thing to enter FEL from the SPL; I would pretty much just need to introduce the following per-SoC(-family) functions: - bool sunxi_fel_flag_test(void) - void sunxi_fel_flag_clear(void) - void sunxi_fel_flag_set(void) The "fel-reset" command (which is easier to type than what I have, "run fel_do_enter") would then call sunxi_fel_flag_set() and initiate a reset, and the SPL's early init just has to do sunxi_fel_flag_test() -> sunxi_fel_flag_clear() -> go_to_fel(). Seems easy enough. Could you recommend to me a sufficiently different chip to test my abstractions against? Something ARMv8 and *without* RTC? I can then send in a series adding FEL support for that. (Also, did that H3 patch actually land? I didn't see anything but want to know if I should be refactoring my approach to extend what that H3 patch does or not.) > Ah, depending on the BSP kernel is indeed quite bad. I wonder what > features of the kernel you rely on that upstream does not have? Or is it > more about the BMC userland parts that are married to the Allwinner kernel > and its own interfaces? I don't fully know; getting the kernel back on mainline is, as I said, a push for another day. I'm very much making a point of not looking into it before the bootloader can be upgraded to something that isn't a crashy, hard-to-update, failure-prone mess. (I'm working in "biggest fire, first out" order.) That said, the first such dependent feature that leaps to mind is the AWNAND driver's CONFIG_AW_SPINAND_SIMULATE_MULTIPLANE, which logically interleaves pages of the NAND in a different ordering vs. what the physical NAND (and mainline's spi-nand driver) does. Alas this is a feature we're dependent on not because it provides benefits to our users (it does not, and in downstream discussions I've been soapboxing about how it's likely wearing down people's NANDs) but because the boards are flashed at the factory with this flag enabled so we need it set for the NAND to be accessible. We've experimented with reflashing the board with that flag disabled, but that has so far only resulted in corrupted flash. Hope is not lost, though, for I have a half-written tool which shows some promise in being able to "unscramble the egg" and migrate existing NANDs over to the correct layout. That should be sufficient to get mainline U-Boot (and Tina Linux with the flag disabled) working, but I have no idea about mainline Linux still: this would only peel back one layer of the onion, and I don't know whether the next obstacle will be easier, harder, or about the same difficulty. But it does mean that, for now, we're stuck with Tina Linux. > Final DT is a noble goal, but in reality there will always be room for > improvement and additions. So what we typically do is to start with a > simple .dts for the kernel tree, describing the basic peripherals, and > everything that already works and is not subject to debate. If in doubt, > include a node, and we will comment. Could you prepare such a patch? The peripheral-describing .dts that I have is for Tina Linux, and uses incompatible compatibles (ha), includes, dt-bindings, temporary hacks while better driver support can be developed, and would otherwise not fly upstream. I can send it in *anyway* if for some reason you think that's a good idea, but I really don't see that as being anything other than a waste of time. As well, I can't write a fresh .dts for mainline (one more likely to be accepted on the list). A mainline kernel has never been booted on this board, so I would do no better at this than a kernel contributor selected at random. The best I can do now is write something that *looks* like the correct .dts. As I keep saying, that may change in the future. But the answer today is still "no, I cannot." > This > should not contradict any DT nodes that U-Boot uses, so it's not a double > effort. True, in theory it *shouldn't* but in practice, I've found it does. One way I've been bitten is that the sunxi SPI driver in U-Boot doesn't support Quad-SPI, so if the DT says the SPI-NAND is connected with a bus width of 4, the SPI-NAND driver requests Quad-SPI transfers, but the SPI master driver has no idea that it needs to handle the transfer any differently, and we're left with corrupt NAND reads/writes. Without Quad-SPI support in U-Boot's master driver (and/or, better yet, a U-Boot equivalent to Linux commit 83596fbeb5) -- also a push for another day -- I have no choice but to give U-Boot a specially edited version of the DT that omits this property. > This would mean we have a *second* board DT for the T113s SoC in the > kernel, which always helps to improve quality and prevents hacks that just > work on the MangoPi. Besides, the TuringPi board is an actually useful > application of the SoC, deployed and available, in contrast to just some > development board from Chinese websites. > And once this is merged, we could just copy this over to U-Boot and add > the defconfig and any other support patches there. See below. >> ...but for now it's very much meant to be out-of-tree. :) >> >> (I also do not work for the company that produced this board -- I'm just > > Ah, that would have been a first anyway ;-) Oh? What would have been a first? I could pass it along to my contact at this company and encourage him to get involved in some way. I'm sure they'd appreciate the opportunity for the good press associated with being the first at something in the F/OSS world, and it might help to get them in the habit of cooperating closely with upstream (to make it less likely that they just fork things the moment upstream doesn't solve some problem they're having). > Yeah, I understand it's not the most grateful job to chase up on doing > things properly and stay on with the upstreaming process. Ultimately it's > the right thing to do, though, and will save you hassle over time. Plus we > (the community) will help you with that, and you'd get a second commit in > the kernel ;-) Ideologically-speaking, this is music to my ears, and I think we would even be having this same discussion were our roles reversed: we do both agree fully on the (mutual) benefits of upstream contribution. But even more ultimately: the available time on any given day is limited, and I have to choose my battles. There are often things that either require less effort, save an even greater hassle over time, or provide more urgently-needed benefits, which (pragmatically speaking) ought to take priority. That doesn't mean the other lower-priority items have no benefit, it just means they should not be done *now.* > Cheers, > Andre Likewise, Sam