Re: GSoC Project - Beagle BSP Projects

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

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

Re: GSoC Project - Beagle BSP Projects

[Christian Mauderer]

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 



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?


 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.


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.


Best regards

Christian



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 

Re: GSoC Project - Beagle BSP Projects

[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
> > 
> >  >
> >    > >).
> > > 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 
> >
> > 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 of the GSoC ;-)
>
> Basically it's the following steps:
>
> - Importing the relevant parts (should be the usb_template stuff) from
> FreeBSD into libbsd. 

Re: GSoC Project - Beagle BSP Projects

[Ahamed Husni]

Hi all,

I have prepared a draft proposal
.
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
> > 
> >  >
> >    > >).
> > > 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 
> >
> > 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 of the GSoC ;-)
>
> Basically it's the following steps:
>
> - Importing the relevant parts (should be the usb_template stuff) from
> FreeBSD into libbsd. That's basically what the first commit on the
> branch does. Take a look at the CONTRIBUTING.md file in libbsd for
> details about the import process:
> https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n158
>
> - Enable them for Beagle. That's the second commit on the branch.
>
> - Somehow configure the USB OTG stuff. Like I said: That's the tricky
> part. It has something to do with the usb_temp_init functions. But I
> didn't manage to get it working in an hour or 

Re: GSoC Project - Beagle BSP Projects

[Christian Mauderer]

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

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

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 of the GSoC ;-)

Basically it's the following steps:

- Importing the relevant parts (should be the usb_template stuff) from 
FreeBSD into libbsd. That's basically what the first commit on the 
branch does. Take a look at the CONTRIBUTING.md file in libbsd for 
details about the import process: 
https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n158


- Enable them for Beagle. That's the second commit on the branch.

- Somehow configure the USB OTG stuff. Like I said: That's the tricky 
part. It has something to do with the usb_temp_init functions. But I 
didn't manage to get it working in an hour or so and stopped trying 
after that. So finding out how to configure and set up the stuff will be 
part of your Project.


Best regards

Christian



Best regards,

On Fri, Mar 26, 2021 at 8:17 PM Christian MAUDERER 
> 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

Re: GSoC Project - Beagle BSP Projects

[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
> > ).
> > 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
> > ).
> > 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 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.
>
> Mass storage depends on the current implementation for that in FreeBSD.
> It might could be an interesting part.
>
> >
> > Would implementing Ethernet 

Re: GSoC Project - Beagle BSP Projects

[Christian MAUDERER]

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

Mass storage depends on the current implementation for that in FreeBSD. 
It might could be an interesting part.




Would implementing Ethernet and Serial solve the problem of using TTL 
converters

when working on RTEMS in Beagle for the developers?



Depends on the application. For those who want to write an application, 
a CDC Serial device would be a nice alternative. For those who want to 
develop drivers or RTEMS itself: Very unlikely that CDC Serial is enough 
for that.



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?





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?


I expect a JTAG-Debugger. I had good experience with the Segger J-Link 
EDU for GSoC projects with BBB. Alternatively there are OpenOCD based 
ones out there too that are said do work well. Note that you have to 
solder a debug connector to the Beagle for that.


Best regards

Christian



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 mailto:nilho...@gmail.com>> 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
mailto:christian.maude...@embedded-brains.de>> wrote:

Hello Gedare,

Am 23.03.21 um 16:48 schrieb Gedare Bloom:
 > CC: Nils, Utkarsh
 >
 > On Tue, Mar 

Re: GSoC Project - Beagle BSP Projects

[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
>>> >>> ]. *
>>> >>> *
>>> >>> *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?)
>>> >>
>>> >> I'm really not sure what the state of the PRU is. I didn't follow that
>>> >> project closely. Maybe one of the mentors of that project can say
>>> >> anything regarding that.
>>> >>
>>> > Some more background:
>>> > https://lists.rtems.org/pipermail/devel/2019-December/056478.html
>>> > https://lists.rtems.org/pipermail/devel/2020-January/056958.html
>>> >
>>> > Maybe Utkarsh or Nils have more to say.
>>> >
>>> >>>   2. Implement additional peripheral support.
>>> >>>  What would be most useful?
>>> >>>  (USB OTG, CAN, ...).
>>> >>
>>> >> I 

Re: GSoC Project - Beagle BSP Projects

[Utkarsh Rai]

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
>> >>> ]. *
>> >>> *
>> >>> *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?)
>> >>
>> >> I'm really not sure what the state of the PRU is. I didn't follow that
>> >> project closely. Maybe one of the mentors of that project can say
>> >> anything regarding that.
>> >>
>> > Some more background:
>> > https://lists.rtems.org/pipermail/devel/2019-December/056478.html
>> > https://lists.rtems.org/pipermail/devel/2020-January/056958.html
>> >
>> > Maybe Utkarsh or Nils have more to say.
>> >
>> >>>   2. Implement additional peripheral support.
>> >>>  What would be most useful?
>> >>>  (USB OTG, CAN, ...).
>> >>
>> >> I think CAN is a bit hard without some CAN analyzer hardware as a peer.
>> >>
>> >> 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.
>> >>
>> > 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?
>> >
>>
>> It won't produce a lot of code. But it will produce relevant one:
>>
>> 1. Interface for configuration (if necessary)
>>
>> 2. Example application
>>
>> 3. Documentation
>>
>> For Ethernet and serial port that's most likely it. For Mass storage
>> there might be some more code. Without a too detailed look: I would
>> expect that the mass storage either implements some access to a raw
>> block device - in which case it would be necessary to add the access to
>> block devices. Or it implements something like the PTP stuff used on
>> smartphones in which case there will be most likely some code that
>> accesses the file system using POSIX functions instead of FreeBSD kernel
>> functions.
>>
>> Best regards
>>
>> Christian
>>
>> >> Best regards
>> >>
>> >> Christian
>> >>
>> >>>
>> >>>  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
>> >>>  <
>> http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
>> >
>> >>>  (Blog post)
>> >>>
>> >>>
>> >>> Thanks,
>> >>> 

Re: GSoC Project - Beagle BSP Projects

[Christian MAUDERER]

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
]. *
*
*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?)


I'm really not sure what the state of the PRU is. I didn't follow that
project closely. Maybe one of the mentors of that project can say
anything regarding that.


Some more background:
https://lists.rtems.org/pipermail/devel/2019-December/056478.html
https://lists.rtems.org/pipermail/devel/2020-January/056958.html

Maybe Utkarsh or Nils have more to say.


  2. Implement additional peripheral support.
 What would be most useful?
 (USB OTG, CAN, ...).


I think CAN is a bit hard without some CAN analyzer hardware as a peer.

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.


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?



It won't produce a lot of code. But it will produce relevant one:

1. Interface for configuration (if necessary)

2. Example application

3. Documentation

For Ethernet and serial port that's most likely it. For Mass storage 
there might be some more code. Without a too detailed look: I would 
expect that the mass storage either implements some access to a raw 
block device - in which case it would be necessary to add the access to 
block devices. Or it implements something like the PTP stuff used on 
smartphones in which case there will be most likely some code that 
accesses the file system using POSIX functions instead of FreeBSD kernel 
functions.


Best regards

Christian


Best regards

Christian



 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.


BBB_Serial_Out.png


___
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


--

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

Re: GSoC Project - Beagle BSP Projects

[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
> > ]. *
> > *
> > *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?)
>
> I'm really not sure what the state of the PRU is. I didn't follow that
> project closely. Maybe one of the mentors of that project can say
> anything regarding that.
>
Some more background:
https://lists.rtems.org/pipermail/devel/2019-December/056478.html
https://lists.rtems.org/pipermail/devel/2020-January/056958.html

Maybe Utkarsh or Nils have more to say.

> >  2. Implement additional peripheral support.
> > What would be most useful?
> > (USB OTG, CAN, ...).
>
> I think CAN is a bit hard without some CAN analyzer hardware as a peer.
>
> 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.
>
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?

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

Re: GSoC Project - Beagle BSP Projects

[Christian MAUDERER]

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 
]. *

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


I'm really not sure what the state of the PRU is. I didn't follow that 
project closely. Maybe one of the mentors of that project can say 
anything regarding that.



 2. Implement additional peripheral support.
What would be most useful?
(USB OTG, CAN, ...).


I think CAN is a bit hard without some CAN analyzer hardware as a peer.

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



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.


BBB_Serial_Out.png


___
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

GSoC Project - Beagle BSP Projects

[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