DT510: BSP bring-up plan (device tree, kernel, phased tiers)

[ajlennon]

Summary

Track DT510 (imx8mm-jaguar-dt510) BSP work against Ollie Hull’s hardware pinout SSOT: phased tiers (A–D), risk notes, DTS single-source symlink action, and spec↔BSP gaps.

Project plan (committed)

docs/DT510-BSP-PROJECT-PLAN.md

Tool-generated reference (review only — not the build)

Folder: docs/reference/dt510-ollie-tool-generated/ — pin_mux.dts, pin_mux.c, pin_mux.h for gap analysis vs the shipping imx8mm-jaguar-dt510.dts and the SSOT. Incomplete; see README in that folder.

Hardware SSOT (first cut; revise on error)

VIX DT510 – Google Doc

Status (rolling)

• Tiers A–A4: checklist + DTS hygiene landed; Tier B1 BQ25792 DT enabled — kernel driver for ti,bq25792 still TBD on LmP 6.6.x (see thread).
• Tier C2 (in progress): TAS6424 — sound-tas6424 + tas6424@6a + CONFIG_SND_SOC_TAS6424; placeholder high-voltage rail pending SSOT; AMP_STBY# / AMP_MUTE# GPIOs next. Implementation: 396cb8e (and 0667663 for MACHINE_FEATURES gate).
• Open product question (needs @ohull456): 4-channel TDM vs stereo I2S on SAI1 for TAS6424 — see latest Implementation comment (trade-offs + ask).

Next steps

Continue Tier C2 validation on hardware after Foundries image; wire standby/mute GPIOs from SSOT; decide TDM vs I2S with Ollie before locking simple-audio-card TDM slot parameters. Then TAA5412 / TAC5301 per agreed order.

Assignees

Alex Lennon (@ajlennon), Ollie Hull (@ohull456).

---

Coordinates BSP DT/kernel changes per the committed plan.

[ajlennon]

Process update — BSP ↔ hardware lab

We’ll keep this issue as the live thread for handoffs and lab results.

Workflow (see repo doc §11): DT510-BSP-PROJECT-PLAN.md §11

• Alex: post an Implementation comment per testable slice (commit/PR, what to verify).
• Ollie: reply with Lab result (PASS/FAIL/PARTIAL + notes).
• Both: we’ll fill the Lab verification log table in that doc via small PRs as milestones complete.

Latest doc commit: e964c28.

[ajlennon]

Reference material — tool-generated pinmux / DTS (review only)

Ollie’s incomplete, non-build outputs are committed for gap analysis vs SSOT — not the shipping device tree.

Folder: docs/reference/dt510-ollie-tool-generated/ on main
Browse: https://github.com/DynamicDevices/meta-dynamicdevices-bsp/tree/main/docs/reference/dt510-ollie-tool-generated

File	Purpose
pin_mux.dts	Tool-generated DTS — compare to recipes-bsp/device-tree/lmp-device-tree/imx8mm-jaguar-dt510.dts
pin_mux.c / pin_mux.h	Companion generated C/header — review only; not compiled by this layer

Project plan (tiers + lab loop): docs/DT510-BSP-PROJECT-PLAN.md

Use this thread for Implementation / Lab result comments per §11; use the reference files when deciding next BSP steps against the hardware SSOT.

[ajlennon]

Implementation — Tier A1–A2 Single DTS symlink + SSOT header

• Commit / PR: d78fe3b (follow-up 7d45bda doc ref only)
• Scope:
  • Canonical DTS only in recipes-bsp/device-tree/lmp-device-tree/imx8mm-jaguar-dt510.dts.
  • recipes-kernel/linux/linux-lmp-fslc-imx/imx8mm-jaguar-dt510.dts is now a symlink to that file (no duplicate content).
  • SSOT / plan / reference-folder comment block at top of canonical DTS.
  • Plan doc updated (tier status, §6, lab log).
• Image / artifact: Rebuild virtual/kernel / factory image from main as you normally do — no DT binary content change expected vs previous identical DTS.
• Please verify in lab:
  • Image still builds (BitBake unpacks symlink OK).
  • Board boots as before (no expected hardware delta).
  • Optional: dtb in deploy still present and sane for imx8mm-jaguar-dt510.
• Risks if any: Low — if a Windows checkout breaks symlinks, use WSL or core.symlinks true; CI/Linux OK.

Next plan step: Tier A3 — audit spreadsheet / checklist (bus, address, DT node, driver, fragment per SSOT vs pin_mux reference), then A4 placeholders as needed.

[ajlennon]

Note — Foundries build trigger (workflow)

Team triggers DT510 Foundries builds by committing + pushing meta-subscriber-overrides on main-imx8mm-jaguar-dt510 (source.foundries.io/factories/vixdt/meta-subscriber-overrides). Typical checkout path: vixdt/meta-subscriber-overrides.

Order: land BSP changes on DynamicDevices/meta-dynamicdevices-bsp main first, then push subscriber-overrides so the factory sync picks up the new BSP.

Documented in DT510-BSP-PROJECT-PLAN.md §3 (commit cc215d0).

[ajlennon]

Implementation — Tier A3–A4 Audit checklist + I2C3 placeholders

• Commit / PR: 66d5c1f (doc SHA fix: 16b4109)
• Scope:
  • New DT510-HARDWARE-AUDIT-CHECKLIST.md — SSOT blocks vs BSP (living table).
  • DTS &i2c3: disabled placeholders bq25792@6b, lt9611@39 (7-bit; SSOT 8-bit 0x72 noted in checklist) — no pinctrl changes, drivers do not probe while disabled.
  • Project plan updated (§3 checklist link, §7, Tier A3/A4 complete, errata).
• Image / artifact: BSP main → then your usual push to meta-subscriber-overrides (main-imx8mm-jaguar-dt510) to trigger Foundries.
• Please verify in lab:
  • Boot unchanged (USB gadget / Wi‑Fi / audio smoke as before).
  • Optional: i2cdetect -y <bus for i2c3> — 0x6b and 0x39 may appear if hardware is populated; no driver bind until we enable nodes.
• Risks: Low — if lontium,lt9611 or ti,bq25792 compatible strings differ from kernel, harmless while status = "disabled".

Tier A complete. Next: Tier B1 (enable BQ25792 + interrupts + fragment) when ready.

[ajlennon]

Implementation — USB dual-audio vs codec path (toggle)

• Commit: fedf002
• What: MACHINE_FEATURES dt510-usb-dual-audio-autostart controls whether usb-dual-audio-gadget-dt510.service is enabled at boot. Default in BSP machine conf remains on (same as before).
• Codec-first / later: add MACHINE_FEATURES:remove:imx8mm-jaguar-dt510 = "dt510-usb-dual-audio-autostart" in factory conf (e.g. subscriber local.conf / site fragment). Gadget scripts stay; run systemctl start usb-dual-audio-gadget-dt510 for simulated USB testing.
• Doc: docs/DT510-USB-DUAL-AUDIO.md

[ajlennon]

Questions for @ohull456 (hardware / SSOT) — unblock next BSP steps

Please reply inline (or bullet answers). Goal is to close gaps from Tier A4 (partial) and §7 / audit checklist so we can add DT + fragments safely.

---

1) I2C4 + SE050 @ 0x48

• Is I2C4 fully routed on DT510 per the current schematic, and does it match what we should describe in Linux (pinmux / &i2c4 in device tree)?
• Any pull-ups / level shifters or address caveats vs the SSOT Google Doc?
• OK to add a disabled se050@48 (or NXP-compatible) child under &i2c4 once the bus node exists, or do you want to wait until OpTEE/SE05x bring-up is scheduled?

---

2) I2C2 address 0x50 — TAC5301 vs TCPC / USB-C

• The BSP still has a disabled tcpc@50 placeholder. SSOT lists TAC5301 at 0x50. Which is correct on shipping DT510 hardware?
• If TAC5301 wins: confirm we should remove/rename the TCPC node and align STUSB4500 / role-switch elsewhere (or document shared bus rules).

---

3) I2C3 placeholders already in DT (bq25792@6b, lt9611@39 disabled)

• Confirm 7-bit addresses: BQ25792 = 0x6B, LT9611 = 0x39 (SSOT 8-bit 0x72 for LT9611) on I2C3 as wired.
• Any GPIO (e.g. charger interrupt, HDMI reset/int/fault) that must be frozen before we set status = "okay"?

---

4) SAI / audio blocks not yet in DT (TAC5301 SAI6, TAA5412 SAI5, TAS6424 SAI1)

• Order of bring-up you want: which codec first after TAS2563 (already on SAI3)?
• Any pinmux constraints (e.g. SAI1 currently disabled in DT) that the schematic already resolves so we can plan one DT change set?

---

5) XM125 radar vs SSOT (CAN ECSPI2, GNSS GPIO)

• Google Doc vs current DT: ECSPI2 is tied to XM125 today; SSOT wants MCP2518xx on ECSPI2. Is the intended product: radar or CAN, or mutually exclusive variants?
• GNSS reset vs XM125 lines: can you confirm no pin clash on the shipping board (or which revision fixes it)?

---

6) SSOT document

• Is the Google Doc still the live first-cut, or is there a schematic / revision we should treat as newer for the next DT pass?

Thanks — once we have these, we can mark A4 complete or split follow-up issues (B1 charger, C3 HDMI, B4 SE050, etc.) with confidence.

[ajlennon]

SE050 — same bus as Sentai (recorded)

Conclusion: SSOT I2C4 @ 0x48 matches the existing OpTEE SE05x setup: CFG_CORE_SE05X_I2C_BUS=3 = Linux &i2c4. DT510 se05x / OEFID already match Sentai.

Doc: docs/DT510-SE050.md (commit 818de11). Plan + audit checklist updated.

[ajlennon]

Product clarification — no XM125 radar on DT510

XM125 (Acconeer) was a Jaguar Sentai bring-up (MACHINE_FEATURES includes xm125-radar on Sentai only). DT510 does not carry this hardware.

Updates (repo):

• imx8mm-jaguar-dt510.dts: xm125@52 → status = \"disabled\" with comment; ECSPI2 comment → available for SSOT CAN when ready (not “for XM125”).
• Audit checklist / project plan: CAN C4 / GNSS C5 no longer assume XM125 GPIO conflict on DT510.

@ohull456 — you can ignore XM125 when answering earlier questions about radar vs CAN / GPIO on DT510; focus on SSOT + schematic for CAN and GNSS only.

[ajlennon]

Sentai vs DT510 — clarification for hardware handoff (Ollie)

This is captured in-repo so it does not live only in chat:

• Checklist: docs/DT510-HARDWARE-AUDIT-CHECKLIST.md → section Sentai vs DT510: product clarification (#sentai-vs-dt510-product-clarification)
• Plan pointer: docs/DT510-BSP-PROJECT-PLAN.md §2 links to the same section

Different in the BSP by design

Topic	Sentai	DT510
XM125 radar	MACHINE_FEATURES includes xm125-radar; xm125@52 enabled; xm125-radar-monitor is Sentai-only	Not populated; node disabled; no xm125-radar
USB dual UAC2 gadget autostart	Not this machine feature	dt510-usb-dual-audio-autostart (lab/sim path; see DT510-USB-DUAL-AUDIO.md)
BQ25792 / LT9611	Not as the same DTS placeholder snapshot	Disabled placeholders in DT510 DTS — confirm BOM + bus per schematic (not inferrable from MACHINE_FEATURES alone)

Same machine-feature stack in both .conf files (not Sentai-only)

Both append nxpiw612-sdio, stusb4500, zigbee, tas2562, and the same se05x / SE05X_OEFID pattern (when not local-dev). Any difference is antenna / RF / BOM, not that list.

Please confirm: imx8mm-jaguar-dt510.conf still says Wi‑Fi may follow Sentai for demo until new hardware — does DT510 hardware match Sentai or only the software profile?

Historical (Sentai DTS comments only)

BGT 60TR13C → XM125 lineage on older Sentai bring-up; not assumed for DT510.

Open by SKU (checklist + plan tiers)

CAN, GNSS, Ethernet, full audio, HDMI depend on what is fitted. ECSPI2: free on DT510 for CAN (e.g. MCP2518xx) — not tied up for XM125 GPIOs like the Sentai XM125 story.

---

Ping @ohull456 — questions above are the ones that need product/schematic answers; the table in the checklist is the living SSOT ↔ BSP tracker.

[ohull456]

Questions for @ohull456 (hardware / SSOT) — unblock next BSP steps

Please reply inline (or bullet answers). Goal is to close gaps from Tier A4 (partial) and §7 / audit checklist so we can add DT + fragments safely.

1) I2C4 + SE050 @ 0x48

• Is I2C4 fully routed on DT510 per the current schematic, and does it match what we should describe in Linux (pinmux / &i2c4 in device tree)?
• Any pull-ups / level shifters or address caveats vs the SSOT Google Doc?
• OK to add a disabled se050@48 (or NXP-compatible) child under &i2c4 once the bus node exists, or do you want to wait until OpTEE/SE05x bring-up is scheduled?

2) I2C2 address 0x50 — TAC5301 vs TCPC / USB-C

• The BSP still has a disabled tcpc@50 placeholder. SSOT lists TAC5301 at 0x50. Which is correct on shipping DT510 hardware?
• If TAC5301 wins: confirm we should remove/rename the TCPC node and align STUSB4500 / role-switch elsewhere (or document shared bus rules).

3) I2C3 placeholders already in DT (bq25792@6b, lt9611@39 disabled)

• Confirm 7-bit addresses: BQ25792 = 0x6B, LT9611 = 0x39 (SSOT 8-bit 0x72 for LT9611) on I2C3 as wired.
• Any GPIO (e.g. charger interrupt, HDMI reset/int/fault) that must be frozen before we set status = "okay"?

4) SAI / audio blocks not yet in DT (TAC5301 SAI6, TAA5412 SAI5, TAS6424 SAI1)

• Order of bring-up you want: which codec first after TAS2563 (already on SAI3)?
• Any pinmux constraints (e.g. SAI1 currently disabled in DT) that the schematic already resolves so we can plan one DT change set?

5) XM125 radar vs SSOT (CAN ECSPI2, GNSS GPIO)

• Google Doc vs current DT: ECSPI2 is tied to XM125 today; SSOT wants MCP2518xx on ECSPI2. Is the intended product: radar or CAN, or mutually exclusive variants?
• GNSS reset vs XM125 lines: can you confirm no pin clash on the shipping board (or which revision fixes it)?

6) SSOT document

• Is the Google Doc still the live first-cut, or is there a schematic / revision we should treat as newer for the next DT pass?

Thanks — once we have these, we can mark A4 complete or split follow-up issues (B1 charger, C3 HDMI, B4 SE050, etc.) with confidence.

• Yes, I2C4 is fully routed exactly the same as Sentai unit.
• Same address, external pull-ups (as on sentai unit) and no level-shifters.
• Not sure what you mean by the last bulletpoint - the only item on i2c4 is the se050.

• TCPC is still disabled - prioritise TAC5301 at addr 0x50.
• There is no STUSB4500 on the DT510, it's not powered from USB-C.

• BQ25792 i2c addr is confirmed as 0x6B. LT9611 i2c addr is 0x39 as you said.
• Not sure at the moment (this is low priority)

• Order of codec bring-up - TAS6424E-Q1, TAA5412-Q1, TAC5301-Q1. TAC5301-Q1 is low priority.
• TAS6424E-Q1 has two control signals as listed in google doc, AMP_STBY# and AMP_MUTE# will both need to be high. TAS2563 should be configured the same as on Sentai. The other two codecs both have software sleep modes that aren't controlled in hardware.

• Radar doesn't exist on DT510, use for CAN controller.
• Again, XM125 doesn't exist on DT510, use for GNSS.

• Google doc is first cut with no new revision yet.

[ajlennon]

Lab result — DT510 boot validation (192.168.2.139)

Build / image tested: LmP 5.0.9-146-96 (PRETTY_NAME / VERSION_ID from /etc/os-release)

Outcome: PASS (boot, SSH, userspace; no ERR journal lines or failed units in checks below)

Environment: SSH fio@192.168.2.139 — validated from dev machine after user reported image deployed to test board.

Checks performed

Check	Result
SSH	OK
Hostname	imx8mm-jaguar-dt510-260b3209dabbe775
Kernel	Linux 6.6.52-lmp-standard aarch64 SMP PREEMPT
LMP_MACHINE	imx8mm-jaguar-dt510
LMP_FACTORY / LMP_FACTORY_TAG	vixdt / main-imx8mm-jaguar-dt510
Uptime at test	~31 min; load avg ~0.07–0.14
systemctl --failed	0 failed units
journalctl -b -p err	no ERR-level lines this boot
dmesg sample (tail, grep error/fail/warn/critical)	no matches in sampled tail
Memory	~1.8 Gi total; normal free/available

Pinout doc / schematic: not evaluated in this pass (software boot-only).

---

Automated/assistant SSH validation; quote or extend for formal lab sign-off if needed.