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.3 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 91D09C4320A for ; Mon, 9 Aug 2021 13:16:53 +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 BCF9D61004 for ; Mon, 9 Aug 2021 13:16:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BCF9D61004 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 692C481D48; Mon, 9 Aug 2021 15:16:50 +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="JoFzA3lk"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6EA0581468; Mon, 9 Aug 2021 15:16:49 +0200 (CEST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 1EB7881D48 for ; Mon, 9 Aug 2021 15:16:45 +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-qk1-x72c.google.com with SMTP id 14so18275278qkc.4 for ; Mon, 09 Aug 2021 06:16:45 -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=lQl507OXcM1FNTnCLQJoME2siVMcKyq0VykWgRSFEL0=; b=JoFzA3lkv1hc02PP3SsXJ4VhLmvGI+T3R6Qf+XCBYosKz7T72xs6kBStz2flaqdVQ6 Ki3aKDJSbiU/k7glDb1bwq2ypI4WPWLr0g7p6+KHVs4K0ObbvaN0eEYjTMPHH6zGqKi2 AFqeh08gQFMelg9cJlmYW6wnP1ZXweL9UIeAU= 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=lQl507OXcM1FNTnCLQJoME2siVMcKyq0VykWgRSFEL0=; b=V+UZJE6i0FDTRf9D90SRfXt7OlDQ1h1C232mgGUEmwJZLnTthz5AmzzjXO+hctZuGG uA/CH+1FHbCMVuqcWRK+c+0me06je1PWeqMuhCrHGmh4BqxiLjK/MKoPHFKRx7feS5+f 8/XavEDep5QMWBvxGk03O+/WYljCKKXlFtlvoddWchPC9Ugep31/D3DC/t+iv04xt7RV kIQwGtHkAdAWIqt9Lj9jV6FP9RtsVaceRxspKw1DMCRPJVLwNdrcpoIj9vYVQh4RsDmr YRNJAIH1ZVGgmSm4FVoDrBPGv0tyIqRVlmOn+PY25O1OvnPsFMiwY2AyjUebcv8B7Lyy F0rA== X-Gm-Message-State: AOAM531x41s0DniYkVLqW0hFg8WZYFIGQyxvlL/78CnnV/M8rh12hqw7 Z5aQs2SoHCLOpj/LeIzi+LGUxw== X-Google-Smtp-Source: ABdhPJzPNKn48lYFi9P2T3jN3AN8/RtKjuhpW68hJvGKEgMJMbgGnraPCZsM2Uz+gXLbSnH1+R7QQg== X-Received: by 2002:a05:620a:a81:: with SMTP id v1mr1095215qkg.271.1628515003804; Mon, 09 Aug 2021 06:16:43 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-74d7-5a21-e666-aea2.res6.spectrum.com. [2603:6081:7b01:cbda:74d7:5a21:e666:aea2]) by smtp.gmail.com with ESMTPSA id w185sm9281031qkd.30.2021.08.09.06.16.42 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 09 Aug 2021 06:16:42 -0700 (PDT) Date: Mon, 9 Aug 2021 09:16:40 -0400 From: Tom Rini To: Ye Li Cc: "marex@denx.de" , "swarren@nvidia.com" , "hai.pham.ud@renesas.com" , "u-boot@lists.denx.de" , "simon.k.r.goldschmidt@gmail.com" , "lokeshvutla@ti.com" , "wd@denx.de" , "jan.kiszka@siemens.com" Subject: Re: [EXT] Re: [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64" Message-ID: <20210809131640.GN858@bill-the-cat> References: <20210802212759.GD9379@bill-the-cat> <20210803215144.GW9379@bill-the-cat> <015eed03-b945-8757-e994-17d17de45546@denx.de> <20210806164917.GB858@bill-the-cat> <4aff44db-6a83-bcce-a405-1662187983b2@denx.de> <20210808140010.GH858@bill-the-cat> <03720507-5ea4-0fb9-0549-37df3128be2b@denx.de> <20210808145457.GI858@bill-the-cat> <9dbf9adb-7f6b-4b3c-859a-9a0024c69917@denx.de> <1628494486.86799.17.camel@nxp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3sP1+uScbtwzRm4f" Content-Disposition: inline In-Reply-To: <1628494486.86799.17.camel@nxp.com> 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 --3sP1+uScbtwzRm4f Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 09, 2021 at 07:34:34AM +0000, Ye Li wrote: > Hi Marek, >=20 > On Sun, 2021-08-08 at 17:25 +0200, Marek Vasut wrote: > > Caution: EXT Email > >=20 > > On 8/8/21 4:54 PM, Tom Rini wrote: > >=20 > > [...] > >=20 > > >=20 > > > >=20 > > > > >=20 > > > > > I expect it was not simply because up > > > > > until rather recently we didn't have any checks for "don't > > > > > overwrite > > > > > specific areas of memory" other than right before firing off > > > > > the OS (and > > > > > modify whatever memory you want to modify is a feature not a > > > > > bug). > > > > The LMB has been around since forever though ? > > > Yes, LMB has been around since the PowerPC device tree days I > > > suspect (I > > > didn't dig that far back), but only used outside of the "don't > > > overwrite > > > the running U-Boot while we relocate device tree / initrd before > > > booting > > > OS" since 2018 or so. > > So, are we using LMB for two different things now ? > >=20 > > >=20 > > > >=20 > > > > [...] > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > >=20 > > > > > > > OK, so then there isn't a problem reverting this commit for > > > > > > > rcar? > > > > > > The revert will break the use case where the other CPUs are > > > > > > using memory > > > > > > above U-Boot, but have a look at the following branch, it > > > > > > should permit me > > > > > > to parametrize the arch_lmb_reserve() better and reserve the > > > > > > right memory > > > > > > areas per architecture/mach/board, and even clean the > > > > > > arch_lmb_reserve up > > > > > > further: > > > > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A% > > > > > > 2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-sh%2F- > > > > > > %2Ftree%2Flmb- > > > > > > v1&data=3D04%7C01%7Cye.li%40nxp.com%7Cb9bda480d0494a9249c70 > > > > > > 8d95a80c552%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6376 > > > > > > 40331407737098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > > > > > > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata > > > > > > =3DyhIbMHWZMjXy59BVDFVbY2owM7TNdWvk%2B3w2IHg78ok%3D&reserve > > > > > > d=3D0 > > > > > > So yes, pick the revert and I'll submit the four patches for > > > > > > likely next > > > > > > release. > > > > > Thanks for explaining, I'll pick up the revert patch then. > > > > >=20 > > > > > For your LMB tree, I like the initial approach but looking at > > > > > 528915c71762 ("imx: Fix potential lmb memory overwritten by > > > > > stack") I > > > > > think that shows the general "4K is enough for stack we hope" > > > > > is wrong, > > > > > and we should do 16K instead for everyone as the default.=A0=A0But > > > > > we can > > > > > discuss that more too once you post the whole series which > > > > > again, I > > > > > think is the right direction. > > > > The IMX thing is odd indeed and raises a bigger question -- what > > > > is the > > > > "right" amount of stack to reserve ? > > > It's a good question, yes.=A0=A0And some more details about what > > > exactly the > > > NXP folks were doing to hit that would also be nice. > > +CC Ye Li. >=20 > On i.MX8QM/QXP, we implement the=A0ft_system_setup to update kernel FDT. > It needs larger stack size to parse the FDT to disable nodes if the > corresponding resources are not owned by A core. > When we enabled the initrd relocation in u-boot, it allocates a space > from LMB for initrd just before the SP reservation. The stack overflow > overwrites the initrd and cause kernel issue. >=20 > The size of stack reservation actually depends on the implementation. > There are lots of board or soc level functions in the boot sequence. > You can't predict how much stack is needed. So providing a way that can > adjust the size is useful. Thanks for explaining. It sounds like arch/arm/mach-imx/imx8m/soc.c::the=A0ft_system_setup() needs a comment that it uses a lot of stack, due to how complex it is, and that arch/arm/mach-imx/misc.c::board_lmb_reserve() should get moved, and reworked to just reserve another few kilobytes, for the imx8m case. --=20 Tom --3sP1+uScbtwzRm4f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmERKrUACgkQFHw5/5Y0 tyxUbAv/WzrQnItgqBUJw4b3k/DqlD0aIDw8AjntcXagitMFzPRUo8fdFvqX4OLA dGyp6vFkC2y/4S3vABxTUOgdENQi8lO2dBTjXYv2v5BDSfkRSKgQhg015h1ftChy fzJp+iWus4XxFV3ImuLa/fW+WTrLp1OZ8FHhbTczmsWgLdkytlIwGqxp84iV2mqo cZQ19M10Ai7HkyaX/ppxUSnnPnxiqRz6755LHMiz+pfVv/tSzhQnEiODOKvW+PTb s1M1s8Fvuczm1vmf2q1MOC1IEEpzA1UF+rOaHfE4JaPLRMDm3rTHHuayW3lg1Bf0 8GQIAWI50s4Eq5a8IcXFLnb2vSrZqZHiPS5yRN4I8f+lrSqsIq9KOhf4LFzORafD GAgSGz/Y4CdKRaRAgoiabMMM24WauHRsIUBEpNeedhgaRlym1B1ti05/cbKiZHgP c8aq3RM07SPqPCIJgnYVIyzr1+GQuQNu4gB1lrI+3L1kJgttyb9qXk8GaoEY9297 9idKjUoY =f9yn -----END PGP SIGNATURE----- --3sP1+uScbtwzRm4f--