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

Hesham Almatary heshamelmatary at gmail.com
Sun Apr 2 19:55:31 UTC 2023 

Thanks Alan for investigating this issue and following up with the
updates. It's fine to leave it for now, perhaps even report it to
Renode if we think it's a problem with their simulator or something.


On Sun, 2 Apr 2023 at 17:22, Alan Cudmore <alan.cudmore at gmail.com> wrote:
>
> 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



-- 
Regards,
Hesham

More information about the devel mailing list