[PATCH v2] docs/user: add docs for riscv/kendrytek210 BSP variant

Alan Cudmore alan.cudmore at gmail.com
Sun Apr 2 16:21:51 UTC 2023 

I submitted a v4 patch for the user/bsps/bsps-riscv.rst page.
I improved the instructions for running on Renode by providing a .resc file
that would work, rather than modifying an existing script that was used to
run Linux.

This should work until I have some time to figure out why the
'SetSerialExecution True' keeps ticker from working. Given that defining
CLOCK_DRIVER_USE_ONLY_BOOT_PROCESSOR also works, this seems like a race
condition between RTEMS and renode. I don't notice this on any of the
physical boards I have tested.
I don't understand the implications of telling the clock driver to only use
the boot CPU, so I would prefer to leave that alone for now.

Thanks,
Alan


On Sat, Apr 1, 2023 at 11:05 PM Alan Cudmore <alan.cudmore at gmail.com> wrote:

> Update on K210/ticker on Renode:
> If I define CLOCK_DRIVER_USE_ONLY_BOOT_PROCESSOR in the RISC-V BSP,
>  ticker works on the unmodified .resc file.
> Alan
>
> On Sat, Apr 1, 2023 at 8:17 PM Alan Cudmore <alan.cudmore at gmail.com>
> wrote:
>
>> Hi Hesham,
>> I found a difference between the .resc file I use to run single tests and
>> the .resc file that the renode-test uses.
>> The resc file where ticker.exe fails has this extra statement:
>> $ex='machine SetSerialExecution True'
>> If I comment that out, ticker runs on Renode.
>> I couldn't find that in the documentation, so I'm going to have to search
>> the renode code to see what it does. I'm pretty sure I used to run
>> ticker.exe by itself without commenting out that line.
>> It's odd because a number of other examples work with the statement like
>> smp08.exe, unlimited.exe, hello.exe.
>>
>> For reference, my renode-test setup for the K210 is here:
>> https://github.com/alanc98/k210-rtems-test
>> Note that if you run this, the rki test will fail unless you remove the
>> last test or build an RKI image for the k210:
>> https://github.com/alanc98/rki2/tree/rtems6
>>
>> Alan
>>
>>
>> On Sat, Apr 1, 2023 at 6:13 PM Alan Cudmore <alan.cudmore at gmail.com>
>> wrote:
>>
>>> Interesting - I get the same error when I run ticker on renode now. I
>>> just tried it on a board and it works.
>>> It also still passes the renode-test that I run, which includes ticker
>>> ticker along with a dozen other tests. I'll look into why this does not
>>> work right now.
>>> Thanks,
>>> Alan
>>>
>>>
>>> On Sat, Apr 1, 2023 at 5:32 PM Hesham Almatary <heshamelmatary at gmail.com>
>>> wrote:
>>>
>>>> Thanks Alan! It Looks good to me. I'd appreciate your help with
>>>> running on the simulator. I followed your documentation in this patch,
>>>> but ticker seems to fatal error as follows:
>>>>
>>>> "*** FATAL ***
>>>> fatal source: 6 (RTEMS_FATAL_SOURCE_BSP)
>>>> CPU: 0
>>>> fatal code: 3342 (0x00000d0e)
>>>> RTEMS version: 6.0.0.4021b87e002a094fb0d8ddd099cb8483d6986c8b
>>>> RTEMS tools: 12.2.1 20221121 (RTEMS 6, RSB
>>>> 65f83cf973d6f1f8974ea1818e653753b83eaea8-modified, Newlib b9898fc)
>>>> executing thread ID: 0x09010001
>>>> executing thread name: IDLE"
>>>>
>>>> This is the log from Renode:
>>>>
>>>> 22:28:53.3268 [INFO] Loaded monitor commands from:
>>>> /home/hesham/Downloads/renode_portable/scripts/monitor.py
>>>> 22:28:58.0077 [INFO] Including script:
>>>>
>>>> /home/hesham/Downloads/renode_portable/scripts/single-node/kendryte_k210.resc
>>>> 22:28:58.0181 [INFO] System bus created.
>>>> 22:28:58.8437 [INFO] sysbus: Loading segment of 68760 bytes length at
>>>> 0x80000000.
>>>> 22:28:58.8568 [INFO] sysbus: Loading segment of 4096 bytes length at
>>>> 0x80010C98.
>>>> 22:28:58.8571 [INFO] sysbus: Loading segment of 6217728 bytes length
>>>> at 0x80012000.
>>>> 22:28:58.8783 [INFO] cpu1: Setting PC value to 0x80000000.
>>>> 22:28:58.8793 [INFO] cpu2: Setting PC value to 0x80000000.
>>>> 22:28:58.9003 [INFO] machine-0: Machine started.
>>>> 22:28:58.9704 [WARNING] plic: Unhandled write to offset 0x200000, value
>>>> 0x0.
>>>> 22:28:58.9790 [WARNING] sysbus: [cpu1: 0x80009FE0] (tag:
>>>> 'SYSCTL/clk_sel0') ReadDoubleWord from non existing peripheral at
>>>> 0x50440020, returning 0x00000000.
>>>>
>>>>
>>>> On Sat, 1 Apr 2023 at 21:22, Alan Cudmore <alan.cudmore at gmail.com>
>>>> wrote:
>>>> >
>>>> > Hi Hesham,
>>>> > I applied your suggestions and sent a v3 patch.
>>>> > Thanks for the review,
>>>> > Alan
>>>> >
>>>> >
>>>> > On Sat, Apr 1, 2023 at 1:43 PM Hesham Almatary <
>>>> heshamelmatary at gmail.com> wrote:
>>>> >>
>>>> >> On Fri, 31 Mar 2023 at 17:15, Alan Cudmore <alan.cudmore at gmail.com>
>>>> wrote:
>>>> >> >
>>>> >> > This patch adds the documentation for building and running RTEMS
>>>> on the Kendryte K210
>>>> >> > RISC-V SoC. The generic riscv introducion was re-arranged to list
>>>> the multilib variants
>>>> >> > then the specific hardware targets. In addition a couple of errors
>>>> were fixed for the
>>>> >> > generic QEMU commands.
>>>> >> >
>>>> >> > V2 corrected a typo, expanded K210 Console UART parameters, and
>>>> addded a hyperlink
>>>> >> > to renode.io install instructions.
>>>> >> >
>>>> >> > Closes #4876
>>>> >> > ---
>>>> >> >  user/bsps/bsps-riscv.rst | 116
>>>> ++++++++++++++++++++++++++++++++++-----
>>>> >> >  1 file changed, 103 insertions(+), 13 deletions(-)
>>>> >> >
>>>> >> > diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
>>>> >> > index 41f369f..af79e6e 100644
>>>> >> > --- a/user/bsps/bsps-riscv.rst
>>>> >> > +++ b/user/bsps/bsps-riscv.rst
>>>> >> > @@ -8,7 +8,7 @@ riscv (RISC-V)
>>>> >> >  riscv
>>>> >> >  =====
>>>> >> >
>>>> >> > -This BSP offers 12 variants:
>>>> >> > +**This BSP offers 10 variants, each corresponding to a GCC
>>>> multilib:**
>>>> >> >
>>>> >> We should probably remove the number as it changes and what we have
>>>> in
>>>> >> RTEMS might not be an exact match. i.e., "This BSP corresponds to
>>>> >> multilib variants, with different RISC-V standard extensions" or
>>>> >> something.
>>>> >>
>>>> >> >  * rv32i
>>>> >> >
>>>> >> > @@ -30,23 +30,22 @@ This BSP offers 12 variants:
>>>> >> >
>>>> >> >  * rv64imafdc
>>>> >> >
>>>> >> > -* frdme310arty
>>>> >> > -
>>>> >> > -* mpfs64imafdc
>>>> >> > -
>>>> >> > -Each rv* variant corresponds to a GCC multilib.  A particular
>>>> variant reflects an
>>>> >> > -ISA with ABI and code model choice. All rv64 BSPs have medany
>>>> code model by
>>>> >> > +Each variant reflects an ISA with ABI and code model choice. All
>>>> rv64 BSPs have medany code model by
>>>> >> >  default, while rv32 BSPs are medlow. The reason is that RV32
>>>> medlow can access
>>>> >> >  the entire 32-bit address space, while RV64 medlow can only
>>>> access addresses
>>>> >> >  below 0x80000000. With RV64 medany, it's possible to perform
>>>> accesses above
>>>> >> > -0x80000000.
>>>> >> > +0x80000000. The BSP must be started in machine mode.
>>>> >> > +
>>>> >> > +The reference platform for the rv* variants is the QEMU `virt`
>>>> machine.
>>>> >> > +
>>>> >> QEMU and Spike.
>>>> >>
>>>> >> > +**The BSP also provides the following 3 variants for specific
>>>> hardware targets:**
>>>> >> >
>>>> >> > -The BSP must be started im machine mode.
>>>> >> > +* frdme310arty - The reference platform for this variant is the
>>>> Arty FPGA board with the Sifive Freedom E310 reference design.
>>>> >> >
>>>> >> > -The reference platform for this BSP is the QEMU `virt` machine.
>>>> >> > +* mpfs64imafdc - The reference platform for this variant is the
>>>> Microchip PolarFire SoC Icicle Kit.
>>>> >> > +
>>>> >> > +* kendrytek210 - The reference platform for this variant is the
>>>> Kendryte K210 SoC on the Sipeed MAiX Bit or MAiXDuino board.
>>>> >> >
>>>> >> > -The reference platform for the mpfs64imafdc BSP variant is the
>>>> Microchip
>>>> >> > -PolarFire SoC Icicle Kit.
>>>> >> >
>>>> >> >  Build Configuration Options
>>>> >> >  ---------------------------
>>>> >> > @@ -90,6 +89,9 @@ configuration INI file. The ``waf`` defaults can
>>>> be used to inspect the values.
>>>> >> >       The maximum number of NS16550 devices supported by the
>>>> console driver (2
>>>> >> >       by default).
>>>> >> >
>>>> >> > +``RISCV_ENABLE_SIFIVE_UART_SUPPORT``
>>>> >> > +     Enable the Sifive console UART (disabled by default)
>>>> >> > +
>>>> >> np: SiFive.
>>>> >>
>>>> >> >  ``RISCV_RAM_REGION_BEGIN``
>>>> >> >       The begin of the RAM region for linker command file (default
>>>> is 0x80000000).
>>>> >> >
>>>> >> > @@ -104,6 +106,10 @@ configuration INI file. The ``waf`` defaults
>>>> can be used to inspect the values.
>>>> >> >       Enables support Microchip PolarFire SoC if defined to a
>>>> non-zero
>>>> >> >       value, otherwise it is disabled (disabled by default).
>>>> >> >
>>>> >> > +``RISCV_ENABLE_KENDRYTE_K210_SUPPORT``
>>>> >> > +     Enables support for the Kendtryte K210 SoC if defined to a
>>>> non-zero
>>>> >> > +     value, otherwise it is disabled (disabled by default).
>>>> >> > +
>>>> >> >  ``RISCV_BOOT_HARTID``
>>>> >> >       The boot hartid (processor number) of risc-v cpu by default
>>>> 0.
>>>> >> >
>>>> >> > @@ -131,7 +137,7 @@ The console driver supports devices compatible
>>>> to
>>>> >> >
>>>> >> >  * "ns16750" (see ``RISCV_CONSOLE_MAX_NS16550_DEVICES`` BSP
>>>> option).
>>>> >> >
>>>> >> > -* "sifive,uart0" (see ``RISCV_ENABLE_FRDME310ARTY_SUPPORT`` BSP
>>>> option).
>>>> >> > +* "sifive,uart0" (see ``RISCV_ENABLE_SIFIVE_UART_SUPPORT`` BSP
>>>> option). This console driver is used by the frdme310arty and kendrytek210
>>>> BSP variants.
>>>> >> >
>>>> >> >  They are initialized according to the device tree.  The console
>>>> driver does not
>>>> >> >  configure the pins or peripheral clocks.  The console device is
>>>> selected
>>>> >> > @@ -145,11 +151,13 @@ and spike machines. For instance, to run the
>>>> ``rv64imafdc`` BSP with the
>>>> >> >  following "config.ini" file.
>>>> >> >
>>>> >> >  .. code-block:: none
>>>> >> > +
>>>> >> >      [riscv/rv64imafdc]
>>>> >> >
>>>> >> >  Run the following QEMU command.
>>>> >> >
>>>> >> >  .. code-block:: shell
>>>> >> > +
>>>> >> >      $ qemu-system-riscv64 -M virt -nographic -bios $RTEMS_EXE
>>>> >> >      $ qemu-system-riscv64 -M spike -nographic -bios $RTEMS_EXE
>>>> >> >
>>>> >> > @@ -160,11 +168,13 @@ For instance, to run the ``rv64imafdc`` BSP
>>>> with the following
>>>> >> >  "config.ini" file.
>>>> >> >
>>>> >> >  .. code-block:: none
>>>> >> > +
>>>> >> >      [riscv/rv64imafdc]
>>>> >> >
>>>> >> >  Run the following Spike command.
>>>> >> >
>>>> >> >  .. code-block:: shell
>>>> >> > +
>>>> >> >      $ spike --isa=rv64imafdc $RTEMS_EXE
>>>> >> >
>>>> >> >  Unlike QEMU, Spike supports enabling/disabling a subset of the
>>>> imafdc extensions
>>>> >> > @@ -277,6 +287,86 @@ Serial terminal UART1 displays the SMP
>>>> example messages
>>>> >> >
>>>> >> >      *** END OF TEST SMP 1 ***
>>>> >> >
>>>> >> > +Kendryte K210
>>>> >> > +-------------
>>>> >> > +
>>>> >> > +The Kendryte K210 SoC is a dual core 64-bit RISC-V SoC with an AI
>>>> NPU,
>>>> >> > +built in SRAM, and a variety of peripherals. Currently just the
>>>> console UART, interrupt controller, and timer are supported.
>>>> >> > +
>>>> >> > +The device tree blob is embedded in the ``kendrytek210`` BSP
>>>> variant by default.
>>>> >> > +When the kendrytek210 BSP variant is selected,
>>>> ``BSP_DTB_IS_SUPPORTED`` enabled and the DTB header path
>>>> >> > +``BSP_DTB_HEADER_PATH`` is set to bsp/kendryte-k210-dtb.h.
>>>> >> > +
>>>> >> > +The ``kendrytek210`` BSP variant has been tested on the following
>>>> simulator and boards:
>>>> >> > +
>>>> >> > +* Renode.io simulator using the Kendrtye k210 model
>>>> >> > +* Sipeed MAix BiT board
>>>> >> > +* Sipeed MaixDuino board
>>>> >> > +
>>>> >> > +**Building the Kendryte K210 BSP**
>>>> >> > +
>>>> >> > +Configuration file ``config.ini``:
>>>> >> > +
>>>> >> > +.. code-block:: none
>>>> >> > +
>>>> >> > +    [riscv/kendrytek210]
>>>> >> > +    RTEMS_SMP = True
>>>> >> > +
>>>> >> > +Build RTEMS:
>>>> >> > +
>>>> >> > +.. code-block:: shell
>>>> >> > +
>>>> >> > +    $ ./waf configure --prefix=$HOME/rtems-start/rtems/6
>>>> >> > +    $ ./waf
>>>> >> > +
>>>> >> > +**Flash an executable to the Sipeed MAix BiT or MAixDuino board**
>>>> >> > +
>>>> >> > +Binary images can be flashed to the Sipeed boards through the USB
>>>> port using the kflash.py utility available from the python pip utility.
>>>> >> > +
>>>> >> > +.. code-block:: shell
>>>> >> > +
>>>> >> > +    $ riscv-rtems6-objcopy -Obinary ticker.exe ticker.bin
>>>> >> > +    $ kflash.py --uart /dev/ttyUSB0 ticker.bin
>>>> >> > +
>>>> >> > +After the image is flashed, the RTEMS image will automatically
>>>> boot. It will also run when the board is reset or powered through the USB
>>>> cable. The USB port provides the power and console UART. Plug the USB cable
>>>> into a host PC and bring up a terminal emulator at 115200 baud, 8 data
>>>> bits, 1 stop bit, no parity, and no flow control. On Linux the UART device
>>>> is often ``/dev/ttyUSB0``.
>>>> >> > +
>>>> >> > +**Run a RTEMS application on the Renode.io simulator**
>>>> >> > +
>>>> >> > +RTEMS executables compiled with the kendrytek210 BSP can run on
>>>> the renode.io simulator using the built-in K210 model. The simulator
>>>> currently supports the console UART, interrupt controller, and timer.
>>>> >> > +
>>>> >> > +To install renode.io please refer to the `installation
>>>> instructions <https://github.com/renode/renode#installation>`_. Once
>>>> installed make a local copy of the ``kendryte_k210.resc`` script from the
>>>> ``renode/scripts/single-node`` directory to a local directory where it can
>>>> be edited. Edit the script and change the line that loads the Linux image
>>>> to load a RTEMS elf image instead. The default extension for the RTEMS
>>>> sample ELF images is ``.exe``.
>>>> >> > +
>>>> >> > +Change this line in the kendryte_k210.resc file:
>>>> >> > +
>>>> >> > +.. code-block:: shell
>>>> >> > +
>>>> >> > +    sysbus LoadELF @
>>>> https://dl.antmicro.com/projects/renode/kendryte-k210--vmlinux-s_2206416-2c1f2b2c2f2fc0c48a7b12a3f3c65809b81f452e
>>>> >> > +
>>>> >> > +To this:
>>>> >> > +
>>>> >> > +.. code-block:: shell
>>>> >> > +
>>>> >> > +    sysbus LoadELF @ticker.exe
>>>> >> > +
>>>> >> > +After editing the script, start renode and load the
>>>> kendryte_k210.resc script to start the emulation.
>>>> >> > +
>>>> >> > +.. code-block:: shell
>>>> >> > +
>>>> >> > +    (monitor) s @kendryte_k210.resc
>>>> >> > +
>>>> >> > +You should see a renode UART window and the RTEMS ticker example
>>>> output.
>>>> >> > +
>>>> >> > +
>>>> >> > +**Generating the Device Tree Header**
>>>> >> > +
>>>> >> > +The kendrytek210 BSP uses a built in device tree blob. If
>>>> additional peripheral support is added to the BSP, the device tree may need
>>>> to be updated. After editing the device tree source, compile it to a device
>>>> tree blob with the following command:
>>>> >> > +
>>>> >> > +.. code-block:: shell
>>>> >> > +
>>>> >> > +    $ dtc -O dtb -b 0 -o kendryte-k210.dtb kendryte-k210.dts
>>>> >> > +
>>>> >> > +The dtb file can then be converted to a C array using the
>>>> rtems-bin2c tool. The data for the device tree binary can then replace the
>>>> existing device tree binary data in the ``kendryte-k210-dtb.h`` header file.
>>>> >> > +
>>>> >> >  noel
>>>> >> >  ====
>>>> >> >
>>>> >> > --
>>>> >> > 2.25.1
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > devel mailing list
>>>> >> > devel at rtems.org
>>>> >> > http://lists.rtems.org/mailman/listinfo/devel
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Regards,
>>>> >> Hesham
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Hesham
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230402/4989666f/attachment-0001.htm>

More information about the devel mailing list