RISCV toolchain from source

[v3l0c1r4pt0r]

Hi folks,

Do you think it might be useful to spend some time to recover toolchain from source? I mean to be able to build exactly the same versions of tools like GCC, libc, etc. and adjust some configuration bits if needed. I did this kind of stuff for few boards lately (https://github.com/v3l0c1r4pt0r/cc-factory) and I think I might be able to do the same thing for BL602. For the mentioned boards this allowed me to link to existing binaries, but I didn't have any working toolchain in these cases. Here we have some. So let me know, what do you think? Is it worth to do it now? I can spend an evening or two on that.

[WildCryptoFox]

If this was done quickly, the history could be rewritten to strip out the large binaries. However, this is generally a nasty thing to do to git and to all developers who cloned the repo already. I mean "quickly" here as in to minimize the inconvenience of the rewritten history.

[gamelaster]

@WildCryptoFox Well, this would be great, but as you noted, already many people forked it.
@v3l0c1r4pt0r Generally, I think this is good idea :) Also, probably the toolchain needs to be done for the core what is used in BL602, which is SiFive E24 from what I know.

[jamespthomas]

Not entirely sure we need to build this as part of the project, most distributions carry riscv64 cross compilers now, could simply document using them?

[WildCryptoFox]

@jamespthomas Ideally a generic toolchain would suffice but this involves custom extensions (I.e. the crypto coprocessor). It is plausible the toolchain is specialized for this target. Can someone confirm?

[jamespthomas]

@WildCryptoFox I did not know that, some documentation on this would be good (I saw your existing issue)

[v3l0c1r4pt0r]

@jamespthomas If I have working compiler, built from source I could in theory try compiling some sources from this repo and compare for any differences.

[v3l0c1r4pt0r]

So, I have good news. At least GCC and binutils are the exactly same binary as is available here. They simply copied CentOS variant (https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6.tar.gz) and that's it. Therefore it is not necessary to create any custom scripts.

Edit: I made a draft pull request #23 that deletes files known to be present in SiFive's package.