What do you want to study in GSOC 2020?
Niteesh
gsnb.gn at gmail.com
Fri Jan 3 17:37:12 UTC 2020
On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer <list at c-mauderer.de>
wrote:
> On 03/01/2020 13:49, Niteesh wrote:
> > I have gone through previous year works and selected a few topics which
> > I found
> > interesting.
> > 1. Basic Support for Trace Compass #3696
> > <https://devel.rtems.org/ticket/3696>.
>
> A basic support has been added last year and Sebastian extended that
> quite a bit because we had a customer who needed it. I'm not sure what
> the current state is and whether there are tasks left that could be done
> in a GSoC project.
>
> > 2. RTEMS testing tool project #2927 <https://devel.rtems.org/ticket/2927
> >.
>
> No idea what the status is. Chris?
>
> > 3. Beagle BSP: Add a flattened device tree based initialization #3784
> > <https://devel.rtems.org/ticket/3784>.
>
> That one is open. It would include adding some infrastructure for fdt
> based drivers. In theory you could do the same project for raspberry or
> any other board.
>
> Please note Gedares comment from the previous mail:
>
> > 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.
>
>
> > 4. BSPs for Simulators #2903 <https://devel.rtems.org/ticket/2903>.
>
> That's always open.
>
> Some simulators are easy because the board is already supported and you
> only have to find out how to start it. For these a tester integration is
> a good target. But most likely that's only small stuff and should be
> only one part of a project.
>
> Other simulators are not supported yet. In that case you have to write
> some drivers which can be a good project size.
>
> > 5. Improve the Raspberry Pi BSP #2899 <
> https://devel.rtems.org/ticket/2899>.
>
> You already noted: The raspberry BSP isn't in the best shape. So it's
> quite open for improvement.
>
> I think that there is still some work getting it to run again. We don't
> have something with "*bcm*" in libbsd yet so most likely USB and
> Ethernet are not working yet. Could be still still be a nice task.
>
Why don't we use the driver's from other sources as a reference and create
our
own, for USB https://github.com/Chadderz121/csud this could be used as a
reference, U-boot, and Linux are good sources too. But is it worth the
effort for a
BSP like raspberry pi? There is also a c++ bare metal environment called
circle
https://github.com/rsta2/circle which supports USB(
https://github.com/rsta2/uspi)
and ethernet.
Christian, can you check out this https://github.com/0xabu/qemu/wiki it
partially supports
USB, can you give it a try?
>
> With the difficulties getting it to run on RPi3 or RPi4 that might could
> be also a project. It seems that they are aarch64. Also I was quite
> surprised about it I didn't find a aarch64 BSP. So that would be a new
> port.
>
Rpi3 looks for kernel7.img if it finds one, it boots into 32bit mode, so if
the, offset is the only difference
between rpi2 and rpi3 it should boot without any issues I'll try adding the
AUX uart driver
and see if it boots on Rpi3.
I would also like to discuss about the FDT infrastructure for RTEMS, I
would like to know what are
the requirements, what could be expected in a short span of 3months, what
could be used as a reference
and so on.
Note that an aarch64 port would most likely be observed with argus eyes
> because it has the potential to be a very important port. But don't let
> that keep you bag suggesting it.
>
> >
> > I would like to know what are the future plans for these topics.
> > What is the current status of USB and ethernet in raspberrypi?
> > Does the beagle BSP require hardware or is it possible to emulate it?
>
> I never used an emulator for Beagle. It seems that qemu supported it
> some when:
>
> https://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
>
> But I didn't find it in current qemu. So most likely it would need
> hardware.
>
> > Last year Vijay Kumar Banerjee worked on analysis and generation of gcov
> > reports.
> >
> > On Thu, Jan 2, 2020 at 10:07 PM Gedare Bloom <gedare at rtems.org
> > <mailto:gedare at rtems.org>> wrote:
> >
> > On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer
> > <list at c-mauderer.de <mailto: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>
> > > > <mailto: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>>
> > > > > <mailto: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>>
> > > > > <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 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>>>
> > > > > >> <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 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>>>>
> > > > > >>> <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 <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>>
> > > > <mailto: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 <mailto:devel at rtems.org>
> > > http://lists.rtems.org/mailman/listinfo/devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200103/095a30a5/attachment-0001.html>
More information about the devel
mailing list