Investigate bad bitstream selection by bazel

[pamaury]

Description

The title might not be accurate. The problem can usually be reproduced as follows:

• checkout master
• bazel clean --expunge
• run a test (like ROM e2e or manufacturing)
• switch to a branch with a relatively big diff with the current one (and difference bitstream?)
• run a test The test will typically fail in non-obvious ways like the ROM not starting. This can materialize as an SFDP header error. This makes development quite frustrating because it is easy to loose time not realizing the problem and then doing a whole clean/expunge takes a while.

I suspect the problem comes from the bitstream cache because running bazel clean --expunge fixes the problem.

• [ ] Investigate root cause
• [ ] Find a way to at least tell the user that there is a mismatch and he/she needs to clean/expunge
• [ ] Fix the problem

[pamaury]

Ping @timothytrippel @engdoreis @jwnrt @johngt

[a-will]

If you want to change bitstreams, you must run something like...

bazel sync --configure

Once bazel retrieves the bitstreams cache, it does not do so again unless prompted. The freshness of the cache is not handled by bazel--For various reasons, it is impossible to create such a bazel-managed cache that is publicly usable. (e.g. env vars are inputs to the toolchain, but it's still not a cache hit when two different toolchains actually have the same output)

[a-will]

Optionally, you can install a git hook to try to automatically update:

https://opentitan.org/guides/getting_started/setup_fpga.html#using-the-bitstreams-repository

[pamaury]

Thanks for the links. Could you explain why it is impossible in bazel, and also what exactly happens that leads to those "broken" bitstream images? Is there no way to at least detect the problem and tell the user to resync?

[dmcardle]

Hey @pamaury, there's a bit more context here: https://github.com/lowRISC/opentitan/blob/e0ef3881b93f963106d40b8dcc446033a489f937/rules/bitstreams.bzl#L91-L95

[hcallahan-lowrisc]

Related : https://github.com/lowRISC/opentitan/pull/16863

[luismarques]

I've witnessed and experienced myself various situations that could be avoided with git hooks, saving time and resources. And sometimes we already even have such hooks, as was the case here for the bitstream selection [1], but people just aren't aware or haven't bothered to install them. Since git hooks can't be installed by merely cloning the repository, can we instead decide on a minimum set of hooks that everybody should have and then have bazel check that those are installed as part of the build process? By having such a baseline of hooks we'd avoid a lot of these situations (e.g. missing Signed-off by lines that are only detected in CI). Having bazel check the hook installation would quickly ensure that everybody is brought along to that baseline, as it would be very difficult not to trip such check as part of normal development.

[1] https://opentitan.org/guides/getting_started/setup_fpga.html#using-the-bitstreams-repository