| 30 Jun 2022 |
 fufexan | I can also use your repo in my dotfiles to configure the board and then deploy it? | 08:22:46 |
| fufexan | * can I also use your repo in my dotfiles to configure the board and then deploy it? | 08:22:54 |
 matthewcroughan - nix.how | Not sure what you mean by that | 08:23:04 |
| fufexan | uh, use whatever nixpkgs + overlays you have for the board | 08:23:27 |
| matthewcroughan - nix.how | It's better just to use the flake as is, it's not very re-usable if you want to import it into your own flake | 08:23:28 |
| matthewcroughan - nix.how | I could make functions like mkVisionFive ./configuration.nix which would be very re-usable | 08:23:59 |
| fufexan | that would be nice | 08:24:24 |
 dramforever | there could be a visionfive.nix module that adds things like config.system.build.flashBootloader | 08:24:44 |
| matthewcroughan - nix.how | We'll start to compete with yocto big time if someone made libraries of functions to make boards work like that :P | 08:24:44 |
| matthewcroughan - nix.how | In reply to @dramforever:matrix.org
there could be a visionfive.nix module that adds things like config.system.build.flashBootloader And that could be added to the linux_visionfive pr right? | 08:25:34 |
| matthewcroughan - nix.how | I suppose I'll work on that, and add it to nixpkgs when done | 08:25:50 |
| matthewcroughan - nix.how | but that requires merging https://github.com/NixOS/nixpkgs/pull/168826 | 08:26:01 |
| matthewcroughan - nix.how | I would really rather see it merged now, since it works so well | 08:26:07 |
| matthewcroughan - nix.how | I could make the argument that it should be merged now, so that work like this can be done on top of this PR, but what do you think? | 08:26:43 |
| matthewcroughan - nix.how | If we don't merge it, it just gets stale, and work cannot be done. The PR works fine. | 08:27:07 |
| matthewcroughan - nix.how | If it were merged now, I'd work on adding wifi, and then the flashBootloader script, in my own PR. | 08:27:54 |
| matthewcroughan - nix.how | It is a real question whether stuff like this is best placed in nixpkgs itself, or in a flake these days though. | 08:29:36 |
 Alyssa Ross | I think at least some of it belongs in nixos-hardware | 08:30:06 |
| matthewcroughan - nix.how | It means that the visionfive would be unique in having that flashBootloader script, which handles a lot for the user | 08:30:40 |
| dramforever | I think it brings in a bit too much random stuff. There's a master version of OpenSBI, a fork of U-Boot by NickCao, StarFive's entire fork of Linux | 08:31:07 |
| matthewcroughan - nix.how | that'll settle though, so it won't be a problem | 08:31:26 |
| dramforever | I think it's best to just start working on stuff in a flake | 08:31:52 |
| fufexan | the kernel is fine in nixpkgs imo, as that's where people expect to find kernels | 08:32:37 |
| fufexan | but the rest could be developed in a flake | 08:32:44 |
| fufexan | it's much easier to move fast in a flake than in nixpkgs | 08:32:55 |
| matthewcroughan - nix.how | vendor kernels being in nixpkgs does sound weird though if you think about it | 08:33:05 |
| matthewcroughan - nix.how | nixos-hardware wants to be a collection of nix code that you import to circumvent hardware quirks | 08:33:19 |
| matthewcroughan - nix.how | requiring a vendor kernel (custom kernel supplied by weirdos that continue to make the ecosystem more broken) is a hardware quirk | 08:33:47 |
| matthewcroughan - nix.how | so it would make sense to start polluting nixos-hardware, rather than nixpkgs, with that stuff | 08:34:25 |
| dramforever | I'm not sure how StarFive feels about upstreaming random stuff. They already upstreamed their GPIO/clock/reset drivers to mainline, but it seems that they updated it in their fork and added more stuff | 08:34:31 |
