Hi Ludo,
OK. To put it differently, a typical POSIX program won’t work on
Zephyr; programs have to target the Zephyr interfaces, right?
This is mostly correct. I think a lot of my conceptual difficulties come from the fact that west/zephyr try to tackle the issues of software deployment and dependency management at the project level. What I mean to say is that in the rest of the software world we have things like auto tools or pkg-config to help with component composition but Zephyr tries to do all composition through several thousands of lines of cmake. Every bit as complex as the kernel kconfig but even more so since modules can be scattered across the file system. One of the selling points of zephyr is that your application is abstracted from the hardware and can run on multiple boards without modification. However to make this happen you need to do a lot of work on the application side. Below you can see an example. You have to provide the proper kernel config for every target you want to support.
Using guix there may be a more elegant solution to these problems but maybe not.
Thank you for all your feedback, Mitchell
On Mar 11, 2023, at 7:12 AM, Ludovic Courtès <ludo@gnu.org> wrote:
Hi Mitchel,(Please keep the issue Cc’d.)Apologies for the delay!Mitchell Schmeisser <mitchellschmeisser@librem.one> 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 onZephyr; 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
<https://guix.gnu.org/manual/en/html_node/Platforms.html> 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 <mitchellschmeisser@librem.one>
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 bitmore time to comment before we publish. I followed up with a commitediting 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! Onepackage was using (append (list …) (package-native-inputs …)), whichreally works “by chance” I guess; you should use ‘modify-inputs’instead.)Let me know if anything’s amiss!Thanks,Ludo’.
|