lopper: assists: gen_domain_dts: auto-detect carrier-board peripheral…

[kedareswararao]

… Kconfig

Lopper currently generates the Zephyr-specific devicetree but not the Kconfig defaults a peripheral may also need, so those are hand-added per board today. Add infra to generate these too: if a peripheral needs certain configs, add a rule to emit them into the board's Kconfig.defconfig, so it gets copied to the board and consumed just like the generated DT. Board-specific entries (e.g. EEPROM) can be added by reading the board name off the SDT root node.

Also guard the board_Kconfig.defconfig scratch file, reused across west lopper-command invocations, against being appended to under a stale board's guard left over from a prior run.

[kedareswararao]

@zeddii : Please review when you have sometime

[zeddii]

Thanks @kedareswararao — auto-generating the DT-derived Kconfig defaults instead of hand-adding them per board is a useful direction. A few things to sort before it can be merged: one correctness bug, a test gap, and something I'd like to understand.

1. Blocking — the stale-file guard has a hole (same board, silent config bleed).

board_Kconfig.defconfig lives in sdt.outdir, which is reused across lopper_command.py runs. Both write paths are conditional, and neither touches the file when a run has nothing to add:

• Path A (gen_domain_dts.py:1069-1079) writes a fresh file only if default_entries: — a board not in _ARM_BOARD_DEFAULT_KCONFIG gets [] and skips the write.
• Path B (_append_dt_peripheral_kconfig:1794) does if not entries: return before the guard in _append_kconfig_entries_before_endif can run.

So the guard only protects the append case. For a board not in the dict (e.g. versal2_apu):

Run 1: versal2_apu carrier design WITH an i2c EEPROM  -> Path B creates
         `if BOARD_VERSAL2_APU ... <eeprom cfg> ... endif`
Run 2: versal2_apu plain design, NO EEPROM (same outdir)
         Path A: [] -> no write;  Path B: no entries -> early return
         -> file still holds Run 1's block; guard is TRUE (same board)
         -> the plain design silently inherits an EEPROM Kconfig default it never declared.

Fix: reset the file for the current board unconditionally at the start of the run (or delete any pre-existing scratch copy) before either path, so a prior run can't survive regardless of whether this run adds anything.

2. Please add tests. The new helpers (detect_dt_peripherals, board_symbol_for_machine, detect_board_i2c_mux_prio, _append_kconfig_entries_before_endif) are pure string/regex logic and easy to unit-test — especially the stale-file guard above, which is the crux of the change and currently unverified.

3. Not a blocker — just thinking out loud on _ARM_BOARD_DEFAULT_KCONFIG. I was wondering about the baked-in defaults here — they look like a verbatim copy of upstream's boards/amd/versal_apu/Kconfig.defconfig and versal_rpu/Kconfig.defconfig (the BUILD_OUTPUT_BIN default, the USERSPACE/COMPILER_ISA_THUMB2 block), which upstream also maintains, so I could see them drifting over time. I'm not exactly sure how these files get consumed by the Zephyr build on the lopper_command.py side (copied over the in-tree file, merged, sourced?), so this really isn't blocking — I just want to understand the flow, and maybe see if there's a smaller-footprint way to get the same result (e.g. emitting only the DT-derived additions and leaving the upstream baseline in place). If you can sketch how the generated board_Kconfig.defconfig gets picked up, that'd help.

None of this is a rejection — the peripheral-detection logic is sound and well-commented, and the blast radius is safely Zephyr-scoped. The stale-file bug + tests are the things to fix in this PR; #3 is just me trying to understand the flow.