GSoC 2020: Weekly Progress

mkdir RTEMS_GSoC_2020
cd RTEMS_GSoC_2020

Project Title: BSP Buildset for EPICS

git init Project Abstract

The development of the freely available, open-source, RTEMS, solved one of the biggest obstacles that beamline researchers used to face in buying commercial Real-Time operating systems that used EPICS base software.

However, with both EPICS and RTEMS gearing up for their latest stable releases, i.e, EPICS7 and RTEMS5 respectively, they should be made fully compatible to ensure continuous support in the newer versions.

This project aims to solve this problem and create a vertically integrated BSP Build Set which will be able to create a bootable BSP image with EPICS7+RTEMS 5 that can run in a simulator. RTEMS provides RTEMS Source Builder which is a tool to build packages from source and adding packages like EPICS to the RSB as libraries is called vertical integration. This project will create build sets that stack library dependencies vertically to create a stack. The main goals of this project are to make progress for some low-barrier simulation approaches like qemu/i386, qemu/xilinx_zynq and powerpc/psim used by EPICS community and then later on move to real hardware systems.

Photo by Thomas Jensen on Unsplash

git add Week 1 Progress

The community bonding period (5th May — 1st June) was an overwhelming experience for a beginner like me. The mentors not only guided me well but also instilled me with the thought to start working in this period itself. So, I began coding work in the community period itself.

Officially the students have started coding on their Google Summer of Code’s project starting 1 June and now that the first week is already over, here’s a brief overview of the work I have done:

Target: Getting PTP support to RTEMS

What is PTP? PTP, or Precision Time Protocol, is another network-based time synchronization standard like Network Time Protocol, but instead of millisecond-level synchronization, PTP networks aim to achieve nanosecond- or even picosecond-level synchronization. For most commercial and industrial applications, NTP is more than accurate enough, but if you need even tighter synchronization and timestamping, you’ll need to migrate to a PTP server.

Why is PTP timestamping so accurate? It uses hardware timestamping instead of software, and like any other fine scientific instrument, PTP equipment is dedicated to one specialized purpose: keeping devices synchronized. For that reason alone, PTP networks have much sharper time resolutions, and unlike NTP, PTP devices will actually timestamp the amount of time that synchronization messages spend in each device, which accounts for device latency.

I first forked it from https://github.com/ptpd/ptpd. In order to customise it to work with RTEMS following files were modified: https://github.com/ptpd/ptpd/compare/master...mritunjaysharma394:master

After modification, I created a tar file so that Autoconf tools are not required. That solved the problem a little, but another error.

The work is still in progress as many errors and bugs are surfacing daily but with the active support of mentors, I hope to fix this by the end of next week.

git status

Progress:

1. Written .cfg and .bset files for ptp daemon in rtems/rsb.
2. Modification in ptpd repo to make it suitable for it to build using RSB.
3. Parallelly worked on ppsi (same PTP daemon, but alternate project) but errors again

GitHub Repo: https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:master

Blockers

1. The errors due to some discrepancies in the configure.ac file has created some trouble.
2. The netinet problem is solved. Only configurations related errors are there, which need to be worked on.

Learnings from Week 1

1. About PTP: While I had the idea of NTP earlier, but this project made me learn about the more precise Precision Time Protocol. This week, I also started learning more about how PTP works from various blogs.
2. Getting hands-on with Configure files: This was also the first time when I got the experience of writing .cfg files. I had initial hiccups but then the documentation at https://docs.rtems.org/releases/rtems-docs-4.11.2/rsb/configuration.html helped me get through them.
3. More experience with Makefiles: I also gained more experience in editing and writing Makefiles. A makefile is simply a way of associating short names, called targets, with a series of commands to execute when the action is requested. For instance, a common makefile target is “clean,” which generally performs actions that clean up after the compiler — removing object files and the resulting executable.

git add Week 2 Progress

What was the target of this week?

To try and fix the configure errors and make ptpd run possible.

The problem with configure errors was looking like a never-ending problem, till the time, Heinz guided with a great tutorial on what should be the strategy of solving these problems.

More than coding, this week was about debugging and modifying the files in ptpd directory and learning to use autoconf tools.

git status

Progress:

1. Modified source-builder/config/ptpd-2–1.cfg file to use autoconf tools when using git source.
2. Studied more about PTP through blogs and learnt about its architecture.
3. Tried to study the existing codebase of EPICS to make progress in what changes have to be done there.

Blockers:

1. Use of autoconf tools and then making it a tarball, resolved a few problems, but errors like these still came:

"/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build: 155: /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build: ../ptpd-master/configure: not found

Learnings from Week 2

1. Autotools: Autotools is composed of several tools: aclocal, autoconf, automake , belonging to two packages: Automake and Autoconf.

• Autoconf generates the configure script, from a template named configure.ac. The configure script will check all characteristics of the host system and generate the makefiles from Makefile.in templates.
• Automake is used to generate complete Makefile.in templates, following GNU standards from very simple Makefile.am templates.

Relationship between various files.

2. PTP Architecture: Understood PTP in depth this week. Not only the architecture but also on how it works and I was amazed by its design and the way it uses Hardware timestamping.

Sequence diagram showing the exchange of messages between a PTP master clock and a PTP slave clock.

At the end of these exchanges the slave clock has all four timestamps. So it can calculate the offset of it’s clock with respect to the master as

offset = (t2 + t3 — t1 — t4) /2.

git add Week 3&4(ongoing) Progress

The past couple of weeks was a little slow in progress and I not only regret it but also have fastened my belts to ensure the loss done in this week and the ongoing week is covered up in the following weeks.

The reasons for slow progress are personal. Some unfortunate events happened which affected my mental health and so much so that I was not able to timely communicate with my mentors about the things I was facing.

This was quite wrong on my part but I take up this as a challenge to finish the work in the time that was lost and ensure proper communication with the mentors.

Few Progress was still made which is as follows:

git status

Progress:

1. Tried to build ptpd by hand, the configure ran properly, however, build
   again failed with different errors.
2. I have halted the work on RSB because it is important to build the packages by hand first and I have figured it out ( a little late, I know, but better late than never :-))

Blockers:

1. No blockers as such. The blocker was my confusion to pick up RSB first and now I know that so hoping things will make progress in the right direction.

Learnings from Week 3&4(ongoing):

1. Communication: Yes, this time, it is not a technical thing. However, it is the most important thing that I learnt. Mentors are there to help, understand and empathise but it is the responsibility of the mentee to bring up the problem with them. I have learnt this lesson and after this, I will ensure daily communique with the mentors to ensure that I am progressing in the right direction
2. RSB: Revised again the role of RTEMS source builder in detail from https://docs.rtems.org/releases/rtems-docs-4.11.2/rsb/source-builder.html.

Plans for Phase 2

1. Start the work back on EPICS community codebase first. Working on files mentioned below will be a priority to get things worked.

• epics7/modules/libcom/RTEMS/posix/rtems_init.c
• epics7/modules/libcom/RTEMS/posix/rtems_netconfig.c
• epics7/configure/os/CONFIG.Common.RTEMS

2. Regular communication and documentation will be ensured.

3. Completing the buffer work and covering up things missed in Phase 1.

Thank you so much for reading the blog! This will be updated on weekly/bi-weekly basis giving the updates of what all fun I am doing this summer :-)