What do you want to study in GSOC 2020?
Christian Mauderer
list at c-mauderer.de
Mon Dec 30 21:47:47 UTC 2019
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.
>
> 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/
>
> >
> > > 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.
> >
>
More information about the devel
mailing list