On 03/01/2020 18:37, Niteesh wrote: > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer <l...@c-mauderer.de > <mailto:l...@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.
The reason for using libbsd is that its already there and therefore its easy to add for all chips that are supported (and raspberry is supported in FreeBSD). U-Boot and Linux can't be used most of the time due to license issues. Both have a GPL license which isn't usable in a lot of RTEMS applications (industrial, automotive, ...). There shouldn't be any GPL code in the core repository and we tend to avoid libraries if there are alternatives. > > Christian, can you check out this https://github.com/0xabu/qemu/wiki it > partially supports > USB, can you give it a try? RTEMS with libbsd doesn't yet have a USB support committed for the raspberry. Do you mean try it with Linux or Windows? Did you already test something? What do you want to find out? > > > 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. Don't forget to add a "kernel_address=0x00200000" line if you use the linker file like it is currently there in RTEMS. > > 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. We use a lot of FreeBSD stuff (because it has a matching license and is quite well designed most of the time). So I would suggest to take a look how the FDT stuff works in FreeBSD and whether we can adopt or port the interface - maybe slightly adapted to RTEMS needs like having an early initialization for the console driver. Porting or implementing that and adapting a few drivers as proof of concept should be possible in the given time if you discuss the basic direction before the coding starts. Please note (for any project you pick): If there is some unexpected work along the way, the initial plan can be adapted. So don't be afraid that you might not manage to get everything done. In such a case you just have to talk to your mentor (which you should do anyway on a regular basis). > > 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 <ged...@rtems.org > <mailto:ged...@rtems.org> > > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>> wrote: > > > > On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote: > > > > > > On 30/12/2019 15:45, Niteesh wrote: > > > > On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> wrote: > > > > > > > > On 30/12/2019 07:25, Niteesh wrote: > > > > > > > > > > > > > > > On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault > > <dufa...@hda.com <mailto:dufa...@hda.com> > <mailto:dufa...@hda.com <mailto:dufa...@hda.com>> > > > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com> > <mailto:dufa...@hda.com <mailto:dufa...@hda.com>>> > > > > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com> > <mailto:dufa...@hda.com <mailto:dufa...@hda.com>> > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com> > <mailto:dufa...@hda.com <mailto:dufa...@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 > > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > > <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>> wrote: > > > > > > > > > > > > On 28/12/2019 07:12, Niteesh wrote: > > > > > >> > > > > > >> > > > > > >> On Sat, 28 Dec, 2019, 3:51 AM Christian Mauderer, > > > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> > > > > > >> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@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 > > > > > >> <l...@c-mauderer.de > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> > > > > > <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>> > > > > > >>> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> > > > > > <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@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@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > <mailto:devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>>> > > > > <mailto:devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > <mailto:devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@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@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > > http://lists.rtems.org/mailman/listinfo/devel > > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel