Enhancement request: add --board or BOARD= to scripts (for Main SOC)

[hlyi]

@jnilo1 Thanks for your quick actions on #124 and other enhancement requests. Could you please start to add command/makefile option to specify alternative boards for all related scripts including efr32 firmware build, so we can have builds for all boards in one branch? Thanks a lot!

[jnilo1]

Hi @hlyi,

Agreed in principle — with v3.10.0 the kernel side already works this way (BOARD=<board> ./build_kernel.sh, one DTS + one Kconfig entry + one Makefile line per board), and the userdata side is board-agnostic since s40button v2 discovers its pin from the DTS. What is left is the EFR32 side, and it deserves a clear plan rather than a quick hack, because it is bigger than a pin map:

What "BOARD=" means for the radio firmware

The G4's radio is an EFR32MG13P732HI — a different chip from the Lidl's EFR32MG1B232F256GM48, not just different wiring: different flash/RAM size, different part number for the slc generator, its own Gecko bootloader build (23-Bootloader), and its own pin/VCOM routing. So a board entry on the radio side is a per-board configuration set, roughly:

2-Zigbee-Radio-Silabs-EFR32/boards/
├── lidl/   — chip part number, slcp target, VCOM pins, flow-control type
└── g4/     — same files, MG13P values (contributed)

with the build scripts (build_ncp.sh first, then the bootloader and OT-RCP builds) taking BOARD= and sourcing the board directory instead of the hard-coded Lidl values — same pattern as the kernel.

The deal: sharing in both directions

I have no G4 hardware, and radio firmware is not something I will ship untested: a wrong pin map or bootloader layout bricks the chip side until SWD rescue. So the split I propose:

• I provide the mechanism: BOARD= plumbing in the build scripts, the lidl reference board directory (bit-identical output to today's builds), and documentation of what a board directory must define.
• You provide and validate the g4 values on your hardware — you have already done most of this by building your sw-flow firmware from our setup.

And to make the G4 a first-class citizen rather than scattered comments across five discussions, please post the complete parameter set that makes your box work, so I can turn it into a dedicated G4 documentation page in the repo (a "ports to other boards" section). Concretely:

• SoC side: DRAM size/timing values you ended up with, flash chip and size, the Ethernet PHY/port mapping, the LAN-LED behaviour;
• DTS values: memory@0 size, button GPIO line, status-LED line, EFR32 nRST line, plus your blmode pin-probing results when you have them;
• Radio side: confirmed chip marking, which firmware you run (your GSDK build vs Sengled stock), baud, flow-control mode that works, and the xoff/xon counters under load;
• Bootloader: serial header pinout if it differs from the Lidl, and anything the V2.x bootloader needed.

Everything we shipped in v3.10.0 for the G4 was built blind on your reports — the documentation page closes the loop, and the next G4 owner gets a working recipe instead of an archaeology project.

To size the first step

Which firmware variants do you actually need for the G4 — NCP only, or also OT-RCP / the standalone router? I would rather wire BOARD= into the builds you will use than convert all four scripts speculatively.

P.S. — you have opened five enhancement requests and we have shipped a release largely built around your port; if the project is useful to you, a star on the repo is the cheapest way to say so. 😉

[hlyi]

@jnilo1 Thanks a lot for adding the support of alternative board!

I just created PR #127 for testing the alternative build. Need your help to address the following issues before the alternative build can coexist with the default one:

1. 3-Main-SoC-Realtek-RTL8196E/32-Kernel/config-6.18-realtek.txt has hardcoded CONFIG_DTB_RTL8196E_GEN=y which only works for default built. Can you support different config based upon board, Or better yet, has a common file, such as config-6.18-realtek-common.txt and board specific one that can be merged together.
   • the default can have CONFIG_DTB_RTL8196E_GEN=y
   • Sengled G4 can have CONFIG_DTB_RTL8196E_SENGLED_E39_G8C=y
2. board specific build for 31-Bootloader. A few files I touched:
   • boot/main.c to change the text for RAM: 64MB
   • btcode/start.h to change DDR_TIMING_VAL and DDR1_32MB_193MHZ. I think we may need more generic name for DDR1_32MB_193MHZ
3. address hardcoded MUX_SEL_2 in 3-Main-SoC-Realtek-RTL8196E/32-Kernel/files-6.18/drivers/net/ethernet/rtl8196e-eth/rtl8196e_hw.c line 322-325. It should be based upon device tree configuration of gpio-line-names and ethernet/interface@0/member-ports
   • if a port used in gpio-line-names, it should be configured as GPIO.
   • if a port enabled in member-ports, it should be configured as LED
   • if a port is not in either group above, it should be configured with default value ( disabled)
4. Minor thing that nice to fix:
   • name consistency: I think 'efr32-nrst' in gpio-line-names should be using the same name as radio-bridge/nrst-gpios
   • is there a way to have gpio-line and radio-bridge merged together?

P.S. Sorry, I thought I already "star'ed" the project, maybe I doubled clicked it. Anyway, you are deserving more stars, I wish I could give multiple stars! Again, greatly appreciate your support!

[jnilo1]

Hi @hlyi,

Thanks for PR #127 — full review posted there (summary: the DTS compiles and merges cleanly against v3.10.0; the boothold relocation is conceptually right but needs the kernel/userspace side to follow, which we are taking on; two trivial fixes on your side). Point-by-point on the four items:

1. Per-board kernel config — already in place, give it a try

config-6.18-realtek.txt is only the committed default. build_kernel.sh already fixes up the generated .config to match BOARD=: it clears every CONFIG_DTB_RTL8196E_* choice entry, sets the one mapped to your board, and runs olddefconfig (look for the "Board dtb:" block in the script). With your PR applied, BOARD=sengled-e39-g8c ./build_kernel.sh should select CONFIG_DTB_RTL8196E_SENGLED_E39_G8C without touching the committed config — that is exactly the path the lidl/other-board split was designed for. If you hit a case where the fixup produces the wrong .config, that's a bug — please report it with the script output.

A common-file + fragment merge would only become necessary if a board someday needs config deltas beyond the DTB choice (different drivers, sizes, …). None is needed for the G4 so far, so we'd rather not add the machinery speculatively.

2. BOARD= for the bootloader — agreed, same contract as the radio firmware

We'll add BOARD= to the bootloader build: a per-board fragment carrying the DDR parameters (with DDR1_32MB_193MHZ renamed to something board-neutral, as you suggest), the RAM-size banner derived from it, and — important, see the PR review — the boothold flag address derived from the board's DRAM top, so your 0x03FFE000 page lines up end-to-end (bootloader read side included).

Same deal as the radio side: we ship the mechanism and the lidl reference (bit-identical output to today's boot.bin — our bootloader build is reproducible and we intend to keep it that way), you provide and validate the G4 values on your hardware. You already have working DDR values since your board boots, so this is mostly packaging.

3. Ethernet driver PIN_MUX_SEL_2 — agreed, your rule is the plan

Your diagnosis is exact: the 0x44 clear in rtl8196e_hw.c is Lidl-shaped. On your board it currently works only by probe-order luck — the gpio-rtl819x request() hook re-muxes pads B2–B6 when a consumer claims the line, after the ethernet driver cleared the fields. The plan follows your proposal:

• pad named in gpio-line-names → the ethernet driver leaves its mux field alone (the GPIO claim owns it);
• pad whose port is in member-ports → configured as an ASIC link/activity LED (port 0 on the G4 vs port 4 on the Lidl — this is your LAN-LED item from Enhancement request: moving hardcoded hardware setting to device tree. #124);
• otherwise → the default (disabled).

4. Naming

gpio-line-names and radio-bridge/nrst-gpios can't be merged — they serve different consumers. The line name is informational (what gpioinfo shows, and what s40button uses for discovery); nrst-gpios is the functional reference, by controller + offset, and never looks at the name string. What we can do is fix the convention: efr32-nrst is the canonical line name and your DTS already follows it, so the two stay in sync by documentation rather than by mechanism.

Roadmap — and where to build from

All of this lands on a new integration branch, v3.11.0-pre (your PR #127 is already retargeted to it — see the review there). main stays on released v3.10.0 untouched; the G4 batch ships as v3.11.0 once it has been validated on both boards. Please base your G4 builds and any follow-up PRs on v3.11.0-pre.

The batch: DT-bound boothold/panic-record page (watchdog + boothold tool), blmode_pulse in the bridge (#123), the DT-aware ethernet pad handling above, BOARD= for the bootloader build, and PR #127 merged.

And the standing ask from my previous comment still applies: your PR gives us the DTS facts, but the dedicated G4 documentation page also needs the DRAM/flash details, the serial-header pinout, and the radio parameters once you have them tested. Thanks for the star — much appreciated!

[hlyi]

@jnilo1 Thanks for accepting the PR and creating v3.11.0-pre branch. Quick feedback your notes:

1. You are right. It worked as you described. my bad.

2. I added boards/sengled-e39-g8c/board.h to the bootloader, it built correctly on my board, and send you PR add board.h for sengled-e39-g8c bootloader #128 for merging, please check.

3. thanks for addressing PIN_MUX_SEL_2 issue, with your fix, my board works with the stock code without needing my local manual hack. there is a minor issue in rtl8196e_hw.c that you may consider to fix: It configures GPIO ports as expected. However, for non-GPIO ports (PB2-PB6), they are configured as LEDs for LAN ports. for Sengled G4, that is not a problem, as all PB2-PB6 are used. But for your board, two of them are not used but being configured as LEDs unexpectedly. I think you can fix by:

   • in rtl8196e_hw.c change

                        mask |= 3 << pads[i].shift;
                        if (name && *name)
                                val |= 3 << pads[i].shift;
     

     to

                        if (name && *name){
                                mask |= 3 << pads[i].shift;
                                val |= 3 << pads[i].shift;
                        }
     

   • in rtl8196e_dt.c, configure port LEDs based upon member-ports

   what do you think?

I will test blmode_pulse and get back to you. Thanks again!

[jnilo1]

Hi @hlyi,

Great round — point by point:

1. Per-board kernel config

Glad it worked as designed, thanks for confirming.

2. Bootloader board.h — PR #128 merged

Merged into v3.11.0-pre (review notes on the PR). With your DDR values and BOARD_DRAM_TOP_KSEG1 0xA4000000 in the tree, BOARD=sengled-e39-g8c ./build_bootloader.sh now produces a G4 loader whose boothold read address (0xA3FFEFFC) matches your DTS end-to-end. The lidl build still reproduces the committed boot.bin bit-for-bit. I also took your 5 s → 1 s blmode-hold reduction; please confirm during your blmode_pulse test that 1 s reliably enters the Gecko bootloader on the real pin.

3. PIN_MUX_SEL_2 for pads in neither group — fixed, but not via member-ports

Your underlying point is right: pads that are neither GPIO-named nor LED-wired should not be driven as LED_PORTn. Shipped on v3.11.0-pre as eth v2.8, with two deliberate differences from your sketch:

• The driver still writes all five fields, every eth0 up. Masking only the named pads would leave the others at whatever the bootloader (or a previous claim) left there — the inherited-state non-determinism that v2.7 was built to eliminate. Determinism comes from writing the full mask; the per-pad value is what the DT controls.

• The LED pads come from a new DT property, not from member-ports. The pad↔LED_PORTn naming in the datasheet does not predict the wiring: your G4 uses port 0 and the Lidl uses port 4, yet both boards have their LAN LED on pad B2. So member-ports cannot select the LED pad — it is a wiring fact, and wiring facts live in the DTS. The GPIO node now takes, next to gpio-line-names:

  realtek,led-pads = <10>;    /* B2: LAN LED */
  

The resulting rule: named in gpio-line-names → GPIO (0b11); listed in realtek,led-pads → ASIC LED (0b00); neither → left as unclaimed GPIO (0b11), i.e. Hi-Z — Table 36 has no true "disabled" encoding (we measured 00/10 both leave the ASIC driving the pin; 11 floats it), so unclaimed GPIO is the safe default for unknown wiring. If the property is absent, unnamed pads fall back to the v2.7 behaviour (0b00), so an out-of-tree DTS keeps its LAN LED.

The property lives in the base rtl8196e.dts, and your G4 DTS inherits it through its #include (verified in the compiled G4 dtb) — on the G4 it changes nothing anyway, since B2 was your only unnamed pad and it is the LED. Bench-verified on the Lidl: 0x44 reads 0x36D8 (B2 = LED, everything else GPIO/Hi-Z), LAN LED, status LED, button and the EFR32 bridge all fine. On your side nothing to do beyond rebuilding from the branch whenever convenient.

Still on the wishlist from you

• blmode_pulse against the real Sengled bootloader-entry pin (with the 1 s hold);
• the complete G4 parameter set for the documentation page (Enhancement request: add --board or BOARD= to scripts (for Main SOC) #126 above);
• the xoff/xon counters under load when you get a chance.

Thanks again — the G4 is now a first-class board in every build (kernel, userdata, bootloader).

[hlyi]

Hi @jnilo1 ,

1. Yes blmode_pulse works reliably for me with 1s hold time,
2. will update update documentation page when porting in a better shape ( after trying radio FW)
3. will update when I get radio up and running.

Some questions regarding your setting realtek,led-pads. Based upon the spec, it seems that LED_PORT and ethernet port is 1-1 mapping. Since Lidl uses port4, I would expect GPIOB6 would need to be configured for your LAN port LED. that was not the case?

[jnilo1]

Hi @hlyi,

Noted on 1–3 — glad the 1 s hold is reliable, and we'll wait for your parameter set and radio results for the doc page.

Your realtek,led-pads question deserved a careful answer, so before replying we put eyes on the bench — and you were right. It also uncovered a real bug, so thank you for pushing on it.

You were right: the 1-1 mapping holds on both boards

The visual re-test falsified our "LAN LED on B2" claim. Ground truth on the Lidl, verified by eye:

• B6 muxed to unclaimed GPIO (Hi-Z) → LAN LED dead, even under traffic;
• B6 muxed to the LED function (0b00) → link/activity indication returns;
• B2 in any state → no effect on the LED.

So the Lidl LAN LED is on B6 = LED_PORT4, matching its switch port 4 — exactly the Table 36 1-1 naming you read from the spec. Your G4 (port 0 → B2 = LED_PORT0) follows it too.

The wrong claim traced back to an early bring-up misdiagnosis: B2 had been driven as a GPIO, the LED didn't react, and that was read as "the LED is hardwired to the ASIC output, bypassing the pin mux" — when in fact the LED simply was never on B2. The pin mux works exactly as documented.

Which means v2.8 as shipped had a regression

With realtek,led-pads = <10> the Lidl build floated B6 and the LAN LED was dead — and no register readback could catch it, since every register held exactly the intended value. Fixed on v3.11.0-pre (ae99dc7):

• Lidl DTS: realtek,led-pads = <14> (B6);
• your G4 DTS now declares realtek,led-pads = <10> explicitly — it was silently inheriting the Lidl value through the #include, and with the base flipped to B6 (named reset-button on your board) inheritance would have killed your LED.

Note the prebuilt Lidl kernel image on the branch still predates this fix; it will be refreshed with the next batch. Your G4 builds compile the DTS from source, so you get the fix on your next build with nothing to do.

Why we still keep the property declared

Full credit: deriving the LED pads from member-ports, as you first proposed, would have been correct on both known boards — and would have prevented this very bug. We're keeping the explicit property anyway, for one reason: a port mask can prove a port is in use, but not that an LED is actually wired to its pad, and Hi-Z must stay the default for unknown wiring. The lesson we did take is recorded next to the property instead: the LED pad is a wiring fact that only a visual check proves — anyone porting to a new board should expect to verify it by eye.

[hlyi]

@jnilo1 Thanks for debugging this! And glad to hear we are aligned.

I tested this build on Sengled G4. It worked as expected 👍 Since we have a different thread #130 for radio build support, this thread is for main SoC multiple platform support, which you already successfully accomplished it. Shall we merge this branch to main, and I can close this discussion?

[jnilo1]

Glad the build works as expected on the G4 — and thanks again for catching the LED-pad regression; that was a good save.

On merging to main

The SoC-side multi-board support is done and accepted, so from your side this thread's goal is reached. The one nuance is when it reaches main: v3.11.0-pre is the public integration branch, and it merges into main as a single squashed commit at the v3.11.0 release — not before. That release will also carry two things still landing on the branch:

• the radio BOARD= work from Enhancement request: adding BOARD= support to radio FW build enviroment #130 (the EFR32 half of the same generalization), and
• a batch of driver-audit fixes we're finishing independently.

So nothing is lost by leaving pre to accumulate a little longer — the G4 is already a first-class board in every build on it (bootloader, kernel, userdata, and now the hardware doc), and it all ships together at v3.11.0, with your contributions credited.

Closing this discussion

Please go ahead and close it if you'd like — the main-SoC multi-platform work it tracked is complete. The radio side continues in #130, and the actual pre → main merge will happen at the release. I'll ping the relevant threads when v3.11.0 is tagged.

[hlyi]

Thanks @jnilo1! Closing.