fix tests scenarios failing with undefined reference to z_impl_sys_rand_get

[manuargue]

Some tests are failing with undefined reference to z_impl_sys_rand_get for boards hexiwear/mk64f12 and frdm_k64f/mk64f12. It looks like these boards lack of RNG driver and and the test scenarios are not enabling any test RNG, so enable it.

Not sure about side effects, so I'm open to better suggestions -I'm just trying to unblock unrelated CI failures in another pr.

Fixes #82344

[Thalley]

Not sure about this change.

The documentation for the option states:

	  This option is intended to be selected only by application-level
	  configurations (e.g. in tests and samples) to indicate that the
	  application is allowed to run with a random number generator that is not
	  truly random. Board-level configurations must not select this option
	  unless the sole purpose of the board is testing (e.g. QEMU emulation
	  boards).

Not sure if we can consider these cases here tests.

Furthermore, the option is hardened, which will give a build warning. That doesn't like something we really want to have in samples.

An alternative to this PR is to remove the boards that do not support a random generator for applications that require a random generator.

[manuargue]

An alternative to this PR is to remove the boards that do not support a random generator for applications that require a random generator.

my bad, it seems that is possible to enable CONFIG_ENTROPY_GENERATOR=y for these SoCs -which I'm not familiar with :)

[Thalley]

An alternative to this PR is to remove the boards that do not support a random generator for applications that require a random generator.

my bad, it seems that is possible to enable CONFIG_ENTROPY_GENERATOR=y for these SoCs -which I'm not familiar with :)

Doing a search for CONFIG_ENTROPY_GENERATOR=y show that it's more common to enable this in the prj.conf files, rather than in board files.

I'm not sure which way is "correct"

[manuargue]

Doing a search for CONFIG_ENTROPY_GENERATOR=y show that it's more common to enable this in the prj.conf files, rather than in board files.

I based on https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/bluetooth/peripheral_ht/boards/frdm_rw612.conf#L2. I'm not familiar enough with the tests to enable it at prj.conf, so I'll let others with better knowledge than me on this to comment.

[jhedberg]

I'd assume it's the enabling of Bluetooth that brings this dependency. It might make more sense to do this as a select statement in the HCI driver that this board uses, similar to what was done for ESP32 here: #82198

[manuargue]

I'd assume it's the enabling of Bluetooth that brings this dependency. It might make more sense to do this as a select statement in the HCI driver that this board uses, similar to what was done for ESP32 here: #82198

It's using the BT_H4/zephyr,bt-hci-uart generic driver, not an specific NXP implementation.

I see from https://github.com/zephyrproject-rtos/zephyr/pull/79931/files three other different approaches to this same problem:

1. Select CONFIG_ENTROPY_GENERATOR=y from test/sample prj.conf
2. Select CONFIG_ENTROPY_GENERATOR=y from the board's sample/test conf overlay
3. Set CONFIG_ENTROPY_GENERATOR default to y in the board defconfig when BT=y

If the dependency comes from the BT_H4 driver, then I agree with you to select it from there. Otherwise, (3) may be a better fit.

[jhedberg]

I need to take a look of it's some subset of Bluetooth functionality (or subset boards with Bluetooth) that need this, or if it's always needed. If it's the latter, maybe we should just add the select to config BT.

[jhedberg]

Right now this seems to be fixing this on a per-app basis, which would then leave all other Bluetooth apps broken with this board. So out of the various alternatives being discussed that's probably the worst option.

[jhedberg]

Could you try if the same issue gets fixed by #82363? If so, then we should probably move to that instead of selecting ENTROPY_GENERATOR separately for each board or HCI driver.

[manuargue]

Could you try if the same issue gets fixed by #82363? If so, then we should probably move to that instead of selecting ENTROPY_GENERATOR separately for each board or HCI driver.

@jhedberg agree, it fixes the issue indeed, thanks! Btw you may want to also cleanup all the tests/samples overlays that are selecting ENTROPY_GENERATOR for specific boards after your change.

[manuargue]

moved to #82363