Re: [isa-dev] Digest for isa-dev@groups.riscv.org - 5 updates in 1 topic

[Robert Lipe]

I think that xpack, a popular distribution of RISC-V tools on Linux, is still shipping GCC 8.2, which is known to be sub-awesome for the faster moving aspects of RISC-V, like RV32E. I know I've seen 8.2 coming from someone in the last week. Maybe Buffalo Labs? 

With WCH shipping their CH32V003 parts claiming to be RV32E (which, last I looked, hadn't actually been ratified) parts as low as $0.10.in qty, I suspect we'll see an upswing in RV32E interest.

Like Vector 0.7.1, vendors ship chips before the specs are final and then outsource the tooling, ABI, and compatibility issues to others. :⁠-⁠\

They're already shipping a modified GCC and refusing to provide source. They provide source for OpenOCD but it's a giant un-upstreamable mess. Being an RBI member doesn't always mean they're good community members. 

On Sat, Jan 14, 2023, 5:48 AM <isa...@groups.riscv.org> wrote:

isa...@groups.riscv.org

Google Groups

Topic digest
View all topics

• RV32E toolchain - 5 Updates

RV32E toolchain

Tommy Murphy <tommy_...@hotmail.com>: Jan 13 12:01PM Where did you get that toolchain from? At 8.2.0 it seems very old. And it also looks like a bare metal toolchain but is being passed Linux toolchain flags and seems to be looking for glibc rather than newlib which is odd. I would start by looking for a more recent toolchain.

martin ribelotta <martinr...@gmail.com>: Jan 13 09:13AM -0300 Here: https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases This bundles a multilib toolchain with rv32e support.   This is the result of execute riscv-none-elf-gcc -print-multi-lib: rv32e/ilp32e;@march=rv32e@mabi=ilp32e rv32ea/ilp32e;@march=rv32ea@mabi=ilp32e rv32eac/ilp32e;@march=rv32eac@mabi=ilp32e rv32ec/ilp32e;@march=rv32ec@mabi=ilp32e rv32em/ilp32e;@march=rv32em@mabi=ilp32e rv32ema/ilp32e;@march=rv32ema@mabi=ilp32e rv32emac/ilp32e;@march=rv32emac@mabi=ilp32e rv32emc/ilp32e;@march=rv32emc@mabi=ilp32e rv32i/ilp32;@march=rv32i@mabi=ilp32 rv32ia/ilp32;@march=rv32ia@mabi=ilp32 rv32iac/ilp32;@march=rv32iac@mabi=ilp32 rv32iaf_zicsr/ilp32f;@march=rv32iaf_zicsr@mabi=ilp32f rv32iafc_zicsr/ilp32f;@march=rv32iafc_zicsr@mabi=ilp32f rv32iafd_zicsr/ilp32d;@march=rv32iafd_zicsr@mabi=ilp32d rv32iafdc_zicsr/ilp32d;@march=rv32iafdc_zicsr@mabi=ilp32d rv32ic/ilp32;@march=rv32ic@mabi=ilp32 rv32if_zicsr/ilp32f;@march=rv32if_zicsr@mabi=ilp32f rv32ifc_zicsr/ilp32f;@march=rv32ifc_zicsr@mabi=ilp32f rv32ifd_zicsr/ilp32d;@march=rv32ifd_zicsr@mabi=ilp32d rv32ifdc_zicsr/ilp32d;@march=rv32ifdc_zicsr@mabi=ilp32d rv32im/ilp32;@march=rv32im@mabi=ilp32 rv32ima/ilp32;@march=rv32ima@mabi=ilp32 rv32imaf_zicsr/ilp32f;@march=rv32imaf_zicsr@mabi=ilp32f rv32imafc_zicsr/ilp32f;@march=rv32imafc_zicsr@mabi=ilp32f rv32imafd_zicsr/ilp32d;@march=rv32imafd_zicsr@mabi=ilp32d rv32imafdc_zicsr/ilp32d;@march=rv32imafdc_zicsr@mabi=ilp32d rv32imc/ilp32;@march=rv32imc@mabi=ilp32 rv32imf_zicsr/ilp32f;@march=rv32imf_zicsr@mabi=ilp32f rv32imfc_zicsr/ilp32f;@march=rv32imfc_zicsr@mabi=ilp32f rv32imfd_zicsr/ilp32d;@march=rv32imfd_zicsr@mabi=ilp32d rv32imfdc_zicsr/ilp32d;@march=rv32imfdc_zicsr@mabi=ilp32d rv64i/lp64;@march=rv64i@mabi=lp64 rv64ia/lp64;@march=rv64ia@mabi=lp64 rv64iac/lp64;@march=rv64iac@mabi=lp64 rv64iaf_zicsr/lp64f;@march=rv64iaf_zicsr@mabi=lp64f rv64iafc_zicsr/lp64f;@march=rv64iafc_zicsr@mabi=lp64f rv64iafd_zicsr/lp64d;@march=rv64iafd_zicsr@mabi=lp64d rv64iafdc_zicsr/lp64d;@march=rv64iafdc_zicsr@mabi=lp64d rv64ic/lp64;@march=rv64ic@mabi=lp64 rv64if_zicsr/lp64f;@march=rv64if_zicsr@mabi=lp64f rv64ifc_zicsr/lp64f;@march=rv64ifc_zicsr@mabi=lp64f rv64ifd_zicsr/lp64d;@march=rv64ifd_zicsr@mabi=lp64d rv64ifdc_zicsr/lp64d;@march=rv64ifdc_zicsr@mabi=lp64d rv64im/lp64;@march=rv64im@mabi=lp64 rv64ima/lp64;@march=rv64ima@mabi=lp64 rv64imac/lp64;@march=rv64imac@mabi=lp64 rv64imaf_zicsr/lp64f;@march=rv64imaf_zicsr@mabi=lp64f rv64imafc_zicsr/lp64f;@march=rv64imafc_zicsr@mabi=lp64f rv64imafd_zicsr/lp64d;@march=rv64imafd_zicsr@mabi=lp64d rv64imafdc_zicsr/lp64d;@march=rv64imafdc_zicsr@mabi=lp64d rv64imc/lp64;@march=rv64imc@mabi=lp64 rv64imf_zicsr/lp64f;@march=rv64imf_zicsr@mabi=lp64f rv64imfc_zicsr/lp64f;@march=rv64imfc_zicsr@mabi=lp64f rv64imfd_zicsr/lp64d;@march=rv64imfd_zicsr@mabi=lp64d rv64imfdc_zicsr/lp64d;@march=rv64imfdc_zicsr@mabi=lp64d   You can see the support of rv32emac and all of their variants (e, ec, emc, etc). The @march, @mabi indicate the combination of -march=... and -mabi=... in the command line that select the correct mode.     El vie, 13 ene 2023 a las 9:01, Tommy Murphy (<tommy_...@hotmail.com>) escribió:

Tommy Murphy <tommy_...@hotmail.com>: Jan 13 12:33PM That link is to a toolchain that's much more recent than the one in your screenshot? ________________________________ From: martin ribelotta <martinr...@gmail.com> Sent: Friday, January 13, 2023 12:13:29 PM To: Tommy Murphy <tommy_...@hotmail.com> Cc: akhilesh Kotwaliwale <akhil...@gmail.com>; RISC-V ISA Dev <isa...@groups.riscv.org> Subject: Re: [isa-dev] RV32E toolchain   Here: https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases This bundles a multilib toolchain with rv32e support.   This is the result of execute riscv-none-elf-gcc -print-multi-lib: rv32e/ilp32e;@march=rv32e@mabi=ilp32e rv32ea/ilp32e;@march=rv32ea@mabi=ilp32e rv32eac/ilp32e;@march=rv32eac@mabi=ilp32e rv32ec/ilp32e;@march=rv32ec@mabi=ilp32e rv32em/ilp32e;@march=rv32em@mabi=ilp32e rv32ema/ilp32e;@march=rv32ema@mabi=ilp32e rv32emac/ilp32e;@march=rv32emac@mabi=ilp32e rv32emc/ilp32e;@march=rv32emc@mabi=ilp32e rv32i/ilp32;@march=rv32i@mabi=ilp32 rv32ia/ilp32;@march=rv32ia@mabi=ilp32 rv32iac/ilp32;@march=rv32iac@mabi=ilp32 rv32iaf_zicsr/ilp32f;@march=rv32iaf_zicsr@mabi=ilp32f rv32iafc_zicsr/ilp32f;@march=rv32iafc_zicsr@mabi=ilp32f rv32iafd_zicsr/ilp32d;@march=rv32iafd_zicsr@mabi=ilp32d rv32iafdc_zicsr/ilp32d;@march=rv32iafdc_zicsr@mabi=ilp32d rv32ic/ilp32;@march=rv32ic@mabi=ilp32 rv32if_zicsr/ilp32f;@march=rv32if_zicsr@mabi=ilp32f rv32ifc_zicsr/ilp32f;@march=rv32ifc_zicsr@mabi=ilp32f rv32ifd_zicsr/ilp32d;@march=rv32ifd_zicsr@mabi=ilp32d rv32ifdc_zicsr/ilp32d;@march=rv32ifdc_zicsr@mabi=ilp32d rv32im/ilp32;@march=rv32im@mabi=ilp32 rv32ima/ilp32;@march=rv32ima@mabi=ilp32 rv32imaf_zicsr/ilp32f;@march=rv32imaf_zicsr@mabi=ilp32f rv32imafc_zicsr/ilp32f;@march=rv32imafc_zicsr@mabi=ilp32f rv32imafd_zicsr/ilp32d;@march=rv32imafd_zicsr@mabi=ilp32d rv32imafdc_zicsr/ilp32d;@march=rv32imafdc_zicsr@mabi=ilp32d rv32imc/ilp32;@march=rv32imc@mabi=ilp32 rv32imf_zicsr/ilp32f;@march=rv32imf_zicsr@mabi=ilp32f rv32imfc_zicsr/ilp32f;@march=rv32imfc_zicsr@mabi=ilp32f rv32imfd_zicsr/ilp32d;@march=rv32imfd_zicsr@mabi=ilp32d rv32imfdc_zicsr/ilp32d;@march=rv32imfdc_zicsr@mabi=ilp32d rv64i/lp64;@march=rv64i@mabi=lp64 rv64ia/lp64;@march=rv64ia@mabi=lp64 rv64iac/lp64;@march=rv64iac@mabi=lp64 rv64iaf_zicsr/lp64f;@march=rv64iaf_zicsr@mabi=lp64f rv64iafc_zicsr/lp64f;@march=rv64iafc_zicsr@mabi=lp64f rv64iafd_zicsr/lp64d;@march=rv64iafd_zicsr@mabi=lp64d rv64iafdc_zicsr/lp64d;@march=rv64iafdc_zicsr@mabi=lp64d rv64ic/lp64;@march=rv64ic@mabi=lp64 rv64if_zicsr/lp64f;@march=rv64if_zicsr@mabi=lp64f rv64ifc_zicsr/lp64f;@march=rv64ifc_zicsr@mabi=lp64f rv64ifd_zicsr/lp64d;@march=rv64ifd_zicsr@mabi=lp64d rv64ifdc_zicsr/lp64d;@march=rv64ifdc_zicsr@mabi=lp64d rv64im/lp64;@march=rv64im@mabi=lp64 rv64ima/lp64;@march=rv64ima@mabi=lp64 rv64imac/lp64;@march=rv64imac@mabi=lp64 rv64imaf_zicsr/lp64f;@march=rv64imaf_zicsr@mabi=lp64f rv64imafc_zicsr/lp64f;@march=rv64imafc_zicsr@mabi=lp64f rv64imafd_zicsr/lp64d;@march=rv64imafd_zicsr@mabi=lp64d rv64imafdc_zicsr/lp64d;@march=rv64imafdc_zicsr@mabi=lp64d rv64imc/lp64;@march=rv64imc@mabi=lp64 rv64imf_zicsr/lp64f;@march=rv64imf_zicsr@mabi=lp64f rv64imfc_zicsr/lp64f;@march=rv64imfc_zicsr@mabi=lp64f rv64imfd_zicsr/lp64d;@march=rv64imfd_zicsr@mabi=lp64d rv64imfdc_zicsr/lp64d;@march=rv64imfdc_zicsr@mabi=lp64d   You can see the support of rv32emac and all of their variants (e, ec, emc, etc). The @march, @mabi indicate the combination of -march=... and -mabi=... in the command line that select the correct mode.     El vie, 13 ene 2023 a las 9:01, Tommy Murphy (<tommy_...@hotmail.com<mailto:tommy_...@hotmail.com>>) escribió: Where did you get that toolchain from? At 8.2.0 it seems very old. And it also looks like a bare metal toolchain but is being passed Linux toolchain flags and seems to be looking for glibc rather than newlib which is odd. I would start by looking for a more recent toolchain.   -- You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org<mailto:isa-dev+u...@groups.riscv.org>. To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/LO0P265MB6866C115A8D6B0362C2F686FF9C29%40LO0P265MB6866.GBRP265.PROD.OUTLOOK.COM<https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/LO0P265MB6866C115A8D6B0362C2F686FF9C29%40LO0P265MB6866.GBRP265.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.

martin ribelotta <martinr...@gmail.com>: Jan 13 10:59AM -0300 Yes, that's it. The last version is gcc 12.2.0 but you have 11.x, 10.x and 8.x series   El vie, 13 ene 2023 a las 9:33, Tommy Murphy (<tommy_...@hotmail.com>) escribió:

Tommy Murphy <tommy_...@hotmail.com>: Jan 13 02:57PM @akhilesh Kotwaliwale - can you post (attach) a full build log to show what exactly is going on please?   Also - can you post logs rather than screenshots as they are very difficult to read on some devices and for some people.

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to isa-dev+u...@groups.riscv.org.

[Tommy Murphy]

> I think that xpack, a popular distribution of RISC-V tools on Linux, is still shipping GCC 8.2, which is known to be sub-awesome for the faster moving aspects of RISC-V, like RV32E. I know I've seen 8.2 coming from someone in the last week. Maybe Buffalo Labs? 

The xPack Project provides RISC-V bare metal toolchain builds all the way from 7.1 to 12.2.

https://xpack.github.io/riscv-none-elf-gcc/releases/

I have no idea why anybody would choose to use 8.2 these days though.

[martin ribelotta]

El sáb, 14 ene 2023 a las 17:35, Robert Lipe (<rober...@gmail.com>) escribió:

I think that xpack, a popular distribution of RISC-V tools on Linux, is still shipping GCC 8.2, which is known to be sub-awesome for the faster moving aspects of RISC-V, like RV32E. I know I've seen 8.2 coming from someone in the last week. Maybe Buffalo Labs? 

With WCH shipping their CH32V003 parts claiming to be RV32E (which, last I looked, hadn't actually been ratified) parts as low as $0.10.in qty, I suspect we'll see an upswing in RV32E interest.

Like Vector 0.7.1, vendors ship chips before the specs are final and then outsource the tooling, ABI, and compatibility issues to others. :⁠-⁠\

They're already shipping a modified GCC and refusing to provide source. They provide source for OpenOCD but it's a giant un-upstreamable mess. Being an RBI member doesn't always mean they're good community members. 

Id you are planning to use gcc with wch parts, please, check this build:

https://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1

From hydrabus3 guys.

This gcc version have a patch to incorporate "WCH-Interrupt-fast" attribute required to vendor firmware extension that use hardware stack on interrupt (this extension must be enabled in a vendor-specific CSR but make a big improve in interrupt latency)

This is the specific patch:

https://github.com/hydrausb3/riscv-none-elf-gcc-xpack/blob/xpack/patches/gcc-12.2.0.patch.diff

I asked the MounRiver people about the source code of the gcc distributed with MounRiver Studio (old xpack gcc 8.x version with some patches) and the response was that they are working with gcc guys to integrate in the mainstream (I no have reason to doubt in it but the lack of some source code or at least minimal diff file to accomplish with GPL licence is very irregular)

Additionally, interrupt handling attribute is not the only modification about WCH gcc (provided by MounRiver). WCH cores add some proprietary X extensions to the C extension that are not documented (WCH said that their are working on it)

 

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAGJ6%2BwrQz0OsQ4%2BvPL%2BTgKjoj7TcmxDWWe0TGb5sg2%3DzC3HaJw%40mail.gmail.com.

[Robert Lipe]

Good call. It took a while to reconstruct where I saw this as it's been raining RISC-V parts lately. (Yay!) Fortunately, I had a reasonably small set to look through as this was fresh in my mind.

Mounriver is the tool provider for WCH, the aforementioned RV32E maker and GPL violator.

In the MacOS tab of http://www.mounriver.com/download

is a zip file. The zip file contains:

➜  z ls
openocd_arm64.zip
openocd_x86_64.zip
xpack-riscv-none-embed-gcc-8.2.0.zip

So it's the binaries (and not sources) of OpenOCD for both Intel and M1/M2 Macs and a distribution of 

distro-info/licenses/gcc-10.2.0 which has the COPYING files.

The binary is definitely 8.2.0 as evidenced by the runtime and date:

bin/*gcc --version
riscv-none-embed-gcc (xPack GNU RISC-V Embedded GCC x86_64) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.

But the funny thing is that if you strings the binary, it looks like it was built in a directory named 10.2.0:

/Users/wch/Work/riscv-none-embed-gcc-10.2.0-1.2/darwin-x64/sources/riscv-gcc-10.
2.0-1.1/gcc/diagnostic.c
(xPack GNU RISC-V Embedded GCC x86_64)
8.2.0
<https://github.com/sifive/freedom-tools/issues/>

The Linux tarfile contains a GCC that's also 8.2.0, seemingly also built from the (excellent) SiFive tree but it's built in a sensibly named source tree:
(xPack GNU RISC-V Embedded GCC, 64-bit)
8.2.0
<https://github.com/sifive/freedom-tools/issues>
/Host/home/yyyy/Work/riscv-none-embed-gcc-8.2.0-3.1/sources/riscv-gcc-8.2.0-3.1/libcpp/include/line-map.h

What a weird distribution. Some combination of WCH, Mounriver, and XPack are doing strange things that are less than helpful. But that's why I was thinking that XPack was 8.2.0 - because the most recent XPack I'd downloaded WAS 8.2.0.

This is the wrong list for it, but this kind of stuff is where I wish RVI could push back on their members and lean into providing current tools, providing sensible licenses, actually providing sources upon request, nudging them into upstreaming, etc. I know their GCC at the very least includes support for new interrupt modes to support their Sparc-like register window thingy for interrupts, but they've rebuffed source requests.

RJL

[Tommy Murphy]

> Mounriver is the tool provider for WCH, the aforementioned RV32E maker and GPL violator.

They're not the only RVI member in breach of GPL, unfortunately... :⁠-⁠|

[Robert Lipe]

Hey, Martin.

This gcc version have a patch to incorporate "WCH-Interrupt-fast" attribute required to vendor firmware

Good stuff. Thanx. I plan to ignore their fast interrupt stuff (I value a single GCC for ALL my RISC-V build - people that care about saving N clock cycles on an interrupt can chase that) but that's good to see. 
 

I asked the MounRiver people about the source code of the gcc distributed with MounRiver Studio (old xpack gcc 8.x version with some patches) and the response was that they are working with gcc guys to integrate in the mainstream (I no have reason to doubt in it but the lack of some source code or at least minimal diff file to accomplish with GPL licence is very irregular)

This specific patch doesn't look contentious to the relatively untrained eye. I scanned the gcc-patches and gcc archives back to Jan 2021 and didn't see this patch actually submitted.

I have looked at the openocd diffs. Without being unkind, there is no way a sober maintainer would accept their support for their proprietary JTAG replacement, WCH-Link. That code is unpleasant and rife with logic errors and misunderstandings about how C works.

At least they will part with that source upon request.
 

Additionally, interrupt handling attribute is not the only modification about WCH gcc (provided by MounRiver). WCH cores add some proprietary X extensions to the C extension that are not documented (WCH said that their are working on it)

Ummm hmmmm.

Whether it's upstreamed or not, it's a GPL violation.

Thanx for confirming the xpack contents and finding that patch for the interrupt attribute!
RJL

[Robert Lipe]

On Sat, Jan 14, 2023 at 4:49 PM Tommy Murphy <tommy_...@hotmail.com> wrote:

> Mounriver is the tool provider for WCH, the aforementioned RV32E maker and GPL violator.

They're not the only RVI member in breach of GPL, unfortunately... :⁠-⁠|

Sadly, I think most of us can name a few.

My point wasn't to name and shame WCH alone on this. My point was that I'd like to see membership in RVI mean that you aren't also actively backstabbing RVI at the same time. 

It may be beyond the scope of this list, but I'm pretty sure that people on this list are down the virtual halls from the right people to help make RVI membership be a badge of honor for good and ethical participation.

Well, if not good and ethical, at least NOT actively violating licenses.

RJL.

[martin ribelotta]

El sáb, 14 ene 2023 a las 20:08, Robert Lipe (<rober...@gmail.com>) escribió:

Hey, Martin.

This gcc version have a patch to incorporate "WCH-Interrupt-fast" attribute required to vendor firmware

Good stuff. Thanx. I plan to ignore their fast interrupt stuff (I value a single GCC for ALL my RISC-V build - people that care about saving N clock cycles on an interrupt can chase that) but that's good to see. 
 

I asked the MounRiver people about the source code of the gcc distributed with MounRiver Studio (old xpack gcc 8.x version with some patches) and the response was that they are working with gcc guys to integrate in the mainstream (I no have reason to doubt in it but the lack of some source code or at least minimal diff file to accomplish with GPL licence is very irregular)

This specific patch doesn't look contentious to the relatively untrained eye. I scanned the gcc-patches and gcc archives back to Jan 2021 and didn't see this patch actually submitted.

This patch is made by an enthusiast related to the hydrabus3 community and is really not problematic... The real thing about WCH version of gcc is the unknown X instructions for "code reduction" (from QungKe processor v4 ref. man.) that is cleanly emitted by the MounRiver toolchain (checked by objdump by me in both toolchains) that are fully undocumented and create real fragmentation into the ecosystem.

 

I have looked at the openocd diffs. Without being unkind, there is no way a sober maintainer would accept their support for their proprietary JTAG replacement, WCH-Link. That code is unpleasant and rife with logic errors and misunderstandings about how C works.

When I have some time, I try to reverse engine the TIO/TCK protocol (apparently is a cJTAG variant with some proprietary TAP access)

[martin ribelotta]

El sáb, 14 ene 2023 a las 20:15, Robert Lipe (<rober...@gmail.com>) escribió:

On Sat, Jan 14, 2023 at 4:49 PM Tommy Murphy <tommy_...@hotmail.com> wrote:

> Mounriver is the tool provider for WCH, the aforementioned RV32E maker and GPL violator.

They're not the only RVI member in breach of GPL, unfortunately... :⁠-⁠|

Sadly, I think most of us can name a few.

Is extremely sad because existing BSD-Style license toolchains like LLVM/Clang that provides the closed source behaviour that these guys need (and, in my understand, is more friendly to the developers than gcc codebase) 

 

My point wasn't to name and shame WCH alone on this. My point was that I'd like to see membership in RVI mean that you aren't also actively backstabbing RVI at the same time. 

It may be beyond the scope of this list, but I'm pretty sure that people on this list are down the virtual halls from the right people to help make RVI membership be a badge of honor for good and ethical participation.

Any guys know a RISC-V MCU company that plays nice with toolchain/ecosystem?

 - Microchip?

 - Boufalo? I see the toolchain and SDK and (apparently) is a good player in this scenario...

 - Espressif? (Maybe this is the most near-to-ideal?)

 - unknown?

May be interesting to create a list of current offers in MCU (the most active field for RV32/RV64 arch at now), but officially maintained maybe? Some time ago, the RISC-V site maintained a list like it but was fastly outdated..

 

Well, if not good and ethical, at least NOT actively violating licenses.

RJL.

Thnks and best regards! 

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAGJ6%2BwpDefBKQtEhgjZON-hosXUfJn_TSPdUZmmE6YvhepTUUQ%40mail.gmail.com.

[Robert Lipe]

Any guys know a RISC-V MCU company that plays nice with toolchain/ecosystem?

 - Microchip?

 - Boufalo? I see the toolchain and SDK and (apparently) is a good player in this scenario...

 - Espressif? (Maybe this is the most near-to-ideal?)

 - unknown? 

 

May be interesting to create a list of current offers in MCU (the most active field for RV32/RV64 arch at now),

We can try. Let's think about volume RISC-V MCUs:

Bouffalo and Espressif both license cores from others (SiFive and with BL, now T-head) and treat them like a black box. Both ship or point to the vendor's toolchain unmodified. So BL60x, 70x, and ESP32-C3 use unmodified SiFive chains for each platform.  In both cases, SiFive "chicken bits" may be enabled by startup code, but there's nothing unique to these chips.

The very new BL808 uses the T-Head version of GCC (they need that 0.7.1 Vector support...) for all three cores. I haven't received BL618 to be sure (ordered it today) or ESP32-L6 to know what they're using. Both companies frame the core GCC/Binutils/GDB stuff with a fuller SDK for access to peripherals and such.

Gigadevices ships Nuclei cores.  There are no vendor extensions in it. Dead simple RV32IMAC.

Kendryte K210 as used in so many of the older Sipeed boards are straight-up Rocket, I think. There's an NPU on the chip and it implements an old version of the spec that governs MMU, but it's an old chip and pretty well understood now. K510 is newer, but I can't tell that any of those have made it to hobbyists.

StarFive's JH-7100 and JH-7110 use the SiFive U74 cores and the CPU cores are very vanilla, with the SiFive chains being recommended. (TBC: they're vanilla because SiFive has done a great job upstreaming work.) The SoCs have some compliance with bus vs. cache coherency that's out of spec, but I think those are technically "errata" and not extensions.

D1 and D1s by allwinner (as well as the big core in BL808) are a bit of a mess. Allwinner has a history of GPL compliance issues. They use the C906 cores and have a couple of unratified extensions and they use V0.7.1, so Vector 1.0 compatibility is right out. (Bruce Holt often points out that if they'd called it anything other than "RVV", they wouldn't take the heat and would probably still have the best-selling vector product in history.) They used some of the bits marked reserved in the PTEs to mark caching attributes of individual pages via PBMT, making them incompatible with MMU code for other RV39 parts. They were trying to solve the same problem, but they trampled the spec to "fix" it. So there are DMA and icache sync issues.  Linux, like GCC, originally pushed back on these changes as not being spec-conforming, but I think they sold enough parts to move the GNUdists to just dealing with them. These aren't really the code generation issues of the type that GCC, GDB, or Binutils much concern themselves over, but this part is a giant pain for system devs. I don't know that we have a great plan for ABIs with libraries for OSes that run on parts with both RVV 0.7.1 and 1.0, for example, or how we handle shared libraries written for one linking against objects expecting another. Maybe that exists and I just haven't seen it. It feels like a game of chicken with 1.0 devices that should finally skip this year.. 

For D1, D1S, and BL808, I think the T-head chain is officially recommended, but I'm not sure that the distros like Debian are actually shipping with T-head as the primary installed chains. Maybe they're just ignoring Vector and the goofy indexed addressing modes and such other highlighted features and just treating them as normal, conforming RISC-V parts. They were late to ship sources, but I think xuantie-gnu-toolchain is now complete. All the T-head stuff uses another proprietary JTAG mutant.

WCH uses the Mounriver stuff we've talked about for their Qingke cores, complete with compliance issues that go with it. Their chain had "magic" opcodes which are still instrumented. Again , proprietary JTAG.

Bluetrum has the AB32VG1. It's optimized for audio processing, so it has some kind of DSP extension, but so little is spoken of this part in my world that I don't know what they use.

I think we thus have two clusters:
A) MCUs that can reasonably run a majority of their functionality with stock GNU/LLVM chains. 
B) MCUs where you can either use the vendor's chain or ignore headlining features of the chips. These include T-Head designs like BL808 or D1 and all the WCH parts. It's probably not a coincidence that this cluster tends to be the parts with proprietary JTAG replacements.

I personally build 32 and 64-bit code for all the parts in (A) (SiFive from BL706 up to JH-7110, GD32V, k210, etc. for both RV32 and RV64) using a single compiler in Homebrew. https://github.com/riscv-software-src/homebrew-riscv. Only this week am I really straying from that as I venture into the CH203, '307, and soon, the RV32e '003.

I think that's a decent summary of volume MCU parts that are available in the western world. If I've missed any or there's more info needed, LMK.

 

but officially maintained maybe? Some time ago, the RISC-V site maintained a list like it but was fastly outdated..

Early last year, I mailed pages worth of updates and they fell on the floor. "Thanks, we're already working on it." Another year of changes has passed.

RJL

P. s. Some I may recycle some amount of these words for a blog post. 

[Tommy Murphy]

Thanks for the great summary of currently available volume RISC-V parts Robert.

Would it be worth capturing that info somewhere like this?

https://wiki.osdev.org/RISC-V#Real_Hardware

I don't see any official RVI wiki or similar that accepts community input. Pity.

[Robert Lipe]

On Mon, Jan 16, 2023 at 4:09 AM Tommy Murphy <tommy_...@hotmail.com> wrote:

Thanks for the great summary of currently available volume RISC-V parts Robert.

Thank you. 

Would it be worth capturing that info somewhere like this?

https://wiki.osdev.org/RISC-V#Real_Hardware

Oh, my. That's quite out of date. We're quite far from "not existing much". I think I added five boards - that I expect to be high volume - in the last six weeks. (JH-7110 * 2, BL808 * 2, BL704, BL616 is in the mail. It's Raining RISC-V!)

If that's worth updating, I'll sign up for an account[1] and, at the very least, update the list of SoCs, even if I'm less confident of my ability to remember all the boards. (OTOH, I try to own one of everything that's under $100 anyway, so I should just look in my parts drawers. :-) ) I'll admit my collection/knowledge/writing is heavily slanted toward MCUs but I suspect that anyone coding for a kilo-core RISC-V part isn't exactly roaming the web looking for such answers.

I'll probably put some version of those words on https://robertlipe.com as it's almost all about RISC-V anyway.  Maybe OSDev should point to that article once it exists.

I'm absolutely open to receiving updates (privately or via WP comments) and keeping such an article up to date. 

RJL

[1] Hrmph. Their "prove you're a human" questions are quite PC-centric from the early 90's.