Support for macOS #6
Comments
|
Ping @riscv-mcu |
|
@Zepan @btx000 do we have any updates on this issue? A ton of reports go to PlatformIO Core repository. |
|
Same issue would be great to get an update about root cause or workaround. |
QAQ Please |
|
As a temporary workaround I have created a fork with support for MacOS tooling. It uses a probably slightly older toolchain and is more or less untested. I could compile and upload an Arduino blink example. More information can be found on the project page. I am not sure how useful this is, but maybe it helps and you might give it a try. |
|
@yesitsme007 thanks! Where did you get binaries for compiler and openOCD? Did you use the official RISC-V toolchain? Could you try this toolchain https://bintray.com/beta/#/platformio/dl-packages/toolchain-riscv?tab=files? |
|
I used the toolchain from this page: GNU Embedded Toolchain — v2019.08.0. Scroll down and search for "GNU Embedded Toolchain". I will give your link a try, may take some time. I tried to compile my own toolchain from Git, but I could not figure out the correct configuration for the configure script. So I got some binaries but they did not work and produced many errors during compilation of the blink sample. OpenOCD was compiled from the source (master). |
|
@Zepan @btx000 could we use official RISC-V toolchain? It's already in our CDN for all OSes. Does GD32V have custom ISA and require custom toolchain? |
|
I did a quick smoke test just by replacing the binaries and I could compile and upload the Blink example. Seems to work. To which platform does this belong? If there are no objections I will replace the toolchain in my fork and refer to the offical package repo instead. I get a for each and every binary this stupid popup "This software is from an unidentified developer". I guess it will not happen when installed by PlatformIO. I assume it is caused by manual downloading this from bintray in the browser. I also can only test the Longan board. |
|
This bugreport is wandering around everywhere. Is there still no official toolchain for GD32V for MacOS? Is it "just" a matter of pulling sources (precisely where, @ivankravets ?) and wrangling a build? The tree from jfrog is still a 64-bit build: booger.o: file format elf64-littleriscv Disassembly of section .text: 0000000000000000 : I don't really care much about IDEs. I "just" want to be able to build my own OS and maybe a filesystem and ship them to my GD32V boards. I keep running into kendrite builds and python interpreters. I just want a boot sector. :-) I have Macs that I can dedicate to compilation for a few hours, in case someone actually hasn't. Point me to a source tree and and some samples as a test case for a WIO Lite and I'll make a go of it if necessary. (I was a GCC maintainer long, long ago...) |
|
We would like to fix this but can't. We need to wait any official news from Nuclei and Sipeed companies. @fanghuaqi do you have any updates on a toolchain for macOS? Thanks! |
|
Hi @ivankravets , currently we didn't have task force to build MAC OS version, I will talk with team to see any body who is familiar with MAC OS building, thanks. |
|
If you just need someone to crank builds of something that works on Linux
and can provide a little initial handholding (precisely what source, what
targets matter, testing procedure, a contact for help for patch acceptance,
etc.) I can probably help with that. If there is someone that's mastered CI
for the Linux builds for Travis or Github Actions or whatever, we should
bring this to parity.
There is a ridiculously confusing array of gd32v (different boards
shouldn't need different *compilers*; they may need different libcrts and
such) vs. kendrite and "bare" toolchains that are still deeply entangled
with an RTOS and expectations of specific boot monitors loaded on the
development devices, and such that it's bewildering. Let's make it better.
…On Sun, Mar 29, 2020 at 8:57 PM Huaqi Fang ***@***.***> wrote:
Hi @ivankravets <https://github.com/ivankravets> , currently we didn't
have task force to build MAC OS version, I will talk with team to see any
body who is familiar with MAC OS building, thanks.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VADZ5IZCO54SPRVXTXSDRJ74BVANCNFSM4IWWXUZQ>
.
|
|
@GPSBabel Thanks for your reply and help, actually, the GD32VF103 chips are based on Nuclei RISC-V processors, and now we provide official support for these chips and our evaluation core in FPGA board in our platform here, please check in https://github.com/Nuclei-Software, and we also provide platform-nuclei. And by the way, our source code for nuclei riscv-toolchain and openocd are placed in https://github.com/riscv-mcu/, we are also discussing to compile MAC-OS version, but currently lack of time. Thanks |
|
Thank you. That is hugely helpful. This tells me from helping to populate
the Mac equivalent for https://nucleisys.com/download.php is the start.
Cracking open rv_linux_bare_19-12-12-13-12 I see there is one GNU toolchain
build. The code generator in riscv-nuclei-elf-gcc-9.2.0 is a single code
generator; there is no 64-bit target here. (So we're completely out of
Kendrite 210's space. I now realize that's a competing chip company. Got
it.) Starting from HEAD of
https://github.com/riscv-mcu/riscv-gnu-toolchain?utm_source=platformio&utm_medium=docs
I
should be able to configure and build a riscv-nuclei-elf- target
If I can provide that as a tarball, we've saved everyone some frustration
and many hours of build time, right? With that in hand, the next thing
toattack is Nuclei which, probably won't need much work since it's the
target side, and then to hello world. on the GD32VF103CBT6 on Sipeed’s
Longan Nano and their Wio Lite.
Sound like a reasonable attack plan?
Has there ever been a MacOS build and it's just fallen into disrepair or is
this new host?
…On Sun, Mar 29, 2020 at 11:02 PM Huaqi Fang ***@***.***> wrote:
@GPSBabel <https://github.com/gpsbabel> Thanks for your reply and help,
actually, the GD32VF103 chips are based on Nuclei RISC-V processors, and
now we provide official support for these chips and our evaluation core in
FPGA board in our platform here, please check in
https://github.com/Nuclei-Software, and we also provide platform-nuclei
<https://github.com/Nuclei-Software/platform-nuclei>.
And by the way, our source code for nuclei riscv-toolchain and openocd are
placed in https://github.com/riscv-mcu/, we are also discussing to
compile MAC-OS version, but currently lack of time.
Thanks
Huaqi
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VAD4IUFOJI7RHXBRB5A3RKAKTPANCNFSM4IWWXUZQ>
.
|
|
As a tip to others, while a build from source is possible, there is a homebrew version that can be 'brew installed" with WAY less effort: https://github.com/riscv/homebrew-riscv Everything seems to be defaulting to the rv64 ISA, but you can pass the flags to get RV32 code. As a relative newcomer to RISC-V, I can't tell how much vendor super-sauce is in the respective toolchains for BumbleBee/GD32VF103CBT6 vs K210. Beyond the defaults (which matter at interrupt time) it looks like the code gen actually is the same. The simulators are flaky and I've had no success with JTAG tools or inbuilt debugging, but it at least emits opcodes and sometimes runs spike or Qemu. I even spun up Ubuntu 2019.3 on an old laptop and the state of code gen was about the same, but USB on it was totally unrecognized, so I'm back to focusing on MacOS-hosted dev. |
|
One year later I step into the same problem on OSX during an attempt to install a compressed library to a project: |
With the new ARM64 devices from Apple, what's the plan? |
|
The toolchain in Homebrew works well on M1; I submitted fixes the week they
came out. I work on several gd32v projects with it.
I don't use platformio.
…On Sat, Jul 31, 2021, 7:17 PM Morgan Gangwere ***@***.***> wrote:
Platform Manager: Installing gd32v
Platform Manager: gd32v @ 1.2.1 has been installed!
Tool Manager: Installing platformio/toolchain-gd32v @ ~9.2.0
Error: Could not find the package with 'platformio/toolchain-gd32v @ ~9.2.0' requirements for your system 'darwin_arm64'
With the new ARM64 devices from Apple, what's the plan?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VADZLMGSN6WYIJCDRZGTT2SHANANCNFSM4IWWXUZQ>
.
|
Be that as it may, this ticket is about platformio on macos. If you have a suggestion on how to make platformio work with the binaries shipped by Homebrew, we're all ears. |
|
It looks like platformio is "just" a wrapper around the standard GNU tools.
Platformio seems to require sipeed/platform-gd32v. Of interest,
builder/main.py seems to be the thing that names other things. It uses the
Nuclei toolchain which is a slightly chopped up version of the GNU chain,
too.
Looking at
https://github.com/sipeed/platform-gd32v/blob/b32d98889df9100aaa35724081d85d16eadc3c5d/builder/main.py
it seems to be responsible for naming the important part of the tools. I'd
start by teaching it to use tools named things like
"riscv64-unknown-elf-gcc". For the compiler, linker, and the assembler,
you'll tweak -march and -mabi to force the 64-bit build into 32-bit mode.
You can see an example of this done at:
https://github.com/robertlipe/riscv7/blob/main/tools/common.mk
sweeten to taste per
https://docs.platformio.org/en/latest/platforms/creating_platform.html
and
https://github.com/platformio/platform-shakti/blob/develop/builder/main.py
This issue has been open for almost two years. Sipeed hasn't accepted
offers of help to make this combination work better.As such, you're going
to either brace yourself for some work in getting all the wrappers right or
just be prepared to give up PlatformIO and use one of the other numerous
similar wrapper combinations, such as those from the chip makers that
provide IDEs, or just use the "raw" tools, and use whatever build system
you prefer to just compile, assemble, link, and load the software yourself.
Be prepared to learn a little about Bare Metal Programming when learning
about standard libraries, exceptions, etc. The combination of Mac hosting
and RISC-V target is just not a large audience and support from the vendors
is pretty poor. Related to that, the toolchain produced by SiFive also
generally works pretty well on GD32V if you're prepared to tweak the
startup code, linker addresses, some of the standard libraries, etc. That
pile of bits is pretty much the ones I suggested, but with a layer of
SiFive stuff added as defaults.
…On Sun, Aug 1, 2021 at 8:12 PM Morgan Gangwere ***@***.***> wrote:
I don't use platformio.
Be that as it may, this ticket is about platformio on macos.
If you have a suggestion on how to make platformio work with the binaries
shipped by Homebrew, we're all ears.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VAD5B3UH4HQJN27ZRKZ3T2XWJJANCNFSM4IWWXUZQ>
.
|
|
Hi there. For everyone struggling with building on macOS I've prepared build-toolchain-gd32v.sh that essentially cooks the missing package. It requires brew and some packages in place, but builds maintainers version of GCC rather than mainland one used by homebrew-riscv. Also defaults to This script is not perfect, since it assumes HomeBrew packages. But with some not big effort, we could make standalone build for it, building all needed libs in place instead so tools such as Same applies to If maintainers want to have some Catalina and up build prepared I can help. Just ping me here. |
Can you add support for macOS?
In the moment I get following error message with PlatformIO:
The text was updated successfully, but these errors were encountered: