[PATCH] gcc12/libstdc++: Fix lifetime bugs for non-TLS eh_globals

[chrisj]

From: Chris Johns 

- This is the fix from PR105880:
   https://gcc.gnu.org/bugzilla/attachment.cgi?id=53103

Closes #4661
---
 .../config/tools/rtems-gcc-12-newlib-head.cfg | 29 ++-
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
index ce168ea..f7a0b55 100644
--- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
@@ -5,13 +5,21 @@
 %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 
f9eb91029c31ed2ca3c4ce2066d99352f63f55120aaad295b58621786fe76228d182a4421292fa95007ac6b6529a589795fe3e794ac77b0b86f9cf9286125e36
+%hash sha512 %{gcc_expand_name}.tar.gz \
+ 
+euRApwx7SyjxM4gZtmTUvY/VRIKqtKVtYYheG/nYijRgqRCEpL6lQB6xrZSmliXlf4+eUrHewuG+c+ShhJeNg==
+
+%patch add gcc -p1 
--rsb-file=PR105880-libstdcxx-Fix-lifetime-bugs-for-non-TLS-eh_globals.patch \
+ https://gcc.gnu.org/bugzilla/attachment.cgi?id=53103
+%hash sha512 PR105880-libstdcxx-Fix-lifetime-bugs-for-non-TLS-eh_globals.patch\
+
4ueSYXR59fcp0tch/6p4ktay2srtx6h2hmREL4qtNr4TvglwurWUdqN3c9mIe38YDPcY/braF+83vHSCybg33Q==
 
 %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 
413f14374856f8bfd2bb94a56f1860fff8fe9a936f33c96fdf6a5a0c5a30e2cf7d05026d0338e8b30015a93d80169a602397076b947c8292ac5b5cdc2237ec4e
+%hash sha512 0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch \
+ 
QT8UN0hW+L/Su5Slbxhg//j+mpNvM8lv32paDFow4s99BQJtAzjoswAVqT2AFppgI5cHa5R8gpKsW1zcIjfsTg==
 
 %patch add newlib -p1 
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
-%hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
+%hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch \
+ 
fKI36r/Vs4JxMYbh/CkN/JmaNTMVeV7LjdDSL80at/W/MfQymVStq5GtBMEA3KwOhtQG/bzo+Cz53COELIjK9g==
 
 # Following patches are related to compilation on Apple M1/Darwin host 
platform.
 # They are here to workaround issues with ISL, MPFR and MPC libraries.
@@ -20,18 +28,23 @@
 # The patches are solely for libisl 0.24, libmpfr 4.1.0 and libmpc 1.2.1
 # See #4657 for more information.
 %patch add isl -p1 
https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-isl-config.patch
-%hash sha512 fix-mac-arm64-isl-config.patch 
c07fdb605a6520d194358504731e63b540211ef680383f1ca4ec65b4ac43ae27687534fd7d8196a4dbe83a0ecf2c42a4254c71e609ee484a7614573bc499a2e8
+%hash sha512 fix-mac-arm64-isl-config.patch \
+
wH/bYFplINGUNYUEcx5jtUAhHvaAOD8cpOxltKxDridodTT9fYGWpNvoOg7PLEKkJUxx5gnuSEp2FFc7xJmi6A==
 %patch add mpfr -p1 
https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-mpfr-config.patch
-%hash sha512 fix-mac-arm64-mpfr-config.patch 
dc5069df870bd02b7e78ed22c6ad9e9a2bb9ca372ce1a6b7e8fa5b7635dcef35c29f251fe5195c9c2a43513116c12cab1b0e96171cf34bd7fb7d0334c2c740fb
+%hash sha512 fix-mac-arm64-mpfr-config.patch \
+
3FBp34cL0Ct+eO0ixq2emiu5yjcs4aa36PpbdjXc7zXCnyUf5RlcnCpDUTEWwSyrGw6WFxzzS9f7fQM0wsdA+w==
 %patch add mpc -p1 
