From patchwork Mon Mar 13 13:52:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mitchell Schmeisser X-Patchwork-Id: 47936 Return-Path: X-Original-To: patchwork@mira.cbaines.net Delivered-To: patchwork@mira.cbaines.net Received: by mira.cbaines.net (Postfix, from userid 113) id AF1CD16DDF; Mon, 13 Mar 2023 13:53:15 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mira.cbaines.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=MAILING_LIST_MULTI, MIME_HEADER_CTYPE_ONLY,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mira.cbaines.net (Postfix) with ESMTPS id 1AD7716D2A for ; Mon, 13 Mar 2023 13:53:14 +0000 (GMT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbibn-0000fg-RY; Mon, 13 Mar 2023 09:53:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbibm-0000fS-UZ for guix-patches@gnu.org; Mon, 13 Mar 2023 09:53:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pbibm-0002yw-Mj for guix-patches@gnu.org; Mon, 13 Mar 2023 09:53:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pbibm-0005FI-HD for guix-patches@gnu.org; Mon, 13 Mar 2023 09:53:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#61765] custom toolchain blog post Resent-From: Mitchell Schmeisser Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 13 Mar 2023 13:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61765 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: moreinfo To: Ludovic =?utf-8?q?Court=C3=A8s?= Cc: 61765@debbugs.gnu.org Received: via spool by 61765-submit@debbugs.gnu.org id=B61765.167871556620122 (code B ref 61765); Mon, 13 Mar 2023 13:53:02 +0000 Received: (at 61765) by debbugs.gnu.org; 13 Mar 2023 13:52:46 +0000 Received: from localhost ([127.0.0.1]:33938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbibV-0005ET-2N for submit@debbugs.gnu.org; Mon, 13 Mar 2023 09:52:45 -0400 Received: from mx1.librem.one ([138.201.176.93]:59734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbibS-0005EE-7S for 61765@debbugs.gnu.org; Mon, 13 Mar 2023 09:52:43 -0400 Received: from smtp.librem.one (unknown [192.241.214.14]) by mx1.librem.one (Postfix) with ESMTPS id 1C64881E79; Mon, 13 Mar 2023 06:52:36 -0700 (PDT) Authentication-Results: name mx1.librem.one; dmarc=fail (p=reject dis=none) header.from=librem.one Message-ID: Date: Mon, 13 Mar 2023 09:52:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Content-Language: en-US References: <87sfeuucab.fsf@librem.one> <87fsarmfw6.fsf@gnu.org> <87k003xgs0.fsf@librem.one> <87zg8jwkqc.fsf@gnu.org> In-Reply-To: <87zg8jwkqc.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Mitchell Schmeisser X-ACL-Warn: , Mitchell Schmeisser via Guix-patches X-Patchwork-Original-From: Mitchell Schmeisser via Guix-patches via From: Mitchell Schmeisser Errors-To: guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org Sender: guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org X-getmail-retrieved-from-mailbox: Patches Here are two patches with minor fixes. Sorry about the code formatting... Does anyone have any tips for getting emacs to format scheme code in markdown? Thanks, Mitchell On 3/11/23 07:11, Ludovic Courtès wrote: > Hi Mitchel, > > (Please keep the issue Cc’d.) > > Apologies for the delay! > > Mitchell Schmeisser skribis: > >>> One thing that’s not clear to me: with this in place, can you do “guix >>> build --target=arm-zephyr-eabi hello”, for instance? If not, what’s >>> missing to support it? >> You cannot. I do not know how to describe it in a succinct way but >> suffice to say the applications need to know they are targeting Zephyr >> when they are written. The application will include a `prj.conf` which >> is analogous to a custom defconfig in the Linux kernel. >> Either in this file, or somewhere in the CMakeLists.txt a `BOARD` >> variable is set to specify a specific board definition. >> These board definitions contain information about the architecture and >> the CMake scripts themselves pick the toolchain. >> >> It's not that it's impossible to implement something like `guix build >> --target=arm-zephyr-eabi k64f-hello-world` but the k64f-hello-world >> would be written in such a way that the target is implicit in the >> package. > OK. To put it differently, a typical POSIX program won’t work on > Zephyr; programs have to target the Zephyr interfaces, right? > >> The way I envision the `--target/system` flags being used in this >> context is `guix build --target=arm-linux-gnueabihf k64f-hello-world` >> which will still produce the correct firmware but will allow the >> firmware to be staged to another machine which will be responsible for >> the final deployment over some transport. > Or rather: > > guix build --target=arm-zephyr-eabi k64f-hello-world > > ? > >>> I wonder if it would be worth mentioning >>> too, and how >>> one would go about adding a module. WDYT? >> I considered trying to add Zephyr platforms but I'm not sure it's worth >> the effort. >> In addition to the patch to the website I attached another post(in org) >> which describes how I integrated this toolchain into the Guix >> infrastructure to allow defining firmware packages. >> Maybe there will be additional information in there which can help you >> understand where I'm going with all of this. >> >> There will be a part 3 (and possibly more) about how to practically use >> this stuff in a real project. > Woow. :-) > >> From 0920ec7d951354c94c3da277d58e54b587522622 Mon Sep 17 00:00:00 2001 >> From: Mitchell Schmeisser >> Date: Mon, 27 Feb 2023 10:20:32 -0500 >> Subject: [PATCH] website: Add toolchain blog post >> >> website/blog/custom-toolchains-with-guix.md: New file > I pushed it under the drafts directory for now, to leave others a bit > more time to comment before we publish. I followed up with a commit > editing things a bit, mostly fixing typographical issues, > spelling/capitalization, code formatting, and removing tabs. > > https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/custom-toolchains-with-guix.md > > (BTW, I made slight modifications to some of the code snippets to! One > package was using (append (list …) (package-native-inputs …)), which > really works “by chance” I guess; you should use ‘modify-inputs’ > instead.) > > Let me know if anything’s amiss! > > Thanks, > Ludo’. From 25a65c6ace2a3df43d6c3c6d6e23062a51419025 Mon Sep 17 00:00:00 2001 From: Mitchell Schmeisser Date: Mon, 13 Mar 2023 09:39:22 -0400 Subject: [PATCH 2/2] website: custom-toolchains-with-guix: Update reference URL * website/drafts/custom-toolchains-with-guix.md: Changed url from "latest" to 3.1 which was the current version at the time of writting. --- website/drafts/custom-toolchains-with-guix.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/drafts/custom-toolchains-with-guix.md b/website/drafts/custom-toolchains-with-guix.md index fb491c6..ffc3b1a 100644 --- a/website/drafts/custom-toolchains-with-guix.md +++ b/website/drafts/custom-toolchains-with-guix.md @@ -447,7 +447,7 @@ for a given board. There are standard locations the build system will look for the SDK. We are not using any of them. Our SDK lives in the store, immutable forever. -According to [the Zephyr documentation](https://docs.zephyrproject.org/latest/develop/west/without-west.html), the variable `ZEPHYR_SDK_INSTALL_DIR` needs to point to our custom spot. +According to [the Zephyr documentation](https://docs.zephyrproject.org/3.1.0/develop/west/without-west.html), the variable `ZEPHYR_SDK_INSTALL_DIR` needs to point to our custom spot. We also need to grab the CMake files from the [repository](https://github.com/zephyrproject-rtos/sdk-ng) -- 2.39.1