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 8E732EB64D7 for ; Fri, 16 Jun 2023 16:27:37 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D2E7085F2B; Fri, 16 Jun 2023 18:27:34 +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="JREc5ukr"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5813B86245; Fri, 16 Jun 2023 18:27:33 +0200 (CEST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 983568467C for ; Fri, 16 Jun 2023 18:27:30 +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=bigunclemax@gmail.com Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-98646e2fc70so136554466b.1 for ; Fri, 16 Jun 2023 09:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686932850; x=1689524850; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Cbo+Vhs8dqJ4Jh5mNWkWRR+1FQGEiu47lWfDx1Qd5R8=; b=JREc5ukr4jdWyZejzJygUABCkCqOvxmO2qJWoueeHwKly7g2X5IhIbZhUIYSVzmtgO AxmQIt1Igh60aDu2JQAgDHEZx6B6aL8QneZl2bJu5LYdvZr42Wnl8BEy9X/nvfM+4mlh Aybhs7i7K1b+E2KkPTH/sPyqUpQGQ6aXbfrePSx5gcRfdRQzET4DrBuP0D5OZ6RLI1ID osiOFOkIKFytl04ezYVlIzuXPKVmXspYQfjCbe56AdfFDvzSUcML+1Bkr5dUk6IPJqb5 LG4faCMOzfT/4ozwFS7oG8KVPUvOmx2+vZOs1zmpFtWdK38OtY9I0xHu6EZ5SRuj+LBL P0Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686932850; x=1689524850; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Cbo+Vhs8dqJ4Jh5mNWkWRR+1FQGEiu47lWfDx1Qd5R8=; b=HZVap0EmMVC42zJwz4XL5kHwOlUzG9WWuOWrk0opBw2Z0AfOELx+13UXbO1irQFJtO tkOYSIOJr2HPQMBNncGNJhFuCLkLObcH1RMg59540uBkq9s2U/gkhUfDf/7+d6M4f36m P7ldE9ONjR42aiLCTkpWf7LAlHA5Ig4v4TYlks3X2rMqSwbQnir5WvmhD03j2gHvNllW iGqvaFcccaOUCYd+Rf0xmz/lwaqKYLyN8DSGiPg73vv0BjkNqMpcMnNfPiqk3p7ovj1P t+su7osGxFKNVBacO12XrbKvmLoqfjKwJ3hpWTWctkzMnMf1ybFh3FuBmhDXwjF8yid6 ZIfQ== X-Gm-Message-State: AC+VfDynD5N9+xaivIU/rt746G68k+6CptJNuPeBV+ljehwJFvSZ/30K YuLy++RTqpc9cZDQTn4UpX3PrMhdFI1UrpEN3PE= X-Google-Smtp-Source: ACHHUZ4ExUAicLr4FcIZsr0wDUWe+PouCg+rXls/eg0Jd1gmCS6dD+p8WQtMho27SbrETpoQ1Kjw2uz4LTUTBtFXv40= X-Received: by 2002:a17:906:354e:b0:94a:5819:5a2b with SMTP id s14-20020a170906354e00b0094a58195a2bmr2295477eja.33.1686932849754; Fri, 16 Jun 2023 09:27:29 -0700 (PDT) MIME-Version: 1.0 References: <20221206004549.29015-1-andre.przywara@arm.com> <04c52801-a6d0-033b-c7f4-613e0b789d96@gmail.com> <20230612012056.65883683@slackpad.lan> <20230616165902.0b6eea86@donnerap.cambridge.arm.com> In-Reply-To: <20230616165902.0b6eea86@donnerap.cambridge.arm.com> From: Maxim Kiselev Date: Fri, 16 Jun 2023 19:27:16 +0300 Message-ID: Subject: Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support To: Andre Przywara Cc: Sam Edwards , u-boot@lists.denx.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Sam, =D0=BF=D1=82, 16 =D0=B8=D1=8E=D0=BD. 2023=E2=80=AF=D0=B3. =D0=B2 18:59, And= re Przywara : > > On Mon, 12 Jun 2023 15:18:17 -0600 > Sam Edwards wrote: > > Hi Sam, > > something regarding "reset" below ... > > > On 6/11/23 18:20, Andre Przywara wrote: > > > Thanks for the update and the list! Can you confirm where you > > > still needed code changes compared to say my github branch plus the > > > changes we already discussed? Trying some guesses below, please confi= rm > > > or deny: > > > > Preeeeetttttyyy much everything I've changed locally has been submitted > > to the list or discussed in the relevant patchset. Have you updated you= r > > GitHub branch recently (past couple of weeks)? I haven't been watching > > it but I can pull it again and see which of my local changes are still > > required. > > > > >> I have a build of U-Boot for my target, complete with: > > >> - UART3 initialized correctly > > > > > > this is problematic because of the other pinmux used on your board, > > > which cannot easily be encoded alongside the existing UART3 pinmux? > > > > Actually no, my board's UART3 is on PB6/PB7, nice and standard. > > > > >> - DRAM coming up correctly > > >> - SPL sets configured boot clock correctly > > > > > > This should work as per github? > > > > Yep, everything was working satisfactorily once I figured out I needed > > to set CONFIG_SYS_CLK_FREQ to get acceptable boot speeds. > > > > >> - SPI-NAND support (SPL and U-Boot proper) > > > > > > This is with Icenow's series? Any D1 specific changes needed there? > > > > Yes, with Icenowy's series (322733). > > > > I learned that the BROM sets the boot medium code to 0x04 when it's an > > SPI-*NAND* (while older chips used 0x03 for "it's either SPI-NOR or > > SPI-NAND, good luck figuring out which"). Since `env_get_location` > > assumes BOOT_DEVICE_SPI is NOR (and my target needs to load env from UB= I > > iff booting from NAND), I'm hoping I can convince Icenowy to separate > > out the SPI-NAND and SPI-NOR load methods entirely (vs. her current > > try-NAND-then-NOR approach) with the aid of some disambiguation logic t= o > > probe for an SPI-NAND on the older chips known to report these as 0x03. > > > > I also needed Maksim's patch series (355747) to support the D1 SPI mast= er. > > > > >> - MMC support (SPL and U-Boot proper) > > >> - SPL boot from FEL > > > > > > again worked already in github? > > > > Yes and yes. I was just confirming they're good; no local work needed > > from me here. > > > > >> - USB gadget support > > > > > > So with the fixed SUNXI_SRAMC_BASE you said it worked? What about the > > > USB PHY? That needs at least wiring in the compatible string? If you > > > have such a patch, can you please rebase it on top of my v2 USB PHY > > > series and post that? > > > > Yes, with corrected SUNXI_SRAMC_BASE -- though I also needed my patches > > to make musb-new/sunxi.c use the UDC gadget model in DM (series 358842)= , > > as I don't think there's another way to init the controller at runtime. > > > > I can't say whether the endpoint limit is correct or that mUSB *host* > > operation works. > > > > The USB PHY only required that CONFIG_PHY_SUN4I_USB be enabled. The > > correct compatible is already wired up. It does look like your PHY > > series drops the explicit requirement to set PHY_SUN4I_USB so that's > > better than what I was doing (adding a `select` directive under R528). > > > > I can test your series if you want but I doubt it intersects my work > > here in any significant way. > > > > >> - Ethernet MAC+PHY support > > > > > > Anything surprising here? Is that using an already supported external > > > PHY? > > > > The only surprise was this was how I noticed that CONFIG_CLK_SUN20I_D1 > > was not being implicitly enabled. Enabling that was then how I found > > that the clock driver wasn't compatible with current upstream (which I > > already mentioned). > > > > The PHY is external and already supported, adding it to my DT required > > very little work. > > > > >> - I=C2=B2C support * > > >> - GPIO support (LEDs, buttons, misc. board management) > > > > > > again should work out of the box, minus your board specific > > > configuration? > > > > GPIO is completely OotB, yes. I=C2=B2C is OotB once MVTWSI_CONTROL_CLEA= R_IFLG > > is set correctly. (The pinctrl requirements for it are a little harder, > > more on that below.) > > > > >> - `reset` working (requries CONFIG_SYSRESET unset, WDT key) > > > > > > Isn't "CONFIG_SYSRESET unset" a hack? I dimly remember we had this fo= r > > > some other SoC initially, but later got rid of it? > > > > Unsetting it is required for reset_cpu() to be defined. Your patchset > > updates that function (albeit without adding the WDT key, so the curren= t > > patch is broken) to support NCAT2 already. U-Boot has no driver for > > "allwinner,sun20i-d1-wdt-reset", so this is the only way for `reset` to > > work. > > So I had a look at this, and it's a bit surprising: > The watchdog driver already supports "allwinner,sun20i-d1-wdt" for a > while. We don't need to list the "-reset" version, because the normal > compatible name acts as a fallback string. However the DT node in the bas= e > .dtsi sets: status =3D "reserved"; for this (and the other) watchdog, so > U-Boot's DM (correctly!) ignores those devices. Trying to figure out why. > Adding: > &wdt { > status =3D "okay"; > }; > to sun8i-t113s.dtsi fixes that for me, now the reset command works. I did it the same way for myself. =F0=9F=99=82 But I thought this was the w= rong way and the watchdog should be managed by a trusted OS or something like that. (which we don't have in the mainline yet)