Re: Building leon3 prom image for testing on renode

[Alan Cudmore]

Hi Mazaya,

On Tue, Jul 18, 2023 at 8:35 PM Muhammad Sulthan Mazaya <
msulthanmaz...@gmail.com> wrote:

> Hi Alan,
>
> > Also, as you mentioned, the renode Zephyr example runs directly from RAM
> without a prom image. Is it that the RTEMS LEON3 BSP relies on
> initialization done by the boot prom (GRMON or MKPROM2 based boot code)?
>
> Do you or anyone on the devel mailing list know where/how can I check
> which kind of initialization rtems leon3 bsp rely on? Sorry, I am fairly
> new to this
>
> The prom image source code is pretty simple, but it would take a little
bit of time (for me at least) to decode since it is in SPARC assembly
language:
The code:
https://github.com/TUT-ASI/leon3-grlib-gpl-mirror/blob/master/software/leon3/prom.S
And the prom.h header they use for the renode prom image:
https://github.com/antmicro/renode-rtems-leon3/blob/main/prom.h

Essentially, it is setting up the processor including the stack pointer,
and minimal configuration (AMBA Plug and play?). The idea would be to
translate what the prom.S assembly program is doing into a set of .resc
statements to program configuration registers and set up anything that
RTEMS may need to run. It may be a subset of everything that the assembly
code does - It may come down to just one or two statements. I'm not being
specific with the steps, because I'm not sure myself.. I would have to take
some time to figure out exactly what it's doing.

Here is an example for the K210 where some of the peripheral registers are
programmed in the renode resc script:
https://github.com/renode/renode/blob/master/scripts/single-node/kendryte_k210.resc#L10

Replacing the prom with resc statements is one way to solve the problem -
by understanding the assembly and the memory mapped registers that are
being programmed. The other way to solve the problem is by figuring out the
way to supply the prom.bin file to users that need to run RTEMS/LEON3
binaries on renode. One is an embedded programming problem and the other is
an automation problem. I think both are valid solutions.

Regards,
Alan



> Thank you,
> Mazaya
>
> On Tue, Jul 18, 2023 at 11:27 PM Alan Cudmore 
> wrote:
>
>> Hi Mazaya,
>> I wonder if it is possible to initialize the processor to the state where
>> it can run the RTEMS image in RAM without using the prom image? The
>> processor initialization would have to go in the resc script before the
>> image is loaded and started.
>> Also, as you mentioned, the renode Zephyr example runs directly from RAM
>> without a prom image. Is it that the RTEMS LEON3 BSP relies on
>> initialization done by the boot prom (GRMON or MKPROM2 based boot code)?
>>
>> https://github.com/renode/renode/blob/master/scripts/single-node/leon3_zephyr.resc
>>
>> I guess it ends up being a trade off of tooling vs. trying to program the
>> necessary initialization in the resc script.
>>
>> Regards,
>> Alan
>>
>> On Tue, Jul 18, 2023 at 2:46 AM Muhammad Sulthan Mazaya <
>> msulthanmaz...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I was trying to implement renode for testing leon3 using rtems-test. I
>>> noticed that from the example they provide
>>> https://github.com/antmicro/renode-rtems-leon3/blob/main/leon3_rtems.resc,
>>> it seems like the renode simulator needs the prom image of leon3 to do so.
>>> I don't think an additional build step before testing a particular bsp is
>>> something supported by the build config of rtems-tools + my mentors
>>> also said it shouldn't be on the rtems-tools. Is it okay to have RSB build
>>> that for us as part of the BSP?
>>>
>>> Thank you,
>>> Mazaya
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Building leon3 prom image for testing on renode

[Alan Cudmore]

Hi Mazaya,
I wonder if it is possible to initialize the processor to the state where
it can run the RTEMS image in RAM without using the prom image? The
processor initialization would have to go in the resc script before the
image is loaded and started.
Also, as you mentioned, the renode Zephyr example runs directly from RAM
without a prom image. Is it that the RTEMS LEON3 BSP relies on
initialization done by the boot prom (GRMON or MKPROM2 based boot code)?
https://github.com/renode/renode/blob/master/scripts/single-node/leon3_zephyr.resc

I guess it ends up being a trade off of tooling vs. trying to program the
necessary initialization in the resc script.

Regards,
Alan

On Tue, Jul 18, 2023 at 2:46 AM Muhammad Sulthan Mazaya <
msulthanmaz...@gmail.com> wrote:

> Hi,
>
> I was trying to implement renode for testing leon3 using rtems-test. I
> noticed that from the example they provide
> https://github.com/antmicro/renode-rtems-leon3/blob/main/leon3_rtems.resc,
> it seems like the renode simulator needs the prom image of leon3 to do so.
> I don't think an additional build step before testing a particular bsp is
> something supported by the build config of rtems-tools + my mentors also
> said it shouldn't be on the rtems-tools. Is it okay to have RSB build that
> for us as part of the BSP?
>
> Thank you,
> Mazaya
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS-libbsd freebsd-org submodule would require update in order to import genet drivers. Suggestions?

[Alan Cudmore]

Hi Noor,
If you have not done so already, would it be worth trying to build and
initialize the current libbsd with a loopback driver?
Are there other devices on the RPI4 such as the SD card or USB that may be
usable in the current libbsd on the Pi 4?
I know it will not get you the ethernet driver you need, but having an
environment that runs on the board might be a step in the right direction.

How hard do you think it would be to backport the ethernet driver to the
current rtems-libbsd release?
Alan



On Sun, Jun 4, 2023 at 11:45 AM Noor Aman  wrote:

> Ping, I still require some assistance.
>
> Else I'll go by with Kinsey's suggestion as follows:
>
>> If it turns out we can't trivially bring things up to current, you may
>> need to import the current updated driver from freebsd master into rtemsbsd
>> and maintain it out of tree.
>
>
> Thanks
>
>
> On Thu, 1 Jun 2023 at 23:46, Noor Aman  wrote:
>
>> Hello,
>> Currently freebsd-org submodule is currently checked out at hash-ID
>> 5d85e12 dated September 24, 2019 in master rtems-libbsd branch. In order to
>> import genet drivers, I need to at least get commit from april 2020.
>> Specifically this one https://reviews.freebsd.org/D24436
>>
>> In terms of freebsd release numbers, I need freebsd 13.x candidate in
>> order to import genet drivers. There are no drivers for it in freebsd 12.x.
>>
>> From what I have read in the documentation, the working directory needs
>> to be clean in order to start importing process, but i'm unable to do so
>> when switching to main or master branch. What should I do? Any suggestions?
>>
>> Thank you,
>>
>
>
> --
> Mohd Noor Aman
> Tinkering with Hardware
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rtems.org websites https not working?

[Alan Cudmore]

Hi,
When I try to go to docs.rtems.org, www.rtems.org, or git.rtems.org, I get
an error from my browser: ERR:CERT_DATE_INVALID.
Just wanted to see if anyone else noticed this.
Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Alan Cudmore]

Looks good - I generated the HTML and PDF versions.
Thanks,
Alan

On Tue, Apr 11, 2023 at 5:05 PM Joel Sherrill  wrote:

> Sorry. I didn't realise there were that many revisions and when I searched
> my inbox I missed it
>
> I reverted V2 and applied V6. Hopefully ok now
>
> On Tue, Apr 11, 2023, 2:54 PM Alan Cudmore  wrote:
>
>> Sorry, meant to reply to the list too.. I think you pushed v2 of my
>> patch. I was up to v6 that fixed a bunch of issues.
>> What is the best way to fix this? Rewind, or I can submit a new patch
>> based on this.
>> Thanks, Alan
>>
>> On Tue, Apr 11, 2023, 2:29 PM Joel Sherrill  wrote:
>>
>>> Pushed. Thanks.
>>>
>>> Please check that it looks good to you.
>>>
>>> --joel
>>>
>>> On Fri, Mar 31, 2023 at 11:15 AM Alan Cudmore 
>>> 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:**
>>>>
>>>>  * 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 0x8000. With RV64 medany, it's possible to perform accesses
>>>> above
>>>> -0x8000.
>>>> +0x8000. The BSP must be started in machine mode.
>>>> +
>>>> +The reference platform for the rv* variants is the QEMU `virt` machine.
>>>> +
>>>> +**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)
>>>> +
>>>>  ``RISCV_RAM_REGIO

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

[Alan Cudmore]

Sorry, meant to reply to the list too.. I think you pushed v2 of my patch.
I was up to v6 that fixed a bunch of issues.
What is the best way to fix this? Rewind, or I can submit a new patch based
on this.
Thanks, Alan

On Tue, Apr 11, 2023, 2:29 PM Joel Sherrill  wrote:

> Pushed. Thanks.
>
> Please check that it looks good to you.
>
> --joel
>
> On Fri, Mar 31, 2023 at 11:15 AM Alan Cudmore 
> 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:**
>>
>>  * 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 0x8000. With RV64 medany, it's possible to perform accesses
>> above
>> -0x8000.
>> +0x8000. The BSP must be started in machine mode.
>> +
>> +The reference platform for the rv* variants is the QEMU `virt` machine.
>> +
>> +**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)
>> +
>>  ``RISCV_RAM_REGION_BEGIN``
>>   The begin of the RAM region for linker command file (default is
>> 0x8000).
>>
>> @@ -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 B

Ping for docs/user risc-v doc update

[Alan Cudmore]

I think it's in pretty good shape:
https://lists.rtems.org/pipermail/devel/2023-April/074845.html
I did not wrap the existing console sections, but I used line wrap to
format the other paragraphs to be 80 chars or less. I also updated the
hardcoded RTEMS versions to use macros.
Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Alan Cudmore]

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.

V3 clarified the multilib variant description, clarified the multilib variant 
reference platform, and
corrected capitalization on SiFive.

V4 improves the instructions for running the K210 BSP on the Renode.io 
simulator.

V5 cleaned up the text to be no more than 80 characters per line.

V6 applied word wrap to paragraphs and replaced hard coded RTEMS major versions 
with macros.

Closes #4876
---
 user/bsps/bsps-riscv.rst | 240 ++-
 1 file changed, 188 insertions(+), 52 deletions(-)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
index 41f369f..b4bdf7b 100644
--- a/user/bsps/bsps-riscv.rst
+++ b/user/bsps/bsps-riscv.rst
@@ -8,7 +8,8 @@ riscv (RISC-V)
 riscv
 =
 
-This BSP offers 12 variants:
+**Each variant in this first group corresponds to a GCC multilib option with
+different RISC-V standard extensions.**
 
 * rv32i
 
@@ -30,23 +31,26 @@ This BSP offers 12 variants:
 
 * rv64imafdc
 
-* frdme310arty
+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 0x8000. With RV64 medany, it's possible to
+perform accesses above 0x8000. The BSP must be started in machine mode.
 
-* mpfs64imafdc
+The reference platforms for the rv* variants include the QEMU `virt` and
+`spike` machines and the Spike RISC-V ISA simulator.
 
-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
-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 0x8000. With RV64 medany, it's possible to perform accesses above
-0x8000.
+**The BSP also provides the following 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
 ---
@@ -77,33 +81,41 @@ configuration INI file. The ``waf`` defaults can be used to 
inspect the values.
 The path to the header file containing the device tree blob.
 
 ``BSP_CONSOLE_BAUD``
-The default baud for console driver devices (default 115200).
+The default baud for console driver devices (default is 115200).
 
 ``RISCV_MAXIMUM_EXTERNAL_INTERRUPTS``
  The maximum number of external interrupts supported by the BSP (default
- 64).
+ is 64).
 
 ``RISCV_ENABLE_HTIF_SUPPORT``
  Enable the Host/Target Interface (HTIF) support (enabled by default).
 
 ``RISCV_CONSOLE_MAX_NS16550_DEVICES``
- The maximum number of NS16550 devices supported by the console driver (2
- by default).
+ The maximum number of NS16550 devices supported by the console driver
+ (default is 2).
+
+``RISCV_ENABLE_SIFIVE_UART_SUPPORT``
+ Enable the SiFive console UART (disabled by default).
 
 ``RISCV_RAM_REGION_BEGIN``
- The begin of the RAM region for linker command file (default is 
0x8000).
+ The begin of the RAM region for linker command file
+ (default is 0x8000).
 
 ``RISCV_RAM_REGION_SIZE``
  The size of the RAM region for linker command file (default 64MiB).
 
 ``RISCV_ENABLE_FRDME310ARTY_SUPPORT``
  Enables support sifive Freedom E310 Arty board if defined to a non-zero
- value,otherwise it is disabled (disabled by default)
+ value,otherwise it is disabled (disabled by default).
 
 ``RISCV_ENABLE_MPFS_SUPPORT``
  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.
 
@@ -123,15 +135,15 @@ The clock driver uses th

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

[Alan Cudmore]

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  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 
> 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 
>> 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 
>>> 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 (0x0d0e)
>>>> 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
>>>> 0x8000.
>>>> 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 0x8000.
>>>> 22:28:58.8793 [INFO] cpu2: Setting PC value to 0x8000.
>>>> 22:28:58.9003 [INFO] machine-0: Machine started.
>>>> 22:28:58.9704 [WARNING] plic: Unhandled write to offset 0x20, value
>>>> 0x0.
>>>> 22:28:58.9790 [WARNING] sysbus: [cpu1: 0x80009FE0] (tag:
>>>> 'SYSCTL/clk_sel0') ReadDoubleWord from non existing peripheral at
>>>> 0x50440020, returning 0x.
>>>>
>>>>
>>>> On Sat, 1 Apr 2023 at 21:22, Alan Cudmore 
>>>> wrote:
>>>> >
>>>> > Hi Hesham,
>>>> > I applied your suggestions and sent a v3 patch.
>>>> > Th

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

[Alan Cudmore]

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.

V3 clarified the multilib variant description, clarified the multilib variant 
reference platform, and
corrected capitalization on SiFive.

V4 improves the instructions for running the K210 BSP on the Renode.io 
simulator.

Closes #4876
---
 user/bsps/bsps-riscv.rst | 136 +++
 1 file changed, 123 insertions(+), 13 deletions(-)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
index 41f369f..8a27d62 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:
+**Each variant in this first group corresponds to a GCC multilib option with 
different RISC-V standard extensions.**
 
 * 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 0x8000. With RV64 medany, it's possible to perform accesses above
-0x8000.
+0x8000. The BSP must be started in machine mode.
+
+The reference platforms for the rv* variants include the QEMU `virt` and 
`spike` machines and the Spike RISC-V ISA simulator.
+
+**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)
+
 ``RISCV_RAM_REGION_BEGIN``
  The begin of the RAM region for linker command file (default is 
0x8000).
 
@@ -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,106 @@ Serial terminal UART1 displays the SMP example messages
 
 *** END OF TEST SMP 1 ***
 
+Kendryte K210
+-
+
+The Kendryte K210 SoC is a dual core 

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

[Alan Cudmore]

Hi Chris,
Sorry I should have read that and formatted my changes correctly. I
submitted a v5 patch, but as I sent it, I realized that there are a couple
of places where the RTEMS version macro can be embedded rather than
hard-coding "6". I should have taken more time and avoided flooding the
mailing list with extra traffic. - But I'm much better at this process now
:)
Later today, I'll send a v6 patch with the rtems version macros.

Thanks,
Alan


On Sun, Apr 2, 2023 at 10:14 PM Chris Johns  wrote:

> Hi Alan,
>
> We have a standard for the documentation source:
>
>  https://git.rtems.org/rtems-docs/tree/README.txt#n469
>
> Please note the line length. That can be relaxed when pasting in output
> but we
> need the written text to be within the bounds.
>
> Thanks
> Chris
>
> On 1/4/2023 3:15 am, Alan Cudmore 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:**
> >
> >  * 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 0x8000. With RV64 medany, it's possible to perform accesses
> above
> > -0x8000.
> > +0x8000. The BSP must be started in machine mode.
> > +
> > +The reference platform for the rv* variants is the QEMU `virt` machine.
> > +
> > +**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)
> > +
> >  ``RISCV_RAM_REGION_BEGIN``
> >   The begin of the RAM region for linker command file (default is
> 0x8000).
> >
> > @@ -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.

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

[Alan Cudmore]

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.

V3 clarified the multilib variant description, clarified the multilib variant 
reference platform, and
corrected capitalization on SiFive.

V4 improves the instructions for running the K210 BSP on the Renode.io 
simulator.

V5 cleaned up the text to be no more than 80 characters per line.

Closes #4876
---
 user/bsps/bsps-riscv.rst | 182 ++-
 1 file changed, 159 insertions(+), 23 deletions(-)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
index 41f369f..aac2f7c 100644
--- a/user/bsps/bsps-riscv.rst
+++ b/user/bsps/bsps-riscv.rst
@@ -8,7 +8,8 @@ riscv (RISC-V)
 riscv
 =
 
-This BSP offers 12 variants:
+**Each variant in this first group corresponds to a GCC multilib option with
+different RISC-V standard extensions.**
 
 * rv32i
 
@@ -30,23 +31,26 @@ This BSP offers 12 variants:
 
 * rv64imafdc
 
-* frdme310arty
+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 0x8000. With RV64 medany, it's possible to
+perform accesses above 0x8000. The BSP must be started in machine mode.
 
-* mpfs64imafdc
+The reference platforms for the rv* variants include the QEMU `virt` and 
`spike`
+machines and the Spike RISC-V ISA simulator.
 
-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
-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 0x8000. With RV64 medany, it's possible to perform accesses above
-0x8000.
+**The BSP also provides the following 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
 ---
@@ -77,33 +81,41 @@ configuration INI file. The ``waf`` defaults can be used to 
inspect the values.
 The path to the header file containing the device tree blob.
 
 ``BSP_CONSOLE_BAUD``
-The default baud for console driver devices (default 115200).
+The default baud for console driver devices (default is 115200).
 
 ``RISCV_MAXIMUM_EXTERNAL_INTERRUPTS``
  The maximum number of external interrupts supported by the BSP (default
- 64).
+ is 64).
 
 ``RISCV_ENABLE_HTIF_SUPPORT``
  Enable the Host/Target Interface (HTIF) support (enabled by default).
 
 ``RISCV_CONSOLE_MAX_NS16550_DEVICES``
- The maximum number of NS16550 devices supported by the console driver (2
- by default).
+ The maximum number of NS16550 devices supported by the console driver
+ (default is 2).
+
+``RISCV_ENABLE_SIFIVE_UART_SUPPORT``
+ Enable the SiFive console UART (disabled by default).
 
 ``RISCV_RAM_REGION_BEGIN``
- The begin of the RAM region for linker command file (default is 
0x8000).
+ The begin of the RAM region for linker command file
+ (default is 0x8000).
 
 ``RISCV_RAM_REGION_SIZE``
  The size of the RAM region for linker command file (default 64MiB).
 
 ``RISCV_ENABLE_FRDME310ARTY_SUPPORT``
  Enables support sifive Freedom E310 Arty board if defined to a non-zero
- value,otherwise it is disabled (disabled by default)
+ value,otherwise it is disabled (disabled by default).
 
 ``RISCV_ENABLE_MPFS_SUPPORT``
  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.
 
@@ -123,15 +135,15 @@ The clock driver uses the CLINT timer.
 Console Driver
 --
 
-The console driver supports devices compatib

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

[Alan Cudmore]

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  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 
> 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 
>> 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 (0x0d0e)
>>> 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
>>> 0x8000.
>>> 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 0x8000.
>>> 22:28:58.8793 [INFO] cpu2: Setting PC value to 0x8000.
>>> 22:28:58.9003 [INFO] machine-0: Machine started.
>>> 22:28:58.9704 [WARNING] plic: Unhandled write to offset 0x20, value
>>> 0x0.
>>> 22:28:58.9790 [WARNING] sysbus: [cpu1: 0x80009FE0] (tag:
>>> 'SYSCTL/clk_sel0') ReadDoubleWord from non existing peripheral at
>>> 0x50440020, returning 0x.
>>>
>>>
>>> On Sat, 1 Apr 2023 at 21:22, Alan Cudmore 
>>> 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 
>>> 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
>>> >> > ---
>>>

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

[Alan Cudmore]

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  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 
> 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 (0x0d0e)
>> 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
>> 0x8000.
>> 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 0x8000.
>> 22:28:58.8793 [INFO] cpu2: Setting PC value to 0x8000.
>> 22:28:58.9003 [INFO] machine-0: Machine started.
>> 22:28:58.9704 [WARNING] plic: Unhandled write to offset 0x20, value
>> 0x0.
>> 22:28:58.9790 [WARNING] sysbus: [cpu1: 0x80009FE0] (tag:
>> 'SYSCTL/clk_sel0') ReadDoubleWord from non existing peripheral at
>> 0x50440020, returning 0x.
>>
>>
>> On Sat, 1 Apr 2023 at 21:22, Alan Cudmore  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 
>> 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 va

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

[Alan Cudmore]

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 
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 (0x0d0e)
> 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
> 0x8000.
> 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 0x8000.
> 22:28:58.8793 [INFO] cpu2: Setting PC value to 0x8000.
> 22:28:58.9003 [INFO] machine-0: Machine started.
> 22:28:58.9704 [WARNING] plic: Unhandled write to offset 0x20, value
> 0x0.
> 22:28:58.9790 [WARNING] sysbus: [cpu1: 0x80009FE0] (tag:
> 'SYSCTL/clk_sel0') ReadDoubleWord from non existing peripheral at
> 0x50440020, returning 0x.
>
>
> On Sat, 1 Apr 2023 at 21:22, Alan Cudmore  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 
> wrote:
> >>
> >> On Fri, 31 Mar 2023 at 17:15, Alan Cudmore 
> 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 0x8000. With RV64 medany, it's possible to perform
> accesses above
> >> > -0x8000.
>

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

[Alan Cudmore]

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 
wrote:

> On Fri, 31 Mar 2023 at 17:15, Alan Cudmore  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 0x8000. With RV64 medany, it's possible to perform accesses
> above
> > -0x8000.
> > +0x8000. 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
> 0x8000).
> >
> > @@ -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 opti

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

[Alan Cudmore]

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.

V3 clarified the multilib variant description, clarified the multilib variant 
reference
platform, and corrected capitalization on SiFive.

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..ffa6c09 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:
+**Each variant in this first group corresponds to a GCC multilib option with 
different RISC-V standard extensions.**
 
 * 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 0x8000. With RV64 medany, it's possible to perform accesses above
-0x8000.
+0x8000. The BSP must be started in machine mode.
+
+The reference platforms for the rv* variants include the QEMU `virt` and 
`spike` machines and the Spike RISC-V ISA simulator.
+
+**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)
+
 ``RISCV_RAM_REGION_BEGIN``
  The begin of the RAM region for linker command file (default is 
0x8000).
 
@@ -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. Curre

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

[Alan Cudmore]

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:**
 
 * 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 0x8000. With RV64 medany, it's possible to perform accesses above
-0x8000.
+0x8000. The BSP must be started in machine mode.
+
+The reference platform for the rv* variants is the QEMU `virt` machine.
+
+**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)
+
 ``RISCV_RAM_REGION_BEGIN``
  The begin of the RAM region for linker command file (default is 
0x8000).
 
@@ -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

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

[Alan Cudmore]

Hi Padmarao,
Thanks for reviewing the changes. I agree with your suggestions and will
send out a V2 patch soon.
Thanks,
Alan

On Thu, Mar 30, 2023 at 11:28 AM  wrote:

> Hi Alan,
>
> > On Wed, 2023-03-29 at 10:32 -0400, Alan Cudmore 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.
> >
> > Closes #4876
> > ---
> >  user/bsps/bsps-riscv.rst | 105 ++---
> > --
> >  1 file changed, 92 insertions(+), 13 deletions(-)
> >
> > diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
> > index 41f369f..14055d0 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:**
> >
> >  * 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 0x8000. With RV64 medany, it's possible to perform
> > accesses above
> > -0x8000.
> > +0x8000. The BSP must be started im machine mode.
> I think, it is "in machine mode" not "im"
> > +
> > +The reference platform for the rv* variants is the QEMU `virt`
> > machine.
> > +
> > +**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)
> > +
> >  ``RISCV_RAM_REGION_BEGIN``
> >   The begin of the RAM region for linker command file (default is
> > 0x8000).
> >
> > @@ -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
> 

RISC-V users guide update

[Alan Cudmore]

Hi Hesham and Padmarao (and anyone else that is interested in RISC-V BSPS..
)
I would like your opinion on the documentation update I submitted for the
RISC-V BSPs.
I added support for the K210 BSP variant, but I also re-arranged the
variants into two lists:
  - The multilib variants
  - Target specific variants which now include the FRDME310ARTY, MPFS, and
K210. I thought it would be less confusing to show that there are a class
of multilib variants for the simulators, then a growing list of BSP
variants for specific hardware targets.
I also fixed the QEMU run commands that were not showing up in the rendered
doc.

https://lists.rtems.org/pipermail/devel/2023-March/074798.html

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Alan Cudmore]

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.

Closes #4876
---
 user/bsps/bsps-riscv.rst | 105 ++-
 1 file changed, 92 insertions(+), 13 deletions(-)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
index 41f369f..14055d0 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:**
 
 * 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 0x8000. With RV64 medany, it's possible to perform accesses above
-0x8000.
+0x8000. The BSP must be started im machine mode.
+
+The reference platform for the rv* variants is the QEMU `virt` machine.
+
+**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)
+
 ``RISCV_RAM_REGION_BEGIN``
  The begin of the RAM region for linker command file (default is 
0x8000).
 
@@ -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,75 @@ 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

Re: Call for Mentors gsoc'23

[Alan Cudmore]

Hi Gedare,
I accepted the agreements. I would like to be a secondary mentor again this
year. I'm interested in both RPI and RISC-V based projects.
Thanks,
Alan


On Tue, Mar 7, 2023 at 9:43 PM Gedare Bloom  wrote:

> Hello all,
>
> RTEMS Project is again to participate in GSoC (2023). If you would
> like to be a primary or secondary mentor, please register at
> https://summerofcode.withgoogle.com/ for the current program year, and
> then let me know so that I can add you to RTEMS Project. The workflow
> is a bit different this year, as I cannot add/invite individuals until
> they have set up their profile and agreed to the terms and conditions
> for the current year's program.
>
> If you have ideas for small/large projects, feel free to add them as
> tickets, as explained on our ideas page:
> https://devel.rtems.org/wiki/Developer/OpenProjects
>
> There have already been a few potential new contributors on the
> Discord and mailing list.
>
> Thanks,
> Gedare
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 0/3] bsps/riscv: Add kendrytek210 riscv BSP variant

[Alan Cudmore]

Thanks for the test! I'm working on setting up the Polarfire HSS software
so I can try running on the icicle kit emulation on renode.io.

FYI: If anyone is interested in a very inexpensive RISC-V board, the
Pine64.org Ox64 boards are back in stock:
https://pine64.com/product-category/ox64/
These might make an interesting RTEMS target, since the SoC has 64Mbytes of
PSRAM and can run Linux.

Alan


On Fri, Mar 17, 2023 at 7:41 AM  wrote:

>
> I have tested it on the renode.io simulator and working fine.
>
> Regards
> Padmarao
> > On Wed, 2023-03-15 at 22:04 -0400, Alan Cudmore wrote:
> >
> > Version 2 patch updates: Separated the device tree source and encoded
> > device tree blob into a separate patch, added the license text to
> > k210.h, eliminated whitespace warnings, and eliminated dead code in
> > the conditional compilation structure for the core_get_frequency
> > function in start/bspstart.c.
> >
> > This patch set adds the riscv/kendrytek210 BSP variant to support the
> > Kendryte K210 Dual Core RISC-V SoC. The BSP runs on the renode.io
> > simulator, the Sipeed MAiX BiT and MAiXDuino boards, and would likely
> > run on other boards. RTEMS binaries can be flashed to the boards
> > using
> > the kflash python utility available through the pip command.
> > Currently
> > the BSP supports the console UART which is shared with the
> > frdme310arty,
> > an interrupt controller, and timer. The included device tree source
> > just covers a minimal set of peripherals. The device tree can be
> > expanded as additional device support is addded.
> > Manufacturer, board links, and other information can be found in
> > ticket #4876.
> >
> > Documentation that describes how to build and run the BSP on the
> > boards and simulator has been prepared and will be submitted after
> > the bsp
> > is merged.
> >
> > The full testsuite has not been run on this BSP, but I run a
> > subset of the of testsuite on the renode.io robot test framework.
> >
> > Alan Cudmore (3):
> >   bsps/riscv: add device tree source and device tree blob header for
> > k210 bsp variant
> >   bsps/riscv: add riscv/kendrytek210 BSP variant source changes
> >   spec: add riscv kendrytek210 variant build options
> >
> >  bsps/riscv/riscv/config/kendrytek210.cfg  |   9 +
> >  bsps/riscv/riscv/console/console-config.c |  10 +-
> >  bsps/riscv/riscv/console/fe310-uart.c |   2 +-
> >  bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
> >  bsps/riscv/riscv/include/bsp.h|   4 +
> >  bsps/riscv/riscv/include/bsp/k210.h   | 105 ++
> >  .../riscv/include/bsp/kendryte-k210-dtb.h | 315
> > ++
> >  bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
> >  bsps/riscv/riscv/start/bspstart.c |  43 +++
> >  spec/build/bsps/optdtb.yml|   4 +-
> >  spec/build/bsps/optdtbheaderpath.yml  |   2 +
> >  spec/build/bsps/optfdtuboot.yml   |   3 +
> >  spec/build/bsps/riscv/optramsize.yml  |   2 +
> >  spec/build/bsps/riscv/riscv/abi.yml   |   1 +
> >  .../bsps/riscv/riscv/bspkendrtyek210.yml  |  19 ++
> >  spec/build/bsps/riscv/riscv/grp.yml   |   4 +
> >  spec/build/bsps/riscv/riscv/obj.yml   |   1 +
> >  .../bsps/riscv/riscv/optkendrytek210.yml  |  18 +
> >  spec/build/bsps/riscv/riscv/optns16550max.yml |   4 +-
> >  spec/build/bsps/riscv/riscv/optsifiveuart.yml |  20 ++
> >  spec/build/cpukit/optsmp.yml  |   1 +
> >  21 files changed, 779 insertions(+), 8 deletions(-)
> >  create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
> >  create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
> >  create mode 100644 bsps/riscv/riscv/include/bsp/k210.h
> >  create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h
> >  create mode 100644 spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
> >  create mode 100644 spec/build/bsps/riscv/riscv/optkendrytek210.yml
> >  create mode 100644 spec/build/bsps/riscv/riscv/optsifiveuart.yml
> >
> > --
> > 2.25.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/3] bsps/riscv: Make SMP start more robust

[Alan Cudmore]

Hi Sebastian,
I applied these three patches after my patches and ran them on my K210
board and simulator. I have a set of 12 tests including benchmarks, SMP01,
SMP08, ticker, etc. Everything ran OK.
Is there anything in particular I can try to test them like setting the
maximum CPUs to 1? (K210 is a dual core)
Alan


