Re: Does libbsd really require POSIX enabled now?

[Sebastian Huber]

On 09/06/2022 15:50, Sebastian Huber wrote:

Technically, it should be a big issue.


Technically, it should NOT be a big issue.

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

Static Analysis Tools for RTEMS

[Joel Sherrill]

Hi

With Matthew addressing new warnings from GCC 12, I thought it would be
good to remind everyone that the RTEMS Project has access to two static
analysis tools. As you work, fix bugs/warnings, etc., please remember to
look at the results for the area of code you are touching from the static
analysis tools we have access to:

+ Coverity - https://scan.coverity.com/

+ Codiga - https://app.codiga.io/login?next=/home

Hopefully both of those URLs get you close enough. You will have to ask for
permission to see RTEMS results with both tools.

I should have rtems, rtems-tools, and newlib running automatically. You can
get email from Coverity to report if any issues were added or fixed per
run. Codiga is newer for us and operational experience is lacking. Help
appreciated.

Both run on pushes. Coverity has a max of three runs a day per repository.

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

Re: [gcc] Enable TLS support for RTEMS in libstdc++

[Sebastian Huber]

On 09/06/2022 15:58, Joel Sherrill wrote:



On Thu, Jun 9, 2022 at 2:12 AM Chris Johns > wrote:


On 9/6/2022 4:16 pm, Sebastian Huber wrote:
 > On 08/06/2022 16:18, Sebastian Huber wrote:
 >> On 08/06/2022 16:11, Joel Sherrill wrote:
 >>> On Wed, Jun 8, 2022 at 8:47 AM Sebastian Huber
 >>> mailto:sebastian.hu...@embedded-brains.de>
 >>> >> wrote:
 >>>
 >>>     On 08/06/2022 15:39, Joel Sherrill wrote:
 >>>  > Is TLS actually supported on all targets except MIPS?
 >>>
 >>>     I only added MIPS since this target has a fundamental issue
with the
 >>>     TLS
 >>>     support.
 >>>
 >>>     Which target would you also exclude?
 >>>
 >>> About half of them.
 >>
 >> It seems to be only bfin, lm32, moxie, or1k, and v850. Are these
targets still
 >> in use? Do we have a maintainer for these targets?
 >
 > How do we want to proceed here? Add them to the exclude list in
the GCC
 > configuration, or encourage current or future users of these
targets to add the
 > TLS support so that they can use state of the art C++ support?
The initial TLS
 > support for RTEMS was added in 2013, so this is not really brand
new technology.

I think we should support TLS in C++ for the targets we know work
and any others
can use the eh_globals support. It does work and works OK with POSIX
keys.

How we document this is probability a more pressing question? I
cannot see any
language specific areas in the User or Classic API manuals.


I thought there were tickets for this.

NIOS II - https://devel.rtems.org/ticket/4214 



I also thought I had written up a master list of this at one point. I 
can't find more

than the above. But it should have been close to above.

There isn't a good place in the Classic API Guide for this and I am not sure
where it would go in the User Guide. There are a few features which are not
supported on all architectures -- TLS, SMP, and paravirtualization come to
mind. Distributed multiprocessing is supported but only a few BSPs 
support it.


The CPU Supplement has a section for each port on Thread Local Storage.
My first cut suggestion would be to ensure each port has a section that it
is or is not supported. If it isn't supported, link to a ticket specific 
to that
architecture with keyword TLS. Copy the ticket contents for each 
architecture

and make sure update the CPU Supplement is part of it.

Is there anywhere else it would not get lost?


There is also a foot note in the user manual:

https://docs.rtems.org/branches/master/user/overview/index.html#id11

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

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

Re: [gcc] Enable TLS support for RTEMS in libstdc++

[Joel Sherrill]

On Thu, Jun 9, 2022 at 2:12 AM Chris Johns  wrote:

> On 9/6/2022 4:16 pm, Sebastian Huber wrote:
> > On 08/06/2022 16:18, Sebastian Huber wrote:
> >> On 08/06/2022 16:11, Joel Sherrill wrote:
> >>> On Wed, Jun 8, 2022 at 8:47 AM Sebastian Huber
> >>>  >>> > wrote:
> >>>
> >>> On 08/06/2022 15:39, Joel Sherrill wrote:
> >>>  > Is TLS actually supported on all targets except MIPS?
> >>>
> >>> I only added MIPS since this target has a fundamental issue with
> the
> >>> TLS
> >>> support.
> >>>
> >>> Which target would you also exclude?
> >>>
> >>> About half of them.
> >>
> >> It seems to be only bfin, lm32, moxie, or1k, and v850. Are these
> targets still
> >> in use? Do we have a maintainer for these targets?
> >
> > How do we want to proceed here? Add them to the exclude list in the GCC
> > configuration, or encourage current or future users of these targets to
> add the
> > TLS support so that they can use state of the art C++ support? The
> initial TLS
> > support for RTEMS was added in 2013, so this is not really brand new
> technology.
>
> I think we should support TLS in C++ for the targets we know work and any
> others
> can use the eh_globals support. It does work and works OK with POSIX keys.
>
> How we document this is probability a more pressing question? I cannot see
> any
> language specific areas in the User or Classic API manuals.
>

I thought there were tickets for this.

NIOS II - https://devel.rtems.org/ticket/4214

I also thought I had written up a master list of this at one point. I can't
find more
than the above. But it should have been close to above.

There isn't a good place in the Classic API Guide for this and I am not sure
where it would go in the User Guide. There are a few features which are not
supported on all architectures -- TLS, SMP, and paravirtualization come to
mind. Distributed multiprocessing is supported but only a few BSPs support
it.

The CPU Supplement has a section for each port on Thread Local Storage.
My first cut suggestion would be to ensure each port has a section that it
is or is not supported. If it isn't supported, link to a ticket specific to
that
architecture with keyword TLS. Copy the ticket contents for each
architecture
and make sure update the CPU Supplement is part of it.

Is there anywhere else it would not get lost?

--joel


> 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: Does libbsd really require POSIX enabled now?

[Sebastian Huber]

On 09/06/2022 15:44, Joel Sherrill wrote:
Are there any features besides signals and sporadic scheduling that are 
enabled anymore?


Removing the requirement for RTEMS_POSIX_API for libbsd is just one item 
on my long TODO list. Technically, it should be a big issue. Some 
commands may still use signals. These would be bugs which needs to be fixed.


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

Does libbsd really require POSIX enabled now?

[Joel Sherrill]

Hi

I'm starting a new thread because Frank's documentation thread is long
enough already. From that thread:

===
> I also question why you say RTEMS_POSIX_API needs to be True. That
> does not enable much anymore. I only know of signals and the Sporadic
> Scheduler.
>
Because when I build libbsd without RTEMS_POSIX_API, I get this error:

RTEMS kernel POSIX support is disabled; configure RTEMS with --enable-posix
(complete log in /home/EB/frank_k/src/rtems-libbsd/build/config.log)

The TFTP FS and test suite do compile and work without RTEMS_POSIX_API
set true.
===

Historically, it may have been true that the POSIX API had to be enabled
but I don't think it has to be. If that can be confirmed, we need to drop
that requirement.

Are there any features besides signals and sporadic scheduling that are
enabled anymore?

Thanks.

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

[PATCH rtems-docs v2] TFTPFS: New documentation

[Frank Kuehndel]

From: Frank Kühndel 

---
 filesystem/index.rst   |   1 +
 filesystem/trivial_ftp.rst | 564 -
 2 files changed, 562 insertions(+), 3 deletions(-)

diff --git a/filesystem/index.rst b/filesystem/index.rst
index f4e2ed6..64a2f1d 100644
--- a/filesystem/index.rst
+++ b/filesystem/index.rst
@@ -9,6 +9,7 @@ RTEMS Filesystem Design Guide (|version|).
 .. topic:: Copyrights and License
 
 | |copy| 1988, 2015 On-Line Applications Research Corporation (OAR)
+| |copy| 2022 embedded brains GmbH (http://www.embedded-brains.de)
 
 .. include:: ../common/license.rst
 
diff --git a/filesystem/trivial_ftp.rst b/filesystem/trivial_ftp.rst
index e43c036..3ef8bba 100644
--- a/filesystem/trivial_ftp.rst
+++ b/filesystem/trivial_ftp.rst
@@ -3,7 +3,565 @@
 Trivial FTP Client Filesystem
 *
 
-This chapter describes the Trivial FTP (TFTP) Client Filesystem.
+This chapter describes the Trivial File Transfer Protocol (TFTP) Client
+Filesystem.  TFTP is designed to be an especially simple protocol which
+uses the User Datagram Protocol (UDP) for data transfer over the Internet.
+Its purpose is to send a single file between to network nodes (client and
+server).  A file can be sent in both directions, i.e. a client can either
+read a file from a server or write a file to the server.
 
-This chapter should be written after the IMFS chapter is completed and describe
-the implementation of the TFTP.
+Besides reading or writing a file no other operations are supported.  That
+is, one cannot seek the file, not append to the end of a file, not open
+the file for reading and writing at the same time, not list directories,
+not move files and so on.
+
+TFTP is inherent insecure as it does not provide any means for
+authentication or encryption.  Therefore, it is highly recommended not
+to employ it on public networks.  Nevertheless, it is still widely used
+to load software and configuration data during early boot stages over
+a Local Area Network (LAN).
+
+RTEMS TFTP Filesystem Implementation
+
+
+The RTEMS TFTP filesystem implements a TFTP client which can be used
+through the file system.  With other words, one needs to mount the
+TFTP filesystem and can afterwards open a file for reading or writing
+below that mount point.  The content of that file is then effectively
+read from or written to the remote server.  The RTEMS implementation
+implements the following features:
+
+* `RFC 1350 `_
+  *The TFTP Protocol (Revision 2)*
+* `RFC 2347 `_
+  *TFTP Option Extension*
+* `RFC 2348 `_
+  *TFTP Blocksize Option*
+* `RFC 7440 `_
+  *TFTP Windowsize Option*
+
+Many simple TFTP server do not support options (RFC 2347). Therefore, in
+case the server rejects the first request with options, the RTEMS client
+makes automatically a second attempt using only the "classical" RFC 1350.
+
+The implementation has the following shortcomings:
+
+* IPv6 is not supported (yet).
+
+* No congestion control is implemented.
+
+  (Congestion is simply expressed a network traffic jam which involves
+  package loss.)  This implementation would worsen a congestion situation
+  and squeeze out TCP connections.  If that is a concern in your setup,
+  it can be prevented by using value `1` as `windowsize` when mounting
+  the TFTP file system.
+
+* One must call ``open()``, ``read()``, ``write()`` and ``close()``
+  at a good pace.
+
+  TFTP is designed to read or write a whole already existing file in
+  one sweep.  It uses timeouts (of unspecified length) and it does not
+  know keep-alive messages.  If the client does not respond to the
+  server in due time, the server sets the connection faulty and drops it.
+  To avoid this, the user must read or write enough data fast enough.
+
+  The point here is, one cannot pause the reading or writing for longer
+  periods of time.  TFTP cannot be used for example to write log files
+  where all few seconds a line is written.  Also opening the
+  file at the beginning of an application and closing it that the end
+  will certainly lead to a timeout.  As another example, one cannot
+  read a file by reading one byte per second, this will trigger a
+  timeout and the server closes the connection.  The opening, reading
+  or writing and closing must happen in swift consecutive steps.
+
+* The transfer mode is always ``octet``.  The only alternative
+  ``netascii`` cannot be selected.
+
+* Block number roll-over is currently not supported.  Therefore,
+  the maximum file size is limited to max-block-number times blocksize.
+  For RFC 1350 blocksize is would be 65535 * 512 = 32 MB.  For the
+  default blocksize is would be 65535 * 1456 = 90 MB.
+
+* The inherent insecurity of the protocol has already be mentioned but
+  it is worth 

Re: [PATCH rtems-docs 1/1] TFTPFS: New documentation

[Frank Kühndel]

Hello Chris,
Hello Joel,
Hello Sebastian,

many thanks for your reviews and comments. I will send an updated v2 of
this patch. It will take your comments in account.

On 6/7/22 18:56, Joel Sherrill wrote:
> 
> On Sun, Jun 5, 2022 at 8:56 PM Chris Johns  wrote:
> 
>> Hi Frank,
>>
>> Thanks for the documentation and the TFTP file system update.
>>
>> On 4/6/2022 1:22 am, Frank Kuehndel wrote:
>>> From: Frank Kühndel 
>>>
>>> ---
>>>  filesystem/index.rst   |   1 +
>>>  filesystem/trivial_ftp.rst | 638 -
>>>  2 files changed, 636 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/filesystem/index.rst b/filesystem/index.rst
>>> index f4e2ed6..64a2f1d 100644
>>> --- a/filesystem/index.rst
>>> +++ b/filesystem/index.rst
>>> @@ -9,6 +9,7 @@ RTEMS Filesystem Design Guide (|version|).
>>>  .. topic:: Copyrights and License
>>>
>>>  | |copy| 1988, 2015 On-Line Applications Research Corporation (OAR)
>>> +| |copy| 2022 embedded brains GmbH (http://www.embedded-brains.de)
>>>
>>>  .. include:: ../common/license.rst
>>>
>>> diff --git a/filesystem/trivial_ftp.rst b/filesystem/trivial_ftp.rst
>>> index e43c036..f5940c6 100644
>>> --- a/filesystem/trivial_ftp.rst
>>> +++ b/filesystem/trivial_ftp.rst
>>> @@ -3,7 +3,639 @@
>>>  Trivial FTP Client Filesystem
>>>  *
>>>
>>> -This chapter describes the Trivial FTP (TFTP) Client Filesystem.
>>> +This chapter describes the Trivial File Transfer Protocol (TFTP) Client
>>> +Filesystem.  TFTP is designed to be an especially simple protocol which
>>> +uses the User Datagram Protocol (UDP) for data transfer over the
>> Internet.
>>> +Its purpose is to send a single file between to network nodes (client
>> and
>>> +server).  A file can be sent in both directions, i.e. a client can
>> either
>>> +read a file from a server or write a file to the server.
>>>
>>> -This chapter should be written after the IMFS chapter is completed and
>> describe
>>> -the implementation of the TFTP.
>>> +Besides reading or writing a file no other operations are supported.
>> That
>>> +is, one cannot seek the file, not append to the end of a file, not open
>>> +the file for reading and writing at the same time, not list directories,
>>> +not move files and so on.
>>> +
>>> +TFTP is inherent insecure as it does not provide any means for
>>> +authentication or encryption.  Therefore, it cannot be used over the
>> public
>>> +Internet.
>> Recommended or highly recommended to not be used on public networks?

Ok. I change it to "highly recommended".

>>
>>> Nevertheless, it is still widely used to load software and
>>> +configuration data during early boot stages over a Local Area Network
>>> +(LAN).
>> With regard to security the TFTP port is secure and so the server runs as
>> root.
>> In rtems-tools there is a TFTP proxy to provide a central instance that can
>> proxy sessions out to other machines on a network at any port, ie ones
>> that a
>> user can connect with. This works with the rtems-tftp-server also included
>> in
>> rtems-tools. The rtems-tftp-server (and proxy) and in Python so should be
>> portable.

I did not try this server. It seems not to support the windowsize option
anyway.

>>
>>> +
>>> +RTEMS TFTP Filesystem Implementation
>>> +
>>> +
>>> +The RTEMS TFTP filesystem implements a TFTP client which can be used
>>> +through the file system.  With other words, one needs to mount the
>>> +TFTP filesystem and can afterwards open a file for reading or writing
>>> +below that mount point.  The content of that file is then effectively
>>> +read from or written to the remote server.  The RTEMS implementation
>>> +implements the following features:
>>> +
>>> +* RFC 1350 *The TFTP Protocol (Revision 2)*
>>> +* RFC 2347 *TFTP Option Extension*
>>> +* RFC 2348 *TFTP Blocksize Option*
>>> +* RFC 7440 *TFTP Windowsize Option*
>>
> Would you kindly put the URLs for these in?

OK. I add the URLs as links.
> 
> 
>>> +Many simple TFTP server do not support options (RFC 2347). Therefore, in
>>> +case the server rejects the first request with options, the RTEMS client
>>> +makes automatically a second attempt using only the "classical" RFC
>> 1350.
>>> +
>>> +The implementation has the following shortcomings:
>>> +
>>> +* IPv6 is not supported (yet).
>>> +
>>> +* No congestion control is implemented.
>>> +
>>> +  (Congestion is simply expressed a network traffic jam which involves
>>> +  package loss.)  This implementation would worsen a congestion
>> situation
>>> +  and squeeze out TCP connections.  If that is a concern in your setup,
>>> +  it can be prevented by using value `1` as `windowsize`.
>> Where is this set, the server or the client?

OK. I change the text a bit.

Basically, all options are requested by the client. The server only
confirms those suggested options it supports. Therefore, setting
`windowsize` to 1 is only possible at the client side. Yet, most TFTP
servers do not 

Re: [PATCH] user/bsps/arm: Second Ethernet on i.MX

[Christian MAUDERER]

Hello Chris,

Am 09.06.22 um 09:20 schrieb Chris Johns:

OK push.


Thanks.



(I am not familiar with these devices so ...) Is the needed device tree
fragments easily available to the user?


The device tree for the i.MX6 and i.MX7 series are basically just the 
ones from FreeBSD or Linux. So there are a lot of examples available. 
With the additional hints that I added with this patch, it should be 
possible to create one that is working well for a custom board.


Best regards

Christian



Thanks
Chris

On 9/6/2022 5:03 pm, Christian Mauderer wrote:

This adds information how to use a second Ethernet controller on the
i.MX BSPs.
---
  user/bsps/arm/imx.rst | 17 +
  1 file changed, 17 insertions(+)

diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
index ee98f0b..e2fd7f2 100644
--- a/user/bsps/arm/imx.rst
+++ b/user/bsps/arm/imx.rst
@@ -174,6 +174,23 @@ config like that:
  SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
  #include 
  
+On chips with two Ethernet controllers, the MDIO lines are shared between the

+two controllers for a number of chips variants. This is currently supported 
with
+some restrictions on the initialization order. For this configuration to work,
+you have to make sure that the pins are assigned to the Ethernet controller 
that
+is initialized first. The initialization order in `libbsd` depends on the order
+of the Ethernet controllers in the device tree. So if (for example) `fec2` is
+defined in the device tree sources before `fec1`, make sure that the MDIO lines
+are routed to `fec2` and that the Ethernet PHYs are a sub-node of `fec2` in the
+device tree.
+
+Note that the clock for the second Ethernet controller is not necessarily
+enabled in the `CCM`. On the i.MX6UL/ULL, the clock will be enabled by the
+startup code if the node that is compatible with `fsl,imx6ul-anatop` can be
+found in the device tree. If you have trouble with the second Ethernet
+controller make sure that the `ENET2_125M_EN` bit in the `CCM_ANALOG_PLL_ENET`
+register is set as expected.
+
  MMC/SDCard Driver
  -
  


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
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: [PATCH] user/bsps/arm: Second Ethernet on i.MX

[Chris Johns]

OK push.

(I am not familiar with these devices so ...) Is the needed device tree
fragments easily available to the user?

Thanks
Chris

On 9/6/2022 5:03 pm, Christian Mauderer wrote:
> This adds information how to use a second Ethernet controller on the
> i.MX BSPs.
> ---
>  user/bsps/arm/imx.rst | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
> index ee98f0b..e2fd7f2 100644
> --- a/user/bsps/arm/imx.rst
> +++ b/user/bsps/arm/imx.rst
> @@ -174,6 +174,23 @@ config like that:
>  SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
>  #include 
>  
> +On chips with two Ethernet controllers, the MDIO lines are shared between the
> +two controllers for a number of chips variants. This is currently supported 
> with
> +some restrictions on the initialization order. For this configuration to 
> work,
> +you have to make sure that the pins are assigned to the Ethernet controller 
> that
> +is initialized first. The initialization order in `libbsd` depends on the 
> order
> +of the Ethernet controllers in the device tree. So if (for example) `fec2` is
> +defined in the device tree sources before `fec1`, make sure that the MDIO 
> lines
> +are routed to `fec2` and that the Ethernet PHYs are a sub-node of `fec2` in 
> the
> +device tree.
> +
> +Note that the clock for the second Ethernet controller is not necessarily
> +enabled in the `CCM`. On the i.MX6UL/ULL, the clock will be enabled by the
> +startup code if the node that is compatible with `fsl,imx6ul-anatop` can be
> +found in the device tree. If you have trouble with the second Ethernet
> +controller make sure that the `ENET2_125M_EN` bit in the 
> `CCM_ANALOG_PLL_ENET`
> +register is set as expected.
> +
>  MMC/SDCard Driver
>  -
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [gcc] Enable TLS support for RTEMS in libstdc++

[Chris Johns]

On 9/6/2022 4:16 pm, Sebastian Huber wrote:
> On 08/06/2022 16:18, Sebastian Huber wrote:
>> On 08/06/2022 16:11, Joel Sherrill wrote:
>>> On Wed, Jun 8, 2022 at 8:47 AM Sebastian Huber
>>> >> > wrote:
>>>
>>>     On 08/06/2022 15:39, Joel Sherrill wrote:
>>>  > Is TLS actually supported on all targets except MIPS?
>>>
>>>     I only added MIPS since this target has a fundamental issue with the
>>>     TLS
>>>     support.
>>>
>>>     Which target would you also exclude?
>>>
>>> About half of them.
>>
>> It seems to be only bfin, lm32, moxie, or1k, and v850. Are these targets 
>> still
>> in use? Do we have a maintainer for these targets?
> 
> How do we want to proceed here? Add them to the exclude list in the GCC
> configuration, or encourage current or future users of these targets to add 
> the
> TLS support so that they can use state of the art C++ support? The initial TLS
> support for RTEMS was added in 2013, so this is not really brand new 
> technology.

I think we should support TLS in C++ for the targets we know work and any others
can use the eh_globals support. It does work and works OK with POSIX keys.

How we document this is probability a more pressing question? I cannot see any
language specific areas in the User or Classic API manuals.

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

Re: [PATCH rtems v2] bsps/imx: Enable clock of ETH2

[Christian MAUDERER]

Thanks for the review and the OK to push.

I created a patch for rtems-docs that gives some information about that 
(and about how to use the second Ethernet controller) and sent it to the 
list.


Am 08.06.22 um 02:49 schrieb Chris Johns:

Does the BSP doco in the User Manual need updating to mention the clock setting
and the required FDT?

This code fails silently and so documentation is fine or I think the user should
be alerted some other way.

Otherwise OK to push :)

Thanks
Chris

On 7/6/2022 11:05 pm, Christian Mauderer wrote:

---
  .../include/arm/freescale/imx/imx6ul_ccmreg.h | 152 ++
  bsps/arm/imx/start/bspstart.c |  20 +++
  spec/build/bsps/arm/imx/bspimx.yml|   1 +
  3 files changed, 173 insertions(+)
  create mode 100644 bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h

diff --git a/bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h 
b/bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
new file mode 100644
index 00..e4b597ba32
--- /dev/null
+++ b/bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
@@ -0,0 +1,152 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2022 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef IMX6UL_CCMREG_H
+#define IMX6UL_CCMREG_H
+
+#include 
+
+typedef struct {
+   uint32_t ccr;
+   uint32_t ccdr;
+   uint32_t csr;
+   uint32_t ccsr;
+   uint32_t cacrr;
+   uint32_t cbcdr;
+   uint32_t cbcmr;
+   uint32_t cscmr1;
+   uint32_t cscmr2;
+   uint32_t cscdr1;
+   uint32_t cs1cdr;
+   uint32_t cs2cdr;
+   uint32_t cdcdr;
+   uint32_t chsccdr;
+   uint32_t cscdr2;
+   uint32_t cscdr3;
+   uint32_t reserved_40[2];
+   uint32_t cdhipr;
+   uint32_t reserved_4c[2];
+   uint32_t clpcr;
+   uint32_t cisr;
+   uint32_t cimr;
+   uint32_t ccosr;
+   uint32_t cgpr;
+   uint32_t ccgr0;
+   uint32_t ccgr1;
+   uint32_t ccgr2;
+   uint32_t ccgr3;
+   uint32_t ccgr4;
+   uint32_t ccgr5;
+   uint32_t ccgr6;
+   uint32_t reserved_84[1];
+   uint32_t cmeor;
+} imx6ul_ccm;
+
+typedef struct {
+   uint32_t pll_arm;
+   uint32_t pll_arm_set;
+   uint32_t pll_arm_clr;
+   uint32_t pll_arm_tog;
+   uint32_t pll_usb1;
+   uint32_t pll_usb1_set;
+   uint32_t pll_usb1_clr;
+   uint32_t pll_usb1_tog;
+   uint32_t pll_usb2;
+   uint32_t pll_usb2_set;
+   uint32_t pll_usb2_clr;
+   uint32_t pll_usb2_tog;
+   uint32_t pll_sys;
+   uint32_t pll_sys_set;
+   uint32_t pll_sys_clr;
+   uint32_t pll_sys_tog;
+   uint32_t pll_sys_ss;
+   uint32_t reserved_44[3];
+   uint32_t pll_sys_num;
+   uint32_t reserved_54[3];
+   uint32_t pll_sys_denom;
+   uint32_t reserved_64[3];
+   uint32_t pll_audio;
+   uint32_t pll_audio_set;
+   uint32_t pll_audio_clr;
+   uint32_t pll_audio_tog;
+   uint32_t pll_audio_num;
+   uint32_t reserved_84[3];
+   uint32_t pll_audio_denom;
+   uint32_t reserved_94[3];
+   uint32_t pll_video;
+   uint32_t pll_video_set;
+   uint32_t pll_video_clr;
+   uint32_t pll_video_tog;
+   uint32_t pll_video_num;
+   uint32_t reserved_b4[3];
+   uint32_t pll_video_denom;
+   uint32_t reserved_c4[7];
+   uint32_t pll_enet;
+#define IMX6UL_CCM_ANALOG_PLL_ENET_LOCK BSP_BIT32(31)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENET_25M_REF_EN BSP_BIT32(21)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENET2_125M_EN BSP_BIT32(20)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENABLE_125M BSP_BIT32(19)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_PFD_OFFSET_EN BSP_BIT32(18)

[PATCH] user/bsps/arm: Second Ethernet on i.MX

[Christian Mauderer]

This adds information how to use a second Ethernet controller on the
i.MX BSPs.
---
 user/bsps/arm/imx.rst | 17 +
 1 file changed, 17 insertions(+)

diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
index ee98f0b..e2fd7f2 100644
--- a/user/bsps/arm/imx.rst
+++ b/user/bsps/arm/imx.rst
@@ -174,6 +174,23 @@ config like that:
 SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
 #include 
 
+On chips with two Ethernet controllers, the MDIO lines are shared between the
+two controllers for a number of chips variants. This is currently supported 
with
+some restrictions on the initialization order. For this configuration to work,
+you have to make sure that the pins are assigned to the Ethernet controller 
that
+is initialized first. The initialization order in `libbsd` depends on the order
+of the Ethernet controllers in the device tree. So if (for example) `fec2` is
+defined in the device tree sources before `fec1`, make sure that the MDIO lines
+are routed to `fec2` and that the Ethernet PHYs are a sub-node of `fec2` in the
+device tree.
+
+Note that the clock for the second Ethernet controller is not necessarily
+enabled in the `CCM`. On the i.MX6UL/ULL, the clock will be enabled by the
+startup code if the node that is compatible with `fsl,imx6ul-anatop` can be
+found in the device tree. If you have trouble with the second Ethernet
+controller make sure that the `ENET2_125M_EN` bit in the `CCM_ANALOG_PLL_ENET`
+register is set as expected.
+
 MMC/SDCard Driver
 -
 
-- 
2.35.3

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

Re: [gcc] Enable TLS support for RTEMS in libstdc++

[Sebastian Huber]

On 08/06/2022 16:18, Sebastian Huber wrote:



On 08/06/2022 16:11, Joel Sherrill wrote:
On Wed, Jun 8, 2022 at 8:47 AM Sebastian Huber 
> wrote:


    On 08/06/2022 15:39, Joel Sherrill wrote:
 > Is TLS actually supported on all targets except MIPS?

    I only added MIPS since this target has a fundamental issue with the
    TLS
    support.

    Which target would you also exclude?


About half of them.


It seems to be only bfin, lm32, moxie, or1k, and v850. Are these targets 
still in use? Do we have a maintainer for these targets?


How do we want to proceed here? Add them to the exclude list in the GCC 
configuration, or encourage current or future users of these targets to 
add the TLS support so that they can use state of the art C++ support? 
The initial TLS support for RTEMS was added in 2013, so this is not 
really brand new technology.


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

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

Re: [PATCH 3/5] cpukit/libmd/md5.c: fix warning

[Sebastian Huber]

On 08/06/2022 18:09, Joel Sherrill wrote:


On Wed, Jun 8, 2022, 10:45 AM Gedare Bloom > wrote:


Does this code have an upstream?


I tried to find it. Maybe whoever added it has memory of the source.

As best I can tell, it is lightly or not maintained reference code.


Maybe we should replace the libmd stuff with the latest code from 
OpenBSD or FreeBSD.


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

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

Re: [PATCH 5/5] testsuites/libtests/malloctest: fix warning

[Sebastian Huber]

On 08/06/2022 15:34, Matthew Joyce wrote:

@@ -118,13 +116,6 @@ static void test_realloc(void)
malloc_walk_ok = malloc_walk( 1234, false );
rtems_test_assert( malloc_walk_ok );
_Thread_Dispatch_enable( _Per_CPU_Get() );
-
-  /*
-   *  Realloc with a bad pointer to force a point
-   */
-  p4 = realloc( test_realloc, 32 );
-
-  p4 = _realloc_r( NULL, NULL, 1 );
  }
  
  #define TEST_HEAP_SIZE 2048

@@ -1526,8 +1517,6 @@ static void test_early_malloc( void )
rtems_test_assert( p != q );
rtems_test_assert( q[0] == 0 );
  
-  free( q );

-
r = realloc( q, 128 );
rtems_test_assert( r == q );


Some tests do things you should normally not do. So, sometimes a warning 
is hard to avoid. We should definitely not remove valid tests cases to 
fix warnings.


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

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

Re: [PATCH] validation: Fix CallWithinISR()

[Sebastian Huber]

On 08/06/2022 22:11, Gedare Bloom wrote:

On Wed, Jun 8, 2022 at 1:04 PM Sebastian Huber
  wrote:

On 08/06/2022 17:40, Gedare Bloom wrote:

Hm. This looks ok, but it also seems to be a bit of an awkward
requirement. Is this only relevant for the tm27 test?

I hijacked the tm27 support to add an API for software interrupts.


Do we need something more formal?


The tm27 support works quite well for this purpose. There are probably 
more rewarding areas for RTEMS improvements elsewhere.


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