Add nix flakes support #2
Loading…
Reference in New Issue
No description provided.
Delete Branch "mwojcik/humpback-dds:nix-flakes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This was a tougher nut to crack - mostly because of the failing compilation.
Tried updating
stm32h7xx-hal
but besides some breaking changes, that pulled more newer dependencies, most notablysmoltcp == 0.8.0
and I had some issues withembedded-time
and all in all would require pretty big refactoring and other changes in code - something for some other time, I think.The compilation error plaguing mcu for a long time now is actually from the check phase (actual firmware compiles without issues), but I couldn't pinpoint why - weirdly enough just putting
cargo test
in checkPhase giveserror[E0463]: can't find crate for `test`
- or I may be screwing something up. So the tests are disabled now - figured it would still be an improvement over previous situation. Rustc version can be actually on par with the others.Included updated README (preemptively).
Just use the older Rust version where it worked.
@ -15,3 +15,3 @@
nb = "1.0.0"
embedded-nal = "0.1.0"
minimq = { git = "https://github.com/quartiq/minimq.git", branch = "master" }
minimq = { version = "0.1.0", git = "https://github.com/quartiq/minimq.git" }
I'm surprised that this doesn't come with a corresponding change to Cargo.lock.
Going back to a version that could possibly build and pass tests breaks SaiTLS build instead. I'll try carefully upgrading other packages and getting it to run on newer nightly...
That's surprising, I recall it was fine before. Look at the commit history of nix-scripts and see what Rust versions were used.
I went through all the rust versions that were used in nix-scripts - SaiTLS breaks with 2020-07-25 or earlier, and with neither everything compiles successfully.
Updating stm32h7xx-hal does not help - updated to 0.9.0 with all the necessary code changes and it still throws this in the checkPhase (again, builds fine):
(all of it defined here:
6ce89dffc8/src/rng.rs (L128)
)I'll save the changes for later just in case we'd like to bump the library anyway but I'll try one more thing.
What about that Rust nightly version in
nix/channel-rust-nightly.toml
?Nope, same error.
Was it building on Hydra ever? That's the only place I see a build script for, but I suspect it's never been used in this form.
I tried also downgrading SaiTLS but this proves to be difficult, since it doesn't specify smoltcp version (until latest commit), cargo update tries to pull the newest version which has some breaking changes.
...
It looks like to fix this particular error, I need to upgrade the stm32h7xx-hal library further: I found the commit that fixes this particular error, possibly:
096ef75d49 (diff-23d109d84268da0b9fe2597eb0287d022bb8087cc8d6f2973b8d7710d31ad223)
Now, that I updated the
stm32h7xx-hal
library to just that commit (...commited a day after 0.9.0 release), looks like the library goes through test fine, but now I get a new set of errors from the humpback-dds firmware on its own.That made me think that it's never been tested with
cargo test
in the first place - because yes, these methods are not available on x86_64-linux target platform. And this is regardless ofrustc
version.Now, we have Hydra logs from 2021-06~ so we cannot tell exactly when it broke, but I have a strong suspicion with some coincidental proof.
Consider the three commits:
nix-scripts - 2020-10-08: update nixpkgs from 20.03 to 20.09 for hydra mcu builds
a9108d5fa3
NixOS/nixpkgs - 2020-05-07: default
checkPhase
added, instead of it missing by default - post 20.03, but early 20.09 (before alpha)04248f606f
Humpback was added to Hydra jobs on 2020-09-25:
657d3c1b27
This would mean that Humpback-dds built successfuly when it was first added but I wager it broke after the 20.09 update commit. Unfortunately we don't have the records to prove that it was exactly the case, but that's my guess.
Actually we have them in a database backup from the old server, I can try to dig that out if that's really important (I think not?).
Nah, definitely not important, unless you wanted to confirm exactly when it broke - I think I dug up enough dirt that this shouldn't be necessary :P
@ -0,0 +87,4 @@
buildInputs = with pkgs; [
rustPlatform.rust.rustc
rustPlatform.rust.cargo
openocd dfu-util
if nix/openocd.nix is no longer necessary, please delete the file.
same with the other files in nix/ - I think the whole directory should be deleted.
@ -6,4 +0,0 @@
migen = callPackage ./nix/migen.nix {};
openocd = callPackage ./nix/openocd.nix {};
rustPlatform = callPackage ./nix/rustPlatform.nix {};
itm = callPackage ./nix/itm.nix {inherit rustPlatform;};
What about itm?
@ -21,4 +0,0 @@
'';
openOCDFlashCustomised = writeShellScriptBin "openocd-flash-customised" ''
python3 flash.py $1 $2 $3 $4
Use $@ instead
@ -31,4 +0,0 @@
flash write_image flash_config.bin 0x081e0000 bin
reset run
shutdown"
'';
don't remove?
@ -42,4 +0,0 @@
pkgs.nextpnr
pkgs.icestorm
pkgs.gdb
pkgs.mosquitto
don't remove gdb and mosquitto?
@ -50,4 +0,0 @@
runOpenOcdBlock
openocdFlash
publishMqtt
openOCDFlashCustomised
we still need the scripts...
Why do we still have shell.nix? That can all be ported to flakes AFAICT.
@ -0,0 +46,4 @@
sha256 = "sha256-UmWI3NOE8Lf8ICHOR8nNpbCP9+g3R8XHRX+nUJsH6pY=";
};
cargoPatches = [ ./itm-cargo-lock.patch ];
Is this tested? AFAIK you need
"${self}/itm-cargo-lock.patch"
Either works, but it's the same principle as
97a52e1073/flake.nix (L87)
Tested flashing with Nucleo board.
I think
.gitignore
change should stay -result
is artifact fromnix build
which is introduced here. In addition there also should beflash_config.bin
in there (as it's the artifact from running the flash command) but that's another topic.One more thing however that may need some clarification: openocd commands refer to the config in the repo, which refers to build artifacts in
target/thumbv7em-none-eabihf/release/humpback-dds
(output ofcargo build --release
) - instead of the nix build result - so this may be a tad bit confusing.