What do you want to study in GSOC 2020?
Gedare Bloom
gedare at rtems.org
Thu Jan 2 16:37:08 UTC 2020
On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer <list at c-mauderer.de> wrote:
>
> On 30/12/2019 15:45, Niteesh wrote:
> > On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer <list at c-mauderer.de
> > <mailto:list at c-mauderer.de>> wrote:
> >
> > 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>
> > > <mailto: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 ;-)
> >
> > It is a free course on
> > coursera https://www.coursera.org/learn/build-a-computer/home/welcome
> > do check it out. It's completely simulated in software. But planning to
> > build it on PCB.
> >
> >
> > > 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.
> >
> > Thank you, it's quite good to hear.
> >
> > > 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.
> >
I'll be lurking.
Infrastructure projects are nice (FDT, dynamic linking, debugger,
tracer) but need to be clearly defined ahead of time and discussed
thoroughly with the community, or you risk ending up in the "long
tedious discussions" when you should be coding.
BSP Projects are only good if they are useful. RPI3 might be useful,
although there haven't been a lot of folks clamoring for it.
> > Once I finish with the raspberry pi, I will try to port RTEMS for esp32.
> > I have that board,
> > It has quite a lot of features and really good documentation. It is
> > based on xtensa CPU.
> > https://devel.rtems.org/wiki/TBR/UserManual/SupportedCPUs and is under
> > RTEMS potential port.
> >
>
> Interesting idea. You should post that as a project idea for your GSoC
> project. There are quite some points for new cores that can make a port
> very simple or hard as hell. I don't have the experience to give a good
> estimate for that core. But don't worry. I'm quite sure that this can be
> an interesting project.
>
> Just some random thoughts:
>
> - It seems that the Xtensa is supported in the official GCC since quite
> some time up to the most recent releases. That's a really good starting
> point.
>
> - The core is a commercial IP core. It might can get hard to get a
> detailed core documentation. Let's hope that there is enough community
> documentation for it.
>
> - I didn't really find the core in any other (buyable) chip but the
> ESP32. Do you know whether it is used somewhere else?
>
> - The ESP32 doesn't have too much RAM. If I've seen it right it's 520kB
> on-chip. We have smaller targets than that but it's not really much. The
> libbsd network stack will most likely never run on it. But lwIP should
> work. But I think network stack is something that won't be a topic for a
> first port anyway ;-)
>
> - The Technical Reference Manual looks reasonable detailed:
> https://docs.espressif.com/projects/esp-idf/en/latest/hw-reference/index.html
>
> - For the low level port you definitively need a hardware debugger or a
> good simulator. It seems that JTAG access is possible using OpenOCD.
> There is even an official guide from the manufacturer:
> https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/jtag-debugging/
>
A new architecture port is a worthwhile GSoC Project. There would be a
lot of learning and code generated. However as above there is a
question about utility: Will there be more than 1 xtensa user?
Historically, DPSs seem to have low demand for an RTOS like RTEMS. It
is still a good GSoC project though. One of the barriers to a new
architecture however will be testability: is there a simulator that
can be used for development/testing?
For difficulty, the thing to investigate is how complex is the
register context, interrupt handling mechanisms, memory management,
and on-chip devices (timers, etc.). Also whether or not there is a
2/3-BSD compliant port elsewhere for reusable code. The base xtensa
looks straightforward. The ESP32 is an interesting board.
> >
> > >
> > > > On Dec 28, 2019, at 05:12 , 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 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>>
> > > >> <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 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>>>
> > > >>> <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 <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>
> > <mailto: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.
> > >
> >
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
More information about the devel
mailing list