-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add nix-shell file for building with nix #578
base: master
Are you sure you want to change the base?
Conversation
Can |
Yep I can add that! The reason for adding the shellHooks would be to run the |
Alright I was able to build and run the QEMU example on Pop!_OS 24.04 with nix now with the latest commit. I have not tested flashing the firmware yet. |
Can you build firmware for one of our machines? I'm getting this failure when building galp5.
|
I'll test the galp5 and fix that. |
Alright I was able to build firmware for the galp5, galp7 and addw3. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like it's working! In the Nix shell, the ch341a scripts don't throw "unknown chip" errors on models with XM25QU256C chips anymore, and the handful of random System76 models I tried building all built successfully.
Might want to include the |
Add that @DrymarchonShaun didn't cause any issues with building QEMU so it should be fine, does it fix your issue? |
Yeah, that should do it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm getting a couple of errors when I first enter the shell:
jacob@serw13:~/Work/firmware-open$ nix-shell
Updated Git hooks.
Git LFS initialized.
Enter passphrase for key '/home/jacob/.ssh/id_rsa':
make: Entering directory '/home/jacob/Work/firmware-open/coreboot'
Welcome to the coreboot cross toolchain builder v2024-02-18_732134932b
Building toolchain using 32 thread(s).
Target architecture is i386-elf
ERROR: Missing tool: Please install 'zlib (zlib1g-dev or zlib-devel)'. (eg using your OS packaging system)
make[2]: *** [Makefile:20: build_gcc] Error 1
make[1]: *** [Makefile:36: build-i386] Error 2
make: *** [util/crossgcc/Makefile.mk:32: crossgcc-i386] Error 2
make: Leaving directory '/home/jacob/Work/firmware-open/coreboot'
make: Entering directory '/home/jacob/Work/firmware-open/coreboot'
Welcome to the coreboot cross toolchain builder v2024-02-18_732134932b
Building toolchain using 32 thread(s).
Target architecture is x86_64-elf
ERROR: Missing tool: Please install 'zlib (zlib1g-dev or zlib-devel)'. (eg using your OS packaging system)
make[2]: *** [Makefile:20: build_gcc] Error 1
make[1]: *** [Makefile:39: build-x64] Error 2
make: *** [util/crossgcc/Makefile.mk:32: crossgcc-x64] Error 2
make: Leaving directory '/home/jacob/Work/firmware-open/coreboot'
make: Entering directory '/home/jacob/Work/firmware-open/coreboot'
make: Leaving directory '/home/jacob/Work/firmware-open/coreboot'
zlib1g-dev
is already installed on the host, so not sure if that means something's missing from the nix-shell file? Building firmware still works, though (even after removing that package from the host). Are you also getting those errors/are they expected?
I have that package on my host system and I don't see that message. I do have zlib in the shell already but if I remove it from the shell.nix file I do see those errors. Very odd. |
@jacobgkau can you check that you have the latest changes from this branch? |
I'm on 6ccff2f, which is the last commit on this branch.
Huh, I do see it in |
I don't see that message if I have it in the shell.nix file which makes it seem that it is available in the shell. I believe you can check like this:
|
I did a |
Hmm. This is what I get when I run that command within the shell:
|
Some of my output might be from trying out the zlib-ng library instead which did not work and it needs zlib directly. After that did the error about zlib still appear? |
Yes, that output is immediately following the error messages.
I tried adding
Testing on a fresh lab machine, I actually don't get the errors seen above on my work machine, but I do still get an error building MPFR v4.2.1. |
The |
I used the single-user install on that lab machine, and it looks like I used the multi-user install on my work machine. |
Now I do see this error: Building MPFR v4.2.1 for host ... failed. Check 'build-MPFR/build.log'. so that is indeed odd that it is just happening now. I've been told to go the flake route but the official nix installer does not enable that and you would need to edit your config file for nix for it. |
6e7c446
to
dc94df6
Compare
if you want to simplify things a bit, you could simply use the coreboot-toolchain packaged in nixpkgs https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/tools/misc/coreboot-toolchain/default.nix |
Ah that is neat! I guess I can't run it like this?:
|
try
|
this is what I use for one of my machines (sadly, the only machine in my possession which supports coreboot): |
ahhh it's odd that it is .x64 instead of the normal x86_64. |
you're building x64 coreboot? I saw in the release notes of
but I wasn't sure if it applied to all platforms and configs |
I would just think since the platform/device is x86 it should be building for that no? I am seeing this error though: = note: rust-lld: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory When I run the build script for qemu. |
64bit support for coreboot was added relatively recently I'm not a developer of coreboot, and I cannot speak on the behalf of either the project or the developers |
by the way, this is another interesting project that could serve as a source of inspiration https://codeberg.org/amjoseph/ownerboot |
The goal of this PR is to just run |
f355ec1
to
dc94df6
Compare
the only practical difference between flake and non-flake is that flakes provide a "standard" way of managing inputs regardless, if you want to read an interesting article on the subject: https://jade.fyi/blog/flakes-arent-real/ |
ultimately, what would improve user experience is a pinned version of nixpkgs, which can be achieved in multiple ways (npins niv flakes) |
I like the idea of building it with a flake because it's a common way of managing dependencies, and builds are done in an offline sandbox (apart from fetchPhase which can access the internet). I even set |
but remember that if you fully commit to the flake route you'll very likely run into the same issues that I did namely, only fetchPhase can download files; buildPhase cannot normally this is fine, but coreboot's build system fetches some of its submodules during build time, and performs additional git commands this is why I had to do this in
|
@ahoneybun I suspect part of the problem is using |
This is my output:
I generally use the official nix installer so it should be using the latest stable which is 24.05 from my understanding. |
Hmm, I guess that command doesn't actually list the revision when not using nixos. What about
How often do you run |
Mm that is interesting:
|
Thats really odd considering
|
So I have nix installed on two systems, one with the official and one with the Determinate Systems installer and neither have any channels...
|
Does |
Yes that is correct. The nix installer script needs root but I believe a lot is done in the user account. |
It depends on whether you used the multi-user installation or the single-user installation - https://nixos.org/download/ but nix-info on all three devices says
so I'm assuming you did the multi-user installation? |
Yes since that is the recommended method. |
Hmm. I haven't used nix outside of NixOS, gonna boot up a popos VM and see if I can figure it out. |
@ahoneybun what happens if you first run Also, did |
I just noticed that this exists: https://github.com/coreboot/coreboot/tree/main/util/nixshell |
Once you enter
shell
in the firmware-open repo it will basically run though the install-deps and coreboot-sdk scripts so that you can build your firmware right after it is done. I tested with the qemu firmware test to make sure that it did work.I'm going to test on Pop!_OS next as this was done on NixOS to be sure that I have all of the depends.