https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-mpc-config.patch
-%hash sha512 fix-mac-arm64-mpc-config.patch 
2849b11e360ea98e0b4d708c67723ad2d6c7bac6d1e469673f408b0111cf0278429e8bc38fd2b7538dc2d5bb0cc430c646a0fa7f0b6b105a0482a5455fadc8b9
+%hash sha512 fix-mac-arm64-mpc-config.patch \
+
KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
 # Comment above related to #4657 and patches ends here
 
 %define newlib_version 64b2081
 %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 
0e142b06b855b78729c3319e31cf5c15b48cea1f90e001ae1e2d61793c496374065c5658e835e6277ae0739af22ea397feb2c1bc2509a6a80ee6c03818efbf55
+%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 \
+   
DhQrBrhVt4cpwzGeMc9cFbSM6h+Q4AGuHi1heTxJY3QGXFZY6DXmJ3rgc5ryLqOX/rLBvCUJpqgO5sA4GO+/VQ==
 
 %define with_threads 1
 %define with_plugin 0
-- 
2.24.1

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

[RSB] GCC 12 libstd++ Fix lifetime bugs for non-TLS eh_globals

[chrisj]

Hi,

This patch applies the fix for non-TLS eh_globals archs. See:

https://devel.rtems.org/ticket/4661
https://gcc.gnu.org/bugzilla/attachment.cgi?id=53103

Chris

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

Re: [gcc v2] Enable some features for RTEMS in libstdc++

[Chris Johns]

On 22/6/2022 6:38 am, Chris Johns wrote:
>> On 21 Jun 2022, at 5:39 pm, Sebastian Huber
>>  wrote:
>>
>> On 09/06/2022 20:19, Sebastian Huber wrote:
>>> Remove RTEMS support from crossconfig.m4 since this code is not used due to
>>> "with_newlib" being "yes".
>>> libstdc++-v3/ChangeLog:
>>>    * configure: Regnerate.
>>>    * configure.ac (newlib, *-rtems*): Enable TLS support for all RTEMS
>>>    targets except bfin, lm32, mips, moxie, or1k, and v850.
>>>    For all RTEMS targets, define HAVE_ALIGNED_ALLOC, HAVE_AT_QUICK_EXIT,
>>>    HAVE_LINK, HAVE_POLL, HAVE_QUICK_EXIT, HAVE_READLINK, HAVE_SETENV,
>>>    HAVE_SLEEP, HAVE_SOCKATMARK, HAVE_STRERROR_L, HAVE_SYMLINK,
>>>    HAVE_TRUNCATE, and HAVE_USLEEP.
>>>    * crossconfig.m4 (*-rtems*): Remove.
>>
>> Any comments? 

Is there a ticket to track this change?

> I think this is sensible. Has it been tested on real code?
> 
>> I would like to back port this patch to GCC 10, 11, and 12.

I see this patch is for master. Is a gcc 12 patch available so I can test it?

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

Re: [gcc v2] Enable some features for RTEMS in libstdc++

[Chris Johns]

> On 21 Jun 2022, at 5:39 pm, Sebastian Huber 
>  wrote:
> 
> On 09/06/2022 20:19, Sebastian Huber wrote:
>> Remove RTEMS support from crossconfig.m4 since this code is not used due to
>> "with_newlib" being "yes".
>> libstdc++-v3/ChangeLog:
>>* configure: Regnerate.
>>* configure.ac (newlib, *-rtems*): Enable TLS support for all RTEMS
>>targets except bfin, lm32, mips, moxie, or1k, and v850.
>>For all RTEMS targets, define HAVE_ALIGNED_ALLOC, HAVE_AT_QUICK_EXIT,
>>HAVE_LINK, HAVE_POLL, HAVE_QUICK_EXIT, HAVE_READLINK, HAVE_SETENV,
>>HAVE_SLEEP, HAVE_SOCKATMARK, HAVE_STRERROR_L, HAVE_SYMLINK,
>>HAVE_TRUNCATE, and HAVE_USLEEP.
>>* crossconfig.m4 (*-rtems*): Remove.
> 
> Any comments?

I think this is senseible. Has it been tested on real code?

> I would like to back port this patch to GCC 10, 11, and 12.

Does this imply rtems 5?

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

Re: Updated CAN message structure.

[Pavel Pisa]

Hello Prashanth S,

