d) Configure an output for console
I propose to shave away board configuration multiplicity and promote few guidelines
TL;DR: Numquam ponenda est pluralitas sine necessitate(approx: define guidelines for default board configuration)
Most of the boards supported in Zephyr tree could be configured in quite multiple ways,
either for pins configuration, hardware interfaces, instances of these interfaces and
then configuration of the drivers for each of these entities.
When porting a board and pushing it upstream, one will either copy configuration fromOutcome is a great heterogeneity of configurations and discussions during reviews.
a similar board, either configure the board according to his constraints or interesting
Besides, these various configurations don't make things easy when one try to enable
tests/samples running on multiple boards.
defining default (in tree) board configurations:
a) When a connector (arduino, 96board, ....) is present, configure pins to fit this connector
b) Configure ips matching these pins (For instance configure SPI instance for arduino SPI)c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
Ethernet, VCP, )
e) Propose and configure a default network interface
f) Enable all GPIO ports
g) Provide device tree Zephyr aliases
These guidelines won't avoid discussions since some for these points will conflict for
some boards. Also, some points deserve clarification (configuration means configured
only or configured and enabled?).
g) introduces zephyr aliases and could be seen a separated topic:
Some are already used today, as a tacit rule, also known as LED0, SW0. I propose to
extend these to other components (SPI, I2C, .) and define them in board device tree file.
zephyr,led0 = &green_led_1;
zephyr,sw0 = &user_button;
zephyr,spi = &spi3;
zephyr,serial = &uart2
Using these aliases (and their generated #define) directly in samples/tests would help to
make tests generic without too much trouble. I've set this approach in practice in PR
#5381 [RFC] Add gpio nodes to stm32 based soc/boards 
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays