As June ends, it has been a month since the end of the bonding period. In this report, we find out what the students and mentors have accomplished in that time. Personally, I am impressed with the progress they have made. I encourage the community to communicate with and challenge the students. I encourage the students to keep working and submit patches incrementally. Reviewing and merging can be time-consuming. :)

My project is on target, and I have finished my first milestone, which was to produce a refactored ready queue by June 15th. I posted the code for this in my Google project. However, since then I have re-worked the ready queue implementation in order to further improve its modularity and efficiency. The new ready queue will be part of my next milestone, which is the refactored scheduler subsystem that I have targetted for completion by July 12th.

I am wrapping up the first attempt at refactoring the scheduler subsystem, and expect that I will make my next milestone. During this period I will be preparing patches to see about merging the refactoring work with the CVS head, as my code should be supporting the existing RTEMS scheduling mechanism.

Joel adds: Gedare does not mention a couple of items. He has also submitted the SPARC64 port that he and Eugen Leontie wrote along with two BSPs. He has done previous work on adding an Earliest Deadline First (EDF) Scheduler to RTEMS and we have been contacted by a student and advisor from Portugal with other EDF implementations. These will serve as test cases for having multiple schedulers and being able to easily select one of those available.

The work is going great. The porting is nearly complete on i386, with just 2 changelists left to be added to the gofrontend, and one patch left to be added to RTEMS. The testing of the port, using the GCC Go testsuite was also started side-by-side. Most of the testcases are working fine, and some handful of testcases, which are having trouble, are being handled individually.

After handling all the testcases, patches will be sent in so that the gcc testsuite of RTEMS can handle GCC Go testing. Then, I guess, work will start on documentation.

Joel adds: He is understating how well this has gone.Most of the test failures currently are tests that either will never run on RTEMS or have heavy resource requirements. He has submitted improvements to RTEMS as well as Go and had to get FSF copyright assignment paperwork in place for part of the work.

The work is coming along nicely. I have a set of tools that help cross compile Parrot and the configuration step of parrot and the building step both currently build without errors or warnings for i386 targets.

I am currently wrestling with setting up the default filesystem for QEMU so I can begin running the parrot test suite. Once that is done I will write a script that will allow the test suite to be automatically run under QEMU. After both of those are done, I will work on simplifying the installation and building of Parrot for RTEMS and begin more in-depth documentation.

The project is on schedule. As promised in the proposal, I finished implementing aio_read(), aio_write(), aio_error(), aio_cancel() and aio_return(). There is still work to be done to ensure compatibility with the POSIX standard as defined by the Open Group and an issue with thread priorities.

I am now working on cleaning up, testing and documenting the code. Until the midterm I hope I can also make some progress on aio_init() which will offer some flexibility and optimization to the current implementation. Once this is done I can start working on notification and lio_listio().

As planned, I have been working on libcsupport and libfs in June. There has been considerable improvement in the coverage (now around 92% with -Os considering the Developmental code). _rename_r, fifo/pipe (few explanations required), error reporting have been completed, and user database access routines (getpwent.c) are on the verge of completion. A few wrapper functions have also been targeted.

Although few iterations took more time than expected, things should be moving a bit quicker now, since I have got a taste of how things work. Focus on libcsupport and libfs would continue till major / all of it is covered.

Joel adds: What Bharath does not say is that in March, the coverage percentage for the Developmental configuration was 83%. So the test coverage is moving up nicely.

The port of the NetBSD ATAPI driver's core is almost complete. There are only about 5 functions left to be ported for successful compilation and linking of ata.c, mostly NetBSD autoconf framework functions. Several NetBSD kernel functions were successfully ported and tested in RTEMS.

Once this driver part is successfully compiled I will proceed to testing it in VirtualBox. The next part to be ported will be the IDE controller drivers (pciide) that enable several ATAPI functions including DMA. Some controller drivers will be selected and ported (ICH6, pxiide?,...). Since some functions are already ported for RTEMS, this port should go faster.

Joel adds: This is an important because it adds driver support for more modern hardware.

My project is getting along as planned, the RTEMS Sequenced Initialization should be done inthe mid-term. Now the API of RTEMS Sequenced Initialization has been done, the information of how to design is put the RTEMS wiki and the code of API is put the RTEMS Bugzilla. These days I am working on the the test case of the API. The first version of test case is done and the basic function have been tested, but the code need to be improved.

So next work is to complete the test case, once the test result of the API is ok i can update the RTEMS Classic API, and POSIX API initialization calls with the Sequenced Initialization API and updating all linker command files.

Joel adds: This is an important project for Tiny/RTEMS as it helps completely drop out initialization code that is not needed by an application.

The port is on his way, UART in polled mode is working, so is the clock and timer driver. I have successfully compiled and run several samples programs like hello, ticker, nsecs, paranoia and fileio on lm32-qemu using -M milkymist -nographic arguments.

Moreover i tested hello and ticker on the real Milkymist SoC on a ML401 dev board, which worked perfectly as expected, which validates the uart and timer driver. The framebuffer driver is working, in single buffered -with flicker- mode. I have written a sample test that writes red pixels in the entire frontbuffer and it shows a really nice red screen with qemu in graphic mode :)

Next move : implementing anti-flicker by doing double or triple buffering.