Re: [PATCH rtems-libbsd v2 0/5] Beagle BSP: USB Template Driver for CDC Ethernet

2021-08-08 Thread Christian Mauderer 

Hello Husni,

On 07/08/2021 21:56, Ahamed Husni wrote:

Hi Christian,

Are there any issues I should address in this patch set?


I think the big open question is the one from Chris:

https://lists.rtems.org/pipermail/devel/2021-July/068634.html

You mentioned that you filtered the ones for the imported code. That's 
OK for most symbols if they are not relevant for the part where you work 
on. But Chris copied a whole block of "extern struct 
usb_temp_device_desc *". It's not clear for me whether you filtered some 
of them or whether they haven't been generated.


If they are generated: Please keep them. Basically keep everything that 
is in one of the files that you touch, except if you have a good reason 
why the symbol should _not_ be added.


If they are not generated: Please clearly say that.

Best regards

Christian



On Mon, Aug 2, 2021 at 12:09 PM Christian MAUDERER 
> wrote:


Hello Husni,

Am 01.08.21 um 19:59 schrieb Ahamed Husni:
 > Hi Christian,
 >
 > On Sun, Aug 1, 2021 at 4:57 PM Christian Mauderer
mailto:o...@c-mauderer.de>
 > >> wrote:
 >
 >     Hello Husni,
 >
 >     just tested that and it works fine. With a simple curl I can
reach
 >     about
 >     8.5 MByte/s sending to the beagle and 19.5 MByte/s receiving
from it.
 >
 > That's 68 Mbps for sending. That's an acceptable speed isn't it?
 >

At the moment I would be OK with basically any speed. It was just some
information so that someone who finds the mail knows what he can expect.

It would be interesting to see how the speeds compare to a FreeBSD
setup
on the Beagle. If there is no bug in our port, it should be about
the same.

Best regards

Christian

 >     Please take a look at the points that Chris Johns asked. As
soon as
 >     these are addressed, I think the patches could be merged.
 >
 > I just replied to it now. Sorry for the delay.
 >
 >
 >     Please also make the documentation that you started for this more
 >     public
 >     visible. In other words: Send it as patches to the list and
not only as
 >     a link to some branch!
 >
 > Noted.
 >
 >
 >     Best regards
 >
 >     Christian
 >
 >     On 28/07/2021 13:56, Husni Faiz wrote:
 >      > This set of patches import the drivers from freebsd and
 >      > configures it for the beagle bsp.
 >      >
 >      > Github Branch for the commits
 >      > https://github.com/drac98/rtems-libbsd/commits/usb-cdce

 >     >
 >      >
 >      > Patch for 6-freebsd-12 branch
 >      > https://github.com/drac98/rtems-libbsd/commits/usb-cdce12

 >     >
 >      >
 >      > Husni Faiz (5):
 >      >    usb_template:Import CDC Ethernet
 >      >    usb_template: Configure template driver only for CDC
Ethernet
 >      >    nexus-devices: Include CDC Ethernet for Beagle
 >      >    libbsd.py: add usb template files
 >      >    create-kernel-namespace for USB Template driver
 >      >
 >      >   buildset/default.ini                          |    1 +
 >      >   buildset/minimal.ini                          |    3 +-
 >      >   freebsd/sys/dev/usb/template/usb_template.c   | 1493
 >     +
 >      >   freebsd/sys/dev/usb/template/usb_template.h   |  130 ++
 >      >   .../sys/dev/usb/template/usb_template_cdce.c  |  355 
 >      >   freebsd/sys/dev/usb/usb_device.c              |    8 +-
 >      >   libbsd.py                                     |   25 +
 >      >   rtemsbsd/include/bsp/nexus-devices.h          |    5 +
 >      >   .../machine/rtems-bsd-kernel-namespace.h      |    5 +
 >      >   .../include/machine/rtems-bsd-nexus-bus.h     |   19 +
 >      >   10 files changed, 2041 insertions(+), 3 deletions(-)
 >      >   create mode 100644
freebsd/sys/dev/usb/template/usb_template.c
 >      >   create mode 100644
freebsd/sys/dev/usb/template/usb_template.h
 >      >   create mode 100644
freebsd/sys/dev/usb/template/usb_template_cdce.c
 >      >
 >
 >
 > ___
 > devel mailing list
 > devel@rtems.org 
 > http://lists.rtems.org/mailman/listinfo/devel

 >

-- 


embedded brains

Re: [PATCH rtems-libbsd v2 0/5] Beagle BSP: USB Template Driver for CDC Ethernet

2021-08-08 Thread Ahamed Husni 
Hi Christian,

On Sun, Aug 8, 2021 at 1:36 PM Christian Mauderer  wrote:

> Hello Husni,
>
> On 07/08/2021 21:56, Ahamed Husni wrote:
> > Hi Christian,
> >
> > Are there any issues I should address in this patch set?
>
> I think the big open question is the one from Chris:
>
> https://lists.rtems.org/pipermail/devel/2021-July/068634.html
>
> You mentioned that you filtered the ones for the imported code. That's
> OK for most symbols if they are not relevant for the part where you work
> on. But Chris copied a whole block of "extern struct
> usb_temp_device_desc *". It's not clear for me whether you filtered some
> of them or whether they haven't been generated.
>
>
The "extern struct usb_temp_device_desc *" block is in the usb_template.h
header.
These are not generated structs.
These usb device descriptor structs are for each usb device currently
supported by
freebsd. This patch set only imports the CDC Ethernet device template. So
we can
exclude the other structs with #ifndef __rtems__ if necessary. If the extra
structs should
be excluded, I can send a patch v3.

If they are generated: Please keep them. Basically keep everything that
> is in one of the files that you touch, except if you have a good reason
> why the symbol should _not_ be added.
>
> If they are not generated: Please clearly say that.
>
> Those externs are not generated. They are in the original freebsd source.
https://github.com/freebsd/freebsd-src/blob/main/sys/dev/usb/template/usb_template.h#L106

Best regards,
Husni.

Best regards
>
> Christian
>
> >
> > On Mon, Aug 2, 2021 at 12:09 PM Christian MAUDERER
> >  > > wrote:
> >
> > Hello Husni,
> >
> > Am 01.08.21 um 19:59 schrieb Ahamed Husni:
> >  > Hi Christian,
> >  >
> >  > On Sun, Aug 1, 2021 at 4:57 PM Christian Mauderer
> > mailto:o...@c-mauderer.de>
> >  > >> wrote:
> >  >
> >  > Hello Husni,
> >  >
> >  > just tested that and it works fine. With a simple curl I can
> > reach
> >  > about
> >  > 8.5 MByte/s sending to the beagle and 19.5 MByte/s receiving
> > from it.
> >  >
> >  > That's 68 Mbps for sending. That's an acceptable speed isn't it?
> >  >
> >
> > At the moment I would be OK with basically any speed. It was just
> some
> > information so that someone who finds the mail knows what he can
> expect.
> >
> > It would be interesting to see how the speeds compare to a FreeBSD
> > setup
> > on the Beagle. If there is no bug in our port, it should be about
> > the same.
> >
> > Best regards
> >
> > Christian
> >
> >  > Please take a look at the points that Chris Johns asked. As
> > soon as
> >  > these are addressed, I think the patches could be merged.
> >  >
> >  > I just replied to it now. Sorry for the delay.
> >  >
> >  >
> >  > Please also make the documentation that you started for this
> more
> >  > public
> >  > visible. In other words: Send it as patches to the list and
> > not only as
> >  > a link to some branch!
> >  >
> >  > Noted.
> >  >
> >  >
> >  > Best regards
> >  >
> >  > Christian
> >  >
> >  > On 28/07/2021 13:56, Husni Faiz wrote:
> >  >  > This set of patches import the drivers from freebsd and
> >  >  > configures it for the beagle bsp.
> >  >  >
> >  >  > Github Branch for the commits
> >  >  > https://github.com/drac98/rtems-libbsd/commits/usb-cdce
> > 
> >  >  > >
> >  >  >
> >  >  > Patch for 6-freebsd-12 branch
> >  >  > https://github.com/drac98/rtems-libbsd/commits/usb-cdce12
> > 
> >  >  > >
> >  >  >
> >  >  > Husni Faiz (5):
> >  >  >usb_template:Import CDC Ethernet
> >  >  >usb_template: Configure template driver only for CDC
> > Ethernet
> >  >  >nexus-devices: Include CDC Ethernet for Beagle
> >  >  >libbsd.py: add usb template files
> >  >  >create-kernel-namespace for USB Template driver
> >  >  >
> >  >  >   buildset/default.ini  |1 +
> >  >  >   buildset/minimal.ini  |3 +-
> >  >  >   freebsd/sys/dev/usb/template/usb_template.c   | 1493
> >  > +
> >  >  >   freebsd/sys/dev/usb/template/usb_template.h   |  130 ++
> >  >  >   .../sys/dev/usb/template/usb_templa

Re: [PATCH rtems-libbsd v2 0/5] Beagle BSP: USB Template Driver for CDC Ethernet

2021-08-08 Thread Christian Mauderer 

Hello Husni,

On 08/08/2021 11:15, Ahamed Husni wrote:

Hi Christian,

On Sun, Aug 8, 2021 at 1:36 PM Christian Mauderer > wrote:


Hello Husni,

On 07/08/2021 21:56, Ahamed Husni wrote:
 > Hi Christian,
 >
 > Are there any issues I should address in this patch set?

I think the big open question is the one from Chris:

https://lists.rtems.org/pipermail/devel/2021-July/068634.html


You mentioned that you filtered the ones for the imported code. That's
OK for most symbols if they are not relevant for the part where you
work
on. But Chris copied a whole block of "extern struct
usb_temp_device_desc *". It's not clear for me whether you filtered
some
of them or whether they haven't been generated.

The "extern struct usb_temp_device_desc *" block is in the 
usb_template.h header.

These are not generated structs.
These usb device descriptor structs are for each usb device currently 
supported by
freebsd. This patch set only imports the CDC Ethernet device template. 
So we can
exclude the other structs with #ifndef __rtems__ if necessary. If the 
extra structs should

be excluded, I can send a patch v3.

If they are generated: Please keep them. Basically keep everything that
is in one of the files that you touch, except if you have a good reason
why the symbol should _not_ be added.

If they are not generated: Please clearly say that.

Those externs are not generated. They are in the original freebsd source.
https://github.com/freebsd/freebsd-src/blob/main/sys/dev/usb/template/usb_template.h#L106 



What I wanted to say was: If the defines like

  #defineusb_template_cdce _bsd_usb_template_cdce

are not generated for the other externa that Chris listed, please say 
it. I just checked and they are not. So I'm OK with that.


So if I have followed the discussion correctly, there are no further 
changes (except for the typo in one file), correct?


The branches usb-cdce and usb-cdce12 are up to date?

Best regards

Christian



Best regards,
Husni.

Best regards

Christian

 >
 > On Mon, Aug 2, 2021 at 12:09 PM Christian MAUDERER
 > mailto:christian.maude...@embedded-brains.de>
 > >> wrote:
 >
 >     Hello Husni,
 >
 >     Am 01.08.21 um 19:59 schrieb Ahamed Husni:
 >      > Hi Christian,
 >      >
 >      > On Sun, Aug 1, 2021 at 4:57 PM Christian Mauderer
 >     mailto:o...@c-mauderer.de>
>
 >      > 
      >
 >      >     Hello Husni,
 >      >
 >      >     just tested that and it works fine. With a simple curl
I can
 >     reach
 >      >     about
 >      >     8.5 MByte/s sending to the beagle and 19.5 MByte/s
receiving
 >     from it.
 >      >
 >      > That's 68 Mbps for sending. That's an acceptable speed
isn't it?
 >      >
 >
 >     At the moment I would be OK with basically any speed. It was
just some
 >     information so that someone who finds the mail knows what he
can expect.
 >
 >     It would be interesting to see how the speeds compare to a
FreeBSD
 >     setup
 >     on the Beagle. If there is no bug in our port, it should be about
 >     the same.
 >
 >     Best regards
 >
 >     Christian
 >
 >      >     Please take a look at the points that Chris Johns
asked. As
 >     soon as
 >      >     these are addressed, I think the patches could be merged.
 >      >
 >      > I just replied to it now. Sorry for the delay.
 >      >
 >      >
 >      >     Please also make the documentation that you started
for this more
 >      >     public
 >      >     visible. In other words: Send it as patches to the
list and
 >     not only as
 >      >     a link to some branch!
 >      >
 >      > Noted.
 >      >
 >      >
 >      >     Best regards
 >      >
 >      >     Christian
 >      >
 >      >     On 28/07/2021 13:56, Husni Faiz wrote:
 >      >      > This set of patches import the drivers from freebsd and
 >      >      > configures it for the beagle bsp.
 >      >      >
 >      >      > Github Branch for the commits
 >      >      >
https://github.com/drac98/rtems-libbsd/commits/usb-cdce

 >     

Re: [PATCH rtems-libbsd v2 0/5] Beagle BSP: USB Template Driver for CDC Ethernet

2021-08-08 Thread Ahamed Husni 
Hi,

On Sun, Aug 8, 2021 at 3:00 PM Christian Mauderer  wrote:

> Hello Husni,
>
> On 08/08/2021 11:15, Ahamed Husni wrote:
> > Hi Christian,
> >
> > On Sun, Aug 8, 2021 at 1:36 PM Christian Mauderer  > > wrote:
> >
> > Hello Husni,
> >
> > On 07/08/2021 21:56, Ahamed Husni wrote:
> >  > Hi Christian,
> >  >
> >  > Are there any issues I should address in this patch set?
> >
> > I think the big open question is the one from Chris:
> >
> > https://lists.rtems.org/pipermail/devel/2021-July/068634.html
> > 
> >
> > You mentioned that you filtered the ones for the imported code.
> That's
> > OK for most symbols if they are not relevant for the part where you
> > work
> > on. But Chris copied a whole block of "extern struct
> > usb_temp_device_desc *". It's not clear for me whether you filtered
> > some
> > of them or whether they haven't been generated.
> >
> > The "extern struct usb_temp_device_desc *" block is in the
> > usb_template.h header.
> > These are not generated structs.
> > These usb device descriptor structs are for each usb device currently
> > supported by
> > freebsd. This patch set only imports the CDC Ethernet device template.
> > So we can
> > exclude the other structs with #ifndef __rtems__ if necessary. If the
> > extra structs should
> > be excluded, I can send a patch v3.
> >
> > If they are generated: Please keep them. Basically keep everything
> that
> > is in one of the files that you touch, except if you have a good
> reason
> > why the symbol should _not_ be added.
> >
> > If they are not generated: Please clearly say that.
> >
> > Those externs are not generated. They are in the original freebsd source.
> >
> https://github.com/freebsd/freebsd-src/blob/main/sys/dev/usb/template/usb_template.h#L106
> > <
> https://github.com/freebsd/freebsd-src/blob/main/sys/dev/usb/template/usb_template.h#L106
> >
>
> What I wanted to say was: If the defines like
>
>#defineusb_template_cdce _bsd_usb_template_cdce
>
> are not generated for the other externa that Chris listed, please say
> it. I just checked and they are not. So I'm OK with that.
>
> ah yes. defines for other structs didn't generate. I misunderstood the
question earlier. Sorry.


> So if I have followed the discussion correctly, there are no further
> changes (except for the typo in one file), correct?
>
> yes.

The branches usb-cdce and usb-cdce12 are up to date?
>
> yes. (the typo is not fixed there either.)

Best regards,
Husni.

Best regards
>
> Christian
>
> >
> > Best regards,
> > Husni.
> >
> > Best regards
> >
> > Christian
> >
> >  >
> >  > On Mon, Aug 2, 2021 at 12:09 PM Christian MAUDERER
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  > Hello Husni,
> >  >
> >  > Am 01.08.21 um 19:59 schrieb Ahamed Husni:
> >  >  > Hi Christian,
> >  >  >
> >  >  > On Sun, Aug 1, 2021 at 4:57 PM Christian Mauderer
> >  > mailto:o...@c-mauderer.de>
> > >
> >  >  > 
> >  >  >  >
> >  >  > Hello Husni,
> >  >  >
> >  >  > just tested that and it works fine. With a simple curl
> > I can
> >  > reach
> >  >  > about
> >  >  > 8.5 MByte/s sending to the beagle and 19.5 MByte/s
> > receiving
> >  > from it.
> >  >  >
> >  >  > That's 68 Mbps for sending. That's an acceptable speed
> > isn't it?
> >  >  >
> >  >
> >  > At the moment I would be OK with basically any speed. It was
> > just some
> >  > information so that someone who finds the mail knows what he
> > can expect.
> >  >
> >  > It would be interesting to see how the speeds compare to a
> > FreeBSD
> >  > setup
> >  > on the Beagle. If there is no bug in our port, it should be
> about
> >  > the same.
> >  >
> >  > Best regards
> >  >
> >  > Christian
> >  >
> >  >  > Please take a look at the points that Chris Johns
> > asked. As
> >  > soon as
> >  >  > these are addressed, I think the patches could be
> merged.
> >  >  >
> >  >  > I just replied to it now. Sorry for the delay.
> >  >  >
> >  >  >
> >  >  > Please also make the documentation that you started
> > for this more
> >  >  > public
> >  >  > visible. In other words: Send it as patches to the
> > list and
> >  > not only

Re: [PATCH rtems-libbsd v2 0/5] Beagle BSP: USB Template Driver for CDC Ethernet

2021-08-08 Thread Christian Mauderer 

Hello Chris,

I think all open questions should be answered or did I miss one from 
your side? If not I would like to push the patches.


Best regards

Christian

On 08/08/2021 11:46, Ahamed Husni wrote:

Hi,

On Sun, Aug 8, 2021 at 3:00 PM Christian Mauderer > wrote:


Hello Husni,

On 08/08/2021 11:15, Ahamed Husni wrote:
 > Hi Christian,
 >
 > On Sun, Aug 8, 2021 at 1:36 PM Christian Mauderer
mailto:o...@c-mauderer.de>
 > >> wrote:
 >
 >     Hello Husni,
 >
 >     On 07/08/2021 21:56, Ahamed Husni wrote:
 >      > Hi Christian,
 >      >
 >      > Are there any issues I should address in this patch set?
 >
 >     I think the big open question is the one from Chris:
 >
 > https://lists.rtems.org/pipermail/devel/2021-July/068634.html

 >   
  >
 >
 >     You mentioned that you filtered the ones for the imported
code. That's
 >     OK for most symbols if they are not relevant for the part
where you
 >     work
 >     on. But Chris copied a whole block of "extern struct
 >     usb_temp_device_desc *". It's not clear for me whether you
filtered
 >     some
 >     of them or whether they haven't been generated.
 >
 > The "extern struct usb_temp_device_desc *" block is in the
 > usb_template.h header.
 > These are not generated structs.
 > These usb device descriptor structs are for each usb device
currently
 > supported by
 > freebsd. This patch set only imports the CDC Ethernet device
template.
 > So we can
 > exclude the other structs with #ifndef __rtems__ if necessary. If
the
 > extra structs should
 > be excluded, I can send a patch v3.
 >
 >     If they are generated: Please keep them. Basically keep
everything that
 >     is in one of the files that you touch, except if you have a
good reason
 >     why the symbol should _not_ be added.
 >
 >     If they are not generated: Please clearly say that.
 >
 > Those externs are not generated. They are in the original freebsd
source.
 >

https://github.com/freebsd/freebsd-src/blob/main/sys/dev/usb/template/usb_template.h#L106



 >

>

What I wanted to say was: If the defines like

    #define        usb_template_cdce _bsd_usb_template_cdce

are not generated for the other externa that Chris listed, please say
it. I just checked and they are not. So I'm OK with that.

ah yes. defines for other structs didn't generate. I misunderstood the
question earlier. Sorry.

So if I have followed the discussion correctly, there are no further
changes (except for the typo in one file), correct?

yes.

The branches usb-cdce and usb-cdce12 are up to date?

yes. (the typo is not fixed there either.)

Best regards,
Husni.

Best regards

Christian

 >
 > Best regards,
 > Husni.
 >
 >     Best regards
 >
 >     Christian
 >
 >      >
 >      > On Mon, Aug 2, 2021 at 12:09 PM Christian MAUDERER
 >      > mailto:christian.maude...@embedded-brains.de>
 >     >
 >      > 
 >           >
 >      >     Hello Husni,
 >      >
 >      >     Am 01.08.21 um 19:59 schrieb Ahamed Husni:
 >      >      > Hi Christian,
 >      >      >
 >      >      > On Sun, Aug 1, 2021 at 4:57 PM Christian Mauderer
 >      >     mailto:o...@c-mauderer.de>
>
 >     
>>
 >      >      >  >
 >     
 wrote:
 >      >      >
 >      >      >     Hello Husni,
 >      >      >
 >      >      >     just tested that and it works fine. With a
simple curl
 >     I can
 >      >   

Re: [PATCH rtems-libbsd v2 5/5] create-kernel-namespace for USB Template driver

2021-08-08 Thread Chris Johns 


On 2/8/21 4:24 am, Ahamed Husni wrote:
> Hello Chris,
> 
> On Thu, Jul 29, 2021 at 5:41 AM Chris Johns  > wrote:
> 
> On 28/7/21 9:56 pm, Husni Faiz wrote:
> > Signed-off-by: Husni Faiz  >
> > ---
> >  rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> > index 97cdb625..ae56ad9c 100644
> > --- a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> > +++ b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> > @@ -5279,6 +5279,7 @@
> >  #define      usbd_do_request_proc _bsd_usbd_do_request_proc
> >  #define      usbd_dummy_timeout _bsd_usbd_dummy_timeout
> >  #define      usb_debug _bsd_usb_debug
> > +#define      usb_decode_str_desc _bsd_usb_decode_str_desc
> >  #define      usbd_enum_is_locked _bsd_usbd_enum_is_locked
> >  #define      usbd_enum_lock _bsd_usbd_enum_lock
> >  #define      usbd_enum_lock_sig _bsd_usbd_enum_lock_sig
> > @@ -5515,8 +5516,12 @@
> >  #define      usb_suspend_resume _bsd_usb_suspend_resume
> >  #define      usb_temp_get_desc_p _bsd_usb_temp_get_desc_p
> >  #define      usb_template _bsd_usb_template
> > +#define      usb_template_cdce _bsd_usb_template_cdce
> > +#define      usb_temp_setup _bsd_usb_temp_setup
> >  #define      usb_temp_setup_by_index_p _bsd_usb_temp_setup_by_index_p
> > +#define      usb_temp_sysctl _bsd_usb_temp_sysctl
> >  #define      usb_temp_unload _bsd_usb_temp_unload
> > +#define      usb_temp_unsetup _bsd_usb_temp_unsetup
> >  #define      usb_temp_unsetup_p _bsd_usb_temp_unsetup_p
> >  #define      usb_test_quirk _bsd_usb_test_quirk
> >  #define      usb_test_quirk_p _bsd_usb_test_quirk_p
> 
> How were these additions done? 
> 
>  
> I used the create-kernel-namespace.sh script which auto genarates these 
> definitions.
> That generated more definitions than I have added here. I only filtered out 
> the
> definitions for the codes I imported.

Thanks and yes it is wise to do this.

I am going to ask for these changes to be queued behind my posted patches for
6-freebsd-12 where I have removed the create-kernel-namespace.sh and replaced it
with a new python script.

