= Google Summer of Code 2015 = [[TOC(GSoC/2015, depth=2)]] This page captures the students who make proposals as well as those who work on projects for RTEMS as part of GSoC 2015. [[Image(banner-gsoc2015.png)]] = 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) ||Sujay Raj || Yes || sujayraaj || Port Monkey HTTP Server || [https://docs.google.com/document/d/1BdTmdqwQPG4GxdEa3845K6iLQfUMAGvbmVyZh-uDgRY/edit?usp=sharing proposal] ||Richa Sehgal || Yes || richashi || ~~Run Time Tracing~~ || ~~TBD~~ ||Ragunath D || Yes || ragunath || Beagle BSP improvements || [https://docs.google.com/document/d/1NxW6m8osEmjuHwz61N0FAtNasH0YMa-7UvUpoqCmM30/edit proposal] ||Andrei Popescu || Yes || andrei_ || Condition Variables || [https://docs.google.com/document/d/16EBmWcQw9YccUycofJIlwF98p21PQPq-EJXupes-K80/edit?usp=sharing proposal] ||Hesham ALMatary || Yes || Hesham || Support Rump Kernels on RTEMS || [https://docs.google.com/document/d/1V8w3uHCRjYeIZF1w3aQ0qz-goDhPh91sv7PEGYb7cEU/edit proposal] ||Ketul Shah || Yes || ketul || Beagle BSP improvements ||[https://docs.google.com/document/d/1CFv4u_SCgrHmES3eQqhRlDcKrJ1zsrbkix8hENIkXBM/edit?usp=sharing proposal] ||Yang Qiao || Yes || yangqiao || Raspberry Pi BSP improvements || [https://docs.google.com/document/d/1VrrrGbAc7pqZaZFzlvXoRfAAiGMYLuw90xYKPs-FMMU/edit?usp=sharing Proposal] ||Yurii Shevtsov || Yes || gtament || Raspberry Pi USB Support || [https://docs.google.com/document/d/1q0a53A26AedgyIiN5jwYQiS_aGbABCAc2_D7Vk1sdSU Proposal] ||Andre Marques || Yes || asuol || Raspberry Pi Low Level Peripherals and SD Card || [https://docs.google.com/document/d/11K0qU3OsbSMhNYkTTWt4kitAbd6uuJBcMfA_07Lg6j8 Proposal] ||Jarielle Catbagan || Yes || jrcatbagan || Beagle BSP improvements: Porting micromonitor to boot w/out U-boot || [https://docs.google.com/document/d/1pGQ60e5A4JcXl9_gkBEutIgb6AhiQ00MPJN6J1rSKT8/edit?usp=sharing Proposal] ||Anand Krishnan Prakash || Yes || anandkp92 || Configuration GUI || [https://docs.google.com/document/d/1OOKr9px9yYtAjUvLJM1_Js4xxsg_fXxnN3AWaf3IUp0/edit?usp=sharing Proposal] ||Saurabh Gadia || Yes || sgworks || Nested Mutexes || [https://docs.google.com/a/usc.edu/document/d/1KYp2sJ-hw-Et3e78AsbzDG4ISAbbwuDS3YdzMq05gAg/edit?usp=sharing Proposal] ||Rohini Kulkarni||Yes||krohini||Raspberry Pi 2 Support||[https://docs.google.com/document/d/1t0Qj1l5kMZhwIpot7QWYJ4S9APhd4JHv9Xz2t-9rJWA/edit?usp=sharing Proposal] ||Charith Eranga||Yes||charith||~~RTEMS Clang Support~~||~~TBD~~ ||Waleed Ziad || Yes ||waleedziad||Raspberry Pi 2 Support ||[https://docs.google.com/document/d/17FMNQcIwKTF6sDLF9SlT4R3GBWmpKbRvGijEkfV45yY/edit?usp=sharing Proposal] ||Abdelhamid Amer || Yes || abd_elhamid_ || Stack Analysis for RTEMS || [https://docs.google.com/document/d/17HahCCLfCQD4WRBGRucOTtkWw4VlRABEirunipTVdEI/edit?usp=sharing Proposal] ||Hermann Felbinger || Yes || hermann_19829 || Improve Code Coverage Analysis Meeting Aviation and Automotive Standards || [https://docs.google.com/document/d/14akfj6AIc0HBZ1ZSTc8Hp7MX8k7wrh495Jl3ngvTJDQ/edit?usp=sharing Proposal] || Carlos Falgueras || No || fark || Raspberry Pi BSP Peripherals || [https://docs.google.com/document/d/1Ezr3bseIVOceYlb-pbFJ46vsj_U-q38tPs0-409WPCw/edit?usp=sharing Proposal] || Gowtham Ashok || Yes || gwty || Merge LEON into RTEMS || [https://docs.google.com/document/d/1jq5d6ZPSAdUs31PieMez6Xbbx70HeZj-n6Vkisho-9E/edit?usp=sharing Proposal] || VARA PUNIT ASHOKBHAI || Yes || punitvara || Port RTEMS to Intel® Galileo || [https://docs.google.com/document/d/1w5nqlvOfEJ-jOC47K8NFsgTI9NeCLFKdnZYMejWEBWE/edit?usp=sharing proposal] || VARA PUNIT ASHOKBHAI || Yes || punitvara|| Development of RTEMS Board Support Package for x86_64 Architecture|| [https://docs.google.com/document/d/1eSAJcg2cFoAgleEiev-fMBEZR-MOePlQlZQckStabJo/edit?usp=sharing proposal] 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 require Hello World project. Based upon our experience, students who have successfully compiled and run an RTEMS application have a MUCH MUCH higher chance of success on the proposed project. * The ''IRC Handle'' column is your handle on IRC. RTEMS folks hang out in #rtems on freenode.net. * 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 [https://docs.google.com/document/d/1F5XCodvX8AYNqWX5ssu7dfjkmFT__83uf8ABKbB_Pkg/edit?usp=sharing 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 Melange site. If you do not submit the final proposal via the Google Melange 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 [wiki:Developer/GSoC/ProjectManagement 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 ||Yurii Shevtsov || gtament ||[https://devel.rtems.org/wiki/GSoC/2015/RaspberryPiUSBSupport Wiki]||[https://github.com/gtament/rtems-libbsd Github]|| [http://gtament-rtems.blogspot.com/ Blog] || [https://www.google.com/calendar/embed?src=jagq7dfntgaprdgsv0oer3h4uo%40group.calendar.google.com&ctz=Europe/Kiev Calendar] ||Rohini Kulkarni||krohini||[https://devel.rtems.org/wiki/GSoC/2015/RaspberryPi2Support Wiki]||[https://github.com/krohini1593/rtems/tree/rohini Github]||[http://rohiniwithrpi2.blogspot.in/p/blog-page_3.html Blog]||[https://www.google.com/calendar/embed?src=7b3ff86cvqa1npl4l08i762pus%40group.calendar.google.com&ctz=Asia/Calcutta Calendar] ||Sujay Raj||sujayraaj||[https://devel.rtems.org/wiki/GSoC/2015/Monkey Wiki] ||[https://github.com/sujayraaj/monkey Github] ||[http://beowulfgsoc2015.blogspot.in/ Blog]||TBD ||Anand Krishnan Prakash||anandkp92||[https://devel.rtems.org/wiki/GSoC/2015/GUI wiki]||[https://github.com/anandkp92/waf Github]||[https://aroadtocode.wordpress.com/ Blog]||[https://www.google.com/calendar/embed?src=a0vef436u24eg4attn3v5apvf0%40group.calendar.google.com&ctz=Asia/Calcutta Calendar] ||Saurabh Gadia||sgworks||[https://devel.rtems.org/wiki/GSoC/2015/NestedMutex Wiki]||[https://github.com/saurabhgadia4/rtems Rtems_Github] [https://github.com/saurabhgadia4/lock-model JPF]||[https://rejuvinatewithme.wordpress.com/ Blog]|| [https://www.google.com/calendar/embed?src=usc.edu_h2fh1v7t2fvvjbj1foaqlr2b08%40group.calendar.google.com&ctz=America/Los_Angeles Calendar] ||Andre Marques||asuol||https://devel.rtems.org/wiki/GSoC/2015/RaspberryPi_peripherals_and_SD_card Wiki||[https://github.com/asuol/rtems/tree/GPIO_API Github]|| [https://asuolgsoc2014.wordpress.com/ Blog] || [https://www.google.com/calendar/embed?src=15cl6f09ldthkv0h5e4c3v5vc0%40group.calendar.google.com&ctz=Europe/Lisbon Calendar] ||Jarielle Catbagan||jrcatbagan||[https://devel.rtems.org/wiki/GSoC/2015/BeagleBSPPortingUmon Wiki]|| [https://github.com/jrcatbagan/umon Github] || [http://www.jariellecatbagan.com/ Blog] || [https://www.google.com/calendar/embed?src=tj6g9qkcps98mj106fo9qmenbc%40group.calendar.google.com&ctz=America/Los_Angeles Calendar] ||Ragunath || ragunath || [https://devel.rtems.org/wiki/GSoC/2015/Beagle_BSP wiki] || [https://github.com/ragunath3252 Github] || [http://ragustechblog.blogspot.in/ Blog] || [https://www.google.com/calendar/embed?src=ragunath3252%40gmail.com&ctz=Asia/Calcutta calendar] ||Ketul Shah|| ketul || [https://devel.rtems.org/wiki/GSoC/2015/BeagleBoard_BSP Wiki] || [https://github.com/ketul93/rtems/tree/GPIO_BBB GitHub] || [https://ketulgsoc2015.wordpress.com/ Blog] || [https://www.google.com/calendar/embed?src=br16ka2307d26kg2j6cglhom8c%40group.calendar.google.com&ctz=Asia/Calcutta Calender] ||YANG Qiao|| yangqiao ||[https://devel.rtems.org/wiki/GSoC/2015/rpi_graphic Wiki] || [https://github.com/yangqiao/rtems GitHub] || [https://blog.yangqiao.fr Blog] || TBD 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 freenode.net. * 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. == Gedare == * May 19: Added the Status Updates page, and created this subsection as an example. For next week, I will talk to any students who missed the meeting and follow-up on any problems that were identified. == Andre Marques == * May 19: I have been trying to load code on the PI with openocd through JTAG, and checking the GPIO API, which will be my first task. The first step will be adding locking mechanisms, as that is one of the main features currently missing. * May 26: Missed the meeting due to a university project presentation. Continued to work with JTAG and openocd. The problem seems to lie in the GPIO pin setup for JTAG, as up until now the pins were only configured for a certain alternate function, but the corresponding pull resistors also need to be adjusted (disabled). At this point I seem to be able to send code to the PI, but cannot execute/debug it. * June 2: I have been going through the RPI GPIO API, and have added some locks on the interrupt create/disable functions and am currently evaluating the locations where locking may be needed. I have came to the conclusion that is best to define locks on API functions than on a per pin basis.At the same time I am separating the RPI specific code into separate functions, which could in the future be implemented by each BSP using the API to provide the BSP specific implementation as to provide the required GPIO functions. I intend to post this more clearly on my blog this week, and also check ketul's GPIO work on the BB so we can start to coordinate some ideas. * June 9: This week I have gathered my views on the rtems GPIO API on a blog post and continued to separate the RPI specifics from the generic code. The blog post was announced on the devel-ml yesterday, but I expect it to take a while to have some feedback. At this point the RPI code is almost completely contained on a separate file, and after that I will be adjusting the generic API to reflect the changes mentioned in the blog post regarding API and BSP initilization, and the changes in the interface with an user application. * June 16: I have completely separated the rpi code from the rtems gpio API, and the features mentioned in the last week's blog post are almost all implemented (just need to take care of some details, such as locking the data structure that keeps the GPIO status. Currently only the interrupt management is being protected by a mutex and vector enable/disable). At this time the core of the GPIO API can leave the rpi bsp to somewhere accessible by all BSPs, and may be used by others, so today and in the next very few days I will be finishing/cleaning up/adding documentation to the code, as well as updating the blog/wiki with a developers/user manual so it can be reviewed. While it is being reviewed I can then start to work on the I2C porting to the new framework. * June 23: This week I have posted patches for review regarding the RTEMS GPIO API and its rpi implementation. I have also been gathering more references/documentation to help in the I2C porting (by what I have seen only the xilinx bsp currently uses the new I2C framework). At this time I am correcting the issues/suggestions pointed on the GPIO API, and intend to send a new version of the patches tomorrow/thursday. I should have documentation (developer/user manual and/or blog/wiki page) posted this week. The I2C work can start right after, and at this point I am not expecting much trouble, but if it does I will post any problem on the ml regarding the new framework. * June 30: I have been addressing the issues/suggestions noted on the GPIO API, and am at this point writing my midterm report, which details the current state of the GPIO API. One of the reasons for this delay is a problem with the generic_isr that arised when I changed the pin state data structure, which for some reason causes a crash for no aparent reason when the application uses interrupts (e.g.: just adding a new field to the struct causes a crash when the rtems interrupt handler is called). For now I have put a dummy rtems_chain_control which is not needed, but by having it there I can continue the work, so until now I have ignored it but in the next days I will have to address it. * July 7: Updated the GPIO API to include pin groupings, allowing to write and read byte data to a series of pins which behave as a single entity. Added support for 'parallel' GPIO pin function assignment, allowing the function assignment to be set for multiple pins in a single GPIO hardware call. If a BSP does not support this feature it becomes a sequence of individual calls per pin. * July 14: I have added to the GPIO API support for pin groupings and multi-pin operations. These are useful to operate on a GPIO pin group as a if it was a single entity (i.e.: can be useful to emulate/bit-bang interfaces using GPIO pins), and also allow for fewer hardware calls. I also updated the existing data structures to optimize the memory requirements. The current state and description of the API is currently in my blog (which I have updated just a few hours ago). I have tested all the features with the Pi, and am now updating the existing API test cases. At this point the API is almost ready for another round of code review. * July 21: Corrected some bugs with GPIO multi select and group functions. Added GPIO multi read function, and changed pin state structure to an uni-dimensional array instead of a dynamic matrix. Updated pin release functions. * July 28: Yesterday I have posted in the devel ml the v2 of the GPIO patch set for RTEMS and the Pi. In the meantime I have an initial port of my I2C Pi code to the linux I2C framework, which I am testing and ironing out some issues. I say initial port because the new API allows for a number of small features that libi2c did not have such as the mangling functionality (i.e.: ignoring acknowledgement for certain messages), sending multiple messages (each may include several data packets) without start conditions in between and such. The device driver I have for my I2C testing device has also been ported to use the new framework's device API so the work can be tested. SPI is mainly waiting for the GPIO to get in, and I hope to have a go at the SD card during the weekend. * August 4: The Pi I2C bus driver is working with the linux framework, and the SPI code cleaning is almost done. Regarding the SD card the plan is to use the rtems-libbsd SD/MMC driver for the SD/MMC stack, and interface it with the Pi EMMC module to have access to the SD card. The interfacing with the EMMC module will be based on the work I did previously at the university. == Anand Krishnan Prakash == * May 19: I've looked at wxpython which I will be using to make the GUI and I'm still looking into how waf works (need to figure out how much I need to know about waf for this project). I've made a draft version of how the gui would look and now I plan to incorporate changes suggested by my mentors and also think of how the user will start/stop the GUI. * May 26: New version of gui made based on suggestions from mentors. For this week, I will look up how to go about grouping the configuration options. [https://docs.rtems.org/doc-current/share/rtems/html/c_user/Configuring-a-System.html#Configuring-a-System This] would help in that. Also plan to start coding for the same. * June 2: A basic set of groups has been made and each group is associated with a tag. I'll populate the options with the most appropriate tag/group (currently left blank) and will verify it with my mentors. * June 9: The options have been populated completely. Right now with this tentative list, we will enable each option to belong to one or more than one group. MVC Concept would be used to build the GUI. The GUI would produce the "config.cfg" file which is produced after we run the "waf config" command. * June 16: This week, I compiled the waf version and got to see what the output of the gui is supposed to be - creating the config.cfg file which is later used for waf configure. Started work on the gui. The outlay of menus are done and can be found [https://github.com/anandkp92/waf/tree/waf/gui here]. This week I plan to include tabs and other panels and complete the 'looks' of the gui. Currently Amar is creating functions that gets/sets the options. Once we both are done with our individual parts, I will incorporate the gui with these functions (in the event handlers) to get the expected version of the gui. * June 23: The 'looks' of the GUI is ready. Using functions Amar has coded, I am able to fetch all the options. Now working on creating Panels for displaying just the Boolean options. Will incorporate this into the GUI once it is done. * June 30: GUI supports Boolean and Integer options with event handlers for Reset Button and the specific radio buttons/spin controls. Next will be to include String and StringList options. Also will change the tabs to be based on groups and not types. * July 14: I have implemented GUI panels for String type options and am working on creating a smoother flow of the code and reducing the number of classes. Also working on suggestions that Thomas has provided regarding better documentation and my code. * July 28: So currently when the user opens the GUI, he will be able to choose which BSPs he wants to configure for. After that I've coded, using existing functions to get only the required parameters for those bsps - they are currently being displayed. Now I'm able to get the value from the gui. Working on updating the configuration with it. * August 4: This week, I've taken the options from the gui and am able to update on to the config.cfg file. However, I'm stuck with updating the BSP specific options and my mentors are going to look into it today and help me out. Now what essentially remains is run waf configure and waf build using the created config.cfg file. Then the task of translating the GUI and creating such a gui for user options also remain. * August 11: I have included event handlers for remaining menu items. Currently working on suggestions Thomas had given to run waf build from the gui itself. Currently the config.cfg file is created and works fine when you run waf config and waf build from the command line. Still working on translating the gui. == Saurabh Gadia == * May 19: 1. verify and freeze the proposed solution 2. Set up the essential environment. 3. Set up the blog having design docs. 4. Start working on suggested formal method of validation * May 26: Tasks accomplished last week: 1. Finalizing the design for "nested mutex" problem. 2. Creating formal documentation for the proposed solution. 3. modelling the test cases 4. Setting up the configuration environment. - Task for this week: 1. evaluate which test case is failing in testsuite(sptest) 2. Code the solution for sparc platform. 3. Validate whether the algorithm solves the problem. 4 Then move on to formal validation process as time permits. 5. Documentation on rtems wiki. * June 2: [''Accomplishments'']: Proposed solution with ppt which can be found in wiki section. working on the revised changes made to thread priority related code by sebastian. [''Next Task'']: Fix the master branch for compiling strict_order mutex configuration. Discuss the scope of JPF relating to this project. Setting up the JPF environment as means for validating the design and proposed solution. * June 9: 1. Complete the setup of JPF. 2. Re-write the test case spsem02 3. Understanding the working of JPF. 4. Work on how to emulate the behavior of nested mutex in JPF. 5. Have detailed discussion with Cyrille about further process in JPF and set the milestones accordingly. * June 16: 1. Complete the JPF coding for discussed lock-model which emulates RTEMS behavior. 2. Complete the unfinished task of confusion regarding the spsem02 test case. Get code reviewed by Cyrille for JPF and then discuss further required improvements or test scenarios. * June 23: 1.Test the code for corrected model. 2. Implement the review changes suggested by guides. 3. Try adding properties to JPF. 4. Prepare the mid-term evaluation materials. * June 30: 1. Creation and Testing of spsem03 test case suggested by Sebastian. 2. Modify the JPF to remove big lock 3. With big locks try to test under different combination of threads and locks using Verify() 4. Annotating JPF-Code * July 7: 1. Debugging a test case which is failing the model. 2. Commenting the code in comparison with RTEMS code and Annotating. 3. Model Trace Summary. 4. JPF Verify method checking which will be the final sanity test that assures 100% completeness of model and algorithm inclusive of external locking. * July 14: 1. Global lock free solution proposed and implemented. 2. Generating important testing combinations for thread-id, mutex-id, priority, etc. * July 21: 1. Working on further optimization on global lock free solution to avoid unnecessary locking. 2. Justification of each locks used in solution. 3. Lock Graph. * July 28: 1. Global-lock free was not passing all the good test cases. So modelling and implementing new solution for SMP architecture. * Aug 03: 1. Implemented global lock free solution for SMP. 2. All test cases are passing for SMP arch. 3. Need next steps for implementation in legacy RTEMS code. == Rohini Kulkarni == * May 19: Functional Pi 2. Have run benchmarks. I have been referring to TRMs for details. For next week, its completely identifying cache configurations and testing. Resolve issue faced with respect to scu implementation. * May 26: Looks like cache/mmu setup has been identified, except enabling maintenance operations. Start implementation and subsequent testing. Resolved SCU related issue. Started work with bsp hooks, first with hook 0. Identify common code with existing cortex-A9. * June 2: Tested identified cache configurations. Performance is not as expected. For next week complete cache/mmu configuration. * June 9: Follow up to improve cache/mmu configurations. Started work on SMP. Understand mailboxes and smp implementation with mailboxes. I aim to start implementation for the same this week. * June 16: Understood use of mailbox for SMP and started implementation. Achieve significant progress in terms of SMP implementation in the coming week. * June 23: Went back to cache/mmu issue. Obtained significant improvement in cache performance towards the end of the week. However the mmu_config_table for raspberry does not use the default sections for arm v7. The text section has a write permission also. The reason behind this needs to be understood. Did not go much ahead with SMP in the week. * July 28: Identified bug in cache configuration which was causing the .text section in raspberry pi map to require write permissions. One task is to submit a patch for this bug. The kernel image starts up with SMP changes. The other task is to add interprocessor interrupt for the Pi 2 SMP. * Aug 4: There was some build problem and changes were not being incorporated. I wanted to confirm that missing IPI is the problem. But the build problem was misleading so took almost the week before I was able to get sure of the problem. Next I have to see how IPI can be implemented because RPi2 does not have a GIC. Also I have moved ahead with the text section permissions issue. I could get hold of where the start up hangs though the root of the problem is yet to be identified. == Yurii Shevtsov == * May 19: I managed all compilatoin problems. So build environment is ready. Right now I'm studying libbsd, also there are few moments, concerning libbsd usage left unclear. Oh, I also have to do "paper work", like establishing blog, wikipage. * May 26: I pulled FreeBSD driver for the bcm's USB port (DWC OTG) to my libbsd fork. I'm going to port it during this week. I hope it will be able at least to enumerate devices (hub and phy). * May 33: I started porting DWC OTG driver. Now it compiles. Also I discovered I need some mailbox methods, which, as I understood, are YANG's task. He said he will finish it till this weekend. (The actual discussion is on devel). But I'm planning to try driver without those procs. So I'm working on testing app. * June 23: Running testing apps. Driver is somewhy not loading. * August 11: Made driver finally loading. But it working not as expected. Fixing == Ragunath == * May 19: First task is adding networking support. For this I will be porting ethernet driver from FreeBSD to rtems-libbsd. I have been studying some already ported drivers from FreeBSD to rtems-libbsd. Current progress,I pulled the driver from Freebsd and compiled it with the latest rtems-libbsd. Next target is to code all the rtems specific changes needed and check with the mentors whether that is sufficient.Then try to solve any issues that arises. * May 26: Added the driver to nexus files to get linked with the application as a child of nexus device.Then I defined the resource structure that defines bus handles and interrupt initialization. BBB uses SMC LAN8710A PHY. That phy driver is also ported from FreeBSD. Fixed some fdt, sysctl related changes. Now we are able to read mac address from the device. Facing a hang issue when link goes up. Currently debugging it. * June 2: Found the root cause for the hang issue. The issue is due to rx interrupt getting enabled before it is serviced. I put a temp hack fix and proceeded. I am able to go to the shell and execute commands. ifconfig of the interface works. irq's are established. Next week I will be working on the packet processing side. * June 9: I worked on packet processing this week. We are able to receive the packets and it is moved up the network stack successfully. Transmission of packets have an issue. The network stack generates packets and it reaches the driver. But the packet is not received on the external side. The stats registers shows that the packets are transferred properly. There are no crc, overrun errors. I also checked for connectivity errors using ethtool and that too was inline with working scenarios.The interface includes an Address lookup engine which decides how the packet is transmitted. This is where there is difference between working freebsd driver and rtems driver. Here rtems has some junk entries which are not part of the network. Working driver has entries for only those mac addresses for which it received packets. In rtems there are some random entries which is wrong. I am checking why it happens. I am checking working freebsd driver and checking what might be a possible issue. * June 16: Found the reason for the packet transmission issue. The issue is due to cache. Earlier it was mentioned that cache has to be disabled to make lwIP port to work. After disabling cache, ALE is filled correctly. Packets are transmitted properly. Ping, arp and dhcp were working. As decided in the meeting, I will be testing the rest of the testsuites next week. Cache will be debugged later. * June 23: Most of the testsuites passed successfully. We are able to transfer files using ftpd. We are able to telnet to the machine and execute commands. Other tests also passed successfully. Tests that yet to be tested are foobar client/server. Some tests that does nor depend on networking like media01,usb01 are skipped. ARP, PING, DHCP, FTP, TFTP are all tested and working. I will be preparing the patch and sending it next week. * June 30: Created patch for the ethernet driver and RTEMS workarounds and submitted to devel. Few comments were given and they are addressed. Sebastian suggested that it is better to fix the cache issue in driver instead of disabling the cache completely. I started to debug why cache needs to be disabled to make networking work. * July 7: I continued to debug the cache issue. The ALE entries are corrupted and random values are getting added to the ALE. The frame received on the peer end shows that packets are received from this corrupted entries. Sebastian suggested to check if_cgem driver to see how cache operations are done there. I made similar changes to flush/invalidate cache during tx/rx operations. I also made the memory used non-cacheable. But it did not give the desired result. * July 14: I continued debugging of cache issue. I could not get any significant break through. Cache flush/invalidate did not solve the issue.So it is decided to start on porting lwip to RTEMS. Since we may face similar issue there, we can progress on lwip and debug the cache issue combined with both the stacks. * July 21: I worked on porting of lwIP to RTEMS. I explored the lwip stack and understood its internals. I also read about what support an OS must provide and what are the changes needed. Then I built the lwip port and created a library. Then, I studied RTEMS resource builder & understood how third party packages are built using RSB. I created config and bset file for lwip using ntp as reference. * July 28: I was trying to run an RTEMS application based on lwip stack. I read about how to write application for lwip. I am understanding what are the basic services that needs to be enabled in RTEMS for an lwip app to run like what are the essential "CONFIGURE_" options that need to be enabled.On the cache issue side, I narrowed down the issue to TX part. After we start DMA on the transmit side, the corrupted ethernet frame is sent. I deleted the junk entries before transmitting. But after we transmit, the random entries are created by the DMA operation. * Aug 4: This week I worked on writing an application using lwip stack and RTEMS. With this I will be able to link the lwip library to an application. I started with the app and looked into how to start lwip. I found out what are the necessary “CONFIGURE_” defines for the app. Then I was able to run the app. I faced a few issues with running thethreads. I had to tweak few parameters for the threads to run. Now the app is running successfully. It is able to get the ip address from dhcp server. PING and ARP were also working. So networking is up with lwip. Though there is one issue. The threads are not preempted and I have to yield to get the next thread running. RX & TX are in separate threads so yield is necessary to make it work. Next step is to build the libraries using RSB. == Jarielle Catbagan == * May 19: Currently, I have a basic image to perform UART booting on the BBB. As of right now I am transferring my changes from the initial Umon 1.19 sources to the new revised Umon git source tree obtained from the RTEMS repos. Furthermore, I am also working on a copy of the CSB740 port by replacing the CSB740 specifics with that of the BBB/ARM Cortex-A8 while maximizing code reuse as much as possible. From now up uptil the next status update, I will continue finishing the remaining logistics of the project, continue working on the base files of Umon to get an initial image up and running while committing and pushing my changes regularly. I will draw up inspiration from existing Umon port implementations for the design of the BBB port. Finally, I will continue looking into the ARMv7A ARM Architecture Reference Manual, specifically the application level and system level architecture to help me understand the fundamentals of RTEMS and Umon. * May 26: The boot process that the AM335x/Beaglebone Black undergoes and the possible sources to boot from has been determined. The ideal boot sources to transfer and/or execute the initial image is either from a uSD or via UART. Porting Umon is underway and I am approaching the port with the notion of a top-down approach. That is starting from the entry point where program execution first starts and then traversing the source code while replacing irrelevant and integrating the essential/necessary code. In the context of the Beaglebone Black, program execution starts at rom_reset.S and then jumps to the C code initialization in start.c. My current effort is to integrate the initial functionality and mechanisms specific to the AM335x into these startup files and then have it inter-work with the existing Umon implementation. For my references, I will continue using the ARMv7A Architecture Reference Manual as well as the AM335x Technical Reference Manual, Beaglebone Black System Reference Manual, and the Umon User Manual. * June 2: During the process of converting the initialization file for running Umon from ROM (rom_reset.S) in the csb740 port to the Beaglebone Black, some existing code were reused as the processor in the csb740 port and the AM335x processor share some similarities. The reused code encompasses the fundamental and required initializations. These included retaining the stack initialization for each of the processor modes as well as setting the processor to an initial processor mode, which is supervisor mode. Right now, I am consolidating the necessary information in order to develop the mechanisms to initialize and set up the external DDR3 RAM on the board. This will provide the capability of removing an application's reliance on the limited internal SRAM Furthermore, the utilization of this external memory will allow larger images to run on the system. From the information I was able to obtain it is both practical and efficient in initalizing the external memory at a very low-level, and as a result this process will be done in rom_reset.S. Shortly after, rom_reset.S jumps to the first C-defined function start(). Mostly like the mechanisms to manipulate the external memory will be done in C. * June 9: The previous Umon image that was built was using the previous Umon 1.19 sources. The new Umon source tree, which was obtained from the RTEMS git repos, is stripped of any code that would conflict with the licenses involved. During the process where code was being removed, the directory/file structure of the new Umon source tree was shifted around to the point where a Umon image cannot be built immediately. After performing the necessary modifications, the basic Umon image that boots from UART and was built from the Umon 1.19 sources can now be built with the new Umon source tree. I have also looked more extensively in the initialization that Umon undergoes. Umon does the minimum system intializations with the ultimate goal of presenting the Umon command line to the user. As mentioned in the previous status update, in the context of the AM335x/Beaglebone Black, program execution first starts at rom_reset.S. This contains the low-level mechanisms to initialize the system. From here, a jump to the first C function start() is performed. The general order of function invocation after start() is umonBssinit() -> init0() -> init1() -> init2() -> reginit() -> init3() before finally reaching CommandLoop() where the Umon command line is presented to the user. Getting to this point is the main goal. Since I am approaching the porting process with a top-down approach, the first step would be getting umonBssInit() to function properly. Delving into the specifics of this function, it can be seen that it manipulates the memory location whose base address is 0x80000000. Referring to the AM335x TRM, this is the start location of the external DDR3 SDRAM. As of right now the main focus is performing the necessary configurations to get the external DDR3 SDRAM working before proceeding to modifying the next initialization functions along the chain previously specified. * June 16: Since the last status update, I elaborated extensively the approach that I am taking in porting Umon as well as the fundamentals of DDR3 SDRAMs which can be found in my blog. I have also consolidated all the necessary information that pertain to the composition, operation, and requirements of DDR3 and I am currently implementing the DDR3 configuration in rom_reset.S. The BBB that I have has a 512MB DDR3 SDRAM, which is the D2516EC4BXGGB from Kingston, and I have already familiarized myself with the parameters of the DDR3 as it is required during the DDR3 configuration. The memory subsystem on the AM335x, and subsequently on the BBB, that interfaces with the DDR3 SDRAM is the EMIF subsystem as specified in section 7.3 in the AM335x TRM. Fortunately, TI has a dedicated wiki that provides tips and insights on the configuration of these registers within the EMIF subsystem in order to interface with DDR3. There is also essential information in the JEDEC DDR3 Standard specification, in particular section 3.3.1, as it concisely summaries the sequence of steps required in order to reset and initialize DDR3 properly. As a result, this is also utilized as reference for the current DDR3 implementation effort. There are also the DDR PHY registers that must be configured accordingly based on the characteristics of the board where the DDR3 exists in order to ensure that proper timing is performed for all DDR transactions. Additionally, the clocks going into the DDR memory must also be configured as specified in section 7.3.3.2 in the AM335x TRM. The information that will be utilized to configure the DDR clocks is in section 8.1.6.11 in the AM335x TRM as well. Once the DDR3 configuration is implemented, a simple test that I will be performing to ensure that the DDR3 is setup properly is by manipulating predetermined values within the DDR3 memory range and then outputting the values through UART0. This memory range of the EMIF subsystem, and as a result it is also the memory that can be allocated to DDR3, is 0x80000000 - 0xBFFFFFFF. This is equivalent to 1GB. The modifications/additions to the Umon sources will be pushed accordingly. * June 23: A set of patches were submitted recently on umon-devel@ that fix up the BBB port as well as the main Umon sources to allow Umon to be built successfully. Another set of patches were also submitted that removed and replaced any irrelevant code in the BBB port. The Umon command line has been reached, but functionality is still limited. Executing some of the commands results in a data abort exception and after a substantial amount of debugging, the root cause of the problem has been determined. A multitude of solutions were proposed and formulated, but the best solution is to transition to using the RTEMS compiler instead of the default arm cross-compiler toolset that is used to build Umon. This transition will not only provide the possibility of eradicating the issues we were facing, but also to prevent any issues and complexities that could arise if we chose to transition to the RTEMS toolset later on. Expanding on the premise stated, one thing to note about this transition is that it is an attempt to see if the issues regarding the data abort exception would be rectified. As a result, I will now look into getting the Umon sources to be built using the RTEMS toolset. Once Umon can be built using the RTEMS toolset, a patch will be developed to reflect these changes. Furthermore, the previous set of patches have already been tested by Ed and now only requires some improvements, especially in the format of the code, and it should be ready to be merged with the main Umon sources. * June 30: The patches that I recently submitted creates the base directory for the BBB port, cleans up the uMon sources as well resolving the build process, and provides the first run of removing any irrelevant code and replacing it with those that are specific to the BBB/AM335x. These patches are finally merged in to the uMon master branch at the RTEMS git repos. Furthermore, uMon is now building with the RTEMS tools and this is the first step in providing a more controllable and verifiable way of building uMon. The necessary files are finally incorporated into the uMon master branch that removes uMon's external dependence on the C library provided with the RTEMS toolset. The next step is to get uMon to boot from a uSD and to push the initial version of DDR3 initialization to the Github repo. * July 7: UART0 initialization was integrated. As a result uMon can now boot from uSD. A script was created to automate the process of setting up a bootable SD card to boot uMon using either "raw" or FAT mode. Documentation was added in the BBB port to elaborate the process of how exactly an SD card is set up for either "raw" or FAT mode boot. Patches that incorporate these additions and files were submitted and have been merged. Development on DDR3 initialization has been occurring simultaneously, hence the next task is to get the DDR3 initialized properly for normal operation. * July 14: The DDR3 memory is now initialized. According to the AM335x TRM, Section 2.1 "ARM Cortex-A8 Memory Map", Table 2-1 "L3 Memory Map", DDR memories can span the range 0x80000000 - 0xBFFFFFFF. Prior to initializing the DDR3 memory, accessing a value within the memory space would result in a data abort exception to occur. Now that it is initialized, I have been able to manipulate values within the DDR3 memory space but nothing useful just yet. Now that the DDR3 is initialized, my next step is to set up the MMC interface in order to allow uMon to boot an application image from an external SD card and ultimately from the onboard eMMC memory. With the MMC interface mechanisms in place, booting RTEMS applications will be just a matter of time before it is achieved. * July 21: Currently implementing the SD/MMC interface. I am focusing first on the SD card interface and since the interface to SD and MMC are quite similar, implementing MMC is not far off. In order for the AM335x to connect to the SD card and perform communications, the SD/MMC/SDIO subsystem has to be initialized appropriately. As a result the controller that will handle communications between the AM335x and SD card must have the timing and protocol configured properly. For my reference in setting up the SD controller on the AM335x and to understand what is required to interface with an SD card I am using the AM335x TRM, Section 18 "Multimedia Card (MMC)", Physical Layer Simplified Specification Version 2.00, and SD Host Controller Simplified Specification Version 3.00. * July 28: The interface to the SD card is mostly implemented, just need to clean up the implementation before finally integrating the SD interface functionality with the main BBB port. I am currently working on the MMC interface in order to interact with the onboard eMMC. I will still be using the AM335x TRM, Section 18 "Multimedia Card (MMC)" for my reference in addition to JEDEC JESD84-A441 eMMC-Card Product Standard specification. Once I finish the SD and MMC interface, I will be pursuing Ethernet and then implementing the mechanisms in uMon to do a TFS-less boot. * August 4: Patches that implement the interface to the SD card via the "sd" command have been submitted to umon-devel@ and are now merged with the uMon master. The implementation for the interface to the onboard eMMC is finished for the most part. I am currently in the process of cleaning up the sources and preparing the patches before submitting them to umon-devel@. Once the patches are submitted, I will now be focusing on implementing the Ethernet functionality. == Sujay Raj == * May 19: Got qemu networking figured, and successfully set up development environment on rtems virtual machine. Will be setting up the same on my pc. The next week will involve understanding Monkey's source code. A blog and calender will be established asap. * May 26: networked applications running (using the old stack) on my pc. Last week was spent on reading Monkey current development version's code. Initially it was planned to implement a select (2) version of the polling system. But it was concluded that select on rtems is slow and limited and hence we have to proceed with the new stack. Compiled rtems-libbsd with waf and I am in process of getting things working with it. In the next few days, I will get new stack completely covered, and focus on kqueue. * June 2: Past Week: Most of my time was spent on getting the new stack running. It installs and programs compile using it, but it is not running properly with network demos . I spent around four days working on it with no avail, presently kiwichris is working with me for getting it to work, and hopefully it will be resolved in a day or two. I started with monkey, compiling it with freebsd There weren't major issues and because of the patch kiwichris posted some time ago, things are comparatively smooth. Next Week: Working on rtems-libbsd will be on the sidelines as chris helps me set it up. I will be working solely on monkey. ( I am going to ask edsiper after the meeting about where to head next ). * June 9: Monkey Successfully running on FreeBSD. Some Kqueue tests not running for libbsd. * June 16: Continuing from last week, I figured the problem was in the kqueue test not kqueue itself. I wrote some sample kqueue tests and it worked in the demo, the demo still failing overall. I did some primary stress testing on monkey on linux using both epoll and kqueue and there were times when it failed, I reported some bugs to edsiper and he got them fixed asap ( development at monkey happens too fast ) The work on getting monkey building is nearly done. At the moment for me, it compiles completely but linking it with libc gets an error multiple definition of getreent but that will hopefully be figured out soon. Presently Monkey compiles successfully as a static library. I am looking at how this can be used. Networking with rtems-libbsd is still non-functional, and kiwichris is working on it. Seeing ragunath 's work with libbsd, I am thinking I should catch up with him and try to figure out how he got it working. * June 23: getreent issue resolved. No more need for libc to be added.Monkey successfully building for rtems. Emailed patches for review to chris. Had to discuss porting sendfile to libbsd. Next work to focus on testing monkey on qemu. Have to read about IMFS. == Ketul Shah == * May 19: Currently designing GPIO drivers for BeagleBone Black. I have already designed gpio drivers for output configuration and trying to make it more generalized API. In the next week I will be making it in generalized way according to suggestions from developers. * May 26: Currently I am tesitng my code on BBB and rectifying some errors with consulting mentors. Probably by next week we will be able to merge the code to manline and yah blog and calender I will be establishing this week. * June 2 : Almost done with the generalized gpio API and successfully tested on hardware too. My next task is to work with the GPIO Input and ADC driver development. For that I would be referring TRM of AM335X and probably by next week I will be able to have simple demo with push button on BBB. * June 9 : This week I will address most of the comments from mentors and will also coordinate with RPi student for making GPIO API more generalized. Also this week I am going to add required registers (reference:- TRM of AM335x) mapping which are required for ADC interfacing for BBB. * June 16 : I added required registers for ADC interfacing to AM335x.h. Also added locking mechanism (Mutex) for avoiding rece condition to gpio API. Next week I will try to write code for ADC input. Probably I will be able to give a small demo on ADC on my BBB in upcoming weeks. Meanwhile, I am also updating GPIO API as per mentor(s)' comment(s)/suggestion(s). * June 23 : This week I implemented basic ADC driver and tested it on BBB and found working fine. Waiting for the review(s) for the same. Meanwhile I did some code(GPIO api) cleanup and made it to follow coding conventions. Next week I will try to have some good test with the ADC driver using variable resistor and post the video. * July 28 : I referred the TRM for I2C interfacing and also got myself used to with libi2c api available. Analysed the work done by Claas Ziemke for beaglebone black. Also did communication with him for my some issues.After that I modified his work as required. So up till now I almost done with the i2c driver except adding some functions,tests and reviews. And for testing purpose I managed one adxl345 sensor which can be interfaced via I2C and it will be cool for demo. I am able to interface that sensor with my raspberry pi (raspbian OS) through I2C and got the desired output. * Aug 4 : This week I worked with I2C drivers errors fixing. Then I also worked with adxl345 driver code. I almost completed the driver code for that sensor and put that in libchip . So my next task would be to real hardware testing and making a demo on that sensor interface using designed I2C driver on BBB. Also will try to make one video for all demos on that I worked this summer. == YANG Qiao == * May 19: Mailbox and simple frambuffer implemented. Drawing pixels has tested. Next week I'll will look into the i386 bsp's code and other references for EDID retrieval, resolution autodetection and framebuffer text console implementation. * May 26: Tested the fb interfaces, read and ported part of reusable code from i386 bsp. Next week,Graphic text output would be implemented. * Jun 2: Graphic text output and its drawing implemented. Graphic output without drawing cursor has implemented (only by serial for input devices haven't been ported). Next week,communication with videocore, read EDID will be implemented and resolution autodetect would be active. Clean up and patches would take a bit more time. * Jun 9: fb graphic text console implemented. Part of useful supports for videocore, communicated by mailbox property channel, are implemented. Next week, review, discuss, cleanup all codes, write sample/tests if needed. test and create patch for mailbox, framebuffer, videocore, fbcons individually. ready to move on for graphic libraries porting. * Jun 16: Cleanup and refactory works in process. Find a better way of constructuring the mailbox buffer. Next week, look into the code structure, how the libjpeg library integrated into rsb and how to implement other graphic libraries. Continue to correct the code for the midterm review. * Jun 23: New way of constructuring the mailbox buffer waiting to be reviewed. Refactor the outch code is not done yet. Next week, get ready for the midterm review, continue to cleanup code. Try to port some graphic libraries into rsb. * July 7: Fixed some bugs and inviting more developpers to try out the graphic console . Port and test the microwindows graphic desktop environment. * Aug 10: fixed up bugs everywhere and small improvements, limited the work area memory so that we won't corrupt the GPU memory area. Added kernel commandline support.