I don't have any disassembler available to me to do it. Hook me up with
something nice cause I'd like to investigate these things ahead at times. So in
other words, no I haven't noticed the stacking of spsr or how many instructions
are available. Are these outside the normal ARM architecture?
I would've whipped up a IRQ button driver real quick and committed it but I see
I've been beaten to it while fixing playback bugs. :)
----- Original Message -----
From: Antonius Hellmann
To: Michael Sevakis ; Rockbox development
Sent: Tuesday, May 08, 2007 3:19 PM
Subject: Re: Sansa (PP502x?) GPIO interrupts in rockbox software
Yes, the CPU/COP_INT_EN are write only to my understanding. The results of
these operations can be evaluated in the CPU/COP_INT_EN_STAT. I have no idea,
why on the PP5020 this doesn't work. What I also don't understand is, that
beside CPU-/COP-registers there is a third group of unnamed registers (INT_STAT
etc).
Did you recognize, that there are at least three (may be more) different
assembler instructions to set some
groups in the cpsr data? Also interesting fact in the original sansa code is,
that they sometimes stack the spsr register in the interrupt context, probably
allowing interrupts in interrupt contexts.
Yes, I did the same dump for the cpu interrupts, which did not show any
anomalies.
And yes, CPSRs have to be completely independent between COP and CPU,
otherwise .... garbage.
The keys definitely change the HI_INT_STAT bit6. So if someone wants to
implement key/scrollwheel interrupt handling, the bit6 in the
CPU-/COP_HI_INT_EN register should do it.
----- Original Message -----
From: Michael Sevakis
To: Rockbox development
Sent: Tuesday, May 08, 2007 6:57 PM
Subject: Re: Sansa (PP502x?) GPIO interrupts in rockbox software
I find it likely there's some things that must be worked out about the
register operation - especially re: the PP5020. Don't you find it odd that
frequency scaling requires CPU/COP_INT_EN |= TIMER1_IRQ and not CPU/COP_INT_EN
= TIMER1_IRQ to keep timers running? This is of course only supposed to be
relevant to PP5020 but a core patch that doesn't bang cpsr constantly finds
that IRQs die out and the cores to not wake again in sleep_cores (this really
seems to be the reason).
Is this only COP related?
Keys bang cpsr when posting to the message queues via set_irq_level.
Is cpsr really independent on each core? It would seem there's a tie in
somehow.
Hopefully this investigation can also help get dual core working on PP5020.
Something sounds relevant.
I also noticed from your last bl/fw transition dump that the *_INT_EN
registers are sometimes read then written and not just written. Testing a read
on them seems to always read zero but that doesn't mean it has no effect.
Another question is: why do interrupts on the COP even read keys? This is
not a good condition at all. That code should absolutely be removed. COP_TIMER1
and CPU_TIMER1 and other core specific handlers should be used.
----- Original Message -----
From: Antonius Hellmann
To: Rockbox development
Sent: Tuesday, May 08, 2007 5:08 AM
Subject: Sansa (PP502x?) GPIO interrupts in rockbox software
I evaluated the cop interrupts in the current rockbox software:
After enabling the interrupts on the cop (resetting bit7 in the
corresponding cpsr)
The TIMER1 interrupts correctly lead to a call to irq().
But there are two interesting things:
1. During the measurement period the corresponding COP_INT_STAT does not
always show the bit0 set.
In fact neither COP_INT_STAT nor COP_HI_INT_STAT is set. But the timings
of the irq()-calls correspond
to the TIMER1 interrupts.
2. Pushing a key or moving the scroll wheel sets the HI_INT_STAT (and
only this register) to 0x40.
