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 X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6E23C432BE for ; Mon, 2 Aug 2021 13:04:34 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 2361260FC4 for ; Mon, 2 Aug 2021 13:04:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2361260FC4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C86A0833CD; Mon, 2 Aug 2021 15:04:31 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="NOiJFPNX"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 56D94833E0; Mon, 2 Aug 2021 15:04:29 +0200 (CEST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 C747D833B1 for ; Mon, 2 Aug 2021 15:04:25 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x836.google.com with SMTP id g11so11532684qts.11 for ; Mon, 02 Aug 2021 06:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=GOopY6OWWrIUJDlDMlGeagbpPsHFe6chKJPX6pSMJgs=; b=NOiJFPNXHMMR7lvAjKGUvqFENILtNv6K8EtlfSlqdQt5VQd4eJUEo0S+/yNsceNdbA QYayKHb71IRbYA0yktLm+TIv+bzyFP0ffrBln9UGjPA54rBOhBjae0t8el4T9F8kKnGg xgF5yvXhyMptlMtSB046Zhgw8KGMHSxufLzbM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=GOopY6OWWrIUJDlDMlGeagbpPsHFe6chKJPX6pSMJgs=; b=MRldcuSFa2m1wNbs18ktbUde8iM7pOMyjKFyJP7NPuKnPGsLi93zxWUquxNPzpQ0D5 MSRO2fGrWSVUIWXoCT0r3iOD1QGN35ccOy+AaA6T8cpDSC3VKihJko8hmNnIPWx2hkBj tihCNelKpsVUErrfCKCw+vvxugqjeD0unNa0xW4wiGZgpo2kaOTPJVUGvpVaALJoZFUR pGP88Wt+N8JvxVmHdIplsfnUKhVl4mq5NBHw6S3XSK/45/5eRB8uS1wGCuoYoVAVfzPV crm0VT/ttxZEXCXLqmK+Mk4/3KasZwg01ryxIK54HjFGbYWcShaeNLINQe7snCN/Mubl q6uQ== X-Gm-Message-State: AOAM5319dceHRyy4LBBTZ5JKyEBQCMi4JZY8MalJ9LaTRO0qlxWvR2JG lc7khG8guVInQDDYMXU4z6tObg== X-Google-Smtp-Source: ABdhPJw2OOqCMqFiYTao5y4XgrgJkwfy9QYTCQn0dwu+9fnJHi93DG4TkUqlbP5qTo92IkYiyRVqtg== X-Received: by 2002:a05:622a:134c:: with SMTP id w12mr13476041qtk.281.1627909464614; Mon, 02 Aug 2021 06:04:24 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-ed77-66b8-7f0a-3b78.res6.spectrum.com. [2603:6081:7b01:cbda:ed77:66b8:7f0a:3b78]) by smtp.gmail.com with ESMTPSA id n188sm6055635qke.54.2021.08.02.06.04.22 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 02 Aug 2021 06:04:23 -0700 (PDT) Date: Mon, 2 Aug 2021 09:04:21 -0400 From: Tom Rini To: Jan Kiszka Cc: Marek Vasut , U-Boot Mailing List , Hai Pham , Simon Goldschmidt , Stephen Warren , Lokesh Vutla Subject: Re: [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64" Message-ID: <20210802130421.GS9379@bill-the-cat> References: <20210729152307.GP9379@bill-the-cat> <20210729165802.GA9379@bill-the-cat> <446b4861-6987-092a-43ce-5d3aa322f8f3@denx.de> <7edb5a3f-9896-278d-fe41-e2d48bb8f974@siemens.com> <4602641b-34d2-22dc-01da-e8f46fcc1be3@denx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ihOCVMGS/Nm60Y8G" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean --ihOCVMGS/Nm60Y8G Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 02, 2021 at 01:54:57PM +0200, Jan Kiszka wrote: > On 02.08.21 13:38, Marek Vasut wrote: > > On 8/2/21 1:36 PM, Jan Kiszka wrote: > >> On 02.08.21 12:48, Marek Vasut wrote: > >>> On 8/2/21 11:37 AM, Jan Kiszka wrote: > >>>> On 02.08.21 02:54, Marek Vasut wrote: > >>>>> On 7/29/21 6:58 PM, Tom Rini wrote: > >>>>> > >>>>> [...] > >>>>> > >>>>>>>> so when did rcar3 introduce something there that shouldn't be > >>>>>>>> reserved?=A0 And you had phrased this to me on IRC as about rese= rving > >>>>>>>> spot > >>>>>>>> for ATAGS, and that not being needed of course on arm64.=A0 But > >>>>>>>> that's > >>>>>>>> not > >>>>>>>> what's going on.=A0 Perhaps the answer is that rcar3 needs to > >>>>>>>> introduce a > >>>>>>>> board_lmb_reserve to free the normal arch one and provide whatev= er > >>>>>>>> more > >>>>>>>> narrow scope it needs. > >>>>>>> > >>>>>>> Based on the commit message 2359fa7a878 ("arm: bootm: Disable LMB > >>>>>>> reservation for command line and board info on arm64") , this is > >>>>>>> about ATAGS > >>>>>>> and we really don't need to reserve those on arm64. > >>>>>> > >>>>>> Commit 2359fa7a878 disables the entire arch_lmb_reserve function on > >>>>>> aarch64, yes.=A0 I assumed when we had talked that it was a small = area > >>>>>> being set aside and perhaps mis-recalled that ATAGS tended to live= at > >>>>>> DDR_BASE + 0x800 or so. > >>>>> > >>>>> That arch_lmb_reserve() is responsible for reserving architecture > >>>>> specific memory. On arm32 it is ATAGS, on arm64 it is nothing as > >>>>> far as > >>>>> I can tell (and see below regarding the TLB). > >>>>> > >>>>>> This reservation is not at that spot, and a lot > >>>>>> more than that. > >>>>> > >>>>> Can you please elaborate on this "lot more" part ? Because as much > >>>>> as I > >>>>> studied the reservation code, the "lot more" was ATAGS on arm32 and > >>>>> nothing on arm64. > >>>> > >>>> See my commit log. > >>> > >>> This is not particularly useful answer, considering the commit log sa= ys: > >>> "lot of crucial things", "Possibly more", "likely also on other board= s" > >>> and other opaque statements. But really, the problem so far happens on > >>> one K3 board. > >> > >> "Such things are the page table (tlb_addr), > >> relocated U-Boot and the active stack." > >=20 > > Please read the rest of my answer, I don't believe the TLB should be > > reserved at all. DTTO for the stack. If you think otherwise, please > > explain why. >=20 > Marek, I've provided you with three generic examples of active memory > blocks that are relevant while U-Boot is allocating from and also > filling that LMB. Please follow those cases and explain to us why they > aren't active - or at least prove why they are specific the k3 (for > which I found no traces). >=20 > And stop following the TLB topic for now. That was only my first guess. > The actual crash I'm seeing on my board come from plain code > overwriting. It could have been TLB as well. It could also have been the > stack. All those become unprotected via your reservation removal. Jan, one thing I didn't see before is, are you also using include/configs/ti_armv7_common.h in the end, like the K3 reference platforms, and if not are you setting bootm_size in your environment? I have one more idea on why this fails on your board but not Marek's. Thanks. --=20 Tom --ihOCVMGS/Nm60Y8G Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmEH7VUACgkQFHw5/5Y0 tyzWXgwAtcMgGh4ImNwDq+8NWhKyIEBFgYpPtKCbgOTEDoLM64mtt8m/7anhs3J5 JR+Pr8wGUDG4LlUR95eOqDgMxketz5AIVHsBpLCAGffNfqzqSkZHpOhVhpSZBWh4 ZRhL2tCn3XaXLirvWCZ3TQ3Niov4YeoXHzCuGNrJny/tZpHQjcMUTwQDOQupSA3l +8iQdeCKgf0el/sk3nsWSkChqsEyBdQmCWbn1wa55vNlnGxuCu4/36pyLf7nLuzE //NH53z6/o4GOk6E6hmR9ykNxChWzSWDANDj2gyZMFXOAenGYWsfNPhdw4grhrSa UK6XZ+WX3mj8p9HCnZRCEtqxie9OEBAV+i6qQeDPBaRvaGB+MpbsKus1R0/PTfAi QheokqKLQC6YuO3wkRJ05JXZWBZWHIv2IyJGfsLyiYJxw77CbNkrNqoQ6VQ9PV9M gbrRifqC6SsAnmepxMEszXQ+CbzmMhSeIO+yoshY+XH37+a1g9pz654Qt1BzVUpD +ZLxBc4U =uRN0 -----END PGP SIGNATURE----- --ihOCVMGS/Nm60Y8G--