What do you want to study in GSOC 2020?
Niteesh
gsnb.gn at gmail.com
Sat Jan 4 05:08:49 UTC 2020
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.gn at gmail.com> wrote:
> On Sat, Jan 4, 2020 at 3:34 AM Christian Mauderer <list at 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.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>> wrote:
>> >
>> > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer
>> > <list at c-mauderer.de <mailto: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>
>> > > <mailto: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>
>> > <mailto: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>>
>> > > > > <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 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>>>
>> > > > > > <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 <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>>>
>> > > > > > <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 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>>>>
>> > > > > > >> <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 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>>>>>
>> > > > > > >>> <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 <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>>>
>> > > > > <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 <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>
>> > <mailto: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/20200104/e7690175/attachment-0001.html>
More information about the devel
mailing list