Moved the startup self-tests and RAM sizing behind new BSP interfaces

[fdesbiens]

Why

The framework's stated purpose is that application code can be built for any board that implements the bsp/ contracts. Neither demo could be. Both main.c files reached past those contracts for two things no portable application can see: the board's memory extents, and the hardware specifics its startup self-tests assert on.

Neither was ever application logic. The self-tests test the BSP — linker reservations, clock trees, interrupt controllers — so they belong in the BSP. Moving them takes most of the contamination in main.c with them.

What

Two new contracts in bsp/include/bsp/:

• selftest.h — bsp_self_test(report, context) runs the board's checks and reports each through an application-supplied callback, returning the failure count. Message formatting — and therefore the choice between printf() and bsp_console_write() — stays with the application while the checks stay with the board.
• memory.h — bsp_ram_region(first_unused, &base, &size) reports what RAM the application may claim, clamped against whatever the board reserves above ThreadX's first unused address.

Both targets implement both. Both main.c files now include nothing but C standard headers, tx_api.h and <bsp/...>. The NUCLEO byte pool comes out byte-identical at 88204 bytes, so there is no behaviour change on that target.

The target template and docs/architecture.md gained the two interfaces, and the template ships bsp_memory.c / bsp_selftest.c stubs so a new board has something to fill in. Neither restores the portability claim that #52 walked back — there is still no apps/ directory, and that stays true until CI builds one for two architectures.

One scope call worth flagging

Prototyping bsp_ram_region() on the PolarFire first — as the design intended — surfaced a latent bug there. Its _sbrk() bounded the heap at the end of DRAM, which is the same mistake the NUCLEO shipped with before #50. On the PolarFire it was harmless only because nothing else claimed that memory: the LM75 demo uses static stacks. The moment bsp_ram_region() promises that DRAM to an application, one oversized malloc() could take memory holding thread stacks.

Shipping the interface without fixing that would have made it a trap, so this PR also bounds the PolarFire heap against a documented 64 KB reservation that bsp_ram_region() skips, and adds a self-test guarding the bound the way the NUCLEO's test 4 does. Measured heap use on that target is under 256 bytes, so the reservation has roughly 256x headroom.

The PolarFire tick-rate compile-time check moved to hwtimer.c, next to the TICK_CYCLES constant it guards, because it needs ThreadX headers a portable main.c should not have to pull in.

Verification

Built and Renode-tested locally on both architectures with the CI-pinned toolchains (Arm GNU 14.3.Rel1, xPack RISC-V GCC 14.3.0-1, Renode 1.16.1):

Target	Build	test_renode.py
NUCLEO-F401RE (Cortex-M4)	clean, no warnings	exit 0, 8/8 self-tests pass
PolarFire Icicle (RV64)	clean apart from the known pre-existing RWX LOAD-segment warning	exit 0, 7/7 self-tests pass

Both suites were also confirmed to have kept their teeth after the move. Weakening each target's _sbrk() bound back to the end of RAM makes them exit 1 — three failures on the NUCLEO (matching what was documented when they were first written), one on the PolarFire's new guard — so no assertion was silently lost in the refactor.

Notes

• New self-test coverage: bsp_ram_region()'s invariant on both targets, and the PolarFire heap bound.
• This is the first of four steps toward closing the portability gap, and a coherent resting place on its own: BSP tests belong in the BSP, and vendor headers are out of both main.c files regardless of whether a shared apps/ ever lands.

[fdesbiens]

Why

The framework's stated purpose is that application code can be built for any board that implements the bsp/ contracts. Neither demo could be. Both main.c files reached past those contracts for two things no portable application can see: the board's memory extents, and the hardware specifics its startup self-tests assert on.

Neither was ever application logic. The self-tests test the BSP — linker reservations, clock trees, interrupt controllers — so they belong in the BSP. Moving them takes most of the contamination in main.c with them.

What

Two new contracts in bsp/include/bsp/:

• selftest.h — bsp_self_test(report, context) runs the board's checks and reports each through an application-supplied callback, returning the failure count. Message formatting — and therefore the choice between printf() and bsp_console_write() — stays with the application while the checks stay with the board.
• memory.h — bsp_ram_region(first_unused, &base, &size) reports what RAM the application may claim, clamped against whatever the board reserves above ThreadX's first unused address.

Both targets implement both. Both main.c files now include nothing but C standard headers, tx_api.h and <bsp/...>. The NUCLEO byte pool comes out byte-identical at 88204 bytes, so there is no behaviour change on that target.

The target template and docs/architecture.md gained the two interfaces, and the template ships bsp_memory.c / bsp_selftest.c stubs so a new board has something to fill in. Neither restores the portability claim that #52 walked back — there is still no apps/ directory, and that stays true until CI builds one for two architectures.

One scope call worth flagging

Prototyping bsp_ram_region() on the PolarFire first — as the design intended — surfaced a latent bug there. Its _sbrk() bounded the heap at the end of DRAM, which is the same mistake the NUCLEO shipped with before #50. On the PolarFire it was harmless only because nothing else claimed that memory: the LM75 demo uses static stacks. The moment bsp_ram_region() promises that DRAM to an application, one oversized malloc() could take memory holding thread stacks.

Shipping the interface without fixing that would have made it a trap, so this PR also bounds the PolarFire heap against a documented 64 KB reservation that bsp_ram_region() skips, and adds a self-test guarding the bound the way the NUCLEO's test 4 does. Measured heap use on that target is under 256 bytes, so the reservation has roughly 256x headroom.

The PolarFire tick-rate compile-time check moved to hwtimer.c, next to the TICK_CYCLES constant it guards, because it needs ThreadX headers a portable main.c should not have to pull in.

Verification

Built and Renode-tested locally on both architectures with the CI-pinned toolchains (Arm GNU 14.3.Rel1, xPack RISC-V GCC 14.3.0-1, Renode 1.16.1):

Target	Build	test_renode.py
NUCLEO-F401RE (Cortex-M4)	clean, no warnings	exit 0, 8/8 self-tests pass
PolarFire Icicle (RV64)	clean apart from the known pre-existing RWX LOAD-segment warning	exit 0, 7/7 self-tests pass

Both suites were also confirmed to have kept their teeth after the move. Weakening each target's _sbrk() bound back to the end of RAM makes them exit 1 — three failures on the NUCLEO (matching what was documented when they were first written), one on the PolarFire's new guard — so no assertion was silently lost in the refactor.

Notes

• New self-test coverage: bsp_ram_region()'s invariant on both targets, and the PolarFire heap bound.
• This is the first of four steps toward closing the portability gap, and a coherent resting place on its own: BSP tests belong in the BSP, and vendor headers are out of both main.c files regardless of whether a shared apps/ ever lands.

[fdesbiens]

Why

The framework's stated purpose is that application code can be built for any board that implements the bsp/ contracts. Neither demo could be. Both main.c files reached past those contracts for two things no portable application can see: the board's memory extents, and the hardware specifics its startup self-tests assert on.

Neither was ever application logic. The self-tests test the BSP — linker reservations, clock trees, interrupt controllers — so they belong in the BSP. Moving them takes most of the contamination in main.c with them.

What

Two new contracts in bsp/include/bsp/:

• selftest.h — bsp_self_test(report, context) runs the board's checks and reports each through an application-supplied callback, returning the failure count. Message formatting — and therefore the choice between printf() and bsp_console_write() — stays with the application while the checks stay with the board.
• memory.h — bsp_ram_region(first_unused, &base, &size) reports what RAM the application may claim, clamped against whatever the board reserves above ThreadX's first unused address.

Both targets implement both. Both main.c files now include nothing but C standard headers, tx_api.h and <bsp/...>. The NUCLEO byte pool comes out byte-identical at 88204 bytes, so there is no behaviour change on that target.

The target template and docs/architecture.md gained the two interfaces, and the template ships bsp_memory.c / bsp_selftest.c stubs so a new board has something to fill in. Neither restores the portability claim that #52 walked back — there is still no apps/ directory, and that stays true until CI builds one for two architectures.

One scope call worth flagging

Prototyping bsp_ram_region() on the PolarFire first — as the design intended — surfaced a latent bug there. Its _sbrk() bounded the heap at the end of DRAM, which is the same mistake the NUCLEO shipped with before #50. On the PolarFire it was harmless only because nothing else claimed that memory: the LM75 demo uses static stacks. The moment bsp_ram_region() promises that DRAM to an application, one oversized malloc() could take memory holding thread stacks.

Shipping the interface without fixing that would have made it a trap, so this PR also bounds the PolarFire heap against a documented 64 KB reservation that bsp_ram_region() skips, and adds a self-test guarding the bound the way the NUCLEO's test 4 does. Measured heap use on that target is under 256 bytes, so the reservation has roughly 256x headroom.

The PolarFire tick-rate compile-time check moved to hwtimer.c, next to the TICK_CYCLES constant it guards, because it needs ThreadX headers a portable main.c should not have to pull in.

Verification

Built and Renode-tested locally on both architectures with the CI-pinned toolchains (Arm GNU 14.3.Rel1, xPack RISC-V GCC 14.3.0-1, Renode 1.16.1):

Target	Build	test_renode.py
NUCLEO-F401RE (Cortex-M4)	clean, no warnings	exit 0, 8/8 self-tests pass
PolarFire Icicle (RV64)	clean apart from the known pre-existing RWX LOAD-segment warning	exit 0, 7/7 self-tests pass

Both suites were also confirmed to have kept their teeth after the move. Weakening each target's _sbrk() bound back to the end of RAM makes them exit 1 — three failures on the NUCLEO (matching what was documented when they were first written), one on the PolarFire's new guard — so no assertion was silently lost in the refactor.

Notes

• New self-test coverage: bsp_ram_region()'s invariant on both targets, and the PolarFire heap bound.
• This is the first of four steps toward closing the portability gap, and a coherent resting place on its own: BSP tests belong in the BSP, and vendor headers are out of both main.c files regardless of whether a shared apps/ ever lands.

[fdesbiens]

Why

The framework's stated purpose is that application code can be built for any board that implements the bsp/ contracts. Neither demo could be. Both main.c files reached past those contracts for two things no portable application can see: the board's memory extents, and the hardware specifics its startup self-tests assert on.

Neither was ever application logic. The self-tests test the BSP — linker reservations, clock trees, interrupt controllers — so they belong in the BSP. Moving them takes most of the contamination in main.c with them.

What

Two new contracts in bsp/include/bsp/:

• selftest.h — bsp_self_test(report, context) runs the board's checks and reports each through an application-supplied callback, returning the failure count. Message formatting — and therefore the choice between printf() and bsp_console_write() — stays with the application while the checks stay with the board.
• memory.h — bsp_ram_region(first_unused, &base, &size) reports what RAM the application may claim, clamped against whatever the board reserves above ThreadX's first unused address.

Both targets implement both. Both main.c files now include nothing but C standard headers, tx_api.h and <bsp/...>. The NUCLEO byte pool comes out byte-identical at 88204 bytes, so there is no behaviour change on that target.

The target template and docs/architecture.md gained the two interfaces, and the template ships bsp_memory.c / bsp_selftest.c stubs so a new board has something to fill in. Neither restores the portability claim that #52 walked back — there is still no apps/ directory, and that stays true until CI builds one for two architectures.

One scope call worth flagging

Prototyping bsp_ram_region() on the PolarFire first — as the design intended — surfaced a latent bug there. Its _sbrk() bounded the heap at the end of DRAM, which is the same mistake the NUCLEO shipped with before #50. On the PolarFire it was harmless only because nothing else claimed that memory: the LM75 demo uses static stacks. The moment bsp_ram_region() promises that DRAM to an application, one oversized malloc() could take memory holding thread stacks.

Shipping the interface without fixing that would have made it a trap, so this PR also bounds the PolarFire heap against a documented 64 KB reservation that bsp_ram_region() skips, and adds a self-test guarding the bound the way the NUCLEO's test 4 does. Measured heap use on that target is under 256 bytes, so the reservation has roughly 256x headroom.

The PolarFire tick-rate compile-time check moved to hwtimer.c, next to the TICK_CYCLES constant it guards, because it needs ThreadX headers a portable main.c should not have to pull in.

Verification

Built and Renode-tested locally on both architectures with the CI-pinned toolchains (Arm GNU 14.3.Rel1, xPack RISC-V GCC 14.3.0-1, Renode 1.16.1):

Target	Build	test_renode.py
NUCLEO-F401RE (Cortex-M4)	clean, no warnings	exit 0, 8/8 self-tests pass
PolarFire Icicle (RV64)	clean apart from the known pre-existing RWX LOAD-segment warning	exit 0, 7/7 self-tests pass

Both suites were also confirmed to have kept their teeth after the move. Weakening each target's _sbrk() bound back to the end of RAM makes them exit 1 — three failures on the NUCLEO (matching what was documented when they were first written), one on the PolarFire's new guard — so no assertion was silently lost in the refactor.

Notes

• New self-test coverage: bsp_ram_region()'s invariant on both targets, and the PolarFire heap bound.
• This is the first of four steps toward closing the portability gap, and a coherent resting place on its own: BSP tests belong in the BSP, and vendor headers are out of both main.c files regardless of whether a shared apps/ ever lands.

[fdesbiens]

Why

The framework's stated purpose is that application code can be built for any board that implements the bsp/ contracts. Neither demo could be. Both main.c files reached past those contracts for two things no portable application can see: the board's memory extents, and the hardware specifics its startup self-tests assert on.

Neither was ever application logic. The self-tests test the BSP — linker reservations, clock trees, interrupt controllers — so they belong in the BSP. Moving them takes most of the contamination in main.c with them.

What

Two new contracts in bsp/include/bsp/:

• selftest.h — bsp_self_test(report, context) runs the board's checks and reports each through an application-supplied callback, returning the failure count. Message formatting — and therefore the choice between printf() and bsp_console_write() — stays with the application while the checks stay with the board.
• memory.h — bsp_ram_region(first_unused, &base, &size) reports what RAM the application may claim, clamped against whatever the board reserves above ThreadX's first unused address.

Both targets implement both. Both main.c files now include nothing but C standard headers, tx_api.h and <bsp/...>. The NUCLEO byte pool comes out byte-identical at 88204 bytes, so there is no behaviour change on that target.

The target template and docs/architecture.md gained the two interfaces, and the template ships bsp_memory.c / bsp_selftest.c stubs so a new board has something to fill in. Neither restores the portability claim that #52 walked back — there is still no apps/ directory, and that stays true until CI builds one for two architectures.

One scope call worth flagging

Prototyping bsp_ram_region() on the PolarFire first — as the design intended — surfaced a latent bug there. Its _sbrk() bounded the heap at the end of DRAM, which is the same mistake the NUCLEO shipped with before #50. On the PolarFire it was harmless only because nothing else claimed that memory: the LM75 demo uses static stacks. The moment bsp_ram_region() promises that DRAM to an application, one oversized malloc() could take memory holding thread stacks.

Shipping the interface without fixing that would have made it a trap, so this PR also bounds the PolarFire heap against a documented 64 KB reservation that bsp_ram_region() skips, and adds a self-test guarding the bound the way the NUCLEO's test 4 does. Measured heap use on that target is under 256 bytes, so the reservation has roughly 256x headroom.

The PolarFire tick-rate compile-time check moved to hwtimer.c, next to the TICK_CYCLES constant it guards, because it needs ThreadX headers a portable main.c should not have to pull in.

Verification

Built and Renode-tested locally on both architectures with the CI-pinned toolchains (Arm GNU 14.3.Rel1, xPack RISC-V GCC 14.3.0-1, Renode 1.16.1):

Target	Build	test_renode.py
NUCLEO-F401RE (Cortex-M4)	clean, no warnings	exit 0, 8/8 self-tests pass
PolarFire Icicle (RV64)	clean apart from the known pre-existing RWX LOAD-segment warning	exit 0, 7/7 self-tests pass

Both suites were also confirmed to have kept their teeth after the move. Weakening each target's _sbrk() bound back to the end of RAM makes them exit 1 — three failures on the NUCLEO (matching what was documented when they were first written), one on the PolarFire's new guard — so no assertion was silently lost in the refactor.

Notes

• New self-test coverage: bsp_ram_region()'s invariant on both targets, and the PolarFire heap bound.
• This is the first of four steps toward closing the portability gap, and a coherent resting place on its own: BSP tests belong in the BSP, and vendor headers are out of both main.c files regardless of whether a shared apps/ ever lands.

[fdesbiens]

Why

The framework's stated purpose is that application code can be built for any board that implements the bsp/ contracts. Neither demo could be. Both main.c files reached past those contracts for two things no portable application can see: the board's memory extents, and the hardware specifics its startup self-tests assert on.

Neither was ever application logic. The self-tests test the BSP — linker reservations, clock trees, interrupt controllers — so they belong in the BSP. Moving them takes most of the contamination in main.c with them.

What

Two new contracts in bsp/include/bsp/:

• selftest.h — bsp_self_test(report, context) runs the board's checks and reports each through an application-supplied callback, returning the failure count. Message formatting — and therefore the choice between printf() and bsp_console_write() — stays with the application while the checks stay with the board.
• memory.h — bsp_ram_region(first_unused, &base, &size) reports what RAM the application may claim, clamped against whatever the board reserves above ThreadX's first unused address.

Both targets implement both. Both main.c files now include nothing but C standard headers, tx_api.h and <bsp/...>. The NUCLEO byte pool comes out byte-identical at 88204 bytes, so there is no behaviour change on that target.

The target template and docs/architecture.md gained the two interfaces, and the template ships bsp_memory.c / bsp_selftest.c stubs so a new board has something to fill in. Neither restores the portability claim that #52 walked back — there is still no apps/ directory, and that stays true until CI builds one for two architectures.

One scope call worth flagging

Prototyping bsp_ram_region() on the PolarFire first — as the design intended — surfaced a latent bug there. Its _sbrk() bounded the heap at the end of DRAM, which is the same mistake the NUCLEO shipped with before #50. On the PolarFire it was harmless only because nothing else claimed that memory: the LM75 demo uses static stacks. The moment bsp_ram_region() promises that DRAM to an application, one oversized malloc() could take memory holding thread stacks.

Shipping the interface without fixing that would have made it a trap, so this PR also bounds the PolarFire heap against a documented 64 KB reservation that bsp_ram_region() skips, and adds a self-test guarding the bound the way the NUCLEO's test 4 does. Measured heap use on that target is under 256 bytes, so the reservation has roughly 256x headroom.

The PolarFire tick-rate compile-time check moved to hwtimer.c, next to the TICK_CYCLES constant it guards, because it needs ThreadX headers a portable main.c should not have to pull in.

Verification

Built and Renode-tested locally on both architectures with the CI-pinned toolchains (Arm GNU 14.3.Rel1, xPack RISC-V GCC 14.3.0-1, Renode 1.16.1):

Target	Build	test_renode.py
NUCLEO-F401RE (Cortex-M4)	clean, no warnings	exit 0, 8/8 self-tests pass
PolarFire Icicle (RV64)	clean apart from the known pre-existing RWX LOAD-segment warning	exit 0, 7/7 self-tests pass

Both suites were also confirmed to have kept their teeth after the move. Weakening each target's _sbrk() bound back to the end of RAM makes them exit 1 — three failures on the NUCLEO (matching what was documented when they were first written), one on the PolarFire's new guard — so no assertion was silently lost in the refactor.

Notes

• New self-test coverage: bsp_ram_region()'s invariant on both targets, and the PolarFire heap bound.
• This is the first of four steps toward closing the portability gap, and a coherent resting place on its own: BSP tests belong in the BSP, and vendor headers are out of both main.c files regardless of whether a shared apps/ ever lands.

[fdesbiens]

Why

The framework's stated purpose is that application code can be built for any board that implements the bsp/ contracts. Neither demo could be. Both main.c files reached past those contracts for two things no portable application can see: the board's memory extents, and the hardware specifics its startup self-tests assert on.

Neither was ever application logic. The self-tests test the BSP — linker reservations, clock trees, interrupt controllers — so they belong in the BSP. Moving them takes most of the contamination in main.c with them.

What

Two new contracts in bsp/include/bsp/:

• selftest.h — bsp_self_test(report, context) runs the board's checks and reports each through an application-supplied callback, returning the failure count. Message formatting — and therefore the choice between printf() and bsp_console_write() — stays with the application while the checks stay with the board.
• memory.h — bsp_ram_region(first_unused, &base, &size) reports what RAM the application may claim, clamped against whatever the board reserves above ThreadX's first unused address.

Both targets implement both. Both main.c files now include nothing but C standard headers, tx_api.h and <bsp/...>. The NUCLEO byte pool comes out byte-identical at 88204 bytes, so there is no behaviour change on that target.

The target template and docs/architecture.md gained the two interfaces, and the template ships bsp_memory.c / bsp_selftest.c stubs so a new board has something to fill in. Neither restores the portability claim that #52 walked back — there is still no apps/ directory, and that stays true until CI builds one for two architectures.

One scope call worth flagging

Prototyping bsp_ram_region() on the PolarFire first — as the design intended — surfaced a latent bug there. Its _sbrk() bounded the heap at the end of DRAM, which is the same mistake the NUCLEO shipped with before #50. On the PolarFire it was harmless only because nothing else claimed that memory: the LM75 demo uses static stacks. The moment bsp_ram_region() promises that DRAM to an application, one oversized malloc() could take memory holding thread stacks.

Shipping the interface without fixing that would have made it a trap, so this PR also bounds the PolarFire heap against a documented 64 KB reservation that bsp_ram_region() skips, and adds a self-test guarding the bound the way the NUCLEO's test 4 does. Measured heap use on that target is under 256 bytes, so the reservation has roughly 256x headroom.

The PolarFire tick-rate compile-time check moved to hwtimer.c, next to the TICK_CYCLES constant it guards, because it needs ThreadX headers a portable main.c should not have to pull in.

Verification

Built and Renode-tested locally on both architectures with the CI-pinned toolchains (Arm GNU 14.3.Rel1, xPack RISC-V GCC 14.3.0-1, Renode 1.16.1):

Target	Build	test_renode.py
NUCLEO-F401RE (Cortex-M4)	clean, no warnings	exit 0, 8/8 self-tests pass
PolarFire Icicle (RV64)	clean apart from the known pre-existing RWX LOAD-segment warning	exit 0, 7/7 self-tests pass

Both suites were also confirmed to have kept their teeth after the move. Weakening each target's _sbrk() bound back to the end of RAM makes them exit 1 — three failures on the NUCLEO (matching what was documented when they were first written), one on the PolarFire's new guard — so no assertion was silently lost in the refactor.

Notes

• New self-test coverage: bsp_ram_region()'s invariant on both targets, and the PolarFire heap bound.
• This is the first of four steps toward closing the portability gap, and a coherent resting place on its own: BSP tests belong in the BSP, and vendor headers are out of both main.c files regardless of whether a shared apps/ ever lands.

[fdesbiens]

Why

The framework's stated purpose is that application code can be built for any board that implements the bsp/ contracts. Neither demo could be. Both main.c files reached past those contracts for two things no portable application can see: the board's memory extents, and the hardware specifics its startup self-tests assert on.

Neither was ever application logic. The self-tests test the BSP — linker reservations, clock trees, interrupt controllers — so they belong in the BSP. Moving them takes most of the contamination in main.c with them.

What

Two new contracts in bsp/include/bsp/:

• selftest.h — bsp_self_test(report, context) runs the board's checks and reports each through an application-supplied callback, returning the failure count. Message formatting — and therefore the choice between printf() and bsp_console_write() — stays with the application while the checks stay with the board.
• memory.h — bsp_ram_region(first_unused, &base, &size) reports what RAM the application may claim, clamped against whatever the board reserves above ThreadX's first unused address.

Both targets implement both. Both main.c files now include nothing but C standard headers, tx_api.h and <bsp/...>. The NUCLEO byte pool comes out byte-identical at 88204 bytes, so there is no behaviour change on that target.

The target template and docs/architecture.md gained the two interfaces, and the template ships bsp_memory.c / bsp_selftest.c stubs so a new board has something to fill in. Neither restores the portability claim that #52 walked back — there is still no apps/ directory, and that stays true until CI builds one for two architectures.

One scope call worth flagging

Prototyping bsp_ram_region() on the PolarFire first — as the design intended — surfaced a latent bug there. Its _sbrk() bounded the heap at the end of DRAM, which is the same mistake the NUCLEO shipped with before #50. On the PolarFire it was harmless only because nothing else claimed that memory: the LM75 demo uses static stacks. The moment bsp_ram_region() promises that DRAM to an application, one oversized malloc() could take memory holding thread stacks.

Shipping the interface without fixing that would have made it a trap, so this PR also bounds the PolarFire heap against a documented 64 KB reservation that bsp_ram_region() skips, and adds a self-test guarding the bound the way the NUCLEO's test 4 does. Measured heap use on that target is under 256 bytes, so the reservation has roughly 256x headroom.

The PolarFire tick-rate compile-time check moved to hwtimer.c, next to the TICK_CYCLES constant it guards, because it needs ThreadX headers a portable main.c should not have to pull in.

Verification

Built and Renode-tested locally on both architectures with the CI-pinned toolchains (Arm GNU 14.3.Rel1, xPack RISC-V GCC 14.3.0-1, Renode 1.16.1):

Target	Build	test_renode.py
NUCLEO-F401RE (Cortex-M4)	clean, no warnings	exit 0, 8/8 self-tests pass
PolarFire Icicle (RV64)	clean apart from the known pre-existing RWX LOAD-segment warning	exit 0, 7/7 self-tests pass

Both suites were also confirmed to have kept their teeth after the move. Weakening each target's _sbrk() bound back to the end of RAM makes them exit 1 — three failures on the NUCLEO (matching what was documented when they were first written), one on the PolarFire's new guard — so no assertion was silently lost in the refactor.

Notes

• New self-test coverage: bsp_ram_region()'s invariant on both targets, and the PolarFire heap bound.
• This is the first of four steps toward closing the portability gap, and a coherent resting place on its own: BSP tests belong in the BSP, and vendor headers are out of both main.c files regardless of whether a shared apps/ ever lands.