board_init: Inconsistent declaration

[chrysn]

Description

The use of board_init is inconsistent: Some boards define it in their include/board.h, some don't and rely on the caller to extern void board_init(void) it.

As a side effect, the real documentation for board_init (if there is one) is neigh impossible to find.

Proposed steps

Rip out all board_init from include/board.h files, and ask murdock whether any users of it should add an exter declaration.

In parallel, think about whether it'd make sense to have a single header that declares the function once-and-for-all, and make those that fail use that.

Open questions

• Is there any good reason to have separate board.h definitions for the function?
• If we add other per-board functions, do these apply too? (For example, some boards have external power control for things like speakers; when they follow the current board_init style, it's 50:50 where and whether they declare their functions. Example: e5c0259)

[fjmolinas]

Rip out all board_init from include/board.h files, and ask murdock whether any users of it should add an exter declaration.

In parallel, think about whether it'd make sense to have a single header that declares the function once-and-for-all, and make those that fail use that.

Right out of the bat, I don't see any reason why not to do this.

[fjmolinas]

Rip out all board_init from include/board.h files, and ask murdock whether any users of it should add an exter declaration.

In parallel, think about whether it'd make sense to have a single header that declares the function once-and-for-all, and make those that fail use that.

Right out of the bat, I don't see any reason why not to do this.

Seems like cpu/cortexm_common/vectors_cortexm.c is a big user of this function. Maybe the solution would be a board_common.h header with these definitions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[fjmolinas]

This one is now fixed with #17707 and #16013