[okl4-developer] Some questions about OKL4's driver

[Geoffrey Lee]

On Wed, Dec 26, 2007 at 12:10:09AM +0800, kashin Lin wrote:
> Hi,

hi

> 
> After trying to modify some codes in
> "src/platform" to adapt okl4 to my target, i found i'm
> confused about the driver's relationship.( my target is Davinci from TI
> which has arm926ej-s and DSP inside)
> the naming example works correctly on my target now. and the following are
> my questions:
> 
> 1. in pxa's machine.py for example:
>        drivers = [timer_driver] + pxa.drivers  &
>        v2_drivers = [ ("pxa250_timer", "vtimer"), ("uart_8250", "vserial"),]
>     does "v2_driver" replace "driver" (so "driver" is no use) ?


The drivers line, from inspection, I suspect is a leftover wart from
the driverv1 days.  In the latest release of OKL4 pxa should use
driverv2 not driverv1.


> 
> 2. "Timer driver" :
>     what's the difference between "src/drivers/pxa250_timer" &
> "src/platform/pxa/pistachio/src/timer.cc"?
>     as
> i comprehend, the timer in platform/ is OS timer and responds to
> generate a period interrupt to
>     trigger scheduling in kernel. if it's right, this seems to be a
> indispensable component.
>     but why okl4 still works even i
> don't set the memory map address to OS timer correctly?


Yes, one is in the kernel the other is in userland.  The one in the
kernel has to work if you the timer tick and scheduling to work
properly.

The one in userland typically links into the timer server of Iguana
to provide timer-related functions (e.g. sleep, timeout, seconds since
boot, etc).

Not having a timer interrupt (i.e. kernel timer disabled or does not
work) means that there will be no timeslice expiry, i.e. current thread  
will run forever until explicit yield.  Note that not having a timer
interrupt is not supported.  The above, however, explains why
things may appear to work when the kernel timer driver is 
disabled or broken.

Because L4 currently requires a periodic timer tick, it is very easy
to verify whether the presence of a timer by putting in a print or a debug
breakin in the interrupt routine.  I suspect that if your timer is not
present you won't see anything.

> ( i try naming example )
>     what is the function of
> the timer in drivers/ ? does l4 kernel use this driver? for what?


The drivers in the drivers/ directory are user-level drivers.
They provide support for the various peripherials on a particular
platform (e.g. UART, LCD, touchscreen, etc)

> 
> 3. "UART driver" :
>     what's the difference between "src/drivers/uart_8250" &
> "src/platform/pxa/pistachio/kdb/console.cc"
>     it seems the printf function call is based on console.cc, so the
> output msgs from target through rs232
>     are visible only when i set the correct memory map address to it.
>     but what is the function of the uart driver in drivers/ ?
> 


One is the kernel driver.  The kernel driver is src/platform/pxa/pis...
console.cc and that handles prints that come from the kernel, including
kdb and the KDB print routines in l4/kdebug.h.

The one in drivers/ is the user-level UART driver.  This links against
the vserial program to provide a user-level UART device.

Sometimes, because some boards only have one console output UART, the
kernel driver and the user-level driver may drive the same physical
device which I think is the source of some of your confusion.

To summarize, printf() and kdb output from the kernel always go out
via the kernel driver.  When you are in userland, the things get
a bit complicated.  YOu have the option of using the L4_KDB* in 
l4/kdebug.h in which case they go out via the kernel driver, or you 
have the option of using the user-level UART device, in which case,
you go out to the user-level serial driver via vserial.


> 4. in src/platform/pxa/, there are some codes like irq.cc and intctrl.h
>  related to interrupt controller.
>     but why okl4 still works even i don't set the memory map to INT
> controller's registers correctly?
>     i add printf in OS timer's INT handler further, but no output shown.
>    so does OKL4 not use any interrupt?

The only drivers in the kernel are the console device and timer
driver and interrupt controller.  The timer interrupt is handled in-
kernel if it is a timeslice expiry.  The console device typically runs 
on polling I/O and does not use interrupts.  There is nothing to stop 
you from implementing an interrupt-driven device in the kernel at 
least for the console there is probably little reason for doing so.

If your interrupt controller driver is non-functional things will still
work, but you probably won't get very far, as soon as you try receiving
interrupts things will break.

As for your timer interrupt you probably have to get the interrupt
controller going first before looking into the timer interrupt.

	-gl

> 
> thanks for answering my questions.
> 
> 
> best regards,
> 
> kashin lin

> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer


-- 
Lalalalalalalalala...