Support for macOS

[sstaub]

Can you add support for macOS? In the moment I get following error message with PlatformIO:

[ivankravets]

Ping @riscv-mcu

[ivankravets]

@Zepan @btx000 do we have any updates on this issue? A ton of reports go to PlatformIO Core repository.

[yesitsme007]

Same issue would be great to get an update about root cause or workaround. It seems that the toolchain and openocd for MacOS are missing in the package repositories.

[YuzukiTsuru]

Mac~$ platformio platform install gd32vPlatformManager: Installing gd32v
Downloading  [####################################]  100%          
gd32v @ 1.1.0 has been successfully installed!
PackageManager: Installing toolchain-gd32v @ ~9.2.0
Error: Could not find a version that satisfies the requirement '~9.2.0' for your system 'darwin_x86_64'

QAQ Please

[yesitsme007]

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.

[ivankravets]

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

[yesitsme007]

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

[ivankravets]

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

[yesitsme007]

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.

[GPSBabelDeveloper]

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: $ file booger.o booger.o: ELF 64-bit LSB relocatable, UCB RISC-V, version 1 (SYSV), not stripped Roberts-MacBook-Pro:bin robertlipe$ ./*objdump --disassemble booger.o

booger.o: file format elf64-littleriscv

Disassembly of section .text:

0000000000000000 : 0: 1141 addi sp,sp,-16

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

[ivankravets]

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!

[fanghuaqi]

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.

[GPSBabelDeveloper]

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 notifications@github.com 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 https://github.com/sipeed/platform-gd32v/issues/6#issuecomment-605742302, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3VADZ5IZCO54SPRVXTXSDRJ74BVANCNFSM4IWWXUZQ .

[fanghuaqi]

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

[GPSBabelDeveloper]

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 notifications@github.com 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 https://github.com/sipeed/platform-gd32v/issues/6#issuecomment-605769908, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3VAD4IUFOJI7RHXBRB5A3RKAKTPANCNFSM4IWWXUZQ .

[GPSBabelDeveloper]

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.

[good-point-lab]

One year later I step into the same problem on OSX during an attempt to install a compressed library to a project: $ pio lib -g install tfmicro.zip Library Storage: /Users/administrator/.platformio/lib Library Manager: Installing tfmicro.zip Error: Could not find the package with 'tfmicro.zip' requirements for your system 'darwin_x86_64'

[indrora]

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?

[GPSBabelDeveloper]

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 https://github.com/sipeed/platform-gd32v/issues/6#issuecomment-890421294, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3VADZLMGSN6WYIJCDRZGTT2SHANANCNFSM4IWWXUZQ .

[indrora]

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.

[GPSBabelDeveloper]

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 https://github.com/sipeed/platform-gd32v/issues/6#issuecomment-890639091, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3VAD5B3UH4HQJN27ZRKZ3T2XWJJANCNFSM4IWWXUZQ .

[nanoant]

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 rv32imac ilp32 for GD32V, rather than 64-bit.

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 riscv-nuclei-elf-gdb don't depend on brew:

% otool -L ~/.platformio/packages/toolchain-gd32v/bin/riscv-nuclei-elf-gdb    
/Users/me/.platformio/packages/toolchain-gd32v/bin/riscv-nuclei-elf-gdb:
    /opt/brew/opt/gettext/lib/libintl.8.dylib (compatibility version 11.0.0, current version 11.0.0)
    /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
    /System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.16)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)
    /opt/brew/opt/xz/lib/liblzma.5.dylib (compatibility version 8.0.0, current version 8.5.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /opt/brew/opt/mpfr/lib/libmpfr.6.dylib (compatibility version 8.0.0, current version 8.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)

Same applies to tool-openocd-gd32v and tool-gd32vflash that I've build same way.

If maintainers want to have some Catalina and up build prepared I can help. Just ping me here.