risc-v/mpfs: ihc: don't wait for master if it's already up

[eenurkka]

After rebooting this ihc client hart only, ihc will hang as it's waiting for the initial handshake that just won't be there. Detect this situation and let the rptun / ihc know the master is already up. This makes the RPMSG bus usable even after NuttX reboot, in case there's not much traffic. However, Linux is likely to mark the virtio queue broken if there's descent amount of traffic. This makes the bus no longer function.

Summary

Fix NuttX <-> Linux RPMSG after NuttX reboots

Impact

NuttX <-> Linux RPMSG bus after NuttX reboot

Testing

Saluki v2

[eenurkka]

Will send new version soon

[jlaitine]

Somehow I find this fishy.

After a warm re-boot, initially g_vq_idx is initialized to 0, which == VRING0_NOTIFYID . Thus after a warm reboot this just always passes?

Would it be cleaner to just initialize g_vq_idx to some invalid value (e.g. 0xffff) and compare directly to that? That is,

#define VRING_UNINITIALIZED 0xffff
static uint16_t g_vq_idx = VRING_UNINITIALIZED;

...

if (g_vq_idx == VRING_UNINITIALIZED)
  {
     return;
  } 

[eenurkka]

After a warm boot, g_vq_idx is sometimes (1/10 or so) garbaged, so it won't be 0xffff, maybe the illegal value comes from the msg. Maybe I need to dig in more where the garbaged semi-random value comes from.

But setting it to an illegal value, eg 0xffff sounds like a good idea, but cannot compare to that as g_vq_idx is a rather random value when it corrupts.

[eenurkka]

 .sbss.g_rptun_initialized
                0x00000000a060f30c        0x1 ../../NuttX/nuttx/arch/risc-v/src/libarch.a(mpfs_ihc.o)
 *fill*         0x00000000a060f30d        0x1
 .sbss.g_vq_idx
                0x00000000a060f30e        0x2 ../../NuttX/nuttx/arch/risc-v/src/libarch.a(mpfs_ihc.o)
 .sbss._ZGVN10ModuleBaseI3ADCE7_objectE
                0x00000000a060f310        0x8 ../../src/drivers/adc/board_adc/libdrivers__board_adc.a(ADC.cpp.obj)
                0x00000000a060f310                guard variable for ModuleBase<ADC>::_object
 .sbss._ZN7cm8jl655g_devE
                0x00000000a060f318        0x8 ../../src/drivers/distance_sensor/cm8jl65/libdrivers__cm8jl65.a(cm8jl65_m>                0x00000000a060f318                cm8jl65::g_dev

I'll check if the neighbors overflow...

[jlaitine]

I guess it can only come through mpfs_ihc_interrupt, is there some spurious irq at boot up?