Guess who has an 64-bit RISC-V CPU?

[Cnoob]

I just received a RISC-V (MAiX DOCK) module from seeed.
I couldn't get it to connect with my PC using the micro usb to type c adapter.
But a usb type c lead works fine.

What is nice about this eco system is:

You can get it up and running straight out of the box. I was using Tera Term on windows 10, you do need the CH340 usb to serial chip drive pre installed.
Just copied a LCD demo program from GitHub, written in micro python and pasted it into Tera Term, it ran with no hitches.

At this price the RISC-V boards make cheap powerful microcontroller boards with a built in interested language, potentially an alternative to the Arduino.

   

[SiliconWizard]

Just received mine too (M1W dock).
Didn't try the USB adapter, I have a few USB-C cables, and no issue.

Just a tip (at least *I* was confused for a few sec, and this is not what I had seen on the pictures): the FPC connectors for the LCD and camera have the black latch opposite from where you insert the flat cable, wheras I'm more used of the latch being on the same side. At first I though the connectors where not mounted properly. Not sure if this is a newer (or older?) version of the board we can see on pictures and some videos.

Played around a bit with the pre-flashed MaixPy thing. Works fine so far. I'll be testing it with plain C later on.

For information, with MaixPy and the LCD screen, the board draws ~200mA from the 5V (USB) and gets pretty warm (not too surprised with a dual core @400MHz, but I was not expecting it to get that warm).

[hamster_nz]

I have a hard time getting the RISC-V GCC tools working. I tried building the RISC-V toolchain from source but had lots of dependency version failures.

Has anybody had success? If so, what distro/version are you using?

I'm running an older version of Ubuntu to allow Vivado to work - I might need to stand up a new VM, or maybe even (heavens forbid) play with Docker...

[colorado.rob]

I'm running an older version of Ubuntu to allow Vivado to work

I'm running Vivado 2018.3 on a brand new Fedora 29 distro.  Why the need for ancient Ubuntu?

[legacy]

Has anybody had success? If so, what distro/version are you using?

It's gcc-v8 related, and it seems it's deeply patched.
So I have to pass it, for now, we are already too busy with other projects.

(including making our DTB website more attractive, and safer)

[SiliconWizard]

I have a hard time getting the RISC-V GCC tools working. I tried building the RISC-V toolchain from source but had lots of dependency version failures.

Has anybody had success? If so, what distro/version are you using?

Haven't tried building it as of yet, I've downloaded the toolchain binaries from SiFive ( https://www.sifive.com/boards ) and plan on using that to begin with. I may try building it from source at some point... but one thing after another.

[Cicero]

Still need to get around to using mine, arrive late last week!

[brucehoult]

I have a hard time getting the RISC-V GCC tools working. I tried building the RISC-V toolchain from source but had lots of dependency version failures.

Has anybody had success? If so, what distro/version are you using?

I'm running an older version of Ubuntu to allow Vivado to work - I might need to stand up a new VM, or maybe even (heavens forbid) play with Docker...

Can you be a little more specific?

I build riscv-gnu-toolchain all the time -- literally weekly or more (often daily) with various ISA and ABI settings and custom modifications. No problems at all on 16.04 or 18.04.

p.s. now in Kirwee. Thinking about going into Hagley Park in the morning. Free in the weekend. H-1B and H-4 went in the passports on Tuesday, so we're off to San Mateo in a week from now.

[hamster_nz]

Was trying to use the kendryte Ubuntu toolchain on Ubuntu 16.04.5, but it doesn't seem to want to work. Guess I should have looked elsewhere at the start. It is always a bad sign when a somebody can't even name their download packages with the correct extension.

Code: [Select]

$ tar -tzvf Downloads/kendryte-toolchain-ubuntu-amd64-8.2.0-20190213.tar.gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
$ tar -tvf Downloads/kendryte-toolchain-ubuntu-amd64-8.2.0-20190213.tar.gz
drwxrwxrwx sunnycase/sunnycase 0 2019-02-13 01:28 kendryte-toolchain/
drwxrwxrwx sunnycase/sunnycase 0 2019-02-13 02:01 kendryte-toolchain/bin/
-rwxrwxrwx sunnycase/sunnycase 526688 2019-02-13 02:01 kendryte-toolchain/bin/libgmp.so.10
-rwxrwxrwx sunnycase/sunnycase 1596760 2019-02-13 02:01 kendryte-toolchain/bin/libisl.so.19

So I tried building from https://github.com/riscv/riscv-gnu-toolchain and got hung up on my version of libgmp. I'll try a little harder, since it seems it should work and I am doing something wrong...

Will send you a PM about catching up.

[brucehoult]

Some download methods (typically web browsers) silently unzip things, thus leaving you with a .tar.gz that is actually just a .tar now.

It has not been necessary for a number of years to specify z (or or Z or j or J) to tar. Just say "tar xf" and as long as the input is seekable it will automagically figure out what format it is in and call the correct decompressor as required.

[SiliconWizard]

Some follow-up. I managed to get it up and running with the GCC toolchain. Just a pic here, nothing too exciting yet, but it works!

I used the latest GCC toolchain binaries from SiFive (on Windows 7 here), and the KFLash tool to program the board's flash memory. Wrote my own makefiles (I don't like CMake much and never use it), started with the LCD example, tweaked/cleaned it a bit and added a LED blink on the second core.

