Version 122 (modified by Denis Obrezkov, on Aug 2, 2017 at 3:07:33 PM) (diff)

GSoC 2017, 1st week of the Final Phase, meeting notes from Obrezkov Denis

Google Summer of Code 2017

This page captures the students who make proposals as well as those who work on projects for RTEMS as part of GSoC 2017.

Students' Proposals

Start filling in this table for yourself as soon as possible and update as needed.

Student Completed Hello IRC Handle Proposal Title Google Docs URL
NAME Yes or No nick on #rtems Project Title Link to Google Docs for proposal (shared with mentors)
Tanu Hari Dixit Yes tokencolour RTEMS Tester Improvements
Sichen Zhao Yes sichenzhao Beagleboard BSP projects
Sagar Gupta Yes sgmonusg Raspberry Pi Improvements
Abhimanyu Rawat Yes ABresting Memory Protection
Cillian O'Donnell Yes cpod Improve Coverage Analysis Tools
Denis Obrezkov Yes embden C6x Port
Nikolay Komashinskiy Yes nikokoma TMS570 BSP improvements
Vivek Kukreja Yes vivekk Improvements to Tracing Framework
Aditya Upadhyay Yes adityau Conversion to New Test Suite
Aditya Upadhyay Yes adityau POSIX Compliance
Faizan Khan Yes faizank SD/MMC device driver for Beagelboard
Spencer Goodwin Yes sgoodwin CTF Integration
Mikail Yayla (SOCIS) Yes myay Software-Based Fault Tolerance

The columns are to be filled in as follows:

  • The Student column is for your name.
  • The Completed Hello column lets us all know whether or not you completed the mandatory Hello World project.
  • The IRC Handle column is your handle on IRC. RTEMS folks hang out in #rtems on
  • The Proposal Title should be self-explanatory.
  • The Google Docs URL is your proposal in Google Docs that can be reviewed and commented on by mentors. The proposal template should be copied and used as a baseline. This can be shared with mentors for review. Mentors can insert comments for you.

WARNING: The Google Docs version of the proposal is a WORKING copy. You MUST submit the official and final proposal using the Google site. If you do not submit the final proposal via the Google site, you cannot be considered

Students' Summer of Code Tracking Table

Students whose GSoC project is accepted by RTEMS shall fill in a slot with their information in the following table, which helps to centralize SoC Project Management.

Student Name IRC Handle Project Link Repository Link Blog Calendar
NAME nick on #rtems Link to Project Wiki page Link to project's public Github repository Link to your development blog Link to Calendar with Schedule
Cillian O'Donnell cpod Wiki Github Blog Project Timeline
Tanu Hari Dixit tokencolour Wiki Github Blog TBA
Sichen Zhao sichenzhao Wiki Github Blog TBA
Nikolay Komashinskiy nikokoma Wiki Github Blog TBA
Aditya Upadhyay adityau Wiki Github Blog TBA
Denis Obrezkov embden Wiki Github Blog Project Timeline
Spencer Goodwin spencergoodwin Wiki Github Blog TBA

The columns are to be filled in as follows:

  • The Student column is for your name.
  • The IRC Handle column is your handle on IRC. RTEMS folks hang out in #rtems on
  • The Project Link is a link to the Wiki page for your project.
  • The Repository Link is a link to the github repository for your project.
  • The Blog is a link to your blog with entries about your project. It should be updated regularly during the summer.
  • The Calendar is a link to your Google Calender with milestones and deliverables identified.

Student Status Updates

Each student has a section below for putting in notes from the weekly IRC meetings.


  • Jan 20: GSoC 2017 Page created.
  • May 24: Initial meeting held. Set meeting format and checked in with all students.
  • May 31
    • Roll call, Sichen is absent.
    • Announce one withdrawal and one pending ESA SOCIS Student.
    • Set Expectations for Successful Evaluations
      • Participating in IRC and mailing lists.
      • Attendance at weekly meetings and providing status updates.
      • Posting to Github each day of work.
    • Student updates.
  • June 7: Held Meeting.
  • June 14: Held Meeting. Reminded students of expectations for first phase evaluation, and the need to be posting to github and blog.
  • July 12: Held Meeting.
  • July 19: Held Meeting.
  • July 26: Held Meeting. Reminded students to complete phase 2 evaluations.
  • August 2
    • Announcements:
      • All GSoC students should start to prepare a Final Report for their project. Please see for the requirements. This report should go on your blog, and I also suggest you make a Google Doc of it to edit/share/have as backup.
      • Note that the final evaluation is the hardest, in which we will consider the quality of the CODE you have produced and that you have provided adequate documentation and demonstrated community engagement.
    • Student updates.

Cillian O'Donnell

  • May 24:
    • So far I have made my way through 2014 SOCIS patches and have been working through python exercises to improve my skills. The next step revives the old SOCIS from 2015, which should produce a temporary setup with rtems-test using Couverture-Qemu and generating coverage reports. Currently the SOCIS 2015 patches are applied: Left to do is 8 files with 20 rejects, currently producing build errors in rtems-tools.
  • May 31:
    • All SOCIS 2014,2015 patches are now applied and I fixed the initial build errors in covoar. Fixed some runtime errors in rtem-test and got a first run though RTEMS Tester that resulted in 446 invalid tests. All switched to dry-run due to errors in qemu.cfg. That has disappeared this morning by adding --coverage as the last flag. Problems at the moment are, some coverage code seems to run with or without the flag and Invalid path errors for SymbolSets?.cfg that covoar uses.Next week I'll continue testing and fixing the runtime errors and if I get some decent test results start comparision with regular qemu for all supported bsps.
  • June 7:
    • Fixed the problem of coverage code running with or without the --coverage flag. Submitted patches updating quick-start docs for 4.12 release. Wrote a blog post. Took a detour into rtems-testing repo, tried to fix some build problems and get do_coverage running. At the moment I've started testing with no coverage. I have some reference results for xilinx_zynq_a9_qemu from the RSB built qemu and the Couverture tests all run into qemu.cfg errors. I found 2 problems causing these, there's a GLib warning 'custom memory allocation vtable not supported' that I found some patches to fix from mainline qemu. However they remove malloc tracing to solve the problem so I'm not sure if this is a good solution for our purposes. The other problem is 'qemu: hardware error: gic_cpu_write: Bad offset 100' which I'm looking into at the moment. Next week I'm continuing testing and hopefully start the RSB support.
  • June 14:
    • I got talking to one of the Couverture devs and he pointed me towards a newer stable release that solved all the problems I was talking about last week, so none of the patches are needed now. I was then able to test all 9 common qemu machines that have rtems bsps. Good results for 3 that can be used for RTEMS Tester work and I filed tickets detailing the faults with the others. Wrote a blog post. Read the configuration section of the RSB docs, submitted some fixes. Have a fairly good idea of how the RSB builds work now and I'm starting the RSB qemu switch today.
  • June 21:
    • I have couverture-qemu building via the RSB minus the Gaisler patches. I manually applied those patches and some parts just needed to be moved and some had already been implemented in upstream couverture-qemu. I remade the patches so they cleanly apply and have emailed them to couverture dev Fabien Choteau who interestingly signed off on the original Gaisler patches, so was aware at some stage and possibly already implemented the solutions. Next week I'll try and implement the override option feature Chris mentioned, submit the RSB patches and I was thinking I might put the XML mockups together and leave them on devel to gather feedback for phase 3 and then get back to the RTEMS Tester work.
  • June 28:
    • I got the Gaisler patches to apply cleanly to upstream-qemu but failed to fix the compile issues. Luckily Frederic Konrad (couverture-dev) fixed these in I think a mornings work what I couldn't do for days. I'm waiting to hear back now if there is anything else to be done to help merge them. While waiting I wrote docs for RSB Couverture build in my wiki and I've gotten back to the RTEMS-TESTER work. Currently the --coverage flag triggers the coverage run in which calls and it makes it's way to the end of that and generates an empty html report (only headings, no data). In between this the covoar runs are all skipped due to invalid library paths to for example .../cpukit/score/libscore.a which matches exactly the path in my build tree. So I'm trying to figure out why path.exists(lib) returns false. Next week I'll keep trying to get a coverage report for Leon3, or if I hear back about the patches, I'll continue with that.
  • July 5:
    • Coverage is now running with RTEMS Tester and I have a Leon3 report for libscore.a set. There's some strange behaviour with covoar runs not always finishing and some missing Gcov files that I have detailed on devel. Apart from that it works quite well. I also found some post gsoc work by 2015 student Hermann that cleaned up hard-coded paths and other things, so I've sorted through them added what was still usable. Next week I'll try and get more detailed reports by adding more libraries to the symbol sets and fix the above issues if they need fixing. Also if those problems don't turn out to be too significant, I could start posting patches of what I have and begin the merging effort.
  • July 12:
    • I spent the week working on the 'trace block inconsistent with coverage map' problem. For all cases the trace block is 36 bytes and the coverage map is 24 bytes. I've checked 2 examples where this occurs base_sp.exe and ticker.exe. The couverture trace and the objdump look identical so theres no difference in the generation of these. The start addresses of the block always match, so it is how the end of the block is determined is the problem. From the RTEMS side, each line of the objdump is scanned until 3 items are found for a regex that determines if a new function is on this line. All 3 items match for lines that look like 4000c2cc <_Objects_Get_information_id>: and the section in question has two such lines the first which is 24 bytes until we reach this 4000c2e4 <_Objects_Get_information>: but couverture carries on until a nop at 36 bytes which creates the discrepancy. The couverture op code is 0x12 in both examples which means 'branch fully executed' and 'branch not taken'. I'm trying to find an example with op code 0x11 which would mean the 'branch was taken' and see if that changes how couverture chooses the end of the block, possibly libtests/dl04 or dl05 which I'm looking at, at the moment. Next week I'll be visiting family from Friday to Tuesday, which I mentioned before, so not a whole lot will get done this week.
  • July 19:
    • Not much change in status this week as I was on holidays for most of it. The trace block inconsistent message has been removed as it has been deemed as too restrictive a check and unneccesary. So for this week that leaves the issues Chris mentioned with the merging effort which I am working on right now and the intermittent lock up behaviour.
  • July 26
    • This week I worked on what needs to be changed before merging. I made too many changes to my main branch and broke what I had and couldn't recover. I learned a good lesson, make a branch for every small change, don't merge until fully tested and never break anything that's already working.. :) So I started again and got back to where I was fairly quickly. I fixed almost all the issues mentioned by Chris, added BSD license, remove camelCase, use error class, remove unit tests, move the coverage option out of and in general match the style that is there. I just need to hear back from him about the log output and I'm having trouble getting my global _coverage macro back working without In the mean-time I will look at the covoar lock-up problem, I'm thinking I'll try and attach gdb to the process once I get it to lock-up again and then have a look around. On the plus side of having to start again, the lock-up happens less frequently and the output was cleaned up a bit, so it turned out to be a good thing.

Denis Obrezkov

  • May 24: initial meeting. I have read documents about HiFive1 board, Freedom E310 Architecture, E31 Coreplex core. For the next week I plan:
    • to read User and Priveleged mode ISA
    • to build the toolchain
    • to check the board and its peripheral
    • to build and run in SPICE simulator Hesham's port of RTEMS for RISC-V arcitecture.
  • May 31: meeting.
    • What was done:
      • I have read privileged ISA 1.10 and user ISA 2.2.
      • I have checked that examples for my hifive1 board work (built, ran and debugged through openOCD)
      • I have built a SPIKE simulator (with some issues), built RTEMS RSB but wasn't able to build RTEMS for hifive yet.
      • The blog post was written Building SPIKE
    • The current issues:
      • some .S files aren't compiled due to unrecognized opcodes.
    • Plans for the next week:
      • to build RTEMS BSP for RISC-V and launch it in SPIKE, write a blog post about it
      • to figure out, what should be done in order to make RTEMS run on HiFive1 board
      • if I have time, I will also start trying to launch RTEMS BSP on top of the board and check that Peripheral is working.
  • June 7: meeting.
    • What was done:
      • I made RTEMS riscv-generic BSP compile and pushed my changes to Hesham's repository.
      • I created a branch in my local repository, where I am trying to build rtems bsp for HiFive1
      • I created ticker application, loaded it through openocd and gdb, and can step through it (not far though)
      • The blog post was written Building a simple RTEMS binary for HiFive1
    • The current issues:
      • it is needed to create a working linkcmd and start.S files. Gdb hangs after a long jump instruction.
    • Plans for the next week:
      • to encourage the HiFive1 community to help with problem solving
      • to try to make appropriate linkcmd and start.S files
      • to discuss with Hesham what should be done with interrupt handlers.
  • June 14: meeting.
    • What was done:
      • I figured out how interrupts in RISC-V are handled, particularly in my SoC.
      • I changed linkcmd file, so, now programs are running and gdb doesn't hang.
      • I found out how to run gdb: available gdb doesn't provide continue and until commands, so I have to use stepi command. (remark from 18.06: the continue command works.)
      • I found out that RTEMS'es workspace doesn't fit into the space allocated in linkcmd file.
    • The current issues:
      • implementation of interrupts handling is outdated (Hesham reimplements it)
      • RTEMS'es workspace doesn't fit into memory
    • Plans for the next week:
      • to shrink RTEMS'es workspace and make applications fit into memory
      • to write a summary 2-week blog post which will describe how to configure and run RTEMS on top of a HiFive1 board.
  • June 21: meeting.
    • What was done:
      • I was going to shrink RTEMS'es workspace, but instead of this me and my mentors decided to try to use RTEMS low ticker examples
      • I was able to proceed further but discovered errors during stack initialization. The issues is that my program wants to allocate 0xab817bb3 bytes, though it should allocate only 0x200 bytes. I found out that I have some mistake during the loading: when I try to do: gdb my_application, p rtems_minimum_stack_size, I obtain the legal value of 512 bytes, but after loading to the target I am getting the value of 0xab817bb3.
    • The current issues:
      • .data section is not properly initialized
    • Plans for the next week:
      • to check that .data section is properly initialized and reimplement initialization if needed
      • to produce a new linker file from template
      • since the application doesn't work - it is still needed to write a blog post.
  • June 28: meeting at the end of Phase 1 period.
    • What was done:
      • I checked .data section initialization. It will be required to rework it in order to work right with examples-v2
      • I was able to proceed further to Console initialization
      • I tried to launch minimum example, but the thread exitted with INTERNAL_ERROR_THREAD_EXITTED error
      • summarizing blog post is written: Summarizing Phase 1 results
      • evaluation on GSoC site was completed.
    • The current issues:
      • in minimum example thread exits with the error
      • console driver should be implemented
      • interrupts should be implemented.
    • Plans for the next week:
      • to enable local interrupts
      • to implement console driver
      • to figure out why thread exits with the error.
  • July 5: meeting at the Phase 2 beginning.
    • What was done:
      • I figured out how interrupts are handled in my SoC (FE310-G000)
      • I was trying to configure interrupts properly
      • I proceeded further with low ticker example
      • a blog post is written on interrupt handling in HiFive1: Working with interrupts on HiFive1
      • (after the meeting) I was able to handle interrupts in two day after the meeting commit
    • The current issues:
      • I don't have enough information for debugging, so a console driver is needed.
    • Plans for the next week:
      • to enable local interrupts
      • to implement a console driver.
  • July 12: meeting, Week 2 of Phase 2.
    • What was done:
      • I found out how to handle local interrupts, now they work
      • I've started to implement a console driver.
    • The current issues:
      • external interrupts are kept generating though they are switched off.
    • Plans for the next week:
      • to implement polled console driver and push my changes to Hesham.
  • July 19: meeting, Week 3 of Phase 2.
    • What was done:
      • I have implemented a polled uart driver ( only transmission)
      • I've started to implement a frequency oscillators set up (for setting a uart's baud rate)
      • I wasn't able to push my changes somewhere because my code now has a lot of magic constants.
    • The current issues:
      • the dummy clock driver doesn't work due to an unknown reason
      • a console driver hasn't been implemented to full extent yet (printk works, printf - doesn't)
      • uart reception is not implemented.
    • Plans for the next week:
      • to learn more about configuration options in RTEMS
      • to improve my code's quality (remove magic constants, improve code structure)
      • to implement a console driver
      • to implement reception in uart
      • to make a dummy clock driver run
      • to fill a wiki page on about HiFive1 BSP and write a blog post about Phase 2 results.
  • July 26: meeting, Last week of the Phase 2.
    • What was done:
      • I have discovered mistakes in my console driver
      • I've started to fill in my wiki-page on
      • I was trying to enable a dummy clock driver.
    • The current issues:
      • the dummy clock driver still doesn't work due to an unknown reason
      • a console driver hasn't been implemented to full extent yet (printk works, printf - doesn't)
      • uart reception is not implemented.
    • Plans for the next week:
      • implement proper interrupt handling (utilizing RTEMS interrupt handling procedure)
      • to improve my code quality (remove magic constants)
      • to implement reception in uart
      • to make an interrupt-driven clock driver run
      • to write a blog post about Phase 2 results.
  • August 2: meeting, Week 1 of The Final Phase.
    • What was done:
      • I was able to implement an interrupt-driven clock driver
      • I've started to work on the quality of my code.
    • The current issues:
      • it is needed to properly handle interrupts (add dispatch interrupt routine)
      • a console driver hasn't been implemented to full extent yet (printk works, printf - doesn't)
      • uart reception is not implemented
      • clock-driver occasionally fails and doesn't work with -Os optimization flag.
    • Plans for the next week:
      • implement proper interrupt handling (add dispatch interrupt routine)
      • to figure out why the clock driver with -Os optimization flag doesn't work
      • to improve the quality of my code (remove magic constants)
      • to implement reception in uart
      • to start preparing the Final Report.

Tanu Hari Dixit

  • May 24: Initial meeting.
    • I have gone through all the macro files in rtems-tools.git/tester/rtems/testing and we have decided to use INI files instead of YAML because we have standard support in Python for parsing INI files. PyYAML would have been a dependency which would have been difficult to handle across different hosts.
    • We have finalized on the format for the INI files. Chris already pushed "" in rtemstoolkit and this is taken out from Also the user specific configuration options--we decided we'll have a settings file that would contain user specific details.
    • I will come up with a ReST file as in an official documentation for the new macro files in ini format. I'll also start changing the .mc files.
  • May 31:
    • I had converted the documenation of rtems-tester to ReST and I had mistakenly added the rtems-logo too when it was not needed.
    • It was my first time with the Sphinx documentation of RTEMS. Though, I had worked with Sphinx before, it took me more time to come up with a suitable patch because I had to undo commits. I had less experience with that.
    • I have sent the new version of patches with the doc in line with the documentation of rtems-bsp-builder as Chris had suggested. This documentation also includes the new ini format. I would need to edit it as the format evolves in the course of the conversion.
    • Right now, I'm at converting the mc files.
    • Also I have still to ask Chris what to put on Github.
    • Chris has reviewed the changes. I need to make those changes in the doc.
    • Since the new release 4.12 is just on the horizon, I am supposed to remove the changes with INI bits and apply it as a second patch over the rest of the updated doc.
  • Jun 7:
    • Reported that I got stuck for a long time in figuring out where the changes should be so as to load a ini file.
    • Converted a few mc files to ini files
    • Reported partial success in loading defaults.ini
    • Still to put up blog posts
    • The next week to be spent on debugging

Sichen Zhao

  • May 24:Initial meeting.
    • I am working on first part of my proposal goal: i2c driver
    • So far, i have finished the i2c code, now working on create the patch and send to devel to be review.
    • I get along very well with the mentors, mentors give many advices to me during the project process, they are very enthusiastic.
    • Next week, i will focus on modify i2c patch, at the same time, i will read the USB code in FreeBSD, prepare for second part of proposal.
  • May 31.
    • Absent the meeting for the reason of focus on my paper which deadline is today.
    • I modify the i2c patch and send it to RTEMS devel.
    • I read the USB code in FreeBSD, especially the AM335x dts file which contains the IRQ vector.
    • I found the reason why my USB code can't pull the USB power pin high, and fix it. But there are a new issue occuer, the code seems stuck at somewhere, i think it should stuck at the ISR.
    • I write the blog post about my prepare works and I2C driver.
    • Next week i will try to solve the USB stuck problem, at the same time, i will keep an eye on the mailing list about my i2c patch.
  • June 7.
    • Last week, i remove the old beagle i2c file in source code, modify my i2c code and send patch to devel.
    • And i ported the AM335x USB code file(am335x_musb.c, am335x_prcm.c am335x_usbss.c etc) from FreeBSD to RTEMS-libbsd, and test it. So far the usbss and usbus has already mounted.
    • And now i have a odd problem: when the USB1 as a host and pull the USB1_DRVVBUS pin high. it generate a interrupt, but it stuck and can't go to the interrupt handler function. the interrupt is installed at am335x_musb.c. i am discuss with my mentor and maybe they can give me some advices.
    • Gedare suggested me to ask my problem on mailing list, i will do it if my mentor can fix my problem.
    • Next week, i will focus on the problem i meet, and carry on my USB work.
  • June 14.
    • Last week, i focus on the USB problem i faced: it generate a interrupt, but it stuck and can't go to the interrupt handler function.
    • I discussed with my mentor, fisrtly, we analysis the FreeBSD device tree file: dts, we think the interrupt vector 17 is not used, so we modified the the interrupt resources in nexus-devices.h, But didn't solve the problem.
    • Secondly, we modified the interrupt resource allocate function in AM335x_musb.c, the original function is bus_alloc_resource_any, i replaced it with bus_alloc_resources, but still not worked.
    • Then, i debugged the code and found the interrupt vector 19 is always occur, but we tried may ways just can't figure out the problem. I also asked in mailing list but no one responded to me.
    • So now i wanna separate the USB driver, and ported usb module one by one. i created a roadmap docs and start to implement step by step.
    • Regarding the i2c patch: my mentor Christian Mauderer had review it and the patch work fine. Now i still waiting for others to review.
    • Next week i will focus on my roadmap about USB driver, i will ported usbss driver and prcm driver to RTEMS, and create a clean patch.
  • June 21.
    • Last week, i solved the interrupt problem on USB: The reason is bsp don't check for the valid interrupt vector range in their bsp_interrupt_vector_disable/enable functions. Every one of them will most likely have a problems if someone tries to use libbsd or the interrupt server.
    • I create a patch for solve the irq issue in BBB, Then Sebastian Huber create a patch to solve this issue for all bsps.
    • Then i ported am335x prcm(power control module), scm(system control module), usbss and musb usb control driver from FreeBSD, And now RTEMS can detect USB device on BBB.
    • At last, i add umass support in nexus-devices.h, So RTEMS can mount and read USB disk on BBB.
    • Regarding the i2c patch: has been merged.
    • Next week i will create USB patch and send it to mailing list for review. And work on USB dongle driver.
    • Joel said i need write a document for using umass support on Beaglebone Black.
  • June 28.
    • last week, i create USB patch and send it to mailing list for review. Sebastian Huber said we have to make the BBB the second BSP that uses the FDT. Its good that it works now with the primitive table based Nexus, but the next step should be to use the FDT with unmodified FreeBSD driver sources.
    • So i focus on BBB FDT support, i add "bl bsp_fdt_copy" in start.S and add bsp-fdt.c in beagle, then i write a test application to test. but when my test exe(modify the testsuites/libtests/libfdt01) boot, came out a error: data abort.
    • Boot output error info:
    • I dicussed with my mentor, tried many ways but still can't figure out. So i send email to mailing list asking for help.
    • Next week, i will focus on fix FDT support issue, wait the reply from mailing list.
  • July 6
    • last week, i solve the FDT support issue, and rtems can boot from u-boot fdt.
    • Then i add fdt support for rtems-libbsd, so now libbsd mount device via fdt not nexus on beaglebone black.
    • And i add usb and umass support on the top of fdt. So rtems can mount and detect usb device(such as USB disk) via FDT.
    • I create rtems fdt patch and libbsd fdt and usb patch, sending to mailing list today for review. Sebastian give me some advices, and i am working on it. And i ask about the bin file in my 2/2 patch, and no one reply.
    • Next week, i will working on the advice about fdt and usb patch from mailing list, fix the patch and send to ml for review.
  • July 12
    • last week, i solve the dtb binary file issue. I remove my old patch about add dtb binary file in beagle/simscripts, and import the dts source file from FreeBSD to generate dtb bin file.
    • I modify the beagle/simscripts/ script, add the command to preprocess and compile dts file, then add the generated dtb binary file in image, so dd that to an SD card and boot.
    • So there are a issue arises, the license issue, these dts file is imported from FreeBSD, so how to add the licnese for these file. I think it should be discussed. Currently my way is to create a new license file to illustrate that these files are imported from FreeBSD. And these files is licensed under the terms of the GNU General Public License * version 2.
    • Then i send rtems and libbsd patch to ml yesterday, and get some feedback today, i am working on it.
    • I just get gedare's reply about dts file, and currently another way is directly add the dtb file in rtems, but this way may not be accepted either.
    • Next week, i will working on the advice about patch from mailing list, fix the patch and send to ml for review.
  • July 19
    • last week, i am working on the encrypted WiFi?: WEP and WPA.
    • Regarding the WEP: It is easy to implement and i already implemented it, connect the WEP WiFi? via shell command: ifconfig.
    • Regarding the WPA: It is much harder than WEP. On Linux, BSD, Windows and other OS, WPA is managed by wpa_supplicant software. So we need port wpa_supplicant on RTEMS.
    • Currently, we think there are some difficult points during the porting:
    • 1. "Big" operating systems like Linux, BSD or Windows clean up when a process terminates. RTEMS doesn't have a process separation (at least not on most targets). Therefore all programs have to take care to free their resources before they exit. The normal way for services is to thoroughly review them for any mallocs that are not freed again and for every open that has no close. So that will be one point of the port. Reviewing the code for resource leaks.
    • 2.RTEMS lacks of any memory protection (again: on most targets). That causes problems with every global variable. I'm not sure if it is possible that multiple instances of wpa_supplicant can run at the same time. That might could be necessary for multiple WiFi? interfaces. But if it is, we can't have any global variables. So that is the second big part.
    • Next week, i will working on the porting wpa_supplicant.
  • July 26
    • last week, i am working on the Import of WPA_supplicant.
    • My first step is import wpa_supplicant source files from FreeBSD, and compile it.
    • But during compile, there are many issues. One of these issues is libbsd include path issue, we need add a include header path to tell waf that it has to move the file into another path. As far as I can see, there is currently no support in our build system for such cases.
    • Another issues is the openssl support. WPA_supplicant need openssl support. So we have to import openssl lib from FreeBSD, and there are also many issues in the process of import and compile. So i need fix it one by one.
    • Although there are a lot of problems, i believe the work has been on the right track.
    • Next week, i will still working on the porting wpa_supplicant.
  • August 2
    • last week, i am working on the Import of WPA_supplicant.
    • And the good news is the openssl and wpa_supplicant is already basically ported to RTEMS.
    • And i add the shell command support of wpa_supplicant. So now we can use wpa_supplicant.
    • But when i enable WPA via command "wpa_supplicant -Dbsd -iwlan0 -c/media/umass-sim-0-0/wpa_supplicant.conf", there came out an error:
    • Could not open /dev/urandom.
    • wlan0: WPA: Failed to get random data for SNonce
    • It seems that wpa_supplicant is missing the /dev/urandom device. So i dont know if i need import it, and i already asked it on mailing list. And sebastian give me some advices and i will discuss it with my mentors.
    • Next week, i will working on make wpa_supplicant works.

Aditya Upadhyay

  • May 24:Initial meeting.
    • I am have completed the implementation of inttypes library. I have made a separate test within the samples testsuites named psxinttypes01.
    • I have to port inttypes.h to newlib, i am working on it.
    • I will commit the code of inttypes library in my local github repo.
    • Now i am trying to implement maths related library and will make a test for related methods.
  • May 31.
    • I have send the patch for inttypes.h related methods and its tests named as psxinttypes01 within the samples testsuites to devel and waiting to be review.
    • After review, what they suggest, i will do the changes in my code.
    • Also i will be in touch with my mentors and read others mails on devel, so that i can learn about coding style and conventions.
    • This week, I am working on maths related library and at the same time, i will port the code of inttypes.h to newlib.
    • i was having problem with newlib, and i was trying to build it using j-newlib script, But after Gedare's suggestion, I am trying to build it using RSB.
    • I will update my blog and after building of newlib, I will write the steps to build the newlib in my blog.
  • June 7.
    • i have sent the patch for inttypes to devel and wait for review again after modification suggested by Joel.
    • i am working on libm and trying to use the object file of libm in rtems and will make a test within the testsuites in rtems. But i am not sure libm.a will be accessable in rtems4.12.
    • I am having problem in building the newlib, so I have used another approach. I will apply the patches directly to RSB.
    • Next week, I will work on long double complex methods which are not in newlib and rtems.
  • June 14.
    • So far i have completed inttypes.h related methods and made a testsuite named "psxinttypes01" and it is working for rtems.
    • As Joel's suggestion, i have to use rtems_init() for all the methods in init.c file resided within psxinttypes01 testsuite.
    • I am porting the code of inttypes.h to newlib and need some reformatting, since it is third party code and sent the patches for same to newlib mailing list and need some cross checking.
    • I have ported the code of ccoshl.c from freebsd to newlib. patch has been varified and i will push it to my git repo.
    • I have to use SVN checkout for each function while porting the code from either freeBSD or netBSD.
    • This week, i will work on remaining methods from long double complex library and will port the code and send the patch.
  • June 21.
    • Last week, I have worked on inttypes and long double complex methods. I have ported the code of ccoshl, cacoshl, csqrtl, clogl and methods related to inttypes.
    • I have finally understand the building process of newlib and knew the instruction how to generate using autoreconf.
    • In newlib, i did not see stdbool.h, used in csqrtl methods, so i have used enum for boolean values as Sebastian have suggested. I have modified the ported code again. Corinna Venschen told me to not rely on c99. But they are using stdbool.h from gcc. i have used that stdbool.h in modified patch.
    • I have checked all the dependent methods what i have ported last week. I am still trying to configure SVN Checkout for freeBSD and NetBSD.
    • As Joel have told me to use rtems_init() for all the methods tested within testsuite psxinttypes01. i am working on it and investigating the similar files in testsuites.
    • This week, I will port rest of functions from long double complex methods and will apply the whole ported function patch to RSB as well as make a test for these function in RTEMS.
  • June 28.
    • Last week, I have worked on the remaining long double complex methods. 4 methods was remaining, but now i have ported all these methods and sent the patches for these methods to newlib. They have reviewed the patchs and pushed these to newlib-cygwin/master.
    • Till now, I have completed my coding phase 1 commitment.
    • Now i am working on remaining part of inttype. which is from coding phase 3. I have made tests for inttypes methods but needs some changes.
    • Some warnings from complex methods, i am trying to fix these.
    • Simultaneously, I am updating my blog and RTEMS POSIX API sheet sent by Joel.
  • July 5.
    • This week, I was not feeling well and took bed rest. I have informed my mentors about this and have not attended the meeting.
  • July 12.
    • I had ported the code for inttypes methods from mingw-w64, But after suggestion, Now i have started to port the code for inttypes from FreeBSD.
    • Code for Methods, imaxdiv and Imaxabs have ported and need not any modification according to Corinna's email.
    • But for rest of the methods, I was suggested by Corinna to use locale local thread information what is already exist in newlib. So i am trying to understand the reentrant function, and how to make a function reentrant. I am working on it.
    • With inttypes, I am simultaneously working on some other methods which are already implemented in RTEMS, and have to port the same to newlib. This will cover adjtime, chroot, calloc_r etc..
  • July 19.
    • This week i worked on inttypes methods trying to make reentrant version of these methods
    • For understanding of reentrant function, i have studied previously implemented reentrant methods in newlib.
    • I have submitted the patches to newlib mailing list for review but need to check the header file dependency.
    • I am not sure about reentrant version of inttypes.h like _inttypes.h should be in newlib or not. I am trying to figure out the existence of _inttypes.h.
    • I am also working on some methods like chroot, calloc_r.. etc.
    • I have updated my blog and post the newlib building process as well as rtems environment setup.

Spencer Goodwin

  • May 31
    • I have built RTEMS 4.12 with a version 5.12 version of Qt to run on hardware.
    • Viewing documentation of working CTF examples.
    • Starting to code.
  • June 7
    • I've narrowed my search of files the are needed to create CTF Files.
    • Viewing documentation of working CTF examples.
    • Reviewing TDR documentation.
  • June 14
    • I Learned the many tracing formats will definitely be beneficial in my final product.
    • Different formats are used for display, transport and actual tracing.
    • I've be found source files that pertain to CTF in C++ and Python.
    • BareCTF must be incorporated into my code.
  • June 28
    • Discovery of general code wrapping techniques.
    • Viewing documentation of working CTF examples.
    • Identifying CTF features documentation that is relative to this project.
  • July 12
    • Discovered the best implementation to obtain CTF integration.
    • Updated blog to include more capable interface.
    • Identified implementation to build one or multiple configuration files that pass values by reference.