[Solved] Linux: Confusion about IRQ Number for PL011 on Pi4/aarch64

[hmka]

Hi,

I am running RPi4 Linux (bcm2711_defconfig) under a hypervisor and I have a question about the PL011 IRQ numbers. I use PL011 as the primary UART and I disable BT.

In the DTS:

serial@7e201000 {
compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
reg = <0x7e201000 0x200>;
interrupts = <0x0 0x79 0x4>;
clocks = <0x3 0x13 0x3 0x14>;
clock-names = "uartclk", "apb_pclk";
arm,primecell-periphid = <0x241011>;
cts-event-workaround;
pinctrl-names = "default";
pinctrl-0 = <0x8 0x9>;
status = "okay";
phandle = <0x24>;
};

I interpret the interrupts property as PL011 having an IRQ number of 153. Is this correct?

Second, when I run Linux, PL011 works fine when I "write" to it (i.e., I get the boot log output on PL011 on minicom), but the boot log sounds confusing to me with regards to IRQ number:

[ 2.749292] uart-pl011 fe201000.serial: cts_event_workaround enabled
[ 2.755820] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 19, base_baud = 0) is a PL011 rev2
[ 3.793261] printk: console [ttyAMA0] enabled
[ 3.798108] fe201400.serial: ttyAMA1 at MMIO 0xfe201400 (irq = 19, base_baud = 0) is a PL011 rev2
[ 3.807405] fe201600.serial: ttyAMA2 at MMIO 0xfe201600 (irq = 19, base_baud = 0) is a PL011 rev2
[ 3.816684] fe201800.serial: ttyAMA3 at MMIO 0xfe201800 (irq = 19, base_baud = 0) is a PL011 rev2
[ 3.825953] fe201a00.serial: ttyAMA4 at MMIO 0xfe201a00 (irq = 19, base_baud = 0) is a PL011 rev2

I am not a Linux expert, but why does it get IRQ number 19? Isn't that PPI? The UART/console also doesn't trigger any interrupts when I enter anything, so the init task is stuck at:

[ 4.027345] uart-pl011 fe201000.serial: no DMA platform data
[ 4.039404] Freeing unused kernel memory: 1088K
[ 4.044295] Run /sbin/init as init process

Please press Enter to activate this console.

A kind of related question: Why the base address is 0x7e201000 and not 0xfe201000?

Thanks in advance

[PhilE]

I interpret the interrupts property as PL011 having an IRQ number of 153. Is this correct?

Things are slightly clearer in the source (https://github.com/raspberrypi/linux/bl ... .dtsi#L712):

Code: Select all

&uart0 {
	interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
};

i.e. the interrupt number as seen by the GIC is 121/0x79 - perhaps you misread it as 0x99/153.

I am not a Linux expert, but why does it get IRQ number 19?

Linux takes all the interrupts exposed by all the interrupt controllers and, using an algorithm of its own (perhaps just the order of issue) converts them into a single linear interrupt space - the numbers are effectively opaque tokens.

Why the base address is 0x7e201000 and not 0xfe201000?

Device Tree addresses are addresses on the bus where the device appears. In this case 0x7e201000 is the address as seen by the VPU. The hierarchy of the Device Tree allows the mappings between address spaces to be specified (https://github.com/raspberrypi/linux/bl ... 8.dtsi#L16):

Code: Select all

		ranges = <0x7e000000  0x0 0xfe000000  0x01800000>,
			 <0x7c000000  0x0 0xfc000000  0x02000000>,
			 <0x40000000  0x0 0xff800000  0x00800000>;

The advantage of this is that the same local bus can be instantiated at different base addresses on different devices - c.f. https://github.com/raspberrypi/linux/bl ... 5.dtsi#L20 and https://github.com/raspberrypi/linux/bl ... 36.dtsi#L9.

Here the block of 0x1800000 bytes starting at 0x7e000000 is exposed at 0x0_fe000000 in the ARM physical address space.

[hmka]

Thanks, PhilE for your reply, it's really useful and informative.

i.e. the interrupt number as seen by the GIC is 121/0x79 - perhaps you misread it as 0x99/153.

Correct. I just interpreted it as seen by the core, which is 121 + 32. I confirm that Linux enables this IRQ properly.

I am still however stuck at RX on PL11 from both u-boot and Linux. If I use the mini-uart, I can interrupt u-boot autoboot and RX just fine. But when I switch to PL011, I can't RX. I would appreciate any hints on why this happens.

My config.txt file is:

Code: Select all

#enable_uart=1
#core_freq=250
enable_gic=1
total_mem=3072
arm_64bit=1

dtoverlay=pi3-disable-bt
dtoverlay=pi3-miniuart-bt
#dtoverlay=uart0
#dtoverlay=uart1
dtoverlay=uart2
dtoverlay=uart3
dtoverlay=uart4
dtoverlay=uart5

My minicom config disables hardware and software flow control.

[hmka]

Hi,

I got this problem sorted out by using uart2 instead of uart1. Using uart2, now the driver can actually recognise there is data in the RX and getc(). I investigated this in both u-boot and Linux drivers and I think it's a hardware problem with the first uart1/pl011 to receive data.

Not sure if it's a hardware bug in my board or a general Pi4 issue as I haven't tried on other boards, but I thought to write my findings here in case someone comes across this in the future.

Thanks for your help.

[PhilE]

1) Simplify your config.txt - you don't need both disable-bt and miniuart-bt, either one will release uart0/ttyAMA0 from Bluetooth duty.
2) Watch out for a console trying to use the primary UART - remove console=serial0, console=ttyAMA0 and console=ttyS0 from cmdline.txt.
3) Remember that uart1 is an 8250 clone, not a pl011.

[dony71]

I have same problem when trying to use GPIO14 and GPIO15 (header pinout 8 and 10)
How to resolve this issue?
Can anybody give in details how config.txt should looks like?

[PhilE]

There are too many issues discussed here to say "I have the same problem" - describe what you are trying to do, what you have tried so far, and the results you got.

[dony71]

There are too many issues discussed here to say "I have the same problem" - describe what you are trying to do, what you have tried so far, and the results you got.

I want to use GPIO14 and GPIO15 (header pinout 8 and 10) as serial interface to control uart zigbee module. I have add dtoverlay=uart3 but when when testing with script below, nothing show up on the screen, meaning uart not working.

Code: Select all

#!/bin/sh

sudo stty -F /dev/ttyAMA0 115200
sudo stty -F /dev/ttyAMA1 115200
sudo stty -F /dev/ttyAMA2 115200
sudo stty -F /dev/ttyAMA3 115200
sudo stty -F /dev/ttyAMA4 115200

while true; do
  sudo sh -c "echo 0 > /dev/ttyAMA0"
  sudo sh -c "echo 1 > /dev/ttyAMA1"
  sudo sh -c "echo 2 > /dev/ttyAMA2"
  sudo sh -c "echo 3 > /dev/ttyAMA3"
  sudo sh -c "echo 4 > /dev/ttyAMA4"
  sleep 1
done

[PhilE]

What does "sudo vcdbg log msg" return? Do you get output from any of the UARTs, and if so which?

[dony71]

What does "sudo vcdbg log msg" return? Do you get output from any of the UARTs, and if so which?

I'm using ubuntu 20.04 server so don't have this vcdbg
"dmesg | grep tty" shows

Code: Select all

root@cloudstack-mgmt:~# dmesg | grep tty
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1  smsc95xx.macaddr=DC:A6:32:52:0B:89 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  grub-installer/skip=true net.ifnames=0 dwc_otg.lpm_enable=0 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc
[    0.000540] printk: console [tty1] enabled
[    1.735016] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 14, base_baud = 0) is a PL011 rev2
[    1.739737] fe215040.serial: ttyS0 at MMIO 0x0 (irq = 16, base_baud = 62500000) is a 16550

"raspi-gpio get 0-15" shows

Code: Select all

root@cloudstack-mgmt:~# raspi-gpio get 0-15
GPIO 0: level=1 fsel=0 func=INPUT pull=UP
GPIO 1: level=1 fsel=0 func=INPUT pull=UP
GPIO 2: level=1 fsel=4 alt=0 func=SDA1 pull=UP
GPIO 3: level=1 fsel=4 alt=0 func=SCL1 pull=UP
GPIO 4: level=1 fsel=0 func=INPUT pull=UP
GPIO 5: level=1 fsel=0 func=INPUT pull=UP
GPIO 6: level=1 fsel=0 func=INPUT pull=UP
GPIO 7: level=1 fsel=1 func=OUTPUT pull=UP
GPIO 8: level=1 fsel=1 func=OUTPUT pull=UP
GPIO 9: level=0 fsel=4 alt=0 func=SPI0_MISO pull=DOWN
GPIO 10: level=0 fsel=4 alt=0 func=SPI0_MOSI pull=DOWN
GPIO 11: level=0 fsel=4 alt=0 func=SPI0_SCLK pull=DOWN
GPIO 12: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 13: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 14: level=1 fsel=2 alt=5 func=TXD1 pull=NONE
GPIO 15: level=1 fsel=2 alt=5 func=RXD1 pull=UP

I notice dmesg shows below when running the script

Code: Select all

[56055.283070] uart-pl011 fe201000.serial: no DMA platform data

[PhilE]

TXD1/RXD1 are the data pins for the mini-UART ttyS0. By default on a Pi 4, ttyAMA0/UART0/pl011 is used for Bluetooth comms on GPIOs 30-33. If you want to use it for something else you must add either dtoverlay=disable-bt or dtoverlay=miniuart-bt to config.txt.

[dony71]

TXD1/RXD1 are the data pins for the mini-UART ttyS0. By default on a Pi 4, ttyAMA0/UART0/pl011 is used for Bluetooth comms on GPIOs 30-33. If you want to use it for something else you must add either dtoverlay=disable-bt or dtoverlay=miniuart-bt to config.txt.

I want to use bluetooth and at same time I want to use TXD1/RXD1 on GPIO14/15
Does it mean I should be able to use ttyS0 now, right? but not working now

[PhilE]

Does it mean I should be able to use ttyS0 now, right? but not working now

Yes, provided you connect TXD1 (GPIO 14, pin 8), RXD1 (GPIO15, pin 10) and a GND (usually pin 6) it should just work provided you configure and write to ttyS0, but you do need to put "enable_uart=1" in config.txt.

Have you done any research into UARTs on the Pi? Google "raspberry pi uarts" and the first link is our guide: https://www.raspberrypi.org/documentati ... on/uart.md