Greetings. I am attempting to port Prex v0.8.1 to the TI OMAP 3530 platform (ARM Cortex A8, beagle board reference board). At this point I have the prex bootloader running successfully and the kernel running well enough to complete kernel main and launch the server tasks (boot, proc, etc...) However at this stage of the boot is where problems start to occur. I've been examining the kernel source code and I have a few questions.
One question I have is in regards to irq_lock and irq_unlock. On the surface it appears that this is a simple way to allow nested save/restore of the interrupt state (CPSR reg on ARM) down through a call stack chain. However these functions increment/decrement an integer variable that is essentially kernel global (not thread specific). What I am seeing on boot through strategic DPRINTF placement is that as soon as the scheduler is unlocked in kernel main the two kernel threads that have been started run and immediately call sched_tsleep, which increments the irq_lock variable by two (two threads). At this point other threads context switch in and the irq_lock count goes up and down but never recovers back to zero to cause the interrupt state to be restored. Also I see mixed use of irq_lock/irq_unlock and interrupt_enable/interrupt_disable. An example is in sched_tsleep (uses irq_lock/irq_unlock) compared to sched_unlock (uses interrupt_enable/disable). Is this intentional? Could you explain when each approach is appropriate? I'm having trouble following this detail in the source code. I believe my current problems with the OMAP port revolve around interrupt state management. Cheers, Josh ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Prex-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/prex-devel