On Tuesday 21 of June 2022 19:00:42 Prashanth S wrote:
> This is to present the updated CAN message structure.
>
> *Updating the CAN message structure:*
>
> struct can_message {
>   uint32_t id; // 32 bits to support extended id (29 bits)
>   uint32_t timestamp;
>   uint16_t flags;// RTR | BRS | EXT ...
>   uint16_t len;
>   uint8_t data[64]; // For supporting data transfer up to 64 bytes.
>   };

from my side optimal, no other suggestions.

Best wishes,

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

Updated CAN message structure.

[Prashanth S]

Hi All,

This is to present the updated CAN message structure.

*Updating the CAN message structure:*

struct can_message {
  uint32_t id; // 32 bits to support extended id (29 bits)
  uint32_t timestamp;
  uint16_t flags;// RTR | BRS | EXT ...
  uint16_t len;
  uint8_t data[64]; // For supporting data transfer up to 64 bytes.
  };

Regards
Prashanth S

On Tue, 21 Jun 2022 at 14:43, Oliver Hartkopp 
wrote:

> Hi Christian,
>
> I'm not subscribed to the RTEMS ML so my mail has not been forwarded.
>
> I'm with you about the 16 bit length info.
>
> See below ...
>
> On 6/21/22 08:55, Oliver Hartkopp wrote:
> > Hello all,
> >
> > I'm definitely with Pavel's suggestions here!
> >
> > I added some small remarks regarding the current CAN XL discussion
> in-line:
> >
> > On 20.06.22 22:57, Pavel Pisa wrote:
> >> Hello Prashanth S and others,
> >>
> >> excuse me for lower activity last weeks. We have exams period
> >> and I have lot of other duties and was even ill. I am at Embedded
> >> World in Nuremberg now, so may it be there is some chance to meet
> >> somebody other from RTEMS community.
> >>
> >> As for the e-mail it is better to add one of my personal e-mails
> >> (p...@cmp.felk.cvut.cz or pp...@pikron.com)
> >> to notice me for something important, I do not check every
> >> message comming through my list subscription. I go through
> >> RTEMS, NuttX, CAN, etc. forums only when I have spare time.
> >>
> >> On Monday 20 of June 2022 18:37:38 Prashanth S wrote:
> >>> This is a request for suggestions and feedback for the CAN message
> >>> structure.
> >>>
> >>> *CAN message structure that represents the can messages from
> >>> application to
> >>> driver:*
> >>>
> >>> struct can_message {
> >>> uint32_t timestamp;
> >>> uint32_t id; // 32 bits to support extended id (29
> bits)
> >>> uint16_t flags;// RTR | BRS | EXT ...
> >>> uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48
> >>> | 64
> >>> uint8_t res; // reserved for alignment.
> >>> uint8_t data[64]; // For supporting data transfer up to 64
> >>> bytes.
> >>> };
> >>>
> >>> This is the CAN messages structure created based on the suggestions
> >>> in the
> >>> mail chain and looking through other CAN solutions (Nuttx, GRCAN,
> >>> LinCAN).
> >>
> >> Yes I like solution with explicit and aligned fields.
> >> I confirm that I think that length representing real data length is
> >> better
> >> and it has been chosen for CAN FD by SocketCAN.
> >
> > Yes. Handling the DLC/Length conversion in every user program is a mess.
> > That's why we actually changed the dlc to len even for Classical CAN
> > frames in the struct can_frame:
> >
> > struct can_frame {
> >  canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
> >  union {
> >  /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
> >   * was previously named can_dlc so we need to carry that
> >   * name for legacy support
> >   */
> >  __u8 len;
> >  __u8 can_dlc; /* deprecated */
> >  } __attribute__((packed)); /* disable padding added in some
> > ABIs */
> >  __u8 __pad; /* padding */
> >  __u8 __res0; /* reserved / padding */
> >  __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 ..
> > 15) */
> >  __u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));
> > };
> >
> > You might also think about a union to carry the Classical CAN length and
> > the CAN FD length in one 8 bit value and add the extra Classical CAN raw
> > DLC in another 8 bit value - and make a union with a 16 bit length value
> > which is needed for CAN XL.
> >
> >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/can.h?id=ea7800565a128c1adafa1791ce80afd6016fe21c
> >
> >
> > But in fact the raw DLC value has been introduced only because of some
> > people doing security testing. The Classical CAN raw DLC value has no
> > value for normal CAN applications and therefore using a simple 16 bit
> > length value would be the best choice IMHO (see below).
> >
> >> I confirm that flags implemented with explicit sized field seem to be
> >> more
> >> safe to me. Bitfields are tricky due to endianing and have problem with
> >> initialization and copying when new field is added.
> >>
> >> I am not sure if the field name "dlc" (data length code) is right
> >> when the field represents real length, may be "len" is a better
> >> match.
> >
> > Yes, definitely!
> >
> >> I think that fields order makes sense as well (alignment, purpose
> etc..).
> >> Only think to consider is possibility to swap
> >>
> >>uint32_t timestamp;
> >>uint32_t id;
> >>
> >> because id is the first and the most important and accessed field,
> >> so when the pointer to structure is give it can be small win
> >> on some targets that it can be accessed without 

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

[oss]

Am 21.06.22 um 16:31 schrieb Duc Doan:

Using examples of working APIs is a good idea. But be careful not to
copy any code from that framework because the license (GPL) wouldn't be
compatible.


Sure, I don't copy their code but only see what functions should be in a 
GPIO API (like read, write, toggle, pinmode).


Is set and reset the only state a pin can have? Or is that field
thought
to be extended with (for example) open drain or similar states if a
device supports that?


I think it can be extended but I have only put in the most basic states 
for now.



Beneath that: Not a fan of SET == 0. I think RESET == 0 would be better
because than you can use it as a boolean without conversion.


You are right, that was my mistake. I have fixed it.

Does that mean it is (for example) a GPIO controller? In that case
maybe
call it "rtems_gpio_ctrl_t". My first guess from the name would have
been that it is already a pin.

I have made changes in my newest patch, and rtems_gpio_t is now 
essentially a pin.


Same is true for the structures below: How would I initialize one of
these objects in the application?


The example initialization of those structures can be found in my sample 
blink code: 
https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps/blob/main/RTEMS_Blink_API/src/init.c 
 


OK. So every BSP that want's to use that API will have a different 
rtems_gpio_config_t (or every other structure) that is defined in (for 
example) bsp.h? The application has to know the details of the current 
BSP and initialize the structure accordingly.


That means that if I write an application that can run on an STM32 or 
alternatively on some RISC-V based CPU the API will be different. Not 
really portable.


I know that it is difficult in this case. On the one hand an API should 
be portable. On the other hand it should be able to handle very 
different hardware. And all that with the lowest possible overhead. In 
the end it will be some compromise.


Your goal is to either offer a better compromise than the API that is 
currently used for beagle and RPi. Or as an alternative: Don't try to go 
for an universal one and focus on your current device like a lot of the 
BSPs do. I would prefer a good universal API (better than the Beagle / 
RPi one (*)) but I know the problems so I could live with a device 
specific too. But note that this is my personal opinion. Others might 
have a different one.


(*) In case someone didn't see that (I think it was on discord): The 
Beagle / RPi API has two weaknesses in my point of view:


1. It mixes GPIO with Pinmuxing which is not true for all chips. For 
example the whole Freescale / NXP devices tend to have separate 
controllers for that. Having two APIs for that would be better in my 
point of view.


2. It is written with a quite fixed structure in mind. Controllers that 
don't have that structure need bigger workarounds which makes the API slow.


. The definition of the structures are defined by BSP. Here are 
STM32F4's definitions:

/* CODE BEGINS ***/
struct rtems_gpio_t {
     GPIO_TypeDef *port;
     uint16_t pin;
};

/**
   * This structure should be initialized to 0
   *
   * This structure holds configuration options for STM32F4-specific
   * GPIO. The 2 specific modes are Event and Alternate modes. Select
   * a mode by setting the correct field (is_event_mode or 
is_alternate_mode)

   * to 1.
   */
struct rtems_gpio_config_t {
     uint32_t speed;             /* Speed of the pin. Must be specified */

     uint32_t interrupt_mode;    /* The type of interrupt trigger of the 
pin

                                    Use if the pin is in Interrupt mode */

