BeagleBoard/GSoC/2022 Proposal/bb-config improvements & GPIO Benchmarking

=Proposal Template = About Student: Seak Jian De Mentors: Jason Kridner Code: Wiki: GSoC:

=Status= This project is currently just a proposal.

=Proposal= Completed all the requirements listed on the ideas page. the code for the cross-compilation task can be found here submitted through the pull request #158.

About you
IRC: Jian De Github: https://github.com/Fred-JD School: Universiti Teknologi Malaysia Country: Malaysia Primary language: English, Mandarin Malay Typical work hours: 4PM - 11PM UTC +8 Previous GSoC participation: First year apply gsoc.

About your project
Project name: bb-config improvements & GPIO Benchmarking

Description
Bb-Config Improvement Beagle-config is a terminal UI to make the configuration of beaglebone devices easier and more visually.
 * Update to the latest FTXUI Version
 * Adding a graph section for ADC/DAC using FTXUI graph
 * Support for network-manager using dbus API. Talking directly to dbus saves a step and may expose a richer interface than the command line.
 * Filesystem over NFS(Network File System)
 * Enable/disable "stuff" that takes up the boot up time issue#45
 * Scan Overlays and give a selection box issue#46
 * Add support for setting custom pinmux issue#42

GPIO Benchmarking Benchmark GPIOs using the below four approaches
 * Memory-mapped GPIO with C
 * C++ with file system access
 * LKM
 * PRUs

Method of Implementation
Provide a development timeline with a milestone each of the 11 weeks and any pre-work. (A realistic timeline is critical to our selection process.)
 * 1. Benchmark how fast GPIO write
 * One pin connected and create a loop inverting the value of pin.
 * Then the frequency of the resulting oscillation reported
 * While running, check the cpu and memory usage through htop in cl


 * 2. Benchmark how fast GPIO read and write<br
 * Two pin connected one is for read and another is to write.
 * When detect signal from the read pin quickly output the loop inverted in software.
 * Then the frequency of the resulting oscillation reported
 * While running, check the cpu and memory usage through htop in cl


 * Repeat step 1 & 2 with different method of program GPIO
 * Memory Mapping (mmap)
 * Access sysfs file with C/C++
 * Loadable Kernel Module (LKM)
 * PRU-ICSS

Memory-mapped GPIO with C Will refer this https://github.com/chiragnagpal/beaglebone_mmap

Access sysfs file with C/C++ Additional programming concepts in C/C++ that can be used to create a highly efficient GPIO poll. Callback Functions POSIX threads Linux poll (sys/poll.h)
 * Callback functions are typically implemented in C++ using function pointers.
 * Function pointers are pointers that store the address of a function.
 * It allows a program to control multiple different flows of work that overlap in time. Each flow of work is referred to as a thread, and creation and control over these flows is achieved by making calls to the POSIX Threads API.
 * The poll feature allows programs to multiplex input and output through a series of file descriptors. In other words, the poll system call is analogous to select system call in working as it holds its fire for one of several file descriptors by becoming available for I/O.

Loadable Kernel Module (LKM) Linux kernel space has fully support for interrupts which makes response time faster than user space

After read through the document by Derek Molloy about implementation LKM in GPIOs. I plan to do it in 3 part the 1st part is call linux/gpio with the handler function in LKM. Then the 2nd part improve the 1st part with adding KObject Interface. Then the 3rd part will adding kthread which is real time response in the kernel space.

http://derekmolloy.ie/html/kernel_docs/ExploringBeagleBone_LKMs.pdf

Linux GPIOs can easily access by 

static inline bool gpio_is_valid(int number) static inline int gpio_request(unsigned gpio, const char *label   static inline int  gpio_direction_input(unsigned gpio)   static inline int  gpio_get_value(unsigned gpio)   static inline int  gpio_direction_output(unsigned gpio, int value)   static inline int  gpio_set_debounce(unsigned gpio, unsigned debounce)   static inline int  gpio_sysfs_set_active_low(unsigned gpio, int value)   static inline void gpio_free(unsigned gpio)   static inline int  gpio_to_irq(unsigned gpio)

The LKM driver must register a handler function for the interrupt, which defines the actions that the interrupt should perfor. the handler function is called ebb_gpio_irq_handler

static irq_handler_t ebb_gpio_irq_handler(unsigned int irq,        void *dev_id, struct pt_regs *regs) { // the actions that the interrupt should perform ... }

result = request_irq(irqNumber,        // the interrupt number        (irq_handler_t) ebb_gpio_irq_handler,// pointer to the handler        IRQF_TRIGGER_RISING,                 // interrupt on rising edge        "ebb_gpio_handler",                  // used to identify the owner        NULL);                 // *dev_id for shared interrupt lines, NULL

The ebb_gpio_irq_handler function performs the majority of the timing. The clock time is stored, and the inter-press time is determined each time that the interrupt is handled.

Kobject Interface Then next will look into the kobject interface. The infrastructure that enables sysfs to function is heavily based on the kobject interface. #define KOBJ_NAME_LEN  20 struct kobject { char              *k_name;    // kobject name pointer (not NULL) char              name[KOBJ_NAME_LEN];  // short internal name struct kref       kref;       // the reference count struct list_head  entry;      // linked list to members of the kset struct kobject    *parent;    // the parent kobject struct kset       *kset;      // kobject can be a member of a set struct kobj_type  *ktype;     // kobj_type describes object type struct dentry     *dentry;    // the sysfs directory entry };

A single kobject is mapped to /sys/ebb/ on the file system. There are five attributes associated with the kobject entry (ebb). These are diffTime, isDebounce, lastTime, ledOn, and numberPresses.

Kernel Threads Introduce the use of kernel threads, kthreads, which can be started in response to an event that occurs in our LKM kthreads are used to flash the LED at a user-defined interval.

The return of resources to the kthread scheduler is usually performed with a call to schedule #include    static struct task_struct *task;         // pointer to the thread task static int flash(void *arg) { while(!kthread_should_stop){       // kthread_stop call returns true set_current_state(TASK_RUNNING);  // prevent sleeps temporarily ...                               // state change instructions (flash) set_current_state(TASK_INTERRUPTIBLE);   // sleep but can be awoken msleep(...);                               // millisecond sleep }   }    static int __init ebb_LED_init(void) { task = kthread_run(flash, NULL, "LED_flash_thread");  // start kthread ...   }    static void __exit ebb_LED_exit(void) { kthread_stop(task);                // Stop the LED flashing kthread ...   }

Experience and approach
In 5-15 sentences, convince us you will be able to successfully complete your project in the timeline you have described.

Contingency
What will you do if you get stuck on your project and your mentor isn’t around?

Benefit
If successfully completed, what will its impact be on the BeagleBoard.org community? Include quotes from BeagleBoard.org community members who can be found on http://beagleboard.org/discuss and http://bbb.io/gsocchat.

Misc
Please complete the requirements listed on the ideas page. Provide link to pull request.

Suggestions
Is there anything else we should have asked you?