Additionally the two follow up commits are reverted too:
Revert "lpa: Remove dependencies to NRSW"
Revert "lpa: Use latest version with patched toby driver"
This reverts commit
8f2fca9c5f,
c1187b5553 and
c18ced1d01.
id:379399
Signed-off-by: Patrick Zysset <patrick.zysset@netmodule.com>
The default APN configuration is only required for TOBY-L2. For LARA, it
is properly handled through the QMI interface.
For LARA the only supported profile is RMNET, so this is not
configurable.
tpID: #354963
LARA-L6 is using a QMI interface so we need to enable QMI and the
"generic" plugin.
Also we need to backport libqmi to have the version matching
ModemManager 1.14.
BugzID: 81947
Now all scenarios with a user module are covered:
- static setup with a user module will create a bridge with static IP
- dhcp setup with a user module will put a static IP on the UM and DHCP
on the main interface
BugzID: 81969
This is a setup required for the factory testing image: the user module
must be reachable from the CPU. And since the subnet of the fct ethernet
port and the subnet of the user module are the same, we must bridge them
together.
BugzID: 81969
As explained in the comment, the start of this service may include some
power cycles of the modem and also the startup of ModemManager. All of
this may take longer than the default 90 seconds in some special cases.
This should anyway not be a problem since this service is self resilient
and can handle errors during startup.
BugzID: 80178
hw23: Force wpa-supplicant and hostapd versions
meta-netmodule-wlan provides modified versions of these tools, but they
seem to not work properly on HW23. Since this HW is anyway not supported
in meta-netmodule-wlan, we force the usage of latest stable version.
BugzID: 77173
Co-authored-by: Patrick Zysset <patrick.zysset@netmodule.com>
Reviewed-on: https://git.netmodule.intranet/yoctoproject/meta-netmodule-bsp/pulls/111
Co-Authored-By: Alexandre Bard <alexandre.bard@netmodule.com>
Co-Committed-By: Alexandre Bard <alexandre.bard@netmodule.com>
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>
There is no guarantee that a fix delay is actually enough, because with
the BT_EN gpio, we only control activation of bluetooth on the chip. But
we don't know the status of the whole chip.
Also hciattach has anyway a timeout of 5 seconds, so 0.1 seconds does
probably not make a big difference in this regard.
So in order to make it the safest possible, we can only rely a failure
handling and retrying. The number 5 for retries has been defined since
repeated restart of the service with only 3 retries leads to failure
pretty quickly. At 4 there is no failure anymore. So with 5 we are sure
the risk of failure is really low.
BugzID: 70195
This package contains gpioset, gpiofind, etc
This tools are required to access the gpios from shell scripts.
Also fixes the RDEPENDS ${PN}
BugzID: 65420
Name the BT_EN gpio in the device tree when you want to use this service.
It has to be found with the command: "gpiofind BT_EN".
Signed-off-by: Lucien Mueller <lucien.mueller@netmodule.com>
It was already the case for HW18: eth2 was the default.
Now with HW25, we can't rely either on eth0 name since it is assigned by
default to the wrong port.
We are therefor using lan0 for HW25 and make the nm-conf recipe more
generic.
BugzID: 69468
In order to make the service start faster we make it less nice.
It will therefor have more cpu resources to setup the modem faster. The
overall goal being to have WWAN connectivity earlier during boot
process.
BugzID: 67742
The wifi and bluetooth chip ti wl18xx firmware files are handled by seperate
meta-netmodule-wlan layer.
BugzID: 67576
Signed-off-by: Ramon Moesching <ramon.moesching@netmodule.com>
Mr Jenkins
Alexandre Bard
Patrick Zysset
Marc Mattmueller
Lucien Mueller
Ramon Moesching