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.cudm...@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.cudm...@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.cudm...@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.cudm...@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 <heshamelmat...@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.cudm...@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 >>>>> > <heshamelmat...@gmail.com> wrote: >>>>> >> >>>>> >> On Fri, 31 Mar 2023 at 17:15, Alan Cudmore <alan.cudm...@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@rtems.org >>>>> >> > http://lists.rtems.org/mailman/listinfo/devel >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Regards, >>>>> >> Hesham >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Hesham -- Regards, Hesham _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
