Please Review GSOC proposal after recommended changes

[ashish ashish]

I have made recommended changes in my proposal
proposal

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

Re: GSOC proposal - new POSIX APIs 2024

[Abhinav Srivastava]

Hi!
Requesting comments on my proposal for GSOC 2024 - implementing new POSIX
APIs:
https://docs.google.com/document/d/1iwgzx72TZ0aokNLww-y-IlyEkaRCovjGUhpdQXdP9mg/edit?usp=sharing

Abhinav.
-- 
*"Free society*
*Has, at its core, privacy*
*You must act in trust." - *Salyzyn
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Seeking review for GSoC Proposal "Add RTEMS Framework to PlatformIO"

[Pranav Gupta]

Please have a look at my project proposal for GSoC and suggest changes.

Google Docs Link:
https://docs.google.com/document/d/1uyC1Eai73RET6lcWMkSe01FvcXWhceSD9_q4v8eYCCI/edit

pdf for proposal attached below.


GSOC2024_GUPTA_Add RTEMS Framework to PlatformIO (1).pdf
Description: Adobe PDF document
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC proposal: GSOC2024_Yang_Adding SPI and Watchdog support to Raspberry Pi4B BSP

[Ning Yang]

Hello everyone,

I've prepared a draft for my proposal. Please let me know how I could improve 
it.

Thank you inadvance.

https://docs.google.com/document/d/1NjlUSWhqwUvrsQPBISU05ah0I0IGkEuq6BIThrkMBsg/edit?usp=sharing___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC Proposal Draft - Improve Raspberry Pi 4 BSP

[Utkarsh Verma]

I have drafted my GSoC proposal and uploaded it to Google Docs. You
can leave suggestions as comments in the document.

https://docs.google.com/document/d/1dL5zl_iSYeyx6ZoOpKjy-CkLh_OvgGDJvblrPH5q6rg/edit?usp=sharing

I apologize for not giving you much time for this review.

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

GSoC Proposal for Code Formatting and Style Check for RTEMS score

[Hardik Sethi]

Hey there, the draft for my GSoC 2023 proposal is ready. It would be very
helpful if anyone could review my proposal. All your suggestions are
welcome.
I have attached the link to my proposal below and opened it for
suggestions. If there is any issue with the link, please do let me know.

https://docs.google.com/document/d/11nEfcVgS7XvwPSW3VEreohFeaT9vP8dLNb41sz420UA/edit?usp=sharing

-- 
*Thanks & Regards*
*Hardik Sethi*
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC Proposal - Improve amd64 BSP

[Siddharth Khattar]

Hello all, I'm Siddharth Khattar, Please look at my first draft of the GSoC
Proposal to improve the x64 BSP of RTEMS. I humbly request all to please
take a look at it and comment any and all changes/improvements that can be
improved upon in the proposal. The link to my proposal is:
https://docs.google.com/document/d/1tJmGiT1Ewj8pqIZWXFanEbvPdehrMbWnUuq_d2AlJxU/edit#

Thank You,
Siddharth Khattar
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC Proposal - SiFive HiFive Unleashed RISC-V port for RTEMS

[Amna Mannan]

Hello everyone,
I'm Amna Mannan, wanted to share my proposal for this year with you. I'll
be to glad to know more about this proposal. I have updated the GSOC 2023
wiki.
Here's a link to my proposal.
https://docs.google.com/document/d/1-RfydFwHBI5dvJKJu9TLpVI9wmVRcrqcTuHLJGBNTME/edit?usp=sharing

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

[GSoC Proposal] Ethernet and SMP support for Raspberry Pi 4B AArch64

[Noor Aman]

Hello everyone,
I've drafted a proposal for GSoC 2023. All your help and review is
appreciated. I'm a bit stuck on ideas for SMP, and I'll be glad to know
further ideas for it. I've added the link to the gsoc 2023 wiki and added
it here too.
https://docs.google.com/document/d/1aQq1kkpsRnuxTjaPGQpuU8jN91QtyQXUKG8Sl2JfqdU/edit?usp=sharing

Thanks,
Regards,
-- 
Mohd Noor Aman
Tinkering with Hardware
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Help for GSoC proposal

[Hardik Sethi]

Hey there, I am thinking of taking #4628 for adding SATA support in libbsd
for RTEMS as my GSoC 2023 Project. I have already done the Hello World
patch and sent the screenshot to gedare and DrRTEMS.
This is my first time in GSoC so it would be a great help if someone could
guide me.

Thanks & Regards
Hardik Sethi
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC Proposal : Draft 3 Packaging Programming Language for RSB

[Eshan Dhawan]

Hello Everyone,
Draft 3 of my proposal is ready.
it can be accessed through
https://docs.google.com/document/d/1J4J114C3CrCKEV2L5vgobT-mE0f2xQx2waJTrQ0tNLQ/edit?usp=sharing

I would like to request everyone to review it for any changes or flaws

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

Gsoc Proposal : Packaging Programming Language Draft 2

[Eshan Dhawan]

Hello Everyone,
I have tried to implement the received feedback on draft 1 into this draft.
I would like everyone to look into this and tell how the proposal can be
improved further.

Link:
https://docs.google.com/document/d/1J4J114C3CrCKEV2L5vgobT-mE0f2xQx2waJTrQ0tNLQ/edit?usp=sharing


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

Review for gsoc proposal

[suyash singh]

I have incorporated the valuable suggestions of Dr Bloom in my proposal.
Looking forward for any further suggestions.

https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit


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

Re: Review for my GSOC proposal: Static analysis integration

[suyash singh]

Thanks I have added now.

On Mon, Mar 9, 2020 at 11:00 AM Vaibhav Gupta 
wrote:

>
>
> On Mon, Mar 9, 2020, 10:40 AM suyash singh 
> wrote:
>
>> Please review my proposal. Thank you
>>
>> This project is inspired by https://devel.rtems.org/ticket/3710 and from
>> the mail thread with subject
>> "Improve Coverity Scan Integration: GSOC project details"
>>
>>
>> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>>
> Please add the link to https://devel.rtems.org/wiki/GSoC/2020.
>
> -- Vaibhav
>
>>
>> ___
>> 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: Review for my GSOC proposal: Static analysis integration

[Vaibhav Gupta]

On Mon, Mar 9, 2020, 10:40 AM suyash singh  wrote:

> Please review my proposal. Thank you
>
> This project is inspired by https://devel.rtems.org/ticket/3710 and from
> the mail thread with subject
> "Improve Coverity Scan Integration: GSOC project details"
>
>
> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>
Please add the link to https://devel.rtems.org/wiki/GSoC/2020.

-- Vaibhav

>
> ___
> 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 Proposal : BeagleBoard project

[Vijay Kumar Banerjee]

Hi,

Thanks for all the reviews and comments on the proposal!
I have done all the changes according to the different comments and have
also submitted the final pdf. I would really appreciate any further review
or
any comment, or any kind of fine tuning that might make it a bit better,
before
the deadline on Apr. 9th.

Looking forward to a great summer ahead :)

Thanks,
vijay

On Tue, Apr 2, 2019 at 3:26 AM Chris Johns  wrote:

> On 2/4/19 12:06 am, Sebastian Huber wrote:
> > On 31/03/2019 03:57, Chris Johns wrote:
> >> On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:
> >>> On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom  >>> > wrote:
> >>>
> >>>  Remember you can submit your "Final" proposal many times on GSoC
> site.
> >>>  I made a few comments just regarding the 'public' view of your
> >>>  project. I think the technical plan looks reasonable, and leave
> it to
> >>>  the potential mentors to steer your technical path.
> >>>
> >>>  Gedare
> >>>
> >>> Thank you for reviewing the proposal. I have made the changes
> according to the
> >>> comments and also have uploaded the final proposal in the summer of
> code site.
> >> How will this be tested?
> >>
> >> Is https://github.com/littlevgl/lvgl  of any value?
> >
> > This looks like a really nice graphics library for RTEMS. How did you
> find this
> > one?
>
> I did not, a client did and we are using it on an embedded Linux box with a
> small DVI LCD display. It says it is for small devices and it looked to me
> like
> a good fit for RTEMS.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Proposal : BeagleBoard project

[Chris Johns]

On 2/4/19 12:06 am, Sebastian Huber wrote:
> On 31/03/2019 03:57, Chris Johns wrote:
>> On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:
>>> On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom >> > wrote:
>>>
>>>  Remember you can submit your "Final" proposal many times on GSoC site.
>>>  I made a few comments just regarding the 'public' view of your
>>>  project. I think the technical plan looks reasonable, and leave it to
>>>  the potential mentors to steer your technical path.
>>>
>>>  Gedare
>>>
>>> Thank you for reviewing the proposal. I have made the changes according to 
>>> the
>>> comments and also have uploaded the final proposal in the summer of code 
>>> site.
>> How will this be tested?
>>
>> Is https://github.com/littlevgl/lvgl  of any value?
> 
> This looks like a really nice graphics library for RTEMS. How did you find 
> this
> one?

I did not, a client did and we are using it on an embedded Linux box with a
small DVI LCD display. It says it is for small devices and it looked to me like
a good fit for RTEMS.

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

Re: GSoC Proposal : BeagleBoard project

[Sebastian Huber]

On 31/03/2019 03:57, Chris Johns wrote:

On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:

On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom mailto:ged...@rtems.org>> wrote:

 Remember you can submit your "Final" proposal many times on GSoC site.
 I made a few comments just regarding the 'public' view of your
 project. I think the technical plan looks reasonable, and leave it to
 the potential mentors to steer your technical path.

 Gedare

Thank you for reviewing the proposal. I have made the changes according to the
comments and also have uploaded the final proposal in the summer of code site.

How will this be tested?

Ishttps://github.com/littlevgl/lvgl  of any value?


This looks like a really nice graphics library for RTEMS. How did you 
find this one?


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

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

Re: GSoC Proposal : BeagleBoard project

[Vijay Kumar Banerjee]

On Mon, Apr 1, 2019 at 12:01 AM Christian Mauderer 
wrote:

> Am 31.03.19 um 19:33 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Sun, Mar 31, 2019 at 1:25 PM Christian Mauderer  > > wrote:
> >
> > Am 31.03.19 um 09:08 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > > On Sun, Mar 31, 2019 at 7:27 AM Chris Johns  > 
> > > >> wrote:
> > >
> > > On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:
> > > > On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom
> > mailto:ged...@rtems.org>
> > > >
> > > > 
> >  > > >
> > > > Remember you can submit your "Final" proposal many times
> on
> > > GSoC site.
> > > > I made a few comments just regarding the 'public' view
> > of your
> > > > project. I think the technical plan looks reasonable, and
> > > leave it to
> > > > the potential mentors to steer your technical path.
> > > >
> > > > Gedare
> > > >
> > > > Thank you for reviewing the proposal. I have made the changes
> > > according to the
> > > > comments and also have uploaded the final proposal in the
> summer
> > > of code site.
> > >
> > > How will this be tested?
> > >
> > > The target is to get a console on display. To test each step, I was
> > > planning to write some
> > > tests like to test the EDID reading, we can write a test that
> returns
> > > the EDID reading if the
> > > display is detected, or an error if it's not there.
> > > I think this point is very important and not very clear to me yet.
> Do
> > > you have any suggestions
> > > on testing each part of the project and if possible, include them
> > in the
> > > testsuite?
> > >
> > > Is https://github.com/littlevgl/lvgl of any value?
> > >
> > > I had a brief look and this looks really great and can be a nice
> > > addition to RTEMS.
> > > I think this will go in the "future improvements" (?)
> > >
> > > Chris
> > >
> > >
> >
> > I would suggest a framebuffer console as the primary target for this
> > project. Maybe as an extended goal it could be nice to try the
> libraries
> > already in RSB:
> >
> >
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/graphics
> >
> > Adding a new library would be a very extended goal in my view
> because it
> > hast the potential to eat up a lot of time.
> >
> > Vijay: I think you most likely need some test application already
> during
> > phase 2? So maybe you should add a point that you want to at least
> start
> > a fb-console there? Alternatively: Some simple test application that
> > just draws some dots or lines?
> >
> > In phase 3 it would be great to have the graphics libraries as
> extended
> > goal (lower priority than cleanup and getting code merged).
> >
> > Hi,
> >
> > Thanks for the notes. I have added a point about writing a test
> > application in phase 2
> > and also mentioned the intention to use the RSB graphics library to get
> > a GUI after the
> > code gets merged.
> >
> >
>
> It would be great if you could explicitly mention the framebuffer
> console at end of phase 2 / begin of phase 3. Alternatively (if you
> don't want a console) a test application with .
>
I added it as a point in the beginning of phase3.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Proposal : BeagleBoard project

[Christian Mauderer]

Am 31.03.19 um 19:33 schrieb Vijay Kumar Banerjee:
> 
> 
> On Sun, Mar 31, 2019 at 1:25 PM Christian Mauderer  > wrote:
> 
> Am 31.03.19 um 09:08 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Sun, Mar 31, 2019 at 7:27 AM Chris Johns  
> > >> wrote:
> >
> >     On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:
> >     > On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom
> mailto:ged...@rtems.org>
> >     >
> >     > 
>  >     >
> >     >     Remember you can submit your "Final" proposal many times on
> >     GSoC site.
> >     >     I made a few comments just regarding the 'public' view
> of your
> >     >     project. I think the technical plan looks reasonable, and
> >     leave it to
> >     >     the potential mentors to steer your technical path.
> >     >
> >     >     Gedare
> >     >
> >     > Thank you for reviewing the proposal. I have made the changes
> >     according to the
> >     > comments and also have uploaded the final proposal in the summer
> >     of code site.  
> >
> >     How will this be tested?
> >
> > The target is to get a console on display. To test each step, I was
> > planning to write some 
> > tests like to test the EDID reading, we can write a test that returns
> > the EDID reading if the
> > display is detected, or an error if it's not there.  
> > I think this point is very important and not very clear to me yet. Do
> > you have any suggestions
> > on testing each part of the project and if possible, include them
> in the
> > testsuite? 
> >
> >     Is https://github.com/littlevgl/lvgl of any value?
> >
> > I had a brief look and this looks really great and can be a nice
> > addition to RTEMS.
> > I think this will go in the "future improvements" (?)
> >
> >     Chris
> >
> >
> 
> I would suggest a framebuffer console as the primary target for this
> project. Maybe as an extended goal it could be nice to try the libraries
> already in RSB:
> 
>   https://git.rtems.org/rtems-source-builder/tree/rtems/config/graphics
> 
> Adding a new library would be a very extended goal in my view because it
> hast the potential to eat up a lot of time.
> 
> Vijay: I think you most likely need some test application already during
> phase 2? So maybe you should add a point that you want to at least start
> a fb-console there? Alternatively: Some simple test application that
> just draws some dots or lines?
> 
> In phase 3 it would be great to have the graphics libraries as extended
> goal (lower priority than cleanup and getting code merged).
> 
> Hi,
> 
> Thanks for the notes. I have added a point about writing a test
> application in phase 2 
> and also mentioned the intention to use the RSB graphics library to get
> a GUI after the
> code gets merged. 
> 
> 

It would be great if you could explicitly mention the framebuffer
console at end of phase 2 / begin of phase 3. Alternatively (if you
don't want a console) a test application with .
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Proposal : BeagleBoard project

[Vijay Kumar Banerjee]

On Sun, Mar 31, 2019 at 1:25 PM Christian Mauderer 
wrote:

> Am 31.03.19 um 09:08 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Sun, Mar 31, 2019 at 7:27 AM Chris Johns  > > wrote:
> >
> > On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:
> > > On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom  > 
> > > >> wrote:
> > >
> > > Remember you can submit your "Final" proposal many times on
> > GSoC site.
> > > I made a few comments just regarding the 'public' view of your
> > > project. I think the technical plan looks reasonable, and
> > leave it to
> > > the potential mentors to steer your technical path.
> > >
> > > Gedare
> > >
> > > Thank you for reviewing the proposal. I have made the changes
> > according to the
> > > comments and also have uploaded the final proposal in the summer
> > of code site.
> >
> > How will this be tested?
> >
> > The target is to get a console on display. To test each step, I was
> > planning to write some
> > tests like to test the EDID reading, we can write a test that returns
> > the EDID reading if the
> > display is detected, or an error if it's not there.
> > I think this point is very important and not very clear to me yet. Do
> > you have any suggestions
> > on testing each part of the project and if possible, include them in the
> > testsuite?
> >
> > Is https://github.com/littlevgl/lvgl of any value?
> >
> > I had a brief look and this looks really great and can be a nice
> > addition to RTEMS.
> > I think this will go in the "future improvements" (?)
> >
> > Chris
> >
> >
>
> I would suggest a framebuffer console as the primary target for this
> project. Maybe as an extended goal it could be nice to try the libraries
> already in RSB:
>
>   https://git.rtems.org/rtems-source-builder/tree/rtems/config/graphics
>
> Adding a new library would be a very extended goal in my view because it
> hast the potential to eat up a lot of time.
>
> Vijay: I think you most likely need some test application already during
> phase 2? So maybe you should add a point that you want to at least start
> a fb-console there? Alternatively: Some simple test application that
> just draws some dots or lines?
>
> In phase 3 it would be great to have the graphics libraries as extended
> goal (lower priority than cleanup and getting code merged).
>
> Hi,

Thanks for the notes. I have added a point about writing a test application
in phase 2
and also mentioned the intention to use the RSB graphics library to get a
GUI after the
code gets merged.

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

Re: GSoC Proposal : BeagleBoard project

[Christian Mauderer]

Am 31.03.19 um 09:08 schrieb Vijay Kumar Banerjee:
> 
> 
> On Sun, Mar 31, 2019 at 7:27 AM Chris Johns  > wrote:
> 
> On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:
> > On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom  
> > >> wrote:
> >
> >     Remember you can submit your "Final" proposal many times on
> GSoC site.
> >     I made a few comments just regarding the 'public' view of your
> >     project. I think the technical plan looks reasonable, and
> leave it to
> >     the potential mentors to steer your technical path.
> >
> >     Gedare
> >
> > Thank you for reviewing the proposal. I have made the changes
> according to the
> > comments and also have uploaded the final proposal in the summer
> of code site.  
> 
> How will this be tested?
> 
> The target is to get a console on display. To test each step, I was
> planning to write some 
> tests like to test the EDID reading, we can write a test that returns
> the EDID reading if the
> display is detected, or an error if it's not there.  
> I think this point is very important and not very clear to me yet. Do
> you have any suggestions
> on testing each part of the project and if possible, include them in the
> testsuite? 
> 
> Is https://github.com/littlevgl/lvgl of any value?
> 
> I had a brief look and this looks really great and can be a nice
> addition to RTEMS.
> I think this will go in the "future improvements" (?)
> 
> Chris
> 
> 

I would suggest a framebuffer console as the primary target for this
project. Maybe as an extended goal it could be nice to try the libraries
already in RSB:

  https://git.rtems.org/rtems-source-builder/tree/rtems/config/graphics

Adding a new library would be a very extended goal in my view because it
hast the potential to eat up a lot of time.

Vijay: I think you most likely need some test application already during
phase 2? So maybe you should add a point that you want to at least start
a fb-console there? Alternatively: Some simple test application that
just draws some dots or lines?

In phase 3 it would be great to have the graphics libraries as extended
goal (lower priority than cleanup and getting code merged).


Regards

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

Re: GSoC Proposal : BeagleBoard project

[Vijay Kumar Banerjee]

On Sun, Mar 31, 2019 at 7:27 AM Chris Johns  wrote:

> On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:
> > On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom  > > wrote:
> >
> > Remember you can submit your "Final" proposal many times on GSoC
> site.
> > I made a few comments just regarding the 'public' view of your
> > project. I think the technical plan looks reasonable, and leave it to
> > the potential mentors to steer your technical path.
> >
> > Gedare
> >
> > Thank you for reviewing the proposal. I have made the changes according
> to the
> > comments and also have uploaded the final proposal in the summer of code
> site.
>
> How will this be tested?
>
> The target is to get a console on display. To test each step, I was
planning to write some
tests like to test the EDID reading, we can write a test that returns the
EDID reading if the
display is detected, or an error if it's not there.
I think this point is very important and not very clear to me yet. Do you
have any suggestions
on testing each part of the project and if possible, include them in the
testsuite?

> Is https://github.com/littlevgl/lvgl of any value?
>
> I had a brief look and this looks really great and can be a nice addition
to RTEMS.
I think this will go in the "future improvements" (?)

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

Re: GSoC Proposal : BeagleBoard project

[Chris Johns]

On 31/3/19 5:05 am, Vijay Kumar Banerjee wrote:
> On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom  > wrote:
> 
> Remember you can submit your "Final" proposal many times on GSoC site.
> I made a few comments just regarding the 'public' view of your
> project. I think the technical plan looks reasonable, and leave it to
> the potential mentors to steer your technical path.
> 
> Gedare
> 
> Thank you for reviewing the proposal. I have made the changes according to the
> comments and also have uploaded the final proposal in the summer of code 
> site.  

How will this be tested?

Is https://github.com/littlevgl/lvgl of any value?

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

Re: GSoC Proposal : BeagleBoard project

[Vijay Kumar Banerjee]

On Sat, Mar 30, 2019 at 5:09 PM Gedare Bloom  wrote:

> Remember you can submit your "Final" proposal many times on GSoC site.
> I made a few comments just regarding the 'public' view of your
> project. I think the technical plan looks reasonable, and leave it to
> the potential mentors to steer your technical path.
>
> Gedare
>
> Thank you for reviewing the proposal. I have made the changes according to
the
comments and also have uploaded the final proposal in the summer of code
site.


> On Fri, Mar 29, 2019 at 7:04 AM Vijay Kumar Banerjee
>  wrote:
> >
> > Hello,
> >
> > I have prepared the draft proposal and have signed up in the official
> GSoC site.
> >
> > Here is the link to the proposal
> >
> >
> https://docs.google.com/document/d/14UxH4KE5E3ME_PJZVBVGRgGjeWtSKafDpaQ70fe5Z8Q/edit?usp=sharing
> >
> > I would really appreciate any comments or feedback on the same.
> >
> > Thank you
> >
> > Vijay
> > ___
> > 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 Proposal : BeagleBoard project

[Gedare Bloom]

Remember you can submit your "Final" proposal many times on GSoC site.
I made a few comments just regarding the 'public' view of your
project. I think the technical plan looks reasonable, and leave it to
the potential mentors to steer your technical path.

Gedare

On Fri, Mar 29, 2019 at 7:04 AM Vijay Kumar Banerjee
 wrote:
>
> Hello,
>
> I have prepared the draft proposal and have signed up in the official GSoC 
> site.
>
> Here is the link to the proposal
>
> https://docs.google.com/document/d/14UxH4KE5E3ME_PJZVBVGRgGjeWtSKafDpaQ70fe5Z8Q/edit?usp=sharing
>
> I would really appreciate any comments or feedback on the same.
>
> Thank you
>
> Vijay
> ___
> 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

GSoC Proposal : BeagleBoard project

[Vijay Kumar Banerjee]

Hello,

I have prepared the draft proposal and have signed up in the official GSoC
site.

Here is the link to the proposal

https://docs.google.com/document/d/14UxH4KE5E3ME_PJZVBVGRgGjeWtSKafDpaQ70fe5Z8Q/edit?usp=sharing

I would really appreciate any comments or feedback on the same.

Thank you

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

GSoC Proposal

[Elliott, Braden]

Hello,

I apologize for the late communication, and although the deadline has passed 
for official proposal submissions I would greatly appreciate any advice on my 
proposal for an STM32F446RE BSP.
The proposal can be found on the GSoC Tracking 
Page or the link below.

https://docs.google.com/document/d/1nUlxKEiiW19ZxnN1Zn_ZLNP4R30kSAMXEF9VwQizq3w/edit?usp=sharing

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

Re: GSOC proposal - Runtime tracing

[Vidushi Vashishth]

hi!

> I think we should define some basic functionality which should be
available ready to use during mid term evaluation. I want to avoid a last
minute delivery during the project end with no time to fix problems after a
review. This likely results in some half-finished work which nobody can use.

Currently I plan to deliver a barectf integrated RTEMS trace linker and a
transport mechanism to deliver trace data to the host machine using TCP by
mid term evaluation (second phase). I intend to fix any errors encountered
in the process by end of second phase itself. I understand how kernel level
tracing will be beneficial to the tracing framework. I can modify my
proposal to include this as one of my goals. I also intend to deliver live
tracing functionality as a goal of my third phase. Would it be viable to
accommodate kernel level tracing to my current plan? Or should I discount
any of my current goals (integration of barectf, transport mechanism to
host, live tracing) in place of it?

Regards,
Vidushi Vashishth

On Mon, Mar 26, 2018 at 12:17 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 23/03/18 16:28, Gedare Bloom wrote:
>
>> Hello Vidushi, Sebastian:
>>
>> On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
>>  wrote:
>>
>>> Hello Vidushi,
>>>
>>> the RTEMS Trace Linker is definitely an interesting tool to track down
>>> difficult and specific issues. However, this is a nice to have optional
>>>
>> out-of-box Trace Linker with integration to debugger or CTF tools will
>> be highly beneficial for the "user-side" experience of RTEMS. This can
>> be quite beneficial for marketing if nothing else. :) Given the
>> current state, and that we've had a few projects already on this
>> topic, any project working here needs to focus on delivering a
>> complete slice of the software stack from trace configuration all the
>> way through trace output analysis. There is a lot to review to get the
>> plan right here. I've made comments on the google doc proposal.
>>
>
> I think we should define some basic functionality which should be
> available ready to use during mid term evaluation. I want to avoid a last
> minute delivery during the project end with no time to fix problems after a
> review. This likely results in some half-finished work which nobody can use.
>
>
>> feature from my point of view. We should focus on basic functionality and
>>> this is interrupt entry/exit and thread switching. This should work out
>>> of
>>> the box without having to compile RTEMS with specialized configuration
>>>
>> I agree that this is also an important aspect for "kernel-level"
>> tracing, and it should be implemented directly into RTEMS with
>> standard configuration (configure or confdefs.h options). The
>> requirements for this functionality is unclear, though, such as what
>> the trace output should be.
>>
>> options. It should work via a serial line and network (UDP I guess). It
>>>
>> I don't see how network support can exist out-of-the-box unless the
>> solution exists at libbsd level. I think there will be two pieces to
>> this kind of project:
>> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
>> 2. transporting buffers via worker threads.
>>
>> Then, one can implement a basic worker thread using available drivers
>> in rtems, and also more advanced (network) workers relying on libbsd.
>>
>
> The network transport should rely on the POSIX sockets API only as defined
> by Newlib.
>
>
>> should also support SMP machines. This requires per-processor trace
>>> buffers.
>>> The trace buffer should work without locks, e.g. only interrupt
>>> disable/enable. I would do also a short review of existing trace
>>> solutions.
>>>
>> The use of per-processor buffers makes the "reader" side (transport)
>> more complicated. This is a good place to consider a wait-free
>> non-blocking data structure, or a rwlock with writer prioritization.
>> At any rate, a good design is needed here with some careful thought.
>>
>
> Everything which uses an atomic read-modify-write operation on some global
> data will lead to a significant change in the overall timing on larger
> machines with several cache layers (e.g. QoriIQ T4240). The reader side
> with per-processor data is not that difficult if everything runs in
> kernel-space. You can use processor affine threads (supported by the
> default SMP scheduler) or inter-processor interrupts to fetch the data.
>
>
>> Maybe we don't have to re-invent the wheel. For example:
>>>
>>> http://www.cs.unc.edu/~bbb/feathertrace/
>>>
>>
> This was just one example.
>
>
> --
> 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.
>
>

Re: GSOC proposal - Runtime tracing

[Sebastian Huber]

On 23/03/18 16:28, Gedare Bloom wrote:

Hello Vidushi, Sebastian:

On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
 wrote:

Hello Vidushi,

the RTEMS Trace Linker is definitely an interesting tool to track down
difficult and specific issues. However, this is a nice to have optional

out-of-box Trace Linker with integration to debugger or CTF tools will
be highly beneficial for the "user-side" experience of RTEMS. This can
be quite beneficial for marketing if nothing else. :) Given the
current state, and that we've had a few projects already on this
topic, any project working here needs to focus on delivering a
complete slice of the software stack from trace configuration all the
way through trace output analysis. There is a lot to review to get the
plan right here. I've made comments on the google doc proposal.


