## Week 1 & 2 Updates:

- [x] Studied Zephyr RTOS Basics(Layers)
- [x] Completed Device Driver Developemnt Course
- [x] Studied EEPROM Functions
- [x] Get overview of already developed APIs.

# RTOS

What Is An RTOS?
A Real Time Operating System, commonly known as an RTOS, is a software component that rapidly switches between tasks, giving the impression that multiple programs are being executed at the same time on a single processing core.



# Zephyr RTOS

The Zephyr OS is based on a small-footprint kernel designed for use on resource-constrained and embedded systems: from simple embedded environmental sensors and LED wearables to sophisticated embedded controllers, smart watches, and IoT wireless applications.


# EEPROM Functions
* EEPROM.read(address): Reads a byte from the specified address.
* EEPROM.write(address, value): Writes a byte value to the specified address.
* EEPROM.update(address, value): Writes a byte value only if it differs from the current one.
* EEPROM.get(address, data): Reads any data type or object from EEPROM.
* EEPROM.put(address, data): Writes any data type or object to EEPROM.
* EEPROM[address]: Accesses EEPROM memory as an array.
* EEPROM.length(): Returns the number of cells in the EEPROM.

### The Zephyr kernel supports multiple architectures, including:

* ARCv2 (EM and HS) and ARCv3 (HS6X)
* ARMv6-M, ARMv7-M, and ARMv8-M (Cortex-M)
* ARMv7-A and ARMv8-A (Cortex-A, 32- and 64-bit)
* ARMv7-R, ARMv8-R (Cortex-R, 32- and 64-bit)
* Intel x86 (32- and 64-bit)
* MIPS (MIPS32 Release 1 specification)
* NIOS II Gen 2
* RISC-V (32- and 64-bit)
* SPARC V8
* Tensilica Xtensa

### Zephyr offers a number of familiar services for development:

* **Multi-threading Services** for cooperative, priority-based, non-preemptive, and preemptive threads with optional **round robin time-slicing**. Includes POSIX pthreads compatible API support.
* **Interrupt Services** for **compile-time registration** of interrupt handlers.
* **Memory Allocation Services** for **dynamic allocation** and freeing of fixed-size or **variable-size memory blocks.**
* **Inter-thread Synchronization Services** for **binary semaphores**, **counting semaphores**, and **mutex semaphores**.
* **Inter-thread Data Passing Services** for **basic message queues**, **enhanced message** queues, and **byte streams**.
* **Power Management Services** such as **overarching**, application or policy-defined, **System Power Management** and fine-grained, driver-defined, **Device Power Management**.

## TDA4VM (Dual Arm® Cortex®-A72 SoC)

TDA4VM is a part of K3 multicore soc architecture platform. The SoC's are targeted for atomotive to meet complex processing needs of modern embedded products.

## Contribution guidlines

### 1. Contributor Expectations:

- The Zephyr project encourages contributors to submit changes as smaller pull requests. (PR should be small.)

- How to define small PR: Smaller pr contain logical changes. In case adding large feature adress only smaller part.

- Multiple Commits on a Single PR:
Contributors are further encouraged to break up PRs into multiple commits.

For example, when introducing an extension to an API, contributors can break up the PR into multiple commits targeting these specific changes:

1. Introduce the new APIs, including shared devicetree bindings

2. Update driver implementation X, with driver specific devicetree bindings

3. Update driver implementation Y

4. Add tests for the new API

5. Add a sample using the API

6. Update the documentation

### 2. PR Requirement:

1. Follow [commit msg guidlines](https://docs.zephyrproject.org/latest/contribute/guidelines.html#commit-guidelines).
2. Ref [Linux kernel coding style](https://kernel.org/doc/html/latest/process/coding-style.html).

TISCI:
Texas Instruments’ System Control Interface (TISCI) defines the communication protocol between various processing entities to the System Control Entity on TI SoCs. This is a set of message formats and sequence of operations required to communicate and get system services processed from the System Control Entity in the SoC.

The block diagram of the different Hosts communicating with the System Firmware or System Controller Entity is as shown below.

A host uses multiple threads to communicate with the System Firmware. On the K3 devices the following threads are used for each host:

High priority thread write to System Firmware
Low priority thread write to System Firmware
Response thread read from System Firmware
Notification thread read from System Firmware
Notification Response thread write to System Firmware.

For messages running from MCU R5F the communication mechanism is as below:


## **firmware: ti_sci: Add support for Device control**
Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used in Texas Instrument's System on Chip (SoC) such as those
in keystone family K2G SoC to communicate between various compute
processors with a central system controller entity.

TI-SCI message protocol provides support for management of various
hardware entitites within the SoC. Add support driver to allow
communication with system controller entity within the SoC using the
mailbox client.

We introduce the fundamental device management capability support to
the driver protocol as part of this change.

[[e-mail]: Contributed device reset handling]
Signed-off-by: Dave Gerlach <[e-mail]>
Signed-off-by: Nishanth Menon <[e-mail]>

## **firmware: ti_sci: Add support for Clock control**

Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used in Texas Instrument's System on Chip (SoC) such as those
in keystone family K2G SoC to communicate between various compute
processors with a central system controller entity.

TI-SCI message protocol provides support for management of various
hardware entities within the SoC. Add support driver to allow
communication with system controller entity within the SoC using the
mailbox client.

In general, we expect to function at a device level of abstraction,
however, for proper operation of hardware blocks, many clocks directly
supplying the hardware block needs to be queried or configured.

Introduce support for the set of SCI message protocol support that
provide us with this capability.

Signed-off-by: Nishanth Menon <[e-mail]>

## Power and Clock Management
**Public APIs are provided to perform:**

1. Device Management: Enable and release a module
- This configures both power and clock details for the module and keeps track of its usage.
2. Clock Management: Control the frequency of the clock to a module.
3. Device Reset Control

## **IMP**
The TI-SCI node describes the Texas Instrument's System Controller entity node.
This parent node may optionally have additional children nodes which describe
specific functionality such as clocks, power domain, reset or additional
functionality as may be required for the SoC. This hierarchy also describes the
relationship between the TI-SCI parent node to the child node.

### *IMP DEFINATION*

Texas Instruments’ System Control Interface (TISCI) defines the communication protocol between various
processing entities to the System Control Entity on TI SoCs. This is a set of message formats and sequence of
operations required to communicate and get system services processed from the System Control Entity in the
SoC.
TISCI protocol is used to talk to the SYSFW.

## **[IMP LINK FOR API](https://software-dl.ti.com/tisci/esd/20_08_00/2_tisci_msgs/pm/clocks.html)**

## **[IMP Working](https://e2e.ti.com/support/processors-group/processors/f/processors-forum/872281/faq-what-is-dmsc-and-system-firmware-and-how-does-my-software-depend-on-it)**