Upstream board support to nixos-hardware

[skeuchel]

I did not realize that you were also packaging the pioneer support packages for nixos @silvanshade. Note that between/after my deadlines I finally got around to contribute some initial code to nixos-hardware which was merged just yesterday. Since you already packaged edk2 and the firmware-bin creation tool, would you consider also incorporating them into nixos-hardware?

[silvanshade]

Since you already packaged edk2 and the firmware-bin creation tool, would you consider also incorporating them into nixos-hardware?

I think I could probably do that.

One difference with how I've been doing things here versus the PR you linked, and why I haven't tried to upstream any of this work yet (aside from the fact that it's not quite ready yet), is that I've opted to use upstream sources for as much as possible, rather than the Sophgo or MilkV sources. So for example, using upstream u-root, edk2, a slightly different set of kernel patches (which I hope to refine more soon), etc.

I wasn't sure how appropriate it would be to submit derivations which differ potentially significantly from the vendor sources to something like nixos-hardware, or some of the other similar efforts like @NickCao's NickCao/nixos-riscv (which has support for MilkV duo).

Ultimately my goal here is to create a flake with an installer image built using these refined BSP definitions, including GCC 14 (built from git) for xtheadvector support, with an optional ccache-enabled stdenv, and with cachix support for some major packages.

I'm not sure the extent to which all of that could be incorporated in other upstream efforts but perhaps for the meantime I could adapt the packages you mention to just use the Sophgo sources for a one off PR for nixos-hardware.

Any thoughts about that?

[skeuchel]

One difference with how I've been doing things here versus the PR you linked, and why I haven't tried to upstream any of this work yet (aside from the fact that it's not quite ready yet), is that I've opted to use upstream sources for as much as possible, rather than the Sophgo or MilkV sources. So for example, using upstream u-root, edk2, a slightly different set of kernel patches (which I hope to refine more soon), etc.

I think nixos-hardware is trying to use upstream sources as much as possible as well. Vendor sources are usually abandoned at some point by the vendors. From what I saw in the past, nixos-hardware usually switches at some point to upstream sources if either the vendor's definitions have been completely upstreamed (see for instance opensbi for the vf2 board) or if it is mostly upstreamed it is carrying a small set of the vendor's patches (e.g. helios4). Also the u-root for the pioneer in nixos-hardware is the upstream one with a single extlinux related patch.

I wasn't sure how appropriate it would be to submit derivations which differ potentially significantly from the vendor sources to something like nixos-hardware, [...]

I think either upstream or vendor versions is what they accept. But not really 3rd party sources.

Ultimately my goal here is to create a flake with an installer image built using these refined BSP definitions, including GCC 14 (built from git) for xtheadvector support, with an optional ccache-enabled stdenv, and with cachix support for some major packages.

I'm not sure the extent to which all of that could be incorporated in other upstream efforts but perhaps for the meantime I could adapt the packages you mention to just use the Sophgo sources for a one off PR for nixos-hardware.

I do not think all could be incorporated, but that's also not my goal. I would just keep some vanilla board support in nixos-hardware, and then do more experimental / opinionated stuff in a repo like this. I'm interested in enabling more risc-v support in nixpkgs, but some parts are not easily upstreamable into nixpkgs. For instance, I have been playing with ghc binary dists. I hope we can maybe collaborate here on something like this.

I am also interested in getting gcc 14 up and running way before nixpkgs switches to it. gcc 13 still has known xthead* related bugs (1, 2), which have been patched in 14 but have only been backported partially to 13 (3).

[skeuchel]

Also let me know if I can help you with that.

[silvanshade]

One difference with how I've been doing things here versus the PR you linked, and why I haven't tried to upstream any of this work yet (aside from the fact that it's not quite ready yet), is that I've opted to use upstream sources for as much as possible, rather than the Sophgo or MilkV sources. So for example, using upstream u-root, edk2, a slightly different set of kernel patches (which I hope to refine more soon), etc.

I think nixos-hardware is trying to use upstream sources as much as possible as well. Vendor sources are usually abandoned at some point by the vendors. From what I saw in the past, nixos-hardware usually switches at some point to upstream sources if either the vendor's definitions have been completely upstreamed (see for instance opensbi for the vf2 board) or if it is mostly upstreamed it is carrying a small set of the vendor's patches (e.g. helios4). Also the u-root for the pioneer in nixos-hardware is the upstream one with a single extlinux related patch.

Okay, good to know that. I think this is a reasonable approach.

I wasn't sure how appropriate it would be to submit derivations which differ potentially significantly from the vendor sources to something like nixos-hardware, [...]

I think either upstream or vendor versions is what they accept. But not really 3rd party sources.

As long as we can use mostly upstream sources + some patches from the Sophgo repos (effectively rebasing), that should be enough for now.

Going further though, I've been considering creating some PRs to submit some of the missing Sophgo patches upstream since it seems like otherwise they may never be incorporated. Any thoughts on that?

I would probably not submit them verbatim and try to rewrite parts, but still.

The situation is similar for the Sophgo kernel. The important patches are all basically having to do with the device tree definitions, and even in 6.9, only a small part of those have been submitted.

Ultimately my goal here is to create a flake with an installer image built using these refined BSP definitions, including GCC 14 (built from git) for xtheadvector support, with an optional ccache-enabled stdenv, and with cachix support for some major packages.
I'm not sure the extent to which all of that could be incorporated in other upstream efforts but perhaps for the meantime I could adapt the packages you mention to just use the Sophgo sources for a one off PR for nixos-hardware.

I do not think all could be incorporated, but that's also not my goal. I would just keep some vanilla board support in nixos-hardware, and then do more experimental / opinionated stuff in a repo like this. I'm interested in enabling more risc-v support in nixpkgs, but some parts are not easily upstreamable into nixpkgs. For instance, I have been playing with ghc binary dists. I hope we can maybe collaborate here on something like this.

Sure, sounds good to me. I sent you an invite to the organization by the way.

[silvanshade]

I am also interested in getting gcc 14 up and running way before nixpkgs switches to it. gcc 13 still has known xthead* related bugs (1, 2), which have been patched in 14 but have only been backported partially to 13 (3).

Thanks for the links. I wasn't aware of those issues.

EDIT: Removed all the GCC 14 snippets. I finally managed to get it working and submitted a PR for supporting code to nixpkgs: NixOS/nixpkgs#303514

[silvanshade]

Going to close this for now but will open related issues once I get further with the refactoring and things are in shape for being ready to submit upstream.