bl_iot_sdk icon indicating copy to clipboard operation
bl_iot_sdk copied to clipboard

Published 20 hours ago • verified publisher icon pine64

RISCV toolchain from source

Open v3l0c1r4pt0r opened this issue 4 years ago • 7 comments

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.

v3l0c1r4pt0r avatar Oct 28 '20 14:10 v3l0c1r4pt0r

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.

WildCryptoFox avatar Oct 28 '20 14:10 WildCryptoFox

@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.

gamelaster avatar Oct 28 '20 14:10 gamelaster

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?

jamespthomas avatar Oct 28 '20 14:10 jamespthomas

@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?

WildCryptoFox avatar Oct 28 '20 15:10 WildCryptoFox

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

jamespthomas avatar Oct 28 '20 15:10 jamespthomas

@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 avatar Oct 28 '20 18:10 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.

v3l0c1r4pt0r avatar Oct 28 '20 19:10 v3l0c1r4pt0r