Libre-SOC

[fricklerhandwerk]

A libre processor core design.

• NLnet project
• source code
• manual build setup
• Nix build setup
• related work:
  • https://github.com/ngi-nix/ngi/issues/234
  • https://github.com/ngi-nix/ngi/issues/145
  • https://github.com/ngi-nix/libresoc-soc
  • https://github.com/ngi-nix/coriolis/blob/devel/flake.nix

This project is huge. Some dependencies are already in Nixpkgs, some are upstream, some are in ngi-nix repositories, some apparently still unpackaged. This needs to be sorted out and broken down into separate tasks.

The end goal is to build the latest design with one command. It's more likely though that getting components packaged will simply benefit other hardware designers.

The lead developer seems to be quite frustrated with the Nix community's development model and past interactions with Nix maintainers. I propose that we stay out of the way and just make everything work on our side.

[jleightcap]

I've spent a few hours over the past two weeks wrapping my head around the state of this project w.r.t. Nix packaging.

Goal: tools used to design and implement Libre-SOC have proven useful for real-world hardware design. Package generally useful tools with Nix. Secondary goal: build the SOC reproducibly with Nix.

Summary (2023-03-29)

Libre-SOC project contains tools currently not packaged, these tools have been determined to not have any (open source) users outside of the containing project: so, I'm not considering them for inclusion.
Then, thanks to @L-as et al. in Summer of Nix 2021, the requisite tooling has been packaged:

1. upstream in a Libre-SOC monorepo
2. in a separate, tool-specific repo

There has been some drift due to upstream repo changes that I have now fixed.

Remaining Work

Going forward: Centralize existing work in ngipkgs, determine how best to integrate my fixes.

@fricklerhandwerk below are two drafts for ways to proceed: please let me know your thoughts as to which better fits the intent of ngi-nix.

1. Derivations from flake input

Upstream is non-receptive to further patches, have to work within repos we control.

1a. Include Libre-SOC monorepo as input in flake.nix, override/overrideAttr broken definitions

This is fairly brittle; as upstream continues to drift further from its included but unmaintained flake, fixes accumulate here via overrides.

1b . Fork the upstream monorepo into ngi-nix, apply fixes there rather than override, and use fixed fork as flake input.

This is how we proceded with e.g. #7: but in this case we wouldn't expect our fork to ever get merged back.

2. Derivations in ngipkgs

Rather than compose flakes, include all derivation definitions in this repo.

2a. Copy derivations from upstream monorepo, fix definitions rather than override

Lowest overhead to maintain, but effectively kills all connection with the upstream flake. This might cause confusion for users who have multiple flakes to choose from. (Upstream has little interest in Nix, and I don't think this confusion is likely to occur. I personally think this is the best option.)

2b. Include monorepo in this repo

CC @albertchae, who had this suggestion to effectively fork the upstream monorepo into this repository.

[fricklerhandwerk]

@jleightcap thanks a lot for the update! I also think that taking all the derivations and maintaining them here is the most sensible option. We can then ask upstream to remove their Nix code altogether.

[albertchae]

2b. Include monorepo in this repo

CC @albertchae, who had this suggestion to effectively fork the upstream monorepo into this repository.

@jleightcap To clarify I didn't mean to fork the entire repo but just the nix derivations while preserving their commit history from the monorepo. This should be possible with a combination of git filter-branch https://amandawalkerbrubaker.medium.com/splitting-your-git-repo-while-maintaining-commit-history-35b9f4597514 and the merging with unrelated histories #12 (comment)

But this could be unnecessary work when copying files is a lot easier

[fricklerhandwerk]

If it's not too much overhead, I'd prefer preserving history to give credit where it's due.

[lorenzleutgeb]

@fricklerhandwerk

If it's not too much overhead, I'd prefer preserving history to give credit where it's due.

Then don't squash merge next time please. As far as I understand @jleightcap and @albertchae spent quite some energy in preserving a good history in #168. 7f8b64f was a root (obfuscated by a rebase).

[lorenzleutgeb]

@jleightcap please confirm that the merge of #168 means we can now archive https://github.com/ngi-nix/libresoc-soc and explain what of the items mentioned in the initial post of this issue is still open (if any), because, frankly, I just don't entirely understand what out of all these things has just landed. Thanks!

[fricklerhandwerk]

@lorenzleutgeb

Then don't squash merge next time please. As far as I understand @jleightcap and @albertchae spent quite some energy in preserving a good history in #168. 7f8b64f was a root (obfuscated by a rebase).

@lorenzleutgeb yes, absolutely -- sorry. I looked at the history and was impressed by the second part and confused by the first part, then decided to squash. Re-did it with the exceptional force push to main (forgive my sins).

[jleightcap]

@jleightcap please confirm that the merge of #168 means we can now archive https://github.com/ngi-nix/libresoc-soc and explain what of the items mentioned in the initial post of this issue is still open (if any), because, frankly, I just don't entirely understand what out of all these things has just landed. Thanks!

Confirming with PR merged this issue can be closed,

The end goal is to build the latest design with one command.

is done, and https://github.com/ngi-nix/libresoc-soc is a relic that can be archived/deleted as appropriate.