On Thu, Mar 16, 2023 at 4:59 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> In SMP configurations, check that we run on a configured processor.  If
> not,
> then there is not much what can be done since we do not have a stack
> available
> for this processor.  Just loop forever in this case.  Do this in assemlby
> to
> ensure that no stack memory is used.
> ---
>  bsps/riscv/riscv/start/bspsmp.c |  5 +
>  bsps/riscv/shared/start/start.S | 16 ++--
>  2 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/bsps/riscv/riscv/start/bspsmp.c
> b/bsps/riscv/riscv/start/bspsmp.c
> index 91f4f7b96a..ce5792f5b8 100644
> --- a/bsps/riscv/riscv/start/bspsmp.c
> +++ b/bsps/riscv/riscv/start/bspsmp.c
> @@ -36,10 +36,7 @@ void bsp_start_on_secondary_processor(Per_CPU_Control
> *cpu_self)
>
>cpu_index_self = _Per_CPU_Get_index(cpu_self);
>
> -  if (
> -cpu_index_self < rtems_configuration_get_maximum_processors()
> -  && _SMP_Should_start_processor(cpu_index_self)
> -  ) {
> +  if (_SMP_Should_start_processor(cpu_index_self)) {
>  set_csr(mie, MIP_MSIP | MIP_MEIP);
>  _SMP_Start_multitasking_on_secondary_processor(cpu_self);
>} else {
> diff --git a/bsps/riscv/shared/start/start.S
> b/bsps/riscv/shared/start/start.S
> index 34e1839ca1..42e4348cd0 100644
> --- a/bsps/riscv/shared/start/start.S
> +++ b/bsps/riscv/shared/start/start.S
> @@ -66,8 +66,17 @@ SYM(_start):
> LADDR   sp, _ISR_Stack_area_begin
> LADDR   t2, _ISR_Stack_size
> csrrs0, mhartid
> -   li  t3, RISCV_BOOT_HARTID
> -   sub s0, s0, t3
> +   li  t3, RISCV_BOOT_HARTID
> +   sub s0, s0, t3
> +
> +   /*
> +* Check that this is a configured processor.  If not, then there
> is
> +* not much what can be done since we do not have a stack
> available for
> +* this processor.  Just loop forever in this case.
> +*/
> +   LREGt3, _SMP_Processor_configured_maximum
> +   bgeus0, t3, .Lwfi
> +
> LADDR   t0, _Per_CPU_Information
> sllit1, s0, PER_CPU_CONTROL_SIZE_LOG2
> add s1, t0, t1
> @@ -100,6 +109,9 @@ SYM(_start):
> tailboot_card
>
>  #ifdef RTEMS_SMP
> +.Lwfi:
> +   wfi
> +   j   .Lwfi
>
>  .Lstart_on_secondary_processor:
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 3/3] spec: add riscv kendrytek210 variant build options

[Alan Cudmore]

This patch includes the spec/build options for the riscv kendrytek210
BSP variant. It includes options to allow the frdme310arty console
UART to be used on multiple BSPS, device tree options, memory
options, and other required options for the variant.

Updates #4876
---
 spec/build/bsps/optdtb.yml|  4 +++-
 spec/build/bsps/optdtbheaderpath.yml  |  2 ++
 spec/build/bsps/optfdtuboot.yml   |  3 +++
 spec/build/bsps/riscv/optramsize.yml  |  2 ++
 spec/build/bsps/riscv/riscv/abi.yml   |  1 +
 .../bsps/riscv/riscv/bspkendrtyek210.yml  | 19 ++
 spec/build/bsps/riscv/riscv/grp.yml   |  4 
 spec/build/bsps/riscv/riscv/obj.yml   |  1 +
 .../bsps/riscv/riscv/optkendrytek210.yml  | 18 +
 spec/build/bsps/riscv/riscv/optns16550max.yml |  4 +++-
 spec/build/bsps/riscv/riscv/optsifiveuart.yml | 20 +++
 spec/build/cpukit/optsmp.yml  |  1 +
 12 files changed, 77 insertions(+), 2 deletions(-)
 create mode 100644 spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optkendrytek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optsifiveuart.yml

diff --git a/spec/build/bsps/optdtb.yml b/spec/build/bsps/optdtb.yml
index 78fed67866..f775dc7750 100644
--- a/spec/build/bsps/optdtb.yml
+++ b/spec/build/bsps/optdtb.yml
@@ -6,7 +6,9 @@ build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 default:
-- enabled-by: riscv/mpfs64imafdc
+- enabled-by:
+  - riscv/mpfs64imafdc
+  - riscv/kendrytek210
   value: true
 - enabled-by: true
   value: false
diff --git a/spec/build/bsps/optdtbheaderpath.yml 
b/spec/build/bsps/optdtbheaderpath.yml
index 65573c4cb8..944c8e830e 100644
--- a/spec/build/bsps/optdtbheaderpath.yml
+++ b/spec/build/bsps/optdtbheaderpath.yml
@@ -8,6 +8,8 @@ copyrights:
 default:
 - enabled-by: riscv/mpfs64imafdc
   value: bsp/mpfs-dtb.h
+- enabled-by: riscv/kendrytek210
+  value: bsp/kendryte-k210-dtb.h
 - enabled-by: true
   value: false
 description: |
diff --git a/spec/build/bsps/optfdtuboot.yml b/spec/build/bsps/optfdtuboot.yml
index 8c53b8b799..9d91639dc6 100644
--- a/spec/build/bsps/optfdtuboot.yml
+++ b/spec/build/bsps/optfdtuboot.yml
@@ -6,6 +6,9 @@ build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 default:
+- enabled-by:
+  - riscv/kendrytek210
+  value: false
 - enabled-by: true
   value: true
 description: |
diff --git a/spec/build/bsps/riscv/optramsize.yml 
b/spec/build/bsps/riscv/optramsize.yml
index be80c0f462..1fc407d1ea 100644
--- a/spec/build/bsps/riscv/optramsize.yml
+++ b/spec/build/bsps/riscv/optramsize.yml
@@ -15,6 +15,8 @@ default:
   value: 0x1000
 - enabled-by: riscv/griscv
   value: 0x0100
+- enabled-by: riscv/kendrytek210
+  value: 0x0060
 - enabled-by: true
   value: 0x0400
 description: ''
diff --git a/spec/build/bsps/riscv/riscv/abi.yml 
b/spec/build/bsps/riscv/riscv/abi.yml
index ab3046ee24..de23bdd795 100644
--- a/spec/build/bsps/riscv/riscv/abi.yml
+++ b/spec/build/bsps/riscv/riscv/abi.yml
@@ -10,6 +10,7 @@ default:
 - enabled-by:
   - riscv/mpfs64imafdc
   - riscv/rv64imafdc
+  - riscv/kendrytek210
   value:
   - -march=rv64imafdc
   - -mabi=lp64d
diff --git a/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml 
b/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
new file mode 100644
index 00..91c601979e
--- /dev/null
+++ b/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: riscv
+bsp: kendrytek210
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2022 Alan Cudmore
+cppflags: []
+enabled-by: true
+family: riscv
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: ../../opto2
+- role: build-dependency
+  uid: grp
+source: []
+type: build
diff --git a/spec/build/bsps/riscv/riscv/grp.yml 
b/spec/build/bsps/riscv/riscv/grp.yml
index 713c15509a..a2ed4a1052 100644
--- a/spec/build/bsps/riscv/riscv/grp.yml
+++ b/spec/build/bsps/riscv/riscv/grp.yml
@@ -50,10 +50,14 @@ links:
   uid: ../../optdtbheaderpath
 - role: build-dependency
   uid: optfrdme310arty
+- role: build-dependency
+  uid: optkendrytek210
 - role: build-dependency
   uid: opthtif
 - role: build-dependency
   uid: optmpfs
+- role: build-dependency
+  uid: optsifiveuart
 - role: build-dependency
   uid: optns16550max
 - role: build-dependency
diff --git a/spec/build/bsps/riscv/riscv/obj.yml 
b/spec/build/bsps/riscv/riscv/obj.yml
index 0ddeef828b..d28945fae4 100644
--- a/spec/build/bsps/riscv/riscv/obj.yml
+++ b/spec/build/bsps/riscv/riscv/obj.yml
@@ -16,6 +16,7 @@ install:
   - bsps/riscv/riscv/include/bsp/fe310-uart.h
   - bsps/riscv/riscv/include/bsp/irq.h
   - bsps/riscv/riscv/include/bsp/riscv.h
+  - bsps/riscv/riscv/include/bsp/k210.h
 - destination: ${BSP_INCLUDEDIR}/dev/serial
   source:
   - bsps/r

[PATCH v2 1/3] bsps/riscv: add device tree source and device tree blob header for k210 bsp variant

[Alan Cudmore]

This patch adds the k210 device tree source and the corresponding
device tree blob encoded in the header which is used for the
embedded device tree blob for the Kendryte K210 BSP variant.

Updates #4876
---
 bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
 .../riscv/include/bsp/kendryte-k210-dtb.h | 315 ++
 2 files changed, 531 insertions(+)
 create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
 create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h

diff --git a/bsps/riscv/riscv/dts/kendryte-k210.dts 
b/bsps/riscv/riscv/dts/kendryte-k210.dts
new file mode 100644
index 00..cad413dc81
--- /dev/null
+++ b/bsps/riscv/riscv/dts/kendryte-k210.dts
@@ -0,0 +1,216 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) Alan Cudmore
+ * Copyright (C) Padmarao Begari
+ * Copyright (C) 2022 Microchip Technology Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+ /* This is a device tree for the Kendryte K210 SoC. It is a simplified tree
+  * to support the current RTEMS BSP, but it is not sufficient enough for
+  * full linux or u-boot support.
+  * The file structure is based on the device tree source for the
+  * Polarfire SoC created by Padmaro Begari. The K210 device trees from
+  * u-boot were originally used to bring up the RTEMS BSP and were
+  * referenced to develop this file.
+  */
+
+/dts-v1/;
+
+/ {
+/* 32 bit address bus - upper 32 bits are ignored */
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   model = "Kendtryte K210 generic";
+   compatible = "canaan,kendryte-k210";
+
+   aliases {
+   serial0 = &uarths0;
+   serial1 = &uart1;
+   /* serial2 = &uart2; */
+   /* serial3 = &uart3; */
+   };
+
+   chosen {
+   stdout-path = "serial0";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   timebase-frequency = <780>;
+
+   cpu0: cpu@0 {
+   compatible = "canaan,k210", "riscv";
+   device_type = "cpu";
+   reg = <0>;
+   riscv,isa = "rv64imafdc";
+   i-cache-block-size = <64>;
+   i-cache-size = <0x8000>;
+   d-cache-block-size = <64>;
+   d-cache-size = <0x8000>;
+   cpu0_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+   cpu1: cpu@1 {
+   compatible = "canaan,k210", "riscv";
+   device_type = "cpu";
+   reg = <1>;
+   riscv,isa = "rv64imafdc";
+   i-cache-block-size = <64>;
+   i-cache-size = <0x8000>;
+   d-cache-block-size = <64>;
+   d-cache-size = <0x8000>;
+   cpu1_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+
+   };
+
+   clocks {
+i

[PATCH v2 2/3] bsps/riscv: add riscv/kendrytek210 BSP variant source changes

[Alan Cudmore]

This patch adds support for the Kendryte K210 RISC-V BSP variant.
The SoC uses the existing Interrupt Controller, Timer, and console UART.
It only needs SoC specific initialization and an embedded device tree binary
similar to the polarfire SoC BSP.

Updates #4876
---
 bsps/riscv/riscv/config/kendrytek210.cfg  |   9 ++
 bsps/riscv/riscv/console/console-config.c |  10 +--
 bsps/riscv/riscv/console/fe310-uart.c |   2 +-
 bsps/riscv/riscv/include/bsp.h|   4 +
 bsps/riscv/riscv/include/bsp/k210.h   | 105 ++
 bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
 bsps/riscv/riscv/start/bspstart.c |  43 +
 7 files changed, 171 insertions(+), 6 deletions(-)
 create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
 create mode 100644 bsps/riscv/riscv/include/bsp/k210.h

diff --git a/bsps/riscv/riscv/config/kendrytek210.cfg 
b/bsps/riscv/riscv/config/kendrytek210.cfg
new file mode 100644
index 00..b04e78b0e9
--- /dev/null
+++ b/bsps/riscv/riscv/config/kendrytek210.cfg
@@ -0,0 +1,9 @@
+include $(RTEMS_ROOT)/make/custom/default.cfg
+
+RTEMS_CPU = riscv
+
+CPU_CFLAGS = -march=rv64imafdc -mabi=lp64d -mcmodel=medany
+
+LDFLAGS = -Wl,--gc-sections
+
+CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
diff --git a/bsps/riscv/riscv/console/console-config.c 
b/bsps/riscv/riscv/console/console-config.c
index 4916191e0b..72743fe9d5 100644
--- a/bsps/riscv/riscv/console/console-config.c
+++ b/bsps/riscv/riscv/console/console-config.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
 #include 
 static fe310_uart_context fe310_uart_instance;
 #endif
@@ -239,7 +239,7 @@ static void riscv_console_probe(void)
 }
 #endif
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
 if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0")) {
   fe310_uart_context *ctx;
 
@@ -255,7 +255,7 @@ static void riscv_console_probe(void)
 riscv_console.getchar = fe310_uart_read;
   }
 
-  rtems_termios_device_context_initialize(&ctx->base, "FE310UART");
+  rtems_termios_device_context_initialize(&ctx->base, "SIFIVEUART");
 }
 #endif
 
@@ -290,7 +290,7 @@ rtems_status_code console_initialize(
   size_t i;
 #endif
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
   fe310_uart_context *ctx;
   char fe310_path[] = "/dev/ttyS0";
 #endif
@@ -326,7 +326,7 @@ rtems_status_code console_initialize(
   }
 #endif
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
   ctx = &fe310_uart_instance;
   rtems_termios_device_install(
 fe310_path,
diff --git a/bsps/riscv/riscv/console/fe310-uart.c 
b/bsps/riscv/riscv/console/fe310-uart.c
index 506521add0..ddabcff4c8 100644
--- a/bsps/riscv/riscv/console/fe310-uart.c
+++ b/bsps/riscv/riscv/console/fe310-uart.c
@@ -53,7 +53,7 @@ static void fe310_uart_write (
   fe310_uart_context * ctx = (fe310_uart_context*) base;
   size_t i;
 
-  ctx->regs->div = riscv_get_core_frequency() / 115200 - 1;
+  ctx->regs->div = (riscv_get_core_frequency() / 115200 - 1) & 0x;
   ctx->regs->txctrl |= 1;
   ctx->regs->rxctrl |= 1;
 
diff --git a/bsps/riscv/riscv/include/bsp.h b/bsps/riscv/riscv/include/bsp.h
index 911b85f4a3..c33de42aa7 100644
--- a/bsps/riscv/riscv/include/bsp.h
+++ b/bsps/riscv/riscv/include/bsp.h
@@ -60,6 +60,10 @@
 
 #include 
 
+#if RISCV_ENABLE_KENDRYTE_K210_SUPPORT != 0
+   #include 
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
diff --git a/bsps/riscv/riscv/include/bsp/k210.h 
b/bsps/riscv/riscv/include/bsp/k210.h
new file mode 100644
index 00..d5ae062863
--- /dev/null
+++ b/bsps/riscv/riscv/include/bsp/k210.h
@@ -0,0 +1,105 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup k210_regs
+ *
+ * @brief k210 RISC-V CPU defines.
+ */
+
+/*
+ * Copyright (c) 2022 Alan Cudmore
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in the
+ *  documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPEC

[PATCH v2 0/3] bsps/riscv: Add kendrytek210 riscv BSP variant

[Alan Cudmore]

Version 2 patch updates: Separated the device tree source and encoded
device tree blob into a separate patch, added the license text to
k210.h, eliminated whitespace warnings, and eliminated dead code in 
the conditional compilation structure for the core_get_frequency
function in start/bspstart.c.

This patch set adds the riscv/kendrytek210 BSP variant to support the
Kendryte K210 Dual Core RISC-V SoC. The BSP runs on the renode.io
simulator, the Sipeed MAiX BiT and MAiXDuino boards, and would likely
run on other boards. RTEMS binaries can be flashed to the boards using
the kflash python utility available through the pip command. Currently
the BSP supports the console UART which is shared with the frdme310arty,
an interrupt controller, and timer. The included device tree source
just covers a minimal set of peripherals. The device tree can be
expanded as additional device support is addded.
Manufacturer, board links, and other information can be found in
ticket #4876.

Documentation that describes how to build and run the BSP on the
boards and simulator has been prepared and will be submitted after the bsp
is merged.

The full testsuite has not been run on this BSP, but I run a
subset of the of testsuite on the renode.io robot test framework.

Alan Cudmore (3):
  bsps/riscv: add device tree source and device tree blob header for
k210 bsp variant
  bsps/riscv: add riscv/kendrytek210 BSP variant source changes
  spec: add riscv kendrytek210 variant build options

 bsps/riscv/riscv/config/kendrytek210.cfg  |   9 +
 bsps/riscv/riscv/console/console-config.c |  10 +-
 bsps/riscv/riscv/console/fe310-uart.c |   2 +-
 bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
 bsps/riscv/riscv/include/bsp.h|   4 +
 bsps/riscv/riscv/include/bsp/k210.h   | 105 ++
 .../riscv/include/bsp/kendryte-k210-dtb.h | 315 ++
 bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
 bsps/riscv/riscv/start/bspstart.c |  43 +++
 spec/build/bsps/optdtb.yml|   4 +-
 spec/build/bsps/optdtbheaderpath.yml  |   2 +
 spec/build/bsps/optfdtuboot.yml   |   3 +
 spec/build/bsps/riscv/optramsize.yml  |   2 +
 spec/build/bsps/riscv/riscv/abi.yml   |   1 +
 .../bsps/riscv/riscv/bspkendrtyek210.yml  |  19 ++
 spec/build/bsps/riscv/riscv/grp.yml   |   4 +
 spec/build/bsps/riscv/riscv/obj.yml   |   1 +
 .../bsps/riscv/riscv/optkendrytek210.yml  |  18 +
 spec/build/bsps/riscv/riscv/optns16550max.yml |   4 +-
 spec/build/bsps/riscv/riscv/optsifiveuart.yml |  20 ++
 spec/build/cpukit/optsmp.yml  |   1 +
 21 files changed, 779 insertions(+), 8 deletions(-)
 create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
 create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
 create mode 100644 bsps/riscv/riscv/include/bsp/k210.h
 create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h
 create mode 100644 spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optkendrytek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optsifiveuart.yml

-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] bsps/riscv: add riscv/kendrytek210 BSP variant

[Alan Cudmore]

On Tue, Mar 14, 2023 at 11:35 PM Gedare Bloom  wrote:

> >> >> > diff --git a/bsps/riscv/riscv/start/bspstart.c
> b/bsps/riscv/riscv/start/bspstart.c
> >> >> > index 30d479ce88..a0b6e683f6 100644
> >> >> > --- a/bsps/riscv/riscv/start/bspstart.c
> >> >> > +++ b/bsps/riscv/riscv/start/bspstart.c
> >> >> > @@ -201,6 +201,14 @@ static uint32_t get_core_frequency(void)
> >> >> >  return fdt32_to_cpu(*val);
> >> >> >}
> >> >> >  #endif
> >> >> > +
> >> >> > +#if RISCV_ENABLE_KENDRYTE_K210_SUPPORT != 0
> >> >> > +  uint32_t cpu_clock;
> >> >> > +
> >> >> > +  cpu_clock = k210_get_frequency();
> >> >> > +  return cpu_clock;
> >> >> > +#endif
> >> >> > +
> >> >> >return 0;
> >> >
> >> >
> >> > When you choose the kendrtyek210 BSP variant, the
> RISCV_ENABLE_KENDRYTE_K210_SUPPORT is set to true enabling the code that is
> needed for frequency calculation in this file. I tried to follow the same
> pattern for the MPFS and FRDME310ARTY variants here.
> >> > The K210, FRME310ARTY, and MPFS options could probably use
> refactoring, but I was reluctant to change existing code for the MPFS and
> 310ARTY since I do not have a way of testing them.
> >> >
> >> I would at  a minimum make it #else return 0
> >> to avoid having unreachable code in your build.
> >>
> >
> >  The "return 0" is right after my ifdef block. If I put #else return 0,
> then there will be two "return 0" statements.
> > If none of the variant options are defined, then the entire routine
> defaults to "return 0" at the bottom.
> > Should I eliminate that and put the else clauses for the FRDME310ARTY
> and MPFS variants too?
>
> I meant to put the 'return 0;' in an #else
> That will leave the tail of the function with just one return
> statement, dependent on the CPP macro conditional.
> #if RISCV_ENABLE_KENDRYTE_K210_SUPPORT != 0
>   uint32_t cpu_clock;
>
>   cpu_clock = k210_get_frequency();
>   return cpu_clock;
> #else
>   return 0;
> #endif
>
> This will avoid having a dead code issue. The other blocks above don't
> need to be modified.
>
> I understand now. The 310ARTY or MPFS could fall through to the 'return
0', but the k210 code will always return leaving the extra 'return 0' as
dead code.
I'll send a v2 patch set. I also removed some whitespace warnings that
occur when you apply the patches.
In addition to a few whitespace warnings in the code I added, the
rtems-bin2c tool leaves a space at the end of each line in the array,
causing git to complain about the extra whitespace. If you think that
should be fixed we could put in a ticket for the tool. That could be an
easy contribution for a student.
Thanks,
Alan


> > Thanks,
> > Alan
> >
> >>
> >>
> >> >
> >> >> This code is unreachable if RISCV_ENABLE_KENDRYTE_K210_SUPPORT != 0.
> >> >>
> >> >> >  }
> >> >> >
> >> >> > @@ -215,6 +223,40 @@ uint32_t bsp_fdt_map_intr(const uint32_t
> *intr, size_t icells)
> >> >> >return RISCV_INTERRUPT_VECTOR_EXTERNAL(intr[0]);
> >> >> >  }
> >> >> >
> >> >> > +#if RISCV_ENABLE_KENDRYTE_K210_SUPPORT != 0
> >> >> > +uint32_t k210_get_frequency(void)
> >> >> > +{
> >> >> > +  k210_sysctl_t *sysctl = (k210_sysctl_t *)K210_SYSCTL_BASE;
> >> >> > +  uint32_t cpu_clock = 0;
> >> >> > +  uint32_t clk_freq;
> >> >> > +  uint32_t pll0, nr, nf, od;
> >> >> > +  uint32_t node;
> >> >> > +  const char *fdt;
> >> >> > +  const fdt32_t *val;
> >> >> > +  int len;
> >> >> > +
> >> >> > +  fdt = bsp_fdt_get();
> >> >> > +  node = fdt_node_offset_by_compatible(fdt, -1,"fixed-clock");
> >> >> > +  val = fdt_getprop(fdt, node, "clock-frequency", &len);
> >> >> > +  if (val != NULL && len == 4) {
> >> >> > +clk_freq = fdt32_to_cpu(*val);
> >> >> > +
> >> >> > +if (CLKSEL0_ACLK_SEL(sysctl->clk_sel0) == 1) {
> >> >> > +   /* PLL0 selected */
> >> >> > +   pll0 = sysctl->pll0;
> >> >> > +   nr = PLL_CLK_R(pll0) + 1;
> >> >> > +   nf = PLL_CLK_F(pll0) + 1;
> >> >> > +   od = PLL_CLK_OD(pll0) + 1;
> >> >> > +   cpu_clock = (clk_freq / nr * nf / od)/2;
> >> >> > +} else {
> >> >> > +   /* OSC selected */
> >> >> > +   cpu_clock = clk_freq;
> >> >> > +}
> >> >> > +  }
> >> >> > +  return cpu_clock;
> >> >> > +}
> >> >> > +#endif
> >> >> > +
> >> >> >  void bsp_start(void)
> >> >> >  {
> >> >> >riscv_find_harts();
> >> >> > --
> >> >> > 2.25.1
> >> >> >
> >> >> > ___
> >> >> > devel mailing list
> >> >> > devel@rtems.org
> >> >> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RISC-V link warning :base_sp.exe has a LOAD segment with RWX permissions

[Alan Cudmore]

Hi,
I noticed that my RISC-V builds with the RTEMS master and RSB master now
have this warning on each link:
[3405/4331] Linking build/riscv/rv64imafdc/testsuites/samples/minimum.exe
/home/alan/rtems/tools/6/lib/gcc/riscv-rtems6/12.2.1/../../../../riscv-rtems6/bin/ld:
warning:
/home/alan/rtems/rtems/build/riscv/rv64imafdc/testsuites/samples/base_sp.exe
has a LOAD segment with RWX permissions

I was trying to back up commits in the RTEMS and RSB repositories to see
when it started, but I have not figured it out yet.

My host is Ubuntu 20.04.1 LTS x86_64.

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] bsps/riscv: add riscv/kendrytek210 BSP variant

[Alan Cudmore]

On Mon, Mar 13, 2023 at 12:16 PM Gedare Bloom  wrote:

> On Mon, Mar 13, 2023 at 9:53 AM Alan Cudmore 
> wrote:
> >
> > Thanks for taking a look. Comments below.
> >
> > On Mon, Mar 13, 2023 at 11:04 AM Gedare Bloom  wrote:
> >>
> >> On Thu, Mar 9, 2023 at 8:48 PM Alan Cudmore 
> wrote:
> >> >
> >> > This patch set adds support for the Kendryte K210 RISC-V BSP variant.
> >> > The SoC uses existing PLIC, Timer, and console UART. It only needs
> >> > SoC specific initalization and an embedded device tree binary similar
> >> > to the polarfire SoC BSP.
> >> >
> >> > Updates #4876
> >> > ---
> >> >  bsps/riscv/riscv/config/kendrytek210.cfg  |   9 +
> >> >  bsps/riscv/riscv/console/console-config.c |  10 +-
> >> >  bsps/riscv/riscv/console/fe310-uart.c |   2 +-
> >> >  bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
> >> >  bsps/riscv/riscv/include/bsp.h|   4 +
> >> >  bsps/riscv/riscv/include/bsp/k210.h   |  91 +
> >> >  .../riscv/include/bsp/kendryte-k210-dtb.h | 315
> ++
> >> >  bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
> >> >  bsps/riscv/riscv/start/bspstart.c |  42 +++
> >> >  9 files changed, 687 insertions(+), 6 deletions(-)
> >> >  create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
> >> >  create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
> >> >  create mode 100644 bsps/riscv/riscv/include/bsp/k210.h
> >> >  create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h
> >> >
> >> > diff --git a/bsps/riscv/riscv/config/kendrytek210.cfg
> b/bsps/riscv/riscv/config/kendrytek210.cfg
> >> > new file mode 100644
> >> > index 00..b04e78b0e9
> >> > --- /dev/null
> >> > +++ b/bsps/riscv/riscv/config/kendrytek210.cfg
> >> > @@ -0,0 +1,9 @@
> >> > +include $(RTEMS_ROOT)/make/custom/default.cfg
> >> > +
> >> > +RTEMS_CPU = riscv
> >> > +
> >> > +CPU_CFLAGS = -march=rv64imafdc -mabi=lp64d -mcmodel=medany
> >> > +
> >> > +LDFLAGS = -Wl,--gc-sections
> >> > +
> >> > +CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
> >> > diff --git a/bsps/riscv/riscv/console/console-config.c
> b/bsps/riscv/riscv/console/console-config.c
> >> > index 4916191e0b..72743fe9d5 100644
> >> > --- a/bsps/riscv/riscv/console/console-config.c
> >> > +++ b/bsps/riscv/riscv/console/console-config.c
> >> > @@ -55,7 +55,7 @@
> >> >  #include 
> >> >  #include 
> >> >
> >> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> >> > +#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
> >> >  #include 
> >> >  static fe310_uart_context fe310_uart_instance;
> >> >  #endif
> >> > @@ -239,7 +239,7 @@ static void riscv_console_probe(void)
> >> >  }
> >> >  #endif
> >> >
> >> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> >> > +#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
> >> >  if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0"))
> {
> >> >fe310_uart_context *ctx;
> >> >
> >> > @@ -255,7 +255,7 @@ static void riscv_console_probe(void)
> >> >  riscv_console.getchar = fe310_uart_read;
> >> >}
> >> >
> >> > -  rtems_termios_device_context_initialize(&ctx->base,
> "FE310UART");
> >> > +  rtems_termios_device_context_initialize(&ctx->base,
> "SIFIVEUART");
> >> >  }
> >> >  #endif
> >> >
> >> > @@ -290,7 +290,7 @@ rtems_status_code console_initialize(
> >> >size_t i;
> >> >  #endif
> >> >
> >> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> >> > +#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
> >> >fe310_uart_context *ctx;
> >> >char fe310_path[] = "/dev/ttyS0";
> >> >  #endif
> >> > @@ -326,7 +326,7 @@ rtems_status_code console_initialize(
> >> >}
> >> >  #endif
> >> >
> >> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> >> > +#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
> >> >ctx = &fe310_uart_instance;
>

Re: [PATCH 2/2] bsps/riscv: add riscv/kendrytek210 BSP variant

[Alan Cudmore]

Thanks for taking a look. Comments below.

On Mon, Mar 13, 2023 at 11:04 AM Gedare Bloom  wrote:

> On Thu, Mar 9, 2023 at 8:48 PM Alan Cudmore 
> wrote:
> >
> > This patch set adds support for the Kendryte K210 RISC-V BSP variant.
> > The SoC uses existing PLIC, Timer, and console UART. It only needs
> > SoC specific initalization and an embedded device tree binary similar
> > to the polarfire SoC BSP.
> >
> > Updates #4876
> > ---
> >  bsps/riscv/riscv/config/kendrytek210.cfg  |   9 +
> >  bsps/riscv/riscv/console/console-config.c |  10 +-
> >  bsps/riscv/riscv/console/fe310-uart.c |   2 +-
> >  bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
> >  bsps/riscv/riscv/include/bsp.h|   4 +
> >  bsps/riscv/riscv/include/bsp/k210.h   |  91 +
> >  .../riscv/include/bsp/kendryte-k210-dtb.h | 315 ++
> >  bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
> >  bsps/riscv/riscv/start/bspstart.c |  42 +++
> >  9 files changed, 687 insertions(+), 6 deletions(-)
> >  create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
> >  create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
> >  create mode 100644 bsps/riscv/riscv/include/bsp/k210.h
> >  create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h
> >
> > diff --git a/bsps/riscv/riscv/config/kendrytek210.cfg
> b/bsps/riscv/riscv/config/kendrytek210.cfg
> > new file mode 100644
> > index 00..b04e78b0e9
> > --- /dev/null
> > +++ b/bsps/riscv/riscv/config/kendrytek210.cfg
> > @@ -0,0 +1,9 @@
> > +include $(RTEMS_ROOT)/make/custom/default.cfg
> > +
> > +RTEMS_CPU = riscv
> > +
> > +CPU_CFLAGS = -march=rv64imafdc -mabi=lp64d -mcmodel=medany
> > +
> > +LDFLAGS = -Wl,--gc-sections
> > +
> > +CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
> > diff --git a/bsps/riscv/riscv/console/console-config.c
> b/bsps/riscv/riscv/console/console-config.c
> > index 4916191e0b..72743fe9d5 100644
> > --- a/bsps/riscv/riscv/console/console-config.c
> > +++ b/bsps/riscv/riscv/console/console-config.c
> > @@ -55,7 +55,7 @@
> >  #include 
> >  #include 
> >
> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> > +#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
> >  #include 
> >  static fe310_uart_context fe310_uart_instance;
> >  #endif
> > @@ -239,7 +239,7 @@ static void riscv_console_probe(void)
> >  }
> >  #endif
> >
> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> > +#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
> >  if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0")) {
> >fe310_uart_context *ctx;
> >
> > @@ -255,7 +255,7 @@ static void riscv_console_probe(void)
> >  riscv_console.getchar = fe310_uart_read;
> >}
> >
> > -  rtems_termios_device_context_initialize(&ctx->base, "FE310UART");
> > +  rtems_termios_device_context_initialize(&ctx->base, "SIFIVEUART");
> >  }
> >  #endif
> >
> > @@ -290,7 +290,7 @@ rtems_status_code console_initialize(
> >size_t i;
> >  #endif
> >
> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> > +#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
> >fe310_uart_context *ctx;
> >char fe310_path[] = "/dev/ttyS0";
> >  #endif
> > @@ -326,7 +326,7 @@ rtems_status_code console_initialize(
> >}
> >  #endif
> >
> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> > +#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
> >ctx = &fe310_uart_instance;
> >rtems_termios_device_install(
> >  fe310_path,
> > diff --git a/bsps/riscv/riscv/console/fe310-uart.c
> b/bsps/riscv/riscv/console/fe310-uart.c
> > index 506521add0..ddabcff4c8 100644
> > --- a/bsps/riscv/riscv/console/fe310-uart.c
> > +++ b/bsps/riscv/riscv/console/fe310-uart.c
> > @@ -53,7 +53,7 @@ static void fe310_uart_write (
> >fe310_uart_context * ctx = (fe310_uart_context*) base;
> >size_t i;
> >
> > -  ctx->regs->div = riscv_get_core_frequency() / 115200 - 1;
> > +  ctx->regs->div = (riscv_get_core_frequency() / 115200 - 1) & 0x;
> >ctx->regs->txctrl |= 1;
> >ctx->regs->rxctrl |= 1;
> >
> > diff --git a/bsps/riscv/riscv/dts/kendryte-k210.dts
> b/bsps/riscv/riscv/dts/kendryte-k210.dts
> > new file mode 100644
> > index 00..379aaf01a3
> > --- /dev/null
> > +++

Re: [PATCH 1/2] spec: add riscv Kendryte K210 variant options

[Alan Cudmore]

Good idea. With the number of changes, do you think one commit for the
spec/build options and one for the code is sufficient?

On Mon, Mar 13, 2023 at 10:55 AM Gedare Bloom  wrote:

> I'm not 100% sure it matters, but I think the spec/build commit should
> come after the source is added.  This is a generally good approach
> when integrating code vs build changes, so that you don't try to build
> something that doesn't exist.
>
> On Thu, Mar 9, 2023 at 8:48 PM Alan Cudmore 
> wrote:
> >
> > This patch includes the spec/build options for the riscv kendrytek210
> > BSP variant. It includes options to allow the frdme310arty console
> > UART to be used on multiple BSPS, device tree options, memory
> > options, and other required options for the variant.
> > ---
> >  spec/build/bsps/optdtb.yml|  4 +++-
> >  spec/build/bsps/optdtbheaderpath.yml  |  2 ++
> >  spec/build/bsps/optfdtuboot.yml   |  3 +++
> >  spec/build/bsps/riscv/optramsize.yml  |  2 ++
> >  spec/build/bsps/riscv/riscv/abi.yml   |  1 +
> >  .../bsps/riscv/riscv/bspkendrtyek210.yml  | 19 ++
> >  spec/build/bsps/riscv/riscv/grp.yml   |  4 
> >  spec/build/bsps/riscv/riscv/obj.yml   |  1 +
> >  .../bsps/riscv/riscv/optkendrytek210.yml  | 18 +
> >  spec/build/bsps/riscv/riscv/optns16550max.yml |  4 +++-
> >  spec/build/bsps/riscv/riscv/optsifiveuart.yml | 20 +++
> >  spec/build/cpukit/optsmp.yml  |  1 +
> >  12 files changed, 77 insertions(+), 2 deletions(-)
> >  create mode 100644 spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
> >  create mode 100644 spec/build/bsps/riscv/riscv/optkendrytek210.yml
> >  create mode 100644 spec/build/bsps/riscv/riscv/optsifiveuart.yml
> >
> > diff --git a/spec/build/bsps/optdtb.yml b/spec/build/bsps/optdtb.yml
> > index 78fed67866..f775dc7750 100644
> > --- a/spec/build/bsps/optdtb.yml
> > +++ b/spec/build/bsps/optdtb.yml
> > @@ -6,7 +6,9 @@ build-type: option
> >  copyrights:
> >  - Copyright (C) 2020 embedded brains GmbH (
> http://www.embedded-brains.de)
> >  default:
> > -- enabled-by: riscv/mpfs64imafdc
> > +- enabled-by:
> > +  - riscv/mpfs64imafdc
> > +  - riscv/kendrytek210
> >value: true
> >  - enabled-by: true
> >value: false
> > diff --git a/spec/build/bsps/optdtbheaderpath.yml
> b/spec/build/bsps/optdtbheaderpath.yml
> > index 65573c4cb8..944c8e830e 100644
> > --- a/spec/build/bsps/optdtbheaderpath.yml
> > +++ b/spec/build/bsps/optdtbheaderpath.yml
> > @@ -8,6 +8,8 @@ copyrights:
> >  default:
> >  - enabled-by: riscv/mpfs64imafdc
> >value: bsp/mpfs-dtb.h
> > +- enabled-by: riscv/kendrytek210
> > +  value: bsp/kendryte-k210-dtb.h
> >  - enabled-by: true
> >value: false
> >  description: |
> > diff --git a/spec/build/bsps/optfdtuboot.yml
> b/spec/build/bsps/optfdtuboot.yml
> > index 8c53b8b799..9d91639dc6 100644
> > --- a/spec/build/bsps/optfdtuboot.yml
> > +++ b/spec/build/bsps/optfdtuboot.yml
> > @@ -6,6 +6,9 @@ build-type: option
> >  copyrights:
> >  - Copyright (C) 2020 embedded brains GmbH (
> http://www.embedded-brains.de)
> >  default:
> > +- enabled-by:
> > +  - riscv/kendrytek210
> > +  value: false
> >  - enabled-by: true
> >value: true
> >  description: |
> > diff --git a/spec/build/bsps/riscv/optramsize.yml
> b/spec/build/bsps/riscv/optramsize.yml
> > index be80c0f462..1fc407d1ea 100644
> > --- a/spec/build/bsps/riscv/optramsize.yml
> > +++ b/spec/build/bsps/riscv/optramsize.yml
> > @@ -15,6 +15,8 @@ default:
> >value: 0x1000
> >  - enabled-by: riscv/griscv
> >value: 0x0100
> > +- enabled-by: riscv/kendrytek210
> > +  value: 0x0060
> >  - enabled-by: true
> >value: 0x0400
> >  description: ''
> > diff --git a/spec/build/bsps/riscv/riscv/abi.yml
> b/spec/build/bsps/riscv/riscv/abi.yml
> > index ab3046ee24..de23bdd795 100644
> > --- a/spec/build/bsps/riscv/riscv/abi.yml
> > +++ b/spec/build/bsps/riscv/riscv/abi.yml
> > @@ -10,6 +10,7 @@ default:
> >  - enabled-by:
> >- riscv/mpfs64imafdc
> >- riscv/rv64imafdc
> > +  - riscv/kendrytek210
> >value:
> >- -march=rv64imafdc
> >- -mabi=lp64d
> > diff --git a/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
> b/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
> > new file mode 100644
> > index 00..91c601979e
> 

[PATCH 1/2] spec: add riscv Kendryte K210 variant options

[Alan Cudmore]

This patch includes the spec/build options for the riscv kendrytek210
BSP variant. It includes options to allow the frdme310arty console
UART to be used on multiple BSPS, device tree options, memory
options, and other required options for the variant.
---
 spec/build/bsps/optdtb.yml|  4 +++-
 spec/build/bsps/optdtbheaderpath.yml  |  2 ++
 spec/build/bsps/optfdtuboot.yml   |  3 +++
 spec/build/bsps/riscv/optramsize.yml  |  2 ++
 spec/build/bsps/riscv/riscv/abi.yml   |  1 +
 .../bsps/riscv/riscv/bspkendrtyek210.yml  | 19 ++
 spec/build/bsps/riscv/riscv/grp.yml   |  4 
 spec/build/bsps/riscv/riscv/obj.yml   |  1 +
 .../bsps/riscv/riscv/optkendrytek210.yml  | 18 +
 spec/build/bsps/riscv/riscv/optns16550max.yml |  4 +++-
 spec/build/bsps/riscv/riscv/optsifiveuart.yml | 20 +++
 spec/build/cpukit/optsmp.yml  |  1 +
 12 files changed, 77 insertions(+), 2 deletions(-)
 create mode 100644 spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optkendrytek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optsifiveuart.yml

diff --git a/spec/build/bsps/optdtb.yml b/spec/build/bsps/optdtb.yml
index 78fed67866..f775dc7750 100644
--- a/spec/build/bsps/optdtb.yml
+++ b/spec/build/bsps/optdtb.yml
@@ -6,7 +6,9 @@ build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 default:
-- enabled-by: riscv/mpfs64imafdc
+- enabled-by:
+  - riscv/mpfs64imafdc
+  - riscv/kendrytek210
   value: true
 - enabled-by: true
   value: false
diff --git a/spec/build/bsps/optdtbheaderpath.yml 
b/spec/build/bsps/optdtbheaderpath.yml
index 65573c4cb8..944c8e830e 100644
--- a/spec/build/bsps/optdtbheaderpath.yml
+++ b/spec/build/bsps/optdtbheaderpath.yml
@@ -8,6 +8,8 @@ copyrights:
 default:
 - enabled-by: riscv/mpfs64imafdc
   value: bsp/mpfs-dtb.h
+- enabled-by: riscv/kendrytek210
+  value: bsp/kendryte-k210-dtb.h
 - enabled-by: true
   value: false
 description: |
diff --git a/spec/build/bsps/optfdtuboot.yml b/spec/build/bsps/optfdtuboot.yml
index 8c53b8b799..9d91639dc6 100644
--- a/spec/build/bsps/optfdtuboot.yml
+++ b/spec/build/bsps/optfdtuboot.yml
@@ -6,6 +6,9 @@ build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 default:
+- enabled-by:
+  - riscv/kendrytek210
+  value: false
 - enabled-by: true
   value: true
 description: |
diff --git a/spec/build/bsps/riscv/optramsize.yml 
b/spec/build/bsps/riscv/optramsize.yml
index be80c0f462..1fc407d1ea 100644
--- a/spec/build/bsps/riscv/optramsize.yml
+++ b/spec/build/bsps/riscv/optramsize.yml
@@ -15,6 +15,8 @@ default:
   value: 0x1000
 - enabled-by: riscv/griscv
   value: 0x0100
+- enabled-by: riscv/kendrytek210
+  value: 0x0060
 - enabled-by: true
   value: 0x0400
 description: ''
diff --git a/spec/build/bsps/riscv/riscv/abi.yml 
b/spec/build/bsps/riscv/riscv/abi.yml
index ab3046ee24..de23bdd795 100644
--- a/spec/build/bsps/riscv/riscv/abi.yml
+++ b/spec/build/bsps/riscv/riscv/abi.yml
@@ -10,6 +10,7 @@ default:
 - enabled-by:
   - riscv/mpfs64imafdc
   - riscv/rv64imafdc
+  - riscv/kendrytek210
   value:
   - -march=rv64imafdc
   - -mabi=lp64d
diff --git a/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml 
b/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
new file mode 100644
index 00..91c601979e
--- /dev/null
+++ b/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: riscv
+bsp: kendrytek210
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2022 Alan Cudmore
+cppflags: []
+enabled-by: true
+family: riscv
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: ../../opto2
+- role: build-dependency
+  uid: grp
+source: []
+type: build
diff --git a/spec/build/bsps/riscv/riscv/grp.yml 
b/spec/build/bsps/riscv/riscv/grp.yml
index 713c15509a..a2ed4a1052 100644
--- a/spec/build/bsps/riscv/riscv/grp.yml
+++ b/spec/build/bsps/riscv/riscv/grp.yml
@@ -50,10 +50,14 @@ links:
   uid: ../../optdtbheaderpath
 - role: build-dependency
   uid: optfrdme310arty
+- role: build-dependency
+  uid: optkendrytek210
 - role: build-dependency
   uid: opthtif
 - role: build-dependency
   uid: optmpfs
+- role: build-dependency
+  uid: optsifiveuart
 - role: build-dependency
   uid: optns16550max
 - role: build-dependency
diff --git a/spec/build/bsps/riscv/riscv/obj.yml 
b/spec/build/bsps/riscv/riscv/obj.yml
index 0ddeef828b..d28945fae4 100644
--- a/spec/build/bsps/riscv/riscv/obj.yml
+++ b/spec/build/bsps/riscv/riscv/obj.yml
@@ -16,6 +16,7 @@ install:
   - bsps/riscv/riscv/include/bsp/fe310-uart.h
   - bsps/riscv/riscv/include/bsp/irq.h
   - bsps/riscv/riscv/include/bsp/riscv.h
+  - bsps/riscv/riscv/include/bsp/k210.h
 - destination: ${BSP_INCLUDEDIR}/dev/serial
   source:
   - bsps/riscv/riscv/i

[PATCH 2/2] bsps/riscv: add riscv/kendrytek210 BSP variant

[Alan Cudmore]

This patch set adds support for the Kendryte K210 RISC-V BSP variant.
The SoC uses existing PLIC, Timer, and console UART. It only needs
SoC specific initalization and an embedded device tree binary similar
to the polarfire SoC BSP.

Updates #4876
---
 bsps/riscv/riscv/config/kendrytek210.cfg  |   9 +
 bsps/riscv/riscv/console/console-config.c |  10 +-
 bsps/riscv/riscv/console/fe310-uart.c |   2 +-
 bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
 bsps/riscv/riscv/include/bsp.h|   4 +
 bsps/riscv/riscv/include/bsp/k210.h   |  91 +
 .../riscv/include/bsp/kendryte-k210-dtb.h | 315 ++
 bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
 bsps/riscv/riscv/start/bspstart.c |  42 +++
 9 files changed, 687 insertions(+), 6 deletions(-)
 create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
 create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
 create mode 100644 bsps/riscv/riscv/include/bsp/k210.h
 create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h

diff --git a/bsps/riscv/riscv/config/kendrytek210.cfg 
b/bsps/riscv/riscv/config/kendrytek210.cfg
new file mode 100644
index 00..b04e78b0e9
--- /dev/null
+++ b/bsps/riscv/riscv/config/kendrytek210.cfg
@@ -0,0 +1,9 @@
+include $(RTEMS_ROOT)/make/custom/default.cfg
+
+RTEMS_CPU = riscv
+
+CPU_CFLAGS = -march=rv64imafdc -mabi=lp64d -mcmodel=medany
+
+LDFLAGS = -Wl,--gc-sections
+
+CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
diff --git a/bsps/riscv/riscv/console/console-config.c 
b/bsps/riscv/riscv/console/console-config.c
index 4916191e0b..72743fe9d5 100644
--- a/bsps/riscv/riscv/console/console-config.c
+++ b/bsps/riscv/riscv/console/console-config.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
 #include 
 static fe310_uart_context fe310_uart_instance;
 #endif
@@ -239,7 +239,7 @@ static void riscv_console_probe(void)
 }
 #endif
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
 if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0")) {
   fe310_uart_context *ctx;
 
@@ -255,7 +255,7 @@ static void riscv_console_probe(void)
 riscv_console.getchar = fe310_uart_read;
   }
 
-  rtems_termios_device_context_initialize(&ctx->base, "FE310UART");
+  rtems_termios_device_context_initialize(&ctx->base, "SIFIVEUART");
 }
 #endif
 
@@ -290,7 +290,7 @@ rtems_status_code console_initialize(
   size_t i;
 #endif
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
   fe310_uart_context *ctx;
   char fe310_path[] = "/dev/ttyS0";
 #endif
@@ -326,7 +326,7 @@ rtems_status_code console_initialize(
   }
 #endif
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
   ctx = &fe310_uart_instance;
   rtems_termios_device_install(
 fe310_path,
diff --git a/bsps/riscv/riscv/console/fe310-uart.c 
b/bsps/riscv/riscv/console/fe310-uart.c
index 506521add0..ddabcff4c8 100644
--- a/bsps/riscv/riscv/console/fe310-uart.c
+++ b/bsps/riscv/riscv/console/fe310-uart.c
@@ -53,7 +53,7 @@ static void fe310_uart_write (
   fe310_uart_context * ctx = (fe310_uart_context*) base;
   size_t i;
 
-  ctx->regs->div = riscv_get_core_frequency() / 115200 - 1;
+  ctx->regs->div = (riscv_get_core_frequency() / 115200 - 1) & 0x;
   ctx->regs->txctrl |= 1;
   ctx->regs->rxctrl |= 1;
 
diff --git a/bsps/riscv/riscv/dts/kendryte-k210.dts 
b/bsps/riscv/riscv/dts/kendryte-k210.dts
new file mode 100644
index 00..379aaf01a3
--- /dev/null
+++ b/bsps/riscv/riscv/dts/kendryte-k210.dts
@@ -0,0 +1,216 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) Alan Cudmore
+ * Copyright (C) Padmarao Begari
+ * Copyright (C) 2022 Microchip Technology Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SU

[PATCH 0/2] bsps/riscv: Add kendrytek210 riscv BSP variant

[Alan Cudmore]

This patch set adds the riscv/kendrytek210 BSP variant to support the
Kendryte K210 Dual Core RISC-V SoC. The BSP runs on the renode.io
 simulator, the Sipeed MAiX BiT and MAiXDuino boards, and would likely
run on other boards. RTEMS binaries can be flashed to the boards using
the kflash python utility available through the pip command. Currently
the BSP supports the console UART which is shared with the frdme310arty,
an interrupt controller, and timer. The included device tree source
just covers the minimal set of peripherals. The device tree can be
expanded as additional device support is addded.
Manufacturer, board links, and other information can be found in
ticket #4876.
Documentation that describes how to build and run the BSP on the 
boards and simulator has been prepared and will be submitted after the bsp
is merged.

Updates #4876

Alan Cudmore (2):
  spec: add riscv Kendryte K210 variant options
  bsps/riscv: add riscv/kendrytek210 BSP variant

 bsps/riscv/riscv/config/kendrytek210.cfg  |   9 +
 bsps/riscv/riscv/console/console-config.c |  10 +-
 bsps/riscv/riscv/console/fe310-uart.c |   2 +-
 bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
 bsps/riscv/riscv/include/bsp.h|   4 +
 bsps/riscv/riscv/include/bsp/k210.h   |  91 +
 .../riscv/include/bsp/kendryte-k210-dtb.h | 315 ++
 bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
 bsps/riscv/riscv/start/bspstart.c |  42 +++
 spec/build/bsps/optdtb.yml|   4 +-
 spec/build/bsps/optdtbheaderpath.yml  |   2 +
 spec/build/bsps/optfdtuboot.yml   |   3 +
 spec/build/bsps/riscv/optramsize.yml  |   2 +
 spec/build/bsps/riscv/riscv/abi.yml   |   1 +
 .../bsps/riscv/riscv/bspkendrtyek210.yml  |  19 ++
 spec/build/bsps/riscv/riscv/grp.yml   |   4 +
 spec/build/bsps/riscv/riscv/obj.yml   |   1 +
 .../bsps/riscv/riscv/optkendrytek210.yml  |  18 +
 spec/build/bsps/riscv/riscv/optns16550max.yml |   4 +-
 spec/build/bsps/riscv/riscv/optsifiveuart.yml |  20 ++
 spec/build/cpukit/optsmp.yml  |   1 +
 21 files changed, 764 insertions(+), 8 deletions(-)
 create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
 create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
 create mode 100644 bsps/riscv/riscv/include/bsp/k210.h
 create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h
 create mode 100644 spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optkendrytek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optsifiveuart.yml

-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Jetson Nano BSP

[Alan Cudmore]

On Fri, Feb 24, 2023 at 4:09 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> On 2023-02-24 03:52, Alan Cudmore wrote:
> > Hi all,
> >
> > On Thu, Feb 23, 2023 at 4:00 PM Karel Gardas 
> > wrote:
> >
> >
> > Hi Prakhar,
> >
> > On 2/23/23 20:23, Prakhar Agrawal wrote:
> >  > I completely agree with all your points, but my rationale for
> >  > introducing the jetson nano or jetson AGX orin was because of
> > their GPU
> >  > power.
> >
> > it's really nice what Nvidia achieved here, right? Unfortunately this
> > GPU potential is fully locked up by binary driver NVidia provides
> only
> > for selected number of platforms --- if not just for the only one:
> > Linux. So very questionable how you would unlock that on RTEMS during
> > the limited time of GSoC. Just see what Nouveau folks are doing:
> > https://nouveau.freedesktop.org/ <https://nouveau.freedesktop.org/>
> > -- for years and they just barely got
> > to 3D acceleration. Just clone their git repo, see number of patches,
> > lines of code provided and number of people involved and I think you
> > will get an idea how mamooth task this is...
> >
> >  >
> >  > In the case of large hobby projects or maybe the initial days of a
> >  > startup(seed ones), a real-time system that can work with boards
> > having
> >  > good GPU can do wonders.
> >  > For example, for an autonomous vehicle L2, L3 autonomy can be
> > achieved
> >  > using a 60W Jetson AGX orin, hence if RTEMS support is added to
> the
> >  > board, it might help create an awesome system to handle all the
> > critical
> >  > time constraints necessary for the vehicle and give it the
> > ability to
> >  > coordinate a large number of concurrent activities.
> >
> > If you are interested in machine vision based on AI and robotics, why
> > not to look around for more open-source friendly solution? Recently
> > just
> > found i.MX 8M Plus and their claimed 2.3 TOPS NPU. Certainly not that
> > powerful like NVidia, but NXP is historically more friendly to 3rd
> > party
> > OSes. Not sure about NPU, have not had a time to investigate that
> yet,
> > but perhaps you do?
> >
> > Also, with i.MX 8M Plus you still do have a chance to use AI Vision
> in
> > non-real time manner running on top of Linux and run RTEMS real-time
> > tasks on built in Cortex-M7 -- I mean if you decide that this
> > particular
> > BSP may be your GSoC. :-)
> >
> >
> https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-applications-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS
> <
> https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-applications-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS
> >
> >
> >  >> Honestly I'd rather see a new BSP for a decent RISC-V board.
> >  >
> >  > I was reading about RISC-V and their comparison with ARM SBC and
> > in one
> >  > blog I read this - "ARM processors have benefited from a lot more
> >  > research, funding, and development than RISC-V. This means that
> > it can
> >  > be argued that RISC-V is being left behind"
> >
> > Do not worry about it. RISC-V is here and will stay. A lot was
> already
> > invested into it and much more will still be...
> >
> > I'm working on submitting a RISC-V BSP variant for the Kendryte K210
> > CPU. It's low cost and has a 1TOPS NPU. I don't think the NPU needs a
> > binary driver, and it typically is used with FreeRTOS or bare metal.
> > But I do like the idea of a dual CPU system where a linux/AI processor
> > can work with a RTOS based MCU for real time tasks.
> >
>
> Systems where a Linux (or other desktop-like OS) runs on one core and
> RTEMS on another would be interesting for other cases too. For example
> for an industrial system where you can have a complex GUI and a real
> time part. We had some systems where we thought about implementing
> something like that.
>
>
It looks like the TI TDA4VM on the Beaglebone AI-64 has a dual core A72, a
number of DSPs, and 3 dual R5 processors. I'

Re: GSoC project suggestion for the BSP Raspberry pi 4B aarch64

[Alan Cudmore]

Improving Raspberry Pi 4 support would be a great GSOC project. Right now
the Beagleboard is my default for a low cost network enabled RTEMS board.
But a Pi4 with network and SMP support would be a great board to learn
RTEMS. Even better if the supply problems are addressed this year. In
addition to educational use, the RPI4 compute module enables industrial use
cases.
Regards,
Alan


On Sun, Feb 19, 2023 at 10:28 AM Joel Sherrill  wrote:

> That's all great information to include in the ticket and/or the Users
> Guide.
>
>
>
> On Sun, Feb 19, 2023, 7:44 AM Noor Aman  wrote:
>
>> I booted freeBSD on the Raspberry pi, I was able to confirm that it used
>> genet driver together with miibus for the NIC. This is further confirmed
>> with the FreeBSD manual page.
>> https://man.freebsd.org/cgi/man.cgi?query=genet
>>
>> One more thing to follow is that i noticed that FreeBSD is using PSCI, so
>> I'm assuming that it is being used for SMP. I'll file a ticket as soon as
>> I'm able to grab more information.
>>
>> Here are the full dmesg log of Raspberry pi 4B booting FreeBSD 13.2
>>
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB
>>> compliance
>>> Copyright (c) 1992-2021 The FreeBSD Project.
>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>> The Regents of the University of California. All rights reserved.
>>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>>> FreeBSD 13.2-BETA2 releng/13.2-n254478-065f7854521d GENERIC arm64
>>> FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git
>>> llvmorg-14.0.5-0-gc12386ae247c)
>>> VT(efifb): resolution 592x448
>>> module firmware already present!
>>> real memory  = 4148158464 (3955 MB)
>>> avail memory = 4022452224 (3836 MB)
>>> Starting CPU 1 (1)
>>> Starting CPU 2 (2)
>>> Starting CPU 3 (3)
>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>>> random: unblocking device.
>>> random: entropy device external interface
>>> MAP 39f2b000 mode 2 pages 1
>>> MAP 39f2f000 mode 2 pages 1
>>> MAP 39f31000 mode 2 pages 2
>>> MAP 39f34000 mode 2 pages 4
>>> MAP 3b35 mode 2 pages 16
>>> MAP fe10 mode 0 pages 1
>>> kbd0 at kbdmux0
>>> ofwbus0: 
>>> simplebus0:  on ofwbus0
>>> ofw_clkbus0:  on ofwbus0
>>> clk_fixed0:  on ofw_clkbus0
>>> clk_fixed1:  on ofw_clkbus0
>>> clk_fixed2:  on ofwbus0
>>> clk_fixed3:  on ofwbus0
>>> simplebus1:  on ofwbus0
>>> simplebus2:  on ofwbus0
>>> regfix0:  on ofwbus0
>>> regfix1:  on ofwbus0
>>> regfix2:  on ofwbus0
>>> simplebus3:  on ofwbus0
>>> simple_mfd0:  mem
>>> 0x7d5d2000-0x7d5d2eff on simplebus0
>>> bcm2835_firmware0:  on simplebus0
>>> ofw_clkbus1:  on bcm2835_firmware0
>>> psci0:  on ofwbus0
>>> gic0:  mem
>>> 0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x40046000-0x40047fff
>>> irq 30 on simplebus0
>>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>>> gpio0:  mem 0x7e20-0x7e2000b3 irq
>>> 14,15 on simplebus0
>>> gpiobus0:  on gpio0
>>> gpio1:  on bcm2835_firmware0
>>> gpiobus1:  on gpio1
>>> regfix0: Cannot set GPIO pin: 6
>>> REGNODE_INIT failed: 6
>>> regfix0: Cannot register regulator.
>>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on
>>> simplebus0
>>> gpioregulator0:  on ofwbus0
>>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>>> Timecounter "ARM MPCore Timecounter" frequency 5400 Hz quality 1000
>>> Event timer "ARM MPCore Eventtimer" frequency 5400 Hz quality 1000
>>> usb_nop_xceiv0:  on ofwbus0
>>> bcm2835_clkman0:  mem 0x7e101000-0x7e102fff on
>>> simplebus0
>>> gpioc0:  on gpio0
>>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on
>>> simplebus0
>>> uart0: console (115200,n,8,1)
>>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 on
>>> simplebus0
>>> spibus0:  on spi0
>>> spibus0:  at cs 0 mode 0
>>> spibus0:  at cs 1 mode 0
>>> iichb0:  mem 0x7e804000-0x7e804fff irq 26
>>> on simplebus0
>>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq
>>> 31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>> bcmwd0:  mem
>>> 0x7e10-0x7e100113,0x7e00a000-0x7e00a023,0x7ec11000-0x7ec1101f on
>>> simplebus0
>>> bcmrng0:  mem 0x7e104000-0x7e104027 on
>>> simplebus0
>>> gpioc1:  on gpio1
>>> sdhci_bcm0:  mem 0x7e30-0x7e3000ff
>>> irq 73 on simplebus0
>>> mmc0:  on sdhci_bcm0
>>> fb0:  on simplebus0
>>> fb0: keeping existing fb bpp of 32
>>> fbd0 on fb0
>>> WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD
>>> 14.0.
>>> VT: Replacing driver "efifb" with new "fb".
>>> fb0: 592x448(592x448@0,0) 32bpp
>>> fb0: fbswap: 1, pitch 2368, base 0x3eaf5000, screen_size 1060864
>>> sdhci_bcm1:  mem 0x7e34-0x7e3400ff
>>> irq 79 on simplebus1
>>> mmc1:  on sdhci_bcm1
>>> pmu0:  irq 0,1,2,3 on ofwbus0
>>> cpulist0:  on ofwbus0
>>> cpu0:  on cpulist0
>>> bcm2835_cpufreq0:  on cpu0
>>> cpu1:  on cpulist0
>>> cpu2:  on cpulist0
>>> cpu3:  on cpulist0
>>> pcib0:  mem
>>> 0x7d50-0x7d50930f irq 80,81 on simplebus2
>>> pcib0: hardware identifies as revision 0x304.
>>> pci1:  on pcib0
>>> pcib1:  irq 91 at device 0.

Re: Jetson Nano BSP

[Alan Cudmore]

Hi all,

On Thu, Feb 23, 2023 at 4:00 PM Karel Gardas 
wrote:

>
> Hi Prakhar,
>
> On 2/23/23 20:23, Prakhar Agrawal wrote:
> > I completely agree with all your points, but my rationale for
> > introducing the jetson nano or jetson AGX orin was because of their GPU
> > power.
>
> it's really nice what Nvidia achieved here, right? Unfortunately this
> GPU potential is fully locked up by binary driver NVidia provides only
> for selected number of platforms --- if not just for the only one:
> Linux. So very questionable how you would unlock that on RTEMS during
> the limited time of GSoC. Just see what Nouveau folks are doing:
> https://nouveau.freedesktop.org/ -- for years and they just barely got
> to 3D acceleration. Just clone their git repo, see number of patches,
> lines of code provided and number of people involved and I think you
> will get an idea how mamooth task this is...
>
> >
> > In the case of large hobby projects or maybe the initial days of a
> > startup(seed ones), a real-time system that can work with boards having
> > good GPU can do wonders.
> > For example, for an autonomous vehicle L2, L3 autonomy can be achieved
> > using a 60W Jetson AGX orin, hence if RTEMS support is added to the
> > board, it might help create an awesome system to handle all the critical
> > time constraints necessary for the vehicle and give it the ability to
> > coordinate a large number of concurrent activities.
>
> If you are interested in machine vision based on AI and robotics, why
> not to look around for more open-source friendly solution? Recently just
> found i.MX 8M Plus and their claimed 2.3 TOPS NPU. Certainly not that
> powerful like NVidia, but NXP is historically more friendly to 3rd party
> OSes. Not sure about NPU, have not had a time to investigate that yet,
> but perhaps you do?
>
> Also, with i.MX 8M Plus you still do have a chance to use AI Vision in
> non-real time manner running on top of Linux and run RTEMS real-time
> tasks on built in Cortex-M7 -- I mean if you decide that this particular
> BSP may be your GSoC. :-)
>
>
> https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-applications-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS
>
> >> Honestly I'd rather see a new BSP for a decent RISC-V board.
> >
> > I was reading about RISC-V and their comparison with ARM SBC and in one
> > blog I read this - "ARM processors have benefited from a lot more
> > research, funding, and development than RISC-V. This means that it can
> > be argued that RISC-V is being left behind"
>
> Do not worry about it. RISC-V is here and will stay. A lot was already
> invested into it and much more will still be...
>
> I'm working on submitting a RISC-V BSP variant for the Kendryte K210 CPU.
It's low cost and has a 1TOPS NPU. I don't think the NPU needs a binary
driver, and it typically is used with FreeRTOS or bare metal.
But I do like the idea of a dual CPU system where a linux/AI processor can
work with a RTOS based MCU for real time tasks.

Supply chain issues aside, I also am interested in the Pine64 0x64 and its
multiple RISC-V CPUs. I also have been watching the VisionFive 2, which has
a quad-core RISC-V CPU. The VisionFive 2 Linux support is still maturing,
but it does have OpenSBI U-boot, so it might be possible to load RTEMS
images over TFTP.
https://www.kickstarter.com/projects/starfive/visionfive-2
https://wiki.pine64.org/wiki/Ox64

For ARM based AI systems, what about the Beaglebone AI?
https://beagleboard.org/AI

But, maybe a GSOC sized project related to AI would be to integrate a
library such as tensorflow lite or TinyMAIX:
https://github.com/sipeed/TinyMaix
https://www.tensorflow.org/lite

They might work with the well supported RTEMS boards like the Beaglebone
black.

Regards,
Alan


> Karel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New RISC-V BSP variant (Kendryte K210)

[Alan Cudmore]

On Thu, Dec 1, 2022 at 6:06 PM Joel Sherrill  wrote:
>
> I'm going to say enthusiastically yes.
>
> I suspect that other boards will be very similar so this is likely a good 
> basis to go from.
>
> If you have links where it is actually for sale and not just described, that 
> would be great.
Seeed Studio:
https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-RISC-V-AI-IoT-p-4047.html?queryID=86b62e47589a0b56236a5c29ab704818&objectID=4047&indexName=bazaar_retailer_products
They have a number of other boards and modules, but most have not been
in stock for a while. I'm not sure if it's a supply chain problem like
the Raspberry Pi, or they are no longer available.
Also here:
https://www.dfrobot.com/product-1985.html
https://www.dfrobot.com/product-1972.html
Boards and modules are also available on Aliexpress.
>
> Chris would likely encourage you to post rtems-tester results. :)
I have been using the Rednode.io test framework. I'm currently running
a dozen tests, but I would like to try using rtems-tester.

