Finally, I am able to load IMAGES into Rpi3 using u-boot. But didn't check whether FDT works. I added the AUX driver from my bare-metal project for testing. I'll replace it with NS16550 soon. I loaded the fileio example and it prints the board information. Below is the link to the screenshot https://ibb.co/cJbFHqz But it's stuck there, maybe an exception was raised because I didn't modify the address for another device but not sure! Can you think of something which could have caused it?
On Fri, Jan 3, 2020 at 11:07 PM Niteesh <gsnb...@gmail.com> wrote: > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer <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. > > 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 <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>> 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>>> 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>>>> 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>>>> 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>>>>> 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>>>>>> 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>>> >> > > > > > 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> >> > > http://lists.rtems.org/mailman/listinfo/devel >> > >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel