[PATCH] build: Assert value properties only if not None

[Sebastian Huber]

---
 wscript | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/wscript b/wscript
index 77269f126c..d4defd4f13 100755
--- a/wscript
+++ b/wscript
@@ -738,7 +738,7 @@ class OptionItem(Item):
 return value
 
 def _assert_aligned(self, conf, cic, value, arg):
-if value % arg != 0:
+if value is not None and value % arg != 0:
 conf.fatal(
 "Value '{}' for option '{}' is not aligned by '{}'".format(
 value, self.data["name"], arg
@@ -747,7 +747,7 @@ class OptionItem(Item):
 return value
 
 def _assert_eq(self, conf, cic, value, arg):
-if value != arg:
+if value is not None and value != arg:
 conf.fatal(
 "Value '{}' for option '{}' is not equal to {}".format(
 value, self.data["name"], arg
@@ -756,7 +756,7 @@ class OptionItem(Item):
 return value
 
 def _assert_ge(self, conf, cic, value, arg):
-if value < arg:
+if value is not None and value < arg:
 conf.fatal(
 "Value '{}' for option '{}' is not greater than or equal to 
{}".format(
 value, self.data["name"], arg
@@ -765,7 +765,7 @@ class OptionItem(Item):
 return value
 
 def _assert_gt(self, conf, cic, value, arg):
-if value <= arg:
+if value is not None and value <= arg:
 conf.fatal(
 "Value '{}' for option '{}' is not greater than {}".format(
 value, self.data["name"], arg
@@ -774,7 +774,7 @@ class OptionItem(Item):
 return value
 
 def _assert_in_interval(self, conf, cic, value, arg):
-if value < arg[0] or value > arg[1]:
+if value is not None and (value < arg[0] or value > arg[1]):
 conf.fatal(
 "Value '{}' for option '{}' is not in closed interval [{}, 
{}]".format(
 value, self.data["name"], arg[0], arg[1]
@@ -799,7 +799,7 @@ class OptionItem(Item):
 )
 
 def _assert_le(self, conf, cic, value, arg):
-if value > arg:
+if value is not None and value > arg:
 conf.fatal(
 "Value '{}' for option '{}' is not less than or equal to 
{}".format(
 value, self.data["name"], arg
@@ -808,7 +808,7 @@ class OptionItem(Item):
 return value
 
 def _assert_lt(self, conf, cic, value, arg):
-if value >= arg:
+if value is not None and value >= arg:
 conf.fatal(
 "Value '{}' for option '{}' is not less than {}".format(
 value, self.data["name"], arg
@@ -817,7 +817,7 @@ class OptionItem(Item):
 return value
 
 def _assert_ne(self, conf, cic, value, arg):
-if value == arg:
+if value is not None and value == arg:
 conf.fatal(
 "Value '{}' for option '{}' is not unequal to {}".format(
 value, self.data["name"], arg
@@ -826,7 +826,7 @@ class OptionItem(Item):
 return value
 
 def _assert_power_of_two(self, conf, cic, value, arg):
-if value <= 0 or (value & (value - 1)) != 0:
+if value is not None and (value <= 0 or (value & (value - 1)) != 0):
 conf.fatal(
 "Value '{}' for option '{}' is not a power of two".format(
 value, self.data["name"]
-- 
2.35.3

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

Re: [PATCH rtems-lwip] lwip: Split sources into origin directories

[Vijay Kumar Banerjee]

Hi Pavel,

On Thu, Jun 2, 2022 at 12:09 AM Pavel Pisa  wrote:
>
> Dear Vijay,
>
> On Thursday 02 of June 2022 05:56:56 Vijay Kumar Banerjee wrote:
> > I have pushed this patch and I would like to add a note regarding that.
>
> thanks for the work and time.
>
No problem. I hope we can soon promote the rtems-lwip repository to
the top-level.

> > This patch started interesting discussions about the possible ways to
> > organize code from multiple sources. Pavel also raised an issue with
> > the directory name "uLan". Since the repository is still in a personal
> > area and still in the development stage, we can make rapid changes to
> > the repository. We will change the directory name from uLan to
> > something that's more suitable,
>
> please no uLAN it is RS-485 protocol. Yes it has and reuses our sysless
> firware base project and uses OOMK build system which we use
> for build of GNU/Linux, sysless, RTEMS, NuttX and even Windows
> applications. Because I used our port of LwIP which uses OMK
> build to test it in RTEMS I have named it lwip-omk and because
> we use the code in our instruments firmware which use OMK build,
> sysless and often uLAN protocol it ended in the repo under
> uLAN project.
>
> https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/
>
> But using this project name in the case where
> OMK buid system is unwanted, there is nor RS-485 connection
> and no use of other libraries and bare metal support from
> that PiKRON project is so misleading, that I have to insist
> to not use uLAN label...
>
> I suggest to have only ports directory at the rtems-lwip
> toplevel. We should go through the process to relicense
> all (where we are authors or where we can contact author)
> to RTEMS mainline acceptable licence. If there is some problematic
> driver then it stays in
>
>   ports/driver/driver_name
>
> directory so it will be separated and license precisely defined
> in that directory.
>
This is a good idea, and I totally agree with this approach. The
directories can be named with the target name, and the information of
the source can be included in a file there.

> I still see in the driers base only our own tms570_emac.
> So what is the plan for integrating others?
>
I realized that a few patches are in my local machine that never made
it to the repository. Kinsey is working on another port. We will have
at least two more ports soon.

> It would be great to have there at least two working
> ports because then it will be seen how to select them
> on the build system level.
>
> Thanks for updating project documentation
>
> https://devel.rtems.org/wiki/Packages/LWIP
>
> There is another task to solve. In the OMK build,
> there has been made possible to configure the most
> of the LwIP options from the project top level
> config.omk and config.target. It should be considered,
> how buffers size, count and many other featires will
> be configured in actual RSB build. Problem is that
> LwIP on targets with little memory (it worked on
> 256 kB TMS570LS3137) and on the other hand configuration
> for some bigger systems as is  Gaisler GR740 or somethink
> NOEL-V based can be significantly different when
> megabytes of RAM can be used.
>

The waf scripts can be extended in the way similar to top level
rtems-littlevgl that provides a default header file with config info,
which get rewritten by the script based on manual configurations.
https://git.rtems.org/packages/rtems-littlevgl/


> By the way, I am presenting at
>
> 9th International Workshop on Analogue and Mixed-Signal
> Integrated Circuits for Space Applications
> https://indico.esa.int/event/388/
>
Nice!

> and I have met there people from TTTech
> and they can have interrest to try RTEMS
> even on their TTEthernet space ASIC
> internal Leon 2 core. But it is memory
> constrained environment so for TCP/IP non-real time
> traffic they most probably cannot use BSD stack,
> so LwIP + RTEMS can be the option there.
>

This can be a nice project.

> But it is necessary to put project into some
> reusable shape. Unfortunately I do not have
> time to work on it some intensive way now
> and I do not know RSB stuff enough.
>

Handling the config will be the challenge, but a plain vanilla
rtems-lwip can be built using similar RSB script used for libbsd.


> On the other hand, if they express real interest,
> I can try, if I am able attract some students
> from our universitywho can work on the project.
> I invest a lot to pass knowledge for their serious
> work in this area.
>
> By the way, we have switched our Computer Architectures
> course to RISC-V in this run
>
>   https://cw.fel.cvut.cz/wiki/courses/b35apo/en/start
>
> including simulator
>
>   https://github.com/cvut/qtrvsim
>
> and public recording (even English, sorry Czenglish)
>
>   https://www.youtube.com/playlist?list=PLQL6z4JeTTQnTrML7HgagbjdpCtvdyu0M

Thanks for making the lecture pdfs public and uploading the videos on youtube!


Best regards,
Vijay
>
> Best wishes,
>
>  

Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

[Gedare Bloom]

On Thu, Jun 2, 2022 at 10:08 AM Joel Sherrill  wrote:
>
>
>
> On Thu, Jun 2, 2022, 9:58 AM Christian MAUDERER 
>  wrote:
>>
>> Am 02.06.22 um 16:19 schrieb Joel Sherrill:
>> >
>> >
>> > On Thu, Jun 2, 2022 at 8:58 AM Christian MAUDERER
>> > > > > wrote:
>> >
>> > Am 02.06.22 um 15:49 schrieb Gedare Bloom:
>> >  > On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber
>> >  > > > > wrote:
>> >  >>
>> >  >> On 02/06/2022 09:27, Christian MAUDERER wrote:
>> >  >>>
>> >  >>> Am 01.06.22 um 14:46 schrieb Gedare Bloom:
>> >   On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
>> >   > > > wrote:
>> >  >
>> >  > Typical embedded systems don't have that much memory. Reduce
>> > the buffer
>> >  > size to something more sensible for the usual type of
>> > application.
>> >  > ---
>> >  >freebsd/sys/dev/ffec/if_ffec.c | 8 
>> >  >1 file changed, 8 insertions(+)
>> >  >
>> >  > diff --git a/freebsd/sys/dev/ffec/if_ffec.c
>> >  > b/freebsd/sys/dev/ffec/if_ffec.c
>> >  > index 47c0f770..4c1e147b 100644
>> >  > --- a/freebsd/sys/dev/ffec/if_ffec.c
>> >  > +++ b/freebsd/sys/dev/ffec/if_ffec.c
>> >  > @@ -139,9 +139,17 @@ static struct ofw_compat_data
>> > compat_data[] = {
>> >  >/*
>> >  > * Driver data and defines.  The descriptor counts must be
>> > a power
>> >  > of two.
>> >  > */
>> >  > +#ifndef __rtems__
>> >  >#defineRX_DESC_COUNT   512
>> >  > +#else /* __rtems__ */
>> >  > +#defineRX_DESC_COUNT   64
>> >  > +#endif /* __rtems__ */
>> >  
>> >   Do we need some way to control this parameter? Or, how will this
>> >   appear if it breaks something?
>> >  >>>
>> >  >>> I don't expect that there will be any problems. But I can take
>> > a look
>> >  >>> how I can make that a parameter.
>> >  >>
>> >  >> Can we please keep this a compile time constant as it is.  The 64
>> >  >> descriptors should be more than enough.
>> >  >>
>> >  > I don't mind the reduction of the constant, but it would be good to
>> >  > predict what behavior might indicate this was exceeded. I guess it
>> >  > should be some kind of errno on an allocation request though? So it
>> >  > should be fine, but if a user hits this limit, I guess they have
>> >  > pretty limited options to overcome it.
>> >
>> > Reducing the limit won't cause errors. It will only means that if you
>> > flood the target with network packets, it will cache less packets and
>> > start dropping them earlier. That means:
>> >
>> > On a short packet burst, some packets will be dropped and (for TCP)
>> > some
>> > have to be re-transmitted. So for short bursts it can be a slight
>> > disadvantage.
>> >
>> > On a constant overload situation: It doesn't really make a difference
>> > because the target wouldn't be able to process the packages anyway. It
>> > might even is an advantage because the processor doesn't have to
>> > process
>> > packets that are already outdated and maybe re-transmitted.
>> >
>> >
>> > How much RAM does this save versus having control over the size of
>> > UDP and TCP RX/TX buffers like we had in the legacy stack? I recall
>> > being able to control the various buffer sizes saved a LOT of memory
>> > on applications I used these parameters on.
>> >
>> > There we had four configuration values. Any chance this has a hint
>> > in FreeBSD now or we can provide the same tuning?
>> >
>> >  rtems_set_udp_buffer_sizes(
>> >rtems_bsdnet_config.udp_tx_buf_size,
>> >rtems_bsdnet_config.udp_rx_buf_size
>> >  );
>> >
>> >  rtems_set_tcp_buffer_sizes(
>> >rtems_bsdnet_config.tcp_tx_buf_size,
>> >rtems_bsdnet_config.tcp_rx_buf_size
>> >  );
>> >
>>
>> Are you sure that this is the same buffer? The parameter in this patch
>> is a driver specific ring buffer of rx descriptors. The parameter that
>> you mention sounds more like a general network stack buffer (although I
>> have to say that I don't know these functions of the old stack).
>
>
> I know it isn't the same buffers. It is just likely this has an impact also 
> on fitting into a lower ram environment. And would be general not specific to 
> a driver.
>
>>
>> Regarding the sizes:
>>
>> The driver allocates one mbuf for each buffer. It's a bit tricky to tell
>> exactly how big one MBUF is. FreeBSD does a lot of abstraction there.
>> But a debugger tells me that after the initialization one buffer is:
>>
>>sc->rxbuf_map[0].mbuf->m_len = 2048
>>
>> That means that I reduced the buffers that are 

Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

[Joel Sherrill]

On Thu, Jun 2, 2022, 9:58 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Am 02.06.22 um 16:19 schrieb Joel Sherrill:
> >
> >
> > On Thu, Jun 2, 2022 at 8:58 AM Christian MAUDERER
> >  > > wrote:
> >
> > Am 02.06.22 um 15:49 schrieb Gedare Bloom:
> >  > On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber
> >  >  > > wrote:
> >  >>
> >  >> On 02/06/2022 09:27, Christian MAUDERER wrote:
> >  >>>
> >  >>> Am 01.06.22 um 14:46 schrieb Gedare Bloom:
> >   On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
> >    > > wrote:
> >  >
> >  > Typical embedded systems don't have that much memory. Reduce
> > the buffer
> >  > size to something more sensible for the usual type of
> > application.
> >  > ---
> >  >freebsd/sys/dev/ffec/if_ffec.c | 8 
> >  >1 file changed, 8 insertions(+)
> >  >
> >  > diff --git a/freebsd/sys/dev/ffec/if_ffec.c
> >  > b/freebsd/sys/dev/ffec/if_ffec.c
> >  > index 47c0f770..4c1e147b 100644
> >  > --- a/freebsd/sys/dev/ffec/if_ffec.c
> >  > +++ b/freebsd/sys/dev/ffec/if_ffec.c
> >  > @@ -139,9 +139,17 @@ static struct ofw_compat_data
> > compat_data[] = {
> >  >/*
> >  > * Driver data and defines.  The descriptor counts must be
> > a power
> >  > of two.
> >  > */
> >  > +#ifndef __rtems__
> >  >#defineRX_DESC_COUNT   512
> >  > +#else /* __rtems__ */
> >  > +#defineRX_DESC_COUNT   64
> >  > +#endif /* __rtems__ */
> >  
> >   Do we need some way to control this parameter? Or, how will
> this
> >   appear if it breaks something?
> >  >>>
> >  >>> I don't expect that there will be any problems. But I can take
> > a look
> >  >>> how I can make that a parameter.
> >  >>
> >  >> Can we please keep this a compile time constant as it is.  The 64
> >  >> descriptors should be more than enough.
> >  >>
> >  > I don't mind the reduction of the constant, but it would be good
> to
> >  > predict what behavior might indicate this was exceeded. I guess it
> >  > should be some kind of errno on an allocation request though? So
> it
> >  > should be fine, but if a user hits this limit, I guess they have
> >  > pretty limited options to overcome it.
> >
> > Reducing the limit won't cause errors. It will only means that if you
> > flood the target with network packets, it will cache less packets and
> > start dropping them earlier. That means:
> >
> > On a short packet burst, some packets will be dropped and (for TCP)
> > some
> > have to be re-transmitted. So for short bursts it can be a slight
> > disadvantage.
> >
> > On a constant overload situation: It doesn't really make a difference
> > because the target wouldn't be able to process the packages anyway.
> It
> > might even is an advantage because the processor doesn't have to
> > process
> > packets that are already outdated and maybe re-transmitted.
> >
> >
> > How much RAM does this save versus having control over the size of
> > UDP and TCP RX/TX buffers like we had in the legacy stack? I recall
> > being able to control the various buffer sizes saved a LOT of memory
> > on applications I used these parameters on.
> >
> > There we had four configuration values. Any chance this has a hint
> > in FreeBSD now or we can provide the same tuning?
> >
> >  rtems_set_udp_buffer_sizes(
> >rtems_bsdnet_config.udp_tx_buf_size,
> >rtems_bsdnet_config.udp_rx_buf_size
> >  );
> >
> >  rtems_set_tcp_buffer_sizes(
> >rtems_bsdnet_config.tcp_tx_buf_size,
> >rtems_bsdnet_config.tcp_rx_buf_size
> >  );
> >
>
> Are you sure that this is the same buffer? The parameter in this patch
> is a driver specific ring buffer of rx descriptors. The parameter that
> you mention sounds more like a general network stack buffer (although I
> have to say that I don't know these functions of the old stack).
>

I know it isn't the same buffers. It is just likely this has an impact also
on fitting into a lower ram environment. And would be general not specific
to a driver.


> Regarding the sizes:
>
> The driver allocates one mbuf for each buffer. It's a bit tricky to tell
> exactly how big one MBUF is. FreeBSD does a lot of abstraction there.
> But a debugger tells me that after the initialization one buffer is:
>
>sc->rxbuf_map[0].mbuf->m_len = 2048
>
> That means that I reduced the buffers that are cached in the driver for
> sending data from 512 * 2kiB = 1MiB to 64 * 2kiB = 128kiB for the
> receive direction. Note that our default size 

Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

[Christian MAUDERER]

Am 02.06.22 um 16:19 schrieb Joel Sherrill:



On Thu, Jun 2, 2022 at 8:58 AM Christian MAUDERER 
> wrote:


Am 02.06.22 um 15:49 schrieb Gedare Bloom:
 > On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>> wrote:
 >>
 >> On 02/06/2022 09:27, Christian MAUDERER wrote:
 >>>
 >>> Am 01.06.22 um 14:46 schrieb Gedare Bloom:
  On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
  mailto:christian.maude...@embedded-brains.de>> wrote:
 >
 > Typical embedded systems don't have that much memory. Reduce
the buffer
 > size to something more sensible for the usual type of
application.
 > ---
 >    freebsd/sys/dev/ffec/if_ffec.c | 8 
 >    1 file changed, 8 insertions(+)
 >
 > diff --git a/freebsd/sys/dev/ffec/if_ffec.c
 > b/freebsd/sys/dev/ffec/if_ffec.c
 > index 47c0f770..4c1e147b 100644
 > --- a/freebsd/sys/dev/ffec/if_ffec.c
 > +++ b/freebsd/sys/dev/ffec/if_ffec.c
 > @@ -139,9 +139,17 @@ static struct ofw_compat_data
compat_data[] = {
 >    /*
 >     * Driver data and defines.  The descriptor counts must be
a power
 > of two.
 >     */
 > +#ifndef __rtems__
 >    #define        RX_DESC_COUNT   512
 > +#else /* __rtems__ */
 > +#define        RX_DESC_COUNT   64
 > +#endif /* __rtems__ */
 
  Do we need some way to control this parameter? Or, how will this
  appear if it breaks something?
 >>>
 >>> I don't expect that there will be any problems. But I can take
a look
 >>> how I can make that a parameter.
 >>
 >> Can we please keep this a compile time constant as it is.  The 64
 >> descriptors should be more than enough.
 >>
 > I don't mind the reduction of the constant, but it would be good to
 > predict what behavior might indicate this was exceeded. I guess it
 > should be some kind of errno on an allocation request though? So it
 > should be fine, but if a user hits this limit, I guess they have
 > pretty limited options to overcome it.

Reducing the limit won't cause errors. It will only means that if you
flood the target with network packets, it will cache less packets and
start dropping them earlier. That means:

On a short packet burst, some packets will be dropped and (for TCP)
some
have to be re-transmitted. So for short bursts it can be a slight
disadvantage.

On a constant overload situation: It doesn't really make a difference
because the target wouldn't be able to process the packages anyway. It
might even is an advantage because the processor doesn't have to
process
packets that are already outdated and maybe re-transmitted.


How much RAM does this save versus having control over the size of
UDP and TCP RX/TX buffers like we had in the legacy stack? I recall
being able to control the various buffer sizes saved a LOT of memory
on applications I used these parameters on.

There we had four configuration values. Any chance this has a hint
in FreeBSD now or we can provide the same tuning?

         rtems_set_udp_buffer_sizes(
           rtems_bsdnet_config.udp_tx_buf_size,
           rtems_bsdnet_config.udp_rx_buf_size
         );

         rtems_set_tcp_buffer_sizes(
           rtems_bsdnet_config.tcp_tx_buf_size,
           rtems_bsdnet_config.tcp_rx_buf_size
         );



Are you sure that this is the same buffer? The parameter in this patch 
is a driver specific ring buffer of rx descriptors. The parameter that 
you mention sounds more like a general network stack buffer (although I 
have to say that I don't know these functions of the old stack).


Regarding the sizes:

The driver allocates one mbuf for each buffer. It's a bit tricky to tell 
exactly how big one MBUF is. FreeBSD does a lot of abstraction there. 
But a debugger tells me that after the initialization one buffer is:


  sc->rxbuf_map[0].mbuf->m_len = 2048

That means that I reduced the buffers that are cached in the driver for 
sending data from 512 * 2kiB = 1MiB to 64 * 2kiB = 128kiB for the 
receive direction. Note that our default size for all mbufs in the stack 
is 8MiB (RTEMS_BSD_ALLOCATOR_DOMAIN_PAGE_MBUF_DEFAULT). So 1MiB is a 
relevant part of that. And that's only for one direction!


The Tx buffers only have some management information allocated. They 
will get buffers as soon as there is something to send. But if the 
device can't send fast enough to get rid of the data, it will be most 
likely a similar amount of memory.


Again: That's only the buffers in the driver. Not any buffers on higher 
layers.


Best regards

Christian


--joel


Best regards

Christian



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 

Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

[Joel Sherrill]

On Thu, Jun 2, 2022 at 8:58 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Am 02.06.22 um 15:49 schrieb Gedare Bloom:
> > On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber
> >  wrote:
> >>
> >> On 02/06/2022 09:27, Christian MAUDERER wrote:
> >>>
> >>> Am 01.06.22 um 14:46 schrieb Gedare Bloom:
>  On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
>   wrote:
> >
> > Typical embedded systems don't have that much memory. Reduce the
> buffer
> > size to something more sensible for the usual type of application.
> > ---
> >freebsd/sys/dev/ffec/if_ffec.c | 8 
> >1 file changed, 8 insertions(+)
> >
> > diff --git a/freebsd/sys/dev/ffec/if_ffec.c
> > b/freebsd/sys/dev/ffec/if_ffec.c
> > index 47c0f770..4c1e147b 100644
> > --- a/freebsd/sys/dev/ffec/if_ffec.c
> > +++ b/freebsd/sys/dev/ffec/if_ffec.c
> > @@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
> >/*
> > * Driver data and defines.  The descriptor counts must be a power
> > of two.
> > */
> > +#ifndef __rtems__
> >#defineRX_DESC_COUNT   512
> > +#else /* __rtems__ */
> > +#defineRX_DESC_COUNT   64
> > +#endif /* __rtems__ */
> 
>  Do we need some way to control this parameter? Or, how will this
>  appear if it breaks something?
> >>>
> >>> I don't expect that there will be any problems. But I can take a look
> >>> how I can make that a parameter.
> >>
> >> Can we please keep this a compile time constant as it is.  The 64
> >> descriptors should be more than enough.
> >>
> > I don't mind the reduction of the constant, but it would be good to
> > predict what behavior might indicate this was exceeded. I guess it
> > should be some kind of errno on an allocation request though? So it
> > should be fine, but if a user hits this limit, I guess they have
> > pretty limited options to overcome it.
>
> Reducing the limit won't cause errors. It will only means that if you
> flood the target with network packets, it will cache less packets and
> start dropping them earlier. That means:
>
> On a short packet burst, some packets will be dropped and (for TCP) some
> have to be re-transmitted. So for short bursts it can be a slight
> disadvantage.
>
> On a constant overload situation: It doesn't really make a difference
> because the target wouldn't be able to process the packages anyway. It
> might even is an advantage because the processor doesn't have to process
> packets that are already outdated and maybe re-transmitted.
>

How much RAM does this save versus having control over the size of
UDP and TCP RX/TX buffers like we had in the legacy stack? I recall
being able to control the various buffer sizes saved a LOT of memory
on applications I used these parameters on.

There we had four configuration values. Any chance this has a hint
in FreeBSD now or we can provide the same tuning?

rtems_set_udp_buffer_sizes(
  rtems_bsdnet_config.udp_tx_buf_size,
  rtems_bsdnet_config.udp_rx_buf_size
);

rtems_set_tcp_buffer_sizes(
  rtems_bsdnet_config.tcp_tx_buf_size,
  rtems_bsdnet_config.tcp_rx_buf_size
);

--joel


>
> Best regards
>
> Christian
> --
> 
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

[Christian MAUDERER]

Am 02.06.22 um 15:49 schrieb Gedare Bloom:

On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber
 wrote:


On 02/06/2022 09:27, Christian MAUDERER wrote:


Am 01.06.22 um 14:46 schrieb Gedare Bloom:

On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
 wrote:


Typical embedded systems don't have that much memory. Reduce the buffer
size to something more sensible for the usual type of application.
---
   freebsd/sys/dev/ffec/if_ffec.c | 8 
   1 file changed, 8 insertions(+)

diff --git a/freebsd/sys/dev/ffec/if_ffec.c
b/freebsd/sys/dev/ffec/if_ffec.c
index 47c0f770..4c1e147b 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
   /*
* Driver data and defines.  The descriptor counts must be a power
of two.
*/
+#ifndef __rtems__
   #defineRX_DESC_COUNT   512
+#else /* __rtems__ */
+#defineRX_DESC_COUNT   64
+#endif /* __rtems__ */


Do we need some way to control this parameter? Or, how will this
appear if it breaks something?


I don't expect that there will be any problems. But I can take a look
how I can make that a parameter.


Can we please keep this a compile time constant as it is.  The 64
descriptors should be more than enough.


I don't mind the reduction of the constant, but it would be good to
predict what behavior might indicate this was exceeded. I guess it
should be some kind of errno on an allocation request though? So it
should be fine, but if a user hits this limit, I guess they have
pretty limited options to overcome it.


Reducing the limit won't cause errors. It will only means that if you 
flood the target with network packets, it will cache less packets and 
start dropping them earlier. That means:


On a short packet burst, some packets will be dropped and (for TCP) some 
have to be re-transmitted. So for short bursts it can be a slight 
disadvantage.


On a constant overload situation: It doesn't really make a difference 
because the target wouldn't be able to process the packages anyway. It 
might even is an advantage because the processor doesn't have to process 
packets that are already outdated and maybe re-transmitted.


Best regards

Christian
--

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 rtems-libbsd 2/2] if_ffec: Allow PHY that is connected to other FFEC

[Gedare Bloom]

On Thu, Jun 2, 2022 at 1:35 AM Christian MAUDERER
 wrote:
>
> Am 01.06.22 um 14:50 schrieb Gedare Bloom:
> > Should this be upstreamed?
>
> I don't think so. The solution is quite device specific and has some
> restrictions like the right initialization order (like noted in the
> commit description). I don't think that FreeBSD will accept it.
>
> I have seen some discussions on FreeBSD that they think about a more
> generic approach. Basically that would make it necessary to split the
> MDIO part from the remaining Ethernet controller part and make it a
> separate driver. That would most likely make it necessary to change
> multiple or all Ethernet drivers. I assume that some-when someone at
> FreeBSD will add a solution like that. But till then, I think the
> slightly hacked solution that I did with this patch should work well
> enough for us.
>
OK, that makes sense. Anytime we have some creep in libbsd I would ask
this question. ;)

> >
> > On Mon, May 23, 2022 at 6:22 AM Christian Mauderer
> >  wrote:
> >>
> >> The i.MX6UL (and some others from the i.MX family) have shared MDIO
> >> lines for multiple FFECs. This patch allows to use the MDIO interface
> >> from another Ethernet controller.
> >>
> >> Note that you have to make sure that the FFECs are initialized in the
> >> right order. Normally that can be done via FDT.
> >> ---
> >>   freebsd/sys/dev/ffec/if_ffec.c | 120 +
> >>   1 file changed, 120 insertions(+)
> >>
> >> diff --git a/freebsd/sys/dev/ffec/if_ffec.c 
> >> b/freebsd/sys/dev/ffec/if_ffec.c
> >> index 4c1e147b..316e077c 100644
> >> --- a/freebsd/sys/dev/ffec/if_ffec.c
> >> +++ b/freebsd/sys/dev/ffec/if_ffec.c
> >> @@ -209,6 +209,11 @@ struct ffec_softc {
> >>  int rx_ic_count;/* RW, valid values 0..255 */
> >>  int tx_ic_time;
> >>  int tx_ic_count;
> >> +#ifdef __rtems__
> >> +
> >> +   device_tmdio_device;
> >> +   struct mtx  mdio_mtx;
> >> +#endif /* __rtems__ */
> >>   };
> >>
> >>   static struct resource_spec irq_res_spec[MAX_IRQ_COUNT + 1] = {
> >> @@ -376,6 +381,13 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)
> >>  int val;
> >>
> >>  sc = device_get_softc(dev);
> >> +#ifdef __rtems__
> >> +   if (sc->mdio_device) {
> >> +   return (MIIBUS_READREG(sc->mdio_device, phy, reg));
> >> +   }
> >> +
> >> +   mtx_lock(>mdio_mtx);
> >> +#endif /* __rtems__ */
> >>
> >>  WR4(sc, FEC_IER_REG, FEC_IER_MII);
> >>
> >> @@ -386,11 +398,17 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)
> >>
> >>  if (!ffec_miibus_iowait(sc)) {
> >>  device_printf(dev, "timeout waiting for mii read\n");
> >> +#ifdef __rtems__
> >> +   mtx_unlock(>mdio_mtx);
> >> +#endif /* __rtems__ */
> >>  return (-1); /* All-ones is a symptom of bad mdio. */
> >>  }
> >>
> >>  val = RD4(sc, FEC_MMFR_REG) & FEC_MMFR_DATA_MASK;
> >>
> >> +#ifdef __rtems__
> >> +   mtx_unlock(>mdio_mtx);
> >> +#endif /* __rtems__ */
> >>  return (val);
> >>   }
> >>
> >> @@ -400,6 +418,13 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, 
> >> int val)
> >>  struct ffec_softc *sc;
> >>
> >>  sc = device_get_softc(dev);
> >> +#ifdef __rtems__
> >> +   if (sc->mdio_device) {
> >> +   return (MIIBUS_WRITEREG(sc->mdio_device, phy, reg, val));
> >> +   }
> >> +
> >> +   mtx_lock(>mdio_mtx);
> >> +#endif /* __rtems__ */
> >>
> >>  WR4(sc, FEC_IER_REG, FEC_IER_MII);
> >>
> >> @@ -411,9 +436,15 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, 
> >> int val)
> >>
> >>  if (!ffec_miibus_iowait(sc)) {
> >>  device_printf(dev, "timeout waiting for mii write\n");
> >> +#ifdef __rtems__
> >> +   mtx_unlock(>mdio_mtx);
> >> +#endif /* __rtems__ */
> >>  return (-1);
> >>  }
> >>
> >> +#ifdef __rtems__
> >> +   mtx_unlock(>mdio_mtx);
> >> +#endif /* __rtems__ */
> >>  return (0);
> >>   }
> >>
> >> @@ -1577,6 +1608,9 @@ ffec_detach(device_t dev)
> >>  if (sc->mem_res != NULL)
> >>  bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->mem_res);
> >>
> >> +#ifdef __rtems__
> >> +   mtx_destroy(>mtx);
> >> +#endif /* __rtems__ */
> >>  FFEC_LOCK_DESTROY(sc);
> >>  return (0);
> >>   }
> >> @@ -1726,6 +1760,80 @@ ffec_set_txic(struct ffec_softc *sc)
> >>  ffec_set_ic(sc, FEC_TXIC0_REG, sc->tx_ic_count, sc->tx_ic_time);
> >>   }
> >>
> >> +#ifdef __rtems__
> >> +int
> >> +ffec_get_phy_information(
> >> +   struct ffec_softc *sc,
> >> +   phandle_t node,
> >> +   device_t dev,
> >> +   int *phy_addr
> >> +)
> >> +{
> >> +   phandle_t phy_node;
> >> +   phandle_t parent_node;
> >> +   pcell_t phy_handle, phy_reg;
> >> +   device_t other;
> >> +   phandle_t xref;
> >> +
> >> +   

Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

[Gedare Bloom]

On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber
 wrote:
>
> On 02/06/2022 09:27, Christian MAUDERER wrote:
> >
> > Am 01.06.22 um 14:46 schrieb Gedare Bloom:
> >> On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
> >>  wrote:
> >>>
> >>> Typical embedded systems don't have that much memory. Reduce the buffer
> >>> size to something more sensible for the usual type of application.
> >>> ---
> >>>   freebsd/sys/dev/ffec/if_ffec.c | 8 
> >>>   1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/freebsd/sys/dev/ffec/if_ffec.c
> >>> b/freebsd/sys/dev/ffec/if_ffec.c
> >>> index 47c0f770..4c1e147b 100644
> >>> --- a/freebsd/sys/dev/ffec/if_ffec.c
> >>> +++ b/freebsd/sys/dev/ffec/if_ffec.c
> >>> @@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
> >>>   /*
> >>>* Driver data and defines.  The descriptor counts must be a power
> >>> of two.
> >>>*/
> >>> +#ifndef __rtems__
> >>>   #defineRX_DESC_COUNT   512
> >>> +#else /* __rtems__ */
> >>> +#defineRX_DESC_COUNT   64
> >>> +#endif /* __rtems__ */
> >>
> >> Do we need some way to control this parameter? Or, how will this
> >> appear if it breaks something?
> >
> > I don't expect that there will be any problems. But I can take a look
> > how I can make that a parameter.
>
> Can we please keep this a compile time constant as it is.  The 64
> descriptors should be more than enough.
>
I don't mind the reduction of the constant, but it would be good to
predict what behavior might indicate this was exceeded. I guess it
should be some kind of errno on an allocation request though? So it
should be fine, but if a user hits this limit, I guess they have
pretty limited options to overcome it.

> --
> 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] devel/spike-1.0.0: bump hash

[Gedare Bloom]

On Wed, Jun 1, 2022 at 7:46 AM Ryan Long  wrote:
>
>
> On 6/1/2022 7:36 AM, Gedare Bloom wrote:
> > What/Why did this change? Where we not using a release before?
> I'm not sure. Their Github only shows two releases. One's from 2019 and
> the latest is from late 2021. The last time the hash was bumped was in
> 2020 by Joel, so I'm guessing that was changing it to the 1.0.0 release,
> and this just bumps it to 1.1.0. Maybe it was in beta at the time.
> >
> > Looks ok otherwise.
> >
ok

> > On Wed, May 25, 2022 at 12:31 PM Ryan Long  wrote:
> >> Bump the hash of spike to match the 1.1.0 release
> >>
> >> Closes #4660
> >> ---
> >>   bare/config/devel/spike-1.1.0.cfg | 4 ++--
> >>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/bare/config/devel/spike-1.1.0.cfg 
> >> b/bare/config/devel/spike-1.1.0.cfg
> >> index 644b754..73cf3c2 100644
> >> --- a/bare/config/devel/spike-1.1.0.cfg
> >> +++ b/bare/config/devel/spike-1.1.0.cfg
> >> @@ -8,9 +8,9 @@
> >>
> >>   %include %{_configdir}/base.cfg
> >>
> >> -%define spike_version 66b44bfbedda562a32e4a2cd0716afbf731b69cd
> >> +%define spike_version 530af85d83781a3dae31a4ace84a573ec255fefa
> >>
> >> -%hash sha512 spike-%{spike_version}.tar.gz 
> >> a98fc9e564edb3bb471f04063484a5d056befb8b2258b96de2d238cf27d1d5544c2782c91c7731b8f0aa03012eb3d39de33e4f30927349e38c7e131e8241b92f
> >> +%hash sha512 spike-%{spike_version}.tar.gz 
> >> D+9XugRwrZJ8undjx3x3CILr4VSdeaNsTTUZYeENFPZy6MG7TiQAY5umaUr/oOr6vWCq7YjFhqwjPI+fcieqYw==
> >>
> >>   #
> >>   # The spike build instructions. We use 1.x.x Release 1.
> >> --
> >> 2.30.2
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

[Sebastian Huber]

On 02/06/2022 09:27, Christian MAUDERER wrote:


Am 01.06.22 um 14:46 schrieb Gedare Bloom:

On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
 wrote:


Typical embedded systems don't have that much memory. Reduce the buffer
size to something more sensible for the usual type of application.
---
  freebsd/sys/dev/ffec/if_ffec.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/freebsd/sys/dev/ffec/if_ffec.c 
b/freebsd/sys/dev/ffec/if_ffec.c

index 47c0f770..4c1e147b 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
  /*
   * Driver data and defines.  The descriptor counts must be a power 
of two.

   */
+#ifndef __rtems__
  #define    RX_DESC_COUNT   512
+#else /* __rtems__ */
+#define    RX_DESC_COUNT   64
+#endif /* __rtems__ */


Do we need some way to control this parameter? Or, how will this
appear if it breaks something?


I don't expect that there will be any problems. But I can take a look 
how I can make that a parameter.


Can we please keep this a compile time constant as it is.  The 64 
descriptors should be more than enough.


--
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 rtems] bsps/imx: Enable clock of ETH2

[Christian MAUDERER]

Am 01.06.22 um 14:42 schrieb Gedare Bloom:

On Mon, May 23, 2022 at 6:22 AM Christian Mauderer
 wrote:


---
  bsps/arm/imx/start/bspstart.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/bsps/arm/imx/start/bspstart.c b/bsps/arm/imx/start/bspstart.c
index 04d48d1558..e9cca49200 100644
--- a/bsps/arm/imx/start/bspstart.c
+++ b/bsps/arm/imx/start/bspstart.c
@@ -161,6 +161,18 @@ static void imx_find_gic(const void *fdt)
  #endif
  }

+static void imx_ccm_enable_eth2_clk(void)
+{
+  const void *fdt = bsp_fdt_get();
+
+  if (imx_is_imx6(fdt)) {
+volatile uint32_t *ccm_pll_enet_set = (void *)0x020c80e4;

Should this magic address be a #define somewhere?



You are right: I was lazy here because it was only a single register and 
I thought that it's not that much difference whether I add it as a 
single magic address in the code or as a define in a header. But it's a 
bit out of style so I'll change it to match the style of other similar 
cases.



+const uint32_t ccm_pll_enet_enet2_125m_en = (1 << 20);
+
+*ccm_pll_enet_set = ccm_pll_enet_enet2_125m_en;
+  }
+}
+
  void bsp_start(void)
  {
imx_find_gic(bsp_fdt_get());
@@ -169,4 +181,5 @@ void bsp_start(void)
  bsp_section_nocacheheap_begin,
  (uintptr_t) bsp_section_nocacheheap_size
);
+  imx_ccm_enable_eth2_clk();
  }
--
2.35.3

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


--

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 rtems-libbsd 2/2] if_ffec: Allow PHY that is connected to other FFEC

[Christian MAUDERER]

Am 01.06.22 um 14:50 schrieb Gedare Bloom:

Should this be upstreamed?


I don't think so. The solution is quite device specific and has some 
restrictions like the right initialization order (like noted in the 
commit description). I don't think that FreeBSD will accept it.


I have seen some discussions on FreeBSD that they think about a more 
generic approach. Basically that would make it necessary to split the 
MDIO part from the remaining Ethernet controller part and make it a 
separate driver. That would most likely make it necessary to change 
multiple or all Ethernet drivers. I assume that some-when someone at 
FreeBSD will add a solution like that. But till then, I think the 
slightly hacked solution that I did with this patch should work well 
enough for us.




On Mon, May 23, 2022 at 6:22 AM Christian Mauderer
 wrote:


The i.MX6UL (and some others from the i.MX family) have shared MDIO
lines for multiple FFECs. This patch allows to use the MDIO interface
from another Ethernet controller.

Note that you have to make sure that the FFECs are initialized in the
right order. Normally that can be done via FDT.
---
  freebsd/sys/dev/ffec/if_ffec.c | 120 +
  1 file changed, 120 insertions(+)

diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
index 4c1e147b..316e077c 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -209,6 +209,11 @@ struct ffec_softc {
 int rx_ic_count;/* RW, valid values 0..255 */
 int tx_ic_time;
 int tx_ic_count;
+#ifdef __rtems__
+
+   device_tmdio_device;
+   struct mtx  mdio_mtx;
+#endif /* __rtems__ */
  };

  static struct resource_spec irq_res_spec[MAX_IRQ_COUNT + 1] = {
@@ -376,6 +381,13 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)
 int val;

 sc = device_get_softc(dev);
+#ifdef __rtems__
+   if (sc->mdio_device) {
+   return (MIIBUS_READREG(sc->mdio_device, phy, reg));
+   }
+
+   mtx_lock(>mdio_mtx);
+#endif /* __rtems__ */

 WR4(sc, FEC_IER_REG, FEC_IER_MII);

@@ -386,11 +398,17 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)

 if (!ffec_miibus_iowait(sc)) {
 device_printf(dev, "timeout waiting for mii read\n");
+#ifdef __rtems__
+   mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
 return (-1); /* All-ones is a symptom of bad mdio. */
 }

 val = RD4(sc, FEC_MMFR_REG) & FEC_MMFR_DATA_MASK;

+#ifdef __rtems__
+   mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
 return (val);
  }

@@ -400,6 +418,13 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, int 
val)
 struct ffec_softc *sc;

 sc = device_get_softc(dev);
+#ifdef __rtems__
+   if (sc->mdio_device) {
+   return (MIIBUS_WRITEREG(sc->mdio_device, phy, reg, val));
+   }
+
+   mtx_lock(>mdio_mtx);
+#endif /* __rtems__ */

 WR4(sc, FEC_IER_REG, FEC_IER_MII);

@@ -411,9 +436,15 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, int 
val)

 if (!ffec_miibus_iowait(sc)) {
 device_printf(dev, "timeout waiting for mii write\n");
+#ifdef __rtems__
+   mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
 return (-1);
 }

+#ifdef __rtems__
+   mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
 return (0);
  }

@@ -1577,6 +1608,9 @@ ffec_detach(device_t dev)
 if (sc->mem_res != NULL)
 bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->mem_res);

+#ifdef __rtems__
+   mtx_destroy(>mtx);
+#endif /* __rtems__ */
 FFEC_LOCK_DESTROY(sc);
 return (0);
  }
@@ -1726,6 +1760,80 @@ ffec_set_txic(struct ffec_softc *sc)
 ffec_set_ic(sc, FEC_TXIC0_REG, sc->tx_ic_count, sc->tx_ic_time);
  }

+#ifdef __rtems__
+int
+ffec_get_phy_information(
+   struct ffec_softc *sc,
+   phandle_t node,
+   device_t dev,
+   int *phy_addr
+)
+{
+   phandle_t phy_node;
+   phandle_t parent_node;
+   pcell_t phy_handle, phy_reg;
+   device_t other;
+   phandle_t xref;
+
+   /* Search for the phy-handle and get the address */
+
+   if (OF_getencprop(node, "phy-handle", (void *)_handle,
+   sizeof(phy_handle)) <= 0)
+   return (ENXIO);
+
+   phy_node = OF_node_from_xref(phy_handle);
+
+   if (OF_getencprop(phy_node, "reg", (void *)_reg,
+   sizeof(phy_reg)) <= 0)
+   return (ENXIO);
+
+   *phy_addr = phy_reg;
+
+   /* Detect whether PHY handle is connected to this or another FFEC. */
+   parent_node = phy_node;
+
+   while (parent_node != 0) {
+   if (parent_node == node) {
+   /* PHY is directly connected. That's easy. */
+   sc->mdio_device = NULL;
+   return 0;
+   }
+
+   

Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

[Christian MAUDERER]

Hello Gedare,

Am 01.06.22 um 14:46 schrieb Gedare Bloom:

On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
 wrote:


Typical embedded systems don't have that much memory. Reduce the buffer
size to something more sensible for the usual type of application.
---
  freebsd/sys/dev/ffec/if_ffec.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
index 47c0f770..4c1e147b 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
  /*
   * Driver data and defines.  The descriptor counts must be a power of two.
   */
+#ifndef __rtems__
  #defineRX_DESC_COUNT   512
+#else /* __rtems__ */
+#defineRX_DESC_COUNT   64
+#endif /* __rtems__ */


Do we need some way to control this parameter? Or, how will this
appear if it breaks something?


I don't expect that there will be any problems. But I can take a look 
how I can make that a parameter.


Best regards

Christian




  #defineRX_DESC_SIZE(sizeof(struct ffec_hwdesc) * RX_DESC_COUNT)
+#ifndef __rtems__
  #defineTX_DESC_COUNT   512
+#else /* __rtems__ */
+#defineTX_DESC_COUNT   64
+#endif /* __rtems__ */
  #defineTX_DESC_SIZE(sizeof(struct ffec_hwdesc) * TX_DESC_COUNT)
  #defineTX_MAX_DMA_SEGS 8

--
2.35.3

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


--

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 rtems-lwip] lwip: Split sources into origin directories

[Pavel Pisa]

Dear Vijay,

On Thursday 02 of June 2022 05:56:56 Vijay Kumar Banerjee wrote:
> I have pushed this patch and I would like to add a note regarding that.

thanks for the work and time.

> This patch started interesting discussions about the possible ways to
> organize code from multiple sources. Pavel also raised an issue with
> the directory name "uLan". Since the repository is still in a personal
> area and still in the development stage, we can make rapid changes to
> the repository. We will change the directory name from uLan to
> something that's more suitable,

please no uLAN it is RS-485 protocol. Yes it has and reuses our sysless
firware base project and uses OOMK build system which we use
for build of GNU/Linux, sysless, RTEMS, NuttX and even Windows
applications. Because I used our port of LwIP which uses OMK
build to test it in RTEMS I have named it lwip-omk and because
we use the code in our instruments firmware which use OMK build,
sysless and often uLAN protocol it ended in the repo under
uLAN project.

https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/

But using this project name in the case where
OMK buid system is unwanted, there is nor RS-485 connection
and no use of other libraries and bare metal support from
that PiKRON project is so misleading, that I have to insist
to not use uLAN label...

I suggest to have only ports directory at the rtems-lwip
toplevel. We should go through the process to relicense
all (where we are authors or where we can contact author)
to RTEMS mainline acceptable licence. If there is some problematic
driver then it stays in 

  ports/driver/driver_name

directory so it will be separated and license precisely defined
in that directory.

I still see in the driers base only our own tms570_emac.
So what is the plan for integrating others?

It would be great to have there at least two working
ports because then it will be seen how to select them
on the build system level.

Thanks for updating project documentation

https://devel.rtems.org/wiki/Packages/LWIP

There is another task to solve. In the OMK build,
there has been made possible to configure the most
of the LwIP options from the project top level
config.omk and config.target. It should be considered,
how buffers size, count and many other featires will
be configured in actual RSB build. Problem is that
LwIP on targets with little memory (it worked on
256 kB TMS570LS3137) and on the other hand configuration
for some bigger systems as is  Gaisler GR740 or somethink
NOEL-V based can be significantly different when
megabytes of RAM can be used.

By the way, I am presenting at

9th International Workshop on Analogue and Mixed-Signal
Integrated Circuits for Space Applications
https://indico.esa.int/event/388/

and I have met there people from TTTech
and they can have interrest to try RTEMS
even on their TTEthernet space ASIC
internal Leon 2 core. But it is memory
constrained environment so for TCP/IP non-real time
traffic they most probably cannot use BSD stack,
so LwIP + RTEMS can be the option there.

But it is necessary to put project into some
reusable shape. Unfortunately I do not have
time to work on it some intensive way now
and I do not know RSB stuff enough.

On the other hand, if they express real interest,
I can try, if I am able attract some students
from our universitywho can work on the project.
I invest a lot to pass knowledge for their serious
work in this area.

By the way, we have switched our Computer Architectures
course to RISC-V in this run

  https://cw.fel.cvut.cz/wiki/courses/b35apo/en/start

including simulator

  https://github.com/cvut/qtrvsim

and public recording (even English, sorry Czenglish)

  https://www.youtube.com/playlist?list=PLQL6z4JeTTQnTrML7HgagbjdpCtvdyu0M

Best wishes,

Pavel Pisa

==
 PiKRON s.r.o.   Phone/Fax: +420 284684676
 Kankovskeho 1235Phone: +420 234697622
 182 00 Praha 8  WWW:   http://www.pikron.com/
 Czech Republic  e-mail:  pik...@pikron.com
==
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel