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 29AE3C77B7A for ; Wed, 17 May 2023 03:31:04 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 73F3F86688; Wed, 17 May 2023 05:31:02 +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="aBSIvbHR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2861686690; Wed, 17 May 2023 01:53:48 +0200 (CEST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 49EEE86688 for ; Wed, 17 May 2023 01:53: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-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-24e4f674356so205454a91.3 for ; Tue, 16 May 2023 16:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684281223; x=1686873223; 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=fKZki6CuqGUnumBXhULY1ZA8l3gBqrRMT1v0Wd2vL3U=; b=aBSIvbHRvujxh0y8IIEfSzoBBD7R9RUs54/DbCV2LQnhC3ypx0it/t27FDis9HTDIO +H7QIf1xDwjZR5+Nf+kX6kbq1Pa5GIShbilhTg8JPvccFCyA2/CKMyajlOoi3XdwHvcp gQPprYjaQvWvVjMvBPavDRSd96c8kNk+MM9ynTpvEghDG6PSSkipxTtvvg0e2k4itxBC TSFKObRXlIWyeuT8FPvVwWj5GERj8EHLx1317KIA/mvZUAW0tAbJ1KuLhXieGvD616py 8+FKw5OTbIgR9kKC6fYtZHGPQAk02WXL7wH5zVK8Xo8/d2L27WLRUFKT5qKwiZ5mCjM+ P7Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684281223; x=1686873223; 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=fKZki6CuqGUnumBXhULY1ZA8l3gBqrRMT1v0Wd2vL3U=; b=aJAjA1uDQcs5iM8C9V/vVO3U65qa/iyGs4YNsjabt7RHHfhriV1fefutj7B3I/Xoey aZwAvSXXLisIs4L2qZRHqsXG8DKzRFi6xxl1ol+9lhejOFVawMmaRRxsrtBDHewbRwBF qqPfyTcDdmr6wmaxVlyTf+TtaB2Ra9fHrTYo3uW7l6fGYuiZr5xxg8LIUu9zFMBj+TG5 hKzV8QoHjBrXjTP5osx0DD803evHH6OBJ2r+Izen7Lq6ic8onc/ZwRdo1J1gVzYFj+2s zoGpaN817uQ3YV7wHdJuUSs/DhbN7vWHhci3tmthV9yqdJj9qyb3T43E/swSRov3LxSd yK8Q== X-Gm-Message-State: AC+VfDxW/v20ONT3nRgikVUjELxjYZ/siIuTe75q7pIanV9PoUSIDpVu x3E7WOR3cqWz0XQG1I0rFlxuMVeHJ2GjB+Dk X-Google-Smtp-Source: ACHHUZ71VpcdNE6g6MJu7l1Xrg/fvyGdfN0Fu2HzJ6pniIhKx9zLM0eXH61/cQHRSRZKjJaKcY+wCw== X-Received: by 2002:a17:90b:1e0c:b0:23b:3699:b8a9 with SMTP id pg12-20020a17090b1e0c00b0023b3699b8a9mr38747886pjb.17.1684281223550; Tue, 16 May 2023 16:53:43 -0700 (PDT) Received: from [10.64.107.252] (static-198-54-134-172.cust.tzulo.com. [198.54.134.172]) by smtp.gmail.com with ESMTPSA id 23-20020a17090a0c1700b0024e3d26f644sm176605pjs.3.2023.05.16.16.53.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 May 2023 16:53:43 -0700 (PDT) Message-ID: <2d8c3fce-dfbf-37ec-f7f1-21684c5d1da6@gmail.com> Date: Tue, 16 May 2023 17:53:38 -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: [RFC PATCH 08/17] sunxi: introduce NCAT2 generation model Content-Language: en-US To: Andre Przywara Cc: Samuel Holland , Jagan Teki , u-boot@lists.denx.de, Icenowy Zheng , Jernej Skrabec References: <20221206004549.29015-1-andre.przywara@arm.com> <20221206004549.29015-9-andre.przywara@arm.com> <20230516220850.7ab973b1@slackpad.lan> From: Sam Edwards In-Reply-To: <20230516220850.7ab973b1@slackpad.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 17 May 2023 05:31:00 +0200 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 5/16/23 15:08, Andre Przywara wrote: > This whole memory map is somewhat of a legacy. Apart from a few > addresses for the SPL needs we shouldn't have those defines at all. > Some symbols are needed because there are other macros using them, > although these then are eventually unused. > I have some patches to remove most of the symbols, and patch 14/17 > demonstrates some idea how to pin this down to what's really needed. > > For this particular case: this was copied from the H6 memory map, some > addresses are just plain wrong for the D1 family. I will try to remove > them as much as possible, leaving only the ones needed in. I see - the only "tangible" concern I had was the access to prcm->res_cal_ctrl done in arch/arm/mach-sunxi/clock_sun50i_h6.c:clock_init_safe This doesn't appear to upset the silicon but also doesn't seem necessary either -- and with how tight of a memory footprint SPL has to fit into, I wanted to check whether this was just something undocumented or dead code that needed to be removed. It sounds like it's mostly the latter. > So where did you see problems? If you would (wrongly) reference > PortL somewhere in SPL GPIO code, it would use a wrong pointer, but at > least the code would still compile fine, wouldn't it? The specific patch I had to apply (to arch/arm/mach-sunxi/board.c) was: /* Update PIO power bias configuration by copy hardware detected value */ val = readl(SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL); writel(val, SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL); - val = readl(SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL); - writel(val, SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL); + if (SUNXI_R_PIO_BASE) { + val = readl(SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL); + writel(val, SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL); + } With SUNXI_R_PIO_BASE being 0, this was actually attempting to write to BROM. This might also be something that doesn't really upset the silicon, though: my debug environment is a concolic emulator I quickly hacked up to trace MMIO accesses, and it flagged the write to BROM as an error. It was easier to patch the SPL than to have the emulator ignore the error (and verify that the T113 was cool with it). Since this kind of extraneous/erroneous init code tends to remain undetected when the symbols they need are dummied-out like this, I figured I'd give a nudge in the direction of instead *removing* the symbols where appropriate and fixing whatever breaks -- especially since we really need to be thrifty about SPL size. But that might also be something that happens in a later cleanup pass when the patchset is being prepared for upstream inclusion. :) > P.S. Could you try the github post? Then compiled and booted fine for > me, and includes the DRAM code as well now: > https://github.com/apritzel/u-boot/commits/t113s-mq-r-WIP Ooh, more up-to-date code, thanks for the link! I'll switch to using this instead going forward. My pulls from that branch might be relatively infrequent since I'm also working on some patches for better Clang compatibility concurrent with the efforts here. Is this email thread a good venue for feedback against that branch or would you prefer that I use GitHub issues instead? Warm regards, Sam P.S. My target is the BMC on the Turing Pi 2 board. They have the same SoC and (apparently) UART console configuration, but the differences end there: in particular, my target supports boot from either/both microSD+SPI-NAND. I might have to start pushing for room for SPI drivers in the SPL soon. :)