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.
