[OT ... somewhat] Anyone playing around with RISC-V.

[Ken Pettit [e-mail] [nuttx]]

Hey Gang,

Is anyone else out there besides me playing around with the RISC-V
processor architecture developed at UC Berkley? I'm working on an ASIC
that needs a small processor and have decided to integrate a RISC-V
core. I'm currently adding a debug interface to the Z-scale 32-bit
verilog implementation (called V-scale) and working on an FPGA version
for verification and devlopment purposes.

I'm thinking about doing a NuttX port for RISC-V. There are other
companies out there (http://www.lowrisc.org) developing open source
RISC-V based microontrollers also.

http://riscv.org
https://github.com/ucb-bar/

Anyone else on list interested in this stuff?
Ken

[Gregory Nutt [e-mail] [nuttx]]

Isn't RISC-V close to MIPS?

Off topic...

A few years back, I was discussing a port to MilkyMist with Sébastien
Bourdeauducq (now called M-Lab,
https://en.wikipedia.org/wiki/M-Labs). But that never really went
anywhere. A few other discussions followed.

The is LM32, not RISC-V, but is also open.

greg

[Ken Pettit [e-mail] [nuttx]]

Post by Gregory Nutt ***@yahoo.com [nuttx]
Isn't RISC-V close to MIPS?

Yes, RISC-V is probably closest to MIPS than anything else, though
different enough that it isn't MIPS. There are a lot of other open
cores out there, but the permissive BSD license with RISC-V makes it the
easiest to work with. Reportedly, there are big Tech giants like
Google, HP and Oracle backing RISC-V. Of course they may have alterior
motives to gain control or somthing like with Android / Google Play, etc.

I guess it's just the new cool kid on the block :) At any rate, I have
7 different FPGA boards laying around here and I have finally decided
which one to start out with for validating my debug interface / mini-SoC
implementation.

Ken

Post by Gregory Nutt ***@yahoo.com [nuttx]
Off topic...
A few years back, I was discussing a port to MilkyMist with Sébastien
Bourdeauducq (now called M-Lab,
https://en.wikipedia.org/wiki/M-Labs). But that never really went
anywhere. A few other discussions followed.
The is LM32, not RISC-V, but is also open.
greg

[Dave Marples [e-mail] [nuttx]]

Hmm...a bit of crossover from day job to hobby job here :-)

In the day job we (Technoution) are a founding member of the RISC-V
foundation alongside those giants. One of the missions of the members is
to spread the word about RISC-V but I'm afraid I'm not the expert on
this stuff - I can pass questions, opinions and input along though. One
of the things that will make RISC-V a success is a large ecosystem
supporting it. OS support (and thus nuttx) is essential.

We currently have our own implementation of a RISC-V core and we are
gearing towards a SEU safe variant which we hope will be finished this
summer. Furthermore, we are creating the entire SEU safe memory chain
(safe L1, L2 caches) and we have a SEU safe MMU in the planning.

The guy responsible for leading this work is dreaming of a SIL certified
core we can plug into high assurance, medical, aviation and space
applications...but we're a ways from that yet and, as I said, I'm not
the expert, but I'll happily pass stuff along.

DAVE

Post by Ken Pettit ***@gmail.com [nuttx]

Post by Gregory Nutt ***@yahoo.com [nuttx]
Isn't RISC-V close to MIPS?

Yes, RISC-V is probably closest to MIPS than anything else, though
different enough that it isn't MIPS. There are a lot of other open
cores out there, but the permissive BSD license with RISC-V makes it
the easiest to work with. Reportedly, there are big Tech giants like
Google, HP and Oracle backing RISC-V. Of course they may have
alterior motives to gain control or somthing like with Android /
Google Play, etc.
I guess it's just the new cool kid on the block :) At any rate, I
have 7 different FPGA boards laying around here and I have finally
decided which one to start out with for validating my debug interface
/ mini-SoC implementation.
Ken

[Ramtin Amin [e-mail] [nuttx]]

hello

I'd like to re-open this thread.

Has anyone done any porting around LM32 or m0r1k ?

If not, what would be a good start to look at ? any example of arch ?

thx

Post by Dave Marples ***@marples.net [nuttx]
Hmm...a bit of crossover from day job to hobby job here :-)
In the day job we (Technoution) are a founding member of the RISC-V
foundation alongside those giants. One of the missions of the members is to
spread the word about RISC-V but I'm afraid I'm not the expert on this
stuff - I can pass questions, opinions and input along though. One of the
things that will make RISC-V a success is a large ecosystem supporting it.
OS support (and thus nuttx) is essential.
We currently have our own implementation of a RISC-V core and we are
gearing towards a SEU safe variant which we hope will be finished this
summer. Furthermore, we are creating the entire SEU safe memory chain (safe
L1, L2 caches) and we have a SEU safe MMU in the planning.
The guy responsible for leading this work is dreaming of a SIL certified
core we can plug into high assurance, medical, aviation and space
applications...but we're a ways from that yet and, as I said, I'm not the
expert, but I'll happily pass stuff along.
DAVE
Isn't RISC-V close to MIPS?
Yes, RISC-V is probably closest to MIPS than anything else, though
different enough that it isn't MIPS. There are a lot of other open cores
out there, but the permissive BSD license with RISC-V makes it the easiest
to work with. Reportedly, there are big Tech giants like Google, HP and
Oracle backing RISC-V. Of course they may have alterior motives to gain
control or somthing like with Android / Google Play, etc.
I guess it's just the new cool kid on the block :) At any rate, I have 7
different FPGA boards laying around here and I have finally decided which
one to start out with for validating my debug interface / mini-SoC
implementation.
Ken

[[e-mail] [nuttx]]

I am not aware of any activity. Many people are interested and willing to help (including me), but no one has taken ownership of such a project. Without leadership, efforts like these never happen.

[Ramtin Amin [e-mail] [nuttx]]

I'm fine taking the leadership of such a project. I do it for fun

I am currently using in fact migen/misoc in order to generate a SoC based
on lm32 or m0r1k. What is interesting with misoc is that it generates a
header with all the CSR addresses, which could be reused in an automated
way.

So far, what i'd like to know is if we rather make it run first in a
simulated environement or, if we sould get it to run on a proper device
(such as pipistrelo or papilio pro for example).

Also, what would be the very first step in getting nuttx to run on a new
architecture ? basically what would be the hello world

Post by ***@yahoo.com [nuttx]
I am not aware of any activity. Many people are interested and willing to
help (including me), but no one has taken ownership of such a project.
Without leadership, efforts like these never happen.

[[e-mail] [nuttx]]

Also, what would be the very first step in getting nuttx to run on a new architecture  ? basically what would be the hello world

I imagine that MIPS would be the closest architecture.  In the end, you need two directories.  The first can be cloned from MIPs.  You might get a starting point like:

cd nuttx/arch
cp -a mips riscv

The nuttx/arch/riscv would (eventually) contain all of the RISC-V CPU specific logic.  It should not depend on particular boards or emulations.

The other directory that you need is at nuttx/configs/<myboard>.  That is where all of the board-specific (or emulation-specific) logic would go.  You might be able to clone one of the pic32mx directories to get a start there too.

The most difficult part of the part is the context switching and interrupt handling.  There has to be a state structure defined in nuttx/arch/riscv/irq.h that lays out how all registers are stored. For MIPS this is: https://bitbucket.org/nuttx/nuttx/src/master/arch/mips/include/mips32/irq.h

That structure must be used in a few places:

- When an interrupt occurs, that must be stored on the stack in exactly that form.
- When the interrupt returns, that must be restore from the stack in exactly that form.
- And during context switches.

MIPS interrupt handling is here: https://bitbucket.org/nuttx/nuttx/src/92341600a7aa42ffea7f58edcaee02250535e31f/arch/mips/src/pic32mx/pic32mx-head.S?at=master&fileviewer=file-view-default#pic32mx-head.S-504

But MIPS has probably the most obscure interrupt logic of all supported logic so it is not easy to follow.

A context switch is really like an interrupt (and in some architectures such as ARMv7-M is implemented as an interrupt).  A context switch really consists of two parts:  One task is suspended and another resumes.

- To suspend a task, its registers are saved in the structure just as is done on interrupt entry,
- To resume a task, you restore its registers just as is done on interrupt exit

MIPS uses a software interrupt to perform context switching. You can see that here: https://bitbucket.org/nuttx/nuttx/src/master/arch/mips/src/mips32/up_swint0.c

The only task's registers are saved on entry and exit from the software interrupt (back in pic32mx-head.S). Within up_swint0.c, it just manipulates the register save structures. It is more efficient to use a non-interrupting approach in the spirit of setjmp/longjmp, but that requires a LOT more effort.

If you look around, you can probably find examples of all of this interrupt handling logic that you can borrow in other code.

Once all of the is done, you are finished with the "black magic" programming. All of the rest of the job is relatively easy (but still a lot of work). That is when other people can help you a lot.

Greg

[[e-mail] [nuttx]]

If you are interested in doing this, there are two things I can do for you now to help you get started:


1) When you have the first code ready to submit, I can create a branch in the main repository for you. With that branch, other people can help you with the work.


