I problem was in uart_probe, and console_select. I totally forgot about console_select changing back to pl011. The application starts without any issues https://ibb.co/PZY5BWr but *rtems_shell_wait_for_input *return unsuccessful, maybe it fails because it calls ioctl and I haven't provided a proper handler, what do you think? Now, since I know everything works I'll add in a proper AUX driver(ns16550) and test it again. And also if you remember, there was this issue of printing garbage and FATAL_SOURCE_EXCEPTION while running examples in qemu, I have run the examples multiple times on the board and no issues till now.
On Sat, Jan 4, 2020 at 8:47 AM Niteesh <gsnb...@gmail.com> wrote: > On Sat, Jan 4, 2020 at 3:34 AM Christian Mauderer <l...@c-mauderer.de> > wrote: > >> On 03/01/2020 20:17, Niteesh wrote: >> > 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 >> >> That's a great start. >> >> > 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? >> >> Exceptions should print an exception frame. So I'm not sure whether that >> is the case. Do you have some JTAG adapter that would work with OpenOCD >> or simmilar? >> > I dont have a JTAG. I going to fallback to printfs. I going to stick > printf in various places > and see where it hangs. > Do you have any other ideas? Can we use GDB? > >> > >> > >> > On Fri, Jan 3, 2020 at 11:07 PM Niteesh <gsnb...@gmail.com >> > <mailto:gsnb...@gmail.com>> 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. >> > >> > 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> >> > > <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
