What do you want to study in GSOC 2020?
Christian Mauderer
list at c-mauderer.de
Mon Dec 30 13:44:02 UTC 2019
On 30/12/2019 07:25, Niteesh wrote:
>
>
> On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault <dufault at hda.com
> <mailto:dufault at hda.com>> wrote:
>
>
> Niteesh, what do you want to study? Go over what most interests you
> most about working in a real-time environment like RTEMS, and not
> about working on the RPI, and look at the earlier GSOC projects.
> Propose an ideal project for yourself and get some feedback.
Peter: Thanks for starting that discussion. I started to focus too much
on the running topics about small stuff that can be done as a preparation.
>
> I love learning about how the software and hardware interact, I have
> been programming from 9th grade and have a wide variety of
> interests(networking, app development). But recently I took a course
> called nandtotetris were we build an 8bit computer from scratch, we
> start with NAND gates and finally finish with a Tetris game.
That sounds like a really nice course. Most likely is ended in a bigger
pile of circuit boards to have a running processor ;-)
> Low-level
> software, systems programming, and operating systems are always quite
> fascinating for me. While learning about operating systems, I came
> across the concepts of real-time systems. Back then arduino was the only
> hardware I was having while searching for an RTOS to play with, I came
> across RTEMS. RTOS was harder for me to grasp but were always
> interesting, being a critical part of a system, I always wanted to learn
> how they worked from inside. That's what bought me to contributing to RTOS.
> I wanted to contribute to core of RTEMS, but it was a bit complex for me
> to understand, so I started with driver development for RTEMS.
That's where I started too. But don't hesitate to pick a more complex
topic if you are interested in it. From what I've seen you can read and
understand existing code quite fast compared to some other GSoC students
we had. So I would say that you have a good chance to manage complex
topics too.
> After going through some of the previous GSOC projects, BSP development
> and real-time tracing are what I find interesting. While also converting
> the console driver of rpi to FDT based one, *Christian Mauderer
> *explained how
> FDT worked in FreeBSD and Linux, and RTEMS lacked that infrastructure, I
> have no idea of how hard it would it, and if I am even capable of
> developing it. But one proposal would be to build the FDT infrastructure
> similar to FreeBSD or Linux and have the driver's probe and attach to
> the hardware.
We start to have more and more FDT based BSPs. So it would be great if
our infrastructure would improve. But like I said: Don't hesitate to
pick any other topic. Device drivers (and similar) are low hanging fruit
where it is easy to get success and it isn't very likely to start long
tedious discussions because you only touch one BSP. Therefore I tend to
suggest them for GSoC. But GSoC isn't limited to that.
So if you would like to work at any other topic like (for example)
porting a new architecture, hacking on some scheduler, do something with
the dynamic linking support, add stuff to the libdebugger, or basically
anything else: Just ask whether someone knows a topic in that area or is
interested in mentoring one you suggest. Most likely the mailing list
will become quite a bit more active again in about a week.
>
> > On Dec 28, 2019, at 05:12 , Christian Mauderer <list at c-mauderer.de
> <mailto:list at c-mauderer.de>> wrote:
> >
> > On 28/12/2019 07:12, Niteesh wrote:
> >>
> >>
> >> On Sat, 28 Dec, 2019, 3:51 AM Christian Mauderer,
> <list at c-mauderer.de <mailto:list at c-mauderer.de>
> >> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>> wrote:
> >>
> >> On 27/12/2019 19:06, Niteesh wrote:
> >>> Is there something else that I could work on? I am interested in
> >> taking
> >>> part
> >>> GSOC of 2020. And I want to learn as much as possible.
> >>
> >> Do you search tasks specific to raspberry or general ones? Do
> you search
> >> something for GSoC or just to warm up?
> >>
> >> Anything is fine as long as I am learning something. Since rpi3
> is the
> >> only hardware I have, I am interested in tasks specific to raspi and
> >> general ones which do not require any hardware.
> >
> > For raspberry I think you could continue to get it running on RPi3. My
> > suggestion would be to replace the table based initialization
> (which is
> > handled by console-termios-init.c) with one based on the fdt that is
> > similar to the one in the imx BSP. That will allow to use the same
> > binary on RPi2 and RPi3. But please do that in an extra patch
> after the
> > one that you currently have sent to the mailing list.
> >
> >
> > Some other raspberry specific topics could be the following. Note that
> > this are only suggestions. I don't want to force you to do any of them
> > if you don't like them:
> >
> > - Documentation how you run an application in QEMU / on real hardware
> > for the user manual:
> >
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi
> > (I hope I didn't miss a patch that you already sent ;-) )
> >
> > - A configuration for RTEMS tester that uses the QEMU or real hardware
> > (I think the pi3 allows network boot?). This allows regular test runs
> > for this BSP:
> > https://docs.rtems.org/branches/master/user/testing/index.html and
> > https://docs.rtems.org/branches/master/user/tools/tester.html
> >
> > - Chris created a boot image generator last year. It would be great if
> > you could add a configuration to create raspberry SD images to it:
> > https://docs.rtems.org/branches/master/user/tools/boot-image.html
> >
> > - You can pick basically any component that isn't already there and
> > integrate it. If you want to work with libbsd: Testing or porting
> > Ethernet support could be something.
> >
> > - You most likely want to do something with RPi in your GSoC too. So
> > maybe some comments ("x is already done", "y seems to be still open")
> > for the ticket for it would be nice too:
> https://devel.rtems.org/ticket/2899
> >
> >
> > For non raspberry topics: We have a lot of open bugs where everyone is
> > happy if they are closed: https://devel.rtems.org/query
> >
> > A lot of them might are even out of date and just need someone who
> reads
> > them and asks whether they can be closed.
> >
> >>
> >>
> >>>
> >>> On Fri, Dec 27, 2019 at 5:07 PM Christian Mauderer
> >> <list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> >>> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>> wrote:
> >>>
> >>> On 27/12/2019 12:20, Niteesh wrote:
> >>> > I have sent the patch. I also sent a documentation update
> >> for the
> >>> > quick-start section
> >>> > a few months ago. But no one took a look at it. Can you
> have a
> >>> look at it?
> >>>
> >>> I'll try to have a look at it soon.
> >>>
> >>> >
> >>> > https://www.mail-archive.com/devel@rtems.org/msg20965.html
> >>>
> >>> If you don't get any responses to a patch please just send a
> >> reminder
> >>> one or two weeks later. It's quite likely that the patch just
> >> slipped
> >>> the attention.
> >>>
> >>> Normally I leave documentation patches to our native speakers.
> >> They spot
> >>> a lot of errors that I won't be able to find.
> >>>
> >>> Can you please send a ping for the patch. You can add me to CC
> >> and for
> >>> this one I would suggest to CC Chris Johns too.
> >>>
> >>
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org <mailto:devel at rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc. Software and System Engineering
>
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
>
More information about the devel
mailing list