Reason for reverting to originial state:
- adaption of the v2x-fw-load script
- re-introduction of the v2x recipe in all of our images
- no difference when wainting on USB disconnect event or directly
releaseing the gnss module from its reset
BTW: The original timeout of 50s can be explained as the SCU held a
delay of 40s until powering the v2x module. This delay shall be
removed in the next couple of days.
BugzID: 72787
Signed-off-by: Marc Mattmueller <marc.mattmueller@netmodule.com>
start-up changes:
- usb-hub is just released from reset
- gnss-init service calls a script twice:
- as pre-step: checking the hub state depending on the start
reason:
- at reboot --> just go on, at power-up
- at power-up --> wait for a USB disconnect
of a device for a certain
time
- as start step: releasing gnss module from reset
shutdown changes:
- no resets were triggered
BugzID: 72787
Signed-off-by: Marc Mattmueller <marc.mattmueller@netmodule.com>
The bootloader might already release the usb-hub, the v2x module and
the gnss modem from reset. Thus the usb-hub and the gnss modem are put
into reset first so that a proper enumeration would be possible.
BugzID: 72787
Signed-off-by: Marc Mattmueller <marc.mattmueller@netmodule.com>
The v2x firmware load script contained also the usb hub reset which
affects the GNSS modem. This means that the GNSS modem worked only
when the v2x recipe was enabled. But without firmware the v2x-service
fails at start-up which affects all other images except vcu.
Therefore the usb-hub reset part was extracted from the v2x firmware
load script so that we decouple those two functions. ZF/OM need a
failing v2x service when no firmware is loaded, thus the v2x service
was moved back to the vcu image (see meta-netmodule-om).
The systemd services v2x and gnss-init depend now on usb-hub-reset
whereas gnss-init additionally depends on v2x (if available).
BugzID: 72787
Signed-off-by: Marc Mattmueller <marc.mattmueller@netmodule.com>
Marc Mattmueller
Ramon Moesching