Getting started with Vega board in RIOT

Hello, i have just download rios os and i am beginner in it. i am working on vega board which is new 32 bit micro controller , it is based on risc-v architecture. to run application using rios in it do i need to create some files in CPU and Board directory of rios??? what should be my first step? please share your experience with me.

Hello and welcome to RIOT! Great to hear you are planning to add a new MCU family to RIOT, this is always a welcome addition.

You will need to create a folder for the processor, e.g. cpu/thejas32 and one for the board e.g boards/aries-v3. Ideally you can utilize cpu/riscv_common to cover all the RISC-V specific parts and only have clock setup, vendor headers and peripheral drivers in your CPU platform code. The board will then describe how pins are configured and be only declarative.

You can take a look at #16036 for an example of how a RISC-V family was added, this also also touches some generic RISC-V code as not everything was made properly common before, hopefully you don’t need to touch this if everything needed for your CPU is already covered. Unlike with Cortex-M there is no standard interrupt controller on RISC-V, so unless ERVIC is just an extension to an existing interrupt controller, you’ll need a driver for that too.

Best start with CPU bring-up and a UART driver, so you can get some output. That would then already be something you can open a PR for, it’s always good to get feedback early on. Also feel free to ask in the Chat if you need some help.

btw: Is there a proper datasheet other than this brief overview?

1 Like

Hello, first of all thank you for your response and helping me in this problem.

Do i need to create folder in the CPU directory too, i am asking it again because i thought in CPU directory only the architecture related to our board should be specified (in my case RISC-V common) do i need to create more file in it??

thank you for your valuable suggestion, i’ll take it sure.

No mate, proper datasheet is not available right now but it will be available soon.

Do i need to create folder in the CPU directory too, i am asking it again because i thought in CPU directory only the architecture related to our board should be specified (in my case RISC-V common) do i need to create more file in it??

You are not just adding a board with an already supported MCU, but a whole new MCU family. A MCU/SoC consists not only of a CPU (in this case a RISC-V one for which the riscv_common code is used) but also contains peripherals such as timers, UART, SPI, I2C etc. Those are all vendor specific and will require dedicated drivers.

I’m not convinced @saurav96 expected to be porting to a new board!
If they are beginnier, I strongly suggest ey start with a supported board, and run through a few examples first to get eir feet wet.

okay mate, i undr

okay i got your point but configuration of peripherals should be in CPU directory or in Board directory?? this is the point of confusion for me right now. could you please clear my confusion about it.

yeah, i understand your concern, i have only did compilation of code which is of another controller just to understand the basic thing. flashing of code haven’t done yet.

If i work on supported board, on that case i won’t require porting. my main aim is to do porting on my controller. only then i can get my hands on coding part.

1 Like

The CPU directory contains the peripheral drivers, the board directory only contains the configuration for the peripheral drivers (in periph_conf.h), no actual code.

hello bro, I have done the UART configuration part in it, Now printf is working in our microcontroller, now i am able to see some output.

next i wanted to complete the GPIO part, after completing it when i run the blinky led program, my program is not even going into the main program.

the output which i am getting is given below.

*** RIOT kernel panic:

                                    *** halted.

please share your experience with me, I don’t know why i am getting this.

Great success! I’m already looking forward to your PR :smiley:

For the failed assertion you should also get a hex address with that (e.g. abcdef, usually printed on the line above the output you shared) that you can use with the addr2line tool:

addr2line -e bin/aries-v3/blinky.elf abcdef

This shows the location of the failed assertion. Alternatively you can also enable verbose assertions by setting VERBOSE_ASSERT=1 on the build command line. This will include a human readable printout instead of the hex address (which of course requires more ROM space)

1 Like

Thank you very much for your valuable response. :slightly_smiling_face: I couldn’t found the hex address which you have told me. just above of that statement, number was displaying, when i put it into the command which you have mentioned. i was getting nothing.

but the alternative option of VERBOSE_ASSERT=1 is working perfectly fine, that showed me path of assertion. Thank you mate.