from:"Ahamed Husni"

Re: GSOC 2021: USB Device Drivers - Beaglebone Black

2021-08-11 Thread Ahamed Husni

Hello Kevin,

I'm working on porting the CDC Serial device driver to beagle.
(RTEMS is the device and Linux as host)
I see you have ported USB Serial drivers some time back.
I hope that you can help me clear my doubts.

In your case how did you use a USB Serial adapter and how did you start a
shell
on that device?
Do USB Serial adapters need special handling?

I used the umodem driver with the usb modem template.
Isn't umodem for host and device?

Linux host: sees a ttyACM0 and serial programs can open it.
RTEMS device: ttyU0 and cuaU0 devices are created. (But can't communicate.)
ttyU0.lock, ttyU0.init, cuaU0, ... files are also there.
What do these files do?

Github branch: https://github.com/drac98/rtems-libbsd/commits/usb-serial

If someone can help me out with any clue that'll be really helpful.

Best regards,
Husni.

On Sat, Jul 24, 2021 at 3:32 PM Ahamed Husni 
wrote:

> Hi all,
>
> In phase one of the GSoC I ported the usb template driver and the CDC
> Ethernet template (Template for Ethernet over USB) to the RTEMS LibBSD. The
> driver was tested in the 6-freebsd-12 and the master branch. I have
> prepared a report for phase one.
> https://drac98.github.io/2021/07/13/gsoc-2021-mid-report.html
>
> RTEMS LibBSD doesn't have any documentation in the RTEMS Documentation
> Project. So I documented the driver by creating a frame for the LibBSD.
> Please have a look and give me your feedback.
> https://github.com/drac98/rtems-docs/commits/libbsd
>
> I'm working on TTCP benchmarking for the USB Ethernet.
>
> For phase two first I'll port the USB Serial template.
>
> Thank you,
> Husni.
>
___
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 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  > <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
> > <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
> >  >  > <mailto:christian.maude...@embedded-brains.de>
> >  > <mailto:christian.maude...@embedded-brains.de
> > <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>
> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> >  >  > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> > <mailto:o...@c-mauderer.de <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

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
> >  > <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>
> >  > <mailto:o...@c-mauderer.de <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
> > <https://github.com/drac98/rtems-libbsd/commits/usb-cdce>
> >  > <https://github.com/drac98/rtems-libbsd/commits/usb-cdce
> > <https://github.com/drac98/rtems-libbsd/commits/usb-cdce>>
> >  >  >
> >  >  > Patch for 6-freebsd-12 branch
> >  >  > https://github.com/drac98/rtems-libbsd/commits/usb-cdce12
> > <https://github.com/drac98/rtems-libbsd/commits/usb-cdce12>
> >  > <https://github.com/drac98/rtems-libbsd/commits/usb-cdce12
> > <https://github.com/drac98/rtems-libbsd/commits/usb-cdce12>>
> >  >

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

2021-08-07 Thread Ahamed Husni

Hi Christian,

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

On Mon, Aug 2, 2021 at 12:09 PM Christian MAUDERER <
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>> 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
> > <https://github.com/drac98/rtems-libbsd/commits/usb-cdce>
> >  >
> >  > Patch for 6-freebsd-12 branch
> >  > https://github.com/drac98/rtems-libbsd/commits/usb-cdce12
> > <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 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 0/5] RTEMS LibBSD Documentation

2021-08-01 Thread Ahamed Husni

Github repo
https://github.com/drac98/rtems-docs/commits/libbsd

On Mon, Aug 2, 2021 at 12:56 AM Husni Faiz  wrote:

> The RTEMS LibBSD doesn't have a documentation in the RTEMS Documentation
> Project.
> As I'm currently porting USB device drivers to LibBSD I decided to
> document the drivers I port in the rtems-docs.
>
> In this patch set I have added a quick-start guide and the USB template
> driver documentation.
>
> Husni Faiz (5):
>   libbsd: Quick Start Guide for RTEMS LibBSD
>   libbsd: Index for LibBSD Doc
>   libbsd: Add conf.py and wscript for the libbsd doc.
>   wscript: Enable build for  LibBSD Doc
>   libbsd: USB Template Driver Documentation
>
>  libbsd/conf.py   | 14 +++
>  libbsd/device_driver.rst | 30 +++
>  libbsd/index.rst | 24 +++
>  libbsd/introduction.rst  |  8 +++
>  libbsd/quick_start.rst   | 51 
>  libbsd/wscript   |  7 ++
>  wscript  |  3 ++-
>  7 files changed, 136 insertions(+), 1 deletion(-)
>  create mode 100644 libbsd/conf.py
>  create mode 100644 libbsd/device_driver.rst
>  create mode 100644 libbsd/index.rst
>  create mode 100644 libbsd/introduction.rst
>  create mode 100644 libbsd/quick_start.rst
>  create mode 100644 libbsd/wscript
>
> --
> 2.25.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd v2 4/5] libbsd.py: add usb template files

2021-08-01 Thread Ahamed Husni

I don't get notified of the replies to my patch. Not sure why.
Replies don't go to spam either. That's why my replies are late.
I added the rtems.org to the whitelist. I hope next time I'll get notified
;)

On Thu, Jul 29, 2021 at 5:38 AM Chris Johns  wrote:

> On 28/7/21 9:56 pm, Husni Faiz wrote:
> > add the imported template files for CDC Ethernet
> > register the dev_usb_template module
> > enable usb template in default buildset
> >
> > Signed-off-by: Husni Faiz 
> > ---
> >  buildset/default.ini |  1 +
> >  buildset/minimal.ini |  3 ++-
> >  libbsd.py| 25 +
> >  3 files changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/buildset/default.ini b/buildset/default.ini
> > index 472c535d..117bacc3 100644
> > --- a/buildset/default.ini
> > +++ b/buildset/default.ini
> > @@ -34,6 +34,7 @@ dev_usb_net = on
> >  dev_usb_quirk = on
> >  dev_usb_serial = on
> >  dev_usb_storage = on
> > +dev_usb_template = on
> >  dev_usb_wlan = off
> >  dev_wlan_rtwn = off
> >  iic = on
> > diff --git a/buildset/minimal.ini b/buildset/minimal.ini
> > index 03dd96bb..060b1930 100644
> > --- a/buildset/minimal.ini
> > +++ b/buildset/minimal.ini
> > @@ -19,5 +19,6 @@ extends = default.ini
> >
> >  [modules]
> >  crypto_openssl = off
> > +dev_usb_template = off
> >  netinet6 = off
> > -usr_bin_openssl = off
> > +usr_bin_openssl = off
> > \ No newline at end of file
>
> What happened here?
>
> That's auto generated by the git format-patch. I don't see it in my files.
(Not sure why but Github-like services seem to use that to show the end of
the file icon.
I assume they might get ignored when applying the patches.)

Chris
>
> > diff --git a/libbsd.py b/libbsd.py
> > index c9151901..049ec7f8 100644
> > --- a/libbsd.py
> > +++ b/libbsd.py
> > @@ -1162,6 +1162,30 @@ class dev_usb_storage(builder.Module):
> >  mm.generator['source']()
> >  )
> >
> > +#
> > +# USB Template
> > +#
> > +class dev_usb_template(builder.Module):
> > +
> > +def __init__(self, manager):
> > +super(dev_usb_template, self).__init__(manager,
> type(self).__name__)
> > +
> > +def generate(self):
> > +mm = self.manager
> > +self.addDependency('dev_usb')
> > +self.addKernelSpaceHeaderFiles(
> > +[
> > +'sys/dev/usb/template/usb_template.h',
> > +]
> > +)
> > +self.addKernelSpaceSourceFiles(
> > +[
> > +'sys/dev/usb/template/usb_template.c',
> > +'sys/dev/usb/template/usb_template_cdce.c',
> > +],
> > +mm.generator['source']()
> > +)
> > +
> >  #
> >  # BBB USB
> >  #
> > @@ -5480,6 +5504,7 @@ def load(mm):
> >
> >  mm.addModule(cam(mm))
> >  mm.addModule(dev_usb_storage(mm))
> > +mm.addModule(dev_usb_template(mm))
> >  mm.addModule(dev_usb_controller_bbb(mm))
> >
> >  mm.addModule(net(mm))
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2021-08-01 Thread Ahamed Husni

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.


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

Regards,
Husni.

>
> 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-01 Thread Ahamed Husni

Hi Christian,

On Sun, Aug 1, 2021 at 4:57 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.
>
> That's 68 Mbps for sending. That's an acceptable speed isn't 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.
>
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

Re: [PATCH rtems-libbsd v2 2/5] usb_template: Configure template driver only for CDC Ethernet

2021-08-01 Thread Ahamed Husni

Hello Chris,

Sorry for the late reply.

On Thu, Jul 29, 2021 at 5:37 AM Chris Johns  wrote:

> On 29/7/21 1:10 am, Ahamed Husni wrote:
> >
> >
> > On Wed, 28 Jul 2021, 17:27 Husni Faiz,  > <mailto:ahamedhusn...@gmail.com>> wrote:
> >
> > Add the conditional macro to prevent the driver from referencing
> > the templates which are not imported yet.
> >
> > Include functions which adds the hw.usb.template sysctl variable.
> >
> > Signed-off-by: Husni Faiz  > <mailto:ahamedhusn...@gmail.com>>
> > ---
> >  freebsd/sys/dev/usb/template/usb_template.c | 4 
> >  freebsd/sys/dev/usb/usb_device.c| 8 ++--
> >  2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/freebsd/sys/dev/usb/template/usb_template.c
> > b/freebsd/sys/dev/usb/template/usb_template.c
> > index 0650da15..76567e85 100644
> > --- a/freebsd/sys/dev/usb/template/usb_template.c
> > +++ b/freebsd/sys/dev/usb/template/usb_template.c
> > @@ -1433,12 +1433,15 @@ usb_temp_setup_by_index(struct usb_device
> *udev,
> > uint16_t index)
> > usb_error_t err;
> >
> > switch (index) {
> > +#ifndef __rtems__
> > case USB_TEMP_MSC:
> > err = usb_temp_setup(udev, _template_msc);
> > break;
> > +#endif /* __rtems__ */
> > case USB_TEMP_CDCE:
> > err = usb_temp_setup(udev, _template_cdce);
> > break;
> > +#ifndef __rtems__
> > case USB_TEMP_MTP:
> > err = usb_temp_setup(udev, _template_mtp);
> > break;
> > @@ -1469,6 +1472,7 @@ usb_temp_setup_by_index(struct usb_device
> *udev,
> > uint16_t index)
> > case USB_TEMP_CDCEEM:
> > err = usb_temp_setup(udev, _template_cdceem);
> > break;
> > +#endif /* __rtems__ */
> > default:
> > return (USB_ERR_INVAL);
> > }
> > diff --git a/freebsd/sys/dev/usb/usb_device.c
> b/freebsd/sys/dev/usb/usb_device.c
> > index ee240949..619cae5a 100644
> > --- a/freebsd/sys/dev/usb/usb_device.c
> > +++ b/freebsd/sys/dev/usb/usb_device.c
> > @@ -28,6 +28,10 @@
> >   * SUCH DAMAGE.
> >   */
> >
> > +#ifdef __rtems__
> > +#include 
> > +#endif
> > +
> >  #ifdef USB_GLOBAL_INCLUDE_FILE
> >  #include USB_GLOBAL_INCLUDE_FILE
> >  #else
> > @@ -123,7 +127,7 @@ int usb_template = USB_TEMPLATE;
> >  intusb_template = -1;
> >  #endif
> >
> > -#ifndef __rtems__
> > +#if !defined(__rtems__) ||
> defined(RTEMS_BSD_MODULE_DEV_USB_TEMPLATE)
>
> Is doing this supported by the freebsd-to-rtems.py script?
>
> Like Christian pointed out, similar definitions are used in the libbsd.
I'm not exactly sure how the script works under the hood. I'm thinking the
script uses only the __rtems__
to find differences.
When I run the script in the reverse mode the new changes get applied to
the freebsd-org.
So I assume that works. Isn't it?


> Why is the RTEMS_BSD_MODULE_DEV_USB_TEMPLATE needed?
>

The functions inside the guard seem to be only used by the USB Template
driver.
Since I added that.


>  SYSCTL_PROC(_hw_usb, OID_AUTO, template,
> >  CTLTYPE_INT | CTLFLAG_RWTUN | CTLFLAG_MPSAFE,
> >  NULL, 0, sysctl_hw_usb_template,
> > @@ -255,7 +259,7 @@ sysctl_hw_usb_template(SYSCTL_HANDLER_ARGS)
> >
> > return (0);
> >  }
> > -#endif /* __rtems__ */
> > +#endif /* !__rtmes__ || RTEMS_BSD_MODULE_DEV_USB_TEMPLATE */
> >
> > Ah, a typo here (rtmes). Should I send a new set of patches?
>
> Yes it needs to be correct for the script to work but I would check the
> freebsd-to-rtems.py script works with these guard comments.
>
> Does the script use the comments?
The script works with this guard (and with the typo).

Best regards,
Husni.

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

Re: [PATCH rtems-libbsd v2 2/5] usb_template: Configure template driver only for CDC Ethernet

2021-07-28 Thread Ahamed Husni

On Wed, 28 Jul 2021, 17:27 Husni Faiz,  wrote:

> Add the conditional macro to prevent the driver from referencing
> the templates which are not imported yet.
>
> Include functions which adds the hw.usb.template sysctl variable.
>
> Signed-off-by: Husni Faiz 
> ---
>  freebsd/sys/dev/usb/template/usb_template.c | 4 
>  freebsd/sys/dev/usb/usb_device.c| 8 ++--
>  2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/freebsd/sys/dev/usb/template/usb_template.c
> b/freebsd/sys/dev/usb/template/usb_template.c
> index 0650da15..76567e85 100644
> --- a/freebsd/sys/dev/usb/template/usb_template.c
> +++ b/freebsd/sys/dev/usb/template/usb_template.c
> @@ -1433,12 +1433,15 @@ usb_temp_setup_by_index(struct usb_device *udev,
> uint16_t index)
> usb_error_t err;
>
> switch (index) {
> +#ifndef __rtems__
> case USB_TEMP_MSC:
> err = usb_temp_setup(udev, _template_msc);
> break;
> +#endif /* __rtems__ */
> case USB_TEMP_CDCE:
> err = usb_temp_setup(udev, _template_cdce);
> break;
> +#ifndef __rtems__
> case USB_TEMP_MTP:
> err = usb_temp_setup(udev, _template_mtp);
> break;
> @@ -1469,6 +1472,7 @@ usb_temp_setup_by_index(struct usb_device *udev,
> uint16_t index)
> case USB_TEMP_CDCEEM:
> err = usb_temp_setup(udev, _template_cdceem);
> break;
> +#endif /* __rtems__ */
> default:
> return (USB_ERR_INVAL);
> }
> diff --git a/freebsd/sys/dev/usb/usb_device.c
> b/freebsd/sys/dev/usb/usb_device.c
> index ee240949..619cae5a 100644
> --- a/freebsd/sys/dev/usb/usb_device.c
> +++ b/freebsd/sys/dev/usb/usb_device.c
> @@ -28,6 +28,10 @@
>   * SUCH DAMAGE.
>   */
>
> +#ifdef __rtems__
> +#include 
> +#endif
> +
>  #ifdef USB_GLOBAL_INCLUDE_FILE
>  #include USB_GLOBAL_INCLUDE_FILE
>  #else
> @@ -123,7 +127,7 @@ int usb_template = USB_TEMPLATE;
>  intusb_template = -1;
>  #endif
>
> -#ifndef __rtems__
> +#if !defined(__rtems__) || defined(RTEMS_BSD_MODULE_DEV_USB_TEMPLATE)
>  SYSCTL_PROC(_hw_usb, OID_AUTO, template,
>  CTLTYPE_INT | CTLFLAG_RWTUN | CTLFLAG_MPSAFE,
>  NULL, 0, sysctl_hw_usb_template,
> @@ -255,7 +259,7 @@ sysctl_hw_usb_template(SYSCTL_HANDLER_ARGS)
>
> return (0);
>  }
> -#endif /* __rtems__ */
> +#endif /* !__rtmes__ || RTEMS_BSD_MODULE_DEV_USB_TEMPLATE */
>
Ah, a typo here (rtmes). Should I send a new set of patches?

>
>  /* English is default language */
>
> --
> 2.25.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 2/4] usb_template: Configure template driver only for CDC Ethernet

2021-07-28 Thread Ahamed Husni

Hello Christian,

On Fri, Jul 16, 2021 at 1:18 AM Christian Mauderer 
wrote:

> Hello Husni,
>
> On 06/07/2021 19:00, Husni Faiz wrote:
> > Add the conditional macro to prevent the driver from referencing
> > the templates which are not imported yet.
> >
> > Include functions which adds the hw.usb.template sysctl variable.
> >
> > Signed-off-by: Husni Faiz 
> > ---
> >   freebsd/sys/dev/usb/template/usb_template.c | 4 
> >   freebsd/sys/dev/usb/usb_device.c| 4 ++--
> >   2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/freebsd/sys/dev/usb/template/usb_template.c
> b/freebsd/sys/dev/usb/template/usb_template.c
> > index 0650da15..fe90d5b7 100644
> > --- a/freebsd/sys/dev/usb/template/usb_template.c
> > +++ b/freebsd/sys/dev/usb/template/usb_template.c
> > @@ -1433,12 +1433,15 @@ usb_temp_setup_by_index(struct usb_device *udev,
> uint16_t index)
> >   usb_error_t err;
> >
> >   switch (index) {
> > +#ifndef __rtems__
> >   case USB_TEMP_MSC:
> >   err = usb_temp_setup(udev, _template_msc);
> >   break;
> > +#endif
> >   case USB_TEMP_CDCE:
> >   err = usb_temp_setup(udev, _template_cdce);
> >   break;
> > +#ifndef __rtems__
> >   case USB_TEMP_MTP:
> >   err = usb_temp_setup(udev, _template_mtp);
> >   break;
> > @@ -1469,6 +1472,7 @@ usb_temp_setup_by_index(struct usb_device *udev,
> uint16_t index)
> >   case USB_TEMP_CDCEEM:
> >   err = usb_temp_setup(udev, _template_cdceem);
> >   break;
> > +#endif
> >   default:
> >   return (USB_ERR_INVAL);
> >   }
> > diff --git a/freebsd/sys/dev/usb/usb_device.c
> b/freebsd/sys/dev/usb/usb_device.c
> > index ee240949..28ef1b74 100644
> > --- a/freebsd/sys/dev/usb/usb_device.c
> > +++ b/freebsd/sys/dev/usb/usb_device.c
> > @@ -123,7 +123,7 @@ int   usb_template = USB_TEMPLATE;
> >   int usb_template = -1;
> >   #endif
> >
> > -#ifndef __rtems__
> > +#if !defined(__rtems__) || defined(RTEMS_BSD_MODULE_DEV_USB_TEMPLATE)
>
> Shouldn't there be an include for the rtems/bsd/modules.h somewhere if
> you use the RTEMS_BSD_MODULE_DEV_USB_TEMPLATE define?
>
> Fixed in Patch v2

>   SYSCTL_PROC(_hw_usb, OID_AUTO, template,
> >   CTLTYPE_INT | CTLFLAG_RWTUN | CTLFLAG_MPSAFE,
> >   NULL, 0, sysctl_hw_usb_template,
> > @@ -255,7 +255,7 @@ sysctl_hw_usb_template(SYSCTL_HANDLER_ARGS)
> >
> >   return (0);
> >   }
> > -#endif /* __rtems__ */
> > +#endif /* !__rtmes__ || RTEMS_BSD_MODULE_DEV_USB_TEMPLATE */
> >
> >   /* English is default language */
> >
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 3/4] nexus-devices: Include CDC Ethernet for Beagle

2021-07-27 Thread Ahamed Husni

Hello Christian,

On Wed, Jul 28, 2021 at 12:34 AM Christian Mauderer 
wrote:

> Hello Husni,
>
> On 27/07/2021 17:04, Ahamed Husni wrote:
> >
> >
> > On Fri, Jul 16, 2021 at 1:25 AM Christian Mauderer  > <mailto:o...@c-mauderer.de>> wrote:
> >
> > On 06/07/2021 19:00, Husni Faiz wrote:
> >  > Configure bus for CDC Ethernet
> >  > Include CDC Ethernet in Beagle BSP
> >  >
> >  > Signed-off-by: Husni Faiz  > <mailto:ahamedhusn...@gmail.com>>
> >  > ---
> >  >   rtemsbsd/include/bsp/nexus-devices.h   |  5 +
> >  >   rtemsbsd/include/machine/rtems-bsd-nexus-bus.h | 17
> > +
> >  >   2 files changed, 22 insertions(+)
> >  >
> >  > diff --git a/rtemsbsd/include/bsp/nexus-devices.h
> > b/rtemsbsd/include/bsp/nexus-devices.h
> >  > index e6487470..6a35632e 100644
> >  > --- a/rtemsbsd/include/bsp/nexus-devices.h
> >  > +++ b/rtemsbsd/include/bsp/nexus-devices.h
> >  > @@ -83,6 +83,11 @@ SYSINIT_REFERENCE(rtwn_rtl8188eufw);
> >  >   RTEMS_BSD_DRIVER_USB;
> >  >   RTEMS_BSD_DRIVER_USB_MASS;
> >  >
> >  > +#ifdef RTEMS_BSD_MODULE_DEV_USB_TEMPLATE
> >  > +RTEMS_BSD_DRIVER_USB_TEMPLATE;
> >  > +RTEMS_BSD_DRIVER_CDCE;
> >  > +#endif
> >  > +
> >
> > Same like in patch 2: Shouldn't there be an include for
> > rtems/bsd/modules.h somewhere?
> >
> > I checked the nexus-devices.h and it already has the modules.h included.
>
> Sorry. Might have missed that that include in nexus-devices.h. But For
> patch 2 it is still necessary, isn't it?
>
> I manually removed the  RTEMS_BSD_MODULE_DEV_USB_TEMPLATE
from the modules.h file and rebuilt the libbsd and looked for the symbols
to
see if they are included. The symbols weren't there as expected.

So I thought that the rtems/bsd/modules.h is included in the usb_devices.c
indirectly.
I couldn't track down where it came from. So I might be wrong.

Shall I include the rtems/bsd/modules.h the PATCH V2?

>
> >  >   #elif defined(LIBBSP_ARM_LPC32XX_BSP_H)
> >  >
> >  >   #include 
> >  > diff --git a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> > b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> >  > index 50a43873..84f561f5 100644
> >  > --- a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> >  > +++ b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> >  > @@ -282,6 +282,15 @@ extern "C" {
> >  >   SYSINIT_DRIVER_REFERENCE(umass, uhub)
> >  >   #endif /* RTEMS_BSD_DRIVER_USB_MASS */
> >  >
> >  > +/*
> >  > + * USB Template base driver.
> >  > + */
> >  > +#if !defined(RTEMS_BSD_DRIVER_USB_TEMPLATE)
> >  > +  #define RTEMS_BSD_DRIVER_USB_TEMPLATE   \
> >  > +SYSINIT_REFERENCE(usb_temp_init); \
> >  > +SYSINIT_DRIVER_REFERENCE(usb_template, usb)
> >  > +#endif /* RTEMS_BSD_DRIVER_USB_TEMPLATE */
> >  > +
> >  >   /*
> >  >* USB SAF1761 host controller driver.
> >  >*/
> >  > @@ -490,6 +499,14 @@ extern "C" {
> >  >   SYSINIT_DRIVER_REFERENCE(re, pci);
> >  >   #endif /* RTEMS_BSD_DRIVER_PCI_RE */
> >  >
> >  > +/*
> >  > + * CDC Ethernet Driver.
> >  > + */
> >  > +#if !defined(RTEMS_BSD_DRIVER_CDCE)
> >  > +  #define RTEMS_BSD_DRIVER_CDCE   \
> >  > +SYSINIT_DRIVER_REFERENCE(cdce, uhub);
> >  > +#endif /* RTEMS_BSD_DRIVER_FEC */
> >  > +
> >  >   /**
> >  >** MMI Physical Layer Support.
> >  >**/
> >  >
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 3/4] nexus-devices: Include CDC Ethernet for Beagle

2021-07-27 Thread Ahamed Husni

On Fri, Jul 16, 2021 at 1:25 AM Christian Mauderer 
wrote:

> On 06/07/2021 19:00, Husni Faiz wrote:
> > Configure bus for CDC Ethernet
> > Include CDC Ethernet in Beagle BSP
> >
> > Signed-off-by: Husni Faiz 
> > ---
> >   rtemsbsd/include/bsp/nexus-devices.h   |  5 +
> >   rtemsbsd/include/machine/rtems-bsd-nexus-bus.h | 17 +
> >   2 files changed, 22 insertions(+)
> >
> > diff --git a/rtemsbsd/include/bsp/nexus-devices.h
> b/rtemsbsd/include/bsp/nexus-devices.h
> > index e6487470..6a35632e 100644
> > --- a/rtemsbsd/include/bsp/nexus-devices.h
> > +++ b/rtemsbsd/include/bsp/nexus-devices.h
> > @@ -83,6 +83,11 @@ SYSINIT_REFERENCE(rtwn_rtl8188eufw);
> >   RTEMS_BSD_DRIVER_USB;
> >   RTEMS_BSD_DRIVER_USB_MASS;
> >
> > +#ifdef RTEMS_BSD_MODULE_DEV_USB_TEMPLATE
> > +RTEMS_BSD_DRIVER_USB_TEMPLATE;
> > +RTEMS_BSD_DRIVER_CDCE;
> > +#endif
> > +
>
> Same like in patch 2: Shouldn't there be an include for
> rtems/bsd/modules.h somewhere?
>
> I checked the nexus-devices.h and it already has the modules.h included.

>   #elif defined(LIBBSP_ARM_LPC32XX_BSP_H)
> >
> >   #include 
> > diff --git a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> > index 50a43873..84f561f5 100644
> > --- a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> > +++ b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> > @@ -282,6 +282,15 @@ extern "C" {
> >   SYSINIT_DRIVER_REFERENCE(umass, uhub)
> >   #endif /* RTEMS_BSD_DRIVER_USB_MASS */
> >
> > +/*
> > + * USB Template base driver.
> > + */
> > +#if !defined(RTEMS_BSD_DRIVER_USB_TEMPLATE)
> > +  #define RTEMS_BSD_DRIVER_USB_TEMPLATE   \
> > +SYSINIT_REFERENCE(usb_temp_init); \
> > +SYSINIT_DRIVER_REFERENCE(usb_template, usb)
> > +#endif /* RTEMS_BSD_DRIVER_USB_TEMPLATE */
> > +
> >   /*
> >* USB SAF1761 host controller driver.
> >*/
> > @@ -490,6 +499,14 @@ extern "C" {
> >   SYSINIT_DRIVER_REFERENCE(re, pci);
> >   #endif /* RTEMS_BSD_DRIVER_PCI_RE */
> >
> > +/*
> > + * CDC Ethernet Driver.
> > + */
> > +#if !defined(RTEMS_BSD_DRIVER_CDCE)
> > +  #define RTEMS_BSD_DRIVER_CDCE   \
> > +SYSINIT_DRIVER_REFERENCE(cdce, uhub);
> > +#endif /* RTEMS_BSD_DRIVER_FEC */
> > +
> >   /**
> >** MMI Physical Layer Support.
> >**/
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC 2021: USB Device Drivers - Beaglebone Black

2021-07-24 Thread Ahamed Husni

Hi all,

In phase one of the GSoC I ported the usb template driver and the CDC
Ethernet template (Template for Ethernet over USB) to the RTEMS LibBSD. The
driver was tested in the 6-freebsd-12 and the master branch. I have
prepared a report for phase one.
https://drac98.github.io/2021/07/13/gsoc-2021-mid-report.html

RTEMS LibBSD doesn't have any documentation in the RTEMS Documentation
Project. So I documented the driver by creating a frame for the LibBSD.
Please have a look and give me your feedback.
https://github.com/drac98/rtems-docs/commits/libbsd

I'm working on TTCP benchmarking for the USB Ethernet.

For phase two first I'll port the USB Serial template.

Thank you,
Husni.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2021-07-14 Thread Ahamed Husni

Hi,

Ping :)

On Tue, Jul 6, 2021 at 10:30 PM 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
>
> Husni Faiz (4):
>   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
>
>  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  |4 +-
>  libbsd.py |   25 +
>  rtemsbsd/include/bsp/nexus-devices.h  |5 +
>  .../include/machine/rtems-bsd-nexus-bus.h |   17 +
>  9 files changed, 2030 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
>
> --
> 2.25.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC 2021] Beagle BSP USB OTG Support

2021-05-16 Thread Ahamed Husni

Hi,

I tried the CDC Ethernet in FreeBSD. My Laptop detects an ethernet
<https://dms.uom.lk/s/QrzEsZAiSnWnQdk> interface with an IPv6.
I tried to ping the IPv6, but it didn't work
<https://dms.uom.lk/s/in6R2foWYwFWcdX>. The serial and ethernet works. I'll
check the mass
storage.

--Husni


On Thu, May 13, 2021 at 9:40 AM Ahamed Husni 
wrote:

> Hi,
>
> I couldn't set up the JTAG using Launchpad as it requires some adapters.
> While discussing
> <https://www.element14.com/community/groups/embedded/blog/2019/07/09/hardware-debug-jtag-probe-first-steps#comment-279479>
> in the Element14 forum, it seems it would require a lot of
> work to set up JTAG using the Launchpad.
> I can get the standard JTAG hardwares required  by ordering online before
> the coding period begins.
>
> Until that I did the hardware mod <https://dms.uom.lk/s/8rqygP9qfSGEcAW>
> required for Libdebugger on the BBB
> <https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-using-libdebugger>
> .
> I don't know how to use the libdebugger. If anyone could point me in the
> right direction, that would be great.
>
> I tried booting the FreeBSD on BBB. The serial over usb is working.
> Ethernet and mass storage might require some configuration in FreeBSD.
>
> Best regards,
> Husni Faiz.
>
> On Mon, May 10, 2021 at 12:04 PM Christian MAUDERER <
> christian.maude...@embedded-brains.de> wrote:
>
>> Hello Ahamed,
>>
>> I'm using a J-Link to debug Beagle. I think that it doesn't have a EMU
>> pin either. Only difference: It has an additional TRST. I would suggest
>> to just try it.
>>
>> I think on OpenOCD there are a few options regarding RST. You can have
>> SRST only, TRST only, both connected together and both as separate pins.
>>
>> Best regards
>>
>> Christian
>>
>> Am 10.05.21 um 06:09 schrieb Ahamed Husni:
>> > Hi all,
>> >
>> > I need to debug the Beaglebone Black using JTAG. I got a TI LaunchPad
>> > CC1310. Launchpad has a XDS110 debugger with a (ARM - not sure) 10 pin
>> > JTAG out which can be used to debug external targets. The Beaglebone
>> has
>> > a cTI 20 pin JTAG interface. Pin layouts for the ARM10 and cTI20 is
>> > given here.
>> >
>> >
>> http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html#connector-information
>> > <
>> http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html#connector-information
>> >
>> >
>> > Can we map the pins, point to point without adapters to debug the BBB
>> > using Launchpads's XDS110?
>> >
>> > Following is what I came up with just refering the above given pin
>> layouts.
>> >
>> > *ARM10 to cTI20*
>> >
>> > 1==5 (VTRef/VCC)
>> > 2==1 (SWDIO/TMS)
>> > 3==8(GND)
>> > 4==9  (SWCLK/TCLK) SWDCLK(9) and TCK(11) are separate in cTI
>> > 5==10  (GND)
>> > 6==7(SWO/TDO)
>> > 7 KEYED
>> > 8==3 (NC/TDI)
>> > 9==12   (GNDDetect)
>> > 10==15  (nRESET)
>> >
>> > Will this work? (EMU pins are not used here)
>> >
>> > Also I found a discussion in TI' forum which says,
>> >
>> > "Controlling the EMU0 and EMU1 signals, which are mandatory to place
>> the
>> > AM335x in debug mode."
>> >
>> >
>> https://e2e.ti.com/support/processors-group/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly
>> > <
>> https://e2e.ti.com/support/processors-group/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly
>> >
>> >
>> > Also the hardware Mod for libdebugger in RTEMS connects the SWO/TDO(7)
>> > to the EMU0(13).
>> >
>> >
>> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-using-libdebugger
>> > <
>> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-using-libdebugger
>> >
>> >
>> > My Project Proposal:
>> >
>> https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing
>> > <
>> https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing
>> >
>> >
>> > Best regards,
>> > Husni Faiz.
>> >
>>
>> --
>> 
>> 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: [GSoC 2021] Beagle BSP USB OTG Support

2021-05-12 Thread Ahamed Husni

Hi,

I couldn't set up the JTAG using Launchpad as it requires some adapters.
While discussing
<https://www.element14.com/community/groups/embedded/blog/2019/07/09/hardware-debug-jtag-probe-first-steps#comment-279479>
in the Element14 forum, it seems it would require a lot of
work to set up JTAG using the Launchpad.
I can get the standard JTAG hardwares required  by ordering online before
the coding period begins.

Until that I did the hardware mod <https://dms.uom.lk/s/8rqygP9qfSGEcAW>
required for Libdebugger on the BBB
<https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-using-libdebugger>
.
I don't know how to use the libdebugger. If anyone could point me in the
right direction, that would be great.

I tried booting the FreeBSD on BBB. The serial over usb is working.
Ethernet and mass storage might require some configuration in FreeBSD.

Best regards,
Husni Faiz.

On Mon, May 10, 2021 at 12:04 PM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Hello Ahamed,
>
> I'm using a J-Link to debug Beagle. I think that it doesn't have a EMU
> pin either. Only difference: It has an additional TRST. I would suggest
> to just try it.
>
> I think on OpenOCD there are a few options regarding RST. You can have
> SRST only, TRST only, both connected together and both as separate pins.
>
> Best regards
>
> Christian
>
> Am 10.05.21 um 06:09 schrieb Ahamed Husni:
> > Hi all,
> >
> > I need to debug the Beaglebone Black using JTAG. I got a TI LaunchPad
> > CC1310. Launchpad has a XDS110 debugger with a (ARM - not sure) 10 pin
> > JTAG out which can be used to debug external targets. The Beaglebone has
> > a cTI 20 pin JTAG interface. Pin layouts for the ARM10 and cTI20 is
> > given here.
> >
> >
> http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html#connector-information
> > <
> http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html#connector-information
> >
> >
> > Can we map the pins, point to point without adapters to debug the BBB
> > using Launchpads's XDS110?
> >
> > Following is what I came up with just refering the above given pin
> layouts.
> >
> > *ARM10 to cTI20*
> >
> > 1==5 (VTRef/VCC)
> > 2==1 (SWDIO/TMS)
> > 3==8(GND)
> > 4==9  (SWCLK/TCLK) SWDCLK(9) and TCK(11) are separate in cTI
> > 5==10  (GND)
> > 6==7(SWO/TDO)
> > 7 KEYED
> > 8==3 (NC/TDI)
> > 9==12   (GNDDetect)
> > 10==15  (nRESET)
> >
> > Will this work? (EMU pins are not used here)
> >
> > Also I found a discussion in TI' forum which says,
> >
> > "Controlling the EMU0 and EMU1 signals, which are mandatory to place the
> > AM335x in debug mode."
> >
> >
> https://e2e.ti.com/support/processors-group/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly
> > <
> https://e2e.ti.com/support/processors-group/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly
> >
> >
> > Also the hardware Mod for libdebugger in RTEMS connects the SWO/TDO(7)
> > to the EMU0(13).
> >
> >
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-using-libdebugger
> > <
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-using-libdebugger
> >
> >
> > My Project Proposal:
> >
> https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing
> > <
> https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing
> >
> >
> > Best regards,
> > Husni Faiz.
> >
>
> --
> 
> 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

[GSoC 2021] Beagle BSP USB OTG Support

2021-05-10 Thread Ahamed Husni

Hi all,

I need to debug the Beaglebone Black using JTAG. I got a TI LaunchPad
CC1310. Launchpad has a XDS110 debugger with a (ARM - not sure) 10 pin JTAG
out which can be used to debug external targets. The Beaglebone has a cTI
20 pin JTAG interface. Pin layouts for the ARM10 and cTI20 is given here.

http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html#connector-information

Can we map the pins, point to point without adapters to debug the BBB using
Launchpads's XDS110?

Following is what I came up with just refering the above given pin layouts.

*ARM10 to cTI20*

1==5 (VTRef/VCC)
2==1 (SWDIO/TMS)
3==8(GND)
4==9  (SWCLK/TCLK) SWDCLK(9) and TCK(11) are separate in cTI
5==10  (GND)
6==7(SWO/TDO)
7 KEYED
8==3 (NC/TDI)
9==12   (GNDDetect)
10==15  (nRESET)

Will this work? (EMU pins are not used here)

Also I found a discussion in TI' forum which says,

"Controlling the EMU0 and EMU1 signals, which are mandatory to place the
AM335x in debug mode."

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly

Also the hardware Mod for libdebugger in RTEMS connects the SWO/TDO(7) to
the EMU0(13).

https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-using-libdebugger

My Project Proposal:
https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing

Best regards,
Husni Faiz.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project - Beagle BSP Projects

2021-05-06 Thread Ahamed Husni

Hi,

Sorry for not providing detailed explanations and for the late response.

On Sun, May 2, 2021 at 5:31 PM Christian Mauderer  wrote:

> Hello Husni,
>
> On 01/05/2021 23:38, Ahamed Husni wrote:
> > Hi all,
> >
> > My project proposal
> >
> https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing
> > <
> https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing
> >
> >
> > I tried to set up the JTAG Environment for the Beaglebone Black.
> > But I couldn't find the hardware anywhere in my country (Sri Lanka).
> >
> > I tried to,
> >
> >  1. Find TI XDS Debuggers
> >  2. Find a TI Launchpad so we can isolate and use the debugger in it.
>
> I assume you didn't find these?


Yes, that was the case until yesterday. Luckily I was able to find a TI
Launchpad CC1310 board.
Due to the Covid situation in the country, I'll only be able to get the
hardware on Monday.
So until then I won't be able to try anything related to JTAG.
Also I will need an ARM10-cTI20 JTAG adapter to use the XDS110 debugger in
the launchpad. I'll find it asap.


> >  3. Use RPi as a debugger using OpenOCD
>
> I would have expect that one to work (like nearly any OpenOCD debugger).
> What was the problem? Did OpenOCD detect the processor? What pins did
> you connect? Please provide some more details so we might can help with
> tips.
>


No. I didn't try it myself.
I found a discussion in TI. It looks like someone has tried it and wasn't
successful.
I didn't understand most of the technical stuff in the discussion.
It seems like he was able to program with JTAG but not debug.
https://e2e.ti.com/support/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly

By the way: If you get it running it might would be a nice addition to
> the user manual:
>
>
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-beagle-bone-black-using-a-jtag-debugger-and-gdb
>
> That's currently mostly about the gdb part. You maybe could add two or
> three sentences and program calls how to start OpenOCD on a beagle and
> what pins can be used for it.
>
> >
> > I looked for the debuggers in major electronic shops, embedded systems
> > related companies,
> > university labs and etc. But couldn't find them.
> > Also these debuggers are expensive. When ordering online the shipping
> > charges are also high.
>
> I know from past GSoC that it can be difficult to get certain stuff in
> some countries. That's OK and I'm sure we find some solution.
>
> > So I can't guarantee that I can set up JTAG.
> >
> > Can we use RTEMS Libdebugger until we figure out the JTAG?
>
> I did too few stuff with libdebugger. So I don't know it really well. I
> _think_ that it needs a working network stack which would mean that you
> can only use it _after_ libbsd is initialized.
>
> Anyone: Please correct me if I'm wrong. If it would for example work
> with a serial interface, it should be OK.
>
> > Can we make a fallback plan for this project? If yes, what sorts of
> > changes should be made?
>
> I think the next best thing if you don't have a hardware debugger would
> be the RTEMS event recording. You have to instrument code and the
> processor has to be able to print an exception so you can get the data.
> You can't check anything on a instruction level but it's a great tool if
> you have to analyze the execution order of some problem cases. Most
> likely that will work for a lot of problems in your project too. So I
> would say that should be a fallback. Maybe you want to have a look at that:
>
> https://docs.rtems.org/branches/master/user/tracing/eventrecording.html
>
> Basically it's adding a few CONFIGURE_RECORD_... defines to your
> application, receive events with rtems-record-lttng via network or from
> a serial dump and then using Eclipse Trace Compass to analyze the trace.
> Please speak up if you need help setting that up.
>
>
For the last couple of days I've been learning about the rtems-libbsd.
I have built and installed the rtems-libbsd. I ran the Telnet testsuite on
the hardware.
Serial output is here <https://pastebin.com/c7C2R7Fj>.

Next I'll try out the libdebugger and event recording till I get the JTAG
hardwares.

Best regards,

Husni.

Best regards
>
> Christian
>
> >
> > Best regards,
> > Husni.
> >
> > On Fri, Apr 2, 2021 at 6:16 PM Christian Mauderer  > <mailto:o...@c-mauderer.de>> wrote:
> >
> >
> >
> > On 02/04/2021 08:36, Ahamed Husni wrote:
> >  > > Yes, this seems like an area that

Re: GSoC Project - Beagle BSP Projects

2021-05-01 Thread Ahamed Husni

Hi all,

My project proposal
https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing

I tried to set up the JTAG Environment for the Beaglebone Black.
But I couldn't find the hardware anywhere in my country (Sri Lanka).

I tried to,

   1. Find TI XDS Debuggers
   2. Find a TI Launchpad so we can isolate and use the debugger in it.
   3. Use RPi as a debugger using OpenOCD

I looked for the debuggers in major electronic shops, embedded systems
related companies,
university labs and etc. But couldn't find them.
Also these debuggers are expensive. When ordering online the shipping
charges are also high.
So I can't guarantee that I can set up JTAG.

Can we use RTEMS Libdebugger until we figure out the JTAG?
Can we make a fallback plan for this project? If yes, what sorts of changes
should be made?

Best regards,
Husni.

On Fri, Apr 2, 2021 at 6:16 PM Christian Mauderer  wrote:

>
>
> On 02/04/2021 08:36, Ahamed Husni wrote:
> > > Yes, this seems like an area that can be chipped away at,
> with a
> > > strong plan of activities. My concern would be whether it
> is about
> > > writing code or not?
> > >
> > >
> > > After completing the above milestones, if we have more time I
> can start
> > > to work on
> > > the Mass storage support.
> > >
> >
> >
> > I would suggest to put _more_ into the proposal and make it clear
> that
> > the later points depend on whether there is enough time or not.
> >
> > @Gedare: The time and effort for that project is really hard to
> > estimate
> > in my point of view. Do you have an idea how we could handle that?
> >
> >
> > So do I have to include mass storage support into the project schedule or
> > should I prepare the schedule for Ethernet, Serial and add the list of
> > possible advances and say that I'll work on them if there is enough time?
>
> I would suggest to include it. I'm quite sure that there is enough time.
>
> >
> > Most likely we would have to put some further open points at the end
> of
> > that because like I said: Depending on how well it works you might
> need
> > anything between a day and three weeks to get CDC Ethernet running.
> >  From
> > my first guess, it's maybe a week.
> >
> > Note that I would expect that you will need a debugger and the RTEMS
> > event recording for this kind of project.
> >
> >
> > CDC Serial should be only a small step as soon as CDC Ethernet is
> > running.
> >
> >
> > I don't have a JTAG debugger now. I'll get that set up asap.
> >
> >
> > > USB OTG would be a nice area. But that will be less writing a
> driver
> > > for
> > > Beagle but more finding out how that works with libbsd and
> finding a
> > > good way to configure it. I once put a few hours into it
> didn't take
> > > too
> > > much time till a PC detected an USB device (see
> > >
> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce
> > <https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce>
> >  >
> >   <https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce
> > <https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce>>).
> > > Basically it's about importing the "usb_template" stuff and
> finding a
> > > way to configure it in libbsd.
> >
> >
> > I'm trying to build and test this branch. I had trouble with building
> > the libbsd.
>
> The branch is very old. Most likely it won't build with a current
> toolchain and a current RTEMS. You might want to try to rebase the last
> two patches onto an up to date libbsd.
>
> > So I started to build the tools and kernel from scratch with the RSB
> > master, using
> > beaglebone black bset. It gives me the following error.
> > Error log: https://pastebin.com/NYZRej1B <https://pastebin.com/NYZRej1B>
> >
> > Build command
> >
> > ../source-builder/sb-set-builder --log=beagle.txt
> > --prefix=$BASE/rtems/6 bsps/beagleboneblack.bset
>
> For development I would suggest to build only the toolchain using RSB.
> After that you should build the BSP and libbsd manually. You will have
> to recompile the BSP and libbsd quite often and it's a lot more
> convenient to do that without touching RSB every time.
>
> I would suggest to use some simple scripts or a Make

Re: GSoC Project - Beagle BSP Projects

2021-04-09 Thread Ahamed Husni

Hi all,

I have prepared a draft proposal
<https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing>.
Added the proposal link to RTEMS Wiki.
Husni Faiz - https://devel.rtems.org/wiki/GSoC/2021
Please have a look and let me know your thoughts.
The project description is not complete yet.
I submitted the draft to GSoC as well.

Best regards,
Husni Faiz.

On Fri, Apr 2, 2021 at 6:16 PM Christian Mauderer  wrote:

>
>
> On 02/04/2021 08:36, Ahamed Husni wrote:
> > > Yes, this seems like an area that can be chipped away at,
> with a
> > > strong plan of activities. My concern would be whether it
> is about
> > > writing code or not?
> > >
> > >
> > > After completing the above milestones, if we have more time I
> can start
> > > to work on
> > > the Mass storage support.
> > >
> >
> >
> > I would suggest to put _more_ into the proposal and make it clear
> that
> > the later points depend on whether there is enough time or not.
> >
> > @Gedare: The time and effort for that project is really hard to
> > estimate
> > in my point of view. Do you have an idea how we could handle that?
> >
> >
> > So do I have to include mass storage support into the project schedule or
> > should I prepare the schedule for Ethernet, Serial and add the list of
> > possible advances and say that I'll work on them if there is enough time?
>
> I would suggest to include it. I'm quite sure that there is enough time.
>
> >
> > Most likely we would have to put some further open points at the end
> of
> > that because like I said: Depending on how well it works you might
> need
> > anything between a day and three weeks to get CDC Ethernet running.
> >  From
> > my first guess, it's maybe a week.
> >
> > Note that I would expect that you will need a debugger and the RTEMS
> > event recording for this kind of project.
> >
> >
> > CDC Serial should be only a small step as soon as CDC Ethernet is
> > running.
> >
> >
> > I don't have a JTAG debugger now. I'll get that set up asap.
> >
> >
> > > USB OTG would be a nice area. But that will be less writing a
> driver
> > > for
> > > Beagle but more finding out how that works with libbsd and
> finding a
> > > good way to configure it. I once put a few hours into it
> didn't take
> > > too
> > > much time till a PC detected an USB device (see
> > >
> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce
> > <https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce>
> >  >
> >   <https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce
> > <https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce>>).
> > > Basically it's about importing the "usb_template" stuff and
> finding a
> > > way to configure it in libbsd.
> >
> >
> > I'm trying to build and test this branch. I had trouble with building
> > the libbsd.
>
> The branch is very old. Most likely it won't build with a current
> toolchain and a current RTEMS. You might want to try to rebase the last
> two patches onto an up to date libbsd.
>
> > So I started to build the tools and kernel from scratch with the RSB
> > master, using
> > beaglebone black bset. It gives me the following error.
> > Error log: https://pastebin.com/NYZRej1B <https://pastebin.com/NYZRej1B>
> >
> > Build command
> >
> > ../source-builder/sb-set-builder --log=beagle.txt
> > --prefix=$BASE/rtems/6 bsps/beagleboneblack.bset
>
> For development I would suggest to build only the toolchain using RSB.
> After that you should build the BSP and libbsd manually. You will have
> to recompile the BSP and libbsd quite often and it's a lot more
> convenient to do that without touching RSB every time.
>
> I would suggest to use some simple scripts or a Makefile for that.
> Something like
>
>  https://gitlab.com/c-mauderer/rtems-bbb/-/blob/master/Makefile
>
> Note that the repo containing that Makefile is no official one and it is
> unstable. Most of the time I use it for testing stuff.
>
> >
> > What would be the steps to configure the USB OTG driver from libbsd to
> BBB.
> > I would like to try it out. Please guide me on this.
>
> I think that's most of the problem

Re: GSoC Project - Beagle BSP Projects

2021-04-02 Thread Ahamed Husni

>
> > Yes, this seems like an area that can be chipped away at, with a
>> > strong plan of activities. My concern would be whether it is about
>> > writing code or not?
>> >
>> >
>> > After completing the above milestones, if we have more time I can start
>> > to work on
>> > the Mass storage support.
>> >
>>
>
> I would suggest to put _more_ into the proposal and make it clear that
> the later points depend on whether there is enough time or not.
>
> @Gedare: The time and effort for that project is really hard to estimate
> in my point of view. Do you have an idea how we could handle that?
>

So do I have to include mass storage support into the project schedule or
should I prepare the schedule for Ethernet, Serial  and add the list of
possible advances and say that I'll work on them if there is enough time?



> Most likely we would have to put some further open points at the end of
> that because like I said: Depending on how well it works you might need
> anything between a day and three weeks to get CDC Ethernet running. From
> my first guess, it's maybe a week.
>
> Note that I would expect that you will need a debugger and the RTEMS
> event recording for this kind of project.
>
>
> CDC Serial should be only a small step as soon as CDC Ethernet is running.
>

I don't have a JTAG debugger now. I'll get that set up asap.


> USB OTG would be a nice area. But that will be less writing a driver
> > for
> > Beagle but more finding out how that works with libbsd and finding a
> > good way to configure it. I once put a few hours into it didn't take
> > too
> > much time till a PC detected an USB device (see
> > https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce
> > <https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce>).
> > Basically it's about importing the "usb_template" stuff and finding a
> > way to configure it in libbsd.


I'm trying to build and test this branch. I had trouble with building the
libbsd.
So I started to build the tools and kernel from scratch with the RSB
master, using
beaglebone black bset. It gives me the following error.
Error log: https://pastebin.com/NYZRej1B

Build command

> ../source-builder/sb-set-builder --log=beagle.txt --prefix=$BASE/rtems/6
> bsps/beagleboneblack.bset


What would be the steps to configure the USB OTG driver from libbsd to BBB.
I would like to try it out. Please guide me on this.

Best regards,

On Fri, Mar 26, 2021 at 8:17 PM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Hello Ahamed,
>
> Am 26.03.21 um 15:31 schrieb Ahamed Husni:
> > USB OTG would be a nice area. But that will be less writing a driver
> > for
> > Beagle but more finding out how that works with libbsd and finding a
> > good way to configure it. I once put a few hours into it didn't take
> > too
> > much time till a PC detected an USB device (see
> > https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce
> > <https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce>).
> > Basically it's about importing the "usb_template" stuff and finding a
> > way to configure it in libbsd.
> >
> > I think that topic would have to be a bit of an open one: You might
> > work
> > only a day on it and have a working CDC Ethernet afterwards or you
> can
> > need weeks for that. So you should add an open list of possible
> > advanced
> > targets. An OTG device can be:
> >
> > - Ethernet
> > - Serial port
> > - Mass storage
> > - Keyboard / Mouse
> > - Modem
> > - Audio
> > - ...
> >
> > The simplest one will most likely be Ethernet followed by serial
> > port. I
> > would add some of the others (like mass storage) as an extended
> targets.
> >
> > Best regards
> >
> > Christian
> >
> >
> > USB OTG would allow more extended capabilities for the beagle board.
> > To work on the USB OTG devices, what would be the best way?
> > What I understood from what Christian says is,
> >
> >  1. Finding out how USB OTG works with libbsd and finding a
> >   way to configure it for the beagle.
> >  2. Work on CDC Ethernet
> >  3. CDC Ethernet - Example application & Documentation
> >  4. Work on Serial over USB
> >  5. Serial over USB - Example application & Documentation
> >
> > Am I right?
>
> Most likely we would have to put some further open points

[Beagle BSP] How to run all tests on a Beaglebone Black in an automated way

2021-03-27 Thread Ahamed Husni

Hi,

I ran the hello program on the BBB using a bootable SD card. The SD card
has two partitions.

   1. BOOT - primary, bootable, FAT32
   2. ROOT - primary, ext4

The BOOT partition has the following files.

   1. uEnv.txt
   2. rtems-app.img
   3. Device Tree Blob (am335x-boneblack.dtb)

I want to run all the tests on the BBB. Is there any other way to do this?

You have to get the BBB to fetch exes from a ftftp server (provided inside
> rtems-test) and provide some automated power control to the board.
> - Dr. Joel (in Discord)
>

Best regards,
Husni.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project - Beagle BSP Projects

2021-03-26 Thread Ahamed Husni

>
> USB OTG would be a nice area. But that will be less writing a driver for
> Beagle but more finding out how that works with libbsd and finding a
> good way to configure it. I once put a few hours into it didn't take too
> much time till a PC detected an USB device (see
> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce).
> Basically it's about importing the "usb_template" stuff and finding a
> way to configure it in libbsd.
>
> I think that topic would have to be a bit of an open one: You might work
> only a day on it and have a working CDC Ethernet afterwards or you can
> need weeks for that. So you should add an open list of possible advanced
> targets. An OTG device can be:
>
> - Ethernet
> - Serial port
> - Mass storage
> - Keyboard / Mouse
> - Modem
> - Audio
> - ...
>
> The simplest one will most likely be Ethernet followed by serial port. I
> would add some of the others (like mass storage) as an extended targets.
>
> Best regards
>
> Christian


USB OTG would allow more extended capabilities for the beagle board.
To work on the USB OTG devices, what would be the best way?
What I understood from what Christian says is,

   1. Finding out how USB OTG works with libbsd and finding a
way to configure it for the beagle.
   2. Work on CDC Ethernet
   3. CDC Ethernet - Example application & Documentation
   4. Work on Serial over USB
   5. Serial over USB - Example application & Documentation

Am I right?

Would implementing Ethernet and Serial solve the problem of using TTL
converters
when working on RTEMS in Beagle for the developers?

Yes, this seems like an area that can be chipped away at, with a
> strong plan of activities. My concern would be whether it is about
> writing code or not?
>

After completing the above milestones, if we have more time I can start to
work on
the Mass storage support.



> Hi,
>
> Regarding the PRU.
> I was able to load code to the PRU.
> However I wasn't able to map IRQ interrupts to the PRU, thus unable to
> communicate with it in a meaningful way.
> Also I don't think that this project should be continued without a full
> DEBUGGING Setup.
>
> Best,
> Nils
>

+1, without a proper debugging setup I found it hard to precisely pin point
> the problem when I initially took up this task.
>

What is the full DEBUGGING setup needed to work on the PRU?

Regards,
Husni.

On Tue, Mar 23, 2021 at 10:25 PM Utkarsh Rai 
wrote:

>
>
>
> On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher  wrote:
>
>> Hi,
>>
>> Regarding the PRU.
>> I was able to load code to the PRU.
>> However I wasn't able to map IRQ interrupts to the PRU, thus unable to
>> communicate with it in a meaningful way
>>
>
>
> Just a small addition, AFAIK the issue with this was the fact that mmap()
> would always fail.
>
>
>> .
>> Also I don't think that this project should be continued without a full
>> DEBUGGING Setup.
>>
>
> +1, without a proper debugging setup I found it hard to precisely pin
> point the problem when I initially took up this task.
>
>
>>
>>
> Best,
>> Nils
>>
>> On Tue, 23 Mar 2021 at 17:00, Christian MAUDERER <
>> christian.maude...@embedded-brains.de> wrote:
>>
>>> Hello Gedare,
>>>
>>> Am 23.03.21 um 16:48 schrieb Gedare Bloom:
>>> > CC: Nils, Utkarsh
>>> >
>>> > On Tue, Mar 23, 2021 at 9:17 AM Christian MAUDERER
>>> >  wrote:
>>> >>
>>> >> Hello Ahamed,
>>> >>
>>> >> Am 23.03.21 um 11:24 schrieb Ahamed Husni:
>>> >>> Hi everyone,
>>> >>>
>>> >>> I'm really interested to work on the *Beagle BSP Projects* [#2891
>>> >>> <https://devel.rtems.org/ticket/2891>]. *
>>> >>> *
>>> >>> *Adding PRU Support* [#3730 <https://devel.rtems.org/ticket/3730>]
>>> >>> project seems really interesting to me.
>>> >>> This project is partially done during GSoC 2019
>>> >>> <https://devel.rtems.org/wiki/GSoC/2019>by Nils Hölscher .
>>> >>> Is this a good project for the GSoC?
>>> >>>
>>> >>> Up to now I have,
>>> >>>
>>> >>>   1. Completed the GSoC prerequisite task
>>> >>>   2. Got the required hardware and tested it. (Beagleboard Black,
>>> USB to
>>> >>>  TTL Converter)
>>> >>>   3. Installed RTEMS on the Beagleboard and tested. (Screenshot
>>> attached
>>> >>>  below)
>>> >>

GSoC Project - Beagle BSP Projects

2021-03-23 Thread Ahamed Husni

Hi everyone,

I'm really interested to work on the * Beagle BSP Projects* [#2891
].
*Adding PRU Support* [#3730 ] project
seems really interesting to me.
This project is partially done during GSoC 2019
by Nils Hölscher .
Is this a good project for the GSoC?

Up to now I have,

   1. Completed the GSoC prerequisite task
   2. Got the required hardware and tested it. (Beagleboard Black, USB to
   TTL Converter)
   3. Installed RTEMS on the Beagleboard and tested. (Screenshot attached
   below)


I need guidance to define the scope of the project.
I'm currently thinking of ,

   1. First finish the remaining work from GSoC 2019 on the PRU.
   (What is the status of current implementation of the PRU?)
   2. Implement additional peripheral support.
   What would be most useful?
   (USB OTG, CAN, ...).

The builtin USB is NOT functional other than for power under RTEMS.
> (USB OTG would have to be implemented in RTEMS to get rid of USB to TTL
> Converter.)
> - Ben Gras
> 
> (Blog post)
>

Thanks,
Husni Faiz.


[image: BBB_Serial_Out.png]
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC Prerequisite Task

2021-03-22 Thread Ahamed Husni

Hi all,
This is the modified hello program. I'll attach the screenshots in
another email.

>From 794d291f61c70dfcefb6b566e2a6a4af0fb801a5 Mon Sep 17 00:00:00 2001
From: Husni Faiz 
Date: Mon, 22 Mar 2021 01:18:25 +0530
Subject: [PATCH] GSoC Task

Modified the hello program to meet the requirement.
---
 testsuites/samples/hello/init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/testsuites/samples/hello/init.c
b/testsuites/samples/hello/init.c
index 34ded37c55..b215b1fcf9 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -22,7 +22,9 @@ static rtems_task Init(
 {
   rtems_print_printer_fprintf_putc(_test_printer);
   TEST_BEGIN();
-  printf( "Hello World\n" );
+  printf( "Hello Embedded World\n" );
+  printf( "Welcome to GSoC 202!\n" );
+  printf( "I'm Husni\n" );
   TEST_END();
   rtems_test_exit( 0 );
 }
-- 
2.17.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Servers offline (maybe)

2021-03-20 Thread Ahamed Husni

Hi,
I'm having the same problem ;)


On Sat, Mar 20, 2021 at 11:49 PM Eshan Dhawan 
wrote:

> Hello Everyone,
> Devel site is offline and returns error 503
>
> --
>
> Thanks
> - Eshan
> ___
> 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

Toolchain Build Failed

2021-03-20 Thread Ahamed Husni

HI,
I tried to build the *6/rtems-sparc* toolchain and it gave me the
following error.

Terminal Output

Creating source directory: patches
> download:
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff
> -> patches/automake-1.12.6-bugzilla.redhat.com-1239379.diff
> download:
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
> error: HTTP Error 503: Service Unavailable
> error: downloading
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
> all paths have failed, giving up
> Build FAILED
>   See error report: rsb-report-automake-1.12.6-x86_64-linux-gnu-1.txt
> error: downloading
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
> all paths have failed, giving up
> Build Set: Time 0:02:26.664058
> error: downloading
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
> all paths have failed, giving up
> Build Set: Time 0:02:26.666594
> error: downloading
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
> all paths have failed, giving up
> Build Set: Time 0:02:26.679289
> Build FAILED
>

Error log:

script: 90: /bin/chmod -R a+rX,g-w,o-w .
> Creating source directory: patches
> making dir: /home/drac/workspace/rtems_root/src/rsb/rtems/patches
> download: (full)
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff
> -> patches/automake-1.12.6-bugzilla.redhat.com-1239379.diff
> download:
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff
> -> patches/automake-1.12.6-bugzilla.redhat.com-1239379.diff
> download: no ssl context
> download:
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
> error: HTTP Error 503: Service Unavailable
> error: downloading
> https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
> all paths have failed, giving up
>

Does "Service Unavailable" means that the source file server is not
available?

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

QEMU Beagleboard Emulator

2021-03-18 Thread Ahamed Husni

Hi everyone,
   I'm new to RTEMS Project. I'm interested to work in #2891
 ticket (Beagle BSP) for GSoC. I need
a *beagleboard* emulator. I tried the following,

$ ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
devel/qemu4
$ qemu-system-arm -M beagle
qemu-system-arm: -M beagle: unsupported machine type
Use -machine help to list supported machines

I can find any beagle machines in the list.

Please help me to set it up.

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

Re: GSOC 2021: USB Device Drivers - Beaglebone Black

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

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

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

Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation

Re: [PATCH rtems-libbsd v2 4/5] libbsd.py: add usb template files

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

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

Re: [PATCH rtems-libbsd v2 2/5] usb_template: Configure template driver only for CDC Ethernet

Re: [PATCH rtems-libbsd v2 2/5] usb_template: Configure template driver only for CDC Ethernet

Re: [PATCH rtems-libbsd 2/4] usb_template: Configure template driver only for CDC Ethernet

Re: [PATCH rtems-libbsd 3/4] nexus-devices: Include CDC Ethernet for Beagle

Re: [PATCH rtems-libbsd 3/4] nexus-devices: Include CDC Ethernet for Beagle

GSOC 2021: USB Device Drivers - Beaglebone Black

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

Re: [GSoC 2021] Beagle BSP USB OTG Support

Re: [GSoC 2021] Beagle BSP USB OTG Support

[GSoC 2021] Beagle BSP USB OTG Support

Re: GSoC Project - Beagle BSP Projects

Re: GSoC Project - Beagle BSP Projects

Re: GSoC Project - Beagle BSP Projects

Re: GSoC Project - Beagle BSP Projects

[Beagle BSP] How to run all tests on a Beaglebone Black in an automated way

Re: GSoC Project - Beagle BSP Projects

GSoC Project - Beagle BSP Projects

GSoC Prerequisite Task

Re: RTEMS Servers offline (maybe)

Toolchain Build Failed

QEMU Beagleboard Emulator

29 matches

Site Navigation

Mail list logo

Footer information