I think we should define some basic functionality which should be 
available ready to use during mid term evaluation. I want to avoid a 
last minute delivery during the project end with no time to fix problems 
after a review. This likely results in some half-finished work which 
nobody can use.





feature from my point of view. We should focus on basic functionality and
this is interrupt entry/exit and thread switching. This should work out of
the box without having to compile RTEMS with specialized configuration

I agree that this is also an important aspect for "kernel-level"
tracing, and it should be implemented directly into RTEMS with
standard configuration (configure or confdefs.h options). The
requirements for this functionality is unclear, though, such as what
the trace output should be.


options. It should work via a serial line and network (UDP I guess). It

I don't see how network support can exist out-of-the-box unless the
solution exists at libbsd level. I think there will be two pieces to
this kind of project:
1. capturing traces to memory buffers from interrupt/"kernel" contexts.
2. transporting buffers via worker threads.

Then, one can implement a basic worker thread using available drivers
in rtems, and also more advanced (network) workers relying on libbsd.


The network transport should rely on the POSIX sockets API only as 
defined by Newlib.





should also support SMP machines. This requires per-processor trace buffers.
The trace buffer should work without locks, e.g. only interrupt
disable/enable. I would do also a short review of existing trace solutions.

The use of per-processor buffers makes the "reader" side (transport)
more complicated. This is a good place to consider a wait-free
non-blocking data structure, or a rwlock with writer prioritization.
At any rate, a good design is needed here with some careful thought.


Everything which uses an atomic read-modify-write operation on some 
global data will lead to a significant change in the overall timing on 
larger machines with several cache layers (e.g. QoriIQ T4240). The 
reader side with per-processor data is not that difficult if everything 
runs in kernel-space. You can use processor affine threads (supported by 
the default SMP scheduler) or inter-processor interrupts to fetch the data.





Maybe we don't have to re-invent the wheel. For example:

http://www.cs.unc.edu/~bbb/feathertrace/


This was just one example.

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

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

Re: GSOC proposal - Runtime tracing

[Vidushi Vashishth]

Hi!

I have uploaded my final proposal pdf for GSOC'18. I have tried to
incorporate all the comments made. PFA the final draft of the proposal.

Thanks for being such a wonderful community! I enjoyed every bit of the
application process.

Warm regards,
Vidushi Vashishth

​
 GSOC_proposal_Vidushi_runtime_tracing

​

On Sat, Mar 24, 2018 at 1:23 AM, Vidushi Vashishth 
wrote:

> Hello!
>
> >>We should focus on basic functionality and this is interrupt entry/exit
> and thread switching. This should work out of the box without having to
> compile RTEMS with specialized configuration options. It should work via a
> serial line and network (UDP I guess). It should also support SMP machines.
> This requires per-processor trace buffers. The trace buffer should work
> without locks, e.g. only interrupt disable/enable. I would do also a short
> review of existing trace solutions. Maybe we don't have to re-invent the
> wheel. For example:
>
> http://www.cs.unc.edu/~bbb/feathertrace/
>
> I see. I went through the feathertrace solution documentation. I am also
> looking at other solutions, including Linux Trace Toolkit. I will reinvent
> the focus of my proposal to include the basic functionality suggested.
>
> >There is a lot to review to get the
> plan right here. I've made comments on the google doc proposal.
>
> Yes. I went over the comments. Thank you for such a detailed explanation.
> I will amend the proposal to incorporate the comments.
>
> >I don't see how network support can exist out-of-the-box unless the
> solution exists at libbsd level. I think there will be two pieces to
> this kind of project:
> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
> 2. transporting buffers via worker threads.
>
> Then, one can implement a basic worker thread using available drivers
> in rtems, and also more advanced (network) workers relying on libbsd.
>
> >The use of per-processor buffers makes the "reader" side (transport)
> more complicated. This is a good place to consider a wait-free
> non-blocking data structure, or a rwlock with writer prioritization.
> At any rate, a good design is needed here with some careful thought.
>
> I will investigate if an out of the box solution exists at the libbsd
> level and post it here.
>
>
> Regards,
> Vidushi
>
>
>
> On Fri, Mar 23, 2018 at 8:58 PM, Gedare Bloom  wrote:
>
>> Hello Vidushi, Sebastian:
>>
>> On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
>>  wrote:
>> > Hello Vidushi,
>> >
>> > the RTEMS Trace Linker is definitely an interesting tool to track down
>> > difficult and specific issues. However, this is a nice to have optional
>>
>> out-of-box Trace Linker with integration to debugger or CTF tools will
>> be highly beneficial for the "user-side" experience of RTEMS. This can
>> be quite beneficial for marketing if nothing else. :) Given the
>> current state, and that we've had a few projects already on this
>> topic, any project working here needs to focus on delivering a
>> complete slice of the software stack from trace configuration all the
>> way through trace output analysis. There is a lot to review to get the
>> plan right here. I've made comments on the google doc proposal.
>>
>> > feature from my point of view. We should focus on basic functionality
>> and
>> > this is interrupt entry/exit and thread switching. This should work out
>> of
>> > the box without having to compile RTEMS with specialized configuration
>>
>> I agree that this is also an important aspect for "kernel-level"
>> tracing, and it should be implemented directly into RTEMS with
>> standard configuration (configure or confdefs.h options). The
>> requirements for this functionality is unclear, though, such as what
>> the trace output should be.
>>
>> > options. It should work via a serial line and network (UDP I guess). It
>>
>> I don't see how network support can exist out-of-the-box unless the
>> solution exists at libbsd level. I think there will be two pieces to
>> this kind of project:
>> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
>> 2. transporting buffers via worker threads.
>>
>> Then, one can implement a basic worker thread using available drivers
>> in rtems, and also more advanced (network) workers relying on libbsd.
>>
>> > should also support SMP machines. This requires per-processor trace
>> buffers.
>> > The trace buffer should work without locks, e.g. only interrupt
>> > disable/enable. I would do also a short review of existing trace
>> solutions.
>>
>> The use of per-processor buffers makes the "reader" side (transport)
>> more complicated. This is a good place to consider a wait-free
>> non-blocking data structure, or a rwlock with writer prioritization.
>> At any rate, a good design is needed here with some careful thought.
>>
>> > Maybe we don't have 

Re: GSOC proposal - Runtime tracing

[Vidushi Vashishth]

Hello!

>>We should focus on basic functionality and this is interrupt entry/exit
and thread switching. This should work out of the box without having to
compile RTEMS with specialized configuration options. It should work via a
serial line and network (UDP I guess). It should also support SMP machines.
This requires per-processor trace buffers. The trace buffer should work
without locks, e.g. only interrupt disable/enable. I would do also a short
review of existing trace solutions. Maybe we don't have to re-invent the
wheel. For example:

http://www.cs.unc.edu/~bbb/feathertrace/

I see. I went through the feathertrace solution documentation. I am also
looking at other solutions, including Linux Trace Toolkit. I will reinvent
the focus of my proposal to include the basic functionality suggested.

>There is a lot to review to get the
plan right here. I've made comments on the google doc proposal.

Yes. I went over the comments. Thank you for such a detailed explanation. I
will amend the proposal to incorporate the comments.

>I don't see how network support can exist out-of-the-box unless the
solution exists at libbsd level. I think there will be two pieces to
this kind of project:
1. capturing traces to memory buffers from interrupt/"kernel" contexts.
2. transporting buffers via worker threads.

Then, one can implement a basic worker thread using available drivers
in rtems, and also more advanced (network) workers relying on libbsd.

>The use of per-processor buffers makes the "reader" side (transport)
more complicated. This is a good place to consider a wait-free
non-blocking data structure, or a rwlock with writer prioritization.
At any rate, a good design is needed here with some careful thought.

I will investigate if an out of the box solution exists at the libbsd level
and post it here.


Regards,
Vidushi



On Fri, Mar 23, 2018 at 8:58 PM, Gedare Bloom  wrote:

> Hello Vidushi, Sebastian:
>
> On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
>  wrote:
> > Hello Vidushi,
> >
> > the RTEMS Trace Linker is definitely an interesting tool to track down
> > difficult and specific issues. However, this is a nice to have optional
>
> out-of-box Trace Linker with integration to debugger or CTF tools will
> be highly beneficial for the "user-side" experience of RTEMS. This can
> be quite beneficial for marketing if nothing else. :) Given the
> current state, and that we've had a few projects already on this
> topic, any project working here needs to focus on delivering a
> complete slice of the software stack from trace configuration all the
> way through trace output analysis. There is a lot to review to get the
> plan right here. I've made comments on the google doc proposal.
>
> > feature from my point of view. We should focus on basic functionality and
> > this is interrupt entry/exit and thread switching. This should work out
> of
> > the box without having to compile RTEMS with specialized configuration
>
> I agree that this is also an important aspect for "kernel-level"
> tracing, and it should be implemented directly into RTEMS with
> standard configuration (configure or confdefs.h options). The
> requirements for this functionality is unclear, though, such as what
> the trace output should be.
>
> > options. It should work via a serial line and network (UDP I guess). It
>
> I don't see how network support can exist out-of-the-box unless the
> solution exists at libbsd level. I think there will be two pieces to
> this kind of project:
> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
> 2. transporting buffers via worker threads.
>
> Then, one can implement a basic worker thread using available drivers
> in rtems, and also more advanced (network) workers relying on libbsd.
>
> > should also support SMP machines. This requires per-processor trace
> buffers.
> > The trace buffer should work without locks, e.g. only interrupt
> > disable/enable. I would do also a short review of existing trace
> solutions.
>
> The use of per-processor buffers makes the "reader" side (transport)
> more complicated. This is a good place to consider a wait-free
> non-blocking data structure, or a rwlock with writer prioritization.
> At any rate, a good design is needed here with some careful thought.
>
> > Maybe we don't have to re-invent the wheel. For example:
> >
> > http://www.cs.unc.edu/~bbb/feathertrace/
> >
> > --
> > 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.
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>

Re: GSOC proposal - Runtime tracing

[Gedare Bloom]

Hello Vidushi, Sebastian:

On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
 wrote:
> Hello Vidushi,
>
> the RTEMS Trace Linker is definitely an interesting tool to track down
> difficult and specific issues. However, this is a nice to have optional

out-of-box Trace Linker with integration to debugger or CTF tools will
be highly beneficial for the "user-side" experience of RTEMS. This can
be quite beneficial for marketing if nothing else. :) Given the
current state, and that we've had a few projects already on this
topic, any project working here needs to focus on delivering a
complete slice of the software stack from trace configuration all the
way through trace output analysis. There is a lot to review to get the
plan right here. I've made comments on the google doc proposal.

> feature from my point of view. We should focus on basic functionality and
> this is interrupt entry/exit and thread switching. This should work out of
> the box without having to compile RTEMS with specialized configuration

I agree that this is also an important aspect for "kernel-level"
tracing, and it should be implemented directly into RTEMS with
standard configuration (configure or confdefs.h options). The
requirements for this functionality is unclear, though, such as what
the trace output should be.

> options. It should work via a serial line and network (UDP I guess). It

I don't see how network support can exist out-of-the-box unless the
solution exists at libbsd level. I think there will be two pieces to
this kind of project:
1. capturing traces to memory buffers from interrupt/"kernel" contexts.
2. transporting buffers via worker threads.

Then, one can implement a basic worker thread using available drivers
in rtems, and also more advanced (network) workers relying on libbsd.

> should also support SMP machines. This requires per-processor trace buffers.
> The trace buffer should work without locks, e.g. only interrupt
> disable/enable. I would do also a short review of existing trace solutions.

The use of per-processor buffers makes the "reader" side (transport)
more complicated. This is a good place to consider a wait-free
non-blocking data structure, or a rwlock with writer prioritization.
At any rate, a good design is needed here with some careful thought.

> Maybe we don't have to re-invent the wheel. For example:
>
> http://www.cs.unc.edu/~bbb/feathertrace/
>
> --
> 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.
>
> ___
> 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 proposal - Runtime tracing

[Sebastian Huber]

Hello Vidushi,

the RTEMS Trace Linker is definitely an interesting tool to track down 
difficult and specific issues. However, this is a nice to have optional 
feature from my point of view. We should focus on basic functionality 
and this is interrupt entry/exit and thread switching. This should work 
out of the box without having to compile RTEMS with specialized 
configuration options. It should work via a serial line and network (UDP 
I guess). It should also support SMP machines. This requires 
per-processor trace buffers. The trace buffer should work without locks, 
e.g. only interrupt disable/enable. I would do also a short review of 
existing trace solutions. Maybe we don't have to re-invent the wheel. 
For example:


http://www.cs.unc.edu/~bbb/feathertrace/

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

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

GSOC proposal - Runtime tracing

[Vidushi Vashishth]

Hi!

I apologise for the delay in submission. Was caught up with college project
submission.

PFA my proposal application for GSOC'18. I would appreciate insight and
suggestions.

Best,
Vidushi Vashishth

​
 GSOC_proposal_Vidushi_runtime_tracing

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

[GSoC] Proposal Drafts

[Gedare Bloom]

Aspiring GSoC Students,

I made my first pass and comments over the draft proposals linked from
https://devel.rtems.org/wiki/GSoC/2016 and you should please continue
to improve your drafts as mentors will be reading them as time
permits. If you have not started your proposal, you should be aiming
to do so in order to get useful early feedback and interest from
potential mentors.

The Google Webapp is where you make your official proposal submission.
Note that you can submit a draft there as a google doc also. Please
cross-link to the gdoc you link in the tracking table! Note that if
you submit a PDF for "Final Submission", we are *not* able to see it
until the proposal submission period ends! So, you will NOT receive
any feedback on PDF "Final" submissions, only on "Draft" submission or
your linked gdoc.

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