After discussion with the maintainers, the problem actually lies in the
kernel drivers where a dash is forbidden. But the da9063-hwmon driver
was using a deprecated function which was not checking the name.
BugzID: 81093
These two hardware have the ability to read out the wwan modem supply to
know when it is completely turned off.
This is abstracted to wwan-config through lmsensors rules.
BugzID: 80542
It happens that a soft reset is failing and blocking the chip in a state
where it always times out. The only wait to get out of this is to hard
reset the bluetooth chip.
BugzID: 77171
Detecting if the mac address must be inverted means doing two resets of
the chip in a short period when the mac must be inverted.
These two resets is sometimes letting the BT chip in a state where it
does not answer for more than a minute.
Also fixes getopts string: options -w and -b don't have arguments.
BugzID: 77171
settin mac address of bt and wlan is now triggered in two separated
services.
BugzID: 77171
Signed-off-by: Patrick Zysset <patrick.zysset@netmodule.com>
added several enhancements to the mac-address-set script:
- splittet wlan and bt address setting (use -w / -b options)
- fixed upper and lower case problem with vcu1 addresses
- fixed hexadecimal support with vcu2 addresses
- added testify support (incl. log_test function)
BugzID: 77171
Signed-off-by: Patrick Zysset <patrick.zysset@netmodule.com>
adding a unit test script which uses testify framework to test the
mac-address-set script for vuc1 and vcu2.
BugzID: 77171
Signed-off-by: Patrick Zysset <patrick.zysset@netmodule.com>
if a device is never getting ready on startup sequence, the wait_on()
function runs forever. with this patch it aborts after 10 seconds.
BugzID: 77171
Signed-off-by: Patrick Zysset <patrick.zysset@netmodule.com>
If NetworkManager starts before, it may change the mac address for
scanning and store the chip mac address. When finaly using a static mac
address (for an established connection or AP) it will restore the chip
address instead of our address.
BugzID: 77171
Signed-off-by: Patrick Zysset <patrick.zysset@netmodule.com>
After an overall refactoring this script now does:
* Wait on devices being ready before changing the address
* Handle errors when setting wlan or bluetooth mac address
* Handle different MAC address schemes
* Handle different behaviors when setting wlan mac:
On HW21, the address must be set while the interface is down, but on
HW23 it must be set while the interface is up and if it is down, no
error is thrown, so the modified address is checked.
* Handle different behaviors while setting BT mac:
On HW21, the address must be given with the bytes in reverse order.
We therefore first try with the right order and check the address and
retry with the reversed address if it failed.
BugzID: 77171
Signed-off-by: Patrick Zysset <patrick.zysset@netmodule.com>
those files reside now in the repository itself, thus the recipe
needed to be adapted
BugzID: 75350
Signed-off-by: Marc Mattmueller <marc.mattmueller@netmodule.com>
Our u-boot-nm.inc was just a copy of an outdated u-boot.inc.
I now changed the u-boot-nm.inc file to be a common configuration file
for our u-boot recipes.
BugzID: 75187
Signed-off-by: Lucien Mueller <lucien.mueller@netmodule.com>
And also reduce the number of created artifacts and simplify do_deploy.
The rm commands are not required. bitbake is smart enough to remove the
old deployed artifacts of a recipe.
BugzID: 74357
Signed-off-by: Patrick Zysset <patrick.zysset@netmodule.com>
we power cylce now the power of the v2x module hence it is no longer
needed.
BugzID: 72787
Signed-off-by: Marc Mattmueller <marc.mattmueller@netmodule.com>
the v2x-fw-load script was refactored and ready now a config file. The v2x
recipe installs a v2x config file depending on a distro variable
V2X_ENABLE_FW_LOAD. Inthere it is possible to declare a parameter line like
'is-placeholder-firmware=true' to skip the firmware load in the v2x-fw-load
script. The skip includes also the detection of the DFU mode of the module.
These changes enables us to introduce the v2x package in all our images so
that the service doesn't fail anymore when we are using our placeholder
firmware.
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>
The default behavior is to try to build u-boot-initial-env
Which is not implemented in our u-boot repo.
Part of yocto update to dunfell release.
BugzID: 69636
nmhw21 and hw26 are using common u-boot code base.
Thus we are creating symlink from nmhw21 to hw26.
With this fix jenkins packaging stage is working again.
BugzID: 69325
Signed-off-by: Ramon Moesching <ramon.moesching@netmodule.com>
After changing the distro config to allow reproducible builds, a side
effect was that the date printed during uboot startup was 1 Jan 1970.
In order to get the real build date in uboot, we must unset the
SOURCE_DATE_EPOCH variable.
BugzID: 67738