Skip to content

Introduce monaco-ac-evk Board#527

Open
umang-chheda wants to merge 7 commits intoqualcomm-linux:qcom-6.18.yfrom
umang-chheda:monaco-ac
Open

Introduce monaco-ac-evk Board#527
umang-chheda wants to merge 7 commits intoqualcomm-linux:qcom-6.18.yfrom
umang-chheda:monaco-ac

Conversation

@umang-chheda
Copy link
Copy Markdown

@umang-chheda umang-chheda commented Apr 30, 2026

Add support for Qualcomm's monaco-ac Evaluation Kit (EVK) without
safety monitoring feature of Safety Island(SAIL) subsystem.
This board is based on Qualcomm's QCS8300-AC variant SoC.

Monaco-ac EVK board is a single board computer (SBC) that supports various
industrial applications, including factory automation, industrial
robots, drones, edge AI boxes, machine vision, autonomous mobile
robots (AMRs), and industrial gateways.

Compared to Monaco EVK (monaco-aa):

  • monaco-ac delivers 20 TOPS of NPU performance vs 40 TOPS on
    monaco-aa variant.
  • The power delivery network is simplified from a 4-PMIC arrangement
    (2x PM8654AU + Maxim MAX20018 + TI TPS6594) to 2 PMICs(2x PM8654AU)

Since the two boards share the vast majority of their device tree, this
series first refactors monaco-evk.dts to extract the common hardware
description into monaco-evk-common.dtsi, then introduces monaco-ac-evk.dts.

Also, monaco-ac-evk board supports monaco-evk-ifp-mezzanine attach, Add
support for combined dtb "monaco-ac-evk-ifp-mezzanine" as well, which
overlays monaco-evk-ifp-mezzanine on top of monaco-ac-evk DT.

CRs-Fixed: 4489525

@umang-chheda umang-chheda marked this pull request as ready for review May 4, 2026 06:55
…nto shared dtsi

The monaco-ac EVK is a new board variant which shares the majority of
its hardware description with the existing monaco-evk board.

In preparation for adding this variant, extract the common hardware
nodes from monaco-evk.dts into a new shared monaco-evk-common.dtsi
include file, and update monaco-evk.dts to include it and keep only
board-specific overrides.

No functional change intended.

Link: https://patch.msgid.link/20260427170505.1494703-2-umang.chheda@oss.qualcomm.com
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Introduce bindings for the monaco-ac-evk IoT board, which is
based on the monaco-ac (QCS8300-AC) SoC variant.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260427170505.1494703-3-umang.chheda@oss.qualcomm.com
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
umang-chheda and others added 3 commits May 4, 2026 17:25
Add initial device tree support for monaco-ac EVK board, based
on Qualcomm's monaco-ac (QCS8300-AC) variant SoC.

Compared to the existing monaco-evk board, which is based on the
QCS8300-AA SKU and uses a four-PMIC power delivery network
(2x PM8650AU, Maxim MAX20018, TI TPS6594) to support higher power
requirements, the monaco-ac EVK uses QCS8300-AC SKU
(with 20 TOPS NPU capability) and a simplified two-PMIC power
delivery network (2x PM8650AU).

Apart from the SoC SKU and PDN differences, the board layout and
peripherals are equivalent to the monaco-evk design and are reused
accordingly.

Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
Link: https://patch.msgid.link/20260427170505.1494703-4-umang.chheda@oss.qualcomm.com
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
monaco-ac-evk board supports monaco-evk-ifp-mezzanine attach.

Add combined DTB for the same by merging monaco-ac-evk.dtb with
monaco-evk-ifp-mezzanine overlay.

Link: https://patch.msgid.link/20260427170505.1494703-5-umang.chheda@oss.qualcomm.com
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
… in host mode

Enable primary USB controller in host mode on monaco EVK Platform.

Primary USB controller is connected to a Genesys Logic USB HUB GL3590
having 4 ports. The ports of hub that are present on lemans EVK standalone
board are used as follows:-
1) port-1 is connected to HD3SS3220 Type-C port controller.
2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART
for Bluetooth. This port is to be used only if user optionally replaces the
WiFi card with the NFA765 chip which uses USB for Bluetooth.

Remaining 2 ports will become functional when the interface plus mezzanine
board is stacked on top of corekit:

3) port-2 is connected to another hub which is present on the mezz through
which 4 type-A ports are connected.
4) port-3 is used for the M.2 B key for a 5G card when the mezz is
connected.

Primary USB Controller
          ↓
GL3590 USB Hub (4 ports)
    |
    |-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector
    |
    |-- Port 2 → Mezzanine USB Hub (when mezz attached)
    |
    |-- Port 3 → M.2 B‑Key Slot (when mezz attached)
    |
    |-- Port 4 → M.2 E‑Key Slot
                         (Default: BT via UART;
                          USB only if NFA765 module is installed)

Mark the primary USB controller as host only capable and add the HD3SS3220
Type-C port controller along with Type-c connector for controlling vbus
supply.

In hardware, DIP switches are present to select between USB0 and USB1 ports
for the primary Type‑C USB controller. By default, the switches are in
the OFF state, selecting the USB0 port. Add software support for both HS
and SS switches to eliminate the need for manually changing the DIP switch
position for USB1 operation. Add a USB1 hub reset pin to reset and activate
the hub after boot, ensuring proper detection from its pre‑boot inactive
state.

Link: https://lore.kernel.org/r/20260430142000.3707614-1-swati.agarwal@oss.qualcomm.com
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
Wei Deng and others added 2 commits May 4, 2026 18:53
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make
Bluetooth work, define the necessary device tree nodes, including
UART configuration and power supplies.

The module provides a 3.3V supply originating from the main board's
12V rail. Add a fixed 12V regulator node as the DC-IN source and link
it to the 3.3V regulator node to represent this power hierarchy.

Workaround: With the WCN6855 PMU node present, the driver unintentionally
takes the pwrseq code path, which causes Bluetooth to fail to power up
during an on -> off -> on transition. To unblock functionality, the PMU
node is omitted and all Bluetooth power supply references point directly
to vreg_wcn_3p3, keeping the driver on the non-pwrseq path.

This is a temporary workaround. Once a proper M.2 binding/solution is
upstreamed, both DTS and driver changes will be re-submitted aligned
with the M.2 model.

Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
The QMP PCIe PHYs on Monaco require a dedicated qref voltage supply for
stable operation.

Add the vdda-qref-supply for both PCIe PHY instances on the Monaco-evk.
Without this supply, the system may occasionally crash mainly in system
resume case.

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Copy link
Copy Markdown

@akdwived-dev akdwived-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems this needs additional changes from Storage driver for SDHC to work on 2XPMIC Board. rest all look good!

@umang-chheda
Copy link
Copy Markdown
Author

Seems this needs additional changes from Storage driver for SDHC to work on 2XPMIC Board. rest all look good!

Synced-up with Storage team - currently discussion to enable both eMMC and SD card is going-on with upstream maintainers - so they will be posting patch for SDHC only once the discussion is concluded ...

@qcomlnxci
Copy link
Copy Markdown

Test Matrix

Test Case glymur-crd kaanapali-mtp lemans-evk monaco-evk qcs615-ride qcs6490-rb3gen2 qcs8300-ride qcs9100-ride-r3 sm8750-mtp x1e80100-crd
0_qcom-next-ci-premerge-tests ◻️ ◻️ ◻️ ◻️ ❌ Fail ❌ Fail ◻️ ◻️ ◻️ ◻️
BT_FW_KMD_Service ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
BT_ON_OFF ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
BT_SCAN ◻️ ◻️ ❌ Fail ❌ Fail ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
CPUFreq_Validation ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
CPU_affinity ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
DSP_AudioPD ◻️ ◻️ ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ✅ Pass ◻️ ◻️ ◻️
Ethernet ◻️ ◻️ ⚠️ skip ✅ Pass ⚠️ skip ⚠️ skip ✅ Pass ◻️ ◻️ ◻️
Freq_Scaling ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
GIC ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
IPA ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
Interrupts ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
OpenCV ◻️ ◻️ ⚠️ skip ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ◻️ ◻️ ◻️
PCIe ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
Probe_Failure_Check ◻️ ◻️ ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ◻️ ◻️ ◻️
RMNET ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
UFS_Validation ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
USBHost ◻️ ◻️ ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ◻️ ◻️ ◻️
WiFi_Firmware_Driver ◻️ ◻️ ⚠️ skip ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ◻️ ◻️ ◻️
WiFi_OnOff ◻️ ◻️ ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
adsp_remoteproc ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
cdsp_remoteproc ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
gpdsp_remoteproc ◻️ ◻️ ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ✅ Pass ◻️ ◻️ ◻️
hotplug ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
irq ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
kaslr ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
pinctrl ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
qcom_hwrng ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
remoteproc ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
rngtest ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
shmbridge ◻️ ◻️ ❌ Fail ✅ Pass ❌ Fail ❌ Fail ✅ Pass ◻️ ◻️ ◻️
smmu ◻️ ◻️ ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ◻️ ◻️ ◻️
watchdog ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️
wpss_remoteproc ◻️ ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ◻️ ◻️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants