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