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 48FE3EB64D7 for ; Wed, 21 Jun 2023 20:22:52 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 827EA86351; Wed, 21 Jun 2023 22:22: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="f7ZoS4bd"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E1C2B85BFB; Wed, 21 Jun 2023 22:22:48 +0200 (CEST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 213A886351 for ; Wed, 21 Jun 2023 22:22:43 +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-io1-xd2e.google.com with SMTP id ca18e2360f4ac-76c64da0e46so283351539f.0 for ; Wed, 21 Jun 2023 13:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687378962; x=1689970962; 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=tgb5hYURPd5aAmGu7fugpKL4xF5WpNktMP0qTBOrHpk=; b=f7ZoS4bdRXJ3Y+G85goJboIbD4of9V+jEY9K3OcDrH0HXQrnOU7Jw+fC0hyZTJT/pN JOxQeFhN0cAFoZUNLHQoBn5G7cW4MrFrciAg633bsa0yrfmeNQEwSyk/gUnli6iYaqz5 GGAGnxxPi1VkuA11CiYyEEYScqGLbW0H71Dh+Dl1X17AGSiUWTM4FQOpwUxCocXr+1U9 t2jL749kL772EoV+2893JdXbLJXcIDuvNw5cn85zvUXQM7UDcAyd89d8VsnP8F+D7fC4 z1DgH3OpZa+MWBpAyAoXgalje4VIN5UH+OltFtntJq4GFeorLO6yXww/KzArO4qStZ4t E+kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687378962; x=1689970962; 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=tgb5hYURPd5aAmGu7fugpKL4xF5WpNktMP0qTBOrHpk=; b=aKetX7agpR2CjobsuDq7yyNcH0fWthV0V0bMfnjwCPeTedwIzaEpVD9NLOld6CTBkI b2fRhdTVw+ZTeqmAIMDTYTgxa6HpCD3RQw32GgasDO+VoTKvWMj0QwLvpJXQ7K4o3Lh8 cK2HNJIPb0L0cR0cEWHcsVVQyRvwc0o2bCwQaKfAkDTYR9pL21KRn0N2jgf2ZiWO1hkj i/q38iYtgdfu2ZpzGDQPfsU+7uHj3cNXRBnLXOGtnfOurX1v/9UxIj7yJUNSQE47Wa0L +IBGqtRhF8GJtKRpiHC4IE5+aKaJSIQ9Yc9VAGQAPbBZGuCmjymD0jbkdZo0hofvEDc9 ZiOw== X-Gm-Message-State: AC+VfDzRLoolqh9nc+x/4VVERGdUeEwGAVJV4WhkQcSIlxuiO4bwqtIU IuS4C7TcqHE1f/x85b/TDR4sI7WsIHE= X-Google-Smtp-Source: ACHHUZ6p6pi868g74o4Zmp2Apcy+OCO/vYzX7PcqycTl2VBM+E3HrVxeAM3R84wqtSDB52F/RAmwvw== X-Received: by 2002:a5e:c013:0:b0:77e:2964:266e with SMTP id u19-20020a5ec013000000b0077e2964266emr14772347iol.0.1687378961519; Wed, 21 Jun 2023 13:22:41 -0700 (PDT) Received: from ?IPV6:2001:470:42c4:101:ca89:22a7:eedf:934f? ([2001:470:42c4:101:ca89:22a7:eedf:934f]) by smtp.gmail.com with ESMTPSA id u8-20020a02aa88000000b0040fd1340997sm1544103jai.140.2023.06.21.13.22.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jun 2023 13:22:40 -0700 (PDT) Message-ID: <8a6a9a82-4e13-df41-2c45-3d6380c509cf@gmail.com> Date: Wed, 21 Jun 2023 14:22:39 -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> <20230621115547.23878c39@donnerap.cambridge.arm.com> From: Sam Edwards In-Reply-To: <20230621115547.23878c39@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 On 6/21/23 04:55, Andre Przywara wrote: > On Tue, 20 Jun 2023 16:11:48 -0600 > Sam Edwards wrote: > > Hi Sam, > > pleasure to write with you ;-) Hi Andre, Likewise! > Well, so this is actually the fallback implementation which should > somewhat work on most SoCs: set a flag, reset, and catch the flag in > the SPL. For modern SoCs with CPU hotplug support (the H616 is one one > of those, and it looks like the T113s is as well), there is actually a more > direct route: Oh man, I would definitely prefer a direct route that doesn't require the SPL coming up a second time, but... > We put some magic and the FEL entry address into some special memory > locations, then just reset. Now the *BootROM* will do the check already, > and branch to the provided entry point, which would be the FEL routine. > This doesn't rely on a prepared SPL to be loaded, so works without a > boot device with mainline U-Boot around. > Refer to section 3.4.2.3 and 3.4.2.4 of the T113-S3 user manual (v1.1). > According to this, the magic would be 0xfa50392f, the magic's address is > 0x070005C0, and CPU0's entry point address would be in 0x070005C4. I had a > proof of concept implementation for the H616 using this method. ...I tried this and it seems that the 070005C* block hardware-resets to zero before BROM runs. Is there a softer reset method you had in mind that would avoid this? > The only > problem left would be that someone needs to clean the magic afterwards, > otherwise any follow-up reset would trigger FEL mode again. That's at least pretty fixable though: instead of setting the entry address to the FEL entry point, set it to a thunk placed in SRAM that clears the flag before continuing onward to FEL. >> 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 think all ARMv8 parts have an RTC, so your generic approach might work > there as well. The complication is that the SPL switches to AArch64 very > early, in hand-stitched AArch32 assembly, check out > arch/arm/include/asm/arch-sunxi/boot0.h. > The check would need to be coded like this, then. > >> 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.) > > https://patchwork.ozlabs.org/project/uboot/patch/c211aa414c59e7275fef82bf6f0035276d6e29f3.1656875482.git.msuchanek@suse.de/ This approach seems close to mine, only my go_to_fel() enters by way of return_to_fel() after first modifying fel_stash.lr, since the return_to_fel() mechanism already takes care of restoring the core to a BROM-friendly state. > One might abuse the board as a T113s dev > board, maybe ;-) Does it work without any of the modules populated? Sure, if you're thinking about getting one. You just need an ATX-pinout PSU to power the BMC (it runs off of the 5V standby rail). > ... having a board. So far you are the one contributor with access to > the hardware, so: thanks for volunteering! ;-) Andre, please, I know you're being tongue-in-cheek here, but I said "no." We should have reached the agree-to-disagree point 2 emails ago: you've made your (very compelling) case for why downstream would benefit from the early expertise of the upstream DT reviewers, and how upstream would benefit from having the DT for a second "real" T113-using board, but at some point you need to trust that I understand that and that I must therefore have very good reasons not to be distracting myself with trying to (dual-)boot a mainline kernel yet. One thing at a time, y'know? :) > The U-Boot build system support some kind of build time DT "overlay" > feature: You put a file with the same name, but ending in > "-u-boot.dtsi" in the arch/arm/dts directory, and it will be included > into the DT which gets embedded into the U-Boot image. See > arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dts for an > example, and doc/develop/devicetree/control.rst for the proper > documentation. > So we upstream a minimal, non-controversial and non-contradicting base > .dts into the kernel tree, and can fix things up for the time being > using this method. This hack can then go away if either the mainline > kernel DT gets fixed and/or U-Boot learns the quad-SPI trick. Oh, good to know! I'll try to remember that this option exists when the time comes to use it. > Someone from the board vendor company actually actively adding upstream > support for their device early. There were some examples in the past > where employees participated in upstreaming, but I cannot remember > seeing this too often when it comes to the initial DT support. I brought this email thread to the attention of the firmware development team at this company, then. No promises (they seem to have their hands sufficiently full with userspace work) but FWIW my opinion of them is that they do have a community-centric and F/OSS-oriented mindset, so with a bit of luck they may make themselves known on the upstream mailing lists at some point. Thank you for your ongoing efforts, Sam