search

litex-hub / linux-on-litex-rocket

Run 64-bit Linux on LiteX + RocketChip
BSD 2-Clause "Simplified" License
181 stars 18 forks source link

ci: add GitHub Actions workflow #11

Closed jluebbe closed 3 years ago

jluebbe commented 3 years ago

This adds the groundwork for automatically building bitstreams via GitHub Actions. The artifacts are available for download from the build page: https://github.com/jluebbe/linux-on-litex-rocket/actions/runs/847442335

mithro commented 3 years ago

FYI - @umarcor

jluebbe commented 3 years ago

Note that when trying to actually build the bitstream for the ECP5, you will get an error: https://github.com/jluebbe/linux-on-litex-rocket/runs/2595089523?check_suite_focus=true#step:7:683

It seems an update to the pythondata-cpu-rocket is needed: https://github.com/strumtrar/pythondata-cpu-rocket/commit/897c6606c0d8a0e8b6c30c47a5b1cc74b204d4ec

gsomlo commented 3 years ago

On Sun, May 16, 2021 at 11:11:33AM -0700, Jan Lübbe wrote:

Note that when trying to actually build the bitstream for the ECP5, you will get an error: [...] It seems an update to the pythondata-cpu-rocket is needed: strumtrar/ @.***

@jluebbe, thanks for the PR. I'll look into the finer details over the next week or so, and figure out how far we can comfortably take this.

FWIW, things are building OK for me on Fedora 34, with (distro-packaged) yosys 26e01a6, trellis 210a0a7, and nextpnr f0e30ab.

I notice that ci.yml references ubuntu 18.04, no idea what versions of the toolchain are supposed to be installed there, so maybe some of the "breakage" may have something to do with that.

I'm in the middle of updating all my systems to F34, and as soon as I'm done with that I'll take another pass at possibly updating the toolchain components and pythondata-cpu-rocket to their latest respective upstream.

If that gets CI to stop alerting on false positives, then I guess I'm OK with adding it... :)

Cheers, --Gabriel

umarcor commented 3 years ago

Please, see the review of litex-hub/linux-on-litex-vexriscv#230. The duplication between this workflow and the one there proves the point that a common set of images for this organisation is desirable. I suggest creating litex-hub/actions or litex-hub/ci for gathering common resource to be used in multiple repos.

jluebbe commented 3 years ago

@jluebbe, thanks for the PR. I'll look into the finer details over the next week or so, and figure out how far we can comfortably take this. FWIW, things are building OK for me on Fedora 34, with (distro-packaged) yosys 26e01a6, trellis 210a0a7, and nextpnr f0e30ab. I notice that ci.yml references ubuntu 18.04, no idea what versions of the toolchain are supposed to be installed there, so maybe some of the "breakage" may have something to do with that.

The Ubuntu 18.04 is only used for the VM, the actual build uses the HDL container, so the toolchain versions are supplied by it. As i understand it, it builds the master branch at least every Friday: https://github.com/hdl/containers/blob/main/debian-buster/yosys.dockerfile#L52

Those containers are based on Debian buster.

I'm in the middle of updating all my systems to F34, and as soon as I'm done with that I'll take another pass at possibly updating the toolchain components and pythondata-cpu-rocket to their latest respective upstream. If that gets CI to stop alerting on false positives, then I guess I'm OK with adding it... :) Cheers, --Gabriel

I'm still not convinced that it's a false positive, at least when building with current master versions. :)

jluebbe commented 3 years ago

Closing as this approach is not preferred by the @enjoy-digital (see https://github.com/litex-hub/linux-on-litex-vexriscv/pull/230#issuecomment-843178359)