from:"Will"

Hi

In reviewing ports for deprecation, I noticed that a few architectures have
some very old BSPs which are unlikely to be used anymore. Dropping
architectures and BSPs is beneficial for a few reasons:

+ Architecture removal cuts down on tool configurations when building all
architectures.

+ BSP removal speeds up build sweep times which include rtems-bsp-builder.
That build sweep takes about 8 hours currently.

+ Often eliminates code that cannot be relicensed because I cannot find the
author.

I would like to get some feedback on removing them.

+ ARM candidates include  at least csb336, csb337 and variants. gumstix.
edb7312, and smdk2410

+ m68k candidates include mrm332, most Coldfire BSPs, and 68360 BSPs. The
only ones I currently see a need to keep are the mvme, mcf5282 based,
and genmcf548x.

+ PowerPC should have some but I need help making a list

Help is really needed to make this list. Please speak up. This type of
knowledge is in the community. I have no idea what BSPs are still in use or
even available any longer.

We need to have a ticket on each targeting 6.1 for deprecation and a 7.1
ticket for removal. I am happy to do that part.

Thanks.

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

RFC: Deprecate MIPS port in 6.1

Hi

There does not appear to be any recent activity for this port in RTEMS.
Thread Local Storage is not supported yet. Dynamic loading has a mips
dependent file but it looks like the last work was a patch from 2016 which
was committed in 2020. No idea if this works.

MIPS Technologies is now a RISC-V house. They do not list any MIPS CPUs
under products. I assume they are still collecting license fees from those
with licenses but otherwise MIPS appears to be dead.

Any objections to deprecating this for 6 and removing before 7?

If a user shows up who is interested in it not being removed, we will want
at least more tests passing on the MIPS simulator BSP and likely multiple
BSPs removed.

Thanks

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

RFC: Deprecate Moxie port in 6.1

Hi

There does not appear to be any activity for this port and the Moxie
project does not have any recent activity.

Any objections to deprecating this for 6 and removing before 7?

Thanks

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

Re: Upgrading tools - gcc, binutils, and gdb

Thanks.

I just started a build updating gcc, binutils, and gdb.

On Thu, May 30, 2024 at 1:35 AM Daniel Hellström  wrote:

> Sounds good. From Gaisler we will have long term support for the
> GCC-13/GDB-14 toolchain on SPARC/LEON, and we recently released support for
> GDB-14 in GRMON-3.3.11 for the same toolchain. It is currently available in
> Linux and Baremetal toolchains since April/May. From a maintainence
> perspective, having it also in RTEMS6 releases sounds very good.
>
> Thanks, Daniel
>
>
> Den 5/30/2024 kl. 1:44 AM, skrev Joel Sherrill:
>
> Thanks. It may be a couple of days before I have a merge request ready.
>
> Thanks.
>
> On Wed, May 29, 2024, 6:28 PM Chris Johns  wrote:
>
>> On 30/5/2024 7:22 am, Joel Sherrill wrote:
>> > I am in the middle of updating gcc to the recent 13.3 release to move
>> us off a
>> > git hash.
>> >
>> > Is there any reason we are still on gdb 13? gdb 14.1 was released in
>> Dec 2023.
>>
>> No reason. The change to 13 required python 3 but that has now been
>> absorbed.
>>
>> > Is there any reason we are still on binutils 2.41? binutils 2.42 was
>> release in
>> > Jan 2024.
>> >
>> > I don't mind updating them if no one objects.
>>
>> I do not object.
>>
>> Chris
>>
>
> ___
> 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: Upgrading tools - gcc, binutils, and gdb

2024-05-30 Thread Daniel Hellström

Sounds good. From Gaisler we will have long term support for the 
GCC-13/GDB-14 toolchain on SPARC/LEON, and we recently released support 
for GDB-14 in GRMON-3.3.11 for the same toolchain. It is currently 
available in Linux and Baremetal toolchains since April/May. From a 
maintainence perspective, having it also in RTEMS6 releases sounds very 
good.

Thanks, Daniel

Den 5/30/2024 kl. 1:44 AM, skrev Joel Sherrill:

Thanks. It may be a couple of days before I have a merge request ready.

Thanks.

On Wed, May 29, 2024, 6:28 PM Chris Johns  wrote:

On 30/5/2024 7:22 am, Joel Sherrill wrote:
> I am in the middle of updating gcc to the recent 13.3 release to
move us off a
> git hash.
>
> Is there any reason we are still on gdb 13? gdb 14.1 was
released in Dec 2023.

No reason. The change to 13 required python 3 but that has now
been absorbed.

> Is there any reason we are still on binutils 2.41? binutils 2.42
was release in
> Jan 2024.
>
> I don't mind updating them if no one objects.

I do not object.

Chris

___
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: Upgrading tools - gcc, binutils, and gdb

2024-05-29 Thread Joel Sherrill

Thanks. It may be a couple of days before I have a merge request ready.

Thanks.

On Wed, May 29, 2024, 6:28 PM Chris Johns  wrote:

> On 30/5/2024 7:22 am, Joel Sherrill wrote:
> > I am in the middle of updating gcc to the recent 13.3 release to move us
> off a
> > git hash.
> >
> > Is there any reason we are still on gdb 13? gdb 14.1 was released in Dec
> 2023.
>
> No reason. The change to 13 required python 3 but that has now been
> absorbed.
>
> > Is there any reason we are still on binutils 2.41? binutils 2.42 was
> release in
> > Jan 2024.
> >
> > I don't mind updating them if no one objects.
>
> I do not object.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Upgrading tools - gcc, binutils, and gdb

2024-05-29 Thread Chris Johns

On 30/5/2024 7:22 am, Joel Sherrill wrote:
> I am in the middle of updating gcc to the recent 13.3 release to move us off a
> git hash.
> 
> Is there any reason we are still on gdb 13? gdb 14.1 was released in Dec 
> 2023. 

No reason. The change to 13 required python 3 but that has now been absorbed.

> Is there any reason we are still on binutils 2.41? binutils 2.42 was release 
> in
> Jan 2024.
> 
> I don't mind updating them if no one objects.

I do not object.

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

Upgrading tools - gcc, binutils, and gdb

2024-05-29 Thread Joel Sherrill

Hi

I am in the middle of updating gcc to the recent 13.3 release to move us
off a git hash.

Is there any reason we are still on gdb 13? gdb 14.1 was released in Dec
2023.

Is there any reason we are still on binutils 2.41? binutils 2.42 was
release in Jan 2024.

I don't mind updating them if no one objects.

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

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-05-28 Thread Michal Lenc


Hello,

I have created the draft merge request 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49 so we can 
move the review process there.


Best regards,

Michal

On 23. 05. 24 7:17, Christian MAUDERER wrote:

Hello Michal,

On 2024-05-22 19:49, Michal Lenc wrote:

Hello,

thank you for the feedback.

Do you plan to add the subsystem to the RTEMS core or do you want to 
integrate it as an add-on library? In the first case, your code most 
likely gets more attention if you integrate it into RTEMS and create 
a (draft) merge request. 


The plan is to add it to the RTEMS core. Source code to 
cpukit/dev/can (with CTU CAN FD driver in ctucanfd subdirectory) and 
headers to cpukit/include/dev/can. So from this point of view, draft 
merge request is possible. I will take a look into it in few days.


Regarding headers and their organization, we have done some code 
refactor for more sensible and comprehensible usage. I have described 
it in detail at web manual: 
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html. 
Applications have to include can.h - this defines CAN frame 
structure, ioctls and other defines for API (some of these are 
included through other headers for better code structure, but the 
application just has to include can.h). Controller drivers include 
can-devcommon.h. These are mostly structures moved from can.h that 
are not use for API but only for the controller (can_chip structure, 
functions to filter frames to FIFO etc.). BSP that registers CAN bus 
into /dev namespace includes can-bus.h (+ controller specific header) 
which provides function can_bus_register().



Great. Thank you.



The plan is to install all of these headers even if they are not 
primarily intended to be used from an application. But we think it 
may be useful to provide the interface to create and register 
user-specific driver even from the application if someone has special 
needs surpassing the CAN stack capabilities.


OK.

Best regards

Christian



Best regards,

Michal

On 21. 05. 24 9:09, Christian MAUDERER wrote:

Hello Michal,

On 2024-05-18 14:09, Michal Lenc wrote:

Hello,

Code review without patches or a review system is always a bit 
more effort because there is nothing to add comments directly. It 
seems that I can't register on the gitlab instance that you 
provided. So let's try it here.


I already have an account on RTEMS gitlab so I can make my RTEMS 
fork and put the code there for next part of the review.




Do you plan to add the subsystem to the RTEMS core or do you want to 
integrate it as an add-on library? In the first case, your code most 
likely gets more attention if you integrate it into RTEMS and create 
a (draft) merge request.


Test or demo apps. So most likely not relevant for a review: 


Yes, those will not be going to mainline. I will write special 
testsuite application to test basic interface, similarly to SPI 
testsuite, for this.


*Style*: I would suggest to group defines a bit more. You already 
used prefixes like RTEMS_CAN_QUEUE_* which is great. You can 
improve that a bit more if you use Doxygen "@name" and "@{" ... 
"@}". For an example take a look at 


Added.

*Question*: Why do you prefix some defines with RTEMS (like 
RTEMS_CAN_CHIP_MODE) and others don't have that prefix (like 
CAN_CTRLMODE_LOOPBACK)? The same is true for some other defines in 
other files. I won't mention it every time.


We have tried to make a difference between generic CAN defines like 
modes, flags or errors and strictly RTEMS specific stuff like ioctl 
calls, queue directions and so on. I am not entirely sure whether 
our approach is correct, but there might be some benefits from 
having CAN defines without prefix (some of these defines may be 
even compatible between different systems).




Sounds sensible.

*Style*: Sometimes you use Doxygen @brief. Sometimes \ref. I think 
it works, but it's a bit odd. 


That's caused by my inexperience with Doxygen, changed \ref to @ref.

*Question*: You have ioctls like RTEMS_CAN_DISCARD_QUEUES. 
According to the description, that ioctl has a parameter. Why is 
it an _IO and not an _IOW? The same is true for some more of the 
_IO ioctls


 From Linux kernel documentation 
https://docs.kernel.org/driver-api/ioctl.html#command-number-definitions 
_IOW/_IOR is used if pointer to data is passed to/from kernel. If 
command with no argument or just integer argument is used, then _IO 
should be used. I have not found such a description in RTEMS, but I 
suppose the rules are the same?




Yes, the same rules apply. I missed that there is an exception for 
integer arguments. So that's my fault.


*Typo*: The description of RTEMS_CAN_GET_BITTIMING has a "geets" 
in it's comment. 


Fixed.


*Note*: struct can_chip_ops doesn't have a description.


Good point, added. I have also changed check_bittiming to 
check_and_set_bittiming, it is more fitting.


*Detail*: can_bus_register(...) and can_bitrate2bittiming are

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-05-18 Thread Michal Lenc

Hello,

Code review without patches or a review system is always a bit more
effort because there is nothing to add comments directly. It seems
that I can't register on the gitlab instance that you provided. So
let's try it here.

I already have an account on RTEMS gitlab so I can make my RTEMS fork
and put the code there for next part of the review.

Test or demo apps. So most likely not relevant for a review:

Yes, those will not be going to mainline. I will write special testsuite
application to test basic interface, similarly to SPI testsuite, for this.

*Style*: I would suggest to group defines a bit more. You already used
prefixes like RTEMS_CAN_QUEUE_* which is great. You can improve that a
bit more if you use Doxygen "@name" and "@{" ... "@}". For an example
take a look at

Added.

*Question*: Why do you prefix some defines with RTEMS (like
RTEMS_CAN_CHIP_MODE) and others don't have that prefix (like
CAN_CTRLMODE_LOOPBACK)? The same is true for some other defines in
other files. I won't mention it every time.

We have tried to make a difference between generic CAN defines like
modes, flags or errors and strictly RTEMS specific stuff like ioctl
calls, queue directions and so on. I am not entirely sure whether our
approach is correct, but there might be some benefits from having CAN
defines without prefix (some of these defines may be even compatible
between different systems).

*Style*: Sometimes you use Doxygen @brief. Sometimes \ref. I think it
works, but it's a bit odd.

That's caused by my inexperience with Doxygen, changed \ref to @ref.

*Question*: You have ioctls like RTEMS_CAN_DISCARD_QUEUES. According
to the description, that ioctl has a parameter. Why is it an _IO and
not an _IOW? The same is true for some more of the _IO ioctls

From Linux kernel documentation
https://docs.kernel.org/driver-api/ioctl.html#command-number-definitions
_IOW/_IOR is used if pointer to data is passed to/from kernel. If
command with no argument or just integer argument is used, then _IO
should be used. I have not found such a description in RTEMS, but I
suppose the rules are the same?

*Typo*: The description of RTEMS_CAN_GET_BITTIMING has a "geets" in
it's comment.

Fixed.

*Note*: struct can_chip_ops doesn't have a description.

Good point, added. I have also changed check_bittiming to
check_and_set_bittiming, it is more fitting.

*Detail*: can_bus_register(...) and can_bitrate2bittiming are missing
a description. If they are a public interface, it would be good if
they would have one.

Added.

*Detail*: Description of the can_frame_header. You have field
descriptions like "This member holds the CAN ID value". My first
thought was that it is some kind of address. But with taking a look at
the code, it seems that it is a bit mask that is combined out of
CAN_ERR_ID_* defines. If a field is expected to contain a certain
group of defines: Can you add a note regarding that?

Added. It is a CAN identifier in most cases, but the field is also used
to store CAN_ERR_ID_* in case this is an error frame. Since CAN ID is
only 29 bits, the difference between valid and error frame is determined
by 31st bit of CAN ID (define CAN_ERR_ID_TAG). The complete description
of CAN errors for the stack is here:
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html#error-reporting

*Style*: You have a group of defines like CAN_ERR_*_DATA_BYTE. On the
first glance, I thought it would be the same group as CAN_ERR_ID_*. I
think I would have used CAN_ERR_DATA_BYTE_* instead. Of course that's
a style question and there are always good arguments for any style.
Again: A doxygen group using @{ and @} might achieve the same.

Yes, CAN_ERR_DATA_BYTE_* seems better, changed to it. Also I have added
the groups.

*Typo*: You have a CAN_ERR_PROT_LOC_DARA_BYTE instead of ..._DATA_BYTE.

Fixed.

*Question*: There are a lot of defines in can-frame.h like
CAN_ERR_PROT_LOC_DATA or CAN_ERR_TRX_UNSPEC. Is it clear for someone
more used to CAN, how to use these? Or would a description like
"Possible values for the Byte xyz in a can message" help?

Yes, these defines are mostly standard in CAN stacks (SocketCAN, NuttX etc.)

*Detail*: Again: I'm not happy with the descriptions of the fields of
the structure. A field "flags" that is described as "This member holds
CAN flags" isn't really helpful. Which values can I assign to that
field? Is it a bit mask? Is it a field defined according to some
standard? In that case even a "Holds standard CAN flags" would be
useful because then I know that I just have to take a look at any CAN
documentation.

I detailed the description and added the reference to CAN frame flags.

*Note*: I don't like global defines like MAX_MSGOBJS without a prefix.
That's polluting the name space. Is there a reason that it doesn't
have the CAN or RTEMS_CAN prefix like all other defines?

This is even an unused relict from previous

Re: [PATCH 0/5] Update GRLIB L2C driver for technical note TN-0021

2024-05-17 Thread Sebastian Huber


Hello Martin,

I suggest to remove the grlib/l2c cache support and make sure that 
everything is available through the RTEMS Cache Manager.


On 16.01.24 16:48, Sebastian Huber wrote:

Hello Martin,

we have also the Cache Manager support in 
bsps/sparc/leon3/start/cache.c. At least the lock should be shared 
between these two implementations to ensure that there is no concurrent 
access.


What is the use case for this driver in grlib? Is it used by the Cache 
Manager API?


On 16.01.24 15:06, Martin Åberg wrote:

Implement workarounds for GRLIB-TN-0021 ("Level-2 Cache Issues H1
2023") in the GRLIB L2C driver manager device driver.


Martin Åberg (5):
   grlib/l2c: Fix whitespace
   grlib/l2c: Use printk for debug print
   grlib/l2c: Access registers with helper functions
   grlib/l2c: Write to flush registers using atomic instructions
   grlib/l2c: Prevent concurrent register access

  bsps/shared/grlib/l2c/l2c.c | 267 ++--
  1 file changed, 166 insertions(+), 101 deletions(-)





--
embedded brains GmbH & Co. KG
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: ZynqMP APU RAM Start

2024-05-14 Thread Kinsey Moore

On Tue, May 14, 2024 at 10:39 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 14.05.24 17:11, Kinsey Moore wrote:
> > On Tue, May 14, 2024 at 1:28 AM Chris Johns  > > wrote:
> >
> > On 14/5/2024 4:04 pm, Sebastian Huber wrote:
> >  > Hello,
> >  >
> >  > the ZynqMP APU RAM start addresses are far away from 0x0:
> >  >
> >  > cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> >  > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> >  > actions:
> >  > - get-integer: null
> >  > - assert-uint32: null
> >  > - env-assign: null
> >  > - format-and-define: null
> >  > build-type: option
> >  > copyrights:
> >  > - Copyright (C) 2020 On-Line Applications Research (OAR)
> >  > default:
> >  > - enabled-by:
> >  >   - aarch64/xilinx_zynqmp_lp64_a53
> >  >   - aarch64/xilinx_zynqmp_ilp32_zu3eg
> >  >   - aarch64/xilinx_zynqmp_lp64_cfc400x
> >  >   - aarch64/xilinx_zynqmp_lp64_zu3eg
> >  >   value: 0x1000
> >  > - enabled-by: true
> >  >   value: 0x40018000
> >  > description: |
> >  >   base address of memory area available to the BSP
> >  > enabled-by: true
> >  > format: '{:#010x}'
> >  > links: []
> >  > name: BSP_XILINX_ZYNQMP_RAM_BASE
> >  > type: build
> >  >
> >  > What is the rationale for doing this? Any objections to change
> > the start address
> >  > to 0x0?
> > Not from me but existing workflows will break. Some things to keep
> > in mind:
> >
> > What is the default address used by Linux on this board and what
> > uboot expects?
> >
> > What do the Xilinx tools default to?
> >
> > The load addresses here were taken from other examples when I was first
> > writing this port.
> >
> > The QEMU load address is largely irrelevant since it reads it from the
> > ELF headers and locates it appropriately without other constraints.
> >
> > The address used on hardware is due to u-boot typically loading at
> > 0x800, the RTEMS ELF being initially loaded in lower RAM space, and
> > then u-boot unpacking RTEMS into 0x1000. Everything can be moved
> > around, of course.
>
> Since the RPU cannot access the DDR RAM at 0x0, I suggest to locate the
> APU RAM at 0x0 and use half the size of the DDR RAM for the APU by
> default in the linker command file.
>

So the default RAM would be 256MB instead of the current 512MB. This seems
reasonable and should be sufficient for any tests I'm aware of.

Regarding moving the code to 0x0, that would break null pointer detection.
The vector table is currently mapped RWX due to AArch64 leaving room for 32
instructions per vector entry and the vector target being stored in that
space alongside the vector entry preamble. This could be made RX, but that
is work to be done.

> >
> >  > What is the MMU page size used by the BSPs? Would it be possible
> > to add a NULL
> >  > pointer protection page?
> > The MMU translation table page size is 4KB (0x1000) and the granularity
> > is also 4KB. This will likely need to become more flexible for modern
> > chips that drop 4K page size support as 16KB and 64KB become more
> > common. The 0x0 area is unmapped by default and so throws data aborts on
> > attempted access.
>
> Since these boards usually have lots of DDR RAM available, I would
> switch to a 64KiB page size to reduce the amount of page table reloads
> from RAM. This would waste 64KiB for the NULL pointer protection and up
> to 128KiB at the text/read-only and read-only/read-write boundaries.
>

The page table reloads required depend on how granular the mappings are.
Large block mappings will only consume a few upper level entries instead of
mapping each individual 4KB granule. RTEMS doesn't generally modify
mappings, so mappings generated by translation table walks will only rarely
be invalidated from the TLB. That said, supporting 64KB translation
granules is worth the effort given the direction newer chips are going.

Be aware that we can't move everything over to 64KB blindly as there is no
guarantee of support for any particular translation granule size; 4KB,
16KB, and 64KB are optionally and independently supported so any
combination could exist. ZynqMP in particular supports 4KB and 64KB
translation granules and I'm aware of at least 1 chip that only supports
16KB for practical purposes. QEMU's support for Cortex-A53 cores
contradicts the Cortex-A53 TRM on many points of MMU support suggesting
support of all granule sizes, wrong ASID size, and other issues though I'm
sure QEMU does actually support those modes of operation.

If support for dynamic detection and configuration of granule size is
desired, operation on QEMU will be even less representative of the ability
to run on real hardware.

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

Fwd: GCC 13.3 Release Candidate available from gcc.gnu.org

2024-05-14 Thread Joel Sherrill

GCC is getting closer to a real release. When this drops, we need to switch
the RSB to it for 6 tools.

--joel

-- Forwarded message -
From: Jakub Jelinek via Gcc 
Date: Tue, May 14, 2024, 11:33 AM
Subject: GCC 13.3 Release Candidate available from gcc.gnu.org
To: 

The first release candidate for GCC 13.3 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/
 ftp://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/

and shortly its mirrors.  It has been generated from git commit
r13-8774-g1db45e83021a8a.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 13.3 on Thursday, May 21st.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: ZynqMP APU RAM Start

2024-05-14 Thread Sebastian Huber

On 14.05.24 17:11, Kinsey Moore wrote:
On Tue, May 14, 2024 at 1:28 AM Chris Johns > wrote:

On 14/5/2024 4:04 pm, Sebastian Huber wrote:
 > Hello,
 >
 > the ZynqMP APU RAM start addresses are far away from 0x0:
 >
 > cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
 > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 > actions:
 > - get-integer: null
 > - assert-uint32: null
 > - env-assign: null
 > - format-and-define: null
 > build-type: option
 > copyrights:
 > - Copyright (C) 2020 On-Line Applications Research (OAR)
 > default:
 > - enabled-by:
 >   - aarch64/xilinx_zynqmp_lp64_a53
 >   - aarch64/xilinx_zynqmp_ilp32_zu3eg
 >   - aarch64/xilinx_zynqmp_lp64_cfc400x
 >   - aarch64/xilinx_zynqmp_lp64_zu3eg
 >   value: 0x1000
 > - enabled-by: true
 >   value: 0x40018000
 > description: |
 >   base address of memory area available to the BSP
 > enabled-by: true
 > format: '{:#010x}'
 > links: []
 > name: BSP_XILINX_ZYNQMP_RAM_BASE
 > type: build
 >
 > What is the rationale for doing this? Any objections to change
the start address
 > to 0x0?
Not from me but existing workflows will break. Some things to keep
in mind:

What is the default address used by Linux on this board and what
uboot expects?

What do the Xilinx tools default to?

The load addresses here were taken from other examples when I was first 
writing this port.

The QEMU load address is largely irrelevant since it reads it from the 
ELF headers and locates it appropriately without other constraints.

The address used on hardware is due to u-boot typically loading at 
0x800, the RTEMS ELF being initially loaded in lower RAM space, and 
then u-boot unpacking RTEMS into 0x1000. Everything can be moved 
around, of course.

Since the RPU cannot access the DDR RAM at 0x0, I suggest to locate the 
APU RAM at 0x0 and use half the size of the DDR RAM for the APU by 
default in the linker command file.

 > What is the MMU page size used by the BSPs? Would it be possible
to add a NULL
 > pointer protection page?

I am not sure.

The MMU translation table page size is 4KB (0x1000) and the granularity 
is also 4KB. This will likely need to become more flexible for modern 
chips that drop 4K page size support as 16KB and 64KB become more 
common. The 0x0 area is unmapped by default and so throws data aborts on 
attempted access.

Since these boards usually have lots of DDR RAM available, I would 
switch to a 64KiB page size to reduce the amount of page table reloads 
from RAM. This would waste 64KiB for the NULL pointer protection and up 
to 128KiB at the text/read-only and read-only/read-write boundaries.

--
embedded brains GmbH & Co. KG
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: ZynqMP APU RAM Start

2024-05-14 Thread Kinsey Moore

On Tue, May 14, 2024 at 1:28 AM Chris Johns  wrote:

> On 14/5/2024 4:04 pm, Sebastian Huber wrote:
> > Hello,
> >
> > the ZynqMP APU RAM start addresses are far away from 0x0:
> >
> > cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> > actions:
> > - get-integer: null
> > - assert-uint32: null
> > - env-assign: null
> > - format-and-define: null
> > build-type: option
> > copyrights:
> > - Copyright (C) 2020 On-Line Applications Research (OAR)
> > default:
> > - enabled-by:
> >   - aarch64/xilinx_zynqmp_lp64_a53
> >   - aarch64/xilinx_zynqmp_ilp32_zu3eg
> >   - aarch64/xilinx_zynqmp_lp64_cfc400x
> >   - aarch64/xilinx_zynqmp_lp64_zu3eg
> >   value: 0x1000
> > - enabled-by: true
> >   value: 0x40018000
> > description: |
> >   base address of memory area available to the BSP
> > enabled-by: true
> > format: '{:#010x}'
> > links: []
> > name: BSP_XILINX_ZYNQMP_RAM_BASE
> > type: build
> >
> > What is the rationale for doing this? Any objections to change the start
> address
> > to 0x0?
> Not from me but existing workflows will break. Some things to keep in mind:
>
> What is the default address used by Linux on this board and what uboot
> expects?
>
> What do the Xilinx tools default to?
>
> The load addresses here were taken from other examples when I was first
writing this port.

The QEMU load address is largely irrelevant since it reads it from the ELF
headers and locates it appropriately without other constraints.

The address used on hardware is due to u-boot typically loading at
0x800, the RTEMS ELF being initially loaded in lower RAM space, and
then u-boot unpacking RTEMS into 0x1000. Everything can be moved
around, of course.

> > What is the MMU page size used by the BSPs? Would it be possible to add
> a NULL
> > pointer protection page?
>
> I am not sure.
>

The MMU translation table page size is 4KB (0x1000) and the granularity is
also 4KB. This will likely need to become more flexible for modern chips
that drop 4K page size support as 16KB and 64KB become more common. The 0x0
area is unmapped by default and so throws data aborts on attempted access.

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

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-05-14 Thread Michal Lenc

Hello Christian,

thank you for the thorough review. I am currently at the international
CAN Conference at Baden-Baden, so I will address this once I return by
the end of the week.

Best regards,

Michal Lenc

On 14. 05. 24 10:10, Christian MAUDERER wrote:
> On 2024-05-13 17:40, Christian MAUDERER wrote:
>> Hello Pavel and Michal,
>>
>> sorry for the late reply. I was on vacation last week.
>>
>> On 2024-05-06 11:27, Pavel Pisa wrote:
>>> Dear Christian,
>>>
>>> On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote:
> For others, code under review hosted in CTU university GitLab
> server
>     https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
> Documentation
>    
> https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
>    
> https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html
>
> Main developer behind extension to CAN FD and switch to RTEMS
> is Michal Lenc.
>
> The intention is to (hopefully) reach state when it meets criteria
> to mainlining int RTEMS CPU kit under
>
>     cpukit/dev/can
>>> ...
> I agree, that it is compromise. But adding yet another file
> descriptor
> like multiplexor for queues to each file descriptor seems to me as
> too much complexity. But it can be added. even later as IOCTL to
> remove
> individual queues based on CAN ID matches or queues IDs if create
> is modified to return internal queue IDs...

 I somehow missed that you can open the device multiple times and get
 independent queues. With that, it's completely OK and should be
 flexible
 enough for most applications.

 It's great that you already have put some thought into how it could be
 extended later if some application needs more flexibility.
>>> ...
>> Did you check with
>> some other hardware controller, whether the whole structures /
>> defines
>> / flags close to the hardware do work well for other controllers
>> too?
>
> The code/concept is based on my previous LinCAN and OrtCAN work
>
> https://ortcan.sourceforge.net/lincan/
>>> ...
 I didn't want to doubt your competence. Like I said it's some trap
 that
 I have fallen into often enough myself (like when guiding Prashanths
 GSoC project). But it's clear that you have put a lot of thought into
 that. So I would expect that there shouldn't be much trouble with most
 controllers. Maybe except for the ones where a semiconductor vendor
 thought it would be a good idea to create a completely different
 concept. But these are always difficult.
>>>
>>> I agree with discussion and searching for hard arguments.
>>>
>>> The solution is compromise and in general CAN bus concept
>>> is optimized for direct replacement of wires in car
>>> going between distinc units and its use as general
>>> communication solution has some difficulties and requires
>>> some compromises.
>>>
>>> For small devices with predefined purpose and Autosar,
>>> it is ideal to allocate for each CAN ID (wire signal)
>>> to be sent one communication object on the controller.
>>> Same for each received signal value or their set in the
>>> single frame. The most controllers are equipped by filters
>>> and mechanism to do so including selection of the
>>> Tx message object for physical bus-link arbitration
>>> according to the priority. Then sending side updates
>>> signal value in corresponding Tx object and receiving
>>> side sees most actual one usually on the best effort basis,
>>> older unread frames are overwritten by updated value.
>>>
>>> But even in simple ECU, there are obstacles to use this
>>> principle in all kind of the communication. CAN bus is used
>>> for firmware updates and general configuration. In this
>>> case, the reliable delivery of all messages with given
>>> CAN ID is required because whole sequence has to be
>>> received and processed and the state evolution is associated
>>> to the sequence. If a single message is lost, then all
>>> data are unusable. Because sequence requires exact ordering
>>> it is typical that only single Tx object is used. On Rx
>>> side there can be problem to capture all frames without
>>> overwrite by single Rx object so some controllers ad FIFO
>>> which can be attached to each object or some mechanism
>>> how to allocate more Rx objects and pass them to the user
>>> in FIFO order.
>>>
>>> That works for small ECUs with single purpose firmware.
>>> But on general purpose operating system which should
>>> allow even complete monitoring of the CAN bus, allows
>>> dynamically started applications and even whole virtual
>>> CAN/CANopen nodes, allocation the controller Tx/Rx message
>>> objects for each specific purpose is impossible.
>>>
>>> That is why all generic CAN subsystems which I know
>>> (CAN4Linux, LinCAN, SockteCAN, NuttX char device CAN,
>>> windows Peak's drivers etc.) define API based on
>>>

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-05-14 Thread Christian MAUDERER


On 2024-05-13 17:40, Christian MAUDERER wrote:

Hello Pavel and Michal,

sorry for the late reply. I was on vacation last week.

On 2024-05-06 11:27, Pavel Pisa wrote:

Dear Christian,

On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote:

For others, code under review hosted in CTU university GitLab
server
    https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
Documentation

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html


Main developer behind extension to CAN FD and switch to RTEMS
is Michal Lenc.

The intention is to (hopefully) reach state when it meets criteria
to mainlining int RTEMS CPU kit under

    cpukit/dev/can

...

I agree, that it is compromise. But adding yet another file descriptor
like multiplexor for queues to each file descriptor seems to me as
too much complexity. But it can be added. even later as IOCTL to remove
individual queues based on CAN ID matches or queues IDs if create
is modified to return internal queue IDs...


I somehow missed that you can open the device multiple times and get
independent queues. With that, it's completely OK and should be flexible
enough for most applications.

It's great that you already have put some thought into how it could be
extended later if some application needs more flexibility.

...

Did you check with
some other hardware controller, whether the whole structures / defines
/ flags close to the hardware do work well for other controllers too?


The code/concept is based on my previous LinCAN and OrtCAN work

https://ortcan.sourceforge.net/lincan/

...

I didn't want to doubt your competence. Like I said it's some trap that
I have fallen into often enough myself (like when guiding Prashanths
GSoC project). But it's clear that you have put a lot of thought into
that. So I would expect that there shouldn't be much trouble with most
controllers. Maybe except for the ones where a semiconductor vendor
thought it would be a good idea to create a completely different
concept. But these are always difficult.


I agree with discussion and searching for hard arguments.

The solution is compromise and in general CAN bus concept
is optimized for direct replacement of wires in car
going between distinc units and its use as general
communication solution has some difficulties and requires
some compromises.

For small devices with predefined purpose and Autosar,
it is ideal to allocate for each CAN ID (wire signal)
to be sent one communication object on the controller.
Same for each received signal value or their set in the
single frame. The most controllers are equipped by filters
and mechanism to do so including selection of the
Tx message object for physical bus-link arbitration
according to the priority. Then sending side updates
signal value in corresponding Tx object and receiving
side sees most actual one usually on the best effort basis,
older unread frames are overwritten by updated value.

But even in simple ECU, there are obstacles to use this
principle in all kind of the communication. CAN bus is used
for firmware updates and general configuration. In this
case, the reliable delivery of all messages with given
CAN ID is required because whole sequence has to be
received and processed and the state evolution is associated
to the sequence. If a single message is lost, then all
data are unusable. Because sequence requires exact ordering
it is typical that only single Tx object is used. On Rx
side there can be problem to capture all frames without
overwrite by single Rx object so some controllers ad FIFO
which can be attached to each object or some mechanism
how to allocate more Rx objects and pass them to the user
in FIFO order.

That works for small ECUs with single purpose firmware.
But on general purpose operating system which should
allow even complete monitoring of the CAN bus, allows
dynamically started applications and even whole virtual
CAN/CANopen nodes, allocation the controller Tx/Rx message
objects for each specific purpose is impossible.

That is why all generic CAN subsystems which I know
(CAN4Linux, LinCAN, SockteCAN, NuttX char device CAN,
windows Peak's drivers etc.) define API based on
opening driver and presenting received messages
in FIFO order to application (with options for software
filtering but usually not propagated to controller,
HW - LinCAN has some option to union user FIFOs to
mask and ID propagated to HW, but you usually end with
fully end with need to receve all anyway and it has not been
used at the end). The Tx FIFO order is required for messages
with same ID or even sometimes between same stream of mesages
even wit altering ID for correct realization of some higher
level protocols.

The result is that even on hardware equipped with multiple
Tx objects but without special Tx FIFO order preserving
cyclic queue only single Tx object is used to realize
transmission of all messages, for

Re: ZynqMP APU RAM Start

2024-05-14 Thread Chris Johns

On 14/5/2024 4:04 pm, Sebastian Huber wrote:
> Hello,
> 
> the ZynqMP APU RAM start addresses are far away from 0x0:
> 
> cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> - get-integer: null
> - assert-uint32: null
> - env-assign: null
> - format-and-define: null
> build-type: option
> copyrights:
> - Copyright (C) 2020 On-Line Applications Research (OAR)
> default:
> - enabled-by:
>   - aarch64/xilinx_zynqmp_lp64_a53
>   - aarch64/xilinx_zynqmp_ilp32_zu3eg
>   - aarch64/xilinx_zynqmp_lp64_cfc400x
>   - aarch64/xilinx_zynqmp_lp64_zu3eg
>   value: 0x1000
> - enabled-by: true
>   value: 0x40018000
> description: |
>   base address of memory area available to the BSP
> enabled-by: true
> format: '{:#010x}'
> links: []
> name: BSP_XILINX_ZYNQMP_RAM_BASE
> type: build
> 
> What is the rationale for doing this? Any objections to change the start 
> address
> to 0x0?
Not from me but existing workflows will break. Some things to keep in mind:

What is the default address used by Linux on this board and what uboot expects?

What do the Xilinx tools default to?

> What is the MMU page size used by the BSPs? Would it be possible to add a NULL
> pointer protection page?

I am not sure.

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

ZynqMP APU RAM Start

2024-05-14 Thread Sebastian Huber


Hello,

the ZynqMP APU RAM start addresses are far away from 0x0:

cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
- assert-uint32: null
- env-assign: null
- format-and-define: null
build-type: option
copyrights:
- Copyright (C) 2020 On-Line Applications Research (OAR)
default:
- enabled-by:
  - aarch64/xilinx_zynqmp_lp64_a53
  - aarch64/xilinx_zynqmp_ilp32_zu3eg
  - aarch64/xilinx_zynqmp_lp64_cfc400x
  - aarch64/xilinx_zynqmp_lp64_zu3eg
  value: 0x1000
- enabled-by: true
  value: 0x40018000
description: |
  base address of memory area available to the BSP
enabled-by: true
format: '{:#010x}'
links: []
name: BSP_XILINX_ZYNQMP_RAM_BASE
type: build

What is the rationale for doing this? Any objections to change the start 
address to 0x0?


What is the MMU page size used by the BSPs? Would it be possible to add 
a NULL pointer protection page?


--
embedded brains GmbH & Co. KG
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: 6.1 release on Aug 26, 2024?

2024-05-13 Thread Chris Johns

On 11/5/2024 9:40 pm, Cedric Berger wrote:
> Hello,
> 
> On gitlab, issues tagged "6.1" show a release date of Aug 26, 2024 for this
> milestone, is it the current plan?
> 
> If not, before or after?
> 
> Any plan to merge GCC 13.3 or 14.1 before the release?
> 
> Just curious, and trying to do some planning...

I was required to enter a date and given the last release on the same day in the
year I selected it. It happens to be my passed fathers birthday.

There is hope to have a release before then but there are some things we need to
get sorted.

I need to move the release notes generation to gitlab and currently that task is
unfunded. That means it is in any spare time I can find and when it is the top
of the list I will work on it. I have some ideas on how to do this but it is
still a work in progress. I hope it is easier than Trac which was truly 
horrible.

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

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-05-13 Thread Christian MAUDERER


Hello Pavel and Michal,

sorry for the late reply. I was on vacation last week.

On 2024-05-06 11:27, Pavel Pisa wrote:

Dear Christian,

On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote:

For others, code under review hosted in CTU university GitLab
server
https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
Documentation
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html

Main developer behind extension to CAN FD and switch to RTEMS
is Michal Lenc.

The intention is to (hopefully) reach state when it meets criteria
to mainlining int RTEMS CPU kit under

cpukit/dev/can

...

I agree, that it is compromise. But adding yet another file descriptor
like multiplexor for queues to each file descriptor seems to me as
too much complexity. But it can be added. even later as IOCTL to remove
individual queues based on CAN ID matches or queues IDs if create
is modified to return internal queue IDs...


I somehow missed that you can open the device multiple times and get
independent queues. With that, it's completely OK and should be flexible
enough for most applications.

It's great that you already have put some thought into how it could be
extended later if some application needs more flexibility.

...

Did you check with
some other hardware controller, whether the whole structures / defines
/ flags close to the hardware do work well for other controllers too?


The code/concept is based on my previous LinCAN and OrtCAN work

https://ortcan.sourceforge.net/lincan/

...

I didn't want to doubt your competence. Like I said it's some trap that
I have fallen into often enough myself (like when guiding Prashanths
GSoC project). But it's clear that you have put a lot of thought into
that. So I would expect that there shouldn't be much trouble with most
controllers. Maybe except for the ones where a semiconductor vendor
thought it would be a good idea to create a completely different
concept. But these are always difficult.


I agree with discussion and searching for hard arguments.

The solution is compromise and in general CAN bus concept
is optimized for direct replacement of wires in car
going between distinc units and its use as general
communication solution has some difficulties and requires
some compromises.

For small devices with predefined purpose and Autosar,
it is ideal to allocate for each CAN ID (wire signal)
to be sent one communication object on the controller.
Same for each received signal value or their set in the
single frame. The most controllers are equipped by filters
and mechanism to do so including selection of the
Tx message object for physical bus-link arbitration
according to the priority. Then sending side updates
signal value in corresponding Tx object and receiving
side sees most actual one usually on the best effort basis,
older unread frames are overwritten by updated value.

But even in simple ECU, there are obstacles to use this
principle in all kind of the communication. CAN bus is used
for firmware updates and general configuration. In this
case, the reliable delivery of all messages with given
CAN ID is required because whole sequence has to be
received and processed and the state evolution is associated
to the sequence. If a single message is lost, then all
data are unusable. Because sequence requires exact ordering
it is typical that only single Tx object is used. On Rx
side there can be problem to capture all frames without
overwrite by single Rx object so some controllers ad FIFO
which can be attached to each object or some mechanism
how to allocate more Rx objects and pass them to the user
in FIFO order.

That works for small ECUs with single purpose firmware.
But on general purpose operating system which should
allow even complete monitoring of the CAN bus, allows
dynamically started applications and even whole virtual
CAN/CANopen nodes, allocation the controller Tx/Rx message
objects for each specific purpose is impossible.

That is why all generic CAN subsystems which I know
(CAN4Linux, LinCAN, SockteCAN, NuttX char device CAN,
windows Peak's drivers etc.) define API based on
opening driver and presenting received messages
in FIFO order to application (with options for software
filtering but usually not propagated to controller,
HW - LinCAN has some option to union user FIFOs to
mask and ID propagated to HW, but you usually end with
fully end with need to receve all anyway and it has not been
used at the end). The Tx FIFO order is required for messages
with same ID or even sometimes between same stream of mesages
even wit altering ID for correct realization of some higher
level protocols.

The result is that even on hardware equipped with multiple
Tx objects but without special Tx FIFO order preserving
cyclic queue only single Tx object is used to realize
transmission of all messages, for example SocketCAN on
XCAN controller. So only part of

6.1 release on Aug 26, 2024?

2024-05-11 Thread Cedric Berger


Hello,

On gitlab, issues tagged "6.1" show a release date of Aug 26, 2024 for 
this milestone, is it the current plan?


If not, before or after?

Any plan to merge GCC 13.3 or 14.1 before the release?

Just curious, and trying to do some planning...

Thanks,

Cedric


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

Re: Improvements to SMP under the arch64 architecture

2024-05-09 Thread zhengxiaojun




在 2024/5/8 22:36, Sebastian Huber 写道:

On 08.05.24 08:17, Sebastian Huber wrote:

Hello,

on the arm target, we use this:

static inline struct Per_CPU_Control 
*_ARM_Get_current_per_CPU_control( void )

{
   struct Per_CPU_Control *cpu_self;

   /* Use PL1 only Thread ID Register (TPIDRPRW) */
   __asm__ volatile (
 "mrc p15, 0, %0, c13, c0, 4"
 : "=r" ( cpu_self )
   );

   return cpu_self;
}

to access the per-CPU control. I guess, AArch64 has also a thread ID 
register available for operating system use. With this we could 
implement _CPU_Get_current_processor() like this:


return _Per_CPU_Get_index( _CPU_Get_current_per_CPU_control() );

The BSP-specific startup code has to decode the MPIDR and set the 
thread ID register accordingly.
The thing that's troubling me is where to save configuration information 
as it may affect other BSPs. I want to reduce the scope of impact. I 
think the current BSPs can select update or use the origin way is best.
Maybe the core can decode itself is the best way, but I could not find a 
way to do that. Linux use the information from device tree, so I think 
maybe there's no such way.




If we assume that we always run in EL1 or higher, then we can use the 
TPIDR_EL1 for an _AArch64_Get_current_per_CPU_control().




From the comment of start.S I think RTEMS always run in EL1.

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

Re: Improvements to SMP under the arch64 architecture

2024-05-08 Thread Kinsey Moore

On Wed, May 8, 2024 at 9:36 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08.05.24 08:17, Sebastian Huber wrote:
> > Hello,
> >
> > on the arm target, we use this:
> >
> > static inline struct Per_CPU_Control *_ARM_Get_current_per_CPU_control(
> > void )
> > {
> >struct Per_CPU_Control *cpu_self;
> >
> >/* Use PL1 only Thread ID Register (TPIDRPRW) */
> >__asm__ volatile (
> >  "mrc p15, 0, %0, c13, c0, 4"
> >  : "=r" ( cpu_self )
> >);
> >
> >return cpu_self;
> > }
> >
> > to access the per-CPU control. I guess, AArch64 has also a thread ID
> > register available for operating system use. With this we could
> > implement _CPU_Get_current_processor() like this:
> >
> > return _Per_CPU_Get_index( _CPU_Get_current_per_CPU_control() );
> >
> > The BSP-specific startup code has to decode the MPIDR and set the thread
> > ID register accordingly.
>
> If we assume that we always run in EL1 or higher, then we can use the
> TPIDR_EL1 for an _AArch64_Get_current_per_CPU_control().
>

As currently configured, AArch64 only runs in EL1 (with small portions of
the boot code possibly running in EL3/EL2 depending on the start state) and
is never expected to run in EL0 for any reason. RTEMS does use the EL0
stack pointer, but that's only for interrupt stacks and doesn't actually
drop to EL0 system state.

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

Re: Improvements to SMP under the arch64 architecture

2024-05-08 Thread Sebastian Huber


On 08.05.24 08:17, Sebastian Huber wrote:

Hello,

on the arm target, we use this:

static inline struct Per_CPU_Control *_ARM_Get_current_per_CPU_control( 
void )

{
   struct Per_CPU_Control *cpu_self;

   /* Use PL1 only Thread ID Register (TPIDRPRW) */
   __asm__ volatile (
     "mrc p15, 0, %0, c13, c0, 4"
     : "=r" ( cpu_self )
   );

   return cpu_self;
}

to access the per-CPU control. I guess, AArch64 has also a thread ID 
register available for operating system use. With this we could 
implement _CPU_Get_current_processor() like this:


return _Per_CPU_Get_index( _CPU_Get_current_per_CPU_control() );

The BSP-specific startup code has to decode the MPIDR and set the thread 
ID register accordingly.


If we assume that we always run in EL1 or higher, then we can use the 
TPIDR_EL1 for an _AArch64_Get_current_per_CPU_control().


--
embedded brains GmbH & Co. KG
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: Improvements to SMP under the arch64 architecture

2024-05-08 Thread Sebastian Huber


Hello,

on the arm target, we use this:

static inline struct Per_CPU_Control *_ARM_Get_current_per_CPU_control( 
void )

{
  struct Per_CPU_Control *cpu_self;

  /* Use PL1 only Thread ID Register (TPIDRPRW) */
  __asm__ volatile (
"mrc p15, 0, %0, c13, c0, 4"
: "=r" ( cpu_self )
  );

  return cpu_self;
}

to access the per-CPU control. I guess, AArch64 has also a thread ID 
register available for operating system use. With this we could 
implement _CPU_Get_current_processor() like this:


return _Per_CPU_Get_index( _CPU_Get_current_per_CPU_control() );

The BSP-specific startup code has to decode the MPIDR and set the thread 
ID register accordingly.


--
embedded brains GmbH & Co. KG
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

Improvements to SMP under the arch64 architecture

2024-05-07 Thread zhengxiaojun


Hi, all

The current RTEMS can not run on the multi-core CPUs arranged in 
clusters, the current code treat mpidr as processor index,

but when multi-core arranged in cluster, mpidr is 0,0x100,0x200 ...
So a mapping needs to be established between mpidr and processor index.

MPIDR_EL1
+---+---+++---++---+--+-+
|[63:40]|[39:32]|[31]|[30]|[29:25]|[24]|[23:16]|[15:8]|[7:0]|
+---+---+++---++---+--+-+
|   | Aff3  || U  |  UNK  || Aff2  | Aff1 | Aff0|
+---+---+++---++---+--+-+

For the purpose of multi-core arranged in cluster,there are several 
places need to be improved.

1.start.S: calc and setup stack pointer for each core
2.cpu.h:_CPU_SMP_Get_current_processor()
3.bspsmp-arm-psci.c:_CPU_SMP_Start_processor()
4.arm_gicv3.c:arm_gic_irq_processor_count()
5.arm_gicv3.c:bsp_interrupt_raise_on()

I have made it run on a RK3568 board, use an array to map mpidr to 
processor index.But the changes may affect other BSPs, I need some 
advice on how to reduce the affect and make the changes more generic,

so these changes can be merged into the main version.

Linux get core id from the device tree.

Please feel free to give me your advice.

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

Re: [PATCH 1/2] hw/intc/arm_gic: Fix set pending of PPIs

2024-05-07 Thread Sebastian Huber


Sorry, this did go to the wrong mailing list.

On 07.05.24 14:56, Sebastian Huber wrote:

According to the GICv2 specification section 4.3.7, "Interrupt Set-Pending
Registers, GICD_ISPENDRn":

"In a multiprocessor implementation, GICD_ISPENDR0 is banked for each connected
processor. This register holds the Set-pending bits for interrupts 0-31."

Signed-off-by: Sebastian Huber 
---
  hw/intc/arm_gic.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 4da5326ed6..20b3f701e0 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -1296,12 +1296,14 @@ static void gic_dist_writeb(void *opaque, hwaddr offset,
  
  for (i = 0; i < 8; i++) {

  if (value & (1 << i)) {
+int cm = (irq < GIC_INTERNAL) ? (1 << cpu) : ALL_CPU_MASK;
+
  if (s->security_extn && !attrs.secure &&
  !GIC_DIST_TEST_GROUP(irq + i, 1 << cpu)) {
  continue; /* Ignore Non-secure access of Group0 IRQ */
  }
  
-GIC_DIST_SET_PENDING(irq + i, GIC_DIST_TARGET(irq + i));

+GIC_DIST_SET_PENDING(irq + i, cm);
  }
  }
  } else if (offset < 0x300) {


--
embedded brains GmbH & Co. KG
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

[PATCH 1/2] hw/intc/arm_gic: Fix set pending of PPIs

2024-05-07 Thread Sebastian Huber

According to the GICv2 specification section 4.3.7, "Interrupt Set-Pending
Registers, GICD_ISPENDRn":

"In a multiprocessor implementation, GICD_ISPENDR0 is banked for each connected
processor. This register holds the Set-pending bits for interrupts 0-31."

Signed-off-by: Sebastian Huber 
---
 hw/intc/arm_gic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 4da5326ed6..20b3f701e0 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -1296,12 +1296,14 @@ static void gic_dist_writeb(void *opaque, hwaddr offset,
 
 for (i = 0; i < 8; i++) {
 if (value & (1 << i)) {
+int cm = (irq < GIC_INTERNAL) ? (1 << cpu) : ALL_CPU_MASK;
+
 if (s->security_extn && !attrs.secure &&
 !GIC_DIST_TEST_GROUP(irq + i, 1 << cpu)) {
 continue; /* Ignore Non-secure access of Group0 IRQ */
 }
 
-GIC_DIST_SET_PENDING(irq + i, GIC_DIST_TARGET(irq + i));
+GIC_DIST_SET_PENDING(irq + i, cm);
 }
 }
 } else if (offset < 0x300) {
-- 
2.35.3

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

[PATCH 2/2] hw/intc/arm_gic: Fix writes to GICD_ITARGETSRn

2024-05-07 Thread Sebastian Huber

According to the GICv2 specification section 4.3.12, "Interrupt Processor
Targets Registers, GICD_ITARGETSRn":

"Any change to a CPU targets field value:
[...]
* Has an effect on any pending interrupts. This means:
  - adding a CPU interface to the target list of a pending interrupt makes that
interrupt pending on that CPU interface
  - removing a CPU interface from the target list of a pending interrupt
removes the pending state of that interrupt on that CPU interface."

Signed-off-by: Sebastian Huber 
---
 hw/intc/arm_gic.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 20b3f701e0..79aee56053 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -1397,6 +1397,13 @@ static void gic_dist_writeb(void *opaque, hwaddr offset,
 value = ALL_CPU_MASK;
 }
 s->irq_target[irq] = value & ALL_CPU_MASK;
+if (irq >= GIC_INTERNAL && s->irq_state[irq].pending) {
+/*
+ * Changing the target of an interrupt that is currently
+ * pending updates the set of CPUs it is pending on.
+ */
+GIC_DIST_SET_PENDING(irq, value);
+}
 }
 } else if (offset < 0xf00) {
 /* Interrupt Configuration.  */
-- 
2.35.3

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

RTOS/RTEMS (rtems.git) history rewrite

2024-05-06 Thread Chris Johns

Hello,

A merge request was applied that contained a merge commit and a decision was
taken to correct this in the git repo. This means the history has been
rewritten. Please check your forks or clones if you have updated and pulled in
the merge commit.

We are looking into getting GitLab to flag this and block this from happening.

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

RTOS/RTEMS (rtems.git) history write

2024-05-06 Thread Chris Johns

Hello,

A merge request was applied that contained a merge commit and a decision was
taken to correct this in the git repo. This means the history has been
rewritten. Please check your forks or clones if you have updated and pulled in
the merge commit.

We are looking into getting GitLab to flag this and block this from happening.

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

Re: [PATCH] Fix the CPU count calculation error.

2024-05-06 Thread zhengxiaojun




在 2024/4/19 16:50, Sebastian Huber 写道:

On 19.04.24 09:16, zhengxiaojun wrote:
I tested on arm64, the cpu_count do not increase when 
(redist->icrtyper & GIC_REDIST_ICRTYPER_LAST != 0)，but it is the last 
core.


The current code assumes that you have exactly one interrupt export 
 I'm not quite clear about it. 
Could you explain it?
port. With which SoC are you working currently? One option could be to 
make the number of interrupt export ports configurable.




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

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-05-06 Thread Pavel Pisa

Dear Christian,

On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote:
> > For others, code under review hosted in CTU university GitLab
> > server
> >https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
> > Documentation 
> >
> > https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
> >
> > https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html
> >
> > Main developer behind extension to CAN FD and switch to RTEMS
> > is Michal Lenc.
> >
> > The intention is to (hopefully) reach state when it meets criteria
> > to mainlining int RTEMS CPU kit under
> >
> >cpukit/dev/can
...
> > I agree, that it is compromise. But adding yet another file descriptor
> > like multiplexor for queues to each file descriptor seems to me as
> > too much complexity. But it can be added. even later as IOCTL to remove
> > individual queues based on CAN ID matches or queues IDs if create
> > is modified to return internal queue IDs...
>
> I somehow missed that you can open the device multiple times and get
> independent queues. With that, it's completely OK and should be flexible
> enough for most applications.
>
> It's great that you already have put some thought into how it could be
> extended later if some application needs more flexibility.
...
> >> Did you check with
> >> some other hardware controller, whether the whole structures / defines
> >> / flags close to the hardware do work well for other controllers too?
> >
> > The code/concept is based on my previous LinCAN and OrtCAN work
> >
> > https://ortcan.sourceforge.net/lincan/
...
> I didn't want to doubt your competence. Like I said it's some trap that
> I have fallen into often enough myself (like when guiding Prashanths
> GSoC project). But it's clear that you have put a lot of thought into
> that. So I would expect that there shouldn't be much trouble with most
> controllers. Maybe except for the ones where a semiconductor vendor
> thought it would be a good idea to create a completely different
> concept. But these are always difficult.

I agree with discussion and searching for hard arguments.

The solution is compromise and in general CAN bus concept
is optimized for direct replacement of wires in car
going between distinc units and its use as general
communication solution has some difficulties and requires
some compromises.

For small devices with predefined purpose and Autosar,
it is ideal to allocate for each CAN ID (wire signal)
to be sent one communication object on the controller.
Same for each received signal value or their set in the
single frame. The most controllers are equipped by filters
and mechanism to do so including selection of the
Tx message object for physical bus-link arbitration
according to the priority. Then sending side updates
signal value in corresponding Tx object and receiving
side sees most actual one usually on the best effort basis,
older unread frames are overwritten by updated value.

But even in simple ECU, there are obstacles to use this
principle in all kind of the communication. CAN bus is used
for firmware updates and general configuration. In this
case, the reliable delivery of all messages with given
CAN ID is required because whole sequence has to be
received and processed and the state evolution is associated
to the sequence. If a single message is lost, then all
data are unusable. Because sequence requires exact ordering
it is typical that only single Tx object is used. On Rx
side there can be problem to capture all frames without
overwrite by single Rx object so some controllers ad FIFO
which can be attached to each object or some mechanism
how to allocate more Rx objects and pass them to the user
in FIFO order.

That works for small ECUs with single purpose firmware.
But on general purpose operating system which should
allow even complete monitoring of the CAN bus, allows
dynamically started applications and even whole virtual
CAN/CANopen nodes, allocation the controller Tx/Rx message
objects for each specific purpose is impossible.

That is why all generic CAN subsystems which I know
(CAN4Linux, LinCAN, SockteCAN, NuttX char device CAN,
windows Peak's drivers etc.) define API based on
opening driver and presenting received messages
in FIFO order to application (with options for software
filtering but usually not propagated to controller,
HW - LinCAN has some option to union user FIFOs to
mask and ID propagated to HW, but you usually end with
fully end with need to receve all anyway and it has not been
used at the end). The Tx FIFO order is required for messages
with same ID or even sometimes between same stream of mesages
even wit altering ID for correct realization of some higher
level protocols.

The result is that even on hardware equipped with multiple
Tx objects but without special Tx FIFO order preserving
cyclic queue only single Tx object is used to realize
transmission of all messages, for example SocketCAN on
XCAN controller. So only part of

Request for feedback on project proposal and documentation approach

2024-05-04 Thread Purva Yeshi

Hello Mentors, I have signed up for the RTEMS Gitlab platform. I am
proposing to use hackmd.io as a documentation tool to create blog posts
that detail my work progress. However, I am open to any other suggestions
or preferred platforms you may have in mind.

I would appreciate your feedback on my project proposal
.
Although I have put in a lot of effort to outline my goals and plans, I am
eager to hear your thoughts and suggestions for further improvement. It is
important to me that we are aligned on the objectives, and your insights
could help refine my project direction.

Additionally, I plan to collaborate with you to prepare an updated goal
plan that incorporates any feedback or suggestions you may have.
I am looking forward to hearing back from you soon.
Best regards, Purva Yeshi
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Deployment

2024-05-03 Thread Gedare Bloom

On Fri, May 3, 2024, 7:52 AM Joel Sherrill  wrote:

>
>
> On Thu, May 2, 2024 at 11:48 PM Chris Johns  wrote:
>
>> Hi,
>>
>> This email ask for the rtems-deployment repo to be moved RTEMS/Tools in
>> GitLab.
>>
>> It is a repo of RSB configs to build packages of common or user specific
>> vertical stacks.
>>
>
> I am in favor of it moving.
>

Same. I believe it has matured enough within Chris personal area.


> --joel
>
>>
>> Thanks
>> Chris
>> ___
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Deployment

2024-05-03 Thread Joel Sherrill

On Thu, May 2, 2024 at 11:48 PM Chris Johns  wrote:

> Hi,
>
> This email ask for the rtems-deployment repo to be moved RTEMS/Tools in
> GitLab.
>
> It is a repo of RSB configs to build packages of common or user specific
> vertical stacks.
>

I am in favor of it moving.

--joel

>
> Thanks
> Chris
> ___
> 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

RTEMS Deployment

2024-05-02 Thread Chris Johns

Hi,

This email ask for the rtems-deployment repo to be moved RTEMS/Tools in GitLab.

It is a repo of RSB configs to build packages of common or user specific
vertical stacks.

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

cgit

2024-05-02 Thread Chris Johns

Hello,

We will be shutting down cgit on git.rtems.org in coming days and the URL
redirected to GitLab. If you have personal repos with things you would like to
keep please make a local clone.

Thanks
Chris

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

Re: Cortex-M floating point (Was: RTEMS 6 branching)

On 2/5/2024 7:18 am, Cedric Berger wrote:
> Hello,
> 
> On 25.04.2024 02:16, Chris Johns wrote:
>> I know I am getting ahead of myself but once we have GiLab running and you 
>> have
>> a patch you would like merged please make a merge request.
> 
> Done:
> 
> https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/10
> 
> It worked really well.
> 

Yay and thanks for letting us know.

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

Submit Outstanding Patches Via GitLab

2024-05-01 Thread Joel Sherrill

Hi

If you have any patches that are still pending on the mailing list, please
get yourself an account on gitlab.rtems.org and submit them as a merge
request.

Instructions are linked to in Chris' emails.

Help is available on devel@ and Discord.

Thanks.

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

Re: [PATCH rtems-tools v5] tester/rtemstoolkit: add renode implementation

2024-05-01 Thread Joel Sherrill

gitlab.rtems.org is now alive.

Please setup an account and follow the instructions for a merge request.

We need to see how well things are working. :)

--joel

On Sun, Apr 28, 2024 at 11:35 PM Muhammad Sulthan Mazaya <
msulthanmaz...@gmail.com> wrote:

> Bumping last update of last year's renode porting result. Rebased to
> most recent commit on master.
>
> Fixing typo on renode_script/ folder that is changed to be renode/ in v4
>
> ---
>  .../testing/bsps/kendrytek210-renode.ini  |  38 
>  tester/rtems/testing/bsps/leon3-renode.ini|  37 
>  tester/rtems/testing/renode.cfg   |  64 ++
>  tester/rtems/testing/renode/kendrytek210.resc |  86 
>  tester/rtems/testing/renode/leon3-prom-gpl.S  | 205 ++
>  .../rtems/testing/renode/leon3-prom-gpl.bin   | Bin 0 -> 529 bytes
>  tester/rtems/testing/renode/leon3.resc|  82 +++
>  7 files changed, 512 insertions(+)
>  create mode 100644 tester/rtems/testing/bsps/kendrytek210-renode.ini
>  create mode 100644 tester/rtems/testing/bsps/leon3-renode.ini
>  create mode 100644 tester/rtems/testing/renode.cfg
>  create mode 100644 tester/rtems/testing/renode/kendrytek210.resc
>  create mode 100644 tester/rtems/testing/renode/leon3-prom-gpl.S
>  create mode 100755 tester/rtems/testing/renode/leon3-prom-gpl.bin
>  create mode 100644 tester/rtems/testing/renode/leon3.resc
>
> diff --git a/tester/rtems/testing/bsps/kendrytek210-renode.ini
> b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> new file mode 100644
> index 000..0cc48ae
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> @@ -0,0 +1,38 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright (C) 2023, 2023 Muhammad Sulthan Mazaya (
> msulthanmaz...@gmail.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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 HOLDER 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.
> +#
> +
> +#
> +# The Kendrytek210 Renode BSP
> +#
> +[kendrytek210-renode]
> +bsp = kendrytek210-renode
> +arch= riscv
> +tester  = %{_rtscripts}/renode.cfg
> +bsp_resc_script = %{_rtscripts}/renode/kendrytek210.resc
> diff --git a/tester/rtems/testing/bsps/leon3-renode.ini
> b/tester/rtems/testing/bsps/leon3-renode.ini
> new file mode 100644
> index 000..4ab013d
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/leon3-renode.ini
> @@ -0,0 +1,37 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright (C) 2023, 2023 Muhammad Sulthan Mazaya (
> msulthanmaz...@gmail.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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 HOLDER OR CONTRIBUTORS
> BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +#

Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-05-01 Thread Cedric Berger


Hello,

On 25.04.2024 02:16, Chris Johns wrote:

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request.


Done:

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/10

It worked really well.

Cedric

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

GitLab Workflows and Merge Requests

Hi RTEMS Community.

This email explains the Workflows and Merge Requests.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

The workflow is based around issues and merge requests. We use project forks as
the base of our workflow and outside of that there is no workflow we mandate.
What works for one task or work package may not work for another. Complex tasks
may affect a number of our GitLab Projects with issues and merge requests in a
number of projects. You may want to use an Epic to bring work together.

RTEMS will only accept changes via a Merge Request. This allows us to use the
Gitlab review and approval support which provides an easily accessible record of
the issue, code changes, and the reviews.

Workflows

With our GitLab instance, you fork a repo into your personal workspace and use
that to manage your changes. RTEMS will only accept changes via a Merge Request.
This allows us to use the Gitlab review and approval support which provides an
easily accessible record of the issue, code changes, and the reviews.

Issues and Merge Requests

Most merge requests will have a ticket however it is not always required.
Discussions can happen in merge requests and for simple isolated changes this is
fine.

Please do not use merge requests to introduce new code, concepts, styles or to
change existing behaviours such as APIs or internal interfaces. Please create an
issue before you start the work so the community is aware of the changes coming.
The merge requests can then focus on the details of the implementation and
approval does not need to be about approval of change at a functional level.

Merge Requests

1. We will work with forks of a project as we do not allow pushes to project
repos. This means you need to keep your forked project up to date.

https://docs.gitlab.com/ee/user/project/merge_requests/authorization_for_merge_requests.html#forking-workflow

2. If you are part of a team working on a change you can collaborate on merge
requests

https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaboration.html

3. You work on a fork of a project under your namespace, e.g. my user name is
chris and my namespace is https://gitlab.rtems.org/chris.

4. GitLab enforces branch naming rules and provides branch naming patterns to
help

https://docs.gitlab.com/ee/user/project/repository/branches/index.html#prefix-branch-names-with-issue-numbers

5. You can create a merge from your fork:

https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#when-you-work-in-a-fork

6. We do not normally squash merge requests. A merge request with more than one
commit should be buildable at each commit so a bisect of main does not
break.

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Issues in GitLab

Hi RTEMS Community.

This email explains RTEMS Issues in GitLab.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

All valid tickets in Trac have been brought across to GitLab. This is the fourth
move of this database and each move adds a layer of complexity as we align the
fields and data in the issues. We ask you to review issues in GitLab you are
working on or interested in long term and please make any suitable adjustments
if you think they are needed.  If you are curious we have gone from GNATS ->
Bugzilla -> Trac -> GitLab.

Trac Issues Import

Importing the Trac issues into GitLab was a complex time consuming task and
could not be done with GitLab launched and in use. As we could not bring the
Trac names across as the only accounts in GitLab were the RTEMS GitLab team. We
did not want to create user accounts and asking for user accounts to match
existing Trac accounts was difficult and fragile. The most pragmatic solution
was to strip the names we could not match.

Trac had a single issue database for all RTEMS projects and the projects shared
a single issue number. GitLab supports per-project issues with independent issue
numbers. We could not break up the single Trac database into the projects we
have in GitLab. As a result all Trac issues have been imported into the
RTOS/RTEMS project. The issue should have a label that details its origin.
Please do not move tickets from before #5004 from RTOS/RTEMS as it breaks the
history. Anything after RTOS/RTEMS issue #5004 can be moved.

New issues should be made in the related project, for example  make RSB tickets
in Tools/RTEMS Source Builder.

Issue Templates

We have basic issue and merge request templates located at
https://gitlab.rtems.org/rtems/gitlab-config/-/tree/main/.gitlab. The templates
will evolve as we learn to work with GitLab.

Assignee

We have imported all issues with the Assignee of “Trac Migrate”. If you have an
existing ticket in Trac and you would like to own the issue and its history in
GitLab please update the Assignee field. if the issue

Labels

GitLab only has labels so keywords and components have been consolidated as
labels. Please review existing issues in RTOS/RTEMS for examples on what to use.

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS Project Repos in GitLab

Hi RTEMS Community.

This email explains the RTEMS Project and Repos in GitLab.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

Note, GitLab failed to automatically identify the RTOS/RTEMS licence and it
incorrectly states it is Apache 2.0. It is not and no licences have changed. An
issue is open to sort this out.

GitLab lets you have repositories structured as projects. We have a top level
namespace called RTEMS and our repositories reside under this namespace. Having
everything under a single namespace lets us use a lot of cool GitLab features.
The link is https://gitlab.rtems.org/rtems.

We have some other namespaces alongside RTEMS such as Administration, Approvers
and Architecture. The projects in the top level namespace are place holders for
the groups we use across GitHub and groups let us control what users can do.
The Administration project is used to run GitLab and the servers we have at OSL
OSU. If you have found a bug or problem please raise an issue. If you have a
feature or a good idea please raise an issue. If you know an answer to an issue
that is open please answer.

The Architecture project lets us define groups of users who can own and approve
architecture specific parts of RTEMS. We have this at the top so architecture
owners can manage CI runners.

The top level RTEMS Project contains the following project groups:

 1. Documentation - Our documentation.

 2. Packages - The various packages we can build for RTEMS. Think of them
as 3rd party libraries

 3. Pre-Qualification - The pre-qualification projects based on the
recent ESA funded work

 4. RTOS - The real-time kernel, its examples and the release scripts

 5. Tools - Our ecosystem tools such as the RSB, RTEMS Tools and the
SIS simulator

 6. Programs - A place to organise activities similar or related to
Google Summer of Code

Main Branch

We have chosen this time to move from a master branch to main on all our repos.
Leaving the git.rtems.org repos open while we worked on GitLab meant the project
could continue to function as we deployed GitLab however we have had to make
commits in the GitLab repos to add files like CODEOWNERS and to test the
platform. The simplest solution for us is to roll any commits to git.rtems.org
into the GitLab repos before we go live. If you have maintained any waiting to
be merged on local branches in your repo you can rebase to the main branch. The
following is an example of how to switch an RTEMS git.rtems.org repo you use to
track RTEMS to RTEMS GitLab:

 1. The procedure assumes your local master branch matches the git.rtems.org
master branch and any changes you have are on local branches.

 2. Set the remote  origin to GitLab:
 git remote set-url origin 
ssh://g...@gitlab.rtems.org:/rtems/rtos/rtems.git

 3. Fetch the GitLab repo:
 git fetch

 4. Check out the GitLab main branch:
 git checkout main

 5. We recommend you delete your local master branch:
 git branch -D master

The following is an example of how to switch an RTEMS git.rtems.org repo you
have changed in you wish to post for review and merging to RTEMS GitLab:

 1. The procedure assumes your local master branch matches the git.rtems.org
master branch and any changes you have are on local branches.

 2. Fork the GitLab repo to your user account. Open the project repo in GitLab
and click Fork, located top right. You will need to select a namespace
and it needs to be the one based on your user name. Select the namespace
drop down in the Project URL field and scroll down or enter your user name
and click on the entry.

 3. Set the remote  origin to GitLab:
 git remote set-url origin ssh://g...@gitlab.rtems.org:/chris/rtems.git
Replace my user name with yours.

 4. Fetch the GitLab repo:
 git fetch

 5. Check out the GitLab main branch:
 git checkout main

 6. We recommend you delete your local master branch:
 git branch -D master

Merge Request Approvers

Every merge request in RTEMS requires two approvers. Approvers are organized as
members of subgroups within the top-level Approvers group
https://gitlab.rtems.org/approvers.

We have added initial CODEOWNERS files in GitLab that details which subgroups
own and approve merge requests. There are some members of the community who need
to be added to specific subgroups but we cannot add them until they have
accounts. If you want to be a code owner and approver please raise an
Administration issue. Anyone in the subgroup of “General Approver” is able to be
one of the approvers of  merge requests. However, at least one approver must
belong to a subgroup that is a code owner for a specific file or directory.
Self-approval by the author of the merge request is not allowed.

Please take a few minutes to look over the project structure. A project has its
own issues so when you want to create a new issue please add it to the project
it relates to. We can link issues across projects

RTEMS GitLab Sign In

Hi RTEMS Community.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

This email explains getting an account and signing onto GitLab.
We did not bring any of the existing accounts over to GitLab so you can create
and set up a new account that suits you. It also means we only end up with the
accounts for users who want access. Accounts are personal to you, we do not
allow shared accounts.

Creating an Account

To create an account head to our GitLab server at https://gitlab.rtems.org/ and
then click the “Register” link. If you happen to click “Sign In” click the
“Register now” link below the sign on in the “Don't have an account yet?” area.
The GitLab documentation on managing your Profile is
https://docs.gitlab.com/ee/user/profile/. You can use any email address and all
emails we send are personal emails to you.

Term of Service (TOS)

You will need to accept our TOS agreement for your account to be created. The
TOS covers code of conduct, contributed code licence and privacy policy. It also
covers your conduct if you are a code owner and approver.

Setting up 2FA and SSH key

We require you to use 2FA. A number of client apps should work. GitLab’s
documentation on 2FA is
https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html.
To clone a repo to make a merge request you will need to add an SSH key to your
account. The GitLab documentation to do this is
https://docs.gitlab.com/ee/user/ssh.html.

GitLab Roles

We have defined roles for the projects we have, for example GitLab
administrators, code owners, groups and approvers. We need accounts to complete
adding the roles we have in the project. If you have an existing role in the
RTEMS project, for example maintainer of an architecture, please make your
account and then please create an Administration issue detailing the roles you 
have

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-04-30 Thread Michal Lenc

Hi,

> OK. Maybe then it would be good to make some notes in which cases it's
> OK to add another flag to avoid that someone adds a lot of hardware
> dependent flags here.

Yes, we will add the description. Thanks.

> I assume if something is really very special to a specific hardware,
> the driver should get an extra driver specific IOCTL for that, right? 

Yes, this is already implemented, although not used for CTU CAN FD at
the moment. IOCTL calls not recognized by common layer in can-bus.c are
passed to the driver (if driver implements this functionality, otherwise
-EINVAL is returned immediately). So it is possible for driver to have
specific IOCTL calls.

Best regards,

Michal

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

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-04-30 Thread Christian MAUDERER


Hello Michal,

On 2024-04-29 22:48, Michal Lenc wrote:

Hello Christian,

thank you a lot for the review.


Thank you for your work.

In addition to Pavel Píša's reply, I 
have updated the documentation to provide (hopefully) a better description.


https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html



Thank you. I did take a look on some of the sections where I had some 
open questions, and it's already much clearer now.


I plan to enhance it further, I write it in parallel with my diploma 
thesis at the moment and sometimes I have the text already written in 
one document and not in the other one. So thank you for pointing out the 
parts where the description was not clear. I will address the changes in 
can_chip structure later this week.




Take your time.

Regarding future CAN controllers, I hope we will find some time and 
resources for the implementation of SJA1000 controller to our stack. 
Another interesting controller from our side would be MCAN since we have 
some projects with SAMv7 MCU. But those are more long term goals.




If that's the SAMV71 or SAME70 family: Be very careful with that 
controller and take a very thorough look at the Errata before you plan 
to use it in some productive system. It has some really horrible bugs. 
The worst ones that I encountered was that


1. I couldn't use SDRAM and USB at the same time because the SDRAM added 
a lot of jitter to the USB PLL.


2. Sometimes a conditioned branch instruction did take the wrong path (I 
verified the whole register values and assembly code multiple times 
before believing that it really happened).


I followed the errata quite some time. First there were more and more 
bugs related to SDRAM. Finally, Microchip just told that you should not 
use the SDRAM at all and removed the SDRAM chapter from the reference 
manual.


Of course, you can use the chip. But again: I would strongly recommend 
taking a really detailed look at the errata sheets for all peripherals 
that you plan to use.


Best regards

Christian


Thank you again for your input.

Best regards,

Michal Lenc

On 29. 04. 24 10:56, Christian MAUDERER wrote:

Hello Pavel,

it's quite a big work. So I've started to read through the
documentation to get an overview. Some questions:

Do I understand that correctly, that the only user-facing interface is
via the "/dev/can*" files. There is no separate interface for special
operations, right? That's completely OK for me. I just want to make
sure that I understand it correctly.


Chapter "1.1.1.1: Managing Queues": I assume the limitation that
RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
is a limitation due to the nature of the ioctl interface or the driver
capabilities? It could be a bit of an annoying limitation in an
application that dynamically wants to register or unregister queues.


Chapter "1.1.1.3: Setting Mode": These look quite controller specific.
If I want to add a controller that has a new mode: Would I just add a
new flag? What happens if we reach 33 flags? Would an array or maybe a
structure with a single uint32_t field be a better choice? I assume
that if a controller doesn't support a mode, (like setting FD on a
non-FD controller), the IOCTL will just return an error?


Chapter "1.1.3: Frame Transmission" and "1.1.4: Frame Reception": The
last argument of "write" is a count. If I see a write, my first guess
is that I have to call it like:

  struct can_frame frames[10] = {... /* some values */ ...};
  ssize_t rv = write( fd, frames, sizeof(frames) );

But from taking a look at the tests in the repository, the count
is calculated by can_framelen(). Is it possible to send or receive
multiple CAN frames using write or read? Or is it always a single
frame? What happens if I pass a wrong length? Do I send wrong data,
crash the system or the whole CAN bus or do I just get an error? Can
you make that more clear in the documentation?


Some details regarding "struct can_chip":

* There is a pointer called "type". I would use a "const char *" for
  that. I expect that stuff like names will never change and having
  them constant allows to use a pointer to a flash memory area.

* You have an "int irq". That's not fully compatible to the
  rtems_vector_number which is an uint32_t (at the moment).


Regarding the CAN drivers: Do I see it correctly, that currently only
a single (real) device is supported (ctucanfd)? Did you check with
some other hardware controller, whether the whole structures / defines
/ flags close to the hardware do work well for other controllers too?
Like the mode flags from 1.1.1.3. It doesn't really matter which other
controller. From my own attempts to write a driver stack, I just know
that sometimes you make assumptions based on one controller that are
hard to implement on another one. Usually it's not even necessary to
really add a second controller. Just skimming through the manual can
be really helpful. On the other hand, the Doxygen

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-04-30 Thread Christian MAUDERER

Hello Pavel,

thanks for your explanations.

On 2024-04-29 21:23, Pavel Pisa wrote:

Dear Christian,

thanks a lot for finding time to read through documentation.

On Monday 29 of April 2024 10:56:29 Christian MAUDERER wrote:

it's quite a big work. So I've started to read through the
documentation to get an overview.

For others, code under review hosted in CTU university GitLab
server

https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd

Documentation

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html

Main developer behind extension to CAN FD and switch to RTEMS
is Michal Lenc.

The intention is to (hopefully) reach state when it meets criteria
to mainlining int RTEMS CPU kit under

cpukit/dev/can

We plan to prefix all public functions by rtems_ prefix as the
final step after review and acceptance for mainline to not
pollute applications namespace. User visible structures
types for IOCTLs and farmes are planned to stay without
prefix for readability. They can be hidden by not including
given header file.

Some questions:
Do I understand that correctly, that the only user-facing interface is
via the "/dev/can*" files. There is no separate interface for special
operations, right? That's completely OK for me. I just want to make
sure that I understand it correctly.

Yes, it is the goal to use only character device as the only intreface
to the user application. LinCAN worked in standard POSIX environment
with MMU etc. and even on RTEMS we consider user and kernel
space as fully separated and only read, write, IOCTL exchange
data controlled way.

OK. That's reasonable.

There are more functions which are intended for drivers developers
and for registration from BSP.

I noted that the driver developer has a different interface.

Chapter "1.1.1.1: Managing Queues": I assume the limitation that
RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
is a limitation due to the nature of the ioctl interface or the driver
capabilities? It could be a bit of an annoying limitation in an
application that dynamically wants to register or unregister queues.

The single chip can be opened multiple times, each open instance
created their own canque_ends_user_t

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcanque__ends__user__t.html

This structure allows to connect FIFO queues (canque_edge_t) at any time
in any direction including echo to itself or some intermediate node
to send messages to more links for redundancy etc.

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcanque__edge__t.html

That is internal implementation which is intended to be really flexible
and with minimal locking intervals - only during move to next queue
during iterations.

But we are trying to keep external interface reasonably simple, so we consider
only queues from single user (file-descriptor) to single chip corresponding
to /dev/can during chosen during open for now.

The rationale for discard all only is that we if we allow manipulation of
individual queues we cannot identify queues by pointers. We take as forbidden
to expose kernel pointer addresses of canque_edge_t. It can be resolved
by assigning some unique numbers for each edge created from given user
ends and returning these to user from RTEMS_CAN_CREATE_QUEUE. The initial
default connection can have ID 0. Then it would be easy iterate over
all queues going to/from given user and remove only that queue where
the specified ID matches. Other option is to limit which queues will
be removed based on CAN ID and mask... but there can be problem to uniquely
match such queue etc...

So the compromise is taken. You can remove all queues to given open instance
and then add queues one by one as you want with controlled CAN ID
filters and priority.

If you need to create dynamically some application which needs specific
CAN IDs and priorities and then you expect that it should not interact
with network any more, then you can open /dev/canX again and you have
private queues pool. When the file representation is closed then all
these queues will be removed. That all without any influence
to other open instances to same or other CAN device {if we do not
consider system load).

I agree, that it is compromise. But adding yet another file descriptor
like multiplexor for queues to each file descriptor seems to me as
too much complexity. But it can be added. even later as IOCTL to remove
individual queues based on CAN ID matches or queues IDs if create
is modified to return internal queue IDs...

I somehow missed that you can open the device multiple times and get
independent queues. With that, it's completely OK and should be flexible
enough for most applications.

It's great that you already have put some thought into how it could be
extended later if some application needs more flexibility.

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-04-29 Thread Michal Lenc


Hello Christian,

thank you a lot for the review. In addition to Pavel Píša's reply, I 
have updated the documentation to provide (hopefully) a better description.


https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html

I plan to enhance it further, I write it in parallel with my diploma 
thesis at the moment and sometimes I have the text already written in 
one document and not in the other one. So thank you for pointing out the 
parts where the description was not clear. I will address the changes in 
can_chip structure later this week.


Regarding future CAN controllers, I hope we will find some time and 
resources for the implementation of SJA1000 controller to our stack. 
Another interesting controller from our side would be MCAN since we have 
some projects with SAMv7 MCU. But those are more long term goals.


Thank you again for your input.

Best regards,

Michal Lenc

On 29. 04. 24 10:56, Christian MAUDERER wrote:

Hello Pavel,

it's quite a big work. So I've started to read through the
documentation to get an overview. Some questions:

Do I understand that correctly, that the only user-facing interface is
via the "/dev/can*" files. There is no separate interface for special
operations, right? That's completely OK for me. I just want to make
sure that I understand it correctly.


Chapter "1.1.1.1: Managing Queues": I assume the limitation that
RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
is a limitation due to the nature of the ioctl interface or the driver
capabilities? It could be a bit of an annoying limitation in an
application that dynamically wants to register or unregister queues.


Chapter "1.1.1.3: Setting Mode": These look quite controller specific.
If I want to add a controller that has a new mode: Would I just add a
new flag? What happens if we reach 33 flags? Would an array or maybe a
structure with a single uint32_t field be a better choice? I assume
that if a controller doesn't support a mode, (like setting FD on a
non-FD controller), the IOCTL will just return an error?


Chapter "1.1.3: Frame Transmission" and "1.1.4: Frame Reception": The
last argument of "write" is a count. If I see a write, my first guess
is that I have to call it like:

  struct can_frame frames[10] = {... /* some values */ ...};
  ssize_t rv = write( fd, frames, sizeof(frames) );

But from taking a look at the tests in the repository, the count
is calculated by can_framelen(). Is it possible to send or receive
multiple CAN frames using write or read? Or is it always a single
frame? What happens if I pass a wrong length? Do I send wrong data,
crash the system or the whole CAN bus or do I just get an error? Can
you make that more clear in the documentation?


Some details regarding "struct can_chip":

* There is a pointer called "type". I would use a "const char *" for
  that. I expect that stuff like names will never change and having
  them constant allows to use a pointer to a flash memory area.

* You have an "int irq". That's not fully compatible to the
  rtems_vector_number which is an uint32_t (at the moment).


Regarding the CAN drivers: Do I see it correctly, that currently only
a single (real) device is supported (ctucanfd)? Did you check with
some other hardware controller, whether the whole structures / defines
/ flags close to the hardware do work well for other controllers too?
Like the mode flags from 1.1.1.3. It doesn't really matter which other
controller. From my own attempts to write a driver stack, I just know
that sometimes you make assumptions based on one controller that are
hard to implement on another one. Usually it's not even necessary to
really add a second controller. Just skimming through the manual can
be really helpful. On the other hand, the Doxygen documentation
mentions, that the concept is based on LinCAN. So maybe that already
helps to avoid that trap?


Regarding the device names "/dev/can0" and similar: Currently that
seems to be a fixed scheme, correct? In my experience, sometimes it
can be useful to use longer names instead. For example
"/dev/can_ctufd0". That's especially interesting if a system is
initialized dynamically. For example if you have a USB to CAN adapter
that is enumerated more or less randomly during startup. Is that
supported or are there some fixed assumptions that a can device is
always called "/dev/canX"?

Best regards

Christian


On 2024-04-27 11:53, Pavel Pisa wrote:

Dear RTEMS and CAN community,

I want to report another update in Michal Lenc work
on the generic CAN/CAN FD RTEMS stack.
The Sphinx and Doxygen documentation is generated by CI
on our faculty GitLab server. Links to RTEMS CAN resources
in the section

CAN/CAN FD Subsystem and Drivers for RTEMS
https://canbus.pages.fel.cvut.cz/#cancan-fd-subsystem-and-drivers-for-rtems 



Repository https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
Manual 
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
Doxygen

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-04-29 Thread Pavel Pisa

Dear Christian,

thanks a lot for finding time to read through documentation.

On Monday 29 of April 2024 10:56:29 Christian MAUDERER wrote:
> it's quite a big work. So I've started to read through the
> documentation to get an overview.

For others, code under review hosted in CTU university GitLab
server

  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd

Documentation

  https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
  https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html

Main developer behind extension to CAN FD and switch to RTEMS
is Michal Lenc.

The intention is to (hopefully) reach state when it meets criteria
to mainlining int RTEMS CPU kit under

  cpukit/dev/can

We plan to prefix all public functions by rtems_ prefix as the
final step after review and acceptance for mainline to not
pollute applications namespace. User visible structures
types for IOCTLs and farmes are planned to stay without
prefix for readability. They can be hidden by not including
given header file.

> Some questions: 
> Do I understand that correctly, that the only user-facing interface is
> via the "/dev/can*" files. There is no separate interface for special
> operations, right? That's completely OK for me. I just want to make
> sure that I understand it correctly.

Yes, it is the goal to use only character device as the only intreface
to the user application. LinCAN worked in standard POSIX environment
with MMU etc. and even on RTEMS we consider user and kernel
space as fully separated and only read, write, IOCTL exchange
data controlled way.

There are more functions which are intended for drivers developers
and for registration from BSP. 

> Chapter "1.1.1.1: Managing Queues": I assume the limitation that
> RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
> is a limitation due to the nature of the ioctl interface or the driver
> capabilities? It could be a bit of an annoying limitation in an
> application that dynamically wants to register or unregister queues.

The single chip can be opened multiple times, each open instance
created their own canque_ends_user_t

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcanque__ends__user__t.html

This structure allows to connect FIFO queues (canque_edge_t) at any time
in any direction including echo to itself or some intermediate node
to send messages to more links for redundancy etc. 

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcanque__edge__t.html

That is internal implementation which is intended to be really flexible
and with minimal locking intervals - only during move to next queue
during iterations.

But we are trying to keep external interface reasonably simple, so we consider
only queues from single user (file-descriptor) to single chip corresponding 
to /dev/can during chosen during open for now.

The rationale for discard all only is that we if we allow manipulation of 
individual queues we cannot identify queues by pointers. We take as forbidden
to expose kernel pointer addresses of canque_edge_t. It can be resolved
by assigning some unique numbers for each edge created from given user
ends and returning these to user from RTEMS_CAN_CREATE_QUEUE. The initial
default connection can have ID 0. Then it would be easy iterate over
all queues going to/from given user and remove only that queue where
the specified ID matches. Other option is to limit which queues will
be removed based on CAN ID and mask... but there can be problem to uniquely
match such queue etc...

So the compromise is taken. You can remove all queues to given open instance
and then add queues one by one as you want with controlled CAN ID
filters and priority.

If you need to create dynamically some application which needs specific
CAN IDs and priorities and then you expect that it should not interact
with network any more, then you can open /dev/canX again and you have
private queues pool. When the file representation is closed then all
these queues will be removed. That all without any influence
to other open instances to same or other CAN device {if we do not
consider system load). 

I agree, that it is compromise. But adding yet another file descriptor
like multiplexor for queues to each file descriptor seems to me as
too much complexity. But it can be added. even later as IOCTL to remove
individual queues based on CAN ID matches or queues IDs if create
is modified to return internal queue IDs... 

> Chapter "1.1.1.3: Setting Mode": These look quite controller specific.
> If I want to add a controller that has a new mode: Would I just add a
> new flag? What happens if we reach 33 flags? Would an array or maybe a
> structure with a single uint32_t field be a better choice? I assume
> that if a controller doesn't support a mode, (like setting FD on a
> non-FD controller), the IOCTL will just return an error?

I hope that these modes should be mostly controller

Re: GCC 14: m68k, sh, and sparc64

2024-04-29 Thread Joel Sherrill

On Sun, Apr 28, 2024 at 3:18 PM Joel Sherrill  wrote:

>
>
> On Sun, Apr 28, 2024 at 6:17 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello,
>>
>> the m68k, sh, and sparc64 build fails with GCC 14 due to:
>>
>
> Two of those are scheduled to be removed after we branch 6.
>
> So only the m68k really matters. More below.
>
>>
>> make "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2  -m4-single-only" "CCASFLAGS=-g
>> -O2  -m4-single-only" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET="
>> "INSTALL=/usr/bin/install -c" "LDFLAGS=-m4-single-only"
>> "LIBCFLAGS=-m4-single-only" "LIBCFLAGS_FOR_TARGET=" "MAKE=make"
>> "MAKEINFO=makeinfo --split-size=500" "PICFLAG="
>> "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest"
>> "RUNTESTFLAGS=" "exec_prefix=/tmp/sh/i-sh-rtems6"
>> "infodir=/tmp/sh/i-sh-rtems6/share/info"
>> "libdir=/tmp/sh/i-sh-rtems6/lib" "prefix=/tmp/sh/i-sh-rtems6"
>> "tooldir=/tmp/sh/i-sh-rtems6/sh-rtems6"
>> "top_toollibdir=/tmp/sh/i-sh-rtems6/sh-rtems6/lib/m4-single-only"
>> "AR=/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ar" "AS=as"
>> "CC=/tmp/sh/b-gcc-sh-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-sh-rtems6/./gcc/
>> -nostdinc -B/tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib/
>> -isystem
>> /tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib/targ-include
>> -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include
>> -B/tmp/sh/i-sh-rtems6/sh-rtems6/bin/
>> -B/tmp/sh/i-sh-rtems6/sh-rtems6/lib/ -isystem
>> /tmp/sh/i-sh-rtems6/sh-rtems6/include -isystem
>> /tmp/sh/i-sh-rtems6/sh-rtems6/sys-include  -m4-single-only" "LD=ld"
>> "LIBCFLAGS=-m4-single-only" "NM=" "PICFLAG="
>> "RANLIB=/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ranlib" "DESTDIR=" all-am
>> make[4]: Entering directory
>> '/tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib'
>>CC   libm/complex/libm_a-ccoshl.o
>> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c: In function
>> 'ccoshl':
>> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:13: error:
>> implicit declaration of function 'coshl'; did you mean 'coshf'?
>> [-Wimplicit-function-declaration]
>> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
>>| ^
>>| coshf
>> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:24: error:
>> implicit declaration of function 'cosl'; did you mean 'cosf'?
>> [-Wimplicit-function-declaration]
>> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
>>|^~~~
>>|cosf
>> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:35: error:
>> implicit declaration of function 'sinhl'; did you mean 'sinhf'?
>> [-Wimplicit-function-declaration]
>> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
>>|   ^
>>|   sinhf
>> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:46: error:
>> implicit declaration of function 'sinl'; did you mean 'sinf'?
>> [-Wimplicit-function-declaration]
>> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
>>|  ^~~~
>>|  sinf
>> make[4]: *** [Makefile:43178: libm/complex/libm_a-ccoshl.o] Error 1
>>
>> Implicit function declarations are an error by default in GCC 14. Joel,
>> could you please have a look at the long double support in Newlib since
>> you worked with it some time ago.
>>
>
> Looks like a file that probably should be disabled on targets without
> long double support. I'll try to dig into it.
>

I have a build with a gcc version that has this as a warning but duplicates
the underlying issue. I'll see what I can do.

>
> Please file an RSB issue once we get to gitlab. I think that's where these
> type of issues go now since it is gcc.
>
>>
>> --
>> embedded brains GmbH & Co. KG
>> 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: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-04-29 Thread Christian MAUDERER


Hello Pavel,

it's quite a big work. So I've started to read through the
documentation to get an overview. Some questions:

Do I understand that correctly, that the only user-facing interface is
via the "/dev/can*" files. There is no separate interface for special
operations, right? That's completely OK for me. I just want to make
sure that I understand it correctly.


Chapter "1.1.1.1: Managing Queues": I assume the limitation that
RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
is a limitation due to the nature of the ioctl interface or the driver
capabilities? It could be a bit of an annoying limitation in an
application that dynamically wants to register or unregister queues.


Chapter "1.1.1.3: Setting Mode": These look quite controller specific.
If I want to add a controller that has a new mode: Would I just add a
new flag? What happens if we reach 33 flags? Would an array or maybe a
structure with a single uint32_t field be a better choice? I assume
that if a controller doesn't support a mode, (like setting FD on a
non-FD controller), the IOCTL will just return an error?


Chapter "1.1.3: Frame Transmission" and "1.1.4: Frame Reception": The
last argument of "write" is a count. If I see a write, my first guess
is that I have to call it like:

  struct can_frame frames[10] = {... /* some values */ ...};
  ssize_t rv = write( fd, frames, sizeof(frames) );

But from taking a look at the tests in the repository, the count
is calculated by can_framelen(). Is it possible to send or receive
multiple CAN frames using write or read? Or is it always a single
frame? What happens if I pass a wrong length? Do I send wrong data,
crash the system or the whole CAN bus or do I just get an error? Can
you make that more clear in the documentation?


Some details regarding "struct can_chip":

* There is a pointer called "type". I would use a "const char *" for
  that. I expect that stuff like names will never change and having
  them constant allows to use a pointer to a flash memory area.

* You have an "int irq". That's not fully compatible to the
  rtems_vector_number which is an uint32_t (at the moment).


Regarding the CAN drivers: Do I see it correctly, that currently only
a single (real) device is supported (ctucanfd)? Did you check with
some other hardware controller, whether the whole structures / defines
/ flags close to the hardware do work well for other controllers too?
Like the mode flags from 1.1.1.3. It doesn't really matter which other
controller. From my own attempts to write a driver stack, I just know
that sometimes you make assumptions based on one controller that are
hard to implement on another one. Usually it's not even necessary to
really add a second controller. Just skimming through the manual can
be really helpful. On the other hand, the Doxygen documentation
mentions, that the concept is based on LinCAN. So maybe that already
helps to avoid that trap?


Regarding the device names "/dev/can0" and similar: Currently that
seems to be a fixed scheme, correct? In my experience, sometimes it
can be useful to use longer names instead. For example
"/dev/can_ctufd0". That's especially interesting if a system is
initialized dynamically. For example if you have a USB to CAN adapter
that is enumerated more or less randomly during startup. Is that
supported or are there some fixed assumptions that a can device is
always called "/dev/canX"?

Best regards

Christian


On 2024-04-27 11:53, Pavel Pisa wrote:

Dear RTEMS and CAN community,

I want to report another update in Michal Lenc work
on the generic CAN/CAN FD RTEMS stack.
The Sphinx and Doxygen documentation is generated by CI
on our faculty GitLab server. Links to RTEMS CAN resources
in the section

CAN/CAN FD Subsystem and Drivers for RTEMS
https://canbus.pages.fel.cvut.cz/#cancan-fd-subsystem-and-drivers-for-rtems

Repository https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
Manual 
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
Doxygen 
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html

CAN/CAN FD frame and header described there

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcan__frame.html

Feedback from everybody is welcomed. It would be especially
welcomed if Oliver has some remarks to can_frame_header
and can_frame field names because changes of these
start to be more painfull when/if project is accepted
into RTEMS mainline. Oliver is not probably on RTEMS
list, but I would forward reply there if it will not pass.

I have done initial update of our CAN/CANopen
framework from2003 year to be prepared to work with
new RTEMS solution. Only classic CAN frames for now,
FD is ignored

   https://ortcan.sourceforge.net/
   https://sourceforge.net/p/ortcan/ortcan-vca/commit_browser

Best wishes,

 Pavel
--
 Pavel Pisa

 phone:  +420 603531357
 e-mail: p...@cmp.felk.cvut.cz
 Department of

[PATCH rtems-source-builder v3] bare/config: add renode rsb installation config

2024-04-28 Thread Muhammad Sulthan Mazaya

Bumping last update of last year's renode porting result. Rebased to
most recent commit on master.

Change file name based on Chris's review here 
https://lists.rtems.org/pipermail/devel/2023-July/075802.html

Plus, fix `cp` so that it also include dotfiles. Because without the 
the `.renode-root` file the command won't work.

---
 bare/config/devel/renode-1.13.3-1.cfg | 11 ++
 bare/config/devel/renode.bset |  7 
 source-builder/config/renode-1.cfg|  6 +++
 source-builder/config/renode-common-1.cfg | 45 +++
 4 files changed, 69 insertions(+)
 create mode 100644 bare/config/devel/renode-1.13.3-1.cfg
 create mode 100644 bare/config/devel/renode.bset
 create mode 100644 source-builder/config/renode-1.cfg
 create mode 100644 source-builder/config/renode-common-1.cfg

diff --git a/bare/config/devel/renode-1.13.3-1.cfg 
b/bare/config/devel/renode-1.13.3-1.cfg
new file mode 100644
index 000..3b0b65f
--- /dev/null
+++ b/bare/config/devel/renode-1.13.3-1.cfg
@@ -0,0 +1,11 @@
+#
+# Renode from git
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%define renode_version 1.13.3
+
+%include %{_configdir}/renode-1.cfg
diff --git a/bare/config/devel/renode.bset b/bare/config/devel/renode.bset
new file mode 100644
index 000..f89168d
--- /dev/null
+++ b/bare/config/devel/renode.bset
@@ -0,0 +1,7 @@
+#
+# Build set for Renode
+#
+
+%define release 1
+
+devel/renode-1.13.3-1
diff --git a/source-builder/config/renode-1.cfg 
b/source-builder/config/renode-1.cfg
new file mode 100644
index 000..b203797
--- /dev/null
+++ b/source-builder/config/renode-1.cfg
@@ -0,0 +1,6 @@
+#
+#
+# This configuration file configure's, make's and install's Renode.
+#
+
+%include %{_configdir}/renode-common-1.cfg
diff --git a/source-builder/config/renode-common-1.cfg 
b/source-builder/config/renode-common-1.cfg
new file mode 100644
index 000..5c50298
--- /dev/null
+++ b/source-builder/config/renode-common-1.cfg
@@ -0,0 +1,45 @@
+#
+# Renode from git
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+Name:  renode-%{renode_version}-%{_host}-%{release}
+Summary:   Renode v%{renode_version}
+Version:   %{renode_version}
+Release:   %{release}
+URL:  http://www.renode.io
+
+#
+# Renode source
+# 
+%source set renode 
https://github.com/renode/renode/releases/download/v%{renode_version}/renode_%{renode_version}_source.tar.xz
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  source_dir_renode="renode_%{renode_version}_source"
+  %source setup renode -q -n renode_%{renode_version}_source
+
+  cd ${build_top}
+
+%build
+  build_top=$(pwd)
+
+  cd ${source_dir_renode}
+  ./build.sh
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  mkdir -p %{_bindir}
+  cp -r ./${source_dir_renode}/. %{_bindir}
+
+  cd ${build_top}
-- 
2.34.1

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

[PATCH rtems-docs] add renode docs

2024-04-28 Thread Muhammad Sulthan Mazaya

Bumping last update of last year's renode porting result. Rebased to
most recent commit on master.

Testing using renode docs. Consists of how to install it and how to add
new configuration to test BSP using renode.

---
 user/testing/index.rst  |  1 +
 user/testing/renode.rst | 84 +
 2 files changed, 85 insertions(+)
 create mode 100644 user/testing/renode.rst

diff --git a/user/testing/index.rst b/user/testing/index.rst
index 3d36fab..75e22a3 100644
--- a/user/testing/index.rst
+++ b/user/testing/index.rst
@@ -48,3 +48,4 @@ extension.
simulation
gdb-jtag
tftp
+   renode
diff --git a/user/testing/renode.rst b/user/testing/renode.rst
new file mode 100644
index 000..72b1946
--- /dev/null
+++ b/user/testing/renode.rst
@@ -0,0 +1,84 @@
+Testing Using Renode
+
+
+`Renode `_ is one of the simulators supported for testing
+BSPs using rtems-test. Currently, two BSPs are supported
+for testing via Renode: RISCV Kendryte K210 and SPARC Leon3. To use it,
+the host computer needs to have the necessary dependencies installed.
+
+1. Mono
+   Renode requires Mono >= 5.20 (Linux, macOS) or .NET >= 4.7 (Windows).
+
+   .. csv-table::
+   :delim: |
+
+   **Linux** | Install the ``mono-complete`` package as per the 
installation instructions for various Linux distributions, which can be found 
on `the Mono project website 
`_.
+   **macOS** | On macOS, the Mono package can be downloaded directly from 
`the Mono project website 
`_.
+   **Windows** | On Windows 7, download and install `.NET Framework 4.7 
`_. Windows 10 
ships with .NET by default, so no action is required.
+
+2. Other dependencies (Linux only)
+   On Ubuntu 20.04, you can install the remaining dependencies with the 
following command::
+
+  $ sudo apt-get install policykit-1 libgtk2.0-0 screen uml-utilities 
gtk-sharp2 libc6-dev gcc python3 python3-pip
+
+   If you are running a different distribution, you will need to install an 
analogous list of packages using your package manager; note that the package 
names may differ slightly.
+
+Installing Renode
+^
+
+All the dependencies are installed, you can go install Renode using the RTEMS 
Source Builder (the RSB).
+First, ``cd`` into the place where you put your RSB directory. Then you 
install Renode as follows::
+
+$ cd source-builder
+$ ../source-builder/sb-set-builder --prefix=$YOUR_PREFIX --trace 
--bset-tar-file renode
+
+Adding New BSP Test Config
+^^
+
+The implementation of Renode testing in ``rtems-test`` can be found in the 
rtems-tools repository
+at ``tester/rtems/renode`` folder. This folder contains all the ``resc`` 
scripts used to configure
+BSP testing with Renode. To add a new test configuration, you first need to 
check if the BSP is
+supported by Renode. You can do this by visiting `Renode's page that lists all 
supported boards 
+`_.
+
+If the board is listed there, you'll likely find an example ``resc`` script 
for a simple 
+testing configuration for the BSP in `Renode's GitHub repository 
+`_. You can 
then copy the 
+configuration to a new resc file in ``tester/rtems/renode``. The additional 
configuration that
+you need to add for it to work is the following::
+
+  showAnalyzer "uartAnalyzer" uart 
Antmicro.Renode.Analyzers.LoggingUartAnalyzer
+  uartAnalyzer TimestampFormat None
+
+  set report_repeating_line """
+  from Antmicro.Renode.Logging import ConsoleBackend 
+  ConsoleBackend.Instance.ReportRepeatingLines = True
+  """
+
+  set add_hook """
+  def my_match(line):
+  ok_to_kill_lines = [
+  '*** TEST STATE: USER_INPUT',
+  '*** TEST STATE: BENCHMARK',
+  '*** END OF TEST ',
+  '*** FATAL ***'
+  ]
+  return any(l in line for l in ok_to_kill_lines)
+
+  def my_hook(line):
+  print line
+  monitor.Parse("q")
+
+  
Antmicro.Renode.Hooks.UartHooksExtensions.AddLineHook(monitor.Machine["sysbus.uart"],
 my_match, my_hook)
+  """
+
+  python $add_hook
+
+  python $report_repeating_line 
+
+You need to add the above script configuration just before the ELF is loaded. 
In many cases,
+this is before the ``sysbus LoadELF`` line. The additional configuration is 
used to terminate the
+test according to the configuration of ``rtems-test`` and to map the test 
output to stdout.
+
+The next step is to delete the ``$bin`` variable definition from the example 
script. 
+This is because the ``$bin`` variable will be supplied via the ``renode.cfg`` 
file as the test binary.
-- 
2.34.1

___
devel mailing list

[PATCH rtems-tools v5] tester/rtemstoolkit: add renode implementation

2024-04-28 Thread Muhammad Sulthan Mazaya

Bumping last update of last year's renode porting result. Rebased to
most recent commit on master.

Fixing typo on renode_script/ folder that is changed to be renode/ in v4

---
 .../testing/bsps/kendrytek210-renode.ini  |  38 
 tester/rtems/testing/bsps/leon3-renode.ini|  37 
 tester/rtems/testing/renode.cfg   |  64 ++
 tester/rtems/testing/renode/kendrytek210.resc |  86 
 tester/rtems/testing/renode/leon3-prom-gpl.S  | 205 ++
 .../rtems/testing/renode/leon3-prom-gpl.bin   | Bin 0 -> 529 bytes
 tester/rtems/testing/renode/leon3.resc|  82 +++
 7 files changed, 512 insertions(+)
 create mode 100644 tester/rtems/testing/bsps/kendrytek210-renode.ini
 create mode 100644 tester/rtems/testing/bsps/leon3-renode.ini
 create mode 100644 tester/rtems/testing/renode.cfg
 create mode 100644 tester/rtems/testing/renode/kendrytek210.resc
 create mode 100644 tester/rtems/testing/renode/leon3-prom-gpl.S
 create mode 100755 tester/rtems/testing/renode/leon3-prom-gpl.bin
 create mode 100644 tester/rtems/testing/renode/leon3.resc

diff --git a/tester/rtems/testing/bsps/kendrytek210-renode.ini 
b/tester/rtems/testing/bsps/kendrytek210-renode.ini
new file mode 100644
index 000..0cc48ae
--- /dev/null
+++ b/tester/rtems/testing/bsps/kendrytek210-renode.ini
@@ -0,0 +1,38 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright (C) 2023, 2023 Muhammad Sulthan Mazaya (msulthanmaz...@gmail.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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 HOLDER 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.
+#
+
+#
+# The Kendrytek210 Renode BSP
+#
+[kendrytek210-renode]
+bsp = kendrytek210-renode
+arch= riscv
+tester  = %{_rtscripts}/renode.cfg
+bsp_resc_script = %{_rtscripts}/renode/kendrytek210.resc
diff --git a/tester/rtems/testing/bsps/leon3-renode.ini 
b/tester/rtems/testing/bsps/leon3-renode.ini
new file mode 100644
index 000..4ab013d
--- /dev/null
+++ b/tester/rtems/testing/bsps/leon3-renode.ini
@@ -0,0 +1,37 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright (C) 2023, 2023 Muhammad Sulthan Mazaya (msulthanmaz...@gmail.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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 HOLDER 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.
+#
+
+#
+# The Leon3 Renode BSP
+#
+[leon3-renode]
+bsp = leon3-renode
+arch= sparc
+tester  = %{_rtscripts}/renode.cfg

Re: GCC 14: m68k, sh, and sparc64

2024-04-28 Thread Joel Sherrill

On Sun, Apr 28, 2024 at 6:17 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> the m68k, sh, and sparc64 build fails with GCC 14 due to:
>

Two of those are scheduled to be removed after we branch 6.

So only the m68k really matters. More below.

>
> make "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2  -m4-single-only" "CCASFLAGS=-g
> -O2  -m4-single-only" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET="
> "INSTALL=/usr/bin/install -c" "LDFLAGS=-m4-single-only"
> "LIBCFLAGS=-m4-single-only" "LIBCFLAGS_FOR_TARGET=" "MAKE=make"
> "MAKEINFO=makeinfo --split-size=500" "PICFLAG="
> "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest"
> "RUNTESTFLAGS=" "exec_prefix=/tmp/sh/i-sh-rtems6"
> "infodir=/tmp/sh/i-sh-rtems6/share/info"
> "libdir=/tmp/sh/i-sh-rtems6/lib" "prefix=/tmp/sh/i-sh-rtems6"
> "tooldir=/tmp/sh/i-sh-rtems6/sh-rtems6"
> "top_toollibdir=/tmp/sh/i-sh-rtems6/sh-rtems6/lib/m4-single-only"
> "AR=/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ar" "AS=as"
> "CC=/tmp/sh/b-gcc-sh-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-sh-rtems6/./gcc/
> -nostdinc -B/tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib/
> -isystem
> /tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib/targ-include
> -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include
> -B/tmp/sh/i-sh-rtems6/sh-rtems6/bin/
> -B/tmp/sh/i-sh-rtems6/sh-rtems6/lib/ -isystem
> /tmp/sh/i-sh-rtems6/sh-rtems6/include -isystem
> /tmp/sh/i-sh-rtems6/sh-rtems6/sys-include  -m4-single-only" "LD=ld"
> "LIBCFLAGS=-m4-single-only" "NM=" "PICFLAG="
> "RANLIB=/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ranlib" "DESTDIR=" all-am
> make[4]: Entering directory
> '/tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib'
>CC   libm/complex/libm_a-ccoshl.o
> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c: In function
> 'ccoshl':
> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:13: error:
> implicit declaration of function 'coshl'; did you mean 'coshf'?
> [-Wimplicit-function-declaration]
> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
>| ^
>| coshf
> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:24: error:
> implicit declaration of function 'cosl'; did you mean 'cosf'?
> [-Wimplicit-function-declaration]
> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
>|^~~~
>|cosf
> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:35: error:
> implicit declaration of function 'sinhl'; did you mean 'sinhf'?
> [-Wimplicit-function-declaration]
> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
>|   ^
>|   sinhf
> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:46: error:
> implicit declaration of function 'sinl'; did you mean 'sinf'?
> [-Wimplicit-function-declaration]
> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
>|  ^~~~
>|  sinf
> make[4]: *** [Makefile:43178: libm/complex/libm_a-ccoshl.o] Error 1
>
> Implicit function declarations are an error by default in GCC 14. Joel,
> could you please have a look at the long double support in Newlib since
> you worked with it some time ago.
>

Looks like a file that probably should be disabled on targets without
long double support. I'll try to dig into it.

Please file an RSB issue once we get to gitlab. I think that's where these
type of issues go now since it is gcc.

>
> --
> embedded brains GmbH & Co. KG
> 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: GCC 14: nios2

2024-04-28 Thread Joel Sherrill

On Sun, Apr 28, 2024 at 6:13 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> in order to build the nios2 GCC 14, you have to add --enable-obsolete to
> the configure command line. With this option, it builds fine. I am not
> sure how this option can be added to the RSB just for this target.
>

This is an example from when I was experimenting with changing the multilib
set.

%define  gcc_configure_extra_options --with-multilib-list=rmprofile



>
> --
> embedded brains GmbH & Co. KG
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GCC 14: m68k, sh, and sparc64

2024-04-28 Thread Sebastian Huber


Hello,

the m68k, sh, and sparc64 build fails with GCC 14 due to:

make "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2  -m4-single-only" "CCASFLAGS=-g 
-O2  -m4-single-only" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=" 
"INSTALL=/usr/bin/install -c" "LDFLAGS=-m4-single-only" 
"LIBCFLAGS=-m4-single-only" "LIBCFLAGS_FOR_TARGET=" "MAKE=make" 
"MAKEINFO=makeinfo --split-size=500" "PICFLAG=" 
"PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" 
"RUNTESTFLAGS=" "exec_prefix=/tmp/sh/i-sh-rtems6" 
"infodir=/tmp/sh/i-sh-rtems6/share/info" 
"libdir=/tmp/sh/i-sh-rtems6/lib" "prefix=/tmp/sh/i-sh-rtems6" 
"tooldir=/tmp/sh/i-sh-rtems6/sh-rtems6" 
"top_toollibdir=/tmp/sh/i-sh-rtems6/sh-rtems6/lib/m4-single-only" 
"AR=/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ar" "AS=as" 
"CC=/tmp/sh/b-gcc-sh-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-sh-rtems6/./gcc/ 
-nostdinc -B/tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib/ 
-isystem 
/tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib/targ-include 
-isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include 
-B/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ 
-B/tmp/sh/i-sh-rtems6/sh-rtems6/lib/ -isystem 
/tmp/sh/i-sh-rtems6/sh-rtems6/include -isystem 
/tmp/sh/i-sh-rtems6/sh-rtems6/sys-include  -m4-single-only" "LD=ld" 
"LIBCFLAGS=-m4-single-only" "NM=" "PICFLAG=" 
"RANLIB=/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ranlib" "DESTDIR=" all-am
make[4]: Entering directory 
'/tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib'

  CC   libm/complex/libm_a-ccoshl.o
/home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c: In function 
'ccoshl':
/home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:13: error: 
implicit declaration of function 'coshl'; did you mean 'coshf'? 
[-Wimplicit-function-declaration]

   43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
  | ^
  | coshf
/home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:24: error: 
implicit declaration of function 'cosl'; did you mean 'cosf'? 
[-Wimplicit-function-declaration]

   43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
  |^~~~
  |cosf
/home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:35: error: 
implicit declaration of function 'sinhl'; did you mean 'sinhf'? 
[-Wimplicit-function-declaration]

   43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
  |   ^
  |   sinhf
/home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:46: error: 
implicit declaration of function 'sinl'; did you mean 'sinf'? 
[-Wimplicit-function-declaration]

   43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
  |  ^~~~
  |  sinf
make[4]: *** [Makefile:43178: libm/complex/libm_a-ccoshl.o] Error 1

Implicit function declarations are an error by default in GCC 14. Joel, 
could you please have a look at the long double support in Newlib since 
you worked with it some time ago.


--
embedded brains GmbH & Co. KG
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

GCC 14: nios2

2024-04-28 Thread Sebastian Huber


Hello,

in order to build the nios2 GCC 14, you have to add --enable-obsolete to 
the configure command line. With this option, it builds fine. I am not 
sure how this option can be added to the RSB just for this target.


--
embedded brains GmbH & Co. KG
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

[RSB 1/3] 6/7: Update Newlib

2024-04-27 Thread Sebastian Huber

Keep RTEMS up to date with the upstream development.
---
 rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-13-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
index 1627dac..33a73c8 100644
--- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
@@ -14,12 +14,12 @@
 %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
 %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch 
afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
 
-%define newlib_version 176b19f
+%define newlib_version 730703b
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
ZUzGjXI3ZJ6GrxMXggg+jIO0nyi+edKoilckRxtujsOiwhOyITahIqcOHhZiX5nd4E4UX9p3BSDima/Fd0Gr0w==
+  
To+Y9HgOQIVkjDPUIZninoXtsHNvBXzkMhHw5WgzJlk3WoajUko/QRRowPVqJOfVYOALXXbPeRS1ermxuFCWDA==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
index 315f70b..84dfe32 100644
--- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
@@ -17,12 +17,12 @@
 %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
 %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch 
afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
 
-%define newlib_version 176b19f
+%define newlib_version 730703b
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
ZUzGjXI3ZJ6GrxMXggg+jIO0nyi+edKoilckRxtujsOiwhOyITahIqcOHhZiX5nd4E4UX9p3BSDima/Fd0Gr0w==
+  
To+Y9HgOQIVkjDPUIZninoXtsHNvBXzkMhHw5WgzJlk3WoajUko/QRRowPVqJOfVYOALXXbPeRS1ermxuFCWDA==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
index 4387486..0d34c85 100644
--- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
@@ -34,13 +34,13 @@
 
KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
 # Comment above related to #4657 and patches ends here
 
-%define newlib_version 176b19f
+%define newlib_version 730703b
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \

https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
ZUzGjXI3ZJ6GrxMXggg+jIO0nyi+edKoilckRxtujsOiwhOyITahIqcOHhZiX5nd4E4UX9p3BSDima/Fd0Gr0w==
+  
To+Y9HgOQIVkjDPUIZninoXtsHNvBXzkMhHw5WgzJlk3WoajUko/QRRowPVqJOfVYOALXXbPeRS1ermxuFCWDA==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
index 4dbbd9b..874a9f3 100644
--- a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
@@ -8,12 +8,12 @@
 %hash sha512 %{gcc_expand_name}.tar.gz \
   
UAXjyfPP883wjLDnobDk4wmg/vAO0I4LjzzurLCKejj0FUSk0KvlkVj1CF+3XwFcdlCWRhN7z/Ls4fOunafe9w==
 
-%define newlib_version 176b19f
+%define newlib_version 730703b
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
ZUzGjXI3ZJ6GrxMXggg+jIO0nyi+edKoilckRxtujsOiwhOyITahIqcOHhZiX5nd4E4UX9p3BSDima/Fd0Gr0w==
+  
To+Y9HgOQIVkjDPUIZninoXtsHNvBXzkMhHw5WgzJlk3WoajUko/QRRowPVqJOfVYOALXXbPeRS1ermxuFCWDA==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg

[RSB 2/3] 6: Update GCC 12 and 13

2024-04-27 Thread Sebastian Huber

Keep RTEMS up to date with the upstream development.

For GCC 13, this includes a new set of aarch64 multilibs to address Cortex-A53
workarounds and fixes for powerpc.
---
 rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gcc-13-newlib-head.cfg | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
index 0d34c85..2c32dbb 100644
--- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
@@ -1,12 +1,12 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gcc_version a285310
+%define gcc_version 5705761
 %define gcc_external 1
 %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
 %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
 %hash sha512 %{gcc_expand_name}.tar.gz \
-  
sYxUkDJD7qaCzXndAljnAQMbmssg7AY97cBAMjwqDSC6vxseGSzvO8LGMW46ASM6Zq2frKj8XVj27GnPmwSIXQ==
+  
UDkzSz2uzFzsQ5CfhVz+guUk9Y6UEgWVSRtAHRyhKt+w6aDgEjsDT2JyOErCOATqZQWrK2ZaqDEh7lczz0/vvw==
 
 %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch
 %hash sha512 0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch \
diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
index 874a9f3..1d5959f 100644
--- a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
@@ -1,12 +1,12 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gcc_version 54a235e
+%define gcc_version 67ec6b8
 %define gcc_external 1
 %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
 %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
 %hash sha512 %{gcc_expand_name}.tar.gz \
-  
UAXjyfPP883wjLDnobDk4wmg/vAO0I4LjzzurLCKejj0FUSk0KvlkVj1CF+3XwFcdlCWRhN7z/Ls4fOunafe9w==
+  
XrL345Kt/jd7umjECzc+dWWeiIuN0mXw/Pta5AcZUzqkIaLXXGwNC2mTNJVHRzS4eRc/XnYaaRbHYRfnwXzlLw==
 
 %define newlib_version 730703b
 %define newlib_external 1
-- 
2.35.3

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

[RSB 3/3] 7: Update Binutils, GDB, and GCC

2024-04-27 Thread Sebastian Huber

Keep RTEMS up to date with the upstream development.  This snapshot is close to
the GCC 14 release.
---
 rtems/config/tools/rtems-binutils-head.cfg| 4 ++--
 rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gdb-head.cfg | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/rtems/config/tools/rtems-binutils-head.cfg 
b/rtems/config/tools/rtems-binutils-head.cfg
index 3516d2c..a3ee877 100644
--- a/rtems/config/tools/rtems-binutils-head.cfg
+++ b/rtems/config/tools/rtems-binutils-head.cfg
@@ -1,12 +1,12 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define binutils_version eb42bb1
+%define binutils_version 94f7532
 %define binutils_external 1
 %define binutils_expand_name sourceware-mirror-binutils-gdb-%{binutils_version}
 %source set binutils --rsb-file=%{binutils_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{binutils_version}
 %hash sha512 %{binutils_expand_name}.tar.gz \
-  
qDuLOqwQ/kQX30hIu5UVDqMuKjnpoKTEZ4xo85lrzq6VtnCd6nwdO5t9szbhJc4P1UWww9rRNMcqj7d2BKeNqg==
+  
9UXnhlQrz87/NJ4rDU/m0nYAbaDJWY8/WA1VBqyOboY3QquejzNNGIHRd2I4p5B6pVmcDRX0Wa5/Io4+AOdmNw==
 
 %define with_deterministic_archives 1
 %define with_64_bit_bfd 1
diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
index af8957a..f13f7c6 100644
--- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
@@ -1,12 +1,12 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gcc_version 41aacde
+%define gcc_version 140124a
 %define gcc_external 1
 %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
 %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
 %hash sha512 %{gcc_expand_name}.tar.gz \
-  
xPwSCLLXsJfFKontgrGlU9ep/PVlP3bQOGbgRCG0mj8sD5dq2ifo5VOwGwVMRQD0VFVVOWqeykq3OVkZYlu1GA==
+  
F4l7XA1+KIyuX+IAsCPMcuDU1UVN1VZqkSyA3ppA8woc2+NbygqeNYLlfMkWZDU8fw2ASo7Z0KMd5LYz28iqjQ==
 
 %define newlib_version 730703b
 %define newlib_external 1
diff --git a/rtems/config/tools/rtems-gdb-head.cfg 
b/rtems/config/tools/rtems-gdb-head.cfg
index 17ecee8..f908c63 100644
--- a/rtems/config/tools/rtems-gdb-head.cfg
+++ b/rtems/config/tools/rtems-gdb-head.cfg
@@ -1,11 +1,11 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gdb_version eb42bb1
+%define gdb_version 94f7532
 %define gdb_external 1
 %define gdb_expand_name sourceware-mirror-binutils-gdb-%{gdb_version}
 %source set gdb --rsb-file=%{gdb_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{gdb_version}
 %hash sha512 %{gdb_expand_name}.tar.gz \
-  
qDuLOqwQ/kQX30hIu5UVDqMuKjnpoKTEZ4xo85lrzq6VtnCd6nwdO5t9szbhJc4P1UWww9rRNMcqj7d2BKeNqg==
+  
9UXnhlQrz87/NJ4rDU/m0nYAbaDJWY8/WA1VBqyOboY3QquejzNNGIHRd2I4p5B6pVmcDRX0Wa5/Io4+AOdmNw==
 
 %include %{_configdir}/gdb-8-1.cfg
-- 
2.35.3

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

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

2024-04-27 Thread Pavel Pisa

Dear RTEMS and CAN community,

I want to report another update in Michal Lenc work
on the generic CAN/CAN FD RTEMS stack.
The Sphinx and Doxygen documentation is generated by CI
on our faculty GitLab server. Links to RTEMS CAN resources
in the section

CAN/CAN FD Subsystem and Drivers for RTEMS
https://canbus.pages.fel.cvut.cz/#cancan-fd-subsystem-and-drivers-for-rtems

Repository https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
Manual 
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
Doxygen 
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html

CAN/CAN FD frame and header described there

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcan__frame.html

Feedback from everybody is welcomed. It would be especially
welcomed if Oliver has some remarks to can_frame_header
and can_frame field names because changes of these
start to be more painfull when/if project is accepted
into RTEMS mainline. Oliver is not probably on RTEMS
list, but I would forward reply there if it will not pass.

I have done initial update of our CAN/CANopen
framework from2003 year to be prepared to work with
new RTEMS solution. Only classic CAN frames for now,
FD is ignored 

  https://ortcan.sourceforge.net/
  https://sourceforge.net/p/ortcan/ortcan-vca/commit_browser

Best wishes,

Pavel
--
Pavel Pisa

phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
company:https://pikron.com/ PiKRON s.r.o.
Kankovskeho 1235, 182 00 Praha 8, Czech Republic
projects:   https://www.openhub.net/accounts/ppisa
social: https://social.kernel.org/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home



On Friday 05 of April 2024 12:38:28 Pavel Pisa wrote:
> Hello everybody,
>
> Michal Lenc has updated the project to switch from RTEMS
> semaphores allocated with object ID to self-contained
> ones according to the previous response that self-contained
> objects are preferred. Se actual state in the repo
>
>   https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
>
> The both cases of switching to self-contained objects
> (interrupt_lock -> rtems_lock )
> (rtems_semaphore_create -> rtems_binary_semaphore_init)
> seems to cause measurable increase of overhead in the
> performace testing of the virtual CAN interface
> on Zynq platform. The real communication performance
> does not changed significantly when actual frame sending
> time on the wire is in the loop. But that is the first
> glimpse result only, we may find time for more evaluation
> and even integration of RTEMS to our continuous tests
> setup some day.
>
> Michal Lenc's thesis submission deadline is approaching
> and we would like to have some feedback to start preparation
> of proposal to integrate code into official RTEMS cpukit.
>
> We will be both available at Embedded World Exhibition
> and I will even present the article about CAN/CAN FD
> latency in Linux kernel at the ewC conference
>
>  April 9, 4:00 PM - 5:45 PM
>  Session 2.3 CONNECTIVITY SOLUTIONS
>  Continuous CAN Bus Subsystem Latency Evaluation and Stress Testing
>  on GNU/Linux-Based Systems
>  https://canbus.pages.fel.cvut.cz/#can-bus-channels-mutual-latency-testing
>
> We will take some species from our hardware ZOO and will
> show them on https://www.osadl.org/ booth OSADL booth in hall 4, booth
> 4-168 so if you want to contact us, you can stop there. We will have
> Linux, RTEMS booted MZ_APO kits there and some other
> Linux, NuttX ARM and RISC-V boards. Even if we are
> not presnet at the moment on the booth, OSADL colleagues will have
> contact to us. If there is some RTEMS meeting, we will try
> to reserve time.
>
> Best wishes,
>
> Pavel
> --
> Pavel Pisa
> phone:  +420 603531357
> e-mail: p...@cmp.felk.cvut.cz
> Department of Control Engineering FEE CVUT
> Karlovo namesti 13, 121 35, Prague 2
> university: http://control.fel.cvut.cz/
> personal:   http://cmp.felk.cvut.cz/~pisa
> social: https://social.kernel.org/ppisa
> projects:   https://www.openhub.net/accounts/ppisa
> CAN related:http://canbus.pages.fel.cvut.cz/
> RISC-V education: https://comparch.edu.cvut.cz/
> Open Technologies Research Education and Exchange Services
> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>
> On Wednesday 13 of March 2024 17:01:30 Michal Lenc wrote:
> > Dear RTEMS developers,
> >
> > we have made a progress with our CAN stack and virtual/CTU CAN FD
> > controller tests using standard x86-64 QEMU. We can now provide scripts
> > that build the stack

GitLab Launch

2024-04-26 Thread Chris Johns

Hi RTEMS Community.

We will be launching GitLab during the 1st May 2024. You can access RTEMS GitLab
(RGL) at:

  https://gitlab.rtems.org/

Account creation will be enabled on the 1st May 2024.

The goal of the move to GitLab is to modernise our workflow reducing the burden
of merging patches into our project and making it easier to send in changes. We
are excited to accept merge requests in GitLab and we hope this brings more
people into the project and it encourages users to submit back to the project.

The move to Gitlab means we need to change our workflow. You will need a GitLab
account with 2FA and if you wish to create merge requests you will need to add
an SSH key. Additionally, some repos have changed names and the URL in any repos
you currently have cloned will need updating. The issues in Trac have been moved
to GitLab and may need review and updating.

The development list (devel*..) will no longer be used for patches. Any patches
are not merged from devel@ will need to be turned into a merge request to be
merged. Discussions about patches can happen in merge requests.

I will be sending the following emails to help explains the steps you need work
through and how things will work:

 1. Signing on to RTEMS GitLab
 2. RTEMS Project Repos in GitLab
 3. RTEMS Issues in GitLab
 4. Workflows and Merge Requests

These emails are an introduction. Our documentation is a work in progress and we
ask you to consider creating merge requests to update it if things are missing
or not clear. We welcome contributions from the community to get this work
completed. What we present at the beginning is a starting point.

With GitLab active we can finish some remaining server upgrade work. We will be
taking service2.rtems.org down to upgrade it. The server currently hosts Trac,
docs, mailman web, cgit and more. We were asked by OSU OSL, who host our
servers, to do this and it has taken us a couple of years to get to a point we
can. I would like to thank Lance at OSU OSL for his patience and understanding.
I personally appreciate this and I am sure the community does as well.

This is not the end of the server work we would like to do however it is the end
of the current funding. If you would like to donate to help support the server
work please reach out to Joel and I. The funding can be handled confidentially
if that is important. We need funding to improve the services we provide so
please consider helping.

Finally I would like to thank Amar for his hard work and diligence in bringing
this all together. I appreciate the hours you have put in. Awesome effort. I
would also like to thank Joel, Gedare and Kinsey for putting in the hours each
week over the past months to help make this happen.

If you need help please join the #gitlab-support channel on our Discord server.
It is open to posts and questions. You can find our invite link here
https://www.rtems.org/discord. We will also respond to posts on this list when
we have the time.

Regards
Chris Johns
RTEMS GitLab Team

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

Re: Repo Transition to GitLab

2024-04-26 Thread Joel Sherrill

On Fri, Apr 26, 2024, 12:49 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 26.04.24 00:38, Chris Johns wrote:
> > Hi RTEMS Community
> >
> > The git repos on git.rtems.org are open and accepting patches. The
> GitLab repos
> > will move us to main, something we have been waiting to do. Allowing
> commits
> > into the repos means they will be brought across and played on top of
> the new
> > main branch. We have changes in the repo on GitLab as part of our
> testing and
> > new files such as CODEOWNERS.
> >
> > As a result you will check out main and not rename your master to main.
>
> When will the GitLab available? I can wait with my pending patches so
> that the associated tickets get updated when they are checked in.

The plan is to go live May 1. We expect people to run into minor things we
may have missed in the transition. Discord and devel@ are always there for
help.

How
> will the ticket updates work in GitLab?

When there is a ticket, make a merge request from that. Add your patches.
When ready it will need a review. Comments are made in the UI and need to
be resolved. Then it needs an approval. This is the normal gitlab way.

You can have a branch and MR without an issue.

Whether every change requires an issue is a project process decision but
the lean is to no. You do have to get review and approval.

Approval can come from a larger set of people now.

Are the ticket numbers the same?
>

I checked your isr priority one and it is the same. I think they all were
preserved for rtems. Some were assigned to other repos/projects and those
appear to have new numbers.

--joel

>
> --
> embedded brains GmbH & Co. KG
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Repo Transition to GitLab


On 26.04.24 00:38, Chris Johns wrote:

Hi RTEMS Community

The git repos on git.rtems.org are open and accepting patches. The GitLab repos
will move us to main, something we have been waiting to do. Allowing commits
into the repos means they will be brought across and played on top of the new
main branch. We have changes in the repo on GitLab as part of our testing and
new files such as CODEOWNERS.

As a result you will check out main and not rename your master to main.


When will the GitLab available? I can wait with my pending patches so 
that the associated tickets get updated when they are checked in. How 
will the ticket updates work in GitLab? Are the ticket numbers the same?


--
embedded brains GmbH & Co. KG
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

Repo Transition to GitLab

2024-04-25 Thread Chris Johns

Hi RTEMS Community

The git repos on git.rtems.org are open and accepting patches. The GitLab repos
will move us to main, something we have been waiting to do. Allowing commits
into the repos means they will be brought across and played on top of the new
main branch. We have changes in the repo on GitLab as part of our testing and
new files such as CODEOWNERS.

As a result you will check out main and not rename your master to main.

Regards
Chris
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RFC v2] rtems: Add options to kernel output char handler

Make the kernel I/O output character device processing configurable
through an option set parameter.  Add RTEMS_IO_NO_OUTPUT and
RTEMS_IO_DRAIN options.  The goal of this API change is to enable
draining the kernel output device in the system termination process
before a reset is issued.  A use case for using RTEMS_NO_WAIT is the
polled processing of an input and output stream from and to the I/O
device.
---
v2:

* Do not use EARS.

* Rename RTEMS_FLUSH in RTEMS_IO_DRAIN.

* Rename RTEMS_NO_OUTPUT in RTEMS_IO_NO_TRANSMISSION.

* Add example adoption for sparc/leon3.

 bsps/sparc/leon3/console/printk_support.c | 54 +++---
 cpukit/include/rtems/bspIo.h  | 55 ++-
 cpukit/include/rtems/rtems/options.h  | 22 -
 cpukit/libcsupport/src/rtems_putc.c   |  4 +-
 testsuites/validation/tc-io-put-char.c|  8 +++-
 testsuites/validation/tr-io-kernel.c  |  4 +-
 6 files changed, 132 insertions(+), 15 deletions(-)

diff --git a/bsps/sparc/leon3/console/printk_support.c 
b/bsps/sparc/leon3/console/printk_support.c
index fd23a5033f..adfd653060 100644
--- a/bsps/sparc/leon3/console/printk_support.c
+++ b/bsps/sparc/leon3/console/printk_support.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -56,6 +57,11 @@ apbuart *leon3_debug_uart = NULL;
 
 static void bsp_debug_uart_init(void);
 
+static bool apbuart_can_transmit(apbuart *regs)
+{
+  return (grlib_load_32(>status) & APBUART_STATUS_TE) != 0;
+}
+
 static void apbuart_enable_receive_and_transmit(apbuart *regs)
 {
   uint32_t ctrl;
@@ -66,10 +72,38 @@ static void apbuart_enable_receive_and_transmit(apbuart 
*regs)
   grlib_store_32(>status, 0);
 }
 
-static void bsp_debug_uart_output_char(char c)
+static rtems_status_code bsp_debug_uart_output_char(
+  char c,
+  rtems_option option_set
+)
 {
-  apbuart_outbyte_polled(leon3_debug_uart, c);
-  apbuart_outbyte_wait(leon3_debug_uart);
+  apbuart *regs = leon3_debug_uart;
+  rtems_status_code status = RTEMS_SUCCESSFUL;
+
+  while (true) {
+if (apbuart_can_transmit(regs)) {
+  if ((option_set & RTEMS_IO_NO_TRANSMISSION) == 0) {
+grlib_store_32(>data, (uint8_t) c);
+  }
+
+  break;
+}
+
+if ((option_set & RTEMS_NO_WAIT) != 0) {
+  status = RTEMS_UNSATISFIED;
+  break;
+}
+
+_IO_Relax();
+  }
+
+  if ((option_set & RTEMS_IO_DRAIN) != 0) {
+while (!apbuart_can_transmit(regs)) {
+  _IO_Relax();
+}
+  }
+
+  return status;
 }
 
 static int bsp_debug_uart_poll_char(void)
@@ -77,10 +111,13 @@ static int bsp_debug_uart_poll_char(void)
   return apbuart_inbyte_nonblocking(leon3_debug_uart);
 }
 
-static void bsp_debug_uart_pre_init_out(char c)
+static rtems_status_code bsp_debug_uart_pre_init_out(
+  char c,
+  rtems_option option_set
+)
 {
   bsp_debug_uart_init();
-  (*BSP_output_char)(c);
+  return (*BSP_output_char)(c, option_set);
 }
 
 #if defined(LEON3_APBUART_BASE)
@@ -94,9 +131,14 @@ static void bsp_debug_uart_init(void)
 
 #else /* !LEON3_APBUART_BASE */
 
-static void bsp_debug_uart_discard(char c)
+static rtems_status_code bsp_debug_uart_discard(
+  char c,
+  rtems_option option_set
+)
 {
   (void) c;
+  (void) option_set;
+  return RTEMS_SUCCESSFUL;
 }
 
 /* Initialize the BSP system debug console layer. It will scan AMBA Plu
diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
index 31580cd800..7848704992 100644
--- a/cpukit/include/rtems/bspIo.h
+++ b/cpukit/include/rtems/bspIo.h
@@ -10,7 +10,7 @@
  */
 
 /*
- * Copyright (C) 2020, 2021 embedded brains GmbH & Co. KG
+ * Copyright (C) 2020, 2024 embedded brains GmbH & Co. KG
  * Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
  *
  * Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,8 @@
 #define _RTEMS_BSPIO_H
 
 #include 
+#include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -89,8 +91,48 @@ extern "C" {
  * @ingroup RTEMSAPIKernelCharIO
  *
  * @brief Polled character output functions shall have this type.
+ *
+ * @param out is the character to transmit.
+ *
+ * @param option_set is the option set.
+ *
+ * The behaviour of polled character output functions can be controlled by the
+ * three options #RTEMS_NO_WAIT, #RTEMS_IO_NO_TRANSMISSION, and #RTEMS_IO_DRAIN
+ * specified in the ``option_set`` parameter.
+ *
+ * If the #RTEMS_NO_WAIT option is set in the ``option_set`` parameter and the
+ * device cannot immediately accept a character for transmission, then the
+ * character in ``out`` shall not be transmitted by the device, optionally the
+ * device shall be drained, and ::RTEMS_UNSATISFIED shall be returned.
+ *
+ * If the #RTEMS_IO_NO_TRANSMISSION option is set in the ``option_set``
+ * parameter, the character in the ``out`` parameter shall not be transmitted
+ * by the device.
+ *
+ * If the #RTEMS_NO_WAIT and #RTEMS_IO_NO_TRANSMISSION options are cleared in
+ * the ``option_set`` parameter, then the character in the

Re: [PATCH v2] rtems: Add get/set interrupt priorities


On 16.04.24 07:25, Sebastian Huber wrote:

On 09.04.24 16:28, Sebastian Huber wrote:

Add directives to get and set the priority of an interrupt vector.

Implement the directives for the following BSP families:

* arm/lpc24xx
* arm/lpc32xx
* powerpc/mpc55xxevb
* powerpc/qoriq

Implement the directives for the following interrupt controllers:

* GICv2 and GICv3 (arm and aarch64)
* NVIC (arm)
* PLIC (riscv)

Update #5002.


Any comments to this API extension?


If there are no objections, then I will commit this patch set next Monday.

--
embedded brains GmbH & Co. KG
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: Cortex-M floating point (Was: RTEMS 6 branching)


On 24.04.24 14:37, Cedric Berger wrote:

Hello Sebastian,

On 23.04.2024 19:56, Sebastian Huber wrote:

1. Are all the things need for the release resolved? Tickets reviewed?

It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
Cortex-M floating point issue is not yet fixed in the RTEMS master.


Do you have any feedback on the two patches that I posted on the ticket, 
which seems to fix the issue?


It would be great if you could check the patch at the end of this mail:

https://lists.rtems.org/pipermail/devel/2024-February/077228.html

--
embedded brains GmbH & Co. KG
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: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project

2024-04-24 Thread Vijay Kumar Banerjee

(Adding devel back in the CC)

On Wed, Apr 24, 2024 at 1:34 AM Purva Yeshi  wrote:

> Please feel free to call me Vijay :)
>
> Sure.
>
> That's great! You might be able to relate some of the documentation to the
>> riscv BSP code in the repository.
>
> Yes, and I also added examples related to riscv
>
> Nice


> Have you set up any public repository that we might be able to follow and
>> provide early feedback? It is okay to have work-in-progress commits in your
>> repository.
>
> Yes I forked rtems-docs and commit those changes
> Here is the link:
> https://github.com/purviyeshi/rtems-docs/blob/master/bsp-howto/target_dependant_files.rst
>
>
I had a quick look at the document. Did the content under "peripheral
dependant" and "board dependant" get switched? Based on the lines preceding
your additions.


On Wed, 24 Apr 2024 at 03:26, Vijay Kumar Banerjee  wrote:
>
>> Hi Purva,
>>
>> On Tue, Apr 23, 2024 at 3:18 PM Purva Yeshi 
>> wrote:
>>
>>> Hello Sir,
>>>
>>
>> Please feel free to call me Vijay :)
>>
>>
>>>
>>> Up until now, I have been studying the BSP driver documentation from
>>> https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a
>>> good understanding of why and how target-dependent files are written.
>>> Additionally, I am currently working on how the console and clock driver
>>> are written.
>>>
>>> That's great! You might be able to relate some of the documentation to
>> the riscv BSP code in the repository.
>>
>>
>>> Furthermore, I have been modifying the target-dependent files by adding
>>> more examples to make them more understandable for new users.
>>>
>>
>> Have you set up any public repository that we might be able to follow and
>> provide early feedback? It is okay to have work-in-progress commits in your
>> repository.
>>
>>
>> Best regards,
>> Vijay
>>
>>>
>>> On Fri, 5 Apr 2024 at 21:36, Purva Yeshi 
>>> wrote:
>>>
 Thank you for all the resources.

 Yes, I go through the documentation and the codebase, and I'll try to
 send patches
 Okay, got the point about mailing list and github

 On Fri, 5 Apr 2024 at 02:21, Vijay Kumar Banerjee 
 wrote:

> Hi Purva,
>
>
>
> On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi 
> wrote:
>
>> Hello,
>>
>> I am Purva Yeshi, I applied for the project "Add BSP for Polarfire
>> based Beagle" for GSoC 2024. I proposed a project to create a BSP for the
>> Beagle-V fire board from scratch. The primary objective of the project is
>> to run a "Hello World" code and a ticker on the board. After that, I will
>> focus on developing support for other devices such as Ethernet and U54 
>> MMU.
>>
>> Great! Thanks for completing the proposal and submitting it on the
> portal.
>
>
>> During this waiting period for acceptance, I want to familiarize
>> myself with the codebase of existing supported components of other RISC-V
>> BSP variants. As part of my preparation, I have already built an RTEMS
>> development environment and successfully completed the RTEMS Hello World
>> project on the Qemu spike simulator for the riscv/rv64imafdc BSP variant.
>>
>>
> Since you already have a working RTEMS environment, it would be a
> great idea to start looking at the source code organization of riscv bsps 
> (
> https://git.rtems.org/rtems/tree/bsps/risc). It would also be helpful
> to find some smaller issues (maybe in the documentation) and try to send
> patches for that. Submitting patches for smaller issues is a great idea to
> become familiar with the code contribution process. The documentation for
> riscv bsps can be found at
> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>
> You can also utilize this time to read up on the Beagle-V fire
> documentation and the prior FreeBSD efforts to support that board.
>
> Could you please provide guidance on this. Additionally, is there any
>> specific task or area you suggest I focus on during this period for the
>> project?
>>
>
> Feel free to ask about anything you find interesting (or confusing)
> while going through the source code and the documentation. Especially with
> the documentation, if something confuses you it likely confuses other
> people too, it can be a place to make a great contribution!
>
> The mailing list is the best place to discuss longer questions, and
> the discord channel is better for quick help from people who are signed 
> in.
> The discord channel has a subset of the RTEMS developers on it, the 
> mailing
> list has a wider audience.
>
>
> Good luck with the GSoC application!
>
> Best regards,
> Vijay
>
> ___
>
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>

Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-04-24 Thread Chris Johns

On 24/4/2024 10:37 pm, Cedric Berger wrote:
> Hello Sebastian,
> 
> On 23.04.2024 19:56, Sebastian Huber wrote:
>>> 1. Are all the things need for the release resolved? Tickets reviewed?
>> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
>> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> Do you have any feedback on the two patches that I posted on the ticket, which
> seems to fix the issue?

Thanks to everyone for responding. It seems clear the 6 branch will happen once
GitLab is launched. Once we launch the 6 milestone can be used with burndown and
burnup charts
(https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
to track the branch point.

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request. If there is an issue
please make sure it is on the 6.1 milestone or create one and assign it to the
milestone.

In the meantime Amar and I will take a look at the release notes. We think these
can be based on a ChangeLog report created via the GitLab API. The wrinkle here
is the API needs a key and that of course cannot be exposed in commits.

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

Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-04-24 Thread Chris Johns

On 24/4/2024 10:37 pm, Cedric Berger wrote:
> Hello Sebastian,
> 
> On 23.04.2024 19:56, Sebastian Huber wrote:
>>> 1. Are all the things need for the release resolved? Tickets reviewed?
>> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
>> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> Do you have any feedback on the two patches that I posted on the ticket, which
> seems to fix the issue?

Thanks to everyone for responding. It seems clear the 6 branch will happen once
GitLab is launched. Once we launch the 6 milestone can be used with burndown and
burnup charts
(https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
to track the branch point.

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request. If there is an issue
please make sure it is on the 6.1 milestone or create one and assign it to the
milestone.

In the meantime Amar and I will take a look at the release notes. We think these
can be based on a ChangeLog report created via the GitLab API. The wrinkle here
is the API needs a key and that of course cannot be exposed in commits.

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

Re: RTEMS 6 branching

2024-04-24 Thread Chris Johns

On 25/4/2024 12:06 am, Peter Dufault wrote:
>> On Apr 24, 2024, at 9:27 AM, Kinsey Moore  wrote:
>>
>> That use case definitely wasn't considered for rtems-lwip and I don't know 
>> that it's ever been discussed. If that were intended, I'd expect a "./waf 
>> uninstall" target to exist that would remove the installed network stack so 
>> that you could install a different one since the different stacks install 
>> vastly different sets of headers. IIRC, Chris advocates for installing the 
>> network libraries into a different location than the installed BSP to allow 
>> you to choose which you want at a later time.
>>
> 
> I've been moving a driver from legacy to bsd so I definitely need to easily 
> switch back and forth for the same BSP for testing.
> 
> I agree with Chris, but it's apparently a desirement, not a requirement, so 
> it shouldn't hold up the branching.

Agreed. It would be nice but is it something user would really want or use? I
get there are use cases like the one you raise but a single installed network
stack in a single install prefix makes it easier to write build system checks to
detect the type of stack. I have applications that can switch between legacy and
libbsd and that is important when migrating stacks and debugging.

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

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

2024-04-24 Thread Kinsey Moore

Looks good, thanks!

Kinsey

On Tue, Apr 16, 2024 at 5:20 AM Ning Yang  wrote:

> The clock from the ARM timer is derived from the system clock. This clock
> can
> change dynamically e.g. if the system goes into reduced power or in low
> power
> mode. Thus the clock speed adapts to the overall system performance
> capabilities. For accurate timing it is recommended to use the system
> timers.
>
> if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the
> ARM
> Timer.
> ---
>  bsps/aarch64/raspberrypi/include/bsp/irq.h| 14 ++---
>  .../raspberrypi/include/bsp/raspberrypi.h |  9 ++
>  spec/build/bsps/aarch64/grp.yml   |  3 --
>  .../aarch64/raspberrypi/bspraspberrypi4.yml   |  6 ++--
>  .../bsps/aarch64/raspberrypi/objclock.yml | 31 +++
>  .../aarch64/raspberrypi/objsystemtimer.yml| 23 ++
>  .../aarch64/raspberrypi/optsystemtimer.yml| 24 ++
>  7 files changed, 100 insertions(+), 10 deletions(-)
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml
>
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h
> b/bsps/aarch64/raspberrypi/include/bsp/irq.h
> index 1ff6ae80de..d493e83707 100644
> --- a/bsps/aarch64/raspberrypi/include/bsp/irq.h
> +++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
> @@ -9,6 +9,7 @@
>  /**
>   * Copyright (c) 2013 Alan Cudmore
>   * Copyright (c) 2022 Mohd Noor Aman
> + * Copyright (c) 2024 Ning Yang
>   *
>   *  The license and distribution terms for this file may be
>   *  found in the file LICENSE in this distribution or at
> @@ -33,15 +34,18 @@
>   * @brief Interrupt support.
>   */
>
> -#define BCM2835_INTC_TOTAL_IRQ   (64 + 8)
> +#define BCM2835_INTC_TOTAL_IRQ   216
>
>  #define BCM2835_IRQ_SET1_MIN 0
>  #define BCM2835_IRQ_SET2_MIN 32
>
> -#define BCM2835_IRQ_ID_GPU_TIMER_M0  0
> -#define BCM2835_IRQ_ID_GPU_TIMER_M1  1
> -#define BCM2835_IRQ_ID_GPU_TIMER_M2  2
> -#define BCM2835_IRQ_ID_GPU_TIMER_M3  3
> +#define BCM2711_IRQ_VC_PERIPHERAL_BASE 96
> +
> +/* Interrupt Vectors: System Timer */
> +#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 0)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 1)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 2)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 3)
>
>  #define BCM2835_IRQ_ID_USB   9
>  #define BCM2835_IRQ_ID_AUX   29
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> index 55dd9ed1e9..f185d1df57 100644
> --- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> +++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> @@ -8,6 +8,7 @@
>
>  /*
>   *  Copyright (c) 2022 Mohd Noor Aman
> + *  Copyright (c) 2024 Ning Yang
>   *
>   *  The license and distribution terms for this file may be
>   *  found in the file LICENSE in this distribution or at
> @@ -44,6 +45,7 @@
>
>  #define BCM2711_REG(x)   (*(volatile uint64_t *)(x))
>  #define BCM2711_BIT(n)   (1 << (n))
> +#define BCM2835_REG(addr)(*(volatile uint32_t*)(addr))
>
>  /** @} */
>
> @@ -198,6 +200,13 @@
>  #define BCM2711_GPU_TIMER_C2 (BCM2711_GPU_TIMER_BASE + 0x14)
>  #define BCM2711_GPU_TIMER_C3 (BCM2711_GPU_TIMER_BASE + 0x18)
>
> +/**
> + * NOTE: compatible with the BCM2835 system timer
> + */
> +#define BCM2835_GPU_TIMER_CS_M3  BCM2711_GPU_TIMER_CS_M3
> +#define BCM2835_GPU_TIMER_C3 BCM2711_GPU_TIMER_C3
> +#define BCM2835_GPU_TIMER_CLOBCM2711_GPU_TIMER_CLO
> +#define BCM2835_GPU_TIMER_CS BCM2711_GPU_TIMER_CS
>  /** @} */
>
>  /**
> diff --git a/spec/build/bsps/aarch64/grp.yml
> b/spec/build/bsps/aarch64/grp.yml
> index 9428fb9435..8f40a9952e 100644
> --- a/spec/build/bsps/aarch64/grp.yml
> +++ b/spec/build/bsps/aarch64/grp.yml
> @@ -12,9 +12,6 @@ install:
>source:
>- bsps/aarch64/include/bsp/linker-symbols.h
>- bsps/aarch64/include/bsp/start.h
> -- destination: ${BSP_INCLUDEDIR}/dev/clock
> -  source:
> -  - bsps/include/dev/clock/arm-generic-timer.h
>  - destination: ${BSP_INCLUDEDIR}/dev/irq
>source:
>- bsps/aarch64/include/dev/irq/arm-gic-arch.h
> diff --git a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
> b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
> index a579c094ba..7b6511a8cc 100644
> --- a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
> +++ b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
> @@ -19,6 +19,10 @@ install:
>- bsps/aarch64/raspberrypi/include/bsp/irq.h
>- bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>  links:
> +- role: build-dependency
> +  uid: objclock
> +- role: build-dependency
> +  uid: objsystemtimer
>  - role:

Re: RTEMS 6 branching

2024-04-24 Thread Peter Dufault

> On Apr 24, 2024, at 9:27 AM, Kinsey Moore  wrote:
> 
> That use case definitely wasn't considered for rtems-lwip and I don't know 
> that it's ever been discussed. If that were intended, I'd expect a "./waf 
> uninstall" target to exist that would remove the installed network stack so 
> that you could install a different one since the different stacks install 
> vastly different sets of headers. IIRC, Chris advocates for installing the 
> network libraries into a different location than the installed BSP to allow 
> you to choose which you want at a later time.
> 
> Kinsey

I've been moving a driver from legacy to bsd so I definitely need to easily 
switch back and forth for the same BSP for testing.

I agree with Chris, but it's apparently a desirement, not a requirement, so it 
shouldn't hold up the branching.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

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

Re: RTEMS 6 branching

2024-04-24 Thread Kinsey Moore

On Wed, Apr 24, 2024 at 6:43 AM Peter Dufault  wrote:

> > On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee 
> wrote:
> > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill  wrote:
> >
> >
> > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> > - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
> >
> > > Hi,
> > >
> > > There has been some discussion about when we will branch and it is
> timely we
> > > discuss this. This is my input. :)
> > >
> > > While I create the releases I am not solely responsible for milestone
> dates or
> > > thresholds for a release.
> > >
> > > Please test the RC snaphots on our ftp server. Saying you have is as
> important
> > > as reporting issues.
> > >
> > > 1. Are all the things need for the release resolved? Tickets reviewed?
> >
> > It would be nice to have the interrupt get/set priority API in RTEMS 6.
> The Cortex-M floating point issue is not yet fixed in the RTEMS master.
> >
> > There should be time to get it in. The Gitlab transition needs to be
> complete before the branch is cut.
> >
> > >
> > > 2. The tickets are now in GitLab and locked down in Trac so how does
> that work
> > > if we make a release now? I do not think it does.
> > >
> > > 3. GitLab is going to happen soon so do we take this moment in time
> and make 6
> > > with GitLab and learn what we need to do easing dot releases that
> always follow?
> > > If we do not we may end up with 6.1 and then 6.2 that has differences.
> >
> > We should definitely wait with the release after the Gitlab migration is
> done and some basic CI is running.
> >
> > I don't think holding a release for CI is needed. We have the same basic
> quality and testing we have now.
> >
> > Requiring more work and improvements just moves the release bar.
> >
> > That said, we do need to get some CI processes in place. Hopefully
> between 6.1 and 6.2, we will have at least one or two BSPs required to
> build.
> >
> > >
> > > 4. GitLab breaks the release scripts for the release notes
> (ChangeLog). Amar and
> > > I have discussed a few options but we are yet to test and settle on
> anything. As
> > > is the case with these things easy is often is a series of small
> things that
> > > take time to get right.
> > >
> > > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are
> they updated
> > > for a separated legacy network stack, net services and waf building?
> >
> > Ryan and Ray worked on the autoconf to waf documentation changes a
> couple of years ago.
> >
> > I have no idea what impact the separated Network stacks have on the
> documentation.
> >
> > The legacy networking docs are separated now with instructions on how to
> build them using waf:
> > https://docs.rtems.org/branches/master/legacy-networking/index.html
> >
> > We might need to mention in the user manual that there is no default
> networking stack anymore and the user needs to build the network stack
> separately.
>
> I do (or did, haven't checked lately) have an issue that if I "./waf
> install" one of the network stacks, probably "libbsd", that I can't then
> switch back and forth.  I think a header file got installed that broke
> things.  Don't know if that was fixed, I've just been careful to not
> install either stack so I can switch.
>
> Is that a bug?  Should I figure out what the problem was and report it?
>

That use case definitely wasn't considered for rtems-lwip and I don't know
that it's ever been discussed. If that were intended, I'd expect a "./waf
uninstall" target to exist that would remove the installed network stack so
that you could install a different one since the different stacks install
vastly different sets of headers. IIRC, Chris advocates for installing the
network libraries into a different location than the installed BSP to allow
you to choose which you want at a later time.

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

Cortex-M floating point (Was: RTEMS 6 branching)

2024-04-24 Thread Cedric Berger


Hello Sebastian,

On 23.04.2024 19:56, Sebastian Huber wrote:

1. Are all the things need for the release resolved? Tickets reviewed?

It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
Cortex-M floating point issue is not yet fixed in the RTEMS master.


Do you have any feedback on the two patches that I posted on the ticket, 
which seems to fix the issue?


Thanks,

Cedric

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

Re: RTEMS 6 branching

2024-04-24 Thread Peter Dufault



> On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee  wrote:
> 
> 
> 
> On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill  wrote:
> 
> 
> On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber 
>  wrote:
> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
> 
> > Hi,
> > 
> > There has been some discussion about when we will branch and it is timely we
> > discuss this. This is my input. :)
> > 
> > While I create the releases I am not solely responsible for milestone dates 
> > or
> > thresholds for a release.
> > 
> > Please test the RC snaphots on our ftp server. Saying you have is as 
> > important
> > as reporting issues.
> > 
> > 1. Are all the things need for the release resolved? Tickets reviewed?
> 
> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> There should be time to get it in. The Gitlab transition needs to be complete 
> before the branch is cut. 
> 
> > 
> > 2. The tickets are now in GitLab and locked down in Trac so how does that 
> > work
> > if we make a release now? I do not think it does.
> > 
> > 3. GitLab is going to happen soon so do we take this moment in time and 
> > make 6
> > with GitLab and learn what we need to do easing dot releases that always 
> > follow?
> > If we do not we may end up with 6.1 and then 6.2 that has differences.
> 
> We should definitely wait with the release after the Gitlab migration is done 
> and some basic CI is running.
> 
> I don't think holding a release for CI is needed. We have the same basic 
> quality and testing we have now.
> 
> Requiring more work and improvements just moves the release bar. 
> 
> That said, we do need to get some CI processes in place. Hopefully between 
> 6.1 and 6.2, we will have at least one or two BSPs required to build.
> 
> > 
> > 4. GitLab breaks the release scripts for the release notes (ChangeLog). 
> > Amar and
> > I have discussed a few options but we are yet to test and settle on 
> > anything. As
> > is the case with these things easy is often is a series of small things that
> > take time to get right.
> > 
> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they 
> > updated
> > for a separated legacy network stack, net services and waf building?
> 
> Ryan and Ray worked on the autoconf to waf documentation changes a couple of 
> years ago.
> 
> I have no idea what impact the separated Network stacks have on the 
> documentation.
> 
> The legacy networking docs are separated now with instructions on how to 
> build them using waf:
> https://docs.rtems.org/branches/master/legacy-networking/index.html
> 
> We might need to mention in the user manual that there is no default 
> networking stack anymore and the user needs to build the network stack 
> separately.

I do (or did, haven't checked lately) have an issue that if I "./waf install" 
one of the network stacks, probably "libbsd", that I can't then switch back and 
forth.  I think a header file got installed that broke things.  Don't know if 
that was fixed, I've just been careful to not install either stack so I can 
switch.

Is that a bug?  Should I figure out what the problem was and report it?

> 
> > 6. I have a few small patches to push and then an update to the RSB to pick
> > those changes up before I can create RC4.
> 
> I recently checked in a fix for powerpc and the AArch64 multilib changes for 
> Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be updated. 
> Maybe we should even wait for the GCC 13.3 release.
> 
> I asked about a gcc 13.3 release and we should not wait. They intend to do a 
> 14 release before returning to 13.3. We should plan to do 6.1 with a GCC 13 
> branch hash and probably plan to swap that out with a 13.3 tarball when it's 
> released. 
> 
> We are good at imposing more requirements. :)
> 
> 


Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering



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

Re: RTEMS 6 branching

2024-04-23 Thread Vijay Kumar Banerjee

On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill  wrote:

>
>
> On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
>>
>> > Hi,
>> >
>> > There has been some discussion about when we will branch and it is
>> timely we
>> > discuss this. This is my input. :)
>> >
>> > While I create the releases I am not solely responsible for milestone
>> dates or
>> > thresholds for a release.
>> >
>> > Please test the RC snaphots on our ftp server. Saying you have is as
>> important
>> > as reporting issues.
>> >
>> > 1. Are all the things need for the release resolved? Tickets reviewed?
>>
>> It would be nice to have the interrupt get/set priority API in RTEMS 6.
>> The Cortex-M floating point issue is not yet fixed in the RTEMS master.
>>
>
> There should be time to get it in. The Gitlab transition needs to be
> complete before the branch is cut.
>
>>
>> >
>> > 2. The tickets are now in GitLab and locked down in Trac so how does
>> that work
>> > if we make a release now? I do not think it does.
>> >
>> > 3. GitLab is going to happen soon so do we take this moment in time and
>> make 6
>> > with GitLab and learn what we need to do easing dot releases that
>> always follow?
>> > If we do not we may end up with 6.1 and then 6.2 that has differences.
>>
>> We should definitely wait with the release after the Gitlab migration is
>> done and some basic CI is running.
>>
>
> I don't think holding a release for CI is needed. We have the same basic
> quality and testing we have now.
>
> Requiring more work and improvements just moves the release bar.
>
> That said, we do need to get some CI processes in place. Hopefully between
> 6.1 and 6.2, we will have at least one or two BSPs required to build.
>
>>
>> >
>> > 4. GitLab breaks the release scripts for the release notes (ChangeLog).
>> Amar and
>> > I have discussed a few options but we are yet to test and settle on
>> anything. As
>> > is the case with these things easy is often is a series of small things
>> that
>> > take time to get right.
>> >
>> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they
>> updated
>> > for a separated legacy network stack, net services and waf building?
>>
>
> Ryan and Ray worked on the autoconf to waf documentation changes a couple
> of years ago.
>
> I have no idea what impact the separated Network stacks have on the
> documentation.
>

The legacy networking docs are separated now with instructions on how to
build them using waf:
https://docs.rtems.org/branches/master/legacy-networking/index.html

We might need to mention in the user manual that there is no default
networking stack anymore and the user needs to build the network stack
separately.

>
> > 6. I have a few small patches to push and then an update to the RSB to
>> pick
>> > those changes up before I can create RC4.
>>
>> I recently checked in a fix for powerpc and the AArch64 multilib changes
>> for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be
>> updated. Maybe we should even wait for the GCC 13.3 release.
>>
>
> I asked about a gcc 13.3 release and we should not wait. They intend to do
> a 14 release before returning to 13.3. We should plan to do 6.1 with a GCC
> 13 branch hash and probably plan to swap that out with a 13.3 tarball when
> it's released.
>
> We are good at imposing more requirements. :)
>
>
>
>
>> >
>> >
>> > Thanks
>> > Chris
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>> --
>> embedded brains GmbH & Co. KG
>> 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
>
> ___
> 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: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project

2024-04-23 Thread Vijay Kumar Banerjee

Hi Purva,

On Tue, Apr 23, 2024 at 3:18 PM Purva Yeshi  wrote:

> Hello Sir,
>

Please feel free to call me Vijay :)


>
> Up until now, I have been studying the BSP driver documentation from
> https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a good
> understanding of why and how target-dependent files are written.
> Additionally, I am currently working on how the console and clock driver
> are written.
>
> That's great! You might be able to relate some of the documentation to the
riscv BSP code in the repository.


> Furthermore, I have been modifying the target-dependent files by adding
> more examples to make them more understandable for new users.
>

Have you set up any public repository that we might be able to follow and
provide early feedback? It is okay to have work-in-progress commits in your
repository.


Best regards,
Vijay

>
> On Fri, 5 Apr 2024 at 21:36, Purva Yeshi  wrote:
>
>> Thank you for all the resources.
>>
>> Yes, I go through the documentation and the codebase, and I'll try to
>> send patches
>> Okay, got the point about mailing list and github
>>
>> On Fri, 5 Apr 2024 at 02:21, Vijay Kumar Banerjee 
>> wrote:
>>
>>> Hi Purva,
>>>
>>>
>>>
>>> On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi 
>>> wrote:
>>>
 Hello,

 I am Purva Yeshi, I applied for the project "Add BSP for Polarfire
 based Beagle" for GSoC 2024. I proposed a project to create a BSP for the
 Beagle-V fire board from scratch. The primary objective of the project is
 to run a "Hello World" code and a ticker on the board. After that, I will
 focus on developing support for other devices such as Ethernet and U54 MMU.

 Great! Thanks for completing the proposal and submitting it on the
>>> portal.
>>>
>>>
 During this waiting period for acceptance, I want to familiarize myself
 with the codebase of existing supported components of other RISC-V BSP
 variants. As part of my preparation, I have already built an RTEMS
 development environment and successfully completed the RTEMS Hello World
 project on the Qemu spike simulator for the riscv/rv64imafdc BSP variant.


>>> Since you already have a working RTEMS environment, it would be a great
>>> idea to start looking at the source code organization of riscv bsps (
>>> https://git.rtems.org/rtems/tree/bsps/risc). It would also be helpful
>>> to find some smaller issues (maybe in the documentation) and try to send
>>> patches for that. Submitting patches for smaller issues is a great idea to
>>> become familiar with the code contribution process. The documentation for
>>> riscv bsps can be found at
>>> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>>>
>>> You can also utilize this time to read up on the Beagle-V fire
>>> documentation and the prior FreeBSD efforts to support that board.
>>>
>>> Could you please provide guidance on this. Additionally, is there any
 specific task or area you suggest I focus on during this period for the
 project?

>>>
>>> Feel free to ask about anything you find interesting (or confusing)
>>> while going through the source code and the documentation. Especially with
>>> the documentation, if something confuses you it likely confuses other
>>> people too, it can be a place to make a great contribution!
>>>
>>> The mailing list is the best place to discuss longer questions, and the
>>> discord channel is better for quick help from people who are signed in. The
>>> discord channel has a subset of the RTEMS developers on it, the mailing
>>> list has a wider audience.
>>>
>>>
>>> Good luck with the GSoC application!
>>>
>>> Best regards,
>>> Vijay
>>>
>>> ___
>>>
 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: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project

2024-04-23 Thread Purva Yeshi

Hello Sir,

Up until now, I have been studying the BSP driver documentation from
https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a good
understanding of why and how target-dependent files are written.
Additionally, I am currently working on how the console and clock driver
are written.

Furthermore, I have been modifying the target-dependent files by adding
more examples to make them more understandable for new users.

On Fri, 5 Apr 2024 at 21:36, Purva Yeshi  wrote:

> Thank you for all the resources.
>
> Yes, I go through the documentation and the codebase, and I'll try to send
> patches
> Okay, got the point about mailing list and github
>
> On Fri, 5 Apr 2024 at 02:21, Vijay Kumar Banerjee  wrote:
>
>> Hi Purva,
>>
>>
>>
>> On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi 
>> wrote:
>>
>>> Hello,
>>>
>>> I am Purva Yeshi, I applied for the project "Add BSP for Polarfire based
>>> Beagle" for GSoC 2024. I proposed a project to create a BSP for the
>>> Beagle-V fire board from scratch. The primary objective of the project is
>>> to run a "Hello World" code and a ticker on the board. After that, I will
>>> focus on developing support for other devices such as Ethernet and U54 MMU.
>>>
>>> Great! Thanks for completing the proposal and submitting it on the
>> portal.
>>
>>
>>> During this waiting period for acceptance, I want to familiarize myself
>>> with the codebase of existing supported components of other RISC-V BSP
>>> variants. As part of my preparation, I have already built an RTEMS
>>> development environment and successfully completed the RTEMS Hello World
>>> project on the Qemu spike simulator for the riscv/rv64imafdc BSP variant.
>>>
>>>
>> Since you already have a working RTEMS environment, it would be a great
>> idea to start looking at the source code organization of riscv bsps (
>> https://git.rtems.org/rtems/tree/bsps/risc). It would also be helpful to
>> find some smaller issues (maybe in the documentation) and try to send
>> patches for that. Submitting patches for smaller issues is a great idea to
>> become familiar with the code contribution process. The documentation for
>> riscv bsps can be found at
>> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>>
>> You can also utilize this time to read up on the Beagle-V fire
>> documentation and the prior FreeBSD efforts to support that board.
>>
>> Could you please provide guidance on this. Additionally, is there any
>>> specific task or area you suggest I focus on during this period for the
>>> project?
>>>
>>
>> Feel free to ask about anything you find interesting (or confusing) while
>> going through the source code and the documentation. Especially with the
>> documentation, if something confuses you it likely confuses other people
>> too, it can be a place to make a great contribution!
>>
>> The mailing list is the best place to discuss longer questions, and the
>> discord channel is better for quick help from people who are signed in. The
>> discord channel has a subset of the RTEMS developers on it, the mailing
>> list has a wider audience.
>>
>>
>> Good luck with the GSoC application!
>>
>> Best regards,
>> Vijay
>>
>> ___
>>
>>> 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 9/9] bsp/tms570: Use write-back/write-allocate SDRAM

Update #4982.
---
 bsps/arm/tms570/start/tms570_sys_core.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/arm/tms570/start/tms570_sys_core.S 
b/bsps/arm/tms570/start/tms570_sys_core.S
index 83dee26ec8..ef28d88ede 100644
--- a/bsps/arm/tms570/start/tms570_sys_core.S
+++ b/bsps/arm/tms570/start/tms570_sys_core.S
@@ -655,7 +655,7 @@ _mpuInit_:
 mcr   p15, #0,r0, c6, c2, #0
 ldr   r0,  r6Base
 mcr   p15, #0,r0, c6, c1, #0
-mov   r0,  #0x0002
+mov   r0,  #0x000B
 orr   r0,  r0,#0x0300
 mcr   p15, #0,r0, c6, c1, #4
 movw  r0,  #((0 << 15) + (0 << 14) + (0 << 13) + (0 << 12) + (0 << 11) 
+ (0 << 10) + (0 <<  9) + (0 <<  8) + (0x1A << 1) + (1))
-- 
2.35.3

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

[PATCH 8/9] bsp/tms570: Use RTI for CPU counter

The performance monitor counter is stopped when the core is waiting for
interrupts.

Update #4982.
---
 bsps/arm/tms570/clock/clock.c   | 71 --
 bsps/arm/tms570/cpucounter/cpucounterread.c | 83 -
 spec/build/bsps/arm/tms570/obj.yml  |  1 -
 3 files changed, 48 insertions(+), 107 deletions(-)
 delete mode 100644 bsps/arm/tms570/cpucounter/cpucounterread.c

diff --git a/bsps/arm/tms570/clock/clock.c b/bsps/arm/tms570/clock/clock.c
index 2fb884b3ce..4465e33843 100644
--- a/bsps/arm/tms570/clock/clock.c
+++ b/bsps/arm/tms570/clock/clock.c
@@ -44,27 +44,24 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 static struct timecounter tms570_rti_tc;
 
-static uint32_t tms570_rti_get_timecount(struct timecounter *tc)
+uint32_t _CPU_Counter_frequency(void)
 {
-  return TMS570_RTI.CNT[0].FRCx;
+  return TMS570_RTICLK_HZ / 2;
 }
 
-static void tms570_clock_driver_support_initialize_hardware( void )
+CPU_Counter_ticks _CPU_Counter_read(void)
 {
+  return TMS570_RTI.CNT[0].FRCx;
+}
 
-  uint64_t usec_per_tick;
-  uint32_t tc_frequency;
-  uint32_t tc_increments_per_tick;
-  struct timecounter *tc;
-
-  usec_per_tick = rtems_configuration_get_microseconds_per_tick();
-  tc_frequency = TMS570_RTICLK_HZ / 2;
-  tc_increments_per_tick = (usec_per_tick * tc_frequency + 50) / 100;
-
+static void tms570_rti_initialize( void )
+{
   /* Initialize module */
   TMS570_RTI.GCTRL = 0;
   TMS570_RTI.CAPCTRL = 0;
@@ -72,14 +69,7 @@ static void tms570_clock_driver_support_initialize_hardware( 
void )
   TMS570_RTI.TBCTRL = TMS570_RTI_TBCTRL_INC;
   TMS570_RTI.INTCLRENABLE = 0x05050505;
 
-  /* Initialize counter 0 */
-  TMS570_RTI.CNT[0].CPUCx = 1;
-  TMS570_RTI.CNT[0].UCx = 0;
-  TMS570_RTI.CNT[0].FRCx = 0;
-  TMS570_RTI.CMP[0].COMPx = tc_increments_per_tick;
-  TMS570_RTI.CMP[0].UDCPx = tc_increments_per_tick;
-
-  /* Clear interrupts */
+  /* Disable interrupts */
   TMS570_RTI.CLEARINTENA = TMS570_RTI_CLEARINTENA_CLEAROVL1INT |
TMS570_RTI_CLEARINTENA_CLEAROVL0INT |
TMS570_RTI_CLEARINTENA_CLEARTBINT |
@@ -91,6 +81,44 @@ static void tms570_clock_driver_support_initialize_hardware( 
void )
TMS570_RTI_CLEARINTENA_CLEARINT2 |
TMS570_RTI_CLEARINTENA_CLEARINT1 |
TMS570_RTI_CLEARINTENA_CLEARINT0;
+
+  /* Initialize counter 0 */
+  TMS570_RTI.CNT[0].CPUCx = 1;
+  TMS570_RTI.CNT[0].UCx = 0;
+  TMS570_RTI.CNT[0].FRCx = 0;
+
+  /* Enable counter 0 */
+  TMS570_RTI.GCTRL = TMS570_RTI_GCTRL_CNT0EN;
+}
+
+RTEMS_SYSINIT_ITEM(
+  tms570_rti_initialize,
+  RTEMS_SYSINIT_CPU_COUNTER,
+  RTEMS_SYSINIT_ORDER_MIDDLE
+);
+
+static uint32_t tms570_rti_get_timecount(struct timecounter *tc)
+{
+  return TMS570_RTI.CNT[0].FRCx;
+}
+
+static void tms570_clock_driver_support_initialize_hardware( void )
+{
+
+  uint64_t usec_per_tick;
+  uint32_t tc_frequency;
+  uint32_t tc_increments_per_tick;
+  struct timecounter *tc;
+
+  usec_per_tick = rtems_configuration_get_microseconds_per_tick();
+  tc_frequency = TMS570_RTICLK_HZ / 2;
+  tc_increments_per_tick = (usec_per_tick * tc_frequency + 50) / 100;
+
+  /* Initialize compare 0 */
+  TMS570_RTI.CMP[0].UDCPx = tc_increments_per_tick;
+  TMS570_RTI.CMP[0].COMPx = TMS570_RTI.CNT[0].FRCx + tc_increments_per_tick;
+
+  /* Clear interrupts */
   TMS570_RTI.INTFLAG = TMS570_RTI_INTFLAG_OVL1INT |
TMS570_RTI_INTFLAG_OVL0INT |
TMS570_RTI_INTFLAG_TBINT |
@@ -99,9 +127,6 @@ static void tms570_clock_driver_support_initialize_hardware( 
void )
TMS570_RTI_INTFLAG_INT1 |
TMS570_RTI_INTFLAG_INT0;
 
-  /* Enable counter 0 */
-  TMS570_RTI.GCTRL = TMS570_RTI_GCTRL_CNT0EN;
-
   /* Enable interrupts for counter 0 */
   TMS570_RTI.SETINTENA = TMS570_RTI_SETINTENA_SETINT0;
 
diff --git a/bsps/arm/tms570/cpucounter/cpucounterread.c 
b/bsps/arm/tms570/cpucounter/cpucounterread.c
deleted file mode 100644
index 8cda09f0c6..00
--- a/bsps/arm/tms570/cpucounter/cpucounterread.c
+++ /dev/null
@@ -1,83 +0,0 @@
-/* SPDX-License-Identifier: BSD-2-Clause */
-
-/**
- * @file
- *
- * @ingroup RTEMSBSPsARMTMS570
- *
- * @brief This source file contains the CPU Counter implementation.
- *
- * The counters setup functions are these which has been suggested on
- * StackOverflow.  Code is probably for use on Cortex-A without modifications
- * as well.
- *
- * 
http://stackoverflow.com/questions/3247373/how-to-measure-program-execution-time-in-arm-cortex-a8-processor
- */
-
-/*
- * Copyright (C) 2014 Pavel Pisa 
- *
- * Czech Technical University in Prague
- * Zikova 1903/4
- * 166 36 Praha 6
- * Czech Republic
- *
- * 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

[PATCH 7/9] bsp/tms570: Add TMS570_FATAL_RTI_IRQ_INSTALL

Update #4982.
---
 bsps/arm/tms570/clock/clock.c | 15 ---
 bsps/include/bsp/fatal.h  |  3 +++
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/bsps/arm/tms570/clock/clock.c b/bsps/arm/tms570/clock/clock.c
index cf14d5772f..2fb884b3ce 100644
--- a/bsps/arm/tms570/clock/clock.c
+++ b/bsps/arm/tms570/clock/clock.c
@@ -41,6 +41,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -117,19 +118,11 @@ static void tms570_clock_driver_support_at_tick(volatile 
tms570_rti_t *rti)
   rti->INTFLAG = TMS570_RTI_INTFLAG_INT0;
 }
 
-/**
- * @brief registers RTI interrupt handler
- *
- * @param[in] Clock_isr new ISR handler
- * @param[in] Old_ticker old ISR handler (unused and type broken)
- *
- * @retval Void
- */
 static void tms570_clock_driver_support_install_isr(
   rtems_interrupt_handler handler
 )
 {
-  rtems_status_code sc = RTEMS_SUCCESSFUL;
+  rtems_status_code sc;
 
   sc = rtems_interrupt_handler_install(
 TMS570_IRQ_TIMER_0,
@@ -138,8 +131,8 @@ static void tms570_clock_driver_support_install_isr(
 handler,
 RTEMS_DEVOLATILE(tms570_rti_t *, _RTI)
   );
-  if ( sc != RTEMS_SUCCESSFUL ) {
-rtems_fatal_error_occurred(0xdeadbeef);
+  if (sc != RTEMS_SUCCESSFUL) {
+bsp_fatal(TMS570_FATAL_RTI_IRQ_INSTALL);
   }
 }
 
diff --git a/bsps/include/bsp/fatal.h b/bsps/include/bsp/fatal.h
index 87fc481ead..b41ef2d5c2 100644
--- a/bsps/include/bsp/fatal.h
+++ b/bsps/include/bsp/fatal.h
@@ -217,6 +217,9 @@ typedef enum {
 
   /* Xilinx fatal codes */
   XIL_FATAL_TTC_IRQ_INSTALL = BSP_FATAL_CODE_BLOCK(17),
+
+  /* TMS570 fatal codes */
+  TMS570_FATAL_RTI_IRQ_INSTALL = BSP_FATAL_CODE_BLOCK(18),
 } bsp_fatal_code;
 
 RTEMS_NO_RETURN static inline void
-- 
2.35.3

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

[PATCH 1/9] arm: Add arm_cp15_data_cache_all_invalidate()

Update #4982.
---
 cpukit/score/cpu/arm/include/libcpu/arm-cp15.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h 
b/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h
index c239eaccc8..4a5ddb561e 100644
--- a/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h
+++ b/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h
@@ -2371,6 +2371,23 @@ arm_cp15_set_diagnostic_control(uint32_t val)
   );
 }
 
+/* This is probably a Cortex-R5 specific operation */
+ARM_CP15_TEXT_SECTION static inline void
+arm_cp15_data_cache_all_invalidate(void)
+{
+  ARM_SWITCH_REGISTERS;
+  uint32_t sbz = 0;
+
+  __asm__ volatile (
+ARM_SWITCH_TO_ARM
+"mcr p15, 0, %[sbz], c15, c5, 0\n"
+ARM_SWITCH_BACK
+: ARM_SWITCH_OUTPUT
+: [sbz] "r" (sbz)
+: "memory"
+  );
+}
+
 /**
  * @brief Sets the @a section_flags for the address range [@a begin, @a end).
  *
-- 
2.35.3

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

[PATCH 6/9] bsp/tms570: Fix clock driver

The clock tick rate was off by a factor of two in some configurations.
Use the maximum counter frequency to get the best time resolution.  Do
not use the automatic interrupt clear feature.

Update #4982.
---
 bsps/arm/tms570/clock/clock.c | 99 +++
 1 file changed, 32 insertions(+), 67 deletions(-)

diff --git a/bsps/arm/tms570/clock/clock.c b/bsps/arm/tms570/clock/clock.c
index a3ea08c967..cf14d5772f 100644
--- a/bsps/arm/tms570/clock/clock.c
+++ b/bsps/arm/tms570/clock/clock.c
@@ -9,6 +9,7 @@
  */
 
 /*
+ * Copyright (C) 2024 embedded brains GmbH & Co. KG
  * Copyright (C) 2014 Premysl Houdek 
  *
  * Google Summer of Code 2014 at
@@ -39,9 +40,6 @@
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include 
-
-#include 
 #include 
 #include 
 #include 
@@ -54,57 +52,33 @@ static uint32_t tms570_rti_get_timecount(struct timecounter 
*tc)
   return TMS570_RTI.CNT[0].FRCx;
 }
 
-#ifndef TMS570_PREFERRED_TC_FREQUENCY
-/*
- * Define preferred main time base counter frequency
- * The value of 1MHz is the best matching RTEMS
- * timing system because then there is no need
- * to scale RTEMS configuration microseconds_per_tick
- * parameter
- */
-#define TMS570_PREFERRED_TC_FREQUENCY 100
-#endif /* TMS570_PREFERRED_TC_FREQUENCY */
-
-/**
- *  @brief Initialize the HW peripheral for clock driver
- *
- *  Clock driver is implemented by RTI module
- *
- * @retval Void
- */
 static void tms570_clock_driver_support_initialize_hardware( void )
 {
 
-  uint32_t microsec_per_tick;
+  uint64_t usec_per_tick;
   uint32_t tc_frequency;
-  uint32_t tc_prescaler;
   uint32_t tc_increments_per_tick;
+  struct timecounter *tc;
 
-  microsec_per_tick = rtems_configuration_get_microseconds_per_tick();
-  tc_frequency = TMS570_PREFERRED_TC_FREQUENCY;
-
-  tc_prescaler = (TMS570_RTICLK_HZ + tc_frequency) / (tc_frequency * 2);
-
-  /* Recompute actual most close frequency which can be realized */
-  tc_frequency = (TMS570_RTICLK_HZ + tc_prescaler) / (tc_prescaler * 2);
+  usec_per_tick = rtems_configuration_get_microseconds_per_tick();
+  tc_frequency = TMS570_RTICLK_HZ / 2;
+  tc_increments_per_tick = (usec_per_tick * tc_frequency + 50) / 100;
 
-  /*
-   * Recompute tick period to adjust for configurable or exact
-   * preferred time base 1 usec resolution.
-   */
-  tc_increments_per_tick = ((uint64_t)microsec_per_tick * tc_frequency +
-   50) / 100;
-
-  /* Hardware specific initialize */
+  /* Initialize module */
   TMS570_RTI.GCTRL = 0;
-  TMS570_RTI.CNT[0].CPUCx = tc_prescaler - 1;
-  TMS570_RTI.TBCTRL = TMS570_RTI_TBCTRL_INC;
   TMS570_RTI.CAPCTRL = 0;
   TMS570_RTI.COMPCTRL = 0;
-  /* set counter to zero */
+  TMS570_RTI.TBCTRL = TMS570_RTI_TBCTRL_INC;
+  TMS570_RTI.INTCLRENABLE = 0x05050505;
+
+  /* Initialize counter 0 */
+  TMS570_RTI.CNT[0].CPUCx = 1;
   TMS570_RTI.CNT[0].UCx = 0;
   TMS570_RTI.CNT[0].FRCx = 0;
-  /* clear interrupts*/
+  TMS570_RTI.CMP[0].COMPx = tc_increments_per_tick;
+  TMS570_RTI.CMP[0].UDCPx = tc_increments_per_tick;
+
+  /* Clear interrupts */
   TMS570_RTI.CLEARINTENA = TMS570_RTI_CLEARINTENA_CLEAROVL1INT |
TMS570_RTI_CLEARINTENA_CLEAROVL0INT |
TMS570_RTI_CLEARINTENA_CLEARTBINT |
@@ -123,27 +97,21 @@ static void 
tms570_clock_driver_support_initialize_hardware( void )
TMS570_RTI_INTFLAG_INT2 |
TMS570_RTI_INTFLAG_INT1 |
TMS570_RTI_INTFLAG_INT0;
-  /* set timer */
-  TMS570_RTI.CMP[0].COMPx = TMS570_RTI.CNT[0].FRCx + tc_increments_per_tick;
-  TMS570_RTI.COMP0CLR = TMS570_RTI.CMP[0].COMPx + tc_increments_per_tick / 2;
-  TMS570_RTI.CMP[0].UDCPx = tc_increments_per_tick;
-  /* enable interupt */
-  TMS570_RTI.SETINTENA = TMS570_RTI_SETINTENA_SETINT0;
-  /* enable timer */
+
+  /* Enable counter 0 */
   TMS570_RTI.GCTRL = TMS570_RTI_GCTRL_CNT0EN;
-  /* set timecounter */
-  tms570_rti_tc.tc_get_timecount = tms570_rti_get_timecount;
-  tms570_rti_tc.tc_counter_mask = 0x;
-  tms570_rti_tc.tc_frequency = tc_frequency;
-  tms570_rti_tc.tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
-  rtems_timecounter_install(_rti_tc);
+
+  /* Enable interrupts for counter 0 */
+  TMS570_RTI.SETINTENA = TMS570_RTI_SETINTENA_SETINT0;
+
+  tc = _rti_tc;
+  tc->tc_get_timecount = tms570_rti_get_timecount;
+  tc->tc_counter_mask = 0x;
+  tc->tc_frequency = tc_frequency;
+  tc->tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
+  rtems_timecounter_install(tc);
 }
 
-/**
- * @brief Clears interrupt source
- *
- * @retval Void
- */
 static void tms570_clock_driver_support_at_tick(volatile tms570_rti_t *rti)
 {
   rti->INTFLAG = TMS570_RTI_INTFLAG_INT0;
@@ -175,14 +143,11 @@ static void tms570_clock_driver_support_install_isr(
   }
 }
 
-#define Clock_driver_support_initialize_hardware \
-tms570_clock_driver_support_initialize_hardware
+#define Clock_driver_support_initialize_hardware()

[PATCH 4/9] bsp/tms570: Add TMS570LC4357 PLL support

Update #4982.
---
 bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h 
b/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h
index d5583a1cca..1ca2bff685 100644
--- a/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h
+++ b/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h
@@ -355,6 +355,11 @@ typedef struct{
 /* field: ROS - Reset on PLL Slip */
 #define TMS570_SYS1_PLLCTL1_ROS BSP_BIT32(31)
 
+/* field: BPOS - Bypass of PLL Slip */
+#define TMS570_SYS1_PLLCTL1_BPOS(val) BSP_FLD32(val,29, 30)
+#define TMS570_SYS1_PLLCTL1_BPOS_GET(reg) BSP_FLD32GET(reg,29, 30)
+#define TMS570_SYS1_PLLCTL1_BPOS_SET(reg,val) BSP_FLD32SET(reg, val,29, 30)
+
 /* field: MASK_SLIP - Mask detection of PLL slip */
 #define TMS570_SYS1_PLLCTL1_MASK_SLIP(val) BSP_FLD32(val,29, 30)
 #define TMS570_SYS1_PLLCTL1_MASK_SLIP_GET(reg) BSP_FLD32GET(reg,29, 30)
@@ -404,6 +409,28 @@ typedef struct{
 #define TMS570_SYS1_PLLCTL2_SPR_AMOUNT_SET(reg,val) BSP_FLD32SET(reg, val,0, 8)
 
 
+/*TMS570_SYS1_PLLCTL3*/
+/* field: ODPLL2 - Internal PLL Output Divider. */
+#define TMS570_SYS1_PLLCTL3_ODPLL2(val) BSP_FLD32(val, 29, 31)
+#define TMS570_SYS1_PLLCTL3_ODPLL2_GET(reg) BSP_FLD32GET(reg, 29, 31)
+#define TMS570_SYS1_PLLCTL3_ODPLL2_SET(reg,val) BSP_FLD32SET(reg, val, 29, 31)
+
+/* field: PLLDIV2 - PLL2 Output Clock Divider. */
+#define TMS570_SYS1_PLLCTL3_PLLDIV2(val) BSP_FLD32(val, 24, 28)
+#define TMS570_SYS1_PLLCTL3_PLLDIV2_GET(reg) BSP_FLD32GET(reg, 24, 28)
+#define TMS570_SYS1_PLLCTL3_PLLDIV2_SET(reg,val) BSP_FLD32SET(reg, val, 24, 28)
+
+/* field: REFCLKDIV2 - Reference Clock Divider. */
+#define TMS570_SYS1_PLLCTL3_REFCLKDIV2(val) BSP_FLD32(val, 16, 21)
+#define TMS570_SYS1_PLLCTL3_REFCLKDIV2_GET(reg) BSP_FLD32GET(reg, 16, 21)
+#define TMS570_SYS1_PLLCTL3_REFCLKDIV2_SET(reg,val) BSP_FLD32SET(reg, val, 16, 
21)
+
+/* field: PLLMUL2 - PLL2 Multiplication Factor. */
+#define TMS570_SYS1_PLLCTL3_PLLMUL2(val) BSP_FLD32(val, 0, 15)
+#define TMS570_SYS1_PLLCTL3_PLLMUL2_GET(reg) BSP_FLD32GET(reg, 0, 15)
+#define TMS570_SYS1_PLLCTL3_PLLMUL2_SET(reg,val) BSP_FLD32SET(reg, val, 0, 15)
+
+
 /*TMS570_SYS1_SYSPC10*/
 /* field: ECPCLK_SLEW - ECPCLK slew control. This bit controls between the 
fast or slow slew mode. */
 #define TMS570_SYS1_SYSPC10_ECPCLK_SLEW BSP_BIT32(0)
-- 
2.35.3

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

[PATCH 5/9] bsp/tms570: Add clock BSP options

Update #4982.
---
 bsps/arm/tms570/clock/clock.c   |  4 ++--
 bsps/arm/tms570/console/tms570-sci.c|  2 +-
 bsps/arm/tms570/cpucounter/cpucounterread.c |  2 +-
 bsps/arm/tms570/include/bsp.h   |  6 --
 spec/build/bsps/arm/tms570/grp.yml  | 12 
 spec/build/bsps/arm/tms570/optgclk.yml  | 21 +
 spec/build/bsps/arm/tms570/opthclk.yml  | 21 +
 spec/build/bsps/arm/tms570/optrticlk.yml| 21 +
 spec/build/bsps/arm/tms570/optvclk.yml  | 21 +
 spec/build/bsps/arm/tms570/optvclk2.yml | 21 +
 spec/build/bsps/arm/tms570/optvclk3.yml | 21 +
 11 files changed, 142 insertions(+), 10 deletions(-)
 create mode 100644 spec/build/bsps/arm/tms570/optgclk.yml
 create mode 100644 spec/build/bsps/arm/tms570/opthclk.yml
 create mode 100644 spec/build/bsps/arm/tms570/optrticlk.yml
 create mode 100644 spec/build/bsps/arm/tms570/optvclk.yml
 create mode 100644 spec/build/bsps/arm/tms570/optvclk2.yml
 create mode 100644 spec/build/bsps/arm/tms570/optvclk3.yml

diff --git a/bsps/arm/tms570/clock/clock.c b/bsps/arm/tms570/clock/clock.c
index 2e71440857..a3ea08c967 100644
--- a/bsps/arm/tms570/clock/clock.c
+++ b/bsps/arm/tms570/clock/clock.c
@@ -83,10 +83,10 @@ static void 
tms570_clock_driver_support_initialize_hardware( void )
   microsec_per_tick = rtems_configuration_get_microseconds_per_tick();
   tc_frequency = TMS570_PREFERRED_TC_FREQUENCY;
 
-  tc_prescaler = (BSP_PLL_OUT_CLOCK + tc_frequency) / (tc_frequency * 2);
+  tc_prescaler = (TMS570_RTICLK_HZ + tc_frequency) / (tc_frequency * 2);
 
   /* Recompute actual most close frequency which can be realized */
-  tc_frequency = (BSP_PLL_OUT_CLOCK + tc_prescaler) / (tc_prescaler * 2);
+  tc_frequency = (TMS570_RTICLK_HZ + tc_prescaler) / (tc_prescaler * 2);
 
   /*
* Recompute tick period to adjust for configurable or exact
diff --git a/bsps/arm/tms570/console/tms570-sci.c 
b/bsps/arm/tms570/console/tms570-sci.c
index 63f8e7c8ee..6cb61f2b5d 100644
--- a/bsps/arm/tms570/console/tms570-sci.c
+++ b/bsps/arm/tms570/console/tms570-sci.c
@@ -297,7 +297,7 @@ bool tms570_sci_set_attributes(
 
   /* Apply baudrate to the hardware */
   baudrate *= 2 * 16;
-  bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
+  bauddiv = (TMS570_VCLK_HZ + baudrate / 2) / baudrate;
   ctx->regs->BRS = bauddiv? bauddiv - 1: 0;
 
   ctx->regs->GCR1 |= TMS570_SCI_GCR1_SWnRST | TMS570_SCI_GCR1_TXENA |
diff --git a/bsps/arm/tms570/cpucounter/cpucounterread.c 
b/bsps/arm/tms570/cpucounter/cpucounterread.c
index 009a37bec3..8cda09f0c6 100644
--- a/bsps/arm/tms570/cpucounter/cpucounterread.c
+++ b/bsps/arm/tms570/cpucounter/cpucounterread.c
@@ -68,7 +68,7 @@ static void tms570_cpu_counter_initialize(void)
 
 uint32_t _CPU_Counter_frequency(void)
 {
-  return 2 * BSP_PLL_OUT_CLOCK;
+  return TMS570_GCLK_HZ;
 }
 
 CPU_Counter_ticks _CPU_Counter_read(void)
diff --git a/bsps/arm/tms570/include/bsp.h b/bsps/arm/tms570/include/bsp.h
index 287750295f..1f84486ad4 100644
--- a/bsps/arm/tms570/include/bsp.h
+++ b/bsps/arm/tms570/include/bsp.h
@@ -61,12 +61,6 @@
 #include 
 #include 
 
-#if TMS570_VARIANT == 4357
-#define BSP_PLL_OUT_CLOCK 15000
-#else
-#define BSP_PLL_OUT_CLOCK 16000
-#endif
-
 RTEMS_NO_RETURN void bsp_restart(const void *addr);
 
 #endif /* ASM */
diff --git a/spec/build/bsps/arm/tms570/grp.yml 
b/spec/build/bsps/arm/tms570/grp.yml
index 5a3d4784be..c6d9f02d14 100644
--- a/spec/build/bsps/arm/tms570/grp.yml
+++ b/spec/build/bsps/arm/tms570/grp.yml
@@ -32,6 +32,18 @@ links:
   uid: optmintskstksz
 - role: build-dependency
   uid: optoscmain
+- role: build-dependency
+  uid: optgclk
+- role: build-dependency
+  uid: opthclk
+- role: build-dependency
+  uid: optvclk
+- role: build-dependency
+  uid: optvclk2
+- role: build-dependency
+  uid: optvclk3
+- role: build-dependency
+  uid: optrticlk
 - role: build-dependency
   uid: optreginit
 - role: build-dependency
diff --git a/spec/build/bsps/arm/tms570/optgclk.yml 
b/spec/build/bsps/arm/tms570/optgclk.yml
new file mode 100644
index 00..f7ec86a250
--- /dev/null
+++ b/spec/build/bsps/arm/tms570/optgclk.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-integer: null
+- define: null
+build-type: option
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH & Co. KG
+default:
+- enabled-by:
+  - arm/tms570lc4357_hdk
+  - arm/tms570lc4357_hdk_sdram
+  value: 3
+- enabled-by: true
+  value: 16000
+description: |
+  The option value shall be the GCLK frequency in Hz.
+enabled-by: true
+format: '{}'
+links: []
+name: TMS570_GCLK_HZ
+type: build
diff --git a/spec/build/bsps/arm/tms570/opthclk.yml 
b/spec/build/bsps/arm/tms570/opthclk.yml
new file mode 100644
index 00..652c151eec
--- /dev/null
+++ b/spec/build/bsps/arm/tms570/opthclk.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier:

[PATCH 3/9] bsps/cache: Fix ARM CP-15 get cache size

The rtems_cache_get_data_cache_size() and
rtems_cache_get_instruction_cache_size() functions shall return the entire
cache size for a level of 0.  Levels greater than 0 shall return the size of
the associated level.

Update #4982.
---
 bsps/arm/shared/cache/cache-cp15.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bsps/arm/shared/cache/cache-cp15.c 
b/bsps/arm/shared/cache/cache-cp15.c
index 92ccfcb276..8e0f22282b 100644
--- a/bsps/arm/shared/cache/cache-cp15.c
+++ b/bsps/arm/shared/cache/cache-cp15.c
@@ -222,12 +222,12 @@ static inline size_t arm_cp15_get_cache_size(
   clidr = arm_cp15_get_cache_level_id();
   loc = arm_clidr_get_level_of_coherency(clidr);
 
-  if (level >= loc) {
-return 0;
-  }
-
   if (level == 0) {
 level = loc - 1;
+  } else if (level - 1 >= loc) {
+return 0;
+  } else {
+--level;
   }
 
   ccsidr = arm_cp15_get_cache_size_id_for_level(
-- 
2.35.3

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

[PATCH 2/9] bsps/cache: Simplify Cortex-R5 cache support