2) We can open open an Issue in Bitbucket to discuss issues and review code and designs.


Greg

[Ramtin Amin [e-mail] [nuttx]]

Ok.

i was looking the code there for the bios:
https://github.com/m-labs/misoc/blob/master/misoc/software/libbase/crt0-lm32.S

I see a save and restore function down there, is it something like that ?

Post by ***@yahoo.com [nuttx]
If you are interested in doing this, there are two things I can do for you
1) When you have the first code ready to submit, I can create a branch in
the main repository for you. With that branch, other people can help you
with the work.
2) We can open open an Issue in Bitbucket to discuss issues and review code and designs.
Greg

[[e-mail] [nuttx]]

Yes. I can't tell if it is sufficient or not by looking at the code, but it looks like the correct stuff. The logic needs to save and restore all general purpose registers, stack pointers, status registers, interrupt state registers. Basically everything that is need to get the task back to exactly the same operational state.

[Ramtin Amin [e-mail] [nuttx]]

Hi Greg.

So far I created all the up_*.c files with stub for all the functions, so
nuttx compiles and generate a binary files.
To what stage should my code get in order to get it on a branch as you
suggested ?

Post by ***@yahoo.com [nuttx]
If you are interested in doing this, there are two things I can do for you
1) When you have the first code ready to submit, I can create a branch in
the main repository for you. With that branch, other people can help you
with the work.
2) We can open open an Issue in Bitbucket to discuss issues and review code and designs.
Greg

