-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net: wifi: Changes needed to run Zephyr net samples with Wi-Fi #11803
Conversation
The following west manifest projects have been modified in this Pull Request:
Note: This message is automatically posted and updated by the Manifest GitHub Action. |
c31677b
to
ca94ed7
Compare
@@ -71,6 +71,25 @@ config FLASH_LOAD_SIZE | |||
|
|||
endif # BOARD_NRF7002DK_NRF5340_CPUAPP_NS | |||
|
|||
if NETWORKING |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should do this for nRF7000/nRF7001 also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, definitely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@krish2718 Now looking at this, I would add a similar defconfig for nR7001 DK/shield, but what about nRF7000 shield? WPA_SUPP
is not needed for sure, but do NETWORKING
/NET_L2_ETHERNET
need to be enabled for scan only? Or is WIFI
/WIFI_NRF700X
enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WIFI_NRF700X
and NET_L2_ETHERNET
both are needed.
Test specificationCI/Jenkins/NRF
CI/Jenkins/integration
Detailed information of selected test modules Note: This message is automatically posted and updated by the CI |
You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds. Note: This comment is automatically posted by the Documentation Publishing GitHub Action. |
cc42928
to
aaa684e
Compare
2fa897f
to
155d233
Compare
d59dc5b
to
0b55be6
Compare
Thanks @richabp, I've applied your comments, and added "Configuration" section.
Did you mean @rlubos As discussed offline, we keep it as is for now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor changes for consistency.
f4d00bc
to
e295696
Compare
Thanks @richabp, I've applied your suggestions |
e295696
to
dbbbccc
Compare
dbbbccc
to
c7f646b
Compare
c7f646b
to
79bfe2e
Compare
990b69e
to
e9f5150
Compare
As the Zephyr part of the supplicant was moved to |
f4222be
to
b11ae86
Compare
Using the default timeout value is beneficial in terms of support for upstream sample, which often rely on network interface being up and running before the sample code starts. Using the default timeout gives the conn_mgr/supplicant a chance to connect to a Wi-Fi network before the sample runs. Therefore avoid modifying the default value of the timeout in the driver. Instead, set the timeout explicitly to 0 for the NCS samples that use the net config module. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Fine tune defaults for certain system components (heap/stacks/fd entries) to better match driver requirements. This allows to run upstream networking samples without modifying the configuration files. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case of simple samples, no Wi-Fi credentials storage backend is really needed if static credentials configuration is used. Therefore add an option to use no storage backend. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Enable Wi-Fi components essential for automatic connection establishment by default, if Wi-Fi is enabled. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Pull changes needed to run Zephyr samples with Wi-Fi Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Add a documentation page which specifies which Zephyr networking samples are currently supported in terms of nRF700x and how to build them for that platform. Add changelog entry that mentions adding nRF700x support for upstream Zephyr networking samples. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Supplicant won't work w/o sockets, so just enable them, instead of relying on dependency. This is more consistent with other modules like NET_SOCKETS_PACKET which are selected by the supplicant. It also seems that supplicant requires newlib to work, so enable it by default. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Statically created threads with K_THREAD_DEFINE() are launched after the SYS_INIT phase. This does not play well wth NET_CONFIG library, which may block during SYS_INIT until network interface is UP and RUNNING. In order to be able to connect to Wi-Fi network and thus mark the network interface as running, we need to be able to run supplicant during SYS_INIT. This can be achieved, by starting the thread dynamically during SYS_INIT phase, instead of relying on static thread creation. Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
b11ae86
to
0055cc9
Compare
This PR introduces a set of changes needed to run upstream Zephyr networking samples with nRF7002. For a list of samples, see nrfconnect/sdk-zephyr#1242 - samples with an overlay added have been successfully tested with
nrf7002dk_nrf5340_cpuapp
.This PR comprises mostly of changes needed to automatically enable features essential for Wi-Fi operation when an appropriate board is selected and networking is enabled. The current feature auto-enablement is pretty aggressive so in most cases, the only change needed on the sample side is to configure SSID/password.
Originally, I was hoping we could rely on automatic configuration only, and avoid overlays in
sdk-zephyr
, but it soon turned out that in some cases an overlay config is unavoidable (for example when the sample overwritten the defaultPOSIX_MAX_FDS
). Since we'd need to carry downstream patch anyway because of this, I've decided to add an overlay to all of the required samples, to clearly indicate which samples have been tested and are supported. This means we can relax the current approach to automatically enable certain features a bit and move configuration to the overlay files. If you think something is too much (like for example enabling Connection Manager automatically is a bit of a gray area for me) please speak up, this PR is, among others, to gather feedback.As for the remaining patches:
sdk-nrf
samples only (not sure if it's really needed though)