I tested OpenOCD and managed to connect to the board via JTAG. Yeehaa. Works fine, but I think it still has limitations that are annoying. You can only connect to one core at a time. If you're just debugging, that would be kind of fine, even if not ideal. Now if you're willing to use JTAG to load code into SRAM and run it from there (without having to flash it), it works, but only on one core! That means that once you halted the CPU, you can only resume/start ONE core, the other won't run. Annoying! I may have to investigate a bit more, but I'm not holding my hopes too high for now. The KFLash tool works fine, but it seems to be Windows-only. So I'm not sure how you can do the same on Linux. Again, will have to investigate. Also, frankly it's a bit slowish. Wouldn't be a problem if you can upload code directly to SRAM for development purposes, but as I said above, it has limitations using OpenOCD for now. Just starting though, so if I figure it out, I'll give an update.

One thing to consider is that the documentation is extremely frugal. The K210 datasheet is not much more than a technical marketing sheet as of now, and there is no reference manual. It has been discussed on Kendryte's forum for a while with no update on the matter to be seen as of yet: https://forum.kendryte.com/
There is relatively little activity on the forum and the usual answer from the staff is to use the SDK that "should be enough" for any needs. Yeah. Even the SDK has very little documentation and you have to figure things out reading a lot of code.

This chip looks like a great platform, but Kendryte's team should get their act together IMO if they plan on selling their chips on a large scale. Without proper documentation, who is going to integrate that in a product?

[hamster_nz]

This chip looks like a great platform, but Kendryte's team should get their act together IMO if they plan on selling their chips on a large scale. Without proper documentation, who is going to integrate that in a product?

Yep, open standards are good and all, but if you don't want to tell people how to use your implementation of the standard then they shouldn't be surprised when people use other, better documented, implementations in preference to yours.

First-mover advantage is good and all, but documentation is key for long-term adoption.

(BTW SiFive's documentation is great!)

[SiliconWizard]

Yep, open standards are good and all, but if you don't want to tell people how to use your implementation of the standard then they shouldn't be surprised when people use other, better documented, implementations in preference to yours.

Well, certainly, and here the issue is not even with the RISC-V core itself, but everything else (peripherals, hardware considerations, etc) which is proprietary.
So just because this is a RISC-V-based processor doesn't mean it's self-documenting...

Now to be fair, with the standalone SDK, you can do a lot in a relatively short amount of time, and it looks much less bloated than STM32's HAL for instance. I was able to play with the FFT accelerator and I2S in no time. But still, it needs proper documentation to get past prototyping.

(BTW SiFive's documentation is great!)

I took a look and yes, it's pretty good.

[hamster_nz]

Finally got the toolchain & SDK to work. What a minor minefield. Here's how I did it on Ubuntu 16.04.

- Put  the contents of kendryte-toolchain-ubuntu-amd64-8.2.0-20190213.tar.gz from https://github.com/kendryte/kendryte-gnu-toolchain/releases in /opt.

- Clone the LicheeDan_K210_examples from Sipeed's GitHub at https://github.com/sipeed/LicheeDan_K210_examples

- Add /opt/kendryte-toolchain/bin to $PATH

- Tell the system where to find the libraries for the toolchain - easy way is "export LD_LIBRARY_PATH=/opt/kendryte-toolchain/bin"

You should then be able to build the examples in LicheeDan_K210_examples as instructions in the README

- Clone and program using https://github.com/sipeed/kflash.py, but note it has a "--board" option that isn't mentioned in the README.

Code: [Select]

python3 kflash.py -B dan -p /dev/ttyUSB0 ../LicheeDan_K210_examples/build/lcd.bin

Maybe I will update a few READMEs and submit pull requests...

[SiliconWizard]

Code: [Select]

python3 kflash.py -B dan -p /dev/ttyUSB0 ../LicheeDan_K210_examples/build/lcd.bin


Since last time, I also figured there was a kflash python script besides the Windows KFlash standalone program. Works on Linux. Didn't try it on Windows yet but it should also work on it.
Through kflash, You can also either program the Flash memory or just load the embedded SRAM (so that answers my previous question). It's just an option in the standalone program, I think there is also a similar option with the python script. Unfortunately, even when just loading the SRAM, it's still a bit slowish, because in both cases it first uploads some kind of secondary bootloader which itself takes a couple seconds. Not that bad but still way slower than with JTAG (except I still haven't figured out how to load SRAM with JTAG and then make the CPU restart on both cores).

As far as I've gotten it, this is how kflash works: first, it has to be able to control the RST and BOOT lines of the K210 to make it enter its bootloader, that's why you can see that they are controlled via DTR and CTS with the CH340 chip and transistors. Once it has entered the bootloader, kflash uploads a secondary bootloader, and then, it either programs the Flash chip or loads SRAM. Finally, it restarts the CPU (I think it resets it if you're programing the Flash memory, but if you're loading the SRAM, I'm not sure it resets it, but in any case it does restart at the start address in SRAM.)

Regarding building the GCC toolchain from source, I haven't done that manually as of yet, but I'm using Arch Linux on some of my dev machines and there is an AUR package for the RISC-V GCC toolchain that builds it from source (so when I have time, I'll just take a look at the package file as a guideline to do that manually), and it works fine.

Regarding the Sipeed example projects, be aware that they may not be completely up to date compared to the official Kendryte SDK, and that I've found a few bugs, so I'd recommend using Kendryte's standalone SDK examples instead and have a look at the Sipeed board 's schematic if needed (some I/Os need to be adapted to the board you're using, especially the MEMS microphone: its I2S data line was not correctly set in any of the projects, Sipeed's as well as Kendryte's, for the MAIX DOCK board, but it was unclear in both cases if they were using the on-board microphone or the external microphone array you can buy separately.)

So if you ever want to test the onboard microphone on the MAIX DOCK, this is the correct IO settings:

Code: [Select]

fpioa_set_function(20, FUNC_I2S0_IN_D0);
fpioa_set_function(30, FUNC_I2S0_WS);
fpioa_set_function(32, FUNC_I2S0_SCLK);


[zepan0]

Hi, it is getting warm is because wifi is open default, it cost many current.
you can shutdown wifi by pull down IO8.

[zepan0]

Hi, now we release Arduino IDE, you can use it program with C easily~
https://github.com/sipeed/Maixduino

[zepan0]

Hi, please try us Arduino IDE, it is very easy to use:
https://github.com/sipeed/Maixduino

[zepan0]

Hi, we have signed NDA with them, and get all data.
And we are willing to share any information to any one who need them.
I have already share some reg defination for some guys who want make their own OS for K210.
to kendryte team, they don't want personal developer use register to program(and they have no man to help hundreds users who use register), so they said "it is enough".
But for the business customer, they will place NDA to share more information.

We have package SDK to simple micropython(openmv compatible! and soon support openmv IDE!): https://github.com/sipeed/MaixPy
and also Arduino IDE(support KPU too!): https://github.com/sipeed/Maixduino

I think the easy use environment is more important for newbees(and they may accounted for 90% users).
Also we provide more information for senior engineer who are really need. For example, we help a guy debug MMU working~

welcome to join our telegram group to get more information : https://t.me/sipeed

[hamster_nz]

Hi zepan0 & thanks for your replies

The Micropython is very easy to use, and now I have the right software in the right places the SDK seems very simple to use.  Can't wait to start playing!

It looks more than likely it was just me not knowing the right build options when I tried the generic RISC-V toolchain build. I was getting weird linkage errors, maybe because the libraries where compiled with a smaller memory model for the libraries....

If I get a chance I will give the Arduino interface a try too.

[SiliconWizard]

Hi, it is getting warm is because wifi is open default, it cost many current.
you can shutdown wifi by pull down IO8.

Thanks for the pointer. That explains why it got that warm with MaixPy whereas it got a lot less with my own tests in C (not enabling the WiFi chip). I indeed have a board with a M1W module and not a M1.

I'd be interested in measuring the current draw on the different power rails of the K210 in different use cases (clock freq, peripheral usage, ...) but I guess I would have to design my own board for that.

[zepan0]

MAIX Bit is suit for power debug, as it have no shielding case, you can easily change resistance to adjust Vcore,  meansure the Voltage of 3 channel.
you can remove M1w's shield to do the test too.

tips: MAIX Bit reserved Vcore dynamic adjust circuit, but we NC it to prevent user burn the board...

[SiliconWizard]

MAIX Bit is suit for power debug, as it have no shielding case, you can easily change resistance to adjust Vcore,  meansure the Voltage of 3 channel.

Thanks.

[hamster_nz]

Hi, it is getting warm is because wifi is open default, it cost many current.
you can shutdown wifi by pull down IO8.

Hi, it is getting warm is because wifi is open default, it cost many current.
you can shutdown wifi by pull down IO8.

Was playing around with the I2S interfaces on the board  tonight. The 3W power amp was pretty noisy/hissy, but had a noticeable 'clicking' going on. Had a look at the 5V power rail that powers the D-class amp,  and it was dropping by ~0.25V for exactly 1ms, every 200ms. Changing the USB cable changed the amount of voltage drop.

Followed the hint above:

Code: [Select]

#define PIN_WIFI  8
#define GPIO_WIFI 3
....
int main(void)
{
....
    fpioa_set_function(PIN_WIFI, FUNC_GPIOHS3);
    gpiohs_set_drive_mode(GPIO_WIFI, GPIO_DM_OUTPUT);
    gpio_pin_value_t value = GPIO_PV_LOW;
    gpiohs_set_pin(GPIO_WIFI, value);
....
}

Clicking has now gone away... so I assume it was the ESP8285 WiFi chip drawing enough current over the USB port to cause the power rail to sag.

[zepan0]

you are right,  esp8285 cased it.