[widgetii]

For OpenIPC/firmware#2385. The HI3516D_N81820 speed dome drives its pan/tilt MCU over Pelco-D from the main board. Only uart0 is enabled in hi3516a-demb.dts, so there is no /dev/ttyAMA1 to send on, whatever the board does with its pads.

Change

• hi3516a-demb.dts: &uart1, &uart2 and &uart3 set to status = "okay". This is the reporter's patch.
• hi3516a.dtsi: serial1..3 aliases, so ttyAMA1..3 always map to the same controller, whatever the probe order.

No pinmux. Per the Hi3516A/D datasheet (Issue 10), table 2-48, muxctrl_reg30..35 (0x200F0078..0x8C) all reset to GPIO. A board that doesn't mux them sees no change on the wire and only gains three tty nodes. On the dome, stock firmware sets 0x7C/0x84 to 1 (UART1 RXD/TXD) and keeps 0x78 (the UART1_RTSN ball) as GPIO9_2, driven as an output, which looks like an RS-485 direction pin. That is board-specific, so it belongs in the device profile, not here.

Checked against the datasheet: UART1/2/3 bases 0x2009_0000/0x200A_0000/0x2023_0000, and clock gates PERI_CRG 0xe4 bits 16/17/18. Both match the dtsi and clk-hi3516a.c.

Verified

• Built hi3516dv100_lite against this branch. The decompiled hi3516a-demb.dtb shows uart@20090000/200a0000/20230000 okay and serial1..3 aliases.
• The DTB is appended to the uImage: 1815/2048 KB, +51 bytes.

Not run on a camera. The lab dv100 board is offline. The reporter will boot it from the nightly and report on the issue.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Enable HI3516A UART1–3 with stable serial aliases

✨ Enhancement 🕐 10-20 Minutes

AI Description

• Enable UART1–3 in the HI3516A demo-board device tree for boards using additional serial ports.
• Add serial aliases so each controller retains a predictable ttyAMA number.
• Leave pad muxing to board-specific configuration; camera hardware validation remains pending.

Diagram

graph TD
  SOC["HI3516A DTSI"] --> UART["UART1–3 controllers"] --> DRIVER["PL011 driver"] --> TTY["ttyAMA1–3"]
  SOC --> ALIAS["serial1–3 aliases"] --> DRIVER
  BOARD["Demo board DTS"] --> UART

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Enable UARTs only in camera-specific device trees

• ➕ Avoids exposing unused tty devices on boards that do not use them.
• ➖ Requires distinct device trees or overlays for supported camera variants rather than using the shared demo-board image.

Recommendation: Keep the shared-board enablement if one image must support boards that mux different UARTs. Keeping pad muxing out of this change preserves board-specific control; camera boot testing is still needed.

Files changed (2) +15 / -0

Enhancement (2) +15 / -0

hi3516a-demb.dtsEnable three additional UART controllers +12/-0

Enable three additional UART controllers

• Sets UART1, UART2 and UART3 to okay on the HI3516A demo board, allowing their drivers to probe. It does not configure the pads, so serial signalling still depends on board-specific muxing.

arch/arm/boot/dts/hi3516a-demb.dts

hi3516a.dtsiAssign stable aliases to UART1–3 +3/-0

Assign stable aliases to UART1–3

• Adds serial1, serial2 and serial3 aliases pointing to the corresponding UART controllers. These preserve controller-to-ttyAMA numbering independently of probe order.

arch/arm/boot/dts/hi3516a.dtsi

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (2) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. The PTZ pads stay in GPIO mode 📎 Requirement gap ≡ Correctness

Description

The enabled UART nodes contain only status = "okay" and add no board-specific pinmux configuration
for the PTZ connection. Because the relevant pads remain GPIO unless the board configures them
separately, this implementation does not verify or configure the physical UART path required by the
motor controller.

Code

arch/arm/boot/dts/hi3516a-demb.dts[R90-100]

+&uart1 {
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&uart3 {
+	status = "okay";
+};

Evidence

The checklist requires board-specific evidence for the PTZ UART and corresponding pads to be
configured for UART. The changed board file only marks uart1, uart2, and uart3 as enabled,
with no pinctrl or pad configuration.

Confirm the PTZ MCU UART connection and pinmux for HI3516D_N81820
arch/arm/boot/dts/hi3516a-demb.dts[90-100]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The change enables three UART controllers but does not configure the board-specific pads for the PTZ motor-controller connection, leaving the physical interface in its reset GPIO mode.
## Fix Focus Areas
- arch/arm/boot/dts/hi3516a-demb.dts[90-100]
## Recommended Fix
Verify which UART and physical pads connect to the PTZ MCU on the target board, then add the corresponding board-specific pinctrl and any required RS-485 direction GPIO configuration. Enable only the verified UART path and document the board-specific mapping.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. PTZ movement remains unvalidated 📎 Requirement gap ☼ Reliability

Description

The change creates stable serial aliases and enables the UART controllers but adds no serial
communication test or PTZ protocol configuration. Without testing the configured device against the
motor controller using the applicable settings, users have no demonstrated path to pan, tilt, or
zoom control.

Code

arch/arm/boot/dts/hi3516a.dtsi[R26-28]

+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;

Evidence

The checklist requires a usable userspace device node and testing that serial communication
establishes PTZ control. The diff only adds serial1 through serial3 aliases and enables the UART
nodes; it contains no communication validation or PTZ-control test.

Enable and validate serial PTZ control
arch/arm/boot/dts/hi3516a.dtsi[24-31]
arch/arm/boot/dts/hi3516a-demb.dts[90-100]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The UART aliases and enablement do not establish that the PTZ motor controller is reachable or that Pelco-D communication works.
## Fix Focus Areas
- arch/arm/boot/dts/hi3516a.dtsi[26-28]
- arch/arm/boot/dts/hi3516a-demb.dts[90-100]
## Recommended Fix
After verifying the board-specific UART and pinmux, boot the target hardware and test the resulting device node with the expected Pelco-D 9600 baud, 8N1 settings. Confirm pan, tilt, and zoom commands reach the secondary controller, and record the validation in the board documentation or test coverage.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can import rules and skills only from the repositories your team follows

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. The ptz pads stay in gpio mode 📎 Requirement gap ≡ Correctness

The enabled UART nodes contain only status = "okay" and add no board-specific pinmux configuration
for the PTZ connection. Because the relevant pads remain GPIO unless the board configures them
separately, this implementation does not verify or configure the physical UART path required by the
motor controller.

Agent Prompt

## Issue description
The change enables three UART controllers but does not configure the board-specific pads for the PTZ motor-controller connection, leaving the physical interface in its reset GPIO mode.

## Fix Focus Areas
- arch/arm/boot/dts/hi3516a-demb.dts[90-100]

## Recommended Fix
Verify which UART and physical pads connect to the PTZ MCU on the target board, then add the corresponding board-specific pinctrl and any required RS-485 direction GPIO configuration. Enable only the verified UART path and document the board-specific mapping.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

2. Ptz movement remains unvalidated 📎 Requirement gap ☼ Reliability

The change creates stable serial aliases and enables the UART controllers but adds no serial
communication test or PTZ protocol configuration. Without testing the configured device against the
motor controller using the applicable settings, users have no demonstrated path to pan, tilt, or
zoom control.

Agent Prompt

## Issue description
The UART aliases and enablement do not establish that the PTZ motor controller is reachable or that Pelco-D communication works.

## Fix Focus Areas
- arch/arm/boot/dts/hi3516a.dtsi[26-28]
- arch/arm/boot/dts/hi3516a-demb.dts[90-100]

## Recommended Fix
After verifying the board-specific UART and pinmux, boot the target hardware and test the resulting device node with the expected Pelco-D 9600 baud, 8N1 settings. Confirm pan, tilt, and zoom commands reach the secondary controller, and record the validation in the board documentation or test coverage.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools