Lecture notes

Lecture notes:

*what is relation of kernel and modules?

Ans-registration,methos,data structure,objects etc

*How do you use api without library

ans symbol table

*what is use of symbol

ans address of data or function

*difference between user space and system space

ans rules are different

image

FRAMEWORKS

-platform subsys

-usb subsys

-LLDM or Device model

-sysfs

-RTOS device model

-RTOS driver model

libraries->system call->VFS->char->my driver model->device

-----------

userspace

*OS concepts

-ISR -process schedulling

-IPC

-wake-up

-device model plays important role in embedded kernel

DERIVERS

-mainly there are three types of device drivers

1)character 2)block 3)network

-Porting involves customization of RTOS for specific board which may involve adding,integrating new set of device drivers.

EOS atch/implementation

-RTOS------->real time,embedded}they can be connected

-Embedded linux--------->

+specific bootloader

+HAL will be very specific

+BSP is very specific

+booting technique is very specific

+custom lib.

MEMORY SPACE

-virtual address space---->page table------->physical address

(memory management)

KERNEL MEMORY MANAGER

-memory allocator

1)buddy allocator

-buddy allocator per zone of physical memory

-each buddy allocator has serveral levels

-each level manages true memory

-memory blocks are multiples of page size according to level each block of true memory

-using ptr to struct page we must pass it to kmap() in the case of low memory region,kmap() will extract the corresponding KVAS address

-using ptr tp struct page we must pass it to kmap() will allocate a KVAS page from KVAS

-kumap is must to use for each page frame.

Limitations:

-it provids multiple off page frames

-minimal granulity-internal fragmentation

-it only provides multiple off page frames.-external fragmentation.

2)non-config allocator

--vmalloc() the API interface

-we may request a size of a single page memory or multiple of page size memory block

-non-config memory allocation will do the following

-allocate one or more page frames,from high memory region

-allocates one or more kvas pages from VMALLOC region!!

-using the kvas pages,map the allocated page frames!!

-kvas pages are strictly contiguous and page frames are not contiguous

-in addition VMALLOC region is also used to map memory space redistor of controller is requestby device drivers once mapped logical|virtual address of VMALLOC region are used by drivers!!!

3)slab allocator

-slab allocator subsystem manage serveral slab cache allocator!!

-each slabcache allocator is provided to support memory docs of specific size or type of object.MOst slab cache allocator provides memory blocks or objects less than a page size.

-system creates serveral slab cache allocator each providing support for allocation of specific system object.

-these slab cache allocator can be used by relevant subsystem or componets

-however the slab cache allocator be used by device or other external componets

-system provides seperate slab cache allocator for device drivers or other external componets

-such generic slab cache allocator can be accessed using kmalloc api

-for eg.kmalloc(size,GFP_KERNEL)

-in the case if OBJECTA,system will round_up the size field to the nearest size slab cache allocator

-each size_n slab cache allocator is manager using a slab cache descriptor.

-each slab cache descriptor manage one or more slab!! each slab is typically

a single page frame or multiple contiguous frame.

-each slab is managed by a slab descriptor.

-each slab contains one or more objects of size.

Image 2

DEVICE MODEL

-several objects repreasenting devices.

-contains hierarchy

-contains several datastructures

-device model is built on top of several objects

-some of these are low,intermediate and high level objects

-all these objects are connected and worked together

some low level objects are

-kobjects,kset,kobj_type_attribute object,many more

-struct kobject is the most primitive object that manage a logical device or a physical device

-following are some of the characterics of kobject

1)It maintains the respective device in a herarchy

2)it maintains usage/refrence count of the respective device

3)it maintains the respective device in an aggregation

4)it enable a device to be connected to sysfs

Kset

-kset object may be used for aggregation a set of kobjects

-kobjects of a kset may also be involved in managing hierary

Kobj-type

-it is another used along with a kobject it does the following

-it enables a destination for the kobject and the respective device

-it enables the sysfs to interact with device attributes

-when we manage kset we do with kobject.

-kset can be used to manage multiple device

module----->device model---------->sysfs

-

FILE SYSTEM

-in memory

-on disk memory

-the sysfs manages and maintains metadata only in memory not on-disk

-In sysfs,a typical directory file or a regular file or a softlink are represented using sysfs_dirent object

-typically for a given kobject when a konject is registering with device model a sysfs directory file

vi fs/

-the kobject and corresponding sysfs_divert are connected to each other.

-a given kobject can have one or more attributes

-attributes are represented by struct attributes objects which are abstact

-however such abstract attributes can be associated with real attributes of physical or logical device represented by Kobject.

-In addition such attributes objects can be associated with high level attributes objects these high level attributes object will support certain methods which can be usefull

-corresponding to each attributes of a kobject there will be a sysfs regular file created under sysfs directory of the kobject

-these sys fs are children of the sysfs directory of the kobject and all these children are siblings of the same level.

-the sysfs_dirent object of an attributes as an pointer pointing toa corresponding struct attributes

-in addition,sysfs_dirent of an attribute also as pointer to sysfs_dirent of the kobject meaning parent sysfs_dirent

-let us assume we want to access a sysfs file(regular file)corresponding to an object of a device(its kobject)

vi fs/sysfs/file.c

sysfs----->kobject

sysfs------>attribute

-kobjects does not define device

another harware entity

driver_struct----->driver()

device_struct----->device()

-certain has resources detail

-blocking | wake-up

-certain loading

-assuming we have registred out platform device,if a matching/compatible driver is loaded into the system,following actions will be taken

-probe() method ,following action are typically done

-collect resources into of the specific device lock the resources

-allocates other objects buffers!!

-In addition we may have to register certain system objects with other frameworks

-we must lock the IO space or memory space or IRQ resources drivers as per rules

-to lock IO space addresses we must use request_mem_region()

-to free we may use release_region() or release_mem_region() respective

-in the case of memory space register addresses IO remap must be used to allocate and map into KVAS

-In the prob() once the basic set_up is done,we must register with another functional frame-work!!!

-Such a functional work may be a char layer or a block layer or a network layer or a RT device layer or some layer!!

Application--->RTOS interface----->RTOS kernel------>RTDM layer----->RTDM driver----->platform driver----->platform device----->platform layer------>HAL

INTRODUCTION TO SLEEPING

-if a driver method is invoked in a process context or a kernel thread context

-driver method may block the current process or kernel thread,if there are no contrains

Constrain

-if a spin-lock is up currently behold by the driver method

-if premption is disabled by the driver method

-if local has interrupts are disable by driver method

-a typical driver may maintain one or more weight queues per device in the private object!!

-however rules are different

-we must use a approval lacking mechanizm as per execution

-we may use spinlock(without disabling interrupts),if the critical section are in process context!!

-when a spinlock is acquired implicitly premption is disable

-we may use mutext if the critical section are in process context one reason may be that critical section are relative longer.

-we must use spinlocks (with interrupts disabling) if critical section are between process context and interrupt context in this case ,spinlock(with int disabling) must be done, in process contexts!!

-as per rules when code executes in one of the above critical section blocking is disallowed!!

-as per kernel language such critical section are said to be atomic context

USB DEVICE

-logical description of an USB device and its charateritics

-Their logical description|picture|characteritics is used by operating system to manage and interact with an USB device!!

-such a logical model is defined by USB specification and mainly for interfacing with os or firmware!! This logical model is very intelligent!!

-A typical USB bus is sourced by a host controller and its root-hub!!

-Host controller is typically resisdent on a less intelligent bus or a more intelligent PCI bus!!

-which means,host controller will be managed by a platform driver or a PCI driver

-In addittion Host controller will be further manage for I/O using a host controller driver

-Root-hub is a logical device of host controller manager by a Hub driver.

-In addition each USB device is treated as physical USB device containing one or more logical USB device. In most case only one logical device is present

-each USB device is manage using the USB physical device driver and one or more corresponding USB logical device drivers.Such logical device or custom drivers!!

-Each USB hub is managed using the USB physical device driver and the hub driver.

-The hub driver manages hub functionality in this context!! Hub driver plays a very important role in device management of USB bus

-A typical USB device is described by the following description implementation by the device firmware

-A device descriptor is used to describe overall charateritics of the device

-A device descriptor represents the physical USB device

-Every USB device may have one or more configuration descriptor

-A configuration descriptor defines power requirement and number of logical device support under the configuration !!

-During operation OS/USB framework will select a configuration may be modified explicitly if needed

-Assuming a configuration is selected it will support one or more interface descriptor each interface descriptor describes one logical device.

-Each logical device may contain one or more end points descriptor

-Each endpoint descriptor manages an endpoint of logical device -an endpoint may be a control endpoint or an IN endpoint or an OUT endpoint

-Every USB device as common controller endpoint known as endpoint o_default control endpoint.

-These descriptor are read/extracted by os/usb frame work ,when an usb device discovered or configured

-Each USB physical device is assigned a dynamic USB device number.This USB device number is unique for a device within usb bus.The range is 1 to 127 is -o is reserved for special address.

-Each endpoint also has an address.This includes endpoint number and endpoint direction.

-During the IO transfer USB framework and driver need to access endpoint descriptor

-To access a specific endpoint of a logical USB device of a physical USB device USB dev number and endpoint address is used

-Hub device plays an important role in device discovery and configuration.

-typically A hub device has a logical hub device .this logical hub device contain a controll end point and an interrupt end point.

-Interrupt end point provides HUB ports status change information

As per hub driver frame work int end points of all the hubs are polled periodically!!

-To do this polling USB frame work /hub driver use an interrupt URB!!In the case of interrupt URB,USB frame work will periodically generate URB request.If there is negative response ,USB request will continious

-If the response is +ve ,another polling must be initiated

-If there is +ve response the URB response is proccessed by kernel thread is woken up when needed other wise in blocked state!!

-This kernel thread continious processing the URB response if new device is connected it will be discovered and configured!!

-Descriptor are read and charactertics are understood

-Usb dev number must be assigned and configured selected

-default control end point