     uint32_t is_event_mode;     /* Sets to 1 if the pin is in event mode,
                                    0 other wise.
                                    Use if the pin is in Event mode */
     uint32_t event_mode;        /* The type of event trigger of the pin
                                    Use if the pin is in Event mode */

     uint32_t is_alternate_mode; /* Sets to 1 if the pin is in Alternate 
mode,

                                    0 other wise.
                                    Use if the pin is in Alternate mode */
     uint32_t alternate_mode;    /* Open drain or Push-pull mode
                                    Use if the pin is in Alternate mode */
     uint32_t alternate_fn;      /* The alternate function of the pin
                                    Use if the pin is in Alternate mode */
};
/* CODE ENDS ***/

What would be done in that function?

Why does the application has to implement it?

Where would it be called?


The initialize function is meant to perform setup code for the GPIO. For 
example, for the 

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

[Duc Doan]

>
> Using examples of working APIs is a good idea. But be careful not to
> copy any code from that framework because the license (GPL) wouldn't be
> compatible.


Sure, I don't copy their code but only see what functions should be in a
GPIO API (like read, write, toggle, pinmode).

Is set and reset the only state a pin can have? Or is that field thought
> to be extended with (for example) open drain or similar states if a
> device supports that?
>

I think it can be extended but I have only put in the most basic states for
now.


> Beneath that: Not a fan of SET == 0. I think RESET == 0 would be better
> because than you can use it as a boolean without conversion.
>

You are right, that was my mistake. I have fixed it.

Does that mean it is (for example) a GPIO controller? In that case maybe
> call it "rtems_gpio_ctrl_t". My first guess from the name would have
> been that it is already a pin.
>

I have made changes in my newest patch, and rtems_gpio_t is now essentially
a pin.

Same is true for the structures below: How would I initialize one of
> these objects in the application?
>

The example initialization of those structures can be found in my sample
blink code:
https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps/blob/main/RTEMS_Blink_API/src/init.c
. The definition of the structures are defined by BSP. Here are STM32F4's
definitions:
/* CODE BEGINS ***/
struct rtems_gpio_t {
GPIO_TypeDef *port;
uint16_t pin;
};

/**
  * This structure should be initialized to 0
  *
  * This structure holds configuration options for STM32F4-specific
  * GPIO. The 2 specific modes are Event and Alternate modes. Select
  * a mode by setting the correct field (is_event_mode or is_alternate_mode)
  * to 1.
  */
struct rtems_gpio_config_t {
uint32_t speed; /* Speed of the pin. Must be specified */

uint32_t interrupt_mode;/* The type of interrupt trigger of the pin
   Use if the pin is in Interrupt mode */

uint32_t is_event_mode; /* Sets to 1 if the pin is in event mode,
   0 other wise.
   Use if the pin is in Event mode */
uint32_t event_mode;/* The type of event trigger of the pin
   Use if the pin is in Event mode */

uint32_t is_alternate_mode; /* Sets to 1 if the pin is in Alternate
mode,
   0 other wise.
   Use if the pin is in Alternate mode */
uint32_t alternate_mode;/* Open drain or Push-pull mode
   Use if the pin is in Alternate mode */
uint32_t alternate_fn;  /* The alternate function of the pin
   Use if the pin is in Alternate mode */
};
/* CODE ENDS ***/

What would be done in that function?
>
> Why does the application has to implement it?
>
> Where would it be called?
>

The initialize function is meant to perform setup code for the GPIO. For
example, for the STM32, it would be enabling the clocks of the ports. The
application needs to implement it if they want to use GPIO because the
peripheral needs initialization. They don't have to, though, if they want
to do that initialization somewhere else. This function is called in
bsp_start(). It is already implemented as a weak, empty function, so there
is no problem if the user doesn't implement it.

What would be possible error cases? Is one "UNSATISFIED" enough or
> should it be able to return other errors too (like the return value from
> an I2C transfer because the pin is connected to some SPI-GPIO extender).


 I think "UNSATISFIED" is enough because these are quite low-level. I think
the return values from more complicated things like I2C should be handled
in other functions (like the I2C API), and I want to keep the GPIO thing
portable. I am open to more discussion though, because I am not sure I can
think of all use cases of this GPIO API.

If the write can fail, the read can also fail. Do we need an error
> return value too?
>

Yes, I think that's a good idea. I changed it as below:

/**
  * @brief Reads the digital value of a pin.
  *
  * @param[in] gpiox The GPIO object that owns the pin.
  *
  * @param[out] value The state of the pin.
  *
  * @retval RTEMS_SUCCESSFUL Pin succesfully read.
  * @retval RTEMS_UNSATISFIED Could not read pin.
  */
extern rtems_status_code rtems_gpio_read_pin(rtems_gpio_t *gpiox,
rtems_gpio_pin_state *value);

Best,

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

Re: GSoC 2022 - CAN API test

[Pavel Pisa]

Hello Prashanth S and others,

I am copying reply to the list for recrd and others consideration

On Sunday 19 of June 2022 17:30:16 Christian Mauderer wrote:
> Would that be a generic test for the CAN API that all BSPs can run? Or
> would it be a hardware specific one?

The CAN base test can be HW independent when system is brought
up and CAN interface is configured. Even bitrate and actual
bring up can be target independed if the driver provides
common IOCTL to setup bitrate, sampling point etc. common
way. Only speed has to be changed for for case when transmitter
cannot handle given rate. And for sure you need to know
if the interface is CAN FD capable.

Even for really thorough performance testing of the driver,
it is enough to to implement function which receives each
received frame, decreases CAN ID by one and sends it back.
The ID decrease is required to increase priority of reply
Tx message which ensures that tester flood does not block
the reply.

This test has been used by Jan Charvat during testing
of NuttX ESP32C3 CAN driver testing
https://dspace.cvut.cz/bitstream/handle/10467/101692/F3-DP-2022-Charvat-Jan-NuttX-RTOS-CAN-Bus-Driver-for-Espressif-ESP32C3.pdf
 
You can use Linux kernel based system on the side of the tester
and if the latency tester side provides HW timestamping
then you can retrieve really precise statistic/characteristic
of the HW. I infrastructure has been used in past even to attest
RTEMS CAN driver on MPC5200.

If you have two interfaces, you can forward messages from one
to another and flood system. We have done such testing
for Oliver Hartkopp to attest Linux kernel CAN gateway.

The code has been updated by Matej Vasilevski during his thesis
https://dspace.cvut.cz/bitstream/handle/10467/101450/F3-DP-2022-Vasilevski-Matej-vasilmat.pdf

The other option is to use our old VCA abstraction which
for CAN provides compatability between LinCAN, SocketCAN
and NuttX CAN API and includes canping utility with
master and slave side for throughput testing.

All is part of OrtCAN project

http://ortcan.sourceforge.net/

CAN ping

https://sourceforge.net/p/ortcan/canping/ci/master/tree/

The interfacing to RTEMS API on libVCA side would be easy.
The file to connect library to SocketCAN, LinCAN or NuttX is
singe file, NuttX example

https://sourceforge.net/p/ortcan/ortcan-vca/ci/master/tree/libvca/vca_inuttx.c

So I think there are many options, simple loop to read aceh message
and send it with ID-1 is simple and usesfull step tos tart.

Best wishes,

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

Fwd: Re: Request for feedback for CAN message structure

[Pavel Pisa]

I am forwarding Oliver Hartkopp's founded reply
to the list for archival and rest of the RTEMS
community

--  Forwarded Message  --

Subject: Re: Request for feedback for CAN message structure
Date: Tuesday 21 of June 2022, 08:55:03
From: Oliver Hartkopp 
To: Pavel Pisa , devel@rtems.org
CC: Prashanth S 

Hello all,

I'm definitely with Pavel's suggestions here!

I added some small remarks regarding the current CAN XL discussion in-line:

On 20.06.22 22:57, Pavel Pisa wrote:
> Hello Prashanth S and others,
> 
> excuse me for lower activity last weeks. We have exams period
> and I have lot of other duties and was even ill. I am at Embedded
> World in Nuremberg now, so may it be there is some chance to meet
> somebody other from RTEMS community.
> 
> As for the e-mail it is better to add one of my personal e-mails
> (p...@cmp.felk.cvut.cz or pp...@pikron.com)
> to notice me for something important, I do not check every
> message comming through my list subscription. I go through
> RTEMS, NuttX, CAN, etc. forums only when I have spare time.
> 
> On Monday 20 of June 2022 18:37:38 Prashanth S wrote:
>> This is a request for suggestions and feedback for the CAN message
>> structure.
>>
>> *CAN message structure that represents the can messages from application to
>> driver:*
>>
>> struct can_message {
>> uint32_t timestamp;
>> uint32_t id; // 32 bits to support extended id (29 bits)
>> uint16_t flags;// RTR | BRS | EXT ...
>> uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64
>> uint8_t res; // reserved for alignment.
>> uint8_t data[64]; // For supporting data transfer up to 64 bytes.
>> };
>>
>> This is the CAN messages structure created based on the suggestions in the
>> mail chain and looking through other CAN solutions (Nuttx, GRCAN, LinCAN).
> 
> Yes I like solution with explicit and aligned fields.
> I confirm that I think that length representing real data length is better
> and it has been chosen for CAN FD by SocketCAN.

Yes. Handling the DLC/Length conversion in every user program is a mess. 
That's why we actually changed the dlc to len even for Classical CAN 
frames in the struct can_frame:

struct can_frame {
 canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
 union {
 /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
  * was previously named can_dlc so we need to carry that
  * name for legacy support
  */
 __u8 len;
 __u8 can_dlc; /* deprecated */
 } __attribute__((packed)); /* disable padding added in some ABIs */
 __u8 __pad; /* padding */
 __u8 __res0; /* reserved / padding */
 __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. 
15) */
 __u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));
};

You might also think about a union to carry the Classical CAN length and 
the CAN FD length in one 8 bit value and add the extra Classical CAN raw 
DLC in another 8 bit value - and make a union with a 16 bit length value 
which is needed for CAN XL.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/can.h?id=ea7800565a128c1adafa1791ce80afd6016fe21c

But in fact the raw DLC value has been introduced only because of some 
people doing security testing. The Classical CAN raw DLC value has no 
value for normal CAN applications and therefore using a simple 16 bit 
length value would be the best choice IMHO (see below).

> I confirm that flags implemented with explicit sized field seem to be more
> safe to me. Bitfields are tricky due to endianing and have problem with
> initialization and copying when new field is added.
> 
> I am not sure if the field name "dlc" (data length code) is right
> when the field represents real length, may be "len" is a better
> match.

Yes, definitely!

> I think that fields order makes sense as well (alignment, purpose etc..).
> Only think to consider is possibility to swap
> 
>uint32_t timestamp;
>uint32_t id;
> 
> because id is the first and the most important and accessed field,
> so when the pointer to structure is give it can be small win
> on some targets that it can be accessed without offset addition.
> But that is probably neglectable and there can be arguments against.

The 'id' really defines the CAN frame so it can be seen as a 'key' - 
like in a data base. It makes sense to put it first.

Btw. adding RTR and EXT to the flags field is something I would do today 
too. Good choice!

> Another think to consider is a size of "dlc" and or "len" code.
> There is ongoing standardization process for CAN XL and it
> would allow CAN frames up to 2kB and the length will be with
> byte granularity. But CAN XL adds datatype filed and much more
> options so it is probably out of the actual RTEMS scope
> and would require variable length read and write systemcalls
> 

[PATCH] kern_tc.c: Provide a weak hardpps() implementation

[Sebastian Huber]

The real implementation of hardpps() is defined in kern_ntptime.c.  Use it only
if the NTP support is needed by the application.

Update #2349.
---
 cpukit/score/src/kern_tc.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 78d7fa1e3f..449c830905 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2079,6 +2079,18 @@ pps_ioctl(u_long cmd, caddr_t data, struct pps_state 
*pps)
 }
 
 #ifdef __rtems__
