Enhancement request: adding BOARD= support to radio FW build enviroment

[hlyi]

@jnilo1 Thanks for your enhancements you did in #126. I will leave #126 for Main SOC discussion, and creating this one for radio FW build enhancement. The initial target would be EFR32MG13P732HI that used in Sengled G4. Could you please update build script to support this?

[jnilo1]

Hi @hlyi,

Yes — this is the radio half of the deal sketched in #126; let's make it concrete here.

Good news first: same SDK, same toolchain

The MG13P is Series 1, so it stays inside the build environment you already have: Gecko SDK 4.5.0 + EmberZNet 7.5.1 + ARM GCC. No new SDK, no new toolchain — BOARD= is configuration plumbing, same nature as the kernel and bootloader cases.

The shape

Mirroring the SoC side:

2-Zigbee-Radio-Silabs-EFR32/boards/
├── lidl/               reference — EFR32MG1B232F256GM48, PA4/PA5 RTS/CTS, hw flow
└── sengled-e39-g8c/    contributed — EFR32MG13P732xx, your pinout, sw flow

A board directory defines: the exact chip part number handed to slc generate, the per-firmware project overrides (UART pins / VCOM routing, flow-control type), and — optionally — a matching Gecko bootloader build. build_efr32.sh takes BOARD= (default lidl, generating the same project as today's hard-coded values). Scope per your #123 note: NCP + OT-RCP first; RCP/multi-PAN can follow if you ever want the host-side EmberZNet 8.2 path.

One simplification for the G4: your stock Gecko bootloader is already in place and working (you proved it in #129 — 115200, and blmode_pulse drops into it). So the first milestone needs no bootloader build at all: enter the bootloader via blmode_pulse, flash our NCP/OT-RCP .gbl through it with flash_efr32.sh, keep Stage 1 + stock Stage 2 untouched. That is also the lowest brick-risk path — a rebuilt bootloader for the MG13 can come later if a reason appears.

What we need from you

Same contract as board.h in #128 — mechanism and lidl reference from us, sengled-e39-g8c values from and validated by you (we have no MG13 hardware, and untested radio firmware is an SWD-rescue risk we won't ship blind):

1. The exact ordering part number. The package marking ("EFR32MG13P732HI…") is shorter than the OPN slc needs (EFR32MG13P732F512…-style, with flash/temperature/package suffix). Simplicity Commander over SWD reports it, or it's in Sengled's FCC filing.
2. The UART routing facts: which USART and TX/RX pins connect to the RTL8196E, and confirmation there is no RTS/CTS wiring (= software-flow build, as established in Enhance rtl8196e_uart_bridge_main to support SW Flow control #123).
3. Your current manual edits. If your working sw-flow build already targets the MG13, the board directory is mostly packaging those values — exactly like your board.h.

Proposal: I put the BOARD= plumbing + the lidl reference directory on v3.11.0-pre, and you PR the sengled-e39-g8c directory on top, like #128?

[hlyi]

@jnilo1 sounds a good plan to me👍, thanks

[jnilo1]

Plumbing is in — BOARD= now drives the NCP and OT-RCP firmware builds on v3.11.0-pre, same shape as the bootloader side.

How it works

A board contributes one file, 2-Zigbee-Radio-Silabs-EFR32/boards/<board>/board.env, packaging the MCU OPN and the UART routing. The build scripts read it (default BOARD=lidl):

BOARD=sengled-e39-g8c ./build_efr32.sh ncp ot-rcp

A shared helper writes the routing into the slc-generated VCOM header, changing only the value on each #define. So the lidl default is a strict no-op — verified: the rebuilt NCP .gbl is byte-for-byte identical to the committed firmware. RCP, Router and the bootloader stay lidl-only for now and are skipped for other boards.

Software (XON/XOFF) flow control is wired

The G4 board file is set to software flow — built with XON/XOFF, not the Lidl RTS/CTS handshake:

BOARD_TARGET_DEVICE="EFR32MG13P732F512IM32"   # verified (your #133 doc)
BOARD_UART_FLOW="sw"                          # G4 has no RTS/CTS (#123)

This isn't a patch: the iostream/uartdrv VCOM config already exposes software flow as a flow-control-type option (uartFlowControlSoftware for NCP, uartdrvFlowControlSw for OT-RCP), and the generated init code keys off it. board.env just selects it (hw / sw / none).

What's still needed from you — two things

1. USART + TX/RX pins. The USART/pin entries in board.env are still placeholder Lidl values (USART0, PA0/PA1) — the OPN gives the chip, not the routing the G4 wired. This is the one fact only your hardware has.

2. MG13 device-init config. A clean BOARD=sengled-e39-g8c build doesn't complete from our tree yet — the MG13 trips an MG1B-vs-MG13 SDK delta in device_init_emu (first wall: SL_DEVICE_INIT_EMU_EM4_VSCALE undefined). That's exactly the kind of MG13-specific tweak your local working build must already carry. Your current manual edits are what we need to fold in here.

Next step

Drop your real USART/pins into boards/sengled-e39-g8c/board.env, bring across whatever MG13 config your build needs, and validate over SWD before trusting the image (untested radio firmware is an SWD-rescue risk — we have no MG13 to catch a bad routing). Then PR the board file, like your board.h in #128. The porting contract is in boards/README.md on the branch.

[jnilo1]

Quick update — scratch the device_init_emu blocker I mentioned: BOARD=sengled-e39-g8c now builds NCP and OT-RCP end-to-end (MG13 target, software flow), on v3.11.0-pre.

The EM4 VSCALE error was a red herring. The real cause was on our side: the NCP .slcp pinned the Lidl MCU as a device component ({id: EFR32MG1B232F256GM48}), so slc generate --with EFR32MG13P732F512IM32 pulled both device families and the link failed with duplicate symbols (SystemInit, SystemCoreClock, …); that same confusion is what dropped SL_DEVICE_INIT_EMU_EM4_VSCALE from the generated config. The fix is generic: the build re-points the slcp device id at BOARD_TARGET_DEVICE before slc generate — a no-op for Lidl (its firmware still rebuilds bit-for-bit identical), MG13-only for the G4. OT-RCP needed nothing; its slcp has no device component.

So the mechanism is complete: BOARD=sengled-e39-g8c ./build_efr32.sh ncp ot-rcp produces MG13 images with XON/XOFF flow.

One thing left, and it's yours: the build still uses placeholder Lidl UART pins (USART0, PA0/PA1) because that's the one fact only your hardware has. The image is structurally correct but electrically wrong until those are right. Drop your real USART + TX/RX pins into boards/sengled-e39-g8c/board.env, rebuild, validate over SWD, and PR the file. That's the last piece.

[jnilo1]

A heads-up: there's now a v4.0.0-pre branch

I've opened v4.0.0-pre — it's v3.11.0-pre plus the per-driver kernel audit batch that was waiting in the wings, and it's the branch that will become the next release. No rush at all, but if you'd like your G4 work to sit on the branch that's actually heading to GA, this is the one.

What it adds

A hardening pass over the whole 6.18 kernel tree — one entry per driver under [Unreleased] in 3-Main-SoC-Realtek-RTL8196E/CHANGELOG.md. The headlines: rtl8196e-eth v2.13 (a real DT resource model + BQL on the TX queue), 8250_rtl819x v1.4 (FIFOs finally enabled, RX trigger pinned to 1), rtl819x_wdt v1.6 (panic-safe), plus gpio / leds / spi / clocksource / uart-bridge / irqchip. All board-agnostic, validated on the Lidl bench. The changes live in the driver sources under files-6.18/; the committed kernel-6.18.img is the Lidl reference build, so it's not for your board directly (see the next section).

It's safe on your G4 — I checked the one thing that could have bitten

eth v2.12 now makes the driver claim and verify its three register windows and fails the probe if the devicetree doesn't declare them. Your rtl8196e-sengled-e39-g8c.dts only overrides member-ports, so it inherits those three windows from the shared rtl819x.dtsi (through rtl8196e.dts), and the RTL8196E register map is identical on both boards — so eth comes up normally. Nothing to change on your side.

What it means for you

• Rebuild the kernel for your board, exactly as you already do on v3.11.0-pre: BOARD=sengled-e39-g8c ./build_kernel.sh (the DTB is built into the image, so the default kernel-6.18.img carries the Lidl 32 MB DTB — yours needs the G4 build). That build picks up the audit driver sources automatically. Then flash the kernel partition as usual — userdata, Thread/Zigbee config and keys live on other partitions and stay untouched.
• Your radio work carries over unchanged. The board.env USART + TX/RX pins we still need for Enhancement request: adding BOARD= support to radio FW build enviroment #130, plus blmode_pulse and the G4 parameter set, are all EFR32/userdata — orthogonal to this kernel batch. You keep working them on v4.0.0-pre exactly as on v3.11.0-pre.
• Since the eth / LED / button drivers all changed, if you do move over, a quick word on anything odd there (LAN LED, front button, link under load) would be gold — your G4 is the only second board these paths run on.

Entirely your call on timing — no need to interrupt a bring-up session to do it.

[hlyi]

@jnilo1 Thanks for creating new build environment for multiple boards support 👍 , and providing the heads up for v4.0.0-pre branch. I will move my work to the new branch.

Quick summary on the progress:

1. With local hack build ( before using your new infrastructure), I was able to flash NCP firmware into the radio IC, and HomeAssistant was able to recognize the device ( no further test on the radio being done)
2. G4 Radio IC also uses the same pin as Lidl (PA0 for TX, and PA1 for RX)
3. With new building environment, I flashed built NCP firmware into the radio IC, unfortunately, HomeAssitant can not talk to the radio IC.

Here are a few observations:

1. Generated 4-NCP-UART-HW/build/ncp-uart-hw.slcp still have usartHwFlowControlCtsAndRts, I think that may be culprit.
2. Was not able to flash using ./flash_efr32.sh script if I triggered the bootloader before run the script. I think Pulsing EFR32 nRST for clean pre-probe state... step may be cause it as it would bring the radio back to functional mode.
3. Comeatic but can be confusing.
   • the built firmware is called ncp-uart-hw-7.5.1-115200-sengled-e39-g8c.gbl, I think it should use sw instead
   • the directory name is still 24-NCP-UART-HW even though it now supports SW flow control

Thanks again!

[jnilo1]

Thanks @hlyi — really useful report. I dug into all three points; good news on the firmware, and I think I found the actual blocker. Everything below is pushed to v4.0.0-pre.

Good news: the NCP firmware is already software-flow

I rebuilt BOARD=sengled-e39-g8c NCP here and traced where flow control actually lands in the binary:

• The generated VCOM config header — what the firmware compiles against — is SL_IOSTREAM_USART_VCOM_FLOW_CONTROL_TYPE = uartFlowControlSoftware.
• The autogen keys off that macro: hwFlowControl resolves to usartHwFlowControlNone, sw_flow_control to true. A full sweep of the generated tree found no other RTS/CTS setting.

So the usartHwFlowControlCtsAndRts you spotted in ncp-uart-hw.slcp is a red herring: the .slcp is read only at slc generate time, and the build then copies the per-board VCOM header (sed to sw) over the generated one before compiling — so the slcp value never reaches the binary. It was misleading, though, so I made the slcp track BOARD_UART_FLOW too; it now reads uartFlowControlSoftware for the G4. Lidl rebuilds byte-for-byte identical (verified).

That means flow control was not why HA couldn't talk to your radio.

The actual blocker: the nRST pulse was undoing your bootloader entry (your point 2)

You nailed it. flash_efr32.sh pulsed the EFR32 nRST early "for a clean pre-probe state" — but if you'd already entered the Gecko Bootloader (via blmode_pulse or a download-mode reboot), that pulse reset the chip back into the application, so the upload then ran against a chip that was no longer in the bootloader and the flash silently didn't take. You were almost certainly testing stale firmware.

Fixed: the script now probes the bootloader at 115200 first and skips the nRST pulse when it answers. So both workflows work now — enter the bootloader yourself, or just let the script drive it.

Host side is handled too (#134)

Separately, on the kernel side I split the bridge's flow-control into a board capability (realtek,hw-flow-control in the DT, which the G4 omits) and a runtime mode. Your G4 now defaults the host bridge to sw automatically, and an hw request is clamped to sw so it can't wedge the unwired UART. Details in #134 — but the short version: both ends default to sw on the G4 with no config needed.

Your other points

• PA0/PA1 same as Lidl — good, that confirms the placeholder routing is right. Can you also confirm it's USART0 (not USART1) on the G4? That's the last bit board.env needs before the routing is fully validated.
• Cosmetic naming (ncp-uart-hw-… and 24-NCP-UART-HW): agreed it's confusing on a sw board. I left it for now — renaming the directory/artifacts touches a lot of paths — but it's on the list.

To retest on the G4

Everything is on v4.0.0-pre:

1. git pull, then rebuild your kernel (BOARD=sengled-e39-g8c ./build_kernel.sh) and reflash the kernel partition — that brings in the host-side sw default.
2. Reflash the NCP firmware with the updated flash_efr32.sh (the nRST fix). If you enter the bootloader manually first, it'll now be respected.
3. With both ends on sw, HA should see the coordinator. If it still doesn't, a dmesg | grep uart-bridge (look for hw_fc_capable=0 flow_control=2) plus whatever Z2M/ZHA logs say would tell us if it's now a software-flow interop issue rather than a flash problem.

Appreciate you pushing on this — the nRST-vs-manual-bootloader interaction is a real bug that only showed up because you flash the way you do.

[hlyi]

@jnilo1 Thanks for the fix 👍 . I rebuilt everything based upon v4.0.0-pre branch. Here are the results:

1. Radio FW built successfully
2. flash_efr32.sh works with your fix. Thanks,
3. With latest NCP build, Homeassistant can talks to the device as the router. Thanks for the fix 👍

The new FW build environment is up and running for G4. Great job @jnilo1 👍 Thanks a lot!

The only minor thing to fix for radio FW build environment is directory and FW names. I think it's not critical, we can defer it for future release.

[hlyi]

The original request has been implemented. Close this discussion.