Skip to content

Conversation

@rjeastwest
Copy link

This is support added for the Nordic NRF54LM20, and specifically for the NRF54LM20-DK development board.

@dgarske dgarske self-assigned this Jan 12, 2026
@dgarske dgarske requested review from danielinux and dgarske January 12, 2026 20:25
Copy link
Member

@danielinux danielinux left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution! This port looks well done. I should get a board today or tomorrow to test. Meanwhile after a first look:

  • An entry in docs/Targets.md is missing. We usually put "getting started" information about the specific target in that file.
  • To ensure we don't break this, we should add at least a build test as github workflow.
  • It is unusual to toggle LEDs or in general any interaction with the bootloader is discouraged. I would kindly ask you to move the nrf54lm20_dk.c code to test_app, and feel free to call monitor/tests/led blinking from there at will. The secure bootloader should not include hal_monitor_init, and that should not be part of the hal_ workspace, neither should the bootloader expose any unnecessary interactions except the very devices used for booting/updating (e.g. SPI flash or UART updates). We do have a wolfBoot_printf facility that could be mapped to the UART if you want (not all targets include this) but it should be disabled by default unless PRINTF_ENABLED is explicitly set.
  • Avoid initializing grtc and/or calling sleep in the bootloader. Avoid unnecessary interrupts. Keep the bootloader API minimal (hal_init to set clocks and initialize peripherals, flash write/erase driver, hal_prepare_boot to deinitialize peripherals and unset clocks if needed) + optional uart.

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.

3 participants