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

[kashin Lin]

Hi Geoffrey,

thanks for your detailed description.
i will try it out to make timer and interrupt controller work correctly!

& Happy New Year   to all~


best,

kashin lin

2007/12/26, Geoffrey Lee <glee at ok-labs.com>:
>
> 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...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20080102/9524652b/attachment-0001.htm