> I ask because I see these externs in the template code ...
> 
> 
> extern struct usb_temp_device_desc usb_template_audio;
> extern struct usb_temp_device_desc usb_template_cdce;
> extern struct usb_temp_device_desc usb_template_kbd;
> extern struct usb_temp_device_desc usb_template_modem;
> extern struct usb_temp_device_desc usb_template_mouse;
> extern struct usb_temp_device_desc usb_template_msc;
> extern struct usb_temp_device_desc usb_template_mtp;
> extern struct usb_temp_device_desc usb_template_phone;
> extern struct usb_temp_device_desc usb_template_serialnet;
> extern struct usb_temp_device_desc usb_template_midi;
> extern struct usb_temp_device_desc usb_template_multi;
> extern struct usb_temp_device_desc usb_template_cdceem;
> 
> 
> These externs are for all the usb templates supported by freebsd.
> I only have imported the usb_template_cdce. Other templates are
> not imported yet. Shall I exclude them?

All good. I was more interested in the update process than the USB side of 
things :)

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

Re: [PATCH rtems-libbsd v2 0/5] Beagle BSP: USB Template Driver for CDC Ethernet

2021-08-08 Thread Chris Johns 
On 1/8/21 9:27 pm, Christian Mauderer wrote:
> Hello Husni,
> 
> just tested that and it works fine. With a simple curl I can reach about 8.5
> MByte/s sending to the beagle and 19.5 MByte/s receiving from it.
> 
> Please take a look at the points that Chris Johns asked. As soon as these are
> addressed, I think the patches could be merged.

Can these patches please wait until my patches are merged? I have not seen any
issues and given the size I am waiting a while.

I ask because the symbol changes in the namespace ripple through the 150K lines
of patches I have posted for review and it is a pain to rebase.

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

Re: [PATCH rtems-libbsd v2 0/5] Beagle BSP: USB Template Driver for CDC Ethernet

2021-08-08 Thread Chris Johns 
On 8/8/21 6:06 pm, Christian Mauderer wrote:
> Hello Husni,
> 
> On 07/08/2021 21:56, Ahamed Husni wrote:
>> Hi Christian,
>>
>> Are there any issues I should address in this patch set?
> 
> I think the big open question is the one from Chris:
> 
> https://lists.rtems.org/pipermail/devel/2021-July/068634.html
> 
> You mentioned that you filtered the ones for the imported code. That's OK for
> most symbols if they are not relevant for the part where you work on. But 
> Chris
> copied a whole block of "extern struct usb_temp_device_desc *". It's not clear
> for me whether you filtered some of them or whether they haven't been 
> generated.
> 
> If they are generated: Please keep them. Basically keep everything that is in
> one of the files that you touch, except if you have a good reason why the 
> symbol
> should _not_ be added.
> 
> If they are not generated: Please clearly say that.
> 

The issue is the merging against my changes and as I have stated in the other
thread I have replaced the change script because it on worked on Linux plus the
sort order was something I could not match on other host platforms.

My changes address the sort order, tools used and I added the few symbols that
must have been missed over a period of time. That happens. I hope the updated
procedure is simpler and safer to use on any host platform we support.

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

Re: [PATCH rtems-libbsd v2 0/5] Beagle BSP: USB Template Driver for CDC Ethernet

2021-08-08 Thread Chris Johns 
On 9/8/21 6:20 am, Christian Mauderer wrote:
> I think all open questions should be answered or did I miss one from your 
> side?
> If not I would like to push the patches.

As asked in another thread can they please wait?

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

[PATCH v4] Test needed for timer_create with CLOCK_MONOTONIC

2021-08-08 Thread Zacchaeus Leung 
the timer_create() method can use CLOCK_MONOTONIC but there was  no test for 
this. Also it implements the functionality to
create a CLOCK_MONOTONIC timer and gettime() .
Closes #3888
---
 cpukit/include/rtems/posix/timer.h|  1 +
 cpukit/posix/src/psxtimercreate.c |  3 +-
 cpukit/posix/src/timergettime.c   | 50 ---
 testsuites/psxtests/psxtimer02/psxtimer.c | 26 ++
 testsuites/psxtests/psxtimer02/psxtimer02.scn |  6 +++
 5 files changed, 66 insertions(+), 20 deletions(-)

diff --git a/cpukit/include/rtems/posix/timer.h 
b/cpukit/include/rtems/posix/timer.h
index bcbf07a65a..7ae089173a 100644
--- a/cpukit/include/rtems/posix/timer.h
+++ b/cpukit/include/rtems/posix/timer.h
@@ -48,6 +48,7 @@ typedef struct {
   uint32_t  ticks;  /* Number of ticks of the initialization */
   uint32_t  overrun;/* Number of expirations of the timer*/
   struct timespec   time;   /* Time at which the timer was started   */
+  clockid_t clock_type; /* The type of timer */
 } POSIX_Timer_Control;
 
 /**
diff --git a/cpukit/posix/src/psxtimercreate.c 
b/cpukit/posix/src/psxtimercreate.c
index a63cf1d100..2b5a10140f 100644
--- a/cpukit/posix/src/psxtimercreate.c
+++ b/cpukit/posix/src/psxtimercreate.c
@@ -40,7 +40,7 @@ int timer_create(
 {
   POSIX_Timer_Control *ptimer;
 
-  if ( clock_id != CLOCK_REALTIME )
+  if (  clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
 rtems_set_errno_and_return_minus_one( EINVAL );
 
   if ( !timerid )
@@ -91,6 +91,7 @@ int timer_create(
   ptimer->timer_data.it_value.tv_nsec= 0;
   ptimer->timer_data.it_interval.tv_sec  = 0;
   ptimer->timer_data.it_interval.tv_nsec = 0;
+  ptimer->clock_type = clock_id;
 
   _Watchdog_Preinitialize( &ptimer->Timer, _Per_CPU_Get_snapshot() );
   _Watchdog_Initialize( &ptimer->Timer, _POSIX_Timer_TSR );
diff --git a/cpukit/posix/src/timergettime.c b/cpukit/posix/src/timergettime.c
index ee2a566f0e..2ad841d517 100644
--- a/cpukit/posix/src/timergettime.c
+++ b/cpukit/posix/src/timergettime.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  *  - When a timer is initialized, the value of the time in
@@ -39,35 +40,46 @@
 int timer_gettime(
   timer_ttimerid,
   struct itimerspec *value
) 
 {
   POSIX_Timer_Control *ptimer;
-  ISR_lock_Context lock_context;
-  uint64_t now;
-  uint32_t remaining;
+  ISR_lock_Context lock_context;
+  Per_CPU_Control *cpu;
+  struct timespec now;
+  struct timespec expire;
+  struct timespec result;
 
   if ( !value )
 rtems_set_errno_and_return_minus_one( EINVAL );
 
   ptimer = _POSIX_Timer_Get( timerid, &lock_context );
-  if ( ptimer != NULL ) {
-Per_CPU_Control *cpu;
+  if ( ptimer == NULL ) {
+rtems_set_errno_and_return_minus_one( EINVAL );
+  }
 
-cpu = _POSIX_Timer_Acquire_critical( ptimer, &lock_context );
-now = cpu->Watchdog.ticks;
+  cpu = _POSIX_Timer_Acquire_critical( ptimer, &lock_context );
+  rtems_timespec_from_ticks( ptimer->Timer.expire, &expire );
 
-if ( now < ptimer->Timer.expire ) {
-  remaining = (uint32_t) ( ptimer->Timer.expire - now );
-} else {
-  remaining = 0;
-}
+  if ( ptimer->clock_type == CLOCK_MONOTONIC ) {
+  _Timecounter_Nanouptime(&now);
+  } else  if ( ptimer->clock_type == CLOCK_REALTIME ) {
+_TOD_Get(&now);
+  } else {
+  _POSIX_Timer_Release( cpu, &lock_context );   
+  rtems_set_errno_and_return_minus_one( EINVAL );
+  }
 
-_Timespec_From_ticks( remaining, &value->it_value );
-value->it_interval = ptimer->timer_data.it_interval;
 
-_POSIX_Timer_Release( cpu, &lock_context );
-return 0;
+ if ( rtems_timespec_less_than( &now, &expire ) ) {
+  rtems_timespec_subtract( &now, &expire, &result );
+  } else {
+  result.tv_nsec = 0;
+  result.tv_sec  = 0;
   }
-
-  rtems_set_errno_and_return_minus_one( EINVAL );
+  
+  value->it_value = result;
+  value->it_interval = ptimer->timer_data.it_interval;
+  
+  _POSIX_Timer_Release( cpu, &lock_context );
+  return 0;
 }
diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c 
b/testsuites/psxtests/psxtimer02/psxtimer.c
index 9f79d33c42..1a79369efb 100644
--- a/testsuites/psxtests/psxtimer02/psxtimer.c
+++ b/testsuites/psxtests/psxtimer02/psxtimer.c
@@ -126,6 +126,32 @@ void *POSIX_Init (
   puts( "timer_delete - bad id - EINVAL" );
   status = timer_delete( timer );
   fatal_posix_service_status_errno( status, EINVAL, "bad id" );
+  
+  puts( "timer_create (monotonic) - bad timer id pointer - EINVAL" );
+  status = timer_create( CLOCK_MONOTONIC, &event, NULL );
+  fatal_posix_service_status_errno( status, EINVAL, "bad timer id" );
+
+  puts( "timer_create (monotonic) - OK" );
+  status = timer_create( CLOCK_MONOTONIC, NULL, &timer );
+  posix_service_failed( status, "timer_create OK" );
+
+  puts( "timer_create (monotonic) - too many - EAGAIN" );
+  status = timer_create( CLOCK_MONOTONIC, NULL, &timer

LibBSD - bus space support for PC PCI devices

2021-08-08 Thread Chris Johns 
Hello,

These patches address 2 issues, PC PCI suport for non-Intel targets
and tests with static IP addresses faiing.

- PC PCI

BSPs like MVME2700 (MVME2307) have PC PCI devices with separate IO and
memory bus spaces mapped into separate address spaces. This requires
the BSP provides suitable remapping support. The PCI devices report relative
offsets and not absolute mappings. The support added is only enabled if
the BSP does this otherwise there is no change to existing BSPs and the
direct mappings the bus space support provides.

The bus space support has been cleaned up and a number of issues in some
of the support functions fixed. They must have not been used.

- Tests Waiting for Link UP

Tests that use the network test configured interface and have a static IP 
address did not wait for the link to be UP before starting the test. A DHCP 
client configuration would and simulators like QEMU did not simulate the 
time a PHY takes to come on line.

Add support to check if an interface has a valid and UP media link and
have tests wait for this to happen. I have added the support to 2 tests
and I am sure there other so please add the support when you find one.

Thanks
Chris


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

[PATCH rtems-libbsd v3 1/3] rtemsbsd/bus: Add PCI support to the nexus bus

2021-08-08 Thread Chris Johns 
- Add PCI IO region support

- Add support map buffers to PCI address space

- Add BSP conditional IO space support. Some PC implementations
  have PCI IO space mapped differently to memory space and this needs
  to be reflected in the busspace.

- Include bsp.h to pick per BSP configuration.

Closes #4245
---
 rtemsbsd/include/machine/bus.h| 370 ++
 rtemsbsd/rtems/rtems-kernel-bus-dma.c |   5 +-
 rtemsbsd/rtems/rtems-kernel-nexus.c   |  52 +++-
 3 files changed, 312 insertions(+), 115 deletions(-)

diff --git a/rtemsbsd/include/machine/bus.h b/rtemsbsd/include/machine/bus.h
index 2f0e7ad6..999f5d45 100644
--- a/rtemsbsd/include/machine/bus.h
+++ b/rtemsbsd/include/machine/bus.h
@@ -6,9 +6,13 @@
  * @brief TODO.
  *
  * File origin from FreeBSD 'sys/amd64/include/bus.h'.
+ *
+ * Conditionally supports PCI IO regions (IO Ports).
  */
 
 /*-
+ * Copyright (c) 2021 Chris Johns.  All rights reserved.
+ *
  * Copyright (c) 2009, 2015 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
@@ -25,7 +29,7 @@
  * 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 as
  *the first lines of this file unmodified.
@@ -34,7 +38,7 @@
  *documentation and/or other materials provided with the distribution.
  * 3. The name of the author may not be used to endorse or promote products
  *derived from this software without specific prior written permission.
- * 
+ *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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.
@@ -123,9 +127,46 @@
 #endif
 
 #ifdef __i386__
-  #error "your include paths are wrong"
+  #error "x86 has its own bus.h; check your include paths are correct"
 #endif
 
+#include 
+
+/*
+ * BSP PCI Support
+ *
+ * The RTEMS Nexus bus support can optionaly support PC PCI spaces that
+ * mapped to BSP speciic address spaces. Add the following define to
+ * the BSP header file to enable this support:
+ *
+ *  #define BSP_HAS_PC_PCI
+ *
+ * If enabled a BSP must the following IO region calls:
+ *
+ * inb  : read 8 bits
+ * outb : write 8 bits
+ * inw  : read 16 bits
+ * outw : write 16 bits
+ * inl  : read 32 bits
+ * outl : write 32 bits
+ *
+ * The BSP needs to provide the DRAM address space offset
+ * PCI_DRAM_OFFSET. This is the base address of the DRAM as seen by a
+ * PCI master.
+ *
+ * i386 BSPs have a special bus.h file and do not use this file.
+ */
+
+#ifdef BSP_HAS_PC_PCI
+
+/*
+ * Values for the bus space tag, not to be used directly by MI code.
+ */
+#defineBSP_BUS_SPACE_IO0   /* space is i/o space */
+#defineBSP_BUS_SPACE_MEM   1   /* space is mem space */
+
+#endif /* BSP_HAS_PC_PCI */
+
 /*
  * Bus address alignment.
  */
@@ -144,6 +185,7 @@
 /*
  * Bus access.
  */
+#define BUS_SPACE_INVALID_DATA (~0)
 #define BUS_SPACE_UNRESTRICTED (~0U)
 
 /*
@@ -222,6 +264,102 @@ bus_space_barrier(bus_space_tag_t bst __unused, 
bus_space_handle_t bsh, bus_size
/* Do nothing */
 }
 
+/*
+ * BSP Bus Space Map Support
+ *
+ * Provide as C macros in the BSP header (bsp.h) the following:
+ *
+ *  RTEMS_BSP_READ_1
+ *  RTEMS_BSP_READ_2
+ *  RTEMS_BSP_READ_4
+ *  RTEMS_BSP_READ_8
+ *  RTEMS_BSP_WRITE_1
+ *  RTEMS_BSP_WRITE_2
+ *  RTEMS_BSP_WRITE_4
+ *  RTEMS_BSP_WRITE_8
+ */
+
+static __inline uint8_t
+bsp_bus_space_read_1(const uint8_t __volatile *bsp)
+{
+#if defined(RTEMS_BSP_READ_1)
+   return RTEMS_BSP_READ_1(bsp);
+#else
+   return (*bsp);
+#endif
+}
+
+static __inline uint16_t
+bsp_bus_space_read_2(const uint16_t __volatile *bsp)
+{
+#if defined(RTEMS_BSP_READ_2)
+   return RTEMS_BSP_READ_2(bsp);
+#else
+   return (*bsp);
+#endif
+}
+
+static __inline uint32_t
+bsp_bus_space_read_4(const uint32_t __volatile *bsp)
+{
+#if defined(RTEMS_BSP_READ_4)
+   return RTEMS_BSP_READ_4(bsp);
+#else
+   return (*bsp);
+#endif
+}
+
+static __inline uint64_t
+bsp_bus_space_read_8(const uint64_t __volatile *bsp)
+{
+#if defined(RTEMS_BSP_READ_8)
+   return RTEMS_BSP_READ_8(bsp);
+#else
+   return (*bsp);
+#endif
+}
+
+static __inline void
+bsp_bus_space_write_1(uint8_t __volatile *bsp, uint8_t val)
+{
+#if defined(RTEMS_BSP_WRITE_1)
+   RTEMS_BSP_WRITE_1(bsp, val);
+#else
+   *bsp = val;
+#endif
+}
+
+static __inline void
+bsp_bus_space_write_2(uint16_t __volatile *bsp, uint16_t val)
+{
+#if defined(RTEMS_BSP_WRITE_2)
+   RTEMS_BSP_WRITE_2(bsp, val);
+#else
+   *bsp = val;
+#endif
+}
+
+static __inline void
+bsp_bus_space_write_4(uint32_t __volatile *bsp, uint32_t val)
+{
+#if defined(RTEMS_BSP_WRITE_4)
+   RTEMS_BSP_WRITE_4(bsp, val);
+#else
+   *bsp = v

[PATCH rtems-libbsd v3 2/3] rtemsbsd: Add interface support routines

2021-08-08 Thread Chris Johns 
- Add the ability to check if an interface is up
---
 libbsd.py  |   1 +
 rtemsbsd/include/rtems/bsd/iface.h |  62 
 rtemsbsd/rtems/rtems-bsd-iface.c   | 146 +
 3 files changed, 209 insertions(+)
 create mode 100644 rtemsbsd/include/rtems/bsd/iface.h
 create mode 100644 rtemsbsd/rtems/rtems-bsd-iface.c

diff --git a/libbsd.py b/libbsd.py
index 09a1fbc4..6e09a07c 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -253,6 +253,7 @@ class rtems(builder.Module):
 'rtems/rtems-bsd-cxx.cc',
 'rtems/rtems-bsd-get-ethernet-addr.c',
 'rtems/rtems-bsd-ifconfig.c',
+'rtems/rtems-bsd-iface.c',
 'rtems/rtems-bsd-ifconfig-lo0.c',
 'rtems/rtems-bsd-init-dhcp.c',
 'rtems/rtems-bsd-rc-conf-net.c',
diff --git a/rtemsbsd/include/rtems/bsd/iface.h 
b/rtemsbsd/include/rtems/bsd/iface.h
new file mode 100644
index ..9e583b8a
--- /dev/null
+++ b/rtemsbsd/include/rtems/bsd/iface.h
@@ -0,0 +1,62 @@
+/**
+ * @file
+ *
+ * @ingroup rtems_bsd_rtems
+ *
+ * @brief This file provide a high level interface to simple interface
+ * support calls.
+ */
+
+/*
+ * Copyright (c) 2021. Chris Johns . All rights reserved.
+ *
+ * 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 AUTHOR 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 AUTHOR 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 _RTEMS_BSD_IFACE_H_
+#define _RTEMS_BSD_IFACE_H_
+
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+struct rtems_bsd_iface {
+   char name[IFNAMSIZ];
+   int unit;
+   struct in_addr address;
+   size_t hw_len;
+   uint8_t hw_address[16];
+   struct ifreq ifr;
+   int linkstate;
+};
+
+/*
+ * These calls return 0 is successful and -1 and errno set on error.
+ */
+int rtems_bsd_iface_get(const char *name, struct rtems_bsd_iface *iface);
+int rtems_bsd_iface_link_state(const char *name, bool *state);
+
+#endif
diff --git a/rtemsbsd/rtems/rtems-bsd-iface.c b/rtemsbsd/rtems/rtems-bsd-iface.c
new file mode 100644
index ..4cf25a9b
--- /dev/null
+++ b/rtemsbsd/rtems/rtems-bsd-iface.c
@@ -0,0 +1,146 @@
+/**
+ * @file
+ *
+ * @ingroup rtems_bsd_rtems
+ *
+ * @brief Interface support routines
+ */
+
+/*
+ * Copyright (c) 2021. Chris Johns   All rights reserved.
+ *
+ * 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 AUTHOR 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 AUTHOR 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.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#if !defined(RTEMS_BSD_IFACE_TRACE)
+#define RTEMS_BSD_IFACE_TRACE 0
+#endif
+
+int
+rtems_bsd_iface_

[PATCH rtems-libbsd v3 3/3] testsuite: Wait for the link to be UP

2021-08-08 Thread Chris Johns 
- Wait for a slow PHY to bring the link UP. If the IP address is
  static the test can start before the link is up and the test
  fails.

- Make 2 tests wait. Others will need to be added.
---
 .../include/rtems/bsd/test/default-init.h | 29 +++
 .../rtems/bsd/test/default-network-init.h | 28 ++
 testsuite/nfs01/test_main.c   |  1 +
 testsuite/ping01/test_main.c  |  1 +
 4 files changed, 59 insertions(+)

diff --git a/testsuite/include/rtems/bsd/test/default-init.h 
b/testsuite/include/rtems/bsd/test/default-init.h
index f8ea3acd..ea502f94 100644
--- a/testsuite/include/rtems/bsd/test/default-init.h
+++ b/testsuite/include/rtems/bsd/test/default-init.h
@@ -9,11 +9,31 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
 #include 
 
+static void default_wait_for_link_up( const char *name )
+{
+  size_t seconds = 0;
+  while ( true ) {
+bool link_active = false;
+assert(rtems_bsd_iface_link_state( name, &link_active ) == 0);
+if (link_active) {
+  return;
+}
+sleep( 1 );
+++seconds;
+if (seconds > 10) {
+  printf("error: %s: no active link\n", name);
+  assert(seconds < 10);
+}
+  }
+}
+
 static void default_set_self_prio( rtems_task_priority prio )
 {
   rtems_status_code sc;
@@ -68,6 +88,15 @@ rtems_task Init(
   sc = rtems_task_wake_after( 2 );
   assert(sc == RTEMS_SUCCESSFUL);
 
+#if defined(TEST_WAIT_FOR_LINK)
+  /*
+   * Per test option to wait for the network interface. If the address
+   * is static the PHY may take a while to connect and bring the
+   * interface online.
+   */
+  default_wait_for_link_up( TEST_WAIT_FOR_LINK );
+#endif
+
   test_main();
   /* should not return */
 
diff --git a/testsuite/include/rtems/bsd/test/default-network-init.h 
b/testsuite/include/rtems/bsd/test/default-network-init.h
index ce1fc015..ba995910 100644
--- a/testsuite/include/rtems/bsd/test/default-network-init.h
+++ b/testsuite/include/rtems/bsd/test/default-network-init.h
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -175,6 +176,25 @@ default_network_on_exit(int exit_code, void *arg)
}
 }
 
+static void
+default_wait_for_link_up( const char *name )
+{
+   size_t seconds = 0;
+   while ( true ) {
+   bool link_active = false;
+   assert(rtems_bsd_iface_link_state( name, &link_active ) == 0);
+   if (link_active) {
+   return;
+   }
+   sleep( 1 );
+   ++seconds;
+   if (seconds > 10) {
+   printf("error: %s: no active link\n", name);
+   assert(seconds < 10);
+   }
+   }
+}
+
 static void
 Init(rtems_task_argument arg)
 {
@@ -238,6 +258,14 @@ Init(rtems_task_argument arg)
 #endif
default_network_dhcpcd();
 
+#if defined(TEST_WAIT_FOR_LINK)
+   /*
+* Per test option to wait for the network interface. If the address
+* is static the PHY may take a while to connect and bring the
+* interface online.
+*/
+   default_wait_for_link_up( TEST_WAIT_FOR_LINK );
+#endif
test_main();
 
assert(0);
diff --git a/testsuite/nfs01/test_main.c b/testsuite/nfs01/test_main.c
index 2312040a..170cd484 100644
--- a/testsuite/nfs01/test_main.c
+++ b/testsuite/nfs01/test_main.c
@@ -46,6 +46,7 @@
 #include 
 
 #define TEST_NAME "LIBBSD NFS 1"
+#define TEST_WAIT_FOR_LINK NET_CFG_INTERFACE_0
 #define TEST_STATE_USER_INPUT 1
 
 static void
diff --git a/testsuite/ping01/test_main.c b/testsuite/ping01/test_main.c
index 5702cee2..8b9a42ce 100644
--- a/testsuite/ping01/test_main.c
+++ b/testsuite/ping01/test_main.c
@@ -46,6 +46,7 @@
 #include 
 
 #define TEST_NAME "LIBBSD PING 1"
+#define TEST_WAIT_FOR_LINK NET_CFG_INTERFACE_0
 
 static void
 test_ping(void)
-- 
2.24.1

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