>
> And perhaps we can reach out and let them know RTEMS is available on their 
> hardware. Chris might enjoy poking that bear. lol
I'm sure they would not mind. There are ports of rt-thread, nuttx, and
no-mmu linux to the SoC. Kendrtye offers a bare metal SDK with the
Apache 2.0 license:
https://github.com/kendryte/kendryte-standalone-sdk
They did have a FreeRTOS SDK, but it is no longer maintained:
https://github.com/kendryte/kendryte-freertos-sdk
I don't think there are any binary blobs needed, and an RTEMS image
can just be flashed to the boards using a "kflash.py" utility that is
available through pip, so getting started is easy: Just build RTEMS
images and either run on renode or flash via USB cable.

Alan

>
> On Thu, Dec 1, 2022, 1:46 PM Alan Cudmore  wrote:
>>
>> Hi,
>> I have been working on a basic BSP for the Kendryte K210 RISC-V CPU,
>> and I was wondering if the community members would like me to submit
>> it.
>> The Kendryte K210 is a dual core 64 bit RISC-V processor with a wealth
>> of peripheral I/O, a built-in AI NPU, and 8 Megabytes of on-chip SRAM.
>> I like it because it is one of the lowest cost RISC-V CPUs available,
>> and it appears to run RTEMS well.
>> In addition, my BSP works on the K210 model on the renode.io
>> simulator. I believe it would work on QEMU, but it is very close to
>> the rv64imafdc_medany riscv BSP variant.
>> The changes consist of:
>> - A new riscv/riscv variant and associated build option files
>> - A new DTB header, since the DTB is included in the BSP similar to
>> the polarfire BSP
>> - Some code to detect the frequency in bspstart.c
>> - A new header file for the k210
>> Because the console uses the same sifive uart as the frdme310arty BSP,
>> I factored that out so the Sifive UART can be used in multiple BSP
>> variants. It is able to use the existing timer and interrupt code.
>>
>> In addition to the renode.io simulator, I have run it on the following 
>> boards:
>> - Sipeed MAIX Bit
>> - Sipeed MAIXduino (arduino form factor board with ESP32)
>> - Sipeed Grove AI hat for Raspberry Pi
>>
>> Potential negatives:
>> - I do not have a BSD licensed device tree source, I created the
>> device tree binary from the u-boot distribution. Is it OK to just
>> include the device tree binary (similar to the microblaze)?
>> - The availability of these boards has not been as good for the last
>> year or so, but you can still find them at a relatively low cost. The
>> Sipeed company seems to be focusing on another low cost RISC-V SoC,
>> which is very interesting as well: The Bouffalo Lab BL808 (example
>> here:
>> https://wiki.pine64.org/wiki/Ox64)
>>
>> Is this worth submitting? I don't want to clutter up the tree with
>> devices that may become obsolete - we could focus on the upcoming
>> round of low cost RISC-V SoCs like the BL808.
>> I don't have a specific application I am using it for, but I used it
>> as a very inexpensive way to learn RISC-V on a real board. It may be
>> of some value to integrate additional peripheral support including the
>> AI NPU.
>>
>> If anyone is interested, I can submit the patches or even provide a
>> branch on github.
>>
>> Thanks,
>> Alan
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

New RISC-V BSP variant (Kendryte K210)

[Alan Cudmore]

Hi,
I have been working on a basic BSP for the Kendryte K210 RISC-V CPU,
and I was wondering if the community members would like me to submit
it.
The Kendryte K210 is a dual core 64 bit RISC-V processor with a wealth
of peripheral I/O, a built-in AI NPU, and 8 Megabytes of on-chip SRAM.
I like it because it is one of the lowest cost RISC-V CPUs available,
and it appears to run RTEMS well.
In addition, my BSP works on the K210 model on the renode.io
simulator. I believe it would work on QEMU, but it is very close to
the rv64imafdc_medany riscv BSP variant.
The changes consist of:
- A new riscv/riscv variant and associated build option files
- A new DTB header, since the DTB is included in the BSP similar to
the polarfire BSP
- Some code to detect the frequency in bspstart.c
- A new header file for the k210
Because the console uses the same sifive uart as the frdme310arty BSP,
I factored that out so the Sifive UART can be used in multiple BSP
variants. It is able to use the existing timer and interrupt code.

In addition to the renode.io simulator, I have run it on the following boards:
- Sipeed MAIX Bit
- Sipeed MAIXduino (arduino form factor board with ESP32)
- Sipeed Grove AI hat for Raspberry Pi

Potential negatives:
- I do not have a BSD licensed device tree source, I created the
device tree binary from the u-boot distribution. Is it OK to just
include the device tree binary (similar to the microblaze)?
- The availability of these boards has not been as good for the last
year or so, but you can still find them at a relatively low cost. The
Sipeed company seems to be focusing on another low cost RISC-V SoC,
which is very interesting as well: The Bouffalo Lab BL808 (example
here:
https://wiki.pine64.org/wiki/Ox64)

Is this worth submitting? I don't want to clutter up the tree with
devices that may become obsolete - we could focus on the upcoming
round of low cost RISC-V SoCs like the BL808.
I don't have a specific application I am using it for, but I used it
as a very inexpensive way to learn RISC-V on a real board. It may be
of some value to integrate additional peripheral support including the
AI NPU.

If anyone is interested, I can submit the patches or even provide a
branch on github.

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Is it possible to use cFS without a file system?

[Alan Cudmore]

Hi Frank,The cFS uses files for:Loading individual applications. The current build system can link all applications with the cFE core and the OS image avoiding the need for dynamic loading.The cFE Executive Services startup scriptTable service filesAnd as you mention, any cFS application that uses filesThere are some commands and APIs that will not work without a file system such as loading a new application from a file system or dumping a log to a file.The cFE Executive Services also creates a RAM disk upon startup. So, I think modifications will be necessary to use cFS without a file system, but all file system calls go through the OS Abstraction Layer so the cFS does not depend on the host OS file system API. Because of this, a file abstraction could be created that is simple enough for qualification but still allows the cFS to operate as designed. An example is the “EEPROM File System” or EEFS which has been used to boot cFS systems:https://github.com/nasa/eefsThe EEFS has an older RTEMS file system interface, but in your use case, the OSAL would call the EEFS standalone API directly. Note that this public release has not been updated in quite a while. Regards,Alan From: Frank KühndelSent: Thursday, November 24, 2022 5:08 AMTo: devel@rtems.orgSubject: Is it possible to use cFS without a file system? Hello, the core Flight System (cFS) is a software platform created by NASA (https://cfs.gsfc.nasa.gov/). It provides essential onboard services for space missions. I would like to use cFS on top of an RTEMS qualified for space by ESA (https://rtems-qual.io.esa.int/). Yet, this qualified RTEMS has no file system. cFS can be configured to be used without IP-networking and with static loader only but I have not found any configuration to disable the file system. Does anyone know whether it is possible to use cFS without a file system or can give advice on using cFS without file system? Of course without file system all applications accessing files will not work. Yet, would at least the core services (such as Executive Service (ES), Software Bus Service (SB), Event Service (EVS), Table Service (TBL), and Time Service (TIME)) be functioning? Greetings and ThanksFrank -- embedded brains GmbHHerr Frank KÜHNDELDornierstr. 482178 PuchheimGermanyemail: frank.kuehn...@embedded-brains.dephone:  +49-89-18 94 741 - 23mobile: +49-176-15 22 06 - 11fax:    +49-89-18 94 741 - 08 Registergericht: Amtsgericht MünchenRegisternummer: HRB 157899Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas DörflerUnsere Datenschutzerklärung finden Sie hier:https://embedded-brains.de/datenschutzerklaerung/  ___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Question about SMP tests after shutdown

[Alan Cudmore]

Hi,
I am running testsuite applications on a dual core RISC-V CPU. When I
run samples such as ticker.exe, the test ends without error messages.
On SMP tests, the tests seem to run correctly and end, but there is
always a fatal error from thread(s) on the other CPU.
(RTEMS_FATAL_SOURCE_SMP)
My guess is that the threads are being scheduled after the primary
test thread shut down the RTEMS executive, causing the error to be
caught. Is this expected behavior on a SMP system?
There are a couple of BSPs that implement a fatal error handler to
catch this error, and I would expect that on a real application, it
would be handled appropriately.
The error I get from smp08 is below.
Thanks,
Alan

*** END OF TEST SMP 8 ***

[ RTEMS shutdown ]
CPU: 1
RTEMS version: 6.0.0.1eae6f24fec6c3ab00d8f5d0152d2a5b57ea4589
RTEMS tools: 12.2.1 20221014 (RTEMS 6, RSB
e24641bda7412277c3e6490b663a12aceb093dec, Newlib 0b6342c)
executing thread ID: 0x0a010002
executing thread name: TA01

*** FATAL ***
fatal source: 10 (RTEMS_FATAL_SOURCE_SMP)
CPU: 0
fatal code: 5 (0x0005)
RTEMS version: 6.0.0.1eae6f24fec6c3ab00d8f5d0152d2a5b57ea4589
RTEMS tools: 12.2.1 20221014 (RTEMS 6, RSB
e24641bda7412277c3e6490b663a12aceb093dec, Newlib 0b6342c)
executing thread ID: 0x09010001
executing thread name: IDLE
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Microblaze 2nd timer interrupt

[Alan Cudmore]

Hi Sam,You need to add the timer.h file to the list of files to be installed:https://git.rtems.org/rtems/tree/spec/build/bsps/microblaze/microblaze_fpga/obj.yml#n14Alan From: Sam PriceSent: Sunday, November 6, 2022 12:52 AMTo: DevelopmentSubject: Re: Microblaze 2nd timer interrupt I pushed my changes to rtems sourcehttps://github.com/RTEMS/rtems/compare/master...thesamprice:rtems:timer_debug and setup a hello world an example project to test withhttps://github.com/thesamprice/rtems_mb_timer/blob/main/hello.c However im getting the following error.rtems_mb_timer/hello.c:8:10: fatal error: bsp/timer.h: No such file or directory    8 | #include   |  ^ Is the correct approach to just put all bsp specific calls in bsp.h?  On Sat, Nov 5, 2022 at 10:04 PM Sam Price  wrote:> > The current microblaze design only has a single timer.> > I want to use the 2nd timer on the microblaze to run some low level tasks.> > Wondering if someone could see if i'm on the right track.> > > Regarding the timer from the Xilinx api api> > """The interrupt service routine reads the timer control/status> registers to determine the source of the interrupt."""> > Also there is a interrupt controller on microblaze that has a single> jump register.> > > So the underlying logic is interrupt occurs, 32bit interrupt register> is checked for what bits are set determining what interrupts have> occured.> > > if bit 0 is set then it is a clock interrupt.> > > Then 2 clock register need checked for what timer caused the interrupt.> > > Current RTEMS implementation only uses 1 of the timers.> > > > > > I added static ISR callbacks for the system and user callback at the> top of the mb clock.c file.> > static rtems_interrupt_handler mblaze_clock_isr = 0x0;> > static rtems_interrupt_handler mblaze_user_isr = 0x0;> > > > I added a callback that checks both registers and calls the> appropriate callback.> > > > static void microblaze_clock_handler( void * data){> >   volatile Microblaze_Timer *timer = _Microblaze_Timer;> >   if ( ( timer->tcsr0 & MICROBLAZE_TIMER_TCSR0_T0INT ) == 0 )> >   {> > if(mblaze_clock_isr != 0x0){> >   mblaze_clock_isr(data);> > }> >   }> >   if ( ( timer->tcsr1 & MICROBLAZE_TIMER_TCSR0_T0INT ) == 0 )> >   {> > if(mblaze_user_isr != 0x0){> >   mblaze_user_isr(data);> >   /* Clear the interrupt */> >   timer->tcsr1 |= MICROBLAZE_TIMER_TCSR0_T0INT;> > }> >   }> > }> > > > > > I updated the ISR register to store the system clock, and replace the> isr callback with mine.> > > > static void microblaze_clock_handler_install( rtems_interrupt_handler isr )> > {> >   rtems_status_code sc = RTEMS_SUCCESSFUL;> >   mblaze_clock_isr = isr; <- Store the system ISR> >   sc = rtems_interrupt_handler_install(> > 0,> > "Clock",> > RTEMS_INTERRUPT_UNIQUE,> > microblaze_clock_handler, <- Changed from ISR to my new handler.> > NULL> >   );> > > >   if ( sc != RTEMS_SUCCESSFUL ) {> > bsp_fatal( MICROBLAZE_FATAL_CLOCK_IRQ_INSTALL );> >   }> > }> > > > To the microblaze bsp.h> > > im adding my callback functions to register the users clock function.> > void microblaze_user_clock_handler_install(rtems_interrupt_handler isr);> > > And the appropriate non static function to the mb clock.c file> > void microblaze_user_clock_handler_install(rtems_interrupt_handler isr){> mblaze_user_isr = isr;> }> > Anyhow about to compile and see if it works.   -- Sincerely, Sam Price___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] user: Add openSUSE host details

[Alan Cudmore]

This patch adds details on the packages needed for the RTEMS
source builder on openSUSE Leap 15.4 64 bit. The commands
were tested on a new install with the RTEMS source builder
master branch.
---
 user/hosts/posix.rst | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
index 9769e07..d263247 100644
--- a/user/hosts/posix.rst
+++ b/user/hosts/posix.rst
@@ -179,8 +179,19 @@ than the usual zlib-dev):
 openSUSE
 
 
-This has been reported to work but no instructions were provided. This is an
-opportunity to contribute. Please submit any guidance you can provide.
+The RTEMS Source Builder has been tested on openSUSE Leap 15.4 64bit.
+Starting with a clean install with source repositories enabled, the following
+zypper command installs the required packages:
+
+.. code-block:: none
+
+   # sudo zypper in -t pattern devel_C_C++ devel_python3
+
+In addition, the following command can set python3 as the default python 
interpreter:
+
+.. code-block:: none
+
+   # sudo update-alternatives --install /usr/bin/python python 
/usr/bin/python3 1
 
 .. _FreeBSD:
 
-- 
2.34.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ping on ticket 4728 + patch

[Alan Cudmore]

On Fri, Oct 28, 2022 at 8:07 AM Sebastian Huber
 wrote:
>
> On 22/10/2022 17:36, Alan Cudmore wrote:
> > On Thu, Oct 20, 2022 at 11:23 PM Alan Cudmore  
> > wrote:
> >> On Thu, Oct 20, 2022 at 2:13 AM Sebastian Huber
> >>   wrote:
> >>>
> >>>
> >>> On 20/10/2022 03:48, Alan Cudmore wrote:
> >>>> On Wed, Oct 19, 2022 at 12:24 AM Sebastian Huber
> >>>>   wrote:
> >>>>> On 18/10/2022 21:02, Alan Cudmore wrote:
> >>>>>> *From: *Sebastian Huber<mailto:sebastian.hu...@embedded-brains.de>
> >>>>>> *Sent: *Tuesday, October 18, 2022 11:15 AM
> >>>>>> *To: *Alan Cudmore<mailto:alan.cudm...@gmail.com>;j...@rtems.org
> >>>>>> <mailto:j...@rtems.org>
> >>>>>> *Cc: *rtems-de...@rtems.org<mailto:devel@rtems.org>
> >>>>>> *Subject: *Re: Ping on ticket 4728 + patch
> >>>>>>
> >>>>>> On 18/10/2022 16:36, Alan Cudmore wrote:
> >>>>>>
> >>>>>>> On Tue, Oct 18, 2022 at 9:55 AM Joel Sherrill   
> >>>>>> wrote:
> >>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>>> On Tue, Oct 18, 2022 at 8:44 AM Alan
> >>>>>> Cudmore   wrote:
> >>>>>>
> >>>>>>>>> The log does have the error, and I get it when building by hand 
> >>>>>> too:
> >>>>>>
> >>>>>>>>> start.o: in function `.L0 ':
> >>>>>>
> >>>>>>>>>
> >>>>>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5c):
> >>>>>>
> >>>>>>>>> relocation truncated to fit: R_RISCV_GPREL_I against symbol
> >>>>>>
> >>>>>>>>> `bsp_section_bss_size' defined in*ABS*  section in
> >>>>>>
> >>>>>>>>>
> >>>>>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
> >>>>>>
> >>>>>>>>> collect2: error: ld returned 1 exit status
> >>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>>> Hmmm.. that's weird. You should never get a truncation error 
> >>>>>> linking
> >>>>>> minimum.exe.
> >>>>>>
> >>>>>>>> It should always fit within the BSP's memory and not have any 
> >>>>>> issues
> >>>>>> with branches
> >>>>>>
> >>>>>>>> or calls needing fixup.
> >>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>>> Unless the wrong type of branch/jump/call instruction is used at
> >>>>>> start.S:86, I have
> >>>>>>
> >>>>>>>> no idea.If it's a form that assumes a short distance to the
> >>>>>> destination but is going
> >>>>>>
> >>>>>>>> to a symbol outside start.S and thus could be further.
> >>>>>>
> >>>>>>> Also, 6 of the samples such as hello.exe link without error.
> >>>>>>
> >>>>>>> The rv32imafdc BSP variant does not have CPU_CFLAGS.
> >>>>>>
> >>>>>>> rv32imafd links fine and has specific CPU_CFLAGS, rv32imafdc does 
> >>>>>> not
> >>>>>>
> >>>>>>> have the flags.
> >>>>>>
> >>>>>>> (I'll research the gcc defaults and architecture differences 
> >>>>>> next..)
> >>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>> I get a similar error on the frdme310arty BSP but only on a 
> >>>>>> specific
> >>>>>>
> >>>>>>> POSIX testsuite executable:
> >>>>>>
> >

RE: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader

[Alan Cudmore]

I agree – I am working on a riscv BSP variant (Sipeed MAIX Bit with K210 CPU) where the RTEMS image can be flashed directly to the board and boots without a bootloader.I was also wondering if the statement “Each variant corresponds to a GCC multilib” is still accurate as BSP variants such as the FE310Arty and Microchip Polarfire are added?Thanks,AlanFrom: heshamelmat...@gmail.comSent: Tuesday, October 25, 2022 1:48 PMTo: devel@rtems.orgSubject: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader From: Hesham Almatary  The BSP is capable of initialising the hardware being the first softwarethat takes control on hardware reset (after the bootrom). For instance,using on QEMU's  virt platforms, RTEMS runs as a bios without BBL.Similarily, RTEMS can also be run on harware/FPGA and loaded usingGDB; the bootrom (or a GDB script) should just set the a0/a1 registerswith the boot HART ID and DTB address respectively.--- user/bsps/bsps-riscv.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rstindex 48e7ee7..224506d 100644--- a/user/bsps/bsps-riscv.rst+++ b/user/bsps/bsps-riscv.rst@@ -43,9 +43,7 @@ This BSP offers 15 variants: Each variant corresponds to a GCC multilib.  A particular variant reflects an ISA with ABI and code model choice. -The basic hardware initialization is not performed by the BSP.  A boot loader-with device tree support must be used to start the BSP, e.g. BBL.  The BSP must-be started im machine mode.+The BSP must be started im machine mode.  The reference platform for this BSP is the Qemu `virt` machine. -- 2.25.1 ___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ping on ticket 4728 + patch

[Alan Cudmore]

On Thu, Oct 20, 2022 at 11:23 PM Alan Cudmore  wrote:
>
> On Thu, Oct 20, 2022 at 2:13 AM Sebastian Huber
>  wrote:
> >
> >
> >
> > On 20/10/2022 03:48, Alan Cudmore wrote:
> > > On Wed, Oct 19, 2022 at 12:24 AM Sebastian Huber
> > >  wrote:
> > >>
> > >> On 18/10/2022 21:02, Alan Cudmore wrote:
> > >>> *From: *Sebastian Huber <mailto:sebastian.hu...@embedded-brains.de>
> > >>> *Sent: *Tuesday, October 18, 2022 11:15 AM
> > >>> *To: *Alan Cudmore <mailto:alan.cudm...@gmail.com>; j...@rtems.org
> > >>> <mailto:j...@rtems.org>
> > >>> *Cc: *rtems-de...@rtems.org <mailto:devel@rtems.org>
> > >>> *Subject: *Re: Ping on ticket 4728 + patch
> > >>>
> > >>> On 18/10/2022 16:36, Alan Cudmore wrote:
> > >>>
> > >>>   > On Tue, Oct 18, 2022 at 9:55 AM Joel Sherrill  
> > >>> wrote:
> > >>>
> > >>>   >>
> > >>>
> > >>>   >>
> > >>>
> > >>>   >> On Tue, Oct 18, 2022 at 8:44 AM Alan
> > >>> Cudmore  wrote:
> > >>>
> > >>>   >>> The log does have the error, and I get it when building by hand 
> > >>> too:
> > >>>
> > >>>   >>> start.o: in function `.L0 ':
> > >>>
> > >>>   >>>
> > >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5c):
> > >>>
> > >>>   >>> relocation truncated to fit: R_RISCV_GPREL_I against symbol
> > >>>
> > >>>   >>> `bsp_section_bss_size' defined in*ABS*  section in
> > >>>
> > >>>   >>>
> > >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
> > >>>
> > >>>   >>> collect2: error: ld returned 1 exit status
> > >>>
> > >>>   >>
> > >>>
> > >>>   >>
> > >>>
> > >>>   >> Hmmm.. that's weird. You should never get a truncation error 
> > >>> linking
> > >>> minimum.exe.
> > >>>
> > >>>   >> It should always fit within the BSP's memory and not have any 
> > >>> issues
> > >>> with branches
> > >>>
> > >>>   >> or calls needing fixup.
> > >>>
> > >>>   >>
> > >>>
> > >>>   >> Unless the wrong type of branch/jump/call instruction is used at
> > >>> start.S:86, I have
> > >>>
> > >>>   >> no idea.If it's a form that assumes a short distance to the
> > >>> destination but is going
> > >>>
> > >>>   >> to a symbol outside start.S and thus could be further.
> > >>>
> > >>>   > Also, 6 of the samples such as hello.exe link without error.
> > >>>
> > >>>   > The rv32imafdc BSP variant does not have CPU_CFLAGS.
> > >>>
> > >>>   > rv32imafd links fine and has specific CPU_CFLAGS, rv32imafdc does 
> > >>> not
> > >>>
> > >>>   > have the flags.
> > >>>
> > >>>   > (I'll research the gcc defaults and architecture differences next..)
> > >>>
> > >>>   >
> > >>>
> > >>>   > I get a similar error on the frdme310arty BSP but only on a specific
> > >>>
> > >>>   > POSIX testsuite executable:
> > >>>
> > >>>   >
> > >>>
> > >>>   > start.o: in function `.L0 ':
> > >>>
> > >>>   >
> > >>>
> > >>>   >
> > >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x28):
> > >>>
> > >>>   > relocation truncated to fit: R_RISCV_GPREL_I against symbol
> > >>>
> > >>>   > `bsp_section_bss_size' defined in*ABS*  section in
> > >>>
> > >>>   >
> > >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
> >

Re: Ping on ticket 4728 + patch

[Alan Cudmore]

On Thu, Oct 20, 2022 at 2:13 AM Sebastian Huber
 wrote:
>
>
>
> On 20/10/2022 03:48, Alan Cudmore wrote:
> > On Wed, Oct 19, 2022 at 12:24 AM Sebastian Huber
> >  wrote:
> >>
> >> On 18/10/2022 21:02, Alan Cudmore wrote:
> >>> *From: *Sebastian Huber <mailto:sebastian.hu...@embedded-brains.de>
> >>> *Sent: *Tuesday, October 18, 2022 11:15 AM
> >>> *To: *Alan Cudmore <mailto:alan.cudm...@gmail.com>; j...@rtems.org
> >>> <mailto:j...@rtems.org>
> >>> *Cc: *rtems-de...@rtems.org <mailto:devel@rtems.org>
> >>> *Subject: *Re: Ping on ticket 4728 + patch
> >>>
> >>> On 18/10/2022 16:36, Alan Cudmore wrote:
> >>>
> >>>   > On Tue, Oct 18, 2022 at 9:55 AM Joel Sherrill  wrote:
> >>>
> >>>   >>
> >>>
> >>>   >>
> >>>
> >>>   >> On Tue, Oct 18, 2022 at 8:44 AM Alan
> >>> Cudmore  wrote:
> >>>
> >>>   >>> The log does have the error, and I get it when building by hand too:
> >>>
> >>>   >>> start.o: in function `.L0 ':
> >>>
> >>>   >>>
> >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5c):
> >>>
> >>>   >>> relocation truncated to fit: R_RISCV_GPREL_I against symbol
> >>>
> >>>   >>> `bsp_section_bss_size' defined in*ABS*  section in
> >>>
> >>>   >>>
> >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
> >>>
> >>>   >>> collect2: error: ld returned 1 exit status
> >>>
> >>>   >>
> >>>
> >>>   >>
> >>>
> >>>   >> Hmmm.. that's weird. You should never get a truncation error linking
> >>> minimum.exe.
> >>>
> >>>   >> It should always fit within the BSP's memory and not have any issues
> >>> with branches
> >>>
> >>>   >> or calls needing fixup.
> >>>
> >>>   >>
> >>>
> >>>   >> Unless the wrong type of branch/jump/call instruction is used at
> >>> start.S:86, I have
> >>>
> >>>   >> no idea.If it's a form that assumes a short distance to the
> >>> destination but is going
> >>>
> >>>   >> to a symbol outside start.S and thus could be further.
> >>>
> >>>   > Also, 6 of the samples such as hello.exe link without error.
> >>>
> >>>   > The rv32imafdc BSP variant does not have CPU_CFLAGS.
> >>>
> >>>   > rv32imafd links fine and has specific CPU_CFLAGS, rv32imafdc does not
> >>>
> >>>   > have the flags.
> >>>
> >>>   > (I'll research the gcc defaults and architecture differences next..)
> >>>
> >>>   >
> >>>
> >>>   > I get a similar error on the frdme310arty BSP but only on a specific
> >>>
> >>>   > POSIX testsuite executable:
> >>>
> >>>   >
> >>>
> >>>   > start.o: in function `.L0 ':
> >>>
> >>>   >
> >>>
> >>>   >
> >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x28):
> >>>
> >>>   > relocation truncated to fit: R_RISCV_GPREL_I against symbol
> >>>
> >>>   > `bsp_section_bss_size' defined in*ABS*  section in
> >>>
> >>>   >
> >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
> >>>
> >>>   >
> >>>
> >>>   > collect2: error: ld returned 1 exit status
> >>>
> >>> My off hand guess is that this is a tool chain issue on certain host
> >>>
> >>> systems. For example, I never got this error on our OpenSUSE machines.
> >>>
> >>> I can set up a OpenSUSE virtual machine and try it. I noticed the RSB
> >>> documentation does not have a set of packages for OpenSUSE – I could
> >>> send a docs patch after a successful build. What release do you use? Do
> >>> you have a

Re: Ping on ticket 4728 + patch

[Alan Cudmore]

On Wed, Oct 19, 2022 at 12:24 AM Sebastian Huber
 wrote:
>
> On 18/10/2022 21:02, Alan Cudmore wrote:
> > *From: *Sebastian Huber <mailto:sebastian.hu...@embedded-brains.de>
> > *Sent: *Tuesday, October 18, 2022 11:15 AM
> > *To: *Alan Cudmore <mailto:alan.cudm...@gmail.com>; j...@rtems.org
> > <mailto:j...@rtems.org>
> > *Cc: *rtems-de...@rtems.org <mailto:devel@rtems.org>
> > *Subject: *Re: Ping on ticket 4728 + patch
> >
> > On 18/10/2022 16:36, Alan Cudmore wrote:
> >
> >  > On Tue, Oct 18, 2022 at 9:55 AM Joel Sherrill  wrote:
> >
> >  >>
> >
> >  >>
> >
> >  >> On Tue, Oct 18, 2022 at 8:44 AM Alan
> > Cudmore  wrote:
> >
> >  >>> The log does have the error, and I get it when building by hand too:
> >
> >  >>> start.o: in function `.L0 ':
> >
> >  >>>
> > /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5c):
> >
> >  >>> relocation truncated to fit: R_RISCV_GPREL_I against symbol
> >
> >  >>> `bsp_section_bss_size' defined in*ABS*  section in
> >
> >  >>>
> > /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
> >
> >  >>> collect2: error: ld returned 1 exit status
> >
> >  >>
> >
> >  >>
> >
> >  >> Hmmm.. that's weird. You should never get a truncation error linking
> > minimum.exe.
> >
> >  >> It should always fit within the BSP's memory and not have any issues
> > with branches
> >
> >  >> or calls needing fixup.
> >
> >  >>
> >
> >  >> Unless the wrong type of branch/jump/call instruction is used at
> > start.S:86, I have
> >
> >  >> no idea.If it's a form that assumes a short distance to the
> > destination but is going
> >
> >  >> to a symbol outside start.S and thus could be further.
> >
> >  > Also, 6 of the samples such as hello.exe link without error.
> >
> >  > The rv32imafdc BSP variant does not have CPU_CFLAGS.
> >
> >  > rv32imafd links fine and has specific CPU_CFLAGS, rv32imafdc does not
> >
> >  > have the flags.
> >
> >  > (I'll research the gcc defaults and architecture differences next..)
> >
> >  >
> >
> >  > I get a similar error on the frdme310arty BSP but only on a specific
> >
> >  > POSIX testsuite executable:
> >
> >  >
> >
> >  > start.o: in function `.L0 ':
> >
> >  >
> >
> >  >
> > /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x28):
> >
> >  > relocation truncated to fit: R_RISCV_GPREL_I against symbol
> >
> >  > `bsp_section_bss_size' defined in*ABS*  section in
> >
> >  >
> > /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
> >
> >  >
> >
> >  > collect2: error: ld returned 1 exit status
> >
> > My off hand guess is that this is a tool chain issue on certain host
> >
> > systems. For example, I never got this error on our OpenSUSE machines.
> >
> > I can set up a OpenSUSE virtual machine and try it. I noticed the RSB
> > documentation does not have a set of packages for OpenSUSE – I could
> > send a docs patch after a successful build. What release do you use? Do
> > you have a list of packages to install?
>
> We use openSUSE Leap 15.3 and 15.4. To get the packages maybe try this:
>
> zypper in -t pattern devel_C_C++ devel_python3

I was able to set up an openSUSE Leap 15.4 (64 bit) VM and the above
packages worked for the RSB build.
Unfortunately, I still get the same link error for minimum.exe. Do you
think this is a linker error? Is it worth trying a Clang build?

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Ping on ticket 4728 + patch

[Alan Cudmore]

  From: Sebastian HuberSent: Tuesday, October 18, 2022 11:15 AMTo: Alan Cudmore; j...@rtems.orgCc: rtems-de...@rtems.orgSubject: Re: Ping on ticket 4728 + patch On 18/10/2022 16:36, Alan Cudmore wrote:> On Tue, Oct 18, 2022 at 9:55 AM Joel Sherrill  wrote:>> >> >> On Tue, Oct 18, 2022 at 8:44 AM Alan Cudmore  wrote:>>> The log does have the error, and I get it when building by hand too:>>> start.o: in function `.L0 ':>>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5c):>>> relocation truncated to fit: R_RISCV_GPREL_I against symbol>>> `bsp_section_bss_size' defined in*ABS*  section in>>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/testsuites/samples/minimum.exe>>> collect2: error: ld returned 1 exit status>> >> >> Hmmm.. that's weird. You should never get a truncation error linking minimum.exe.>> It should always fit within the BSP's memory and not have any issues with branches>> or calls needing fixup.>> >> Unless the wrong type of branch/jump/call instruction is used at start.S:86, I have>> no idea.If it's a form that assumes a short distance to the destination but is going>> to a symbol outside start.S and thus could be further.> Also, 6 of the samples such as hello.exe link without error.> The rv32imafdc BSP variant does not have CPU_CFLAGS.> rv32imafd links fine and has specific CPU_CFLAGS, rv32imafdc does not> have the flags.> (I'll research the gcc defaults and architecture differences next..)> > I get a similar error on the frdme310arty BSP but only on a specific> POSIX testsuite executable:> > start.o: in function `.L0 ':> > /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x28):> relocation truncated to fit: R_RISCV_GPREL_I against symbol> `bsp_section_bss_size' defined in*ABS*  section in> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe> > collect2: error: ld returned 1 exit status My off hand guess is that this is a tool chain issue on certain host systems. For example, I never got this error on our OpenSUSE machines. I can set up a OpenSUSE virtual machine and try it. I noticed the RSB documentation does not have a set of packages for OpenSUSE – I could send a docs patch after a successful build. What release do you use? Do you have a list of packages to install? Alan  -- embedded brains GmbHHerr Sebastian HUBERDornierstr. 482178 PuchheimGermanyemail: sebastian.hu...@embedded-brains.dephone: +49-89-18 94 741 - 16fax:   +49-89-18 94 741 - 08 Registergericht: Amtsgericht MünchenRegisternummer: HRB 157899Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas DörflerUnsere Datenschutzerklärung finden Sie hier:https://embedded-brains.de/datenschutzerklaerung/ 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ping on ticket 4728 + patch

[Alan Cudmore]

On Tue, Oct 18, 2022 at 9:55 AM Joel Sherrill  wrote:
>
>
>
> On Tue, Oct 18, 2022 at 8:44 AM Alan Cudmore  wrote:
>>
>> The log does have the error, and I get it when building by hand too:
>> start.o: in function `.L0 ':
>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5c):
>> relocation truncated to fit: R_RISCV_GPREL_I against symbol
>> `bsp_section_bss_size' defined in *ABS* section in
>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
>> collect2: error: ld returned 1 exit status
>
>
>
> Hmmm.. that's weird. You should never get a truncation error linking 
> minimum.exe.
> It should always fit within the BSP's memory and not have any issues with 
> branches
> or calls needing fixup.
>
> Unless the wrong type of branch/jump/call instruction is used at start.S:86, 
> I have
> no idea.If it's a form that assumes a short distance to the destination but 
> is going
> to a symbol outside start.S and thus could be further.

Also, 6 of the samples such as hello.exe link without error.
The rv32imafdc BSP variant does not have CPU_CFLAGS.
rv32imafd links fine and has specific CPU_CFLAGS, rv32imafdc does not
have the flags.
(I'll research the gcc defaults and architecture differences next..)

I get a similar error on the frdme310arty BSP but only on a specific
POSIX testsuite executable:

start.o: in function `.L0 ':

/home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x28):
relocation truncated to fit: R_RISCV_GPREL_I against symbol
`bsp_section_bss_size' defined in *ABS* section in
/home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe

collect2: error: ld returned 1 exit status



>
> --joel
>
>>
>>
>> On Mon, Oct 17, 2022 at 10:43 PM Chris Johns  wrote:
>> >
>> > On 18/10/2022 1:13 pm, Joel Sherrill wrote:
>> > > On Sun, Oct 16, 2022 at 9:32 AM Alan Cudmore > > > <mailto:alan.cudm...@gmail.com>> wrote:
>> > >
>> > > On Fri, Oct 14, 2022 at 9:19 AM Joel Sherrill > > > <mailto:j...@rtems.org>> wrote:
>> > > >
>> > > > Pushed. Thanks for pinging. It does help.
>> > > >
>> > > > Since you are looking at the riscv BSPs, could you look at the four
>> > > > BSP build failures reported here:
>> > > >
>> > > > https://lists.rtems.org/pipermail/build/2022-September/036496.html
>> > > <https://lists.rtems.org/pipermail/build/2022-September/036496.html>
>> > > >
>> > > > I think they are all variants so one fix (maybe repeated) should 
>> > > do it.
>> > > > The reported message isn't much help:
>> > > >
>> > > >1 smp riscv/rv32iac build:
>> > > >   configure: /home/tester/rtems-cron-6/rtems/waf configure\
>> > > >   --prefix=/home/tester/rtems-cron-6/tools/6/bsps 
>> > > --top=/home/tester\
>> > > >   /rtems-cron-6/rtems 
>> > > --rtems-config=config-riscv-rv32iac-smp.ini
>> > > >  error: ld/collect2:0 error: no error message found!
>> > > >
>> > >
>> > > I ran the bsp builder on the riscv BSPs with an updated toolchain and
>> > > latest rtems master. I was able to reproduce only one of the failures
>> > > with the rv32imafdc SMP configuration:
>> > > Failures:
>> > >1 smp riscv/rv32imafdc build:
>> > >   configure: /home/alan/rtems/test-build/rtems/waf configure\
>> > >   --prefix=/home/alan/rtems/test-build/bsps\
>> > >   --top=/home/alan/rtems/test-build/rtems 
>> > > --rtems-config=config-riscv-\
>> > >   rv32imafdc-smp.ini
>> > >  error: ld/collect2:0 error: no error message found!
>> > >
>> > > Average BSP Build Time: 0:00:26.253927
>> > > Total Time 1:04:45.581263
>> > > Passes: 147   Failures: 1
>> > >
>> > > This is the detail from the log:
>> > > [1424/1437] Compiling ../../../rtems/testsuites/samples/nsecs/init.c
>> > > start.o: in function `.L0 ':
>> > > 
>> > > /home/alan/rtems/test-build/rtems/build/riscv/rv32imafdc/../../../

Re: Ping on ticket 4728 + patch

[Alan Cudmore]

The log does have the error, and I get it when building by hand too:
start.o: in function `.L0 ':
/home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5c):
relocation truncated to fit: R_RISCV_GPREL_I against symbol
`bsp_section_bss_size' defined in *ABS* section in
/home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
collect2: error: ld returned 1 exit status

On Mon, Oct 17, 2022 at 10:43 PM Chris Johns  wrote:
>
> On 18/10/2022 1:13 pm, Joel Sherrill wrote:
> > On Sun, Oct 16, 2022 at 9:32 AM Alan Cudmore  > <mailto:alan.cudm...@gmail.com>> wrote:
> >
> > On Fri, Oct 14, 2022 at 9:19 AM Joel Sherrill  > <mailto:j...@rtems.org>> wrote:
> > >
> > > Pushed. Thanks for pinging. It does help.
> > >
> > > Since you are looking at the riscv BSPs, could you look at the four
> > > BSP build failures reported here:
> > >
> > > https://lists.rtems.org/pipermail/build/2022-September/036496.html
> > <https://lists.rtems.org/pipermail/build/2022-September/036496.html>
> > >
> > > I think they are all variants so one fix (maybe repeated) should do 
> > it.
> > > The reported message isn't much help:
> > >
> > >1 smp riscv/rv32iac build:
> > >   configure: /home/tester/rtems-cron-6/rtems/waf configure\
> > >   --prefix=/home/tester/rtems-cron-6/tools/6/bsps 
> > --top=/home/tester\
> > >   /rtems-cron-6/rtems --rtems-config=config-riscv-rv32iac-smp.ini
> > >  error: ld/collect2:0 error: no error message found!
> > >
> >
> > I ran the bsp builder on the riscv BSPs with an updated toolchain and
> > latest rtems master. I was able to reproduce only one of the failures
> > with the rv32imafdc SMP configuration:
> > Failures:
> >1 smp riscv/rv32imafdc build:
> >   configure: /home/alan/rtems/test-build/rtems/waf configure\
> >   --prefix=/home/alan/rtems/test-build/bsps\
> >   --top=/home/alan/rtems/test-build/rtems 
> > --rtems-config=config-riscv-\
> >   rv32imafdc-smp.ini
> >  error: ld/collect2:0 error: no error message found!
> >
> > Average BSP Build Time: 0:00:26.253927
> > Total Time 1:04:45.581263
> > Passes: 147   Failures: 1
> >
> > This is the detail from the log:
> > [1424/1437] Compiling ../../../rtems/testsuites/samples/nsecs/init.c
> > start.o: in function `.L0 ':
> > 
> > /home/alan/rtems/test-build/rtems/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5
> > c): relocation truncated to fit: R_RISCV_GPREL_I against symbol
> > `bsp_section_bss_size' defined in *ABS* section in /home/
> > 
> > alan/rtems/test-build/rtems/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
> > collect2: error: ld returned 1 exit status
> >
> > This seems to be similar to the error I get when I try to build the
> > frdme310arty BSP with the testsuite and posix enabled:
> > [4152/4326] Compiling testsuites/validation/tr-sem-surrender.c
> > start.o: in function `.L0 ':
> > 
> > /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_te
> > xt+0x28): relocation truncated to fit: R_RISCV_GPREL_I against symbol
> > `bsp_section_bss_size' defined in *ABS* section in
> > 
> > /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
> > collect2: error: ld returned 1 exit status
> >
> > I need to investigate this more.
> >
> >
> > There are two issues.
> >
> > (1) The test in question does not fit on this target and needs to be 
> > disabled.
> >
> > (2) Somewhere there is parsing of this output which may be able to be more 
> > helpful.
> >
> > Chris... any pointers on (2)? Can the output of bsp builder be improved?
>
> 1) There should be a log of all the build details. Check in that for the 
> error.
>
> 2) Can you build it by hand and see the error?
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ping on ticket 4728 + patch

[Alan Cudmore]

On Fri, Oct 14, 2022 at 9:19 AM Joel Sherrill  wrote:
>
> Pushed. Thanks for pinging. It does help.
>
> Since you are looking at the riscv BSPs, could you look at the four
> BSP build failures reported here:
>
> https://lists.rtems.org/pipermail/build/2022-September/036496.html
>
> I think they are all variants so one fix (maybe repeated) should do it.
> The reported message isn't much help:
>
>1 smp riscv/rv32iac build:
>   configure: /home/tester/rtems-cron-6/rtems/waf configure\
>   --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
>   /rtems-cron-6/rtems --rtems-config=config-riscv-rv32iac-smp.ini
>  error: ld/collect2:0 error: no error message found!
>

I ran the bsp builder on the riscv BSPs with an updated toolchain and
latest rtems master. I was able to reproduce only one of the failures
with the rv32imafdc SMP configuration:
Failures:
   1 smp riscv/rv32imafdc build:
  configure: /home/alan/rtems/test-build/rtems/waf configure\
  --prefix=/home/alan/rtems/test-build/bsps\
  --top=/home/alan/rtems/test-build/rtems --rtems-config=config-riscv-\
  rv32imafdc-smp.ini
 error: ld/collect2:0 error: no error message found!

Average BSP Build Time: 0:00:26.253927
Total Time 1:04:45.581263
Passes: 147   Failures: 1

This is the detail from the log:
[1424/1437] Compiling ../../../rtems/testsuites/samples/nsecs/init.c
start.o: in function `.L0 ':
/home/alan/rtems/test-build/rtems/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5
c): relocation truncated to fit: R_RISCV_GPREL_I against symbol
`bsp_section_bss_size' defined in *ABS* section in /home/
alan/rtems/test-build/rtems/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
collect2: error: ld returned 1 exit status

This seems to be similar to the error I get when I try to build the
frdme310arty BSP with the testsuite and posix enabled:
[4152/4326] Compiling testsuites/validation/tr-sem-surrender.c
start.o: in function `.L0 ':
/home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_te
xt+0x28): relocation truncated to fit: R_RISCV_GPREL_I against symbol
`bsp_section_bss_size' defined in *ABS* section in
/home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
collect2: error: ld returned 1 exit status

I need to investigate this more.

> It might be nothing more than a test which doesn't fit in some section
> but I have no idea beyond that they are all noted as SMP. Chris may be
> helpful decoding the precise configuration.
>
> --joel
>
> On Thu, Oct 13, 2022 at 8:27 PM Alan Cudmore  wrote:
>>
>> Hi,
>> Sorry, I did not set a message subject in my previous email.
>>
>> Ping on this patch. I built all of the riscv/riscv BSPs that use it.
>> It works for the generic riscv/qemu BSP, the PolarFire BSP, and the
>> RISC-V BSP I am working on where the macro failed.
>> https://lists.rtems.org/pipermail/devel/2022-September/073390.html
>>
>> Thanks,
>> Alan
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ping on ticket 4728 + patch

[Alan Cudmore]

I'll check it out - I will need to set up my host to duplicate the
same tester builds.
I also noticed a build failure in the frdme310arty BSP variant when
building all tests with POSIX enabled:

[4152/4326] Compiling testsuites/validation/tc-sem-flush.c
start.o: in function `.L0 ':
/home/alan/rtems/rtems-k210-port/rtems-clean/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x28):
relocation truncated to fit: R_RISCV_GPREL_I against symbol
`bsp_section_bss_size' defined in *ABS* section in
/home/alan/rtems/rtems-k210-port/rtems-clean/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
collect2: error: ld returned 1 exit status

Waf: Leaving directory
`/home/alan/rtems/rtems-k210-port/rtems-clean/build/riscv/frdme310arty'
Build failed
 -> task in 'testsuites/validation/ts-validation-io-kernel.exe' failed
with exit status 1 (run with -v to display more information)

On Fri, Oct 14, 2022 at 9:19 AM Joel Sherrill  wrote:
>
> Pushed. Thanks for pinging. It does help.
>
> Since you are looking at the riscv BSPs, could you look at the four
> BSP build failures reported here:
>
> https://lists.rtems.org/pipermail/build/2022-September/036496.html
>
> I think they are all variants so one fix (maybe repeated) should do it.
> The reported message isn't much help:
>
>1 smp riscv/rv32iac build:
>   configure: /home/tester/rtems-cron-6/rtems/waf configure\
>   --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
>   /rtems-cron-6/rtems --rtems-config=config-riscv-rv32iac-smp.ini
>  error: ld/collect2:0 error: no error message found!
>
> It might be nothing more than a test which doesn't fit in some section
> but I have no idea beyond that they are all noted as SMP. Chris may be
> helpful decoding the precise configuration.
>
> --joel
>
> On Thu, Oct 13, 2022 at 8:27 PM Alan Cudmore  wrote:
>>
>> Hi,
>> Sorry, I did not set a message subject in my previous email.
>>
>> Ping on this patch. I built all of the riscv/riscv BSPs that use it.
>> It works for the generic riscv/qemu BSP, the PolarFire BSP, and the
>> RISC-V BSP I am working on where the macro failed.
>> https://lists.rtems.org/pipermail/devel/2022-September/073390.html
>>
>> Thanks,
>> Alan
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Ping on ticket 4728 + patch

[Alan Cudmore]

Hi,
Sorry, I did not set a message subject in my previous email.

Ping on this patch. I built all of the riscv/riscv BSPs that use it.
It works for the generic riscv/qemu BSP, the PolarFire BSP, and the
RISC-V BSP I am working on where the macro failed.
https://lists.rtems.org/pipermail/devel/2022-September/073390.html

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[no subject]

[Alan Cudmore]

Ping on this patch. I built all of the riscv/riscv BSPs that use it.
It works for the generic riscv/qemu BSP, the PolarFire BSP, and the
RISC-V BSP I am working on where the macro failed.
https://lists.rtems.org/pipermail/devel/2022-September/073390.html

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Visibility of RISCV_BOOT_HARTID

[Alan Cudmore]

Hi Joel,This is relevant to my interests since I am working on a RISC-V BSP variant and I am adding a few options in the spec/build/bsps/riscv/riscv directory.Could this instance be fixed by moving it to the spec/build/bsps/riscv directory?Regards,AlanFrom: Joel SherrillSent: Wednesday, October 12, 2022 10:36 AMTo: rtems-de...@rtems.orgSubject: Visibility of RISCV_BOOT_HARTID Hi I was looking at the bsp default settings for sparc/leon3 to show someone and noticed this which is out of place.  # boot hartid (processor number) of risc-v cpu (default 0)RISCV_BOOT_HARTID = 0 I looked around and see it is an architecture specific ini setting but placed in a directory with architecture independent settings. We don't appear to have any other examples of a cpukit option that is architecture specific. So it is lumped in with all the architecture independent ini settings. We had long discussions about presenting these options with better names, documentation, etc as part of the waf transition. Seems unfortunate to have this show up in all configurations. Any thoughts on how to clean this up? Thanks. --joel   
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps: Improve riscv console FDT parsing

[Alan Cudmore]

Ping for this RISC-V console fix - it builds without error on 310ARTY,
Polarfire, and generic RISCV variants. I tested it on the generic QEMU
riscv platform and Padmarao tested it on the PolarFire.
Thanks,
Alan

On Thu, Sep 29, 2022 at 12:12 PM Alan Cudmore 
wrote:

> This fixes a problem with parsing the FDT compatible property by
> replacing the RISCV_CONSOLE_IS_COMPATIBLE macro with calls to
> the fdt_stringlist_contains function. The macro only works when
> the compatible FDT entry is a single string and not a list of
> strings. The new call will compare each item in the string list.
>
> Close #4728.
> ---
>  bsps/riscv/riscv/console/console-config.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/bsps/riscv/riscv/console/console-config.c
> b/bsps/riscv/riscv/console/console-config.c
> index d962a5a418..7908c2f325 100644
> --- a/bsps/riscv/riscv/console/console-config.c
> +++ b/bsps/riscv/riscv/console/console-config.c
> @@ -139,10 +139,6 @@ static void riscv_console_set_reg_32(uintptr_t addr,
> uint8_t i, uint8_t val)
>  }
>  #endif
>
> -#define RISCV_CONSOLE_IS_COMPATIBLE(actual, actual_len, desired) \
> -  (actual_len == sizeof(desired) \
> - && memcmp(actual, desired, sizeof(desired) - 1) == 0)
> -
>  static void riscv_console_probe(void)
>  {
>const void *fdt;
> @@ -170,7 +166,7 @@ static void riscv_console_probe(void)
>  }
>
>  #if RISCV_ENABLE_HTIF_SUPPORT != 0
> -if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ucb,htif0")) {
> +if (fdt_stringlist_contains(compat, compat_len, "ucb,htif0")) {
>htif_console_context_init(&htif_console_instance.base, node);
>
>riscv_console.context = &htif_console_instance.base;
> @@ -181,8 +177,8 @@ static void riscv_console_probe(void)
>
>  #if RISCV_CONSOLE_MAX_NS16550_DEVICES > 0
>  if (
> -  (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16550a")
> -  || RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16750"))
> +(fdt_stringlist_contains(compat, compat_len, "ns16550a")
> +|| fdt_stringlist_contains(compat, compat_len, "ns16750"))
>  && ns16550_devices < RISCV_CONSOLE_MAX_NS16550_DEVICES
>  ) {
>ns16550_context *ctx;
> @@ -203,7 +199,7 @@ static void riscv_console_probe(void)
>  ctx->set_reg = riscv_console_set_reg_8;
>}
>
> -  if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16750")) {
> +  if (fdt_stringlist_contains(compat, compat_len, "ns16750")) {
>  ctx->has_precision_clock_synthesizer = true;
>}
>
> @@ -243,7 +239,7 @@ static void riscv_console_probe(void)
>  #endif
>
>  #if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> -if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "sifive,uart0")) {
> +if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0")) {
>fe310_uart_context *ctx;
>
>ctx = &fe310_uart_instance;
> --
> 2.34.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] bsp/aarch64: Add new Raspberry Pi 4B BSP

[Alan Cudmore]

The merged BSP works for me, and I have the cFS bundle (
https://github.com/nasa/cfs) running on my Pi4.
What is the best way to support the ethernet, rtems-libbsd? It looks like
FreeBSD supports the Pi4 ethernet device. Any pointers to how libbsd
integration works for a RTEMS BSP?

On Wed, Oct 5, 2022 at 12:55 AM Noor Aman  wrote:

> I have sent the documentations earlier, Although reviews are required.
> I'll reply to that patch to bring it up on the devel.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] user/bsps: Update riscv for PolarFire SoC

[Alan Cudmore]

Hi Padmarao,
The docs look good to me. I have a couple of minor comments inline.
I'm really glad to see this BSP in RTEMS.
Thanks,
Alan

On Wed, Sep 28, 2022 at 4:07 PM Padmarao Begari <
padmarao.beg...@microchip.com> wrote:

> Update the riscv documentation for the Microchip PolarFire SoC
> BSP variant including information about SMP test procedure
> for the Microchip PolarFire Icicle Kit.
> ---
>  user/bsps/bsps-riscv.rst | 114 ++-
>  1 file changed, 113 insertions(+), 1 deletion(-)
>
> diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
> index 5faa87b..be65a68 100644
> --- a/user/bsps/bsps-riscv.rst
> +++ b/user/bsps/bsps-riscv.rst
> @@ -8,7 +8,7 @@ riscv (RISC-V)
>  riscv
>  =
>
> -This BSP offers 13 variants:
> +This BSP offers 15 variants:
>
>  * rv32i
>
> @@ -38,6 +38,8 @@ This BSP offers 13 variants:
>
>  * frdme310arty
>
> +* mpfs64imafdc
> +
>  Each variant corresponds to a GCC multilib.  A particular variant
> reflects an
>  ISA with ABI and code model choice.
>
> @@ -47,6 +49,9 @@ be started im machine mode.
>
>  The reference platform for this BSP is the Qemu `virt` machine.
>
> +The reference platform for the mpfs64imafdc BSP variant is the Microchip
> +PolarFire SoC Icicle Kit.
> +
>  Build Configuration Options
>  ---
>
> @@ -94,6 +99,13 @@ configuration INI file. The ``waf`` defaults can be
> used to inspect the values.
>   Enables support sifive Freedom E310 Arty board if defined to a
> non-zero
>   value,otherwise it is disabled (disabled by default)
>
> +``RISCV_ENABLE_MPFS_SUPPORT``
> + Enables support Microchip PolarFire 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.
> +
>  Interrupt Controller
>  
>
> @@ -124,6 +136,106 @@ They are initialized according to the device tree.
> The console driver does not
>  configure the pins or peripheral clocks.  The console device is selected
>  according to the device tree "/chosen/stdout-path" property value.
>
> +Microchip PolarFire SoC
> +---
> +
> +The PolarFire SoC is the 4x 64-bit RISC-V U54 cores and a 64-bit RISC-V
> +E51 monitor core SoC from the Microchip.
> +
> +The ``mpfs64imafdc`` BSP variant supports the U54 cores not the E51
> because
> +the E51 monitor core is reserved for first stage bootloader
> +(Hart Software Services) and default ``RISCV_BOOT_HARTID`` is 1.
>
I would suggest "... BSP variant supports the U54 cores but not the E51
because the E51 monitor core is reserved for the first stage bootloader
(Hart Software Services). In order to boot from the first U54 core,
``RISCV_BOOT_HARTID`` is set to 1 by default.

> +
> +**SMP test procedure for the Microchip PolarFire Icicle Kit:**
> +
> +The "config.ini" file.
> +
> +.. code-block:: none
> +
> +[riscv/mpfs64imafdc]
> +BUILD_TESTS = True
> +RTEMS_POSIX_API=True
> +RTEMS_SMP = True
> +BSP_START_COPY_FDT_FROM_U_BOOT=False
> +BSP_VERBOSE_FATAL_EXTENSION = False
> +
> +Build RTEMS.
> +
> +.. code-block:: shell
> +
> +$ ./waf configure --prefix=$HOME/rtems-start/rtems/6
> +$ ./waf
> +
> +Convert .exe to .elf file.
> +
> +.. code-block:: shell
> +
> +$ riscv-rtems6-objcopy
> build/riscv/mpfs64imafdc/testsuites/smptests/smp01.exe
> build/riscv/mpfs64imafdc/testsuites/smptests/smp01.elf
>
I believe the .exe file is already .elf, so the file can be renamed or used
as is. Probably OK to leave this since it makes it clear that the elf file
format is needed for the next step.

Also, is it worth mentioning that the DTB is embedded in the BSP rather
than loaded from the eMMC/SD card?

> +
> +Generate a payload for the `smp01.elf` using the `hss-payload-generator <
> https://github.com/polarfire-soc/hart-software-services/blob/master/tools/hss-payload-generator
> >`_.
> +
> +* Copy `smp01.elf` file to the HSS/tools/hss-payload-generator/test
> directory.
> +
> +* Go to hss-payload-generator source directory.
> +
> +.. code-block:: shell
> +
> +$ cd hart-software-services/tools/hss-payload-generator
> +
> +* Edit test/uboot.yaml file for the hart entry points and correct name of
> the
> +  binary file.
> +
> +.. code-block:: none
> +
> +set-name: 'PolarFire-SoC-HSS::RTEMS'
> +hart-entry-points: {u54_1: '0x10', u54_2: '0x10',
> u54_3: '0x10', u54_4: '0x10'}
> +payloads:
> + test/smp01.elf: {exec-addr: '0x10', owner-hart: u54_1,
> secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4,
> priv-mode: prv_m, skip-opensbi: true}
> +
> +* Generate payload
> +
> +.. code-block:: shell
> +
> +$ ./hss-payload-generator -c test/uboot.yaml payload.bin
> +
> +Once the payload binary is generated, it should be copied to the eMMC/SD.
> +
> +`FPGA design with HSS programming file <
> https://github.com/polarfire-soc/polarfire-so

Re: [PATCH rtems-docs v2] raspberrypi4.rst: Added Documentation for the new AArch64 Raspberry pi 4B BSP

[Alan Cudmore]

Hi Noor,
Looks good and builds for me - I have a few minor comments. Please see
inline comments below.
Thanks,
Alan

On Wed, Oct 5, 2022 at 1:41 AM Mohd Noor Aman 
wrote:

> This patch adds the relevant documentations required for booting the new
> BSP.
> JTAG support is added for debugging. I have built the HTML docs and
> verified
> them.
> ---
>  user/bsps/aarch64/raspberrypi4.rst | 99 ++
>  user/bsps/bsps-aarch64.rst |  1 +
>  2 files changed, 100 insertions(+)
>  create mode 100644 user/bsps/aarch64/raspberrypi4.rst
>
> diff --git a/user/bsps/aarch64/raspberrypi4.rst
> b/user/bsps/aarch64/raspberrypi4.rst
> new file mode 100644
> index 000..5a45c65
> --- /dev/null
> +++ b/user/bsps/aarch64/raspberrypi4.rst
> @@ -0,0 +1,99 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2022 Mohd Noor Aman
> +
> +.. _BSP_aarch64_Raspberrypi_4:
> +
> +Raspberry Pi 4B
> +===
> +
> +The 'raspberrypi4b' BSP currently supports only the LP64 ABI. ILP32 is
> not

+supported. Raspberry pi 4B all variants and Raspberry Pi 400  are
> supported. The
> +default bootloader which is used by the Raspbian OS or other OS can be
> used to
> +boot the RTEMS. Currently, QEMU emulation is not supported.
>
I would change "boot the RTEMS" to "boot RTEMS"
Is the RPI4 supported in QEMU? If not, then I would remove that sentence.
Should you mention that SMP is currently not supported, or is that going to
be easy enough to add in the future?

> +
> +Clock Driver
> +
> +
> +The clock driver uses the `ARM Generic Timer`.
> +
>
Which interrupt controller is used? GIC or legacy Raspberry Pi? Worth
putting that here?


> +Console Driver
> +--
> +
> +Raspberry pi 4B has 2 types of UARTs, ARM PL011 and Mini-uart. The PL011
> is a
> +capable, broadly 16550-compatible UART, while the mini UART has a reduced
> +feature set. The console driver supports the default Qemu emulated ARM
> PL011
> +PrimeCell UART as well as the physical ARM PL011 PrimeCell UART in the
> +raspberrypi hardware. Mini-uart is not supported.
> +
> +Preparing to boot
> +--
> +
> +Raspberry Pi uses a different mechanism to boot. First the GPU
> initializes,
> +loads the bootloader and then looks for the kernel img. By default the
> arm64
> +mode looks for the ``kernel8.img``. Any other kernel can be loaded by
> adding
> +`kernel=` to the ``config.txt``.
>
I would change the last line to: "to the config.txt file"
Also, some instances of config.txt are highlighted, but others are not. Do
you want to make them all the same?

> +
> +The Firmware files are required in order to boot RTEMS. The latest
> firmware can
> +be downloaded from the `Raspberry Pi Firmware Repository
> +`_. USB boot is supported. All
> the
> +files (Firmwares and kernel) must be place in the FAT32 partition only.
> Add
> +``arm_64bit=1`` in the config.txt file in order to boot the BSP in 64bit
> kernel
> +mode.

I am still using the Arm Trusted Firmware bl31.bin to boot RTEMS. If that
is still required, that should be added here.

>
> +
> +
> +UART Setup
> +^^
> +
> +Connect your serial device to the GPIO15 and GPIO14. Add the following to
> the
> +config.txt file in order to use the PL011 UART0 and thus disabling the
> default
> +Mini-uart.
> +
> +.. code-block:: none
> +
> +  dtoverlay = disable-bt
> +  enable_uart=1
> +
> +.. note::
> +  The Raspberry Pi 4B and 400 have an additional four PL011 UARTs. They
> are not
> +  supported.
> +
> +Generating kernel image
> +^^^
> +
> +The following steps show how to run ``hello.exe`` on the BSP. Other
> executables
> +can be processed in a similar way.
> +
> +To create the kernel image:
> +
> +.. code-block:: shell
> +
> +  $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel8.img
> +
> +Copy the kernel image to the SD card.
> +
> +JTAG Setup
> +--
> +
> +The Raspberry Pi 4 doesn't have dedicated JTAG pins. Instead, you must
> configure
> +the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The RPi
> 4
> +documentation refers to this as Alt4 functions of those pins. Alt5 does
> exist
> +too, which goes from GPIO4, 5, 6, 12 and 13. you can check this out from
> +`pinout.xyz `_ or `eLinux
> +`_
> +
> +One more thing to note on JTAG with Raspberry pi 4B is that, by default,
> All the
> +GPIO pins are pulled down, according to the `BCM2711 documentation
> +`_.
> This
> +wasn't the case in the earlier models. So in order to let the data flow
> freely,
> +we will have to disable them.
> +
> +.. code-block:: none
> +
> +  # Disable pull downs
> +  gpio=22-27=np
> +
> +  # Enable jtag pins (i.e. GPIO22-GPIO27)
> +  enable_jtag_gpio=1
> +
> +
> diff --git a/user/bsps/bsps-aarch64.rst b/user/bsps/bsps-aarch64.rst
> index 933370f..

Re: [PATCH v3] bsp/aarch64: Add new Raspberry Pi 4B BSP

[Alan Cudmore]

 the above copyright
>>>> + *notice, this list of conditions and the following disclaimer.
>>>> + * 2. Redistributions in binary form must reproduce the above copyright
>>>> + *notice, this list of conditions and the following disclaimer in
>>>> the
>>>> + *documentation and/or other materials provided with the
>>>> distribution.
>>>> + *
>>>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>>> "AS IS"
>>>> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>>>> TO, THE
>>>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>>>> PURPOSE
>>>> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
>>>> CONTRIBUTORS BE
>>>> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>>>> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>>>> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>>>> BUSINESS
>>>> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
>>>> WHETHER IN
>>>> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>>>> OTHERWISE)
>>>> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
>>>> OF THE
>>>> + * POSSIBILITY OF SUCH DAMAGE.
>>>> + */
>>>> +
>>>> +#ifndef LIBBSP_AARCH64_RASPBERRYPI_4_BSP_H
>>>> +#define LIBBSP_AARCH64_RASPBERRYPI_4_BSP_H
>>>> +
>>>> +/**
>>>> + * @addtogroup RTEMSBSPsAArch64
>>>> + *
>>>> + * @{
>>>> + */
>>>> +
>>>> +#include 
>>>> +
>>>> +#ifndef ASM
>>>> +
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#include 
>>>> +
>>>> +/*Raspberry pi MMU initialization */
>>>> +BSP_START_TEXT_SECTION void raspberrypi_4_setup_mmu_and_cache(void);
>>>> +
>>>> +#ifdef __cplusplus
>>>> +extern "C" {
>>>> +#endif /* __cplusplus */
>>>> +
>>>> +#define BSP_ARM_GIC_CPUIF_BASE 0xFF842000
>>>> +#define BSP_ARM_GIC_DIST_BASE 0xFF841000
>>>> +
>>>> +#define BSP_RPI4_PL011_BASE 0xFE201000
>>>> +#define BSP_RPI4_PL011_LENGTH 0x200
>>>> +
>>>> +#ifdef __cplusplus
>>>> +}
>>>> +#endif /* __cplusplus */
>>>> +
>>>> +#endif /* ASM */
>>>> +
>>>> +/** @} */
>>>> +
>>>> +#endif /* LIBBSP_AARCH64_RASPBERRYPI_4_BSP_H */
>>>> diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h
>>>> b/bsps/aarch64/raspberrypi/include/bsp/irq.h
>>>> new file mode 100644
>>>> index 00..effec1b040
>>>> --- /dev/null
>>>> +++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
>>>> @@ -0,0 +1,109 @@
>>>> +/**
>>>> + * @file
>>>> + *
>>>> + * @ingroup raspberrypi_interrupt
>>>> + *
>>>> + * @brief Interrupt definitions.
>>>> + */
>>>> +
>>>> +/**
>>>> + * Copyright (c) 2013 Alan Cudmore
>>>> + * Copyright (c) 2022 Mohd Noor Aman
>>>> + *
>>>> + *  The license and distribution terms for this file may be
>>>> + *  found in the file LICENSE in this distribution or at
>>>> + *
>>>> + *  http://www.rtems.org/license/LICENSE
>>>> + *
>>>> + */
>>>> +
>>>> +#ifndef LIBBSP_ARM_RASPBERRYPI_IRQ_H
>>>> +#define LIBBSP_ARM_RASPBERRYPI_IRQ_H
>>>> +
>>>> +#ifndef ASM
>>>> +
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#if defined(RTEMS_SMP)
>>>> +#include 
>>>> +#endif
>>>> +
>>>> +/**
>>>> + * @defgroup raspberrypi_interrupt Interrrupt Support
>>>> + *
>>>> + * @ingroup RTEMSBSPsARMRaspberryPi
>>>> + *
>>>> + * @brief Interrupt support.
>>>> + */
>>>> +
>>>> +#define BCM2835_INTC_TOTAL_IRQ   (64 + 8)
>>>> +
>>>> +#define BCM2835_IRQ_SET1_MIN 0
>>>> +#define BCM2835_IRQ_SET2_MIN 32
>>>> +
>>>> +#define BCM2835_IRQ_ID_GPU_TIMER_M0  0
>

RE: [PATCH] bsps: Improve riscv console FDT parsing

[Alan Cudmore]

Hi Padmarao,Could you try this patch on your Polarfire board? It works on the generic QEMU BSP and the BSP I am working on which uses the FRDME310ARTY/SiFive UART. It builds with the Polarfire BSP, but I am not able to test it. I downloaded and built QEMU that has Polarfire support, but I need to download and install SoftConsole to get the rest of the parts I need to prepare the binary.Thanks!Alan  From: Alan CudmoreSent: Thursday, September 29, 2022 12:12 PMTo: devel@rtems.orgCc: Alan CudmoreSubject: [PATCH] bsps: Improve riscv console FDT parsing This fixes a problem with parsing the FDT compatible property byreplacing the RISCV_CONSOLE_IS_COMPATIBLE macro with calls tothe fdt_stringlist_contains function. The macro only works whenthe compatible FDT entry is a single string and not a list ofstrings. The new call will compare each item in the string list. Close #4728.--- bsps/riscv/riscv/console/console-config.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/bsps/riscv/riscv/console/console-config.c b/bsps/riscv/riscv/console/console-config.cindex d962a5a418..7908c2f325 100644--- a/bsps/riscv/riscv/console/console-config.c+++ b/bsps/riscv/riscv/console/console-config.c@@ -139,10 +139,6 @@ static void riscv_console_set_reg_32(uintptr_t addr, uint8_t i, uint8_t val) } #endif -#define RISCV_CONSOLE_IS_COMPATIBLE(actual, actual_len, desired) \-  (actual_len == sizeof(desired) \- && memcmp(actual, desired, sizeof(desired) - 1) == 0)- static void riscv_console_probe(void) {   const void *fdt;@@ -170,7 +166,7 @@ static void riscv_console_probe(void) }  #if RISCV_ENABLE_HTIF_SUPPORT != 0-    if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ucb,htif0")) {+    if (fdt_stringlist_contains(compat, compat_len, "ucb,htif0")) {   htif_console_context_init(&htif_console_instance.base, node);    riscv_console.context = &htif_console_instance.base;@@ -181,8 +177,8 @@ static void riscv_console_probe(void)  #if RISCV_CONSOLE_MAX_NS16550_DEVICES > 0 if (-  (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16550a")-  || RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16750"))+    (fdt_stringlist_contains(compat, compat_len, "ns16550a")+    || fdt_stringlist_contains(compat, compat_len, "ns16750")) && ns16550_devices < RISCV_CONSOLE_MAX_NS16550_DEVICES ) {   ns16550_context *ctx;@@ -203,7 +199,7 @@ static void riscv_console_probe(void) ctx->set_reg = riscv_console_set_reg_8;   } -  if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16750")) {+  if (fdt_stringlist_contains(compat, compat_len, "ns16750")) { ctx->has_precision_clock_synthesizer = true;   } @@ -243,7 +239,7 @@ static void riscv_console_probe(void) #endif  #if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0-    if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "sifive,uart0")) {+    if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0")) {   fe310_uart_context *ctx;    ctx = &fe310_uart_instance;-- 2.34.1  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsps: Improve riscv console FDT parsing

[Alan Cudmore]

This fixes a problem with parsing the FDT compatible property by
replacing the RISCV_CONSOLE_IS_COMPATIBLE macro with calls to
the fdt_stringlist_contains function. The macro only works when
the compatible FDT entry is a single string and not a list of
strings. The new call will compare each item in the string list.

Close #4728.
---
 bsps/riscv/riscv/console/console-config.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/bsps/riscv/riscv/console/console-config.c 
b/bsps/riscv/riscv/console/console-config.c
index d962a5a418..7908c2f325 100644
--- a/bsps/riscv/riscv/console/console-config.c
+++ b/bsps/riscv/riscv/console/console-config.c
@@ -139,10 +139,6 @@ static void riscv_console_set_reg_32(uintptr_t addr, 
uint8_t i, uint8_t val)
 }
 #endif
 
-#define RISCV_CONSOLE_IS_COMPATIBLE(actual, actual_len, desired) \
-  (actual_len == sizeof(desired) \
- && memcmp(actual, desired, sizeof(desired) - 1) == 0)
-
 static void riscv_console_probe(void)
 {
   const void *fdt;
@@ -170,7 +166,7 @@ static void riscv_console_probe(void)
 }
 
 #if RISCV_ENABLE_HTIF_SUPPORT != 0
-if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ucb,htif0")) {
+if (fdt_stringlist_contains(compat, compat_len, "ucb,htif0")) {
   htif_console_context_init(&htif_console_instance.base, node);
 
   riscv_console.context = &htif_console_instance.base;
@@ -181,8 +177,8 @@ static void riscv_console_probe(void)
 
 #if RISCV_CONSOLE_MAX_NS16550_DEVICES > 0
 if (
-  (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16550a")
-  || RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16750"))
+(fdt_stringlist_contains(compat, compat_len, "ns16550a")
+|| fdt_stringlist_contains(compat, compat_len, "ns16750"))
 && ns16550_devices < RISCV_CONSOLE_MAX_NS16550_DEVICES
 ) {
   ns16550_context *ctx;
@@ -203,7 +199,7 @@ static void riscv_console_probe(void)
 ctx->set_reg = riscv_console_set_reg_8;
   }
 
-  if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16750")) {
+  if (fdt_stringlist_contains(compat, compat_len, "ns16750")) {
 ctx->has_precision_clock_synthesizer = true;
   }
 
@@ -243,7 +239,7 @@ static void riscv_console_probe(void)
 #endif
 
 #if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
-if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "sifive,uart0")) {
+if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0")) {
   fe310_uart_context *ctx;
 
   ctx = &fe310_uart_instance;
-- 
2.34.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] bsp/aarch64: New entry for Raspberry pi 4B AArch64 BSP

[Alan Cudmore]

TY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +arm_pl011_context raspberrypi_4_context = {
> +  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("PL011"),
> +  .regs = (volatile pl011 *) BSP_RPI4_PL011_BASE,
> +  .initial_baud = 115200
> +};
> +
> +const console_device console_device_table[] = {
> +  {
> +.device_file = "/dev/ttyS0",
> +.probe = console_device_probe_default,
> +.handler = &arm_pl011_fns,
> +.context = &raspberrypi_4_context.base
> +  }
> +};
> +
> +const size_t console_device_count =
> RTEMS_ARRAY_SIZE(console_device_table);
> +
> +static void output_char( char c )
> +{
> +  arm_pl011_write_polled(&raspberrypi_4_context.base, c);
> +}
> +
> +BSP_output_char_function_type BSP_output_char = output_char;
> +
> +BSP_polling_getchar_function_type BSP_poll_char = NULL;
> diff --git a/bsps/aarch64/raspberrypi/include/bsp.h
> b/bsps/aarch64/raspberrypi/include/bsp.h
> new file mode 100644
> index 00..d94a0432d5
> --- /dev/null
> +++ b/bsps/aarch64/raspberrypi/include/bsp.h
> @@ -0,0 +1,73 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSBSPsAArch64Raspberrypi4
> + *
> + * @brief Core BSP definitions
> + */
> +
> +/*
> + * Copyright (C) 2022 Mohd Noor Aman
> + *
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef LIBBSP_AARCH64_RASPBERRYPI_4_BSP_H
> +#define LIBBSP_AARCH64_RASPBERRYPI_4_BSP_H
> +
> +/**
> + * @addtogroup RTEMSBSPsAArch64
> + *
> + * @{
> + */
> +
> +#include 
> +
> +#ifndef ASM
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif /* __cplusplus */
> +
> +#define BSP_ARM_GIC_CPUIF_BASE 0xFF842000
> +#define BSP_ARM_GIC_DIST_BASE 0xFF841000
> +
> +#define BSP_RPI4_PL011_BASE 0xFE201000
> +#define BSP_RPI4_PL011_LENGTH 0x200
> +
> +#ifdef __cplusplus
> +}
> +#endif /* __cplusplus */
> +
> +#endif /* ASM */
> +
> +/** @} */
> +
> +#endif /* LIBBSP_AARCH64_RASPBERRYPI_4_BSP_H */
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h
> b/bsps/aarch64/raspberrypi/include/bsp/irq.h
> new file mode 100644
> index 00..effec1b040
> --- /dev/null
> +++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
> @@ -0,0 +1,109 @@
> +/**
> + * @file
> + *
> + * @ingroup raspberrypi_interrupt
> + *
> + * @brief Interrupt definitions.
> + */
> +
> +/**
> + * Copyright (c) 2013 Alan Cudmore
> + * Copyright (c) 2022 Mohd Noor Aman
> + *
> + *  The license and distribution terms for this file may be
> + *  found in the file LICENSE in this distribution or at
> + *
> + *  http://www.rtems.org/license/LICENSE
> + *
> + */
> +
> +#ifndef LIBBSP_ARM_RASPBERRYPI_IRQ_H
> +#define LIBBSP_ARM_RASPBERRYPI_IRQ_H
> +
> +#ifndef ASM
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if defined(RTEMS_SMP)
> +#include 
> +#endif
> +
> +/**
> + * @defgroup raspberrypi_interrupt Interrrupt Support
> + *
> + * @ingroup RTEM

RE: rtems-tester for raspberry pi 4B

[Alan Cudmore]

Hi Noor,The firmware issue that I am aware of is for the 32 bit arm/raspberrypi BSPs. I would expect that your Aarch64 BSP would work with the latest Raspberry Pi firmware. Are you talking about aarch64/raspberrypi or arm/raspberrypi?Alan From: Noor AmanSent: Sunday, September 25, 2022 3:53 AMTo: William Moore; Alan Cudmore; Hesham Moustafa; rtems-de...@rtems.orgSubject: rtems-tester for raspberry pi 4B Hey,Now that I have built a BSP, I wanted to run the rtems-tester for Raspberry Pi. But I'm confused on what to do now. The raspberry pi 2 bsp required u-boot in order to run the test which is understandable as rpi2 didnt had support for PXE boot, but the raspberry pi 4b has support for tftp boot but I'm unable to use it. Any ideas about how to do that? I would still like to know how u-boot was used for the earlier raspberry pi.  One thing more, once you said Current Raspberry Pi BSPs have problem with the firmware that we have not resolved. Once we are past a certain commit of the Raspberry Pi firmware, RTEMS will not boot. This has prevented me from booting RTEMS on the Raspberry Pi Zero 2 W (Quad core). I know your project is for the Pi 4, but it would be great if we could finally figure that out. because of this I was using old firmwares (1.20200601), but after I finished building BSP, I thought of booting from USB but newer firmware was required. So I tried the firmware-1.20220830 (latest) and it just worked. I tried some more releases and everything worked just fine. I'm just wondering what caused things to change.  Thanks,Noor 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Successful Hello world from RPi4B AArch64 over serial

[Alan Cudmore]

I built the TF-A binary, your dev branch, used the config.txt described below, and was able to run unlimited.exe. (I’m using a Pi4b 2GB)Great milestone!Alan From: Noor AmanSent: Monday, September 19, 2022 11:11 AMTo: William Moore; Alan Cudmore; Hesham Moustafa; rtems-de...@rtems.orgSubject: Successful Hello world from RPi4B AArch64 over serial Hey everyone, I've managed to get RTEMS6 on the Raspberry pi 4B rev 1.4. Every test ran fine except for minimum.exe, It gave a fatal error. Here's my setup for running RTEMS6 on RPi4B: TF-A is required to enable GIC on RPi. I had tried to use armstub-gic.S (https://github.com/raspberrypi/tools/blob/master/armstubs/armstub8.S) but it didn't work out. TF-A on other hand did work pretty well.  Steps to get TF-A binary are described here: https://trustedfirmware-a.readthedocs.io/en/latest/plat/rpi4.html Config.txt section:arm_64bit=1enable_uart=1gpio=22-27=npenable_jtag_gpio=1dtoverlay=disable-btkernel=kernel8.imgenable_gic=1armstub=bl31.bin RTEMS6 My branch (noov-dev): https://github.com/0xnoor/rtems/tree/noor-dev  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 0/4] Microchip PolarFire SoC support

[Alan Cudmore]

Hi Padmarao,
The patches apply cleanly and build for me. What is the recommended
config.ini file for this BSP?
I used:
[riscv/mpfs64imafdc]
BUILD_TESTS=True
RTEMS_POSIX_API=True
RTEMS_SMP=True
BSP_START_COPY_FDT_FROM_U_BOOT=False
BSP_DTB_IS_SUPPORTED=True
BSP_DTB_HEADER_PATH=bsp/mpfs-dtb.h

I don't have a Polarfire SoC board, but is there a QEMU platform to run
this on?

When this is in, I will rebase my k210 variant and eventually get it
submitted!
Thanks,
Alan

On Mon, Sep 19, 2022 at 9:00 AM Padmarao Begari <
padmarao.beg...@microchip.com> wrote:

> This patch set adds the Microchip PolarFire SoC BSP Variant
> support to RISC-V RTEMS.
>
> The PolarFire SoC is the 4x 64-bit RISC-V U54 cores and
> a 64-bit RISC-V E51 monitor core SoC from Microchip, more
> info available here:
> https://www.microchip.com/en-us/products/fpgas-and-plds/
> system-on-chip-fpgas/polarfire-soc-fpgas#Overview
>
> This new BSP variant is added for the 4x U54 cores not for E51
> because the E51 monitor core is resreved for first stage
> bootloader (Hart Software Services).
>
> The boot HARTID configurable is implemented for the riscv BSP
> to work with individual hart(cpu core) or SMP.
>
> This BSP support components: 4 CPU Cores (U54), Interrupt
> controller (PLIC), Timer (CLINT), UART (16550-compatible)
> work fine on actual Microchip PolarFire SoC Icicle Kit.
>
> v2:
> - Add a license and copyright information in dtb header file
> - Use RISCV_BOOT_HARDID instead of RTEMS_BOOT_HARDID
> - Add '_RISCV_Map_hardid_to_cpu_index()' and
> '_RISCV_Map_cpu_index_to_hardid()' functions
> - Change bsp_fdt_get() instead of bsp_fdt_copy() function for dtb
> - Move dtb and dtb header configurable build option to the bsps
>
> Padmarao Begari (4):
>   bsps/riscv: Add device tree blob
>   spec/build/bsps: Add dtb support
>   bsps/riscv: Add Microchip PolarFire SoC BSP variant
>   bsps/shared/: Use device tree blob
>
>  bsps/riscv/riscv/clock/clockdrv.c |   6 +-
>  bsps/riscv/riscv/config/mpfs64imafdc.cfg  |   9 +
>  bsps/riscv/riscv/dts/mpfs.dts | 365 +++
>  bsps/riscv/riscv/include/bsp/mpfs-dtb.h   | 602 ++
>  bsps/riscv/riscv/include/bsp/riscv.h  |  14 +
>  bsps/riscv/riscv/irq/irq.c|  81 +++
>  bsps/riscv/riscv/start/bsp_fatal_halt.c   |   3 +
>  bsps/riscv/riscv/start/bspsmp.c   |   2 +-
>  bsps/riscv/riscv/start/bspstart.c |  19 +-
>  bsps/riscv/shared/start/start.S   |   2 +
>  bsps/shared/start/bsp-fdt.c   |   8 +
>  .../score/cpu/riscv/include/rtems/score/cpu.h |   2 +-
>  .../cpu/riscv/include/rtems/score/cpuimpl.h   |   2 +-
>  spec/build/bsps/optdtb.yml|  19 +
>  spec/build/bsps/optdtbheaderpath.yml  |  20 +
>  spec/build/bsps/riscv/optextirqmax.yml|   5 +-
>  spec/build/bsps/riscv/optrambegin.yml |   5 +-
>  spec/build/bsps/riscv/optramsize.yml  |   5 +-
>  spec/build/bsps/riscv/riscv/abi.yml   |   6 +
>  .../bsps/riscv/riscv/bspmpfs64imafdc.yml  |  19 +
>  spec/build/bsps/riscv/riscv/grp.yml   |   6 +
>  spec/build/bsps/riscv/riscv/optmpfs.yml   |  18 +
>  spec/build/bsps/riscv/riscv/optns16550max.yml |   3 +
>  spec/build/cpukit/cpuopts.yml |   2 +
>  spec/build/cpukit/optarchbits.yml |   1 +
>  spec/build/cpukit/optboothartid.yml   |  19 +
>  spec/build/cpukit/optsmp.yml  |   1 +
>  27 files changed, 1235 insertions(+), 9 deletions(-)
>  create mode 100644 bsps/riscv/riscv/config/mpfs64imafdc.cfg
>  create mode 100644 bsps/riscv/riscv/dts/mpfs.dts
>  create mode 100644 bsps/riscv/riscv/include/bsp/mpfs-dtb.h
>  create mode 100644 spec/build/bsps/optdtb.yml
>  create mode 100644 spec/build/bsps/optdtbheaderpath.yml
>  create mode 100644 spec/build/bsps/riscv/riscv/bspmpfs64imafdc.yml
>  create mode 100644 spec/build/bsps/riscv/riscv/optmpfs.yml
>  create mode 100644 spec/build/cpukit/optboothartid.yml
>
> --
> 2.25.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Successful Hello world from RPi4B AArch64 over serial

[Alan Cudmore]

Great progress Noor!
I will try your branch today.
Alan

On Mon, Sep 19, 2022 at 12:15 PM Joel Sherrill  wrote:

>
>
> On Mon, Sep 19, 2022 at 10:11 AM Noor Aman  wrote:
>
>> Hey everyone,
>> I've managed to get RTEMS6 on the Raspberry pi 4B rev 1.4. Every test ran
>> fine except for minimum.exe, It gave a fatal error.
>>
>
> Congratulations! Hoozah!
>
> minimum.exe is supposed to reflect the smallest application you can have.
> It barely qualifies as an application as the Initialization task exits
> from the
> thread body and that's what triggers the fatal error. It is expected so
> that's a
> pass. Unfortunately, the exception frame you posted to Discord has what
> looks like a mistake in printing the idle thread id (see name on next
> line):
>
> *** FATAL ***
> fatal source: 0 (INTERNAL_ERROR_CORE)
> fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)
> RTEMS version: 6.0.0.ee92899632c823e19aa4f2e7048af3d910f59be2
> RTEMS tools: 12.1.1 20220622 (RTEMS 6, RSB
> eea379370116628dbe91f19e61ad6129aa1951ac, Newlib ea99f21)
> executing thread ID: 0x089010001   <
> executing thread name: IDLE
>
>
> Kinsey can you run this on one of the aarch64 bit targets you have?
> I suspect this is not a Pi specific issue but maybe something in
> printk? Or the printf format specifier used.  Once more is known, this
> likely will need a ticket.
>
> Try the fileio, cdtest, nsecs, and paranoia samples next. If those
> look ok, it is highly likely that most of the single processor tests
> will run.
>
> fileio requires working console input.
>
>
>>
>> Here's my setup for running RTEMS6 on RPi4B:
>>
>> TF-A is required to enable GIC on RPi. I had tried to use armstub-gic.S (
>> https://github.com/raspberrypi/tools/blob/master/armstubs/armstub8.S)
>> but it didn't work out. TF-A on other hand did work pretty well.
>>
>> Steps to get TF-A binary are described here:
>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/rpi4.html
>>
>
>
>>
>> Config.txt section:
>> arm_64bit=1
>> enable_uart=1
>> gpio=22-27=np
>> enable_jtag_gpio=1
>> dtoverlay=disable-bt
>> kernel=kernel8.img
>> enable_gic=1
>> armstub=bl31.bin
>>
>> RTEMS6
>> My branch (noov-dev): https://github.com/0xnoor/rtems/tree/noor-dev
>>
>
> Now work to get this all cleaned up, merged, and documented. Kinsey
> now has a Pi4 ready to double check your work is repeatable from
> rtems.org sources.
>
> --joel
>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsps/riscv/riscv: Fix fe310_uart_read

[Alan Cudmore]

Note: Resending after learning how to use git send-email, please disregard 
previous message. 

This fixes the riscv fe310 console driver fe310_uart_read function. The function
reads the RX status/data register to check if data is available, but discards
the data and reads it a seconds time.
Also cleared the interrupt enable bit in the first_open function.

Close #4719
---
 bsps/riscv/riscv/console/fe310-uart.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/bsps/riscv/riscv/console/fe310-uart.c 
b/bsps/riscv/riscv/console/fe310-uart.c
index 4ae62d7176..506521add0 100644
--- a/bsps/riscv/riscv/console/fe310-uart.c
+++ b/bsps/riscv/riscv/console/fe310-uart.c
@@ -34,11 +34,13 @@
 int fe310_uart_read(rtems_termios_device_context *base)
 {
   fe310_uart_context * ctx = (fe310_uart_context*) base;
+  int32_t  rxdata;
 
-  if ((ctx->regs->rxdata & TXRXREADY) != 0) {
+  rxdata = ctx->regs->rxdata;
+  if ((rxdata & TXRXREADY) != 0) {
 return -1;
   } else {
-return ctx->regs->rxdata;
+return rxdata & 0xFF;
   }
 }
 
@@ -91,6 +93,7 @@ static bool fe310_uart_first_open (
   (ctx->regs)->div = riscv_get_core_frequency() / 115200 - 1;
   (ctx->regs)->txctrl |= 1;
   (ctx->regs)->rxctrl |= 1;
+  (ctx->regs)->ie = 0;
   return true;
 };
 
-- 
2.34.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Subject: [PATCH] bsps/riscv/riscv: Fix fe310_uart_read in console driver

[Alan Cudmore]

From: Alan Cudmore 

This fixes the riscv fe310 console driver fe310_uart_read function. The
function
reads the RX status/data register to check if data is available, but
discards
the data and reads it a second time.
Also cleared the interrupt enable bit in the first_open function.

Close #4719
---
 bsps/riscv/riscv/console/fe310-uart.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/bsps/riscv/riscv/console/fe310-uart.c
b/bsps/riscv/riscv/console/fe310-uart.c
index 4ae62d7176..506521add0 100644
--- a/bsps/riscv/riscv/console/fe310-uart.c
+++ b/bsps/riscv/riscv/console/fe310-uart.c
@@ -34,11 +34,13 @@
 int fe310_uart_read(rtems_termios_device_context *base)
 {
   fe310_uart_context * ctx = (fe310_uart_context*) base;
+  int32_t  rxdata;

-  if ((ctx->regs->rxdata & TXRXREADY) != 0) {
+  rxdata = ctx->regs->rxdata;
+  if ((rxdata & TXRXREADY) != 0) {
 return -1;
   } else {
-return ctx->regs->rxdata;
+return rxdata & 0xFF;
   }
 }

@@ -91,6 +93,7 @@ static bool fe310_uart_first_open (
   (ctx->regs)->div = riscv_get_core_frequency() / 115200 - 1;
   (ctx->regs)->txctrl |= 1;
   (ctx->regs)->rxctrl |= 1;
+  (ctx->regs)->ie = 0;
   return true;
 };

-- 
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/3] bsps/shared/: Use device tree blob

[Alan Cudmore]

Hi Padmarao,
Please see my inline comments below

On Wed, Sep 14, 2022 at 12:51 AM  wrote:

> Hi Alan,
>
> > On Tue, 2022-09-13 at 23:57 -0400, Alan Cudmore wrote:
> >
> > Hi Padmarao,
> > I am working on a RISC-V bsp variant for the Kendryte K210 and I am
> > also using an included DTB. For my k210 bsp, I changed
> > riscv/shared/start/start.S to set the address of the DTB array before
> > calling bsp_fdt_copy. If we change start.S to handle the following
> > three cases, we would not have to change the bsp_fdt_copy function.
> > The three cases are:
> > - no FDT, I assume griscv bsp
> > - uboot - a0 in contains the address of the u-boot loaded DTB
> > - polarfire, k210 and others - set a0 to the address of the included
> > DTB array
> > I think it's better to keep this function generic and not have to
> > conditionally ignore the input parameter.
> >
>
> Yes, Initially I thought same but don't want to include conditional
> statements in the startup code so moved to bsp_fdt_copy().
>
> Can we try like below in the startup code? so that it can support all
> three cases.
>
> #ifdef BSP_DTB_IS_SUPPORTED
> #include BSP_DTB_HEADER_PATH
> #endif
>

For including the DTB header, I have a file similar to the microblaze_fpga
bsp:
https://git.rtems.org/rtems/tree/bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c
Perhaps after your changes are in the tree we can consider promoting this
feature and option to bsps/shared for riscv, microblaze and future bsps
that need a DTB.


>
> #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
> #ifdef BSP_DTB_IS_SUPPORT
> LADDR a0, system_dtb
> #else
> mv  a0, a1
> #endif
> callbsp_fdt_copy
> #endif
>
> I added your dtb options to my build, and tried this code in start.S. It
works for me.
Once your polarfire BSP is in, then it will be much easier for k210 support
- in fact it may just be a few lines of code and selection of options.
Thanks!
Alan


> Regards
> Padmarao
>
> > Thanks,
> > Alan
> >
> >
> > On Thu, Sep 8, 2022 at 11:44 AM Padmarao Begari <
> > padmarao.beg...@microchip.com> wrote:
> > > If the bsp is integrated and supported a device tree
> > > blob(dtb) then use dtb instead of using it from the U-Boot.
> > > ---
> > >  bsps/shared/start/bsp-fdt.c | 11 ++-
> > >  1 file changed, 10 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-
> > > fdt.c
> > > index 75a1ea41c9..7e1a698896 100644
> > > --- a/bsps/shared/start/bsp-fdt.c
> > > +++ b/bsps/shared/start/bsp-fdt.c
> > > @@ -32,6 +32,10 @@
> > >  #include 
> > >  #include 
> > >
> > > +#ifdef BSP_DTB_IS_SUPPORTED
> > > +#include BSP_DTB_HEADER_PATH
> > > +#endif
> > > +
> > >  #ifndef BSP_FDT_IS_SUPPORTED
> > >  #warning "BSP FDT support indication not defined"
> > >  #endif
> > > @@ -51,7 +55,12 @@ bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX /
> > > sizeof(uint32_t)];
> > >
> > >  void bsp_fdt_copy(const void *src)
> > >  {
> > > +#ifdef BSP_DTB_IS_SUPPORTED
> > > +const volatile uint32_t *s = (const uint32_t *) system_dtb;
> > > +#else
> > >const volatile uint32_t *s = (const uint32_t *) src;
> > > +#endif
> > > +
> > >  #ifdef BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
> > >uint32_t *d = (uint32_t *) ((uintptr_t) &bsp_fdt_blob[0]
> > >  - (uintptr_t) bsp_section_rodata_begin
> > > @@ -61,7 +70,7 @@ void bsp_fdt_copy(const void *src)
> > >  #endif
> > >
> > >if (s != d) {
> > > -size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
> > > +size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(s));
> > >  size_t aligned_size = roundup2(m, CPU_CACHE_LINE_BYTES);
> > >  size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
> > >  size_t i;
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/3] bsps/shared/: Use device tree blob

[Alan Cudmore]

Sorry for not thinking this through, but I think I have a more portable
solution for handling the included DTB:
1. In bsps/shared/start/bsp-fdt.c, include the header as you had originally
proposed.
2. Also bsps/shared/start/bsp-fdt.c, change bsp_fdt_get to return either
&bsp_fdt_blob[0] for the u-boot option, or just system_dtb for the DTB
option.
3. in bsps/riscv/shared/start.S - no change is needed for the fdt copy.
This is only needed if the device tree is loaded by u-boot and needs to be
copied. No need to call it for the embedded DTB.
To make this work, you would need to have the following in config.ini for
the polarfire (and eventually k210) bsp variant:
BSP_START_COPY_FDT_FROM_U_BOOT=False
BSP_DTB_IS_SUPPORTED=True
I'm not sure if the BSP_DTB_IS_SUPPORTED option should be moved to the
shared section of the specs, but I think it might - in this case the
default might be False.
Same with the BSP_DTB_HEADER_PATH option - but I'm not sure what a good
default would be for that.

I think this would set up the microblaze_fpga to use the same shared code
and options, and we could eliminate the
bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c file later.

Below are the diffs for bsps/shared/start/bsp-fdt.c that is working on my
k210 board. Again, sorry for any confusion, what I have now is just a
slight change to your original proposal. (changing bsp_fdt_get instead of
bsp_fdt_copy).
Thanks,
Alan
diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
index 75a1ea41c9..6e2a0b82db 100644
--- a/bsps/shared/start/bsp-fdt.c
+++ b/bsps/shared/start/bsp-fdt.c
@@ -36,6 +36,10 @@
 #warning "BSP FDT support indication not defined"
 #endif

+#ifdef BSP_DTB_IS_SUPPORTED
+   #include BSP_DTB_HEADER_PATH
+#endif
+
 #ifndef BSP_FDT_BLOB_SIZE_MAX
 #define BSP_FDT_BLOB_SIZE_MAX 0
 #endif
@@ -76,5 +80,9 @@ void bsp_fdt_copy(const void *src)

 const void *bsp_fdt_get(void)
 {
+#if BSP_DTB_IS_SUPPORTED
+  return system_dtb;
+#else
   return &bsp_fdt_blob[0];
+#endif
 }



On Wed, Sep 14, 2022 at 9:16 AM Alan Cudmore  wrote:

> Hi Padmarao,
> Please see my inline comments below
>
> On Wed, Sep 14, 2022 at 12:51 AM  wrote:
>
>> Hi Alan,
>>
>> > On Tue, 2022-09-13 at 23:57 -0400, Alan Cudmore wrote:
>> >
>> > Hi Padmarao,
>> > I am working on a RISC-V bsp variant for the Kendryte K210 and I am
>> > also using an included DTB. For my k210 bsp, I changed
>> > riscv/shared/start/start.S to set the address of the DTB array before
>> > calling bsp_fdt_copy. If we change start.S to handle the following
>> > three cases, we would not have to change the bsp_fdt_copy function.
>> > The three cases are:
>> > - no FDT, I assume griscv bsp
>> > - uboot - a0 in contains the address of the u-boot loaded DTB
>> > - polarfire, k210 and others - set a0 to the address of the included
>> > DTB array
>> > I think it's better to keep this function generic and not have to
>> > conditionally ignore the input parameter.
>> >
>>
>> Yes, Initially I thought same but don't want to include conditional
>> statements in the startup code so moved to bsp_fdt_copy().
>>
>> Can we try like below in the startup code? so that it can support all
>> three cases.
>>
>> #ifdef BSP_DTB_IS_SUPPORTED
>> #include BSP_DTB_HEADER_PATH
>> #endif
>>
>
> For including the DTB header, I have a file similar to the microblaze_fpga
> bsp:
>
> https://git.rtems.org/rtems/tree/bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c
> Perhaps after your changes are in the tree we can consider promoting this
> feature and option to bsps/shared for riscv, microblaze and future bsps
> that need a DTB.
>
>
>>
>> #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
>> #ifdef BSP_DTB_IS_SUPPORT
>> LADDR a0, system_dtb
>> #else
>> mv  a0, a1
>> #endif
>> callbsp_fdt_copy
>> #endif
>>
>> I added your dtb options to my build, and tried this code in start.S. It
> works for me.
> Once your polarfire BSP is in, then it will be much easier for k210
> support - in fact it may just be a few lines of code and selection of
> options.
> Thanks!
> Alan
>
>
>> Regards
>> Padmarao
>>
>> > Thanks,
>> > Alan
>> >
>> >
>> > On Thu, Sep 8, 2022 at 11:44 AM Padmarao Begari <
>> > padmarao.beg...@microchip.com> wrote:
>> > > If the bsp is integrated and supported a device tree
>> > > blob(dtb) then use dtb instead of using it from the U-Boot.
>> > > ---
>> > >  bsps/shared/start/bsp-

Re: [PATCH 3/3] bsps/shared/: Use device tree blob

[Alan Cudmore]

Hi Padmarao,
I am working on a RISC-V bsp variant for the Kendryte K210 and I am also
using an included DTB. For my k210 bsp, I changed
riscv/shared/start/start.S to set the address of the DTB array before
calling bsp_fdt_copy. If we change start.S to handle the following three
cases, we would not have to change the bsp_fdt_copy function. The three
cases are:
- no FDT, I assume griscv bsp
- uboot - a0 in contains the address of the u-boot loaded DTB
- polarfire, k210 and others - set a0 to the address of the included DTB
array
I think it's better to keep this function generic and not have to
conditionally ignore the input parameter.

Thanks,
Alan


On Thu, Sep 8, 2022 at 11:44 AM Padmarao Begari <
padmarao.beg...@microchip.com> wrote:

> If the bsp is integrated and supported a device tree
> blob(dtb) then use dtb instead of using it from the U-Boot.
> ---
>  bsps/shared/start/bsp-fdt.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
> index 75a1ea41c9..7e1a698896 100644
> --- a/bsps/shared/start/bsp-fdt.c
> +++ b/bsps/shared/start/bsp-fdt.c
> @@ -32,6 +32,10 @@
>  #include 
>  #include 
>
> +#ifdef BSP_DTB_IS_SUPPORTED
> +#include BSP_DTB_HEADER_PATH
> +#endif
> +
>  #ifndef BSP_FDT_IS_SUPPORTED
>  #warning "BSP FDT support indication not defined"
>  #endif
> @@ -51,7 +55,12 @@ bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)];
>
>  void bsp_fdt_copy(const void *src)
>  {
> +#ifdef BSP_DTB_IS_SUPPORTED
> +const volatile uint32_t *s = (const uint32_t *) system_dtb;
> +#else
>const volatile uint32_t *s = (const uint32_t *) src;
> +#endif
> +
>  #ifdef BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
>uint32_t *d = (uint32_t *) ((uintptr_t) &bsp_fdt_blob[0]
>  - (uintptr_t) bsp_section_rodata_begin
> @@ -61,7 +70,7 @@ void bsp_fdt_copy(const void *src)
>  #endif
>
>if (s != d) {
> -size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
> +size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(s));
>  size_t aligned_size = roundup2(m, CPU_CACHE_LINE_BYTES);
>  size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
>  size_t i;
> --
> 2.25.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RPi 4B MMU seems to be enabled but throwing aarch64-default-exception error

[Alan Cudmore]

Hey Noor,
I probably have more questions than answers at this point, as I'm just
learning how all of this works too. Some comments inline below:

On Sun, Sep 4, 2022 at 6:13 AM Noor Aman  wrote:

> Hey,
> Some doubts here:
> 1) On inspecting the raspberry pi 3 config table, I only seem to have 2
> entries, one is for peripheral base, the other one for core local
> peripherals. I have updated the MMU with peripheral base, ARM local
> registers, and ARMC register. If I'm correct then, the Videocore should
> handle every address of uarts, spi and others, right? or am I missing
> something?
>
Does the RAM need to be included? For example, the xilinx-versal BSP has an
entry for RAM, but the xilinx-zynqmp does not.
The RT-Thread Memory/MMU table has more entries than we need for
GIC/UART/Timer/RAM right now, but would those ranges cover the complete set
of peripherals and RAM? I'm not sure why the memory entry they have only
covers 100Mbytes of RAM:
https://github.com/RT-Thread/rt-thread/blob/master/bsp/raspberry-pi/raspi4-64/driver/board.c#L25


> 2) Raspberry pi 3 kernel starts from 0x20 and the MMU is mapped
> starting from 0x10. My question is if the aarch64 kernel starts from
> 0x8, then where should the MMU start from? I'm assuming it does not
> start from 0x0 because my current code's MMU starts from that and it's very
> likely that this is causing problems.
>
> Figure 1 in the BCM2711 shows the different memory mapping modes:
https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf
I believe we should be looking at the one on the right "ARM view of the
address map in low peripheral mode". The "ARM view" here shows the RAM at
0x0. Having the kernel at 0x8 fits in this view. In other words, the
ARM view has memory start at 0 and the kernel is loaded at the 0x8
offset.

3) Any more suggestions? Glad to receive them.
>
In the bsp.h file, I think the defines need to be changed:
#define BSP_RPI4_PL011_BASE 0x7e201000
should be
#define BSP_RPI4_PL011_BASE 0xFE201000
That matches what I see in RT-Thread, and makes sense given the following
from the peripherals guide:
"If the VPU enables "Low Peripheral" mode then the ARM (only) has Main
peripherals available from 0x0_FC00_ to 0x0_FF7F_ and ARM Local
peripherals available from 0x0_FF80_ to 0x0__.
So a peripheral described in this document as being at legacy address
0x7Enn_ is available in the 35-bit address space at 0x4_7Enn_, and
visible to the ARM at 0x0_FEnn_ if Low Peripheral mode is enabled."

So what about the GIC addresses?
In bsp.h you have:
#define BSP_ARM_GIC_CPUIF_BASE 0x0801
#define BSP_ARM_GIC_DIST_BASE 0x0800
#define BSP_ARM_GIC_REDIST_BASE 0x080A
In RT-Thread they use addresses starting at 0xFF840000 (I think..) Should
these be offset as well?

Thanks,
Alan



> Thanks,
> Noor
>
> On Sat, 3 Sept 2022 at 22:05, Alan Cudmore  wrote:
>
>> Hi Noor,
>>
>> Nice blog entry on the JTAG setup. I ordered the FT232H board like yours
>> to see if I can get the same setup working. I have my Pi 4 running the bare
>> metal OS examples, and I have built your branch, so I hope to start looking
>> at the code.
>>
>> What needs to be in the MMU table? I see different entries in the Aarch64
>> BSPs. For example the Xilinx-versal BSP has entries for the GIC,
>> peripherals, and memory. Can you cover RAM and I/O space on the Pi 4 with
>> just one entry?
>>
>> Looking at the RT-Thread OS, they have the following Pi4/Aarch64 MMU
>> table:
>>
>>
>> https://github.com/RT-Thread/rt-thread/blob/master/bsp/raspberry-pi/raspi4-64/driver/board.c#L25
>>
>>
>>
>> Alan
>>
>> *From: *Noor Aman 
>> *Sent: *Friday, September 2, 2022 2:18 PM
>> *To: *Alan Cudmore 
>> *Cc: *Hesham Moustafa ; William Moore
>> ; rtems-de...@rtems.org 
>> *Subject: *Re: RPi 4B MMU seems to be enabled but throwing
>> aarch64-default-exception error
>>
>>
>>
>> Openocd connection is on my website. Here's the link to that.
>> https://0xnoor.hashnode.dev/setup-openocd-with-jtag-uart-on-raspberry-pi-4-using-ft232h
>>
>>
>>
>> I pushed the code to my github repo. Be sure to checkout noor-dev branch.
>> Here's the link for that. https://github.com/0xnoor/rtems
>>
>>
>>
>> And yes the code looks bad as of now, I'll do optimization and everything
>> soon.
>>
>>
>>
>> Thanks
>>
>>
>>
>> On Fri, 2 Sept 2022 at 23:31, Alan Cudmore 
>> wrote:
>>
>> Hi Noor,
>>
>> Can you describe the setup you use for testing the BSP?
>>
>> I can set up my Pi 4 to tr

RE: RPi 4B MMU seems to be enabled but throwing aarch64-default-exception error

[Alan Cudmore]

Hi Noor,Nice blog entry on the JTAG setup. I ordered the FT232H board like yours to see if I can get the same setup working. I have my Pi 4 running the bare metal OS examples, and I have built your branch, so I hope to start looking at the code.What needs to be in the MMU table? I see different entries in the Aarch64 BSPs. For example the Xilinx-versal BSP has entries for the GIC, peripherals, and memory. Can you cover RAM and I/O space on the Pi 4 with just one entry?Looking at the RT-Thread OS, they have the following Pi4/Aarch64 MMU table:https://github.com/RT-Thread/rt-thread/blob/master/bsp/raspberry-pi/raspi4-64/driver/board.c#L25 AlanFrom: Noor AmanSent: Friday, September 2, 2022 2:18 PMTo: Alan CudmoreCc: Hesham Moustafa; William Moore; rtems-de...@rtems.orgSubject: Re: RPi 4B MMU seems to be enabled but throwing aarch64-default-exception error Openocd connection is on my website. Here's the link to that. https://0xnoor.hashnode.dev/setup-openocd-with-jtag-uart-on-raspberry-pi-4-using-ft232h I pushed the code to my github repo. Be sure to checkout noor-dev branch. Here's the link for that. https://github.com/0xnoor/rtems And yes the code looks bad as of now, I'll do optimization and everything soon.  Thanks On Fri, 2 Sept 2022 at 23:31, Alan Cudmore <alan.cudm...@gmail.com> wrote:Hi Noor,Can you describe the setup you use for testing the BSP?I can set up my Pi 4 to try running your code as you update it. How do you setup the OCD connection? Thanks,Alan On Fri, Sep 2, 2022 at 11:48 AM Noor Aman <nooraman5...@gmail.com> wrote:Hey all,Raspberry Pi 4B MMU seems to be enabled, as reported by openocd but gdb is showing to run in a loop from aarch64-defaulit-exception.S file starting from code line number 143 to 220. From what I can gather, it is being caused by the wrong MMU address. Here's a RAM and MMU allocation sizes and base   MEMORY {  RAM_MMU  : ORIGIN = 0x0, LENGTH = (0x1000 * ${AARCH64_MMU_TRANSLATION_TABLE_PAGES})  RAM      : ORIGIN = 0x8, LENGTH = 1024M  } Relevant Openocd info  bcm2711.cpu0 halted in AArch64 state due to debug-request, current mode: EL1Tcpsr: 0x23c4 pc: 0x8e208MMU: enabled, D-Cache: enabled, I-Cache: enabledInfo : New GDB Connection: 1, Target bcm2711.cpu0, state: halted Any ideas? Thanks,Noor 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RPi 4B MMU seems to be enabled but throwing aarch64-default-exception error

[Alan Cudmore]

Hi Noor,
Can you describe the setup you use for testing the BSP?
I can set up my Pi 4 to try running your code as you update it. How do you
setup the OCD connection?

Thanks,
Alan

On Fri, Sep 2, 2022 at 11:48 AM Noor Aman  wrote:

> Hey all,
> Raspberry Pi 4B MMU seems to be enabled, as reported by openocd but gdb is
> showing to run in a loop from aarch64-defaulit-exception.S file starting
> from code line number 143 to 220.
>
> From what I can gather, it is being caused by the wrong MMU address.
>  Here's a RAM and MMU allocation sizes and base
>
>   MEMORY {
>   RAM_MMU  : ORIGIN = 0x0, LENGTH = (0x1000 *
> ${AARCH64_MMU_TRANSLATION_TABLE_PAGES})
>   RAM  : ORIGIN = 0x8, LENGTH = 1024M
>   }
>
> Relevant Openocd info
>
> bcm2711.cpu0 halted in AArch64 state due to debug-request, current mode:
> EL1T
> cpsr: 0x23c4 pc: 0x8e208
> MMU: enabled, D-Cache: enabled, I-Cache: enabled
> Info : New GDB Connection: 1, Target bcm2711.cpu0, state: halted
>
> Any ideas?
>
> Thanks,
> Noor
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711

[Alan Cudmore]

Hi Noor,The plan works for me. Focus on Aarch64 and we can try to merge/consolidate headers after that.I don’t mind looking at GitHub branches to review work in progress. Is that OK with everyone else?Thanks,Alan  From: Noor AmanSent: Friday, July 22, 2022 11:10 AMTo: Alan CudmoreCc: j...@rtems.org; rtems-de...@rtems.org; Hesham Moustafa; William MooreSubject: Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711 Hey Alan, Sorry for the late reply. So here's my plan. I initially thought of editing the raspberrypi.h and making it compatible for every RPi bsp. But I think I'll just be working on Aarch64 only. So I'll define everything related to bcm2711, not bcm283x. And After I complete with RPi4 bsp, we can work on how to merge both the headers. Following up with some additional thoughts:I have already forked rtems github repo on my profile. https://github.com/0xNoor/rtems .Here's the link. I've added 2 additional branches named as noor-dev and noor-master. noor-master server as the backup branch just in case i break anything in my noor-dev branch. I keep on updating the branches with RTEMS:master branch. So every time I have a question, I just need to point to the part of the repo? I think that would be ok to do. So do I need to do this for getting a review too? And Thanks for rt-thread link. It solves my issue for mailbox and others too :)  On Fri, 22 Jul 2022 at 18:24, Alan Cudmore <alan.cudm...@gmail.com> wrote:Hi Noor,Following up with some additional thoughts:My approach for development for this BSP would be to focus on getting it working on a GitHub fork of the RTEMS repo. It could be messy while you are getting it working, but that is the fun part, in my opinion. If you need help or advice, you could send a message pointing us to parts of your repository.Once you have it working, we can figure out the best way to integrate it. Again, in my opinion, once you have something working, moving code around and reformatting is the easy part!Finally, you can submit the patches of the working BSP.Does this sound like a reasonable to everyone? It may not make sense for the community to review patches that may end up changing as the BSP is developed. I am taking a similar approach.. I have been slowly working on a BSP for the Kendryte K210 RISC-V processor. I have it working now, but soon I need to get input for the best way to integrate it with the existing RISC-V BSPs. Thanks for working on this!Alan  From: Alan CudmoreSent: Thursday, July 21, 2022 10:59 PMTo: j...@rtems.orgCc: Noor Aman; rtems-de...@rtems.org; Hesham Moustafa; William MooreSubject: Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711 Joel, I don't think we need to commit the file now.Some suggestions:- Let's not put RPI2 or RPI3 defines or ifdefs in the file if it's only going to be for the Aarch64 RPI4 BSP- If it will be only used for the RPI4, it might be confusing to have the BCM2836 defines rather than using BCM2711- If we really can share most of the defines between the RPI2 and RPI4 bsps, is there any way we can have a common include in the bsps/shared directory? Something like bcm_soc.h that has common defines for all raspberry Pi models? That would require changes to the Raspberry Pi 1 and 2 BSPs but it would avoid duplication of code.I also wonder if we can end up taking advantage of shared drivers such as the pl011 serial driver. Another source of info that may be helpful is the RT-Thread RTOS. They have RPI 2, 3, and 4 BSPs. The RPI4 has 32 and 64 bit versions. In addition the RTOS is Apache 2.0 licensed, so that may be easier to re-use (Please correct me if I'm wrong on the license usage!)https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pi/raspi4-64 Thanks,Alan On Thu, Jul 21, 2022 at 2:01 PM Joel Sherrill <j...@rtems.org> wrote:  On Thu, Jul 21, 2022 at 12:32 PM Noor Aman <nooraman5...@gmail.com> wrote:I dont think this would be visible to any other application until or unless user explicitly include this header 'raspberrypi.h' in their application. And as of now, this header is only placed in bsps/arm/raspberrypi/includes. Sorry. My mistake. I was thinking it was in bsp.h. :( For my project I'm thinking of using this header with my project with bcm2711 addresses included. For my project, this header will go under bsps/aarch64/raspberrypi/includes. So I don't think this will create any problem for other BSPs.  This will be ok. A file has to explicitly include it. If you think it is ready to commit, I'm happy to do it if Alan or someone else also acks. --joel  On Thu, Jul 21, 2022, 10:16 PM Joel Sherrill <j...@rtems.org> wrote:This looks generally ok but is all this visible to any application that includes bsp.h?  It might all need to be moved into a separate header to avoid contaminating everyone's namespace. On Thu, Jul 21, 2022, 10:56 AM Noor Aman <nooraman5...@gmail.com>

RE: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711

[Alan Cudmore]

Hi Noor,Following up with some additional thoughts:My approach for development for this BSP would be to focus on getting it working on a GitHub fork of the RTEMS repo. It could be messy while you are getting it working, but that is the fun part, in my opinion. If you need help or advice, you could send a message pointing us to parts of your repository.Once you have it working, we can figure out the best way to integrate it. Again, in my opinion, once you have something working, moving code around and reformatting is the easy part!Finally, you can submit the patches of the working BSP.Does this sound like a reasonable to everyone? It may not make sense for the community to review patches that may end up changing as the BSP is developed. I am taking a similar approach.. I have been slowly working on a BSP for the Kendryte K210 RISC-V processor. I have it working now, but soon I need to get input for the best way to integrate it with the existing RISC-V BSPs. Thanks for working on this!Alan  From: Alan CudmoreSent: Thursday, July 21, 2022 10:59 PMTo: j...@rtems.orgCc: Noor Aman; rtems-de...@rtems.org; Hesham Moustafa; William MooreSubject: Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711 Joel, I don't think we need to commit the file now.Some suggestions:- Let's not put RPI2 or RPI3 defines or ifdefs in the file if it's only going to be for the Aarch64 RPI4 BSP- If it will be only used for the RPI4, it might be confusing to have the BCM2836 defines rather than using BCM2711- If we really can share most of the defines between the RPI2 and RPI4 bsps, is there any way we can have a common include in the bsps/shared directory? Something like bcm_soc.h that has common defines for all raspberry Pi models? That would require changes to the Raspberry Pi 1 and 2 BSPs but it would avoid duplication of code.I also wonder if we can end up taking advantage of shared drivers such as the pl011 serial driver. Another source of info that may be helpful is the RT-Thread RTOS. They have RPI 2, 3, and 4 BSPs. The RPI4 has 32 and 64 bit versions. In addition the RTOS is Apache 2.0 licensed, so that may be easier to re-use (Please correct me if I'm wrong on the license usage!)https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pi/raspi4-64 Thanks,Alan On Thu, Jul 21, 2022 at 2:01 PM Joel Sherrill  wrote:  On Thu, Jul 21, 2022 at 12:32 PM Noor Aman  wrote:I dont think this would be visible to any other application until or unless user explicitly include this header 'raspberrypi.h' in their application. And as of now, this header is only placed in bsps/arm/raspberrypi/includes. Sorry. My mistake. I was thinking it was in bsp.h. :( For my project I'm thinking of using this header with my project with bcm2711 addresses included. For my project, this header will go under bsps/aarch64/raspberrypi/includes. So I don't think this will create any problem for other BSPs.  This will be ok. A file has to explicitly include it. If you think it is ready to commit, I'm happy to do it if Alan or someone else also acks. --joel  On Thu, Jul 21, 2022, 10:16 PM Joel Sherrill  wrote:This looks generally ok but is all this visible to any application that includes bsp.h?  It might all need to be moved into a separate header to avoid contaminating everyone's namespace. On Thu, Jul 21, 2022, 10:56 AM Noor Aman  wrote:A brief gist of what i found compatible with the older code---COMPATIBLE HEADER BCM2835 timer- GPIO- AUX- GPU timer---DIDNT CHECK SPI- I2C---MINOR CHNAGE IRQ- FIQ---NOT SURE ABOUT Watchdog- Power management- Mailbox register I didnt get any info about power management or watchdog or mailboxes. (It isnt in the BCM2835 Documention too I think??) And to answer your question Alan about if the Aarch64 would require a DTB or not which you asked me quite earlier. I can say now, you dont, because every address is defined here already so no need for the DTB.   diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.hindex eeb48c42f1..a4ed2a01d1 100644--- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h+++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h@@ -52,15 +52,23 @@  * @{  */ -#if (BSP_IS_RPI2 == 1)-  #define RPI_PERIPHERAL_BASE    0x3F00+#if (RPI_BSP == RPI2)+  #define RPI_PERIPHERAL_BASE    0X3F00   #define BASE_OFFSET            0X3F00++#elif (RPI_BSP == RPI4)+  #define RPI_PERIPHERAL_BASE 0xFE00+  #define BASE_OFFSET 0xFE00+  #define RPI_PERIPHERAL_SIZE    0x0180+ #else   #define RPI_PERIPHERAL_BASE    0x2000   #define BASE_OFFSET            0X5E00+   #endif -#define RPI_PERIPHERAL_SIZE      0x0100+#ifndef RPI_PERIPHERAL_SIZE+#define RPI_PERIPHERAL_SIZE     0x0100  /**  * @name Bus to Physical address translation@@ -543,6 +551,188 @@ #define BCM2836_IRQ_SOURCE_PMU            0x0200 #define BCM2836_IRQ_SOU

Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711

[Alan Cudmore]

Joel, I don't think we need to commit the file now.
Some suggestions:
- Let's not put RPI2 or RPI3 defines or ifdefs in the file if it's only
going to be for the Aarch64 RPI4 BSP
- If it will be only used for the RPI4, it might be confusing to have the
BCM2836 defines rather than using BCM2711
- If we really can share most of the defines between the RPI2 and RPI4
bsps, is there any way we can have a common include in the bsps/shared
directory? Something like bcm_soc.h that has common defines for all
raspberry Pi models? That would require changes to the Raspberry Pi 1 and 2
BSPs but it would avoid duplication of code.
I also wonder if we can end up taking advantage of shared drivers such as
the pl011 serial driver.

Another source of info that may be helpful is the RT-Thread RTOS. They have
RPI 2, 3, and 4 BSPs. The RPI4 has 32 and 64 bit versions. In addition the
RTOS is Apache 2.0 licensed, so that may be easier to re-use (Please
correct me if I'm wrong on the license usage!)
https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pi/raspi4-64

Thanks,
Alan

On Thu, Jul 21, 2022 at 2:01 PM Joel Sherrill  wrote:

>
>
> On Thu, Jul 21, 2022 at 12:32 PM Noor Aman  wrote:
>
>> I dont think this would be visible to any other application until or
>> unless user explicitly include this header 'raspberrypi.h' in their
>> application. And as of now, this header is only placed in
>> bsps/arm/raspberrypi/includes.
>>
>
> Sorry. My mistake. I was thinking it was in bsp.h. :(
>
>
>> For my project I'm thinking of using this header with my project with
>> bcm2711 addresses included. For my project, this header will go under
>> bsps/aarch64/raspberrypi/includes. So I don't think this will create any
>> problem for other BSPs.
>>
>
> This will be ok. A file has to explicitly include it.
>
> If you think it is ready to commit, I'm happy to do it if Alan or someone
> else also acks.
>
> --joel
>
>>
>> On Thu, Jul 21, 2022, 10:16 PM Joel Sherrill  wrote:
>>
>>> This looks generally ok but is all this visible to any application that
>>> includes bsp.h?
>>>
>>> It might all need to be moved into a separate header to avoid
>>> contaminating everyone's namespace.
>>>
>>> On Thu, Jul 21, 2022, 10:56 AM Noor Aman  wrote:
>>>
 A brief gist of what i found compatible with the older code
 ---COMPATIBLE HEADER---
 - BCM2835 timer
 - GPIO
 - AUX
 - GPU timer
 ---DIDNT CHECK---
 - SPI
 - I2C
 ---MINOR CHNAGE---
 - IRQ
 - FIQ
 ---NOT SURE ABOUT---
 - Watchdog
 - Power management
 - Mailbox register

 I didnt get any info about power management or watchdog or mailboxes.
 (It isnt in the BCM2835 Documention too I think??)

 And to answer your question Alan about if the Aarch64 would require a
 DTB or not which you asked me quite earlier. I can say now, you dont,
 because every address is defined here already so no need for the DTB.



 diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
 b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
 index eeb48c42f1..a4ed2a01d1 100644
 --- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
 +++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
 @@ -52,15 +52,23 @@
   * @{
   */

 -#if (BSP_IS_RPI2 == 1)
 -  #define RPI_PERIPHERAL_BASE0x3F00
 +#if (RPI_BSP == RPI2)
 +  #define RPI_PERIPHERAL_BASE0X3F00
#define BASE_OFFSET0X3F00
 +
 +#elif (RPI_BSP == RPI4)
 +  #define RPI_PERIPHERAL_BASE 0xFE00
 +  #define BASE_OFFSET 0xFE00
 +  #define RPI_PERIPHERAL_SIZE0x0180
 +
  #else
#define RPI_PERIPHERAL_BASE0x2000
#define BASE_OFFSET0X5E00
 +
  #endif

 -#define RPI_PERIPHERAL_SIZE  0x0100
 +#ifndef RPI_PERIPHERAL_SIZE
 +#define RPI_PERIPHERAL_SIZE 0x0100

  /**
   * @name Bus to Physical address translation
 @@ -543,6 +551,188 @@
  #define BCM2836_IRQ_SOURCE_PMU0x0200
  #define BCM2836_IRQ_SOURCE_LOCAL_TIMER0x0800

 +
 +
 +/**
 + * @name Raspberry Pi 4 ARM_LOCAL registers
 + *
 + * @{
 + */
 +
 +#define BCM2711_LOCAL_REGS_BASE   0x4C000
 +
 +#define BCM2711_LOCAL_ARM_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x00)
 +#define BCM2711_LOCAL_CORE_IRQ_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x0c)
 +#define BCM2711_LOCAL_PMU_CONTROL_SET (BCM2711_LOCAL_REGS_BASE + 0x10)
 +#define BCM2711_LOCAL_PMU_CONTROL_CLR (BCM2711_LOCAL_REGS_BASE + 0x14)
 +#define BCM2711_LOCAL_PERI_IRQ_ROUTE0 (BCM2711_LOCAL_REGS_BASE + 0x24)
 +#define BCM2711_LOCAL_AXI_QUIET_TIME (BCM2711_LOCAL_REGS_BASE + 0x30)
 +#define BCM2711_LOCAL_LOCAL_TIMER_CONTROL (BCM2711_LOCAL_REGS_BASE +
 0x34)
 +#define BCM2711_LOCAL_LOCAL_TIMER_IRQ   (BCM2711_LOCAL_REGS_BASE +
 0x38)
 +

Re: [GSoC] Help needed for the continuation of project RPi4B

[Alan Cudmore]

I verified that my RPi400 (RPi4 with keyboard) enables the console on UART
1, the "Mini UART" by default. (0xfe215040)
If I add this line to config.txt on the SD card:
dtoverlay=disable-bt
The console comes up with the PL011 UART on the same pins (0xfe201000)
So if you want to use the PL011 UART as the RTEMS console, make sure you
have the "dtoverlay=disable-bt" line in config.txt.
Without the "dt-overlay=disable-bt" line, the first PL011 UART is used to
communicate with the bluetooth device, and the Mini UART serves as the
serial console.
Alan

On Mon, Jul 11, 2022 at 3:28 PM Joel Sherrill  wrote:

>
>
> On Mon, Jul 11, 2022 at 11:13 AM Noor Aman  wrote:
>
>> Hello, I wanted some help on my project and what do I need to do next.
>> Here is a summary of what I have done so far.
>>
>>  TESTING 
>> - Tested bare-metal from https://rpi4os.com, worked good
>> - (Suggested by Alan) Tested VxWorks from
>> https://www.windriver.com/products/vxworks, it worked fine too.
>> - Tested the Looking aon the rpi4b, modified the linkercmds to point at
>> address 0x20, 0x8 and 0xFE00 (Tried all three of them), loaded
>> it using openocd, it was getting stuck at the
>>
>> arm_pl011_write_polled (base=, c=13 '\r') at
>> ../../../bsps/shared/dev/serial/arm-pl011.c:79
>> while ((regs->uartfr & PL011_UARTFR_TXFF) != 0)
>>
>> after manually adding serial uart address through GDB, the code jumps to
>> 0x200.
>>
>
> If so, what address is it really at? Looking at
> https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf on
> page 148 of the PDF, I would expect the PL011 to be at these addresses:
>
>  • UART0: 0x7e201000
>  • UART2: 0x7e201400
>  • UART3: 0x7e201600
>  • UART4: 0x7e201800
>  • UART5: 0x7e201a00
>
> Looking at the a72/console source, I see it is using
> BSP_A72_QEMU_VPL011_BASE as the base address of the UART which doesn't
> match the Pi4
>
> $ grep -r BSP_A72_QEMU_VPL011_BASE
> console/console.c:  .regs = (volatile pl011 *) BSP_A72_QEMU_VPL011_BASE,
> include/bsp.h:#define BSP_A72_QEMU_VPL011_BASE 0x900
>
> Assuming I found the right SoC documentation, that is an obvious reason
> the console fails.
>
>
>>  CODE -
>> - Made a basic abi.yml, bsp*.yml, linkercmds.yml for rpi4b under
>> spec/build/aarch64
>> - copied some of the files from a72 like bspstarthooks.c and tm27.h into
>> bsps/aarch64/raspberrypi4b
>>
>
> Reasonable but I think you need console/console.c from a72 and make sure
> the address, etc. is correct for the Pi 4.
>
>
>>
>>  ANOMALIES 
>> - Some registers are failing to show in the gdb, some of them are
>> ESR_EL1, ELR_EL2 and SPSR_EL3, are they required?
>>
>
> Not an expert here but those are protection level related and system
> registers. I'm not surprised you can't see them in gdb. If you need them to
> have specific values, someone else will have to chime in.
>
>
>> - So in order to cross check, I'm trying to use RPi4B qemu build (Custom
>> fork). Not tested yet. I'm planning to do this in a qemu machine. Any other
>> suggestions?
>>
>
> If this qemu is vaguely close, it may make it easier to debug. But your
> peripheral addresses need to be correct for the hardware.
>
> You can also look at the qemu machine code specific to the Pi 4 and should
> be able to easily see what address each peripheral is at.
>
>
>> - trying to use u-boot. One thing to note is that even with U-boot,
>> you'll have to use the bootcode.bin from the 1.20200212 tag. This is
>> mentioned in the VxWorks README. Alan once mentioned about not being able
>> to boot the RPI zero 2, because of this issue. Is there any problem using
>> old Bootcode.bin?
>>
>
> No way to know without trying but focus on the Pi 4 and don't worry about
> other variants having issues with this bootcode.bin. You need it to work
> once for you on the Pi 4. More needs to work before this is a worry.
>
>
>> - tested the christinaa/rpi-open-firmware, didnt work as expected
>>
>>
>>  QUESTIONS 
>> - Would there be any gain from using U-boot? As this is just a Second
>> stage bootloader.
>>
>
> My gut is that it would be a distraction at this point.
>
>>
>> - What should be my next step?
>>
>
> Make sure you have the right address for peripherals. I think at least the
> UART is wrong. But you did get to the console code polling data out so you
> probably have the basic memory map right. Just need to focus on peripherals
> now.
>
>
>
>> - Any recommendations which will help me for the project?
>>
>> I know I'm a bit slow in this project. My sincere apologies for that. My
>> college is still open and we are at the end of the semester so it's a bit
>> inconvenient to adjust my time for both. Semester time was reduced from 6
>> months to 4 months. I think we might not get vacation this year in order to
>> adjust the timing like it was before Covid. So please bear with me a bit :)
>>
>
> Sometimes this type of work is just frustrating and slow. What in
> retrospect is one setting wrong can take an unfort

[PATCH] Updated _Thread_Get_CPU_time_used calls

[Alan Cudmore]

This is for the rtems-net-legacy repository. The patch fixes the
rtems-net-legacy build failure due to change in _Thread_Get_CPU_time_used
parameter change in rtems 6. I have only tried building the i386/pc686 BSP.

---
 libtest/testbusy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libtest/testbusy.c b/libtest/testbusy.c
index c1d4427..51c6a71 100644
--- a/libtest/testbusy.c
+++ b/libtest/testbusy.c
@@ -28,10 +28,10 @@ void rtems_test_busy_cpu_usage( time_t seconds, long
nanoseconds )
   Timestamp_Control  now;

   executing = _Thread_Get_executing();
-  _Thread_Get_CPU_time_used( executing, &start );
+  start = _Thread_Get_CPU_time_used( executing );
   _Timestamp_Set( &busy, seconds, nanoseconds );

   do {
-_Thread_Get_CPU_time_used( executing, &now );
+now = _Thread_Get_CPU_time_used( executing );
   } while ( now - start < busy );
 }
-- 
2.30.1 (Apple Git-130)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems-docs: add example booting aarch64 image on Xilinx ZCU102

[Alan Cudmore]

This patch is for the rtems-docs repo. I added details on the procedure I
used to boot RTEMS images on the Xilinx ZCU102 board. I applied this patch,
and  generated the HTML docs, and everything looks ok to me.
Thanks,
Alan

---
 user/bsps/aarch64/xilinx-zynqmp.rst | 138 
 1 file changed, 138 insertions(+)

diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst
b/user/bsps/aarch64/xilinx-zynqmp.rst
index ca232de..3d55c4c 100644
--- a/user/bsps/aarch64/xilinx-zynqmp.rst
+++ b/user/bsps/aarch64/xilinx-zynqmp.rst
@@ -44,6 +44,144 @@ When booting via u-boot, RTEMS must be packaged into a
u-boot image or booted
 as a raw binary since u-boot does not currently support ELF64 which is
required
 for AArch64 ELF binaries.

+
+Example: Booting a RTEMS image on the ZCU102 ZynqMP board
+-
+
+This example will walk through the steps needed for booting RTEMS from a
SD card on the
+`ZCU102 ZynqMP board. <
https://www.xilinx.com/products/boards-and-kits/ek-u1-zcu102-g.html>`_ The
reference for setting up a SD card and obtaining pre-built boot images is
`here. <
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841858/Board+bring+up+using+pre-built+images
>`_
+
+Hardware Setup
+^^
+
+Set the dip switch SW6 according to the table below. This will allow the
board to boot from the SD card. Connect a Micro-USB cable to the USB UART
interface J83. This is a quad USB UART interface which will show up on the
development host computer as four different serial or tty devices. Use the
first channel for the console UART. It should be set to 115k baud.
+
++---+
+| Dip Switch JW6|
++--+--+--+--+
+|  ON  |  OFF |  OFF |  OFF |
++--+--+--+--+
+
+Prepare a SD card with a bootable partition
+
+
+The goal is to have a bootable SD card with a partition that is formatted
with the FAT file system. The file system will contain the boot artifacts
including BOOT.bin and the u-boot image. The RTEMS image will be placed on
this volume. To create the bootable SD card, follow the directions `here. <
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842385/How+to+format+SD+card+for+SD+boot
>`_
+
+Once you have the card formatted correctly, you need to place the files
from `this archive <
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2202763266/2021.2+Release#Downloads>`_
on the FAT partition. The following file was used for this example:
`xilinx-vck190-v2021.2-final.bsp <
https://www.xilinx.com/member/forms/download/xef.html?filename=xilinx-vck190-v2021.2-final.bsp
>`_
+
+In order to download these files, you need to have a Xilinx account login.
As an alternative, you can download a bootable image for Ubuntu 20.04 and
write it to an SD card using a utility such as `Balena Etcher <
https://www.balena.io/etcher>`_  or dd. The Ubuntu image is available
`here. `_ Download the image for the
Zynq Ultrascale+ MPSoC Development boards, uncompress it and write it to
the SD card. This image creates multiple partitions, but we only need to
use the FAT partition with the boot artifacts on it.
+
+Verify that the board can boot from the SD card
+^^^
+
+It is worth booting the board from the SD card before trying to boot
RTEMS. Insert the card and power on the board. You should see the messages
on the first console indicating the various boot loader stages and
eventually the Linux kernel. The goal is to interrupt u-boot when given the
chance to access the u-boot command prompt.
+
+Build RTEMS with examples
+^
+
+Build the RTEMS `xilinx-zynqmp-lp64-zu3eg` BSP. Use the ticker.exe sample
which can be found in the directory:
+
+.. code-block:: shell
+
+  build/aarch64/xilinx-zynqmp-lp64-zu3eg/testsuites/samples
+
+Prepare the RTEMS image
+^^^
+
+Prepare your RTEMS image to boot from u-boot with the following commands:
+
+.. code-block:: shell
+
+  $ aarch64-rtems6-objcopy -Obinary ticker.exe ticker.bin
+  $ gzip -9 ticker.bin
+  $ mkimage -A arm64 -O rtems -T kernel -a 0x1000 -e 0x1000 -n
RTEMS -d ticker.bin.gz rtems.img
+
+Boot the RTEMS image
+
+Copy the prepared RTEMS image to the SD card and insert the SD crd in the
ZCU102 board. Power on the board.
+When you see the prompt on the console to interupt u-boot, hit a key to
bring up the u-boot command prompt. On the u-boot command prompt you can
boot your RTEMS image:
+
+.. code-block:: shell
+
+  Zynq-MP> fatload mmc 0:1 0x1000 rtems.img
+  Zynq-MP> bootm 0x1000
+
+This is the entire boot sequence:
+
+.. code-block:: shell
+
+  Pre-FSBL boot Started
+  Xilinx Zynq MP First Stage Boot Loader
+  Release 2020.2   Nov 18 2020  -  11:46:01
+  NOTICE:  ATF running on XCZU9EG/silicon v1/RTL5.1 at 0xfffea000
+  NOTICE:  BL31: v2.2(release):xilinx_rebase_v2.2_2

Re: Building RTEMS toolchain on Aarch64 fails on expat

[Alan Cudmore]

On Thu, Oct 14, 2021 at 11:39 AM Joel Sherrill  wrote:
>
> On Thu, Oct 14, 2021 at 10:18 AM Alan Cudmore  wrote:
> >
> > Hi,
> > I tried to use the RSB master branch to build an RTEMS 6 toolchain on
> > a Raspberry Pi 4 running Ubuntu 20.04 64 bit (Aarch64).
> > It fails on expat-2.1.0, with the log saying that expat does not
> > recognize Aarch64.
> > The expat package on the Ubuntu distribution is 2.2.10.
> > Would this be as simple as upgrading the expat version in RSB?
>
> It should be unless Ubuntu has patches to add aarch64 as recognized.
>
> Change the version and the hash and give it a spin.

Doing that now - It's past the expat build, but it will take a while
to build the entire toolchain on an SD card :)

>
> FYI rtems-tools needs updating to bump the has to something recent
> enough to get the aarch64 kcu105_qemu tester configuration and a
> number of Coverity fixes. It's in Alex's queue.
>
> >
> > I know that building a toolchain on a Raspberry Pi is not the most
> > common use case, but with the M1 Macs I think this will start to
> > become a more widely used development platform.
>
> No reason it shouldn't work. You are right that it will start to
> become more used. I saw some graphic that Apple will sell
> 80% of ARM based laptops. My first thought was "what are the
> other 20%?" :)

Probably refers to Chromebooks and Windows ARM devices like the
Microsoft SQ1 processor. We have a Mac with a M1 CPU.. Eventually I'll
have to try to generate an RTEMS toolchain on it.

Alan

>
> --joel
> >
> > Thanks,
> > Alan
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Building RTEMS toolchain on Aarch64 fails on expat

[Alan Cudmore]

Hi,
I tried to use the RSB master branch to build an RTEMS 6 toolchain on
a Raspberry Pi 4 running Ubuntu 20.04 64 bit (Aarch64).
It fails on expat-2.1.0, with the log saying that expat does not
recognize Aarch64.
The expat package on the Ubuntu distribution is 2.2.10.
Would this be as simple as upgrading the expat version in RSB?

I know that building a toolchain on a Raspberry Pi is not the most
common use case, but with the M1 Macs I think this will start to
become a more widely used development platform.

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] bsps: Move optfdt* files to shared parent directory

[Alan Cudmore]

The master branch works for me. I tried the raspberrypi and
raspberrypi2 BSPS and they work fine. I built the beagleboneblack BSP
but did not run it.

When this one line patch is installed, SMP works too:
https://lists.rtems.org/pipermail/devel/2021-August/068832.html
Alan

On Mon, Aug 9, 2021 at 1:37 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Aug 9, 2021, 10:14 AM Pranav Dangi  wrote:
>>
>> Hi joel,
>> I had sent you a rebased patch as a direct attachment, I will ping that 
>> thread once again. Did that fail too?
>
>
> I just pushed a patch you sent me directly. Is it ok on master now?
>
> --joel
>>
>>
>> Thanks,
>> pranav
>>
>> On Mon, 9 Aug 2021, 20:40 Joel Sherrill,  wrote:
>>>
>>> On Mon, Aug 9, 2021 at 10:00 AM Gedare Bloom  wrote:
>>> >
>>> > Hi Joel,
>>> >
>>> > On Fri, Jul 16, 2021 at 10:40 AM Joel Sherrill  wrote:
>>> > >
>>> > > I'm doing a build sweep of all BSPs. When that completes, I plan to
>>> > > push this unless there are comments.
>>> > >
>>> > Did/can you push this?
>>>
>>> It doesn't apply for me. Could be a rebase is needed or it didn't survive
>>> the email client. If it's just an email issue, just send it to me directly 
>>> as an
>>> attachment possibly compressed to avoid any chance of email clients
>>> getting smart.
>>>
>>> Applying: bsps: Move optfdt* files to shared parent directory
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtcpyro.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtcpyro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtmxsz.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtro.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtuboot.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtuboot.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtcpyro.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtcpyro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtmxsz.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtro.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtuboot.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtuboot.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml:1
>>> error: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtro.yml:1
>>> error: spec/build/bsps/powerpc/qoriq/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtcpyro.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtcpyro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtmxsz.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtro.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtuboot.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtuboot.yml: patch does not apply
>>> Patch failed at 0001 bsps: Move optfdt* files to shared parent directory
>>> The copy of the patch that failed is found in:
>>>/home/joel/rtems-work/rtems/.git/rebase-apply/patch
>>>
>>>
>>> >
>>> > > On Fri, Jul 16, 2021 at 9:51 AM pranav  wrote:
>>> > > >
>>> > > > ---
>>> > > >  .../arm/altera-cyclone-v/bspalteracyclonev.yml  |  8 
>>> > > >  spec/build/bsps/arm/beagle/grp.yml  |  8 
>>> > > >  spec/build/bsps/arm/beagle/optfdtcpyro.yml  | 16 
>>> > > >  spec/build/bsps/arm/beagle/optfdtmxsz.yml   | 17 
>>> > > > -
>>> > > >  spec/build/bsps/arm/beagle/optfdtro.yml | 16 
>>> > > >  spec/build/bsps/arm/beagle/optfdtuboot.yml  | 16 
>>> > > >  spec/build/bsps/arm/imx/bspimx.yml  |  8 
>>> > > >  spec/build/bsps/arm/imx/optfdtcpyro.yml | 16 
>>> > > >  spec/build/bsps/arm/imx/optfdtmxsz.yml  | 17 
>>> > > > -
>>> > > >  spec/build/bsps/arm/imx/optfdtro.yml| 16 
>>> > > >  spec/build/bsps/arm/imx/optfdtuboot.yml | 16 
>>> > > >  spec/build/bsps/arm/raspberrypi/grp.yml |  8 
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtcpyro.yml  |  0
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtmxsz.yml   |  0
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtro.yml |  0
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtuboot.yml  |  0
>>> > > >  spec/build/bsps/powerpc/qoriq/grp.yml   |  4 ++--
>>> > > >  spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml| 17 
>>> > > > -

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

I tried to implement the deprecated cp15 ARMv6 data sync and
instruction sync barriers in the code below. I'm not sure if I got it
right.
The samples run on the single core models, but they also run without
the sync instructions (the commented out code).

For the conditional code, I chose the __ARM_ARCH_6KZ__ define, since
it is set by the arch switch the Pi 1 BSP uses. Not all ARMv6 models
have the CP15 VBAR, so in the unlikely event we added an even older
ARMv6 it would break. I can change it to __ARM_ARCH == 6 if that is
preferred.

At this point, my questions are:
1. Is the define OK?
2. Include the sync barriers for ARMv6 or not?
3. If we keep the sync barriers, are they good enough, or do they need
more work?

Thanks,
Alan

Patch:

diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S
index 698495d32e..bb8ad24e96 100644
--- a/bsps/arm/shared/start/start.S
+++ b/bsps/arm/shared/start/start.S
@@ -482,16 +482,26 @@ bsp_start_hook_0_done:

 .Lvector_table_copy_done:

-#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8
/*
 * This code path is only executed by the primary processor.  Set the
 * VBAR to the normal vector table.  For secondary processors, this is
 * done by bsp_start_hook_0().
 */
+#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8
ldr r0, =bsp_vector_table_begin
dsb
mcr p15, 0, r0, c12, c0, 0
isb
+#elif defined __ARM_ARCH_6KZ__
+/*
+** ldr r0, =bsp_vector_table_begin
+** mcr p15, 0, r0, c12, c0, 0
+*/
+mov r1, #0
+ldr r0, =bsp_vector_table_begin
+mcr p15, 0, r1, c7, c10, 4  /* DataSync */
+mcr p15, 0, r0, c12, c0, 0  /* Load VBAR */
+mcr p15, 0, r1, c7, c5, 4   /* Flush Prefetch */
 #endif

SWITCH_FROM_ARM_TO_THUMBr3

On Thu, Jul 1, 2021 at 10:02 AM Sebastian Huber
 wrote:
>
> On 01/07/2021 15:43, Alan Cudmore wrote:
> > The define works, but Armv6 does not implement dsb and isb.
>
> Ok, I think there are some (now deprecated) CP15 registers for dsb and isb.
>
> > I created a separate #if block for Armv6 without the dsb and isb
> > instructions and it seems to work on the Raspberry Pi Zero.
> > Do you think the equivalent synchronization operations are necessary
> > here? If so, I can research and test them. I found some references on
> > Raspberry Pi forums that I can follow (also had links to the ARM
> > manuals)
> >
> > Also, for the #if blocks, would you prefer this style:
> > #if (7A or 8)
> > ..
> > #else if (6)
> > ..
> > #endif
>
> Yes, this would be good.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

On Thu, Jul 1, 2021 at 8:20 AM Sebastian Huber
 wrote:
>
> On 29/06/2021 21:09, Alan Cudmore wrote:
> >> On 29/06/2021 20:56, Alan Cudmore wrote:
> >>> I understand the move in that commit now.
> >>> Maybe it's not working on the single core models because the code is
> >>> conditional for ARMV7 + A or ARMV8?
> >>> https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485
> >>> I think the single core RPIs are ARM1176JZF-S (ARMv6Z).
> >> Oh, yes, this is probably the problem. I wasn't aware that we have a BSP
> >> which uses Armv6. I will try to figure out the right options.
> > Thanks! As soon as you have something that would work, we can test it.
> > The CPU architecture is old, but it looks like these models will be in
> > production until at least 2026.
>
> I didn't find an Armv6 Reference Manual, so I have no idea if this works
> for all Armv6 systems (the only one in RTEMS is probably the Raspberry Pi)
>
> diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S
> index 698495d32e..028bef6d2d 100644
> --- a/bsps/arm/shared/start/start.S
> +++ b/bsps/arm/shared/start/start.S
> @@ -482,7 +482,8 @@ bsp_start_hook_0_done:
>
>   .Lvector_table_copy_done:
>
> -#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8
> +#if __ARM_ARCH == 6 || (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || \
> +  __ARM_ARCH >= 8
>  /*
>   * This code path is only executed by the primary processor.
> Set the
>   * VBAR to the normal vector table.  For secondary processors,
> this is
>
>
> --

The define works, but Armv6 does not implement dsb and isb.
I created a separate #if block for Armv6 without the dsb and isb
instructions and it seems to work on the Raspberry Pi Zero.
Do you think the equivalent synchronization operations are necessary
here? If so, I can research and test them. I found some references on
Raspberry Pi forums that I can follow (also had links to the ARM
manuals)

Also, for the #if blocks, would you prefer this style:
#if (7A or 8)
..
#else if (6)
..
#endif

or two separate #if blocks?

Thanks,
Alan

> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

Also, if you do not have time, we could research a solution ( guidance
is welcome! )
Alan

On Tue, Jun 29, 2021 at 3:09 PM Alan Cudmore  wrote:
>
> On Tue, Jun 29, 2021 at 3:01 PM Sebastian Huber
>  wrote:
> >
> > On 29/06/2021 20:56, Alan Cudmore wrote:
> > > I understand the move in that commit now.
> > > Maybe it's not working on the single core models because the code is
> > > conditional for ARMV7 + A or ARMV8?
> > > https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485
> > > I think the single core RPIs are ARM1176JZF-S (ARMv6Z).
> >
> > Oh, yes, this is probably the problem. I wasn't aware that we have a BSP
> > which uses Armv6. I will try to figure out the right options.
>
> Thanks! As soon as you have something that would work, we can test it.
> The CPU architecture is old, but it looks like these models will be in
> production until at least 2026.
>
> >
> > > Do the conditional defines come from the compiler?
> >
> > Yes, these are compiler built-in defines.
> >
> > --
> > embedded brains GmbH
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.hu...@embedded-brains.de
> > phone: +49-89-18 94 741 - 16
> > fax:   +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

On Tue, Jun 29, 2021 at 3:01 PM Sebastian Huber
 wrote:
>
> On 29/06/2021 20:56, Alan Cudmore wrote:
> > I understand the move in that commit now.
> > Maybe it's not working on the single core models because the code is
> > conditional for ARMV7 + A or ARMV8?
> > https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485
> > I think the single core RPIs are ARM1176JZF-S (ARMv6Z).
>
> Oh, yes, this is probably the problem. I wasn't aware that we have a BSP
> which uses Armv6. I will try to figure out the right options.

Thanks! As soon as you have something that would work, we can test it.
The CPU architecture is old, but it looks like these models will be in
production until at least 2026.

>
> > Do the conditional defines come from the compiler?
>
> Yes, these are compiler built-in defines.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

Hi Sebastian,
I understand the move in that commit now.
Maybe it's not working on the single core models because the code is
conditional for ARMV7 + A or ARMV8?
https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485
I think the single core RPIs are ARM1176JZF-S (ARMv6Z).
Do the conditional defines come from the compiler?

Thanks,
Alan

On Tue, Jun 29, 2021 at 1:42 AM Sebastian Huber
 wrote:
>
> Hello Alan,
>
> On 29/06/2021 03:13, Alan Cudmore wrote:
> > The current RTEMS 6/master branch does not seem to work on the
> > Raspberry Pi single core models, while the 5 branch does.
> >
> > I was able to track it down to a commit where it stopped working:
> > 272534eb725f2486b7a32b39d998202a101bd36e
> >
> > In that commit, the call:
> >   /* Clear Secure or Non-secure Vector Base Address Register */
> >arm_cp15_set_vector_base_address(bsp_vector_table_begin);
> >
> > Was moved from bsp_start_hook_0 to rpi_start_rtems_on_secondary_processor.
> >
> > If I add it back to bsp_start_hook_0, the single core models work again.
>
> I moved the VBAR setting to start.S. Maybe the problem is that TTBCR is
> no longer set to zero before the VBAR is set. The Raspberry Pi BSP is
> the only BSP which did this.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

Hi,
The current RTEMS 6/master branch does not seem to work on the
Raspberry Pi single core models, while the 5 branch does.

I was able to track it down to a commit where it stopped working:
272534eb725f2486b7a32b39d998202a101bd36e

In that commit, the call:
 /* Clear Secure or Non-secure Vector Base Address Register */
  arm_cp15_set_vector_base_address(bsp_vector_table_begin);

Was moved from bsp_start_hook_0 to rpi_start_rtems_on_secondary_processor.

If I add it back to bsp_start_hook_0, the single core models work again.

I added it here to make it work:
https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspstarthooks.c#n72
It seems like it would be called for both the primary and secondary CPUs.

Before Pranav submits a patch, I thought it would be worth seeing if
there was a reason it was moved in the first place.. No need to keep
moving it back and forth.

Also, it's worth mentioning that we still have to troubleshoot SMP on
the Pi 2 and Pi 3. The samples like ticker, hello, unlimited work on
the Pi 2 and Pi 3, but when I try SMP tests, I don't get console
output.

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/raspberrypi: Add FDT defines to build options

[Alan Cudmore]

Hi,
This patch works for me. I can build and run the latest rtems master
branch samples on the RPI 2 and 3.
The samples do not run on the single core models, but it is not
related to this patch. I have a patch for the single core models, and
when combined with this patch I can get the samples to run on RPI
Zero, Zero W, Pi A+, Original Pi Model B+, Pi 2, and Pi 3.

Thanks,
Alan

On Fri, Jun 25, 2021 at 12:18 PM pranav  wrote:
>
> ---
>  spec/build/bsps/arm/raspberrypi/grp.yml |  8 
>  spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml | 15 +++
>  spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml  | 16 
>  spec/build/bsps/arm/raspberrypi/optfdtro.yml| 15 +++
>  spec/build/bsps/arm/raspberrypi/optfdtuboot.yml | 15 +++
>  5 files changed, 69 insertions(+)
>  create mode 100644 spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml
>  create mode 100644 spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml
>  create mode 100644 spec/build/bsps/arm/raspberrypi/optfdtro.yml
>  create mode 100644 spec/build/bsps/arm/raspberrypi/optfdtuboot.yml
>
> diff --git a/spec/build/bsps/arm/raspberrypi/grp.yml 
> b/spec/build/bsps/arm/raspberrypi/grp.yml
> index 7291e8b178..a810fdd529 100644
> --- a/spec/build/bsps/arm/raspberrypi/grp.yml
> +++ b/spec/build/bsps/arm/raspberrypi/grp.yml
> @@ -31,6 +31,14 @@ links:
>uid: optrpi2
>  - role: build-dependency
>uid: optspiiomode
> +- role: build-dependency
> +  uid: optfdtuboot
> +- role: build-dependency
> +  uid: optfdtcpyro
> +- role: build-dependency
> +  uid: optfdtmxsz
> +- role: build-dependency
> +  uid: optfdtro
>  - role: build-dependency
>uid: ../start
>  - role: build-dependency
> diff --git a/spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml 
> b/spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml
> new file mode 100644
> index 00..c26b1ae051
> --- /dev/null
> +++ b/spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml
> @@ -0,0 +1,15 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- define-condition: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +default: true
> +default-by-variant: []
> +description: |
> +  copy the FDT blob into the read-only load area via bsp_fdt_copy()
> +enabled-by: true
> +links: []
> +name: BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
> +type: build
> diff --git a/spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml 
> b/spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml
> new file mode 100644
> index 00..14af766230
> --- /dev/null
> +++ b/spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml
> @@ -0,0 +1,16 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-integer: null
> +- define: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +default: 262144
> +default-by-variant: []
> +description: |
> +  maximum size of the FDT blob in bytes
> +enabled-by: true
> +format: '{}'
> +links: []
> +name: BSP_FDT_BLOB_SIZE_MAX
> +type: build
> diff --git a/spec/build/bsps/arm/raspberrypi/optfdtro.yml 
> b/spec/build/bsps/arm/raspberrypi/optfdtro.yml
> new file mode 100644
> index 00..a61bb2924b
> --- /dev/null
> +++ b/spec/build/bsps/arm/raspberrypi/optfdtro.yml
> @@ -0,0 +1,15 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- define-condition: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +default: true
> +default-by-variant: []
> +description: |
> +  place the FDT blob into the read-only data area
> +enabled-by: true
> +links: []
> +name: BSP_FDT_BLOB_READ_ONLY
> +type: build
> diff --git a/spec/build/bsps/arm/raspberrypi/optfdtuboot.yml 
> b/spec/build/bsps/arm/raspberrypi/optfdtuboot.yml
> new file mode 100644
> index 00..5805e912ff
> --- /dev/null
> +++ b/spec/build/bsps/arm/raspberrypi/optfdtuboot.yml
> @@ -0,0 +1,15 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- define-condition: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +default: true
> +default-by-variant: []
> +description: |
> +  copy the U-Boot provided FDT to an internal storage
> +enabled-by: true
> +links: []
> +name: BSP_START_COPY_FDT_FROM_U_BOOT
> +type: build
> --
> 2.27.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

[Alan Cudmore]

Hi Niteesh,
Here are my latest tests:
- Using your firmware and the rtems.img in your firmware repo, I can
see that it runs on my Raspberry Pi 3. The hello example reports RTEMS
5.1. Was this from the 5 branch?
- The same image does not seem to boot on the Raspberry Pi 1 modules,
but I think that's because I need to add the command line option. What
file should I add that in, and what command line option I should use?

With the code I build:
- I can get your patch to apply on the master/6 branch, and it builds
OK, but I cannot get the raspberrypi BSP to run on any of my boards
yet (with or without your patch and firmware)
-  I can run the unmodified RTEMS 5 branch raspberry pi BSP on all of
the single core models I have (using your firmware). Interestingly,
the samples run on the Raspberry Pi Zero W (with wireless and
bluetooth) without a patch. I thought the Zero W would have the same
console problem as the RPI 3.
- I applied your patch to my RTEMS 5 branch (had to change the include
path for arm-pl011.h). It runs the same on the single core models
without the patch, and the console does not come up on the Pi 3 like
it does with your rtems.img. Is there something else that needs to be
done in RTEMS 5 to default to the pl011 uart?

All of my tests are not using u-boot.

What should be next?
- I can try the rest of my Raspberry Pi single core models with your
firmware and rtems.img, once I know the command line option I need.
- After that, maybe we should figure out how to configure the console
with your patch on the RTEMS 5 branch.
- Finally, we need to figure out how to get the master/6 branch working again.

Thanks!
Alan

On Thu, May 20, 2021 at 7:41 AM Alan Cudmore  wrote:
>
> Hi Niteesh,
> I tried your firmware, booting directly instead of using u-boot. I was
> able to get the RTEMS 5 branch to run on the Raspberry Pi Zero, but I
> still cannot get the master/6 branch to run. I need some time to do
> additional tests. I was also going to re-try your patch and see if I
> can run the master branch and your firmware with the Pi 3.
>
> Our GSOC student just started a RPi improvement project, so I think
> the first step should be to sort all of this out.
> I'm pretty busy right now, but I'll see if I can continue testing in
> the next few days. I want to try loading from u-boot next.
>
> Alan
>
>
> On Thu, May 20, 2021 at 12:52 AM Niteesh G. S.  wrote:
> >
> > ping.
> >
> > On Tue, May 11, 2021 at 1:09 AM Niteesh G. S.  wrote:
> >>
> >> Hello Gedare,
> >>
> >> On Mon, May 10, 2021 at 8:57 PM Gedare Bloom  wrote:
> >>>
> >>> On Thu, May 6, 2021 at 8:49 AM Niteesh G. S.  wrote:
> >>> >
> >>> > Hi Alan,
> >>> >
> >>> > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore  
> >>> > wrote:
> >>> >>
> >>> >> Hi Niteesh,
> >>> >>
> >>> >> I was hoping to try this out as soon as I get some time. No later than 
> >>> >> weekend. So if nobody else is able to check it out, I will be able to 
> >>> >> provide some feedback soon.
> >>> >>
> >>> >> I should be able to bring up the console on a RPi Zero W and RPi3, 
> >>> >> correct?
> >>> >
> >>> > the consoles should work on Zero W and Pi3 by default. They only fail 
> >>> > to work when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> >>> > this option is used. This is because when that option is used it calls 
> >>> > console_initialize which checks if any boot options were present if 
> >>> > none were
> >>> > given it defaults to pl011 which is the secondary UART in Zero w and 
> >>> > Pi3 so we get no output. This patch defaults to the primary UART 
> >>> > instead of
> >>> > pl011 depending on the board.
> >>> > Also, this patch should be applied on RTEMS 5 since we started 
> >>> > supporting Pi3 and Zero w from RTEMS 5.
> >>> >
> >>> You'll need to provide a separate patch with a ticket to close on 5
> >>> for a backport. Wait until you get the approval for the master branch
> >>> though.
> >>
> >> OK. I'll create a ticket and request for a backport once this is pushed on
> >> to the current master
> >>
> >> Thanks,
> >> Niteesh.
> >>>
> >>>
> >>> > Thanks,
> >>> > Niteesh.
> >>> >
> >>> >
> >>> >>
> >>> >> Thanks,
> >>> >>
> >>> >> Alan
> >>

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

[Alan Cudmore]

Hi Niteesh,
I tried your firmware, booting directly instead of using u-boot. I was
able to get the RTEMS 5 branch to run on the Raspberry Pi Zero, but I
still cannot get the master/6 branch to run. I need some time to do
additional tests. I was also going to re-try your patch and see if I
can run the master branch and your firmware with the Pi 3.

Our GSOC student just started a RPi improvement project, so I think
the first step should be to sort all of this out.
I'm pretty busy right now, but I'll see if I can continue testing in
the next few days. I want to try loading from u-boot next.

Alan


On Thu, May 20, 2021 at 12:52 AM Niteesh G. S.  wrote:
>
> ping.
>
> On Tue, May 11, 2021 at 1:09 AM Niteesh G. S.  wrote:
>>
>> Hello Gedare,
>>
>> On Mon, May 10, 2021 at 8:57 PM Gedare Bloom  wrote:
>>>
>>> On Thu, May 6, 2021 at 8:49 AM Niteesh G. S.  wrote:
>>> >
>>> > Hi Alan,
>>> >
>>> > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore  
>>> > wrote:
>>> >>
>>> >> Hi Niteesh,
>>> >>
>>> >> I was hoping to try this out as soon as I get some time. No later than 
>>> >> weekend. So if nobody else is able to check it out, I will be able to 
>>> >> provide some feedback soon.
>>> >>
>>> >> I should be able to bring up the console on a RPi Zero W and RPi3, 
>>> >> correct?
>>> >
>>> > the consoles should work on Zero W and Pi3 by default. They only fail to 
>>> > work when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>>> > this option is used. This is because when that option is used it calls 
>>> > console_initialize which checks if any boot options were present if none 
>>> > were
>>> > given it defaults to pl011 which is the secondary UART in Zero w and Pi3 
>>> > so we get no output. This patch defaults to the primary UART instead of
>>> > pl011 depending on the board.
>>> > Also, this patch should be applied on RTEMS 5 since we started supporting 
>>> > Pi3 and Zero w from RTEMS 5.
>>> >
>>> You'll need to provide a separate patch with a ticket to close on 5
>>> for a backport. Wait until you get the approval for the master branch
>>> though.
>>
>> OK. I'll create a ticket and request for a backport once this is pushed on
>> to the current master
>>
>> Thanks,
>> Niteesh.
>>>
>>>
>>> > Thanks,
>>> > Niteesh.
>>> >
>>> >
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Alan
>>> >>
>>> >>
>>> >>
>>> >> From: Niteesh G. S.
>>> >> Sent: Thursday, May 6, 2021 4:29 AM
>>> >> To: Joel Sherrill; Christian Mauderer
>>> >> Cc: rtems-de...@rtems.org
>>> >> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console device
>>> >>
>>> >>
>>> >>
>>> >> ping.
>>> >>
>>> >>
>>> >>
>>> >> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S.  
>>> >> wrote:
>>> >>
>>> >> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Sat, May 1, 2021, 8:53 AM Niteesh G. S.  wrote:
>>> >>
>>> >> Just to provide more context,
>>> >>
>>> >> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used
>>> >>
>>> >> and no --console option is provided, the console driver defaults to 
>>> >> PL011.
>>> >>
>>> >> In raspberry pi 3 and other models whose primary UART is not PL011, we 
>>> >> get no output.
>>> >>
>>> >> This patch fixes that by linking the primary UART to the console device.
>>> >>
>>> >>
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Niteesh
>>> >>
>>> >>
>>> >>
>>> >> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu  
>>> >> wrote:
>>> >>
>>> >> When no console argument is given, the driver defaults to pl011
>>> >> this results in no output in case of Rpi3 whose primary uart is
>>> >> miniuart.
>>> >> This patch fixes that by defaulting to the primary uart when no
>>> 

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

[Alan Cudmore]

Hi Niteesh,
I was able to build the current RTEMS master (raspberrypi BSP) and I
was also able to successfully apply your patch and rebuild.
However, I am having trouble getting RTEMS running on the Raspberry Pis I have.
I tried it with and without the patch and I cannot get it to work. I
tried a Raspberry Pi Zero, B+, and Zero W ( with the patch).
I used these instructions for the firmware on SD card:
https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi

I tried:
- RTEMS master "arm/raspberrypi" BSP with and without the patch
- RTEMS 5 branch "arm/raspberrypi" BSP
- latest version of the RPI firmware files
- an older version of the RPI firmware (from June 2016)
I used the config.txt file that is recommended, but I did not have any
command line options. I did not have my raspberry Pis connected to
HDMI, only serial.

Can you describe your setup?
I know I have been through this before.

Thanks,
Alan

On Thu, May 6, 2021 at 10:48 AM Niteesh G. S.  wrote:
>
> Hi Alan,
>
> On Thu, May 6, 2021 at 6:12 PM Alan Cudmore  wrote:
>>
>> Hi Niteesh,
>>
>> I was hoping to try this out as soon as I get some time. No later than 
>> weekend. So if nobody else is able to check it out, I will be able to 
>> provide some feedback soon.
>>
>> I should be able to bring up the console on a RPi Zero W and RPi3, correct?
>
> the consoles should work on Zero W and Pi3 by default. They only fail to work 
> when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> this option is used. This is because when that option is used it calls 
> console_initialize which checks if any boot options were present if none were
> given it defaults to pl011 which is the secondary UART in Zero w and Pi3 so 
> we get no output. This patch defaults to the primary UART instead of
> pl011 depending on the board.
> Also, this patch should be applied on RTEMS 5 since we started supporting Pi3 
> and Zero w from RTEMS 5.
>
> Thanks,
> Niteesh.
>
>
>>
>> Thanks,
>>
>> Alan
>>
>>
>>
>> From: Niteesh G. S.
>> Sent: Thursday, May 6, 2021 4:29 AM
>> To: Joel Sherrill; Christian Mauderer
>> Cc: rtems-de...@rtems.org
>> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console device
>>
>>
>>
>> ping.
>>
>>
>>
>> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S.  wrote:
>>
>> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Sat, May 1, 2021, 8:53 AM Niteesh G. S.  wrote:
>>
>> Just to provide more context,
>>
>> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used
>>
>> and no --console option is provided, the console driver defaults to PL011.
>>
>> In raspberry pi 3 and other models whose primary UART is not PL011, we get 
>> no output.
>>
>> This patch fixes that by linking the primary UART to the console device.
>>
>>
>>
>> Thanks,
>>
>> Niteesh
>>
>>
>>
>> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu  wrote:
>>
>> When no console argument is given, the driver defaults to pl011
>> this results in no output in case of Rpi3 whose primary uart is
>> miniuart.
>> This patch fixes that by defaulting to the primary uart when no
>> console option is provided.
>>
>>
>>
>> Does the default need to vary by model?
>>
>> Yes, the primary UART is different across models.
>>
>>
>>
>> Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooth
>>
>> the PL011 is used to talk to the Bluetooth and miniuart acts as the primary 
>> UART.
>>
>> Now we can change this by adding miniuart-bt to config.txt but the miniuart 
>> is
>>
>> based on the VPU core and requires to add another option which sets the core 
>> to
>>
>> a fixed freq.
>>
>>
>>
>> ---
>>  bsps/arm/raspberrypi/console/console-config.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index 6b8eb80aa4..bd3a8d34c2 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -165,10 +165,16 @@ static void console_select( void )
>>  }
>>}else {
>>  /**
>> - * If no command line option was given, default to PL011.
>> + * If no console option was given we default to the primary uarts.
>> + * The initialization of the uart's and BSP_output_char is

RE: [PATCH] bsps/raspberrypi/console: Fix default console device

[Alan Cudmore]

Hi Niteesh,I was hoping to try this out as soon as I get some time. No later than weekend. So if nobody else is able to check it out, I will be able to provide some feedback soon.I should be able to bring up the console on a RPi Zero W and RPi3, correct? Thanks,Alan From: Niteesh G. S.Sent: Thursday, May 6, 2021 4:29 AMTo: Joel Sherrill; Christian MaudererCc: rtems-de...@rtems.orgSubject: Re: [PATCH] bsps/raspberrypi/console: Fix default console device ping. On Sat, May 1, 2021 at 9:47 PM Niteesh G. S.  wrote:On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote: On Sat, May 1, 2021, 8:53 AM Niteesh G. S.  wrote:Just to provide more context,When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is usedand no --console option is provided, the console driver defaults to PL011.In raspberry pi 3 and other models whose primary UART is not PL011, we get no output.This patch fixes that by linking the primary UART to the console device. Thanks,Niteesh On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu  wrote:When no console argument is given, the driver defaults to pl011this results in no output in case of Rpi3 whose primary uart isminiuart.This patch fixes that by defaulting to the primary uart when noconsole option is provided. Does the default need to vary by model?Yes, the primary UART is different across models. Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooththe PL011 is used to talk to the Bluetooth and miniuart acts as the primary UART.Now we can change this by adding miniuart-bt to config.txt but the miniuart isbased on the VPU core and requires to add another option which sets the core toa fixed freq. --- bsps/arm/raspberrypi/console/console-config.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-)diff --git a/bsps/arm/raspberrypi/console/console-config.c b/bsps/arm/raspberrypi/console/console-config.cindex 6b8eb80aa4..bd3a8d34c2 100644--- a/bsps/arm/raspberrypi/console/console-config.c+++ b/bsps/arm/raspberrypi/console/console-config.c@@ -165,10 +165,16 @@ static void console_select( void )     }   }else {     /**-     * If no command line option was given, default to PL011.+     * If no console option was given we default to the primary uarts.+     * The initialization of the uart's and BSP_output_char is already done+     * in the uart_probe function called before this. So now we can safely+     * compare BSP_output_char.      */-    BSP_output_char = output_char_pl011;-    link(PL011, CONSOLE_DEVICE_NAME);+    if (BSP_output_char == output_char_pl011) {+      link(PL011, CONSOLE_DEVICE_NAME);+    }else {+      link(MINIUART, CONSOLE_DEVICE_NAME);+    }   } }-- 2.17.1___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC'21 Raspberry Pi BSP project

[Alan Cudmore]

Hi,
I can try to give you some background, hopefully others will correct
me if I don't get everything right.

You are correct that the BSP just covers the original Pi1 and Pi Zero
(not Pi Zero W) models + the Pi 2. I don't think the I2C and GPIO
interfaces were ported to the Pi2. At some point, I think SMP was
working on the Pi2, but it did not work the last time I tried it.

In addition, the Pi 2 that I have is a BCM2386 (Quad A7) but the
current ones (if you can find one) have a BCM2387 (Quad A53, similar
to the Pi 3). Is the BCM2386 the same as the BCM2387? I did not think
they were.

I looked over the ticket, and much of the 2017 items still apply.. but
maybe this would be the place for the community to help prioritize
what should be done. Here are my thoughts:

1. What Pi Models should we support?

The Pi Zero continues to be a good choice, because it works, the base
model is still available, and is only $5 USD. The Pi Zero W (Bluetooth
and Wifi model) could be supported, but it requires a different
console UART, since the one used by the existing RTEMS BSP is used for
the Bluetooth module. (same applies to the Pi3). The original Pi B/B+,
A+, etc models with the single core BCM2835 should continue to work as
long as the Pi Zero does.

Pi 2: It probably would not take too much to revive this BSP and get
SMP working. But we have the problem of two different SoCs. If you buy
a new Pi 2, it will have a lower clocked BCM2837 like the Pi3 (but
without the extra Bluetooth/Wifi module). It may be hard to locate one
with the older BCM2836 Quad A7. We would have to be careful to specify
what revision of the Pi 2. I would deprecate it in favor of adding Pi
3 support.

Pi 3: This would be a nice model to support. It may not take too much
to get the generic 32 bit ARM build working on it ( like we originally
did with the Pi 2), but like the Pi Zero W, we would have to
reconfigure the RTEMS console to use the secondary UART. AArch64 SMP
support on the Pi 3 would be great in my opinion.

Pi 4: I have not even thought of this one yet. It's a different SoC
(BCM2711, Quad A72). It is the current model, and it looks like the
RPI foundation is targeting industrial use with the Compute Modules.

All models will be in production until at least 2026, the Pi 4 compute
modules until at least 2028.

My vote: keep Pi 0/1 support, add Pi Zero W support by fixing the
console UART. Drop the Pi 2 support, and put the effort into making
the Pi 3 work instead. Pi 2 users, please let me know if I'm wrong
here!

2. What peripherals should we support?
The basics are always a good place to start. Make sure we have
consistent SPI, I2C, GPIO, and support for both UARTs (important for
the Pi Zero W and PI3)
For the SD card, Ethernet, Wifi and Bluetooth, we should probably
follow the Beaglebone and Zynq path by using Libbsd.
The BeagleBone Black has become the more useful low cost RTEMS board
to me because of it's libbsd support for ethernet, USB, and the SD
card.

3. Are graphics important to users? For me, it's not that important, I
would rather have good SPI, I2C, and network support.

I have a couple of use cases that would be covered by this work:
- Pi Zero - this is one of the lowest cost boards available that can
run RTEMS ($5 USD). Although it does not have networking, with good
I2C, GPIO, and SPI support it can support a lot of applications.
- Pi 3 - A low cost SMP system with libbsd networking support would be
a replacement for the BeagleBone Black for my cFS development.

Here is what I think would make a good plan for the Raspberry Pi BSPs:
- Make sure the BSP works on the Pi Zero, fixing SPI, I2C, and GPIO if
necessary.
- Fix the RTEMS console/uart driver for the Pi Zero W, so the same BSP
will work on the Zero with proper configuration
- Deprecate the RPI 2 BSP (unless the community has a case to keep it,
I only have one of these, and it has not been used in years)
- Add RPI 3 32 bit support (needs same console fix as the RPI Zero 0
and most likely different interrupt and I2C, SPI, GPI support)
Bonus work
- Libbsd support for RPI 3, especially the ethernet
- Aarch64 support for RPI 3
Longer term work
RPI 4 and RPI 4 compute module support.

Sorry for the long post, and I hope this helps!
Alan






On Mon, Apr 5, 2021 at 4:00 PM Pranav Dangi  wrote:
>
> I've been going through the RTEMS raspberry pi repository, And i'm having 
> trouble understanding a couple of things there. the Pi1 (and Pi Zero) had the 
> BCM2835 SoC while the pi2 had the BCM2836 SoC, now, in the bsp directory 
> where the raspberry pi header is defined, the header file has register 
> definitions for both BCM2835 (for GPIO, I2C, etc.) and BCM2836 (for the 4 
> cores).
> However, the corresponding i2c.c or gpio.c files for the bsp only have code 
> for the BCM2835_REG registers and not their BCM2836 i.e. the raspberry pi2 
> counterparts.
> So, is the support for pi2 same as that of pi1 (selecting the particular bsp 
> doesn't make sense then) or am I missin

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

On Thu, Oct 15, 2020 at 3:03 PM Chris Johns  wrote:
>
> On 16/10/20 5:22 am, Alan Cudmore wrote:
> > On Thu, Oct 15, 2020 at 11:19 AM Gedare Bloom  wrote:
> >>
> >> On Thu, Oct 15, 2020 at 6:35 AM Joel Sherrill  wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Oct 15, 2020, 7:15 AM Alan Cudmore  wrote:
> >>>>
> >>>> Thanks for all of the help, and thanks for the patch Chris! I was
> >>>> hoping to submit a patch this weekend, so you just gave me back some
> >>>> time :)
> >>>
> >>>
> >>> Glad you found this!
> >>>
> >>> The RFS was new in 4.10 as I recall. You guys have missions using this. 
> >>> Do you need to locally fix this?
> >
> > We have one active mission that uses it. I will be worth trying to
> > determine what word of memory is affected before trying to fix it,
> > since it has been operating normally for 5.5 years with the issue.
> >
>
> The number of bits needs to align to a value that fits the whole 32 bit mask 
> so
> the last is used to trigger the bug.

How can I calculate this? It would be great if I could tell known
users that they don't need to worry about it.
For example, in the open source cFS bundle where I encountered the
issue, it creates an RFS formatted RAM disk that is 0x20 bytes in
size (2 Mbytes). I would imagine that is a nice round number of bitmap
elements.

Thanks,
Alan

>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel