Re: Beaglebone help needed

[Christian Mauderer]

Am 07.03.19 um 09:52 schrieb Sarvesh Patkar:
> Hey Chris and Christian,
> 
> Thank you for the prompt responses. 
> 
> I think there is no update needed to the rtems-source-builder at this
> time for beaglebone. After understanding what Christian told me, I
> realized that I just needed to use the rtems-arm build set. Then, I
> followed this
> README https://git.rtems.org/rtems/tree/bsps/arm/beagle/README from the
> master branch of rtems and ran the ticker sample on the beaglebone.
> 
> For now, I think I will stick to figuring out more about the PRU or ADC
> peripherals and try to write the respective drivers for the BSP.  Since
> I am not associated with GSoC or any other institute, I will keep an eye
> on the mailing lists and make sure I am not duplicating work which
> others are doing on the Beaglebone black. 
> 
> Thanks again for all the help.
> 
> Regards,
> Sarvesh

Hello Sarvesh,

good to hear that you managed to get started. Sorry that I assumed that
you are a student interested in GSoC participation. We currently have
the phase where the students start to search for projects.

Best regards

Christian

> 
> On Wed, Mar 6, 2019 at 10:18 PM Christian Mauderer
>  > wrote:
> 
> Am 06.03.19 um 21:17 schrieb Sarvesh Patkar:
> > Thank you for the responses!
> >
> > Chris,
> >
> > I was using Ben's repository and not git.rtems.org
> 
> > . I will test it with
> > https://git.rtems.org/rtems-source-builder/ some time later today
> to see
> > if it works.
> >
> >
> > Christian, 
> >
> > I didn't know the documentation is outdated.
> 
> Like I said: I have to update it some when.
> 
> >
> > I would like to understand what part of Beaglebone black BSP has not
> > been implemented. The list on the ticket mentioned
> >
> > PRU - programmable realtime units, interesting realtime applications
> > I2C
> > ADC
> > Framebuffer
> > USB
> > Ethernet
> > GPIO
> > CAN
> > MMC (internal flash & sdcard)  
> 
> From the list on the bottom of the ticket, the following are still open:
> 
>     PRU - programmable realtime units, interesting realtime applications
>     ADC
>     Framebuffer
>     GPIO
>     CAN
>     USB OTG (like CDC ethernet or CDC mass storage - not sure about the
> original beagle board but would be great on the beagle bone black)
> 
> Note that already at least one other student is planning a BBB project.
> Of course you can apply to the same. But be aware that we won't have two
> projects with the same target. If you are working on different parts of
> BBB, that's OK.
> 
> What I told the other student:
> 
> - The Framebuffer could be a decent package. (He asked about that on the
> mailing list already.)
> 
> - I have no idea what to do with the PRUs. So if you are interested in
> them, try to bring some ideas.
> 
> - All other packages are most likely quite small. But a combination of
> these could be a package too.
> 
> - If you want to add some other Beagle variant, we would have to have a
> look at how much work to expect and if it is enough for a project.
> 
> >
> > From the repository
> https://git.rtems.org/rtems/tree/bsps/arm/beagle, it
> > seems the i2c, spi, uart, gpio, pwm are implemented. I am not sure
> if I
> > am looking at the right place. So, it would be great if you could
> let me
> > know, where to look, to understand the BSP better.
> >
> > I understand why we don't need the tools to build the application. I
> > will try your way with the scripts from the Gitlab repository and
> try to
> > build a sample application.
> 
> You don't have to use the scripts. But of course you can. Basically the
> scripts just call RSB and the commands for building RTEMS and libbsd,
> build the same tools that originally have been build by Bens RSB branch,
> build a U-Boot and generate a SD-Card image that works without a U-Boot
> on the board too. So much more than the minimum requirement.
> 
> >
> > You mentioned a Wifi example, but there is an ethernet chip on
> board and
> > no Wifi chip. Is there a reason why an external Wifi chip is used and
> > not the ethernet chip? Also, are all networking applications for RTEMS
> > going to use the rtems-libbsd going forward?
> 
> Some parts of WiFi have been a GSoC project that I mentored in 2017.
> Therefore I needed a test platform. The student back then added (benath
> some other stuff) wpa_supplicant and a driver for a RTL8188 based stick.
> 
> The WiFi sample has grown to a more universal one. Since Christmas it
> includes Ethernet too.
> 
> Best regards
> 
> Christian
> 
> >
> > Thank you for the help.
> >
> > Regards,
> 

Survey for RTEMS SMP space profile

[Sebastian Huber]

Hello,

in order to provide a good feature set for the RTEMS SMP space profile 
we need some help from RTEMS users. An ongoing ESA activity tries to 
pre-qualify a subset of RTEMS according to ECSS standards (ECSS-E-ST-40C 
and ECSS-Q-ST-80C). The space profile of RTEMS SMP is intended for 
applications in ECSS software criticality C (ECSS-Q-ST-80C: "Software 
that if not executed, or if not correctly executed, or whose anomalous 
behaviour can cause or contribute to a system failure resulting in: 
Major consequences"). In ECSS-Q-ST-40C  major consequences are 
characterized in Table 6-1 as a major mission degradation without 
effects to the outside world of the system. A future activity may 
perform ISVV (independent Software Verification and Validation) to 
enable a use in criticality category B settings.


This survey is carried out by embedded brains GmbH 
(https://embedded-brains.de). Please contact rt...@embedded-brains.de if 
you have any questions related to this survey.


https://docs.google.com/forms/d/1Ae8_5hCUPtFfBrAuBlTSbp052I-wFp1Ap5V700n2Jgo/edit

You are also cordially invited to participate in the RTEMS SMP 
qualification user group meeting at ESA / ESTEC on Wednesday 27th March 
2019 (which is also accessible on-line via Skype for Business), where 
results from this questionnaire will be presented.


The Skype For Business meeting details:

https://meet.lync.com/esrin/marcel.verhoef/0RH5CI0Y
Conference ID: 90644128, Wed 27 March, 14h30 - 16h00 (GMT+1)
Global call-in numbers 
https://dialin.lync.com/f706e28c-e679-4e08-84a8-b4a001bdd11a


Kind regards,
    Sebastian

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: Beaglebone help needed

[Sarvesh Patkar]

Hey Chris and Christian,

Thank you for the prompt responses.

I think there is no update needed to the rtems-source-builder at this time
for beaglebone. After understanding what Christian told me, I realized that
I just needed to use the rtems-arm build set. Then, I followed this README
https://git.rtems.org/rtems/tree/bsps/arm/beagle/README from the master
branch of rtems and ran the ticker sample on the beaglebone.

For now, I think I will stick to figuring out more about the PRU or ADC
peripherals and try to write the respective drivers for the BSP.  Since I
am not associated with GSoC or any other institute, I will keep an eye on
the mailing lists and make sure I am not duplicating work which others are
doing on the Beaglebone black.

Thanks again for all the help.

Regards,
Sarvesh

On Wed, Mar 6, 2019 at 10:18 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Am 06.03.19 um 21:17 schrieb Sarvesh Patkar:
> > Thank you for the responses!
> >
> > Chris,
> >
> > I was using Ben's repository and not git.rtems.org
> > . I will test it with
> > https://git.rtems.org/rtems-source-builder/ some time later today to see
> > if it works.
> >
> >
> > Christian,
> >
> > I didn't know the documentation is outdated.
>
> Like I said: I have to update it some when.
>
> >
> > I would like to understand what part of Beaglebone black BSP has not
> > been implemented. The list on the ticket mentioned
> >
> > PRU - programmable realtime units, interesting realtime applications
> > I2C
> > ADC
> > Framebuffer
> > USB
> > Ethernet
> > GPIO
> > CAN
> > MMC (internal flash & sdcard)
>
> From the list on the bottom of the ticket, the following are still open:
>
> PRU - programmable realtime units, interesting realtime applications
> ADC
> Framebuffer
> GPIO
> CAN
> USB OTG (like CDC ethernet or CDC mass storage - not sure about the
> original beagle board but would be great on the beagle bone black)
>
> Note that already at least one other student is planning a BBB project.
> Of course you can apply to the same. But be aware that we won't have two
> projects with the same target. If you are working on different parts of
> BBB, that's OK.
>
> What I told the other student:
>
> - The Framebuffer could be a decent package. (He asked about that on the
> mailing list already.)
>
> - I have no idea what to do with the PRUs. So if you are interested in
> them, try to bring some ideas.
>
> - All other packages are most likely quite small. But a combination of
> these could be a package too.
>
> - If you want to add some other Beagle variant, we would have to have a
> look at how much work to expect and if it is enough for a project.
>
> >
> > From the repository https://git.rtems.org/rtems/tree/bsps/arm/beagle, it
> > seems the i2c, spi, uart, gpio, pwm are implemented. I am not sure if I
> > am looking at the right place. So, it would be great if you could let me
> > know, where to look, to understand the BSP better.
> >
> > I understand why we don't need the tools to build the application. I
> > will try your way with the scripts from the Gitlab repository and try to
> > build a sample application.
>
> You don't have to use the scripts. But of course you can. Basically the
> scripts just call RSB and the commands for building RTEMS and libbsd,
> build the same tools that originally have been build by Bens RSB branch,
> build a U-Boot and generate a SD-Card image that works without a U-Boot
> on the board too. So much more than the minimum requirement.
>
> >
> > You mentioned a Wifi example, but there is an ethernet chip on board and
> > no Wifi chip. Is there a reason why an external Wifi chip is used and
> > not the ethernet chip? Also, are all networking applications for RTEMS
> > going to use the rtems-libbsd going forward?
>
> Some parts of WiFi have been a GSoC project that I mentored in 2017.
> Therefore I needed a test platform. The student back then added (benath
> some other stuff) wpa_supplicant and a driver for a RTL8188 based stick.
>
> The WiFi sample has grown to a more universal one. Since Christmas it
> includes Ethernet too.
>
> Best regards
>
> Christian
>
> >
> > Thank you for the help.
> >
> > Regards,
> > Sarvesh
> >
> > On Wed, Mar 6, 2019 at 8:52 AM Christian Mauderer  > > wrote:
> >
> > Am 06.03.19 um 12:11 schrieb Chris Johns:
> > > On 6/3/19 6:07 pm, Sarvesh Patkar wrote:
> > >> Hey everyone,
> > >>
> > >> I went through the quick start guide and could build the Hello
> > World for the
> > >> sparc/erc32 target.
> > >>
> > >> I would like to contribute to RTEMS in adding functionality and
> > maybe, writing
> > >> BSPs for some development boards that I have. I started with
> > Beaglebone Black.
> > >
> > > Welcome and this sounds great.
> >
> > Note that the Beagle Bone Black is already quite well supported
> (except
> > for the outdated documentati