-an usb device is identified using info. Stored in its device descriptor and other descriptor

-in this info commonly used for idebtification is the vendor|product combination anf this combination is not used to bind physical device but used to bing logical device.

-this combination informatiojn is also encoded in the logical device driver

-struct usb_device_id{} is an object used to define supported device by the logical device driver!!

-struct usb_driver{} is allocated and initialized to repreasent an usb physical device

-struct usb_interface object represents an usb logical device .It is also connected to other objects!!

-struct usb_bus() represents an usb bus!!

-this usb_bus() object manages a tree of struct usb_device() object!!

-struct usb_hcd() -it is a superset of struct usb_bus() object!!

-struct hc_driver represents host controller driver . A pointer from USB_HCD() points to this struct hcd_driver

-struct usb_hub() repreasents a usb hub!!!

-this objects internally connects to struct usb_device of the corresponding hub_device

-struct hub_driver() is the object that represents the usb hub driver of the system

-let us typically start with usb_hub_init()

-USB_hub_init() is invoked from usb_init()

-A new kernel thread knows khubd is creaded

-khubd is associated with hub_thread()

-hub_thread() blocks and wake-up when needed when woken-up by hub driver /usb frame work

-hub_event() is the important method executed by hub_thread!

-In the hub driver the prob() method is used when a new hub us detected and the hub driver binds to the logicall devicve of the hub!!

-further invokes hub_configure()!!

-hub_configure set up an interrupt URB for the hubs interrupt end point

-hub_configure also submits the interrupt URB with the USB subsytem

-when the interrupt URB is submitted a compition handler is alsoi submitted a completion handler is a call back which will be invoked by USB frame work

There is response from the hub

-the call back method is known as hub_irq()!!it executes in interru context!!

-Hub_irq does the following action

-collects hub statyus changes went bits-stone it as part of start

RT message queues

-message queues buffer is determinitally allocated and memory

-send/receive API provides strict time-out parameter!!

image 3

GPOS RTOS

-memory protection -No memory protection

problem 1)No overhead

1)overhead 2)smaller foot print

2)footprint

Virtual machine---->physical memory manager----->provides high latency as its api are not designed for real time

RTOS scheduling policy

-typical real time PRIO based

-priority(number of priority are configurable)

-RT RR scheduling will also be supported.

-In a given implementation RR may be enabled or disabled while in free RTOS RR will be enabled if config USE_PREMPTION is

-RT task typically a given RT task will be assigned RT PRIO scheduling policy or RT policy!!

-In addition using certain system API we may provide peridic scheduling as per this our periodic task will woken-up as per period.

-When our RT task is woken-up it will be scheduled as per scheduling policy and priority

-Interrupt priority are higher than task priority

Intrrupt priority

-high dependent on port architechture

-0 is hightest and 31 is lowest

-possible interrupt priority are 0-31

-ISR with interrupt priority 5-31 may use ISR safe API

-ISR with interrupt priority ve 5 cannot use safe API

-interrupt and ISR support nesting and priotization

-RTOS API may disable harware interrupt to implement critical section code

-however they are highy port specific

-such hardware interrupts to disabling must be subject to timing contrains

-sharing interrupts is not accepted in RTOS

-In addition we pass parameter to API the current state of woken up task

-if a higher priority task is woken up and scheduler is invoked it will complete a task switching otherwise not now!!

-In the case of free_RTOS,instead of software generation interrupts is used!! this software generated interrupts is of lowest interrupts priority

-When this interrupts is service it ISR is serviced.This ISR will invoke scheduler

How does BSP differs from port layer

-Port will be modified if we move to another Arch.(port layer is HAL)

Zenomai:-

-Is a typically linux kernel suitable for hard real time os

-Still developers need real time linux a linux based RTOS!! developer using embedded linux-based

-A real-time linux + embedded linux-based

-one such real time linux implementation is know as RT-LINUX

-Another such real time linux is xenomai

-In real time linux implementation a deterministic and low latency interrupts management framwork is added using a micro-kernel or nano kernel to kernel space such a microkernel or nano kernel coexits with linux kernel but takes primary control of hardware of the system!!

-In addtion such a real time system also provides other deterministic and low latency services using a micro-kernel!!

-real time managed under this microkernel will provide real time performance

-linux kernel continious to provide non-rt services as before!!

Xenomai contains

-Task Managment

-Memory management

-IPC feature

-kernel space

userspace

-real time task may have rt task or non rt task

-user space non-rt task is managed using pd

-A userspace rt task is manged using pd and TCB

-A typical non-rt task of user space is managed using Pd and linux scheduler

-A typical RT-task of user space is manged using TCB when rt-task is executing in primary mode of xenomai envitoment

-rt task will keep on execting in primary mode until linux system call is not invoked

-Typically ono rt task is used in user space for initialization and diagnostics!!

-in xenomai rt_pipe and rt_queues are created with predefined size

-the size allocated this rt heap with the pipe/queue

-whenevr buffer is needed for rt pipe or rt queue we must allocate buffer from respective heap.Once used we must free respective buffer.