riscv: add new kendryte k210 chip

[yannishuber]

This PR adds support for the Kendryte K210 chip and the Sipeed MAix Bit board.

TODO:

• Runtime code
• UART
• GPIO
• GPIO interrupts
• SPI
• I²C
• Unit tests

[yannishuber]

The CMSIS-SVD repository has temporarly been changed and will be reset to the original upstream once cmsis-svd/cmsis-svd#104 is merged.

[aykevl]

Overall this looks good. I have left a number of comments inline, however.
Regarding cmsis-svd, while I would prefer to use upstream, I think practically it would be better to fork it into tinygo-org (as we did previously) and keeping it there, even as cmsis-svd upstream merges PRs. Switching between submodule remotes has resulted in trouble before so let's do it once for good.

Looking at this PR, there are really three somewhat distinct changes (two necessary as precondition to K210 support):

• Adding support for non-default code models.
• Adding support for 64-bit RISC-V.
• Adding support for the K210 chip.

You could cleanly separate these in different commits (with a rebase and force-push) or actually make separate PRs, what you prefer. Separate PRs may be faster to merge individually.

[yannishuber]

@aykevl I made two PRs in the tinygo-org/cmsis-svd repo to update it and to incorporate the unmerged fix (tinygo-org/cmsis-svd#3 and tinygo-org/cmsis-svd#4). I will update the submodule repository as soon as these are merged.

I will also separate this pull request into 3 distinct ones as suggested.

[deadprogram]

All of the PRs to the tinygo fork of cmsis-svd are done. Please continue with the rest of the steps so we can get this merged! Thank you.

[deadprogram]

I should be receiving a Sipeed MAix BiT board next week, so I can also help test.

[deadprogram]

So this PR is the precursor to adding the board and machine files for the MAiX BiT, correct? @yannishuber are you planning on doing this? I just got my boards today. 😸

[yannishuber]

@deadprogram yes exactly, i also have this board and I am currently working on it. It should be done soon.

[deadprogram]

So should this PR still be considered draft, or should we look at merging it?

[deadprogram]

@yannishuber is this still a draft PR, or should it be able to be merged into dev?

[yannishuber]

@deadprogram Sorry I didn't see your first reply. No I was thinking of adding the code related to the maix-bit in this PR but I can also make a separate PR if you want. I will work on this today.

[deadprogram]

It can be in the same PR, since that lets us test the full implementation that way. Thank you!

[aykevl]

This chip seems to be pretty similar to the SiFive fe310, so much that I wonder whether some code can be reused between them. That would require putting the SiFive and Kendryte vendor code in the same package (perhaps device/riscv?).

[yannishuber]

...now that each goroutine has its own stack.

@aykevl is that also the case with the coroutines scheduler?

In any case, this can easily be added at a later date.

Well in that case I think this PR is finally ready.

[aykevl]

You may want to rebase on the dev branch to make sure this PR still works after #1142 has been merged.

[yannishuber]

You may want to rebase on the dev branch to make sure this PR still works after #1142 has been merged.

I already did that. The changes from #1142 are incorporated.

[aykevl]

I think this is ready to merge. I'm a bit unsure about the nonstandard API for pin modes, but I guess it's fine for now as it's still usable this way (but with fixed pins).

[deadprogram]

OK, the time has come. Now rebasing into dev

Incredble work @yannishuber and fantastic effort all around. Thank you!