[Gregory Nutt [e-mail] [nuttx]]

We can create the branch anytime you like. I am not too picky about
things on branches, not until we are ready to merge into the master.

Post by Ramtin Amin ***@gmail.com [nuttx]
Hi Greg.
So far I created all the up_*.c files with stub for all the functions,
so nuttx compiles and generate a binary files.
To what stage should my code get in order to get it on a branch as you
suggested ?
If you are interested in doing this, there are two things I can do
1) When you have the first code ready to submit, I can create a
branch in the main repository for you. With that branch, other
people can help you with the work.
2) We can open open an Issue in Bitbucket to discuss issues and
review code and designs.
Greg

[Ken Pettit [e-mail] [nuttx]]

Post by Ramtin Amin ***@gmail.com [nuttx]
Also, what would be the very first step in getting nuttx to run on a

new architecture ? basically what would be the hello world
I imagine that MIPS would be the closest architecture. In the end,
you need two directories. The first can be cloned from MIPs. You
cd nuttx/arch
cp -a mips riscv
The nuttx/arch/riscv would (eventually) contain all of the RISC-V CPU
specific logic. It should not depend on particular boards or emulations.

The thing with RISC-V is that it is really an ISA definition and not a
chip definition. And the ISA allows for 32 bit, 64 bit or 128 bit
processor implementations. Plus you can have various extensions (there
are 4 different privlege levels, optional HW integer math and FPU
implementation, optional atomic instructions, etc.) So the
nuttx/arch/riscv directory ends up with several subdirectories for
rv32i, rv32ima, rv64i, etc. This is what I have implemented, an rv32im
subdirectory. I also have a chip specific directory (the
microcontroller core that uses my nanorv32 is called nr5m100). And
external interrupts are only loosly defined, so you will end up putting
a lot of interrup handling in you chip specific directory.

I built a small microcontroller class RISC-V called nanorv32 and wrote a
sofware environment for it that looks very much like NuttX so that an
eventual port would be seamless. I called that software environment
nanos (for Not AN OS) since it is just a for loop with interrpt handling
and lots of structure. But it has an arch/riscv directory structure
identical to NuttX, follows the same coding standard, and even borrows
the libc library, etc. My arch directory looks like this:

nanos/arch/riscv/
include
arch.h
nr5
rv32im
Kconfig
src
common
Makefile
nr5
chip
rv32im

What I found is that debugging a full port to NuttX requires a source
level debugger. The RISC-V community didn't have these available until
just recently, and I am currently implementing the RISC-V debugging
standard in my Verilog code. It's getting close, but I've probaby got
another week or two before I get full connectivity from OpenOCD to my
little processor.

The other directory that you need is at nuttx/configs/<myboard>. That
is where all of the board-specific (or emulation-specific) logic would
go. You might be able to clone one of the pic32mx directories to get a
start there too.

I have one of these too ( nanos/configs/nr5m100-nexys4 ). Turns out
that so far, there isn't much in there, but then I have mosly been
focusing on the CPU architecture stuff. The SiFive group now has a
couple of open source boards they have released with fully debuggable
RISC-V processors (based on FPGA boards like Virtex 7, Digilent Arty
(Artix 7), etc.). The Arty board is only $99 ... perhaps porting NuttX
to that platform would be a good option.

Ken

[[e-mail] [nuttx]]

Ken,

You have been busy! I recall talking about this some time back, but I did not realize that you had made so much progress.

Can we bring onto a branch into the main repository? I appreciate that you might not be quite ready, but it sounds like now might be the time that there could be some others willing to work on the port.

I could keep everything on the branch until the logic is pristine.

Greg

[Ramtin Amin [e-mail] [nuttx]]

Hi Ken

If I had to go with one of those CPU, which one would you advice me to use
considering what you have already done:

LM32:
https://github.com/m-labs/lm32/tree/84b3e3ca0ad9535acaef201c1482342871358b08
M0R1K:
https://github.com/openrisc/mor1kx/tree/69b97fcb43b35d6c6639ecc68e63d912c09ee8da
PICORV32:
https://github.com/cliffordwolf/picorv32/tree/e630bedda4f16d5f061f93879177a2d6b2a66d29

Ken,
You have been busy! I recall talking about this some time back, but I did
not realize that you had made so much progress.
Can we bring onto a branch into the main repository? I appreciate that you
might not be quite ready, but it sounds like now might be the time that
there could be some others willing to work on the port.
I could keep everything on the branch until the logic is pristine.
Greg

[Ken Pettit [e-mail] [nuttx]]

Hi Ramtin,

Well, PICORV32 is the code base I started with to create NanoRV32. I
added a bunch of stuff to it and that's why it is now Nano instead of
Pico. PICORV32, while nice and small, was a bit too small for what I
needed. The LM32 and MOR1K are really different architectures and
wouldn't belong in an arch/riscv directory, but would have directories
of their own.

So based on that, I would say you would either want to use PICORV32 or
NanoRV32 (I could make the source available). It runs on a Digilent
NEXYS-4 board, but could be ported to any board easily. As I mentioned,
I am about 1 or 2 weeks from having GDB source level debugging working
with it (PICORV32 has NO debug support).

Ken

Post by Ramtin Amin ***@gmail.com [nuttx]
Hi Ken
If I had to go with one of those CPU, which one would you advice me to
https://github.com/m-labs/lm32/tree/84b3e3ca0ad9535acaef201c1482342871358b08
https://github.com/openrisc/mor1kx/tree/69b97fcb43b35d6c6639ecc68e63d912c09ee8da
https://github.com/cliffordwolf/picorv32/tree/e630bedda4f16d5f061f93879177a2d6b2a66d29
Ken,
You have been busy! I recall talking about this some time back,
but I did not realize that you had made so much progress.
Can we bring onto a branch into the main repository? I appreciate
that you might not be quite ready, but it sounds like now might be
the time that there could be some others willing to work on the port.
I could keep everything on the branch until the logic is pristine.
Greg

[Ramtin Amin [e-mail] [nuttx]]

Ken,
Have you managed to get a soc running in an emulated environment ?
Today with misoc, we get a SoC completely emulated with Serial port, and
even ethernet (tun/tap)
That could be nice to get nuttx running this way, so anyone could contribute

What would you think ?

Post by Ken Pettit ***@gmail.com [nuttx]
Hi Ramtin,
Well, PICORV32 is the code base I started with to create NanoRV32. I
added a bunch of stuff to it and that's why it is now Nano instead of
Pico. PICORV32, while nice and small, was a bit too small for what I
needed. The LM32 and MOR1K are really different architectures and wouldn't
belong in an arch/riscv directory, but would have directories of their own.
So based on that, I would say you would either want to use PICORV32 or
NanoRV32 (I could make the source available). It runs on a Digilent
NEXYS-4 board, but could be ported to any board easily. As I mentioned, I
am about 1 or 2 weeks from having GDB source level debugging working with
it (PICORV32 has NO debug support).
Ken
Hi Ken
If I had to go with one of those CPU, which one would you advice me to use
LM32: https://github.com/m-labs/lm32/tree/84b3e3ca0ad9535acaef201c148234
2871358b08
M0R1K: https://github.com/openrisc/mor1kx/tree/
69b97fcb43b35d6c6639ecc68e63d912c09ee8da
PICORV32: https://github.com/cliffordwolf/picorv32/tree/
e630bedda4f16d5f061f93879177a2d6b2a66d29

Ken,
You have been busy! I recall talking about this some time back, but I did
not realize that you had made so much progress.
Can we bring onto a branch into the main repository? I appreciate that
you might not be quite ready, but it sounds like now might be the time that
there could be some others willing to work on the port.
I could keep everything on the branch until the logic is pristine.
Greg

[Ken Pettit [e-mail] [nuttx]]

Hi Ramtin,

Yes, I have my RISC-V core based SoC (serial, timers, GPIO) running in
simulation with emulated Serial port connected to Linux minicom using
Verilog / ncsim DPI (Direct Programming Interface) and even simulated
JTAG debugging to OpenOCD (also using DPI). My Verilog simulation opens
socket port 3334 and connects it to the simulated JTAG / TAP port of the
processor. Then I run openocd with remote_bit_bang JTAG driver and
connect to port 3334. Curently from OpenOCD, I am able to read the JTAG
IDCODE, read / write debug registers and debug RAM.

