From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 7F7033858D33 for ; Wed, 13 Jan 2021 04:42:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7F7033858D33 Received: by mail-lj1-x231.google.com with SMTP id m10so1105685lji.1 for ; Tue, 12 Jan 2021 20:42:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gOhrHVkP26pwgQRMdInpKquyZDC5FZBMSinXnIJTqg8=; b=NWfduGhpL3G6n1kH7qt1TC96gGFAQAbLplXECOawR/mVSsjP6rbgdp3ltkn/nth6Uh GNm5HmYOS5RoQF72XtGa1HRom37gBobp5TMLpq3atNvTmpXzjXLGz2nLWlsO+5Jpj6GP c+QuHtae3KBv34Wq4wT7OrLgx/C8RTVq6VaTUcMz1bPuMRiTncU8ttzhK9TwfzL4L5jg Vslfse/eX+YEsGyDSso19nprkkYAf5c26LTUBc9hZsFHQTbB8cSdKzdv0tC/GiRTcb1Y HW1BsN8XLWZH3WiEGG+1jD34tpWgBoUvqwd9hXQeJsR0sSOi8scEddjbI5lYHeoUcN9T Pn3g== X-Gm-Message-State: AOAM532H1ssq8Ysps7zWvgAchMZY6A5xIVilo+QDqf2AxUicRmGt91+H UDxLfgRukKz+gpNh50pSPYKjBbrkWBEgbaXPSTIW7+vI X-Google-Smtp-Source: ABdhPJzRN2ODbvX6/B162vjR+z3sM4/1Go++4T9UkeTtnpdDtYnj2aELJoSPMyOXPYLsuXi+HXozIGIYxNZ78+9bGBc= X-Received: by 2002:a2e:9797:: with SMTP id y23mr123736lji.358.1610512927154; Tue, 12 Jan 2021 20:42:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: squirvel voxbox Date: Tue, 12 Jan 2021 23:41:53 -0500 Message-ID: Subject: Re: Defining a Super Specific uArch To: Chris Packham Cc: "crossgcc@sourceware.org" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: crossgcc@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: crossgcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 04:42:11 -0000 Thanks so much for the info, I was able to get my build running with it. Very much was under the impression that the suffix was meant to define the specific arch variant (ex POWER, with the suffix 8 or 9), rather than just being the final name of the toolchain/config. Cheers! On Tue, Jan 12, 2021 at 7:04 PM Chris Packham < Chris.Packham@alliedtelesis.co.nz> wrote: > > On 13/01/21 11:45 am, squirvel voxbox via crossgcc wrote: > > Hi All, > > > > I asked a fairly similar question over on the irc channel, and didn't > get a > > response, so I'm trying here. > https://github.com/crosstool-ng/crosstool-ng is probably the best > support channel these days. I keep an eye on IRC but it's sporadic at best. > > Let's say I'm attempting to target a super specific CPU, (in this case a > > RK3328, which is a 64bit armv8-a+crypto cpu). What would be the proper > way > > to define the cpu? > My initial thought is to make a generic aarch64 toolchain and use > -march= in CFLAGS to tune for your desired system (the > aarch64-unknown-linux-gnu sample is probably good enough for this). > > I am currently defining: > > target architecture: arm > > suffix to the arch-part: v8-a+crypto (according to gcc, the dash is > > required to define v8-a) > The suffix is just used in naming the tools so it could be anything > (often people add things "le", "be" or "hf"). Adding a '-' breaks things > that use the toolchain tuple to figure stuff out. It'd be nice if we > could stop users from putting a '-' in there but I'm not sure that > Kconfig has a way of validating string input fields. > > emit assembly for CPU: cortex-a53 > > other items are set based on the sample aarch64-rpi3 configuration > > > > But ct-ng build fails due to: > > "Invalid configuration `aarch64v8-a+crypto-RK3328-linux-gnu': more > than > > four components" (so more than 4 dashes according to the script source > code) > > or if I disable the vendor string (set to RK3328) > > "Invalid configuration `aarch64v8-a+crypto-linux-gnu': machine > > `aarch64v8-a+crypto' not recognized" > > > > In theory I could just add all the specific uarch flags to CFLAGS/LDFLAGS > > such as -march=, but that feels rather hacky especially since there is an > > arch suffix field. > I think what you want is to set CT_ARCH_ARCH ("Architecture level:") to > armv8-a+crypto which should have the effect of making this the default > when no -march= is specified in CFLAGS. The fact that you're already > setting the vendor string to RK3328 is probably good enough to > distinguish the resulting toolchain from any others you might have. > > Is the hacky way the way I should be defining this cpu, or am I just > > specifying this incorrectly? If the latter, what is the proper way to > > specify a super specific uarch? > > > > Thanks, > > squirvel > > -- > > For unsubscribe information see http://sourceware.org/lists.html#faq