"At page 146, the documentation says : Each UART has one intra-chip interrupt UARTINTR generated as the OR-ed function of its five individual interrupts.
Great, one might think there is one interrupt per UART.
However, at page 87, one can read : | IRQ 57 | OR of all PL011 UART |"
Yes. I have read that document (a lot) and initially though that they were referring to one interrupt per UART but then realised that they were referring to one interrupt for the lot. As is typical you get an interrupt for a UART and then read various registers (like the IIR in a 16550) to figure out what to do. The PL011 has a different set of registers at different offset addresses but they fundamentally do the same thing. It is unclear to me how we get from IRQ 57 to the IRQ 153 used to start the devc-serpl011 driver. I am reasonably familiar with how the interrupt system works in the Xilinx ARM systems but have yet to come to grips with it on the Pi.
"For reference the mapping is :
UART0: 0x7e201000
UART2: 0x7e201400
UART3: 0x7e201600
UART4: 0x7e201800
UART5: 0x7e201a00
"
Yes. I concur. The BSP addresses UART3 at 0xfe201600. 0x7e201600 points to the same.
"
The RPi4 BSP starts /dev/ser3
with this command line :
devc-serpl011 -b115200 -c48000000 -e -F -u3 0xfe201600,153
Int the RPi4 BSP, file src\hardware\startup\lib\public\aarch64\bcm2711.h :
/*
* UART Controllers
*/
#define BCM2711_UART0_BASE 0xfe201000
#define BCM2711_UART0_IRQ (96+57)
#define BCM2711_UART1_BASE 0xfe215000
#define BCM2711_UART1_IRQ (96+29)
#define BCM2711_UART2_BASE 0xfe201400
#define BCM2711_UART2_IRQ (96+57)
#define BCM2711_UART3_BASE 0xfe201600
#define BCM2711_UART3_IRQ (96+57)
#define BCM2711_UART4_BASE 0xfe201800
#define BCM2711_UART4_IRQ (96+57)
#define BCM2711_UART5_BASE 0xfe201a00
#define BCM2711_UART5_IRQ (96+57)
This confirms there is one interrupt for all PL011 UARTs.
"
Again, I concur. I also found this.
So I tried
devc-serpl011 -b115200 -c48000000 -e -F -u3 0xfe201800,153
and it sent it into fairy land when the InterruptAttach() call is made. If I comment it out this doesn’t happen - but of course this doesn’t help me!
So I tried changing the IRQ’s to (93+96) etc and unsurprisingly this didn’t work either. But at least the system doesn’t stop!
"When you say “no interrupts fire for me”, what do you mean exactly ?
/dev/ser3
does not work ?
Other UART drivers do not work ?
"
/dev/ser3 works fine with the base address stated as 0xfe201600. Any other of the base addresses with the IRQ as 153 does not. I try this as single instances of devc-serpl011 - I am not stringing all the address/IRQ’s along in the same instance of the driver. Although I tried…
I want to have another look at the way InterruptAttach() is being used. But right now I’m at a loss.
I have the various GPIO’s wired to provide me with Tx/Rx/GND and use a pulsed laser ranger device that works fine with /dev/ser3 at 460800,n,8,1. Unfortunately the rate is fixed. When powered up it simply starts spewing out small (4 byte) packets at a rate of 1 khz. As I said, it works fine on /dev/ser3 (devc-serpl011 … 0xfe201600,153) but not with any other base address. As I said also, it kills the entire system at the InterruptAttach() call. After a few seconds it reboots - presumably the watchdog kicks in and resets it. So something drastic is happening.
Thanks for replying so quickly Nico. I wasn’t expecting anything so fast! I put something up on the Blackberry (qnx.com) forum and didn’t get any response at all. If I can’t figure this out using informal processes I guess I will have to annoy someone at Blackberry as I do have a support plan with them. But I do try to sort these kinds of things out before I call on them!
Geoff.