I am now in the process of getting the RISC-V side debug support
implemented (I wrote the debug ROM yesterday, have interrupts working,
etc.). I may actually be less than a week away, but hard to tell. I
don't have a need for Ethernet on my initial design, but that may change
with the 2nd generation of our SoC.

Is misoc a MIPS processor? MIPS and RISC-V are similar, but yet different.

Ken

Post by Ramtin Amin ***@gmail.com [nuttx]
Ken,
Have you managed to get a soc running in an emulated environment ?
Today with misoc, we get a SoC completely emulated with Serial port,
and even ethernet (tun/tap)
That could be nice to get nuttx running this way, so anyone could contribute
What would you think ?
Hi Ramtin,
Well, PICORV32 is the code base I started with to create
NanoRV32. I added a bunch of stuff to it and that's why it is now
Nano instead of Pico. PICORV32, while nice and small, was a bit
too small for what I needed. The LM32 and MOR1K are really
different architectures and wouldn't belong in an arch/riscv
directory, but would have directories of their own.
So based on that, I would say you would either want to use
PICORV32 or NanoRV32 (I could make the source available). It runs
on a Digilent NEXYS-4 board, but could be ported to any board
easily. As I mentioned, I am about 1 or 2 weeks from having GDB
source level debugging working with it (PICORV32 has NO debug
support).
Ken

Post by Ramtin Amin ***@gmail.com [nuttx]
Hi Ken
If I had to go with one of those CPU, which one would you advice
https://github.com/m-labs/lm32/tree/84b3e3ca0ad9535acaef201c1482342871358b08
<https://github.com/m-labs/lm32/tree/84b3e3ca0ad9535acaef201c1482342871358b08>
https://github.com/openrisc/mor1kx/tree/69b97fcb43b35d6c6639ecc68e63d912c09ee8da
<https://github.com/openrisc/mor1kx/tree/69b97fcb43b35d6c6639ecc68e63d912c09ee8da>
https://github.com/cliffordwolf/picorv32/tree/e630bedda4f16d5f061f93879177a2d6b2a66d29
<https://github.com/cliffordwolf/picorv32/tree/e630bedda4f16d5f061f93879177a2d6b2a66d29>
Ken,
You have been busy! I recall talking about this some time
back, but I did not realize that you had made so much progress.
Can we bring onto a branch into the main repository? I
appreciate that you might not be quite ready, but it sounds
like now might be the time that there could be some others
willing to work on the port.
I could keep everything on the branch until the logic is pristine.
Greg

[Ramtin Amin [e-mail] [nuttx]]

Ken,

Misoc is a "tool" based on migen. Basically migen (milkymyst generator) is
"A Python toolbox for building complex digital hardware"
it lets you use python instead of verilog. Quite powerful once you get used
to it.

MiSoC uses migen in order to create a soc. So it implements for examples
interconnect (wishbones, endpoints..) and so on.

Then it becomes a matter of making a SoC wiht a couple of lines.
There is a fork that integrates both migen/misoc called litex that I use
which currently implements a SoC with either m32 or mor1k or picorv32
( https://github.com/enjoy-digital/litex/ )

but adding a cpu is a matter of adding a couple of lines.

If you publish your nanorv32, I could try to get a simulated SoC running
with it, if you use wishbone buses. Could be fun in fact.

Post by Ken Pettit ***@gmail.com [nuttx]
Hi Ramtin,
Yes, I have my RISC-V core based SoC (serial, timers, GPIO) running in
simulation with emulated Serial port connected to Linux minicom using
Verilog / ncsim DPI (Direct Programming Interface) and even simulated JTAG
debugging to OpenOCD (also using DPI). My Verilog simulation opens socket
port 3334 and connects it to the simulated JTAG / TAP port of the
processor. Then I run openocd with remote_bit_bang JTAG driver and connect
to port 3334. Curently from OpenOCD, I am able to read the JTAG IDCODE,
read / write debug registers and debug RAM.
I am now in the process of getting the RISC-V side debug support
implemented (I wrote the debug ROM yesterday, have interrupts working,
etc.). I may actually be less than a week away, but hard to tell. I don't
have a need for Ethernet on my initial design, but that may change with the
2nd generation of our SoC.
Is misoc a MIPS processor? MIPS and RISC-V are similar, but yet different.
Ken
Ken,
Have you managed to get a soc running in an emulated environment ?
Today with misoc, we get a SoC completely emulated with Serial port, and
even ethernet (tun/tap)
That could be nice to get nuttx running this way, so anyone could contribute
What would you think ?

Post by Ken Pettit ***@gmail.com [nuttx]
Hi Ramtin,
Well, PICORV32 is the code base I started with to create NanoRV32. I
added a bunch of stuff to it and that's why it is now Nano instead of
Pico. PICORV32, while nice and small, was a bit too small for what I
needed. The LM32 and MOR1K are really different architectures and wouldn't
belong in an arch/riscv directory, but would have directories of their own.
So based on that, I would say you would either want to use PICORV32 or
NanoRV32 (I could make the source available). It runs on a Digilent
NEXYS-4 board, but could be ported to any board easily. As I mentioned, I
am about 1 or 2 weeks from having GDB source level debugging working with
it (PICORV32 has NO debug support).
Ken
Hi Ken
If I had to go with one of those CPU, which one would you advice me to
LM32: https://github.com/m-labs/lm32/tree/84b3e3ca0ad9535acaef201c
1482342871358b08
M0R1K: https://github.com/openrisc/mor1kx/tree/69b97fcb43b35
d6c6639ecc68e63d912c09ee8da
PICORV32: https://github.com/cliffordwolf/picorv32/tree/e630
bedda4f16d5f061f93879177a2d6b2a66d29

Ken,
You have been busy! I recall talking about this some time back, but I
did not realize that you had made so much progress.
Can we bring onto a branch into the main repository? I appreciate that
you might not be quite ready, but it sounds like now might be the time that
there could be some others willing to work on the port.
I could keep everything on the branch until the logic is pristine.
Greg

[Ramtin Amin [e-mail] [nuttx]]

Hi greg

well I thought about it a little more, and so far, I have my directories
like this under arch
misoc
src/
lm32/
common/
include/
lm32
*.h
Kconfig

The reason for that is that is that arch will hold all the driver that wold
be the same wether we use lm32 or mor1k or picorv32.. The processor should
be selected using the menuconfig.

I manage to use the AVR makefile and modify them in order to get it to work
with lm32-elf-gcc

knowing that my save/restore registers happen in the crt0.S, how am I
supposed to define the struct xcptcontext

Also, if I got it right, I need to have a irqsave and irqrestore function.
irqsave should disable interrupt, and save all the regs.
irqrestore should re-enble interupt and restore. (correct me if am wrong)


Regarding context switching. what should trigger the interupt that does the
context switching ? should I put a timer in my design that triggers an
interrupt at every xxx clock tick, (xxx being possible a CSR) ?

Post by Ramtin Amin ***@gmail.com [nuttx]
Ken,
Misoc is a "tool" based on migen. Basically migen (milkymyst generator) is
"A Python toolbox for building complex digital hardware"
it lets you use python instead of verilog. Quite powerful once you get
used to it.
MiSoC uses migen in order to create a soc. So it implements for examples
interconnect (wishbones, endpoints..) and so on.
Then it becomes a matter of making a SoC wiht a couple of lines.
There is a fork that integrates both migen/misoc called litex that I use
which currently implements a SoC with either m32 or mor1k or picorv32
( https://github.com/enjoy-digital/litex/ )
but adding a cpu is a matter of adding a couple of lines.
If you publish your nanorv32, I could try to get a simulated SoC running
with it, if you use wishbone buses. Could be fun in fact.

Post by Ken Pettit ***@gmail.com [nuttx]
Hi Ramtin,
Yes, I have my RISC-V core based SoC (serial, timers, GPIO) running in
simulation with emulated Serial port connected to Linux minicom using
Verilog / ncsim DPI (Direct Programming Interface) and even simulated JTAG
debugging to OpenOCD (also using DPI). My Verilog simulation opens socket
port 3334 and connects it to the simulated JTAG / TAP port of the
processor. Then I run openocd with remote_bit_bang JTAG driver and connect
to port 3334. Curently from OpenOCD, I am able to read the JTAG IDCODE,
read / write debug registers and debug RAM.
I am now in the process of getting the RISC-V side debug support
implemented (I wrote the debug ROM yesterday, have interrupts working,
etc.). I may actually be less than a week away, but hard to tell. I don't
have a need for Ethernet on my initial design, but that may change with the
2nd generation of our SoC.
Is misoc a MIPS processor? MIPS and RISC-V are similar, but yet different.
Ken
Ken,
Have you managed to get a soc running in an emulated environment ?
Today with misoc, we get a SoC completely emulated with Serial port, and
even ethernet (tun/tap)
That could be nice to get nuttx running this way, so anyone could contribute
What would you think ?

Post by Ken Pettit ***@gmail.com [nuttx]
Hi Ramtin,
Well, PICORV32 is the code base I started with to create NanoRV32. I
added a bunch of stuff to it and that's why it is now Nano instead of
Pico. PICORV32, while nice and small, was a bit too small for what I
needed. The LM32 and MOR1K are really different architectures and wouldn't
belong in an arch/riscv directory, but would have directories of their own.
So based on that, I would say you would either want to use PICORV32 or
NanoRV32 (I could make the source available). It runs on a Digilent
NEXYS-4 board, but could be ported to any board easily. As I mentioned, I
am about 1 or 2 weeks from having GDB source level debugging working with
it (PICORV32 has NO debug support).
Ken
Hi Ken
If I had to go with one of those CPU, which one would you advice me to
LM32: https://github.com/m-labs/lm32/tree/84b3e3ca0ad9535acaef201c
1482342871358b08
M0R1K: https://github.com/openrisc/mor1kx/tree/69b97fcb43b35
d6c6639ecc68e63d912c09ee8da
PICORV32: https://github.com/cliffordwolf/picorv32/tree/e630
bedda4f16d5f061f93879177a2d6b2a66d29

Ken,
You have been busy! I recall talking about this some time back, but I
did not realize that you had made so much progress.
Can we bring onto a branch into the main repository? I appreciate that
you might not be quite ready, but it sounds like now might be the time that
there could be some others willing to work on the port.
I could keep everything on the branch until the logic is pristine.
Greg

[[e-mail] [nuttx]]

I am working with an Xtensa port now which as similar issues. I have the directories set up like:


arch/xtensa/src/common - logic common to all Xtensa architectures
arch/xtensa/src/lx6 - logic unique to the Xtensa LX6 family
arch/xtrensa/src/esp32 - logic unique to the ESP32 implementation of LX6


Sounds like you are following something similar. This will support multiple Xtensa families and multiple implementations of members of each family.


LX6 drivers would go under src/lx6.


This is analogous to STM32, for example, which has


arch/arm/src/common - logic common to all ARM architectures
arch/arm/src/armv7-m- logic unique to the ARMv7-M family
arch/arm/src/stm32- logic unique to the STM32 implementation of ARMv7-M



Ken Pettit is doing an RISC-V port and I imagine he is doing something similar. I like this directory layout because (1) it is the same for all architecutres, and (2) it is proven to give sufficient flexibility.


Greg

[[e-mail] [nuttx]]

Related to directory structure, is file naming...

Post by ***@yahoo.com [nuttx]
arch/xtensa/src/common - logic common to all Xtensa architectures

Under this directory, all files begin with xtrensa_

Note that this is different that some older architectures like ARM which begin with up_. up_, however is the wrong prefix. See http://www.nuttx.org/doku.php?id=wiki:nxinternal:naming.

Post by ***@yahoo.com [nuttx]
arch/xtensa/src/lx6 - logic unique to the Xtensa LX6 family

Files in this directory begin with lx6_

Post by ***@yahoo.com [nuttx]
arch/xtrensa/src/esp32 - logic unique to the ESP32 implementation of X6

Files in directory begin with esp32_

Greg

[Ken Pettit [e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]
Ken Pettit is doing an RISC-V port and I imagine he is doing something
similar. I like this directory layout because (1) it is the same for
all architecutres, and (2) it is proven to give sufficient flexibility.

Yes, and my directory structure is basically the same as described:

arch
risc-v
include
src
common - RISC-V common
nr5m100 - chip specific
rv32im - architecture common

Oh, and I almost have the port working on the FPGA. It loads, executes
to the idle loop and even attempts to do context switches ... just no
tasks to swich to yet. I'm working on nsh_main to come up now.

Ken

Post by ***@yahoo.com [nuttx]
Greg

[Ramtin Amin [e-mail] [nuttx]]

and what are the different element that could triggers a soft interrupt
that does the context switching ? a timer?

Post by ***@yahoo.com [nuttx]
Ken Pettit is doing an RISC-V port and I imagine he is doing something
similar. I like this directory layout because (1) it is the same for all
architecutres, and (2) it is proven to give sufficient flexibility.
arch
risc-v
include
src
common - RISC-V common
nr5m100 - chip specific
rv32im - architecture common
Oh, and I almost have the port working on the FPGA. It loads, executes to
the idle loop and even attempts to do context switches ... just no tasks to
swich to yet. I'm working on nsh_main to come up now.
Ken
Greg

[Ken Pettit [e-mail] [nuttx]]

Hi Ramtin,

The RISC-V Draft Privileged ISA Specification doesn't really specify
anything like a SYSTICK. It defines a Supervisor level real-time 64-bit
counter that never resets, with instructions that the implementation and
software environment must provide a means of triggering timer interrupts
based on this real-time count.

I didn't like this, so in my implementation, I added a
decrement-and-reload SYSTICK timer that can generate an independent
interrupt when the timer reaches zero. This is what I use for context
switching.

Also, the spec identifies an ECALL opcode that is used to trigger a
software interrupt for "OS Environment" services. I use this when the
OS wants to perform a syscall. I just recently added the ecall opcode
to my implementation and am debugging why register $a0 (the argument 1
register) is overwritten with a nonsensical value when ECALL is executed.

Ken

Post by Ramtin Amin ***@gmail.com [nuttx]
and what are the different element that could triggers a soft
interrupt that does the context switching ? a timer?

Post by ***@yahoo.com [nuttx]
Ken Pettit is doing an RISC-V port and I imagine he is doing
something similar. I like this directory layout because (1) it is
the same for all architecutres, and (2) it is proven to give
sufficient flexibility.

arch
risc-v
include
src
common - RISC-V common
nr5m100 - chip specific
rv32im - architecture common
Oh, and I almost have the port working on the FPGA. It loads,
executes to the idle loop and even attempts to do context switches
... just no tasks to swich to yet. I'm working on nsh_main to
come up now.
Ken

Post by ***@yahoo.com [nuttx]
Greg

[Ramtin Amin [e-mail] [nuttx]]

Thanks

So far am trying to compile nuttx for lm32. My arch has almost nothing.
those dependencies are not match so far:
`_exit'
`up_assert'
`up_block_task'
`up_create_stack'
`up_idle'
`up_initialize'
`up_initial_state'
`up_interrupt_context'
`up_irq_restore'
`up_irq_save'
`up_release_pending'
`up_release_stack'
`up_stack_frame'
`up_unblock_task'

Which one of those are mendatory to implement, or in other word, which one
could I escape implementing to get a minimalist thing running ?

Post by Ken Pettit ***@gmail.com [nuttx]
Hi Ramtin,
The RISC-V Draft Privileged ISA Specification doesn't really specify
anything like a SYSTICK. It defines a Supervisor level real-time 64-bit
counter that never resets, with instructions that the implementation and
software environment must provide a means of triggering timer interrupts
based on this real-time count.
I didn't like this, so in my implementation, I added a
decrement-and-reload SYSTICK timer that can generate an independent
interrupt when the timer reaches zero. This is what I use for context
switching.
Also, the spec identifies an ECALL opcode that is used to trigger a
software interrupt for "OS Environment" services. I use this when the OS
wants to perform a syscall. I just recently added the ecall opcode to my
implementation and am debugging why register $a0 (the argument 1 register)
is overwritten with a nonsensical value when ECALL is executed.
Ken
and what are the different element that could triggers a soft interrupt
that does the context switching ? a timer?

Post by ***@yahoo.com [nuttx]
Ken Pettit is doing an RISC-V port and I imagine he is doing something
similar. I like this directory layout because (1) it is the same for all
architecutres, and (2) it is proven to give sufficient flexibility.
arch
risc-v
include
src
common - RISC-V common
nr5m100 - chip specific
rv32im - architecture common
Oh, and I almost have the port working on the FPGA. It loads, executes
to the idle loop and even attempts to do context switches ... just no tasks
to swich to yet. I'm working on nsh_main to come up now.
Ken
Greg

[[e-mail] [nuttx]]

They are all mandatory.

[Michael Smith [e-mail] [nuttx]]

Ramtin,

Context switching in a pre-emptive system normally happens as consequence of:

- Quantum expiry (quantum timer expiry)
- Blocking
- A higher-priority task being made runnable, either by an asynchronous event (interrupt) or synchronous event (e.g. message transmission)

It’s convenient to make all of these look as similar as possible; since they typically all involve the return-from-exception path, that’s the place where I like to do it...

= Mike

and what are the different element that could triggers a soft interrupt that does the context switching ? a timer?

Post by ***@yahoo.com [nuttx]
Ken Pettit is doing an RISC-V port and I imagine he is doing something similar. I like this directory layout because (1) it is the same for all architecutres, and (2) it is proven to give sufficient flexibility.

arch
risc-v
include
src
common - RISC-V common
nr5m100 - chip specific
rv32im - architecture common
Oh, and I almost have the port working on the FPGA. It loads, executes to the idle loop and even attempts to do context switches ... just no tasks to swich to yet. I'm working on nsh_main to come up now.
Ken

Post by ***@yahoo.com [nuttx]
Greg

[Ken Pettit [e-mail] [nuttx]]

Hi Greg,

Ken,
You have been busy! I recall talking about this some time back, but I
did not realize that you had made so much progress.

Well, you know, gotta do somthing with my time! :)

Can we bring onto a branch into the main repository? I appreciate that
you might not be quite ready, but it sounds like now might be the time
that there could be some others willing to work on the port.

Hmm. I would need to at least copy my arch/riscv directory into nuttx
first and get it to compile. Really shouldn't be much effort as I have
used very nearly identical directory structure and names, though with a
few small changes since it really was nanos and not NuttX. Turns out
most of my effort was in getting low-level nr5m100 vectors, ISR and
peripherals implemented. But if I publish my NanoRV32 core, then all of
that code becomes instantly useful to someone (maybe).

Let me think about it for the day ... it was always my plan to get this
stuff incorporated into NuttX and release it, maybe just after it was a
bit more mature.

Ken