arch: Remove default value for BOARD_LOOPSPERMSEC

[linguini1]

Summary

This commit removes the default Kconfig value for CONFIG_BOARD_LOOPSPERMSEC.
This will result in a compile time error for any users who have not configured
this value for their board.

QEMU ARMv8-A configurations were given a value obtained by running
calib_udelay on the NSH configuration.

Closes #17004.

Impact

Users will no longer waste time debugging issues that result from having an incorrect value of this configuration option, causing delay/timing issues.

This will affect any user-created defconfig (or NuttX provided defconfig)
without a value set for CONFIG_BOARD_LOOPSPERMSEC by preventing them from
compiling. It causes files that use CONFIG_BOARD_LOOPSPERMSEC while it is
undefined to fail compilation.

Testing

Compiling the configuration nucleo-g474re:lpuartnsh (currently has no value
set for CONFIG_BOARD_LOOPSPERMSEC), we see the compile error as desired:

$ make -j
Create version.h
LN: platform/board to /home/linguini/coding/nuttx-space/apps/platform/dummy
Register: dd
Register: nsh
Register: sh
CC:  group/group_signal.c clock/delay.c: In function 'udelay_coarse':
clock/delay.c:79:23: error: 'CONFIG_BOARD_LOOPSPERMSEC' undeclared (first use in this function); did you mean 'CONFIG_BOARD_LOOPSPERUSEC'?
   79 |       for (i = 0; i < CONFIG_BOARD_LOOPSPERMSEC; i++)
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                       CONFIG_BOARD_LOOPSPERUSEC
clock/delay.c:79:23: note: each undeclared identifier is reported only once for each function it appears in

When we set the parameter to a dummy value of 0, compilation passes:

$ make -j
Create version.h
LN: platform/board to /home/linguini/coding/nuttx-space/apps/platform/dummy
Register: sh
Register: nsh
Register: dd
In file included from chip/stm32_flash.c:42:
chip/stm32g4xxx_flash.c:78:4: warning: #warning "Flash Configuration has been overridden - make sure it is correct" [-Wcpp]
   78 | #  warning "Flash Configuration has been overridden - make sure it is correct"
      |    ^~~~~~~
CC:  misc/lib_debug.c chip/stm32_gpio.c:44:11: note: '#pragma message: CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py'
   44 | #  pragma message "CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py"
      |           ^~~~~~~
CPP:  /home/linguini/coding/nuttx-space/nuttx/boards/arm/stm32/nucleo-g474re/scripts/ld.script-> /home/linguini/coding/nuttx-space/nuttx/boards/arm/stm32/nucleo-g474re/scriptLD: nuttx
Memory region         Used Size  Region Size  %age Used
           flash:      128596 B       512 KB     24.53%
            sram:        8144 B        96 KB      8.28%
CP: nuttx.bin

Since some boards do not have active users who can provide us with a correct
value, I have set those board configurations to use a value of
CONFIG_BOARD_LOOPSPERMSEC=0 to allow this PR to be merged without breaking the
CI runs due to build errors. However, these boards have a warning in the
board.h file now to ask users to use a proper value and please submit the
patch to the upstream repository. Here is what that looks like at compile time
for one of the stm32 boards:

$ make -j
Create version.h
LN: platform/board to /home/linguini/coding/nuttx-space/apps/platform/dummy
Register: nsh
Register: sh
Register: dd
In file included from misc/assert.c:41:
/home/linguini/coding/nuttx-space/nuttx/include/arch/board/board.h:39:2: warning: #warning "CONFIG_BOARD_LOOPSPERMSEC is set to 0 to prevent CI build errors." "up_udelay() and similar delay functions will not work correctly." "If you use this board, please determine an appropriate value using the" "calib_udelay application in nuttx-apps. It would be appreciated if you" "submit a patch with the new value to apache/nuttx and remove this warning." [-Wcpp]
   39 | #warning "CONFIG_BOARD_LOOPSPERMSEC is set to 0 to prevent CI build errors." \
      |  ^~~~~~~

[linguini1]

Looks like there are some defconfigs using the default value. Good to catch.

[cederom]

Looks like we need to fix the boards where -1 / default is used, just to pass build here and have correct timings on these boards, then update the res of the boards depending on what we have at hand? :-)

On the other hand we may keep this default and put some pressure / attention to the proper timings calibration when using different boards. I am wondering what impacts the value and if the differences are big - is it build specific? For instance when using different compiler, specific optimization level, many irqs, threads, etc :-)

I mean this 5000 default was set because any default may be wrong when this value is not calibrated on a final firmware build? People just did not know that? In that case we may leave as-is and just add Pre-Flight-Check-List to the documentation with list of important things to know / check / verify when creating / building NuttX based projects? :-)

[acassis]

@linguini1 instead of suggesting searching for CONFIG_BOARD_LOOPSPERMSEC I suggest search for calib_udelay because there is not a page dedicated to CONFIG_BOARD_LOOPSPERMSEC and when searching for it returns many pages.

Searching for calib_udelay returned two pages, but I think we need to move calib_udelay from apps/examples/ to apps/system/ because it is a system tool used to help the system to work correctly. And it also will avoid calib_udelay returning in the apps examples pages. What do you think?

[linguini1]

@linguini1 instead of suggesting searching for CONFIG_BOARD_LOOPSPERMSEC I suggest search for calib_udelay because there is not a page dedicated to CONFIG_BOARD_LOOPSPERMSEC and when searching for it returns many pages.

That's fine, I plan to make one for BOARD_LOOPSPERMSEC but it's better to redirect to calib_udelay for now, I agree.

Searching for calib_udelay returned two pages, but I think we need to move calib_udelay from apps/examples/ to apps/system/ because it is a system tool used to help the system to work correctly. And it also will avoid calib_udelay returning in the apps examples pages. What do you think?

I don't mind moving it to the system directory but that's outside the scope of this PR. I agree it makes more sense, but I might do it later. Right now I just want to prevent users from making a frustrating mistake.

[linguini1]

MSVC failure appears unrelated.

[acassis]

MSVC failure appears unrelated.

@simbit18 you are the MS guy, any idea?

[linguini1]

@acassis @jerpelea do you think this change would be considered a "breaking change"?

[acassis]

@acassis @jerpelea do you think this change would be considered a "breaking change"?

No, it is not.

[linguini1]

@linguini1 if this PR isn't ready to merge, please mark it as draft to avoid the accidental merge :-) Thank you!

With these new commits it should be ready to merge, provided that the CI passes!

[cederom]

Ugh, another problem revealed now? If there are build errors then CI will fail for all builds after merge? o_O

====================================================================================
Configuration/Tool: sim/citest
2026-01-02 19:43:04
------------------------------------------------------------------------------------
  Cleaning...
HEAD detached at pull/17011/merge
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	defconfig.tmp

nothing added to commit but untracked files present (use "git add" to track)
  Configuring...
  Building NuttX...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

100  143k    0  143k    0     0   363k      0 --:--:-- --:--:-- --:--:--  363k

100 1646k    0 1646k    0     0  3124k      0 --:--:-- --:--:-- --:--:-- 3124k
timers/arch_alarm.c: In function 'udelay_coarse':
Error: timers/arch_alarm.c:67:23: error: 'CONFIG_BOARD_LOOPSPERMSEC' undeclared (first use in this function); did you mean 'CONFIG_BOARD_LOOPSPERUSEC'?
   67 |       for (i = 0; i < CONFIG_BOARD_LOOPSPERMSEC; i++)
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                       CONFIG_BOARD_LOOPSPERUSEC
timers/arch_alarm.c:67:23: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [Makefile:109: arch_alarm.o] Error 1
make[1]: Target 'libdrivers.a' not remade because of errors.
make: *** [tools/LibTargets.mk:107: drivers/libdrivers.a] Error 2

[linguini1]

Ugh, another problem revealed now? If there are build errors then CI will fail for all builds after merge? o_O

Yeah, I'm travelling right now but I aim to fix this. The other sim configs are able to avoid the use of LOOPSPERMSEC so it should be a trivial change for this one too. Hopefully the last issue left!

[cederom]

Safe travels @linguini1 :-)

[linguini1]

Can anyone tell me how I might run qemu-armv7r:nsh? There is no documentation for that version of QEMU but I'd like to run calib_udelay to get a value for it

[cederom]

Maybe this? https://nuttx.apache.org/docs/latest/platforms/arm/qemu/boards/qemu-armv7a/index.html

[linguini1]

Maybe this? https://nuttx.apache.org/docs/latest/platforms/arm/qemu/boards/qemu-armv7a/index.html

I tried to adapt that to armv7 by using -cpu cortex-r5 but no luck. I want to make sure I have the correct setup so the value is correct.