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 A7514C77B75 for ; Tue, 23 May 2023 06:55:10 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 42B32854CF; Tue, 23 May 2023 08:55:08 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org 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=linaro.org header.i=@linaro.org header.b="A51WfPDy"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 457B6855D9; Tue, 23 May 2023 08:55:07 +0200 (CEST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 4E755847BE for ; Tue, 23 May 2023 08:55:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-30957dd7640so2771665f8f.3 for ; Mon, 22 May 2023 23:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1684824902; x=1687416902; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aKXPErW7mOt2g7otJCuwGjFmktFi1+tvt0oLLqeFMTU=; b=A51WfPDyJANtQIjjZ9JKAwQIgxKmT6lIoC+GINk2BxpnAm7TqaDmN+2T4agfZKzh+A w/FfghHAzCdXhvBgjeuUNJFhismMSRI5YXe5F667fMXv4Wr/N/jx4J/CNBzzAmNdq6EO jE8wx3ae7ylsNIES/hP7wEerHCBhA/Cz6lToFaAP8hK4K+yMknxwnPwDYbZWKNqxQn3j mVE8csEHibylVNL50vuYvhLcXGwraN7j5pZud+zFO/oeojpACBZjvmHmURqauiUgHVrk 7sbeIOfAIlGrkRnkC9oUPIfpTZmbZ+V/UNgZhBynwu5yG0lBrl/GGTBL2n7WisDzbaTV 8b9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684824902; x=1687416902; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aKXPErW7mOt2g7otJCuwGjFmktFi1+tvt0oLLqeFMTU=; b=jwCQJDeQ5qigu7B11lr219gD1fsTbUPHMDUTFaxbDbIrgPbV/rYM84abhHv7s7n0TR 4n5XxLU2mMd0ANCu7FcWFjS8uM3fzTXbu6VvRg1I3zaOSjChM4ek2KIEU20IR12dRQAK hqXfy5bKYJJPC8rpXBfwg9OAGj9CZWH5B2Qb++9IeBVbAfLeTnLB6xd760Rh5dvCQvfV SnDF3s1QbPWWqsoA+u3YyEDJ/QTKADEa6pYtEojwwCZgB3LpLOVVTOtcJ7IR4EfkuC9Z Ha9bJtnQcKQw8w607vhVEobjHJfhaU6mmOsqHQRKB2Bo0Jrzw1m9Wv5OMFxf6WdHlnMm Om3Q== X-Gm-Message-State: AC+VfDwQkiiQGv10gYzgYrwi0phs+jN+jNAIO3h5MYxmEgoMYP9S8Fwj tDKUBcOvp6AYKT0Z4rl+ooXw5A== X-Google-Smtp-Source: ACHHUZ7qf/xh1q0eOMSiUnHqaG6pzSifYvlzxPj8YCHKK+wdJYWKzrzlAf+twScyBNKpCuIyvtcLOg== X-Received: by 2002:a5d:468c:0:b0:30a:8c65:50d6 with SMTP id u12-20020a5d468c000000b0030a8c6550d6mr5369345wrq.12.1684824902675; Mon, 22 May 2023 23:55:02 -0700 (PDT) Received: from hera (ppp176092130041.access.hol.gr. [176.92.130.41]) by smtp.gmail.com with ESMTPSA id y10-20020adff6ca000000b002f103ca90cdsm9966637wrp.101.2023.05.22.23.55.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 May 2023 23:55:02 -0700 (PDT) Date: Tue, 23 May 2023 09:54:59 +0300 From: Ilias Apalodimas To: Sam Edwards Cc: Heinrich Schuchardt , u-boot@lists.denx.de, Alper Nebi Yasak , Andrew Scull , Kever Yang , Marek =?iso-8859-1?Q?Beh=FAn?= , Michal Simek , Nathan Barrett-Morrison , Pali =?iso-8859-1?Q?Roh=E1r?= , Peng Fan , Philip Oberfichtner , Philipp Tomsich , Quentin Schulz , Simon Glass , Tom Rini Subject: Re: [RFC PATCH 00/10] Improve ARM target's support for LLVM toolchain Message-ID: References: <20230520205547.1009254-1-CFSworks@gmail.com> <23EFB5F3-C3F5-44BC-BB6D-730656F67578@gmx.de> <2355e4a5-1474-5579-2171-8339226db14f@gmail.com> <229aafd0-f1af-8555-bd85-4fb8ce81e67b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <229aafd0-f1af-8555-bd85-4fb8ce81e67b@gmail.com> 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 Mon, May 22, 2023 at 01:37:26PM -0600, Sam Edwards wrote: > Hi Ilias, > > On 5/22/23 00:52, Ilias Apalodimas wrote: > > I can help clean up the arm architecture even further. I was toying > > with the idea of having page-aligned sections and eventually map > > u-boot with proper permissions per section. Right now (at least for > > the majority of arm platforms) we are doing RWX for all the memory, > > apart from devices that are mapped as RW. I do have an awfully hacky > > PoC around, but the linker script cleanup is more than welcome. > > Glad to hear it (and excited by the idea of proper W^X)! Yes that's my end goal here. Looking around the code we have in U-Boot regarding the mmu configuration, it's a lot easier (and cleaner) to fix the linker script, add symbols for ro_start, rw_start etc and layout the binary in a way we can easily map it, instead of leaving it as is and try to fix the mapping in c code. > The linker script > cleanup (i.e. deleting those pesky `sections.c` files and going back to > linker-assigned symbols) can really happen whenever; it won't cause a > problem on any version of GNU ld from <7 years ago. Perhaps a series of > patches (one per arch) doing that should be landed first? Yes probably, because I specifically remember digging through the history of why the sections were defined like that in the first place. > > > It's probably not a mailing list issue. I only got the efi related > > patches on my mailbox. The recipients were generated with > > get_maintainers.pl? Heinirch and I only received the efi* portions as > > we maintain that subsystem > > Well, it's true that you and Heinrich weren't Cc: on every email in the > series. I just went with patman's default behavior. > > But every patch was sent To: the u-boot list, and I do see the whole series > showing up on the archive. Did you not even receive the other patches in the > series via the list? > > Cheers, > Sam Cheers /Ilias