-
Notifications
You must be signed in to change notification settings - Fork 0
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
Upstream board support to nixos-hardware #1
Comments
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 I wasn't sure how appropriate it would be to submit derivations which differ potentially significantly from the vendor sources to something like 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 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 Any thoughts about that? |
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 think either upstream or vendor versions is what they accept. But not really 3rd party sources.
I do not think all could be incorporated, but that's also not my goal. I would just keep some vanilla board support in 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). |
Also let me know if I can help you with that. |
Okay, good to know that. I think this is a reasonable approach.
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.
Sure, sounds good to me. I sent you an invite to the organization by the way. |
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 |
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. |
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?
The text was updated successfully, but these errors were encountered: