samples: boards: nxp: s32: create sample mbox

[congnguyenhuu]

The sample supports ping-pong loopback data on a MBOX channel within one core.
The expected received data must match the sent data when running the sample.

The sample result on s32z2xxdc2/s32z270/rtu0:

   mbox_data demo started
   send (on channel 0) value: 0
   received (on channel 0) value: 0
   send (on channel 0) value: 1
   received (on channel 0) value: 1
   ...
   send (on channel 0) value: 98
   received (on channel 0) value: 98
   send (on channel 0) value: 99
   received (on channel 0) value: 99
   mbox_data demo ended

[congnguyenhuu]

Hello @kartben, Could you please take a look at my PR? Thanks!

[manuargue]

The hardware MRU on SoC S32Z supports ping-pong loopback data on a MBOX channel within one core.

While it's technically possible to send a message from a CPU to itself, that's not a typical or very meaningful use case -especially in the context of a sample. Mailbox peripherals like the MRU are generally intended for inter-CPU communication. This implementation feels more like an internal test case rather than functionality that should be demonstrated in a generic Zephyr sample.

[congnguyenhuu]

While it's technically possible to send a message from a CPU to itself, that's not a typical or very meaningful use case -especially in the context of a sample. Mailbox peripherals like the MRU are generally intended for inter-CPU communication. This implementation feels more like an internal test case rather than functionality that should be demonstrated in a generic Zephyr sample.

Yes, this implementation is internal and specific to the NXP S32 SoC. Therefore, I created an internal test for the NXP S32 SoC instead of doing in the generic Zephyr test.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
61.0% Duplication on New Code

See analysis details on SonarQube Cloud

[manuargue]

Yes, this implementation is internal and specific to the NXP S32 SoC. Therefore, I created an internal test for the NXP S32 SoC instead of doing in the generic Zephyr test.

By internal I really meant, internal, as not on this Github repo :) I fail to see the benefit of having an NXP sample for the mailbox driver where a CPU send msgs to itself. We could have maybe two Zephyr apps exchanging msgs through the mailbox, it would make more sense.

If the mbox maintainers think this is useful, please keep it in the generic sample as you originally did. I can only advise from the NXP S32 pov.

[kartben]

What @manuargue said, basically. It's really not clear why this new sample would be needed.