[okl4-developer] regarding interrupts
Nelson Tam
nelson at ok-labs.com
Fri Apr 18 11:38:14 EST 2008
Hi Gabi,
On 17/04/2008, at 3:32 PM, Gabi Voiculescu wrote:
> Hi.
>
> I am struggling to get past the THRD1200 test when using
> test_libs=all on my okl4 1.5.2 release.
>
> I have two questions for you:
> *************************************************************************************
> 1. Where do I specify in the build scripts that I want to be able to
> break in the kdb using the ESC key? I remember somewhere the
> implicit platforms had this feature turned on by default. I know I
> found it a few months ago but I can't find the particular line
> again. I need to add my own platform over there. Alternatively, can
> you tell me how I can enable this feature in the build command line?
If you take a look at pistachio/SConscript, find the line where it says:
if args.get("ENABLE_KDB_CONS", True) and args.get("KDB_BREAKIN",
True) and getattr(env.machine, "kdb_breakin", True):
cppdefines += [("CONFIG_KDB_BREAKIN", 1)]
CONFIG_KDB_BREAKIN tells the kernel to check for the ESC key on the
serial console. Notice that all 3 conditions have to be true in order
for CONFIG_KDB_BREAKIN to be defined, but they are all true by default
(the last argument in each condition defines the default value).
This means that unless you explicitly define one of those conditions
to be false, the ESC key will work.
The following command line will guarantee to make ESC work:
./tools/build.py [blah] ENABLE_KDB_CONS=True KDB_BREAKIN=True
> **************************************************************************************
> 2. In platform/xxx/include/intctrl.h I have a function called
> is_irq_available().
> What is it's purpose?
> I have seen that on couple of platforms where the return from this
> function is always not null (gumstix, for example), and others on
> which certain interrupt numbers are protected (the function returns
> false for them), and as I saw in my run the interrupt is left
> disabled from then on. Why do you protect certain irq's? Or is that
> they are simply absent (register bit is not used on the platform)?
There are some interrupts that we don't expose to the user due to
various reason, usually if they are sensitive to the system, and need
to be managed by the kernel. It really depends on the platform.
In the new 2.1 release, the framework for managing interrupts is
unified, so take a look at platform/xxx/pistachio/src/interrupt.cc.
> **************************************************************************************
> 3. I need to give to the platform dependent timer driver two memory
> pages.
> I need someone to confirm I used the dx file and the scan_devices()
> function properly. The code still does not work.
>
> All the examples I see only use one (which is mapped in
> device_core.c with device_add_resource).
>
> For my goal I added the following in device_core.c' s scan_devices:
>
> ........................
> /* timer device */
> memsection_lookup((objref_t)
> env_memsection_base(iguana_getenv("OKL4_VTIMER_SERVER")),
> &server_);
> timer_server = thread_l4tid(server_);
> device_add_resource(timer_server, 0x10105000,0, MEMORY_RESOURCE,
> &env); /* sfr area for timer */
> dprintf("[device_core] timer - added resources: memory
> 0x10105000\n");
> device_add_resource(timer_server, 0x10120000,0, MEMORY_RESOURCE,
> &env); /* sfr area for Dev chip IC */
> dprintf("[device_core] timer - added resources: memory
> 0x10120000\n");
> device_add_resource(timer_server, 41,0, INTERRUPT_RESOURCE, &env);
> dprintf("[device_core] timer - added resources: irq 41\n");
> device = device_create(timer_server, &me, TIMER, &env);
> dprintf("[device_core] timer - created\n");
> timer_device = device.ref.obj;
> ..........................................
>
> As you can see, I need to add two memory resources to the driver.
> All is because I need to also use the endirq register in the driver
> and I can't simply import it with <plat/...h> because the driver is
> built separately.
>
> I have duplicated the resource and block objects in the .dx file as
> following:
>
> <resource name="main" rtype="mem_space_t" />
>
> <block name="main" space_type="mem" space="main" register_size="32">
>
> <register name="tload" offset="0x00" type="rw"/>
> <register name="tvalue" offset="0x04" type="ro"/>
>
> <!-- We only use the first timer in the dual timer module -->
> <register name="tcontrol" offset="0x08" type="rw">
> <field name="timeren" bits="7"/>
> <field name="timermode" bits="6"/>
> <field name="inten" bits="5"/>
> <field name="rsvd" bits="4"/>
> <field name="timerpre" bits="3:2"/>
> <field name="timersize" bits="1"/>
> <field name="oneshot" bits="0"/>
> </register>
>
> <register name="tintclr" offset="0x0c" type="wo">
> <field name="rsvd" bits="31:1"/>
> <field name="intclr" bits="0"/>
> </register>
>
> <register name="tris" offset="0x10" type="ro"/>
> <register name="tmis" offset="0x14" type="ro"/>
>
> <register name="tbgload" offset="0x18" type="rw"/>
> </block>
>
> <!-- this is what I need to add...a second SFR area -->
> <resource name="ic_int" rtype="mem_space_t" />
> <block name="ic_int" space_type="mem" space="ic_int"
> register_size="32">
> <register name="control" offset="0x000" type="rw">
> <field name = "rsvd" bits="31:1"/>
> <field name = "enable" bits="0"/>
> </register>
>
> <register name = "endirq" offset="0x010" type="wo">
> <field name = "raz" bits="31:13"/>
> <field name = "cpuid" bits="12:10"/>
> <field name = "intid" bits="9:0"/>
> </register>
> </block>
OK this one is interesting. We have written drivers that need to talk
to 2 non-contiguous memory regions (and even GPIO lines), but requires
a bit of work in both the driver and the virtual device server code
(in both versions 1.5 and 2.1).
I think it would take non-trivial amount of time for an engineer at
OKL, so unfortunately we can't provide a quick-and-easy solution for
you on the mailing list immediately. But please let us know how you'd
like us to help you in this regard.
--
(nt)
Nelson Tam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1560 bytes
Desc: not available
Url : http://lists.okl4.org/pipermail/developer/attachments/20080418/dfc89176/attachment.bin
More information about the Developer
mailing list