+/*
+ * The real implementation of hardpps() is defined in kern_ntptime.c.  Use it
+ * only if the NTP support is needed by the application.
+ */
+RTEMS_WEAK void
+hardpps(struct timespec *tsp, long nsec);
+{
+
+   (void)tps;
+   (void)nsec;
+}
+
 static int
 default_wait(struct pps_state *pps, struct timespec timeout)
 {
-- 
2.35.3

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

Re: Request for feedback for CAN message structure

[oss]

Hello Pavel and Prashanth,

Am 20.06.22 um 22:57 schrieb Pavel Pisa:

Hello Prashanth S and others,

excuse me for lower activity last weeks. We have exams period
and I have lot of other duties and was even ill. I am at Embedded
World in Nuremberg now, so may it be there is some chance to meet
somebody other from RTEMS community.

As for the e-mail it is better to add one of my personal e-mails
(p...@cmp.felk.cvut.cz or pp...@pikron.com)
to notice me for something important, I do not check every
message comming through my list subscription. I go through
RTEMS, NuttX, CAN, etc. forums only when I have spare time.

On Monday 20 of June 2022 18:37:38 Prashanth S wrote:

This is a request for suggestions and feedback for the CAN message
structure.

*CAN message structure that represents the can messages from application to
driver:*

struct can_message {
uint32_t timestamp;
uint32_t id; // 32 bits to support extended id (29 bits)
uint16_t flags;// RTR | BRS | EXT ...
uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64
uint8_t res; // reserved for alignment.
uint8_t data[64]; // For supporting data transfer up to 64 bytes.
};

This is the CAN messages structure created based on the suggestions in the
mail chain and looking through other CAN solutions (Nuttx, GRCAN, LinCAN).


Yes I like solution with explicit and aligned fields.
I confirm that I think that length representing real data length is better
and it has been chosen for CAN FD by SocketCAN.

I confirm that flags implemented with explicit sized field seem to be more
safe to me. Bitfields are tricky due to endianing and have problem with
initialization and copying when new field is added.

I am not sure if the field name "dlc" (data length code) is right
when the field represents real length, may be "len" is a better
match.

I think that fields order makes sense as well (alignment, purpose etc..).
Only think to consider is possibility to swap

   uint32_t timestamp;
   uint32_t id;

because id is the first and the most important and accessed field,
so when the pointer to structure is give it can be small win
on some targets that it can be accessed without offset addition.
But that is probably neglectable and there can be arguments against.

Another think to consider is a size of "dlc" and or "len" code.
There is ongoing standardization process for CAN XL and it
would allow CAN frames up to 2kB and the length will be with
byte granularity. But CAN XL adds datatype filed and much more
options so it is probably out of the actual RTEMS scope
and would require variable length read and write systemcalls
because 2kB overhead for some 1 or 2 byte message is too high.

So even 8 bit length field is OK for now and may be res field
can solve CAN XL compatibility one day.


Not sure where the field will be used but wouldn't it be better if 
length is 16 bit already if there is an upcoming standard that will 
support lengths that need it. Otherwise some drivers might use the "res" 
for something else or make some assumptions about the length of the 
field that make it harder to change it later.


Best regards

Christian



So generally I agree with the message structure, I declare
minor weight vote to switch from "dlc" to "len".
I think that switch to common message structure based API
on RTEMS would be big win and that (at least for
now) keeping character device like API with IOCTLs
is simpler and matches better actual RTEMS CAN implementations.

Best wishes,

Pavel
___
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: [gcc v2] Enable some features for RTEMS in libstdc++

[Sebastian Huber]

On 09/06/2022 20:19, Sebastian Huber wrote:

Remove RTEMS support from crossconfig.m4 since this code is not used due to
"with_newlib" being "yes".

libstdc++-v3/ChangeLog:

* configure: Regnerate.
* configure.ac (newlib, *-rtems*): Enable TLS support for all RTEMS
targets except bfin, lm32, mips, moxie, or1k, and v850.
For all RTEMS targets, define HAVE_ALIGNED_ALLOC, HAVE_AT_QUICK_EXIT,
HAVE_LINK, HAVE_POLL, HAVE_QUICK_EXIT, HAVE_READLINK, HAVE_SETENV,
HAVE_SLEEP, HAVE_SOCKATMARK, HAVE_STRERROR_L, HAVE_SYMLINK,
HAVE_TRUNCATE, and HAVE_USLEEP.
* crossconfig.m4 (*-rtems*): Remove.


Any comments? I would like to back port this patch to GCC 10, 11, and 12.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel