WFX Linux driver parameters are accessible under /sys/module/wfx/parameters/

sudo tree /sys/module/wfx/parameters/

/sys/module/wfx/parameters/
├── gpio_reset
├── gpio_wakeup
└── power_mode

Each parameter can be checked

sudo cat /sys/module/wfx/parameters/gpio_reset
-2
sudo cat /sys/module/wfx/parameters/gpio_wakeup
-2
sudo cat /sys/module/wfx/parameters/power_mode
0

These parameters match those listed in the modinfo wfx parameters description

parm: gpio_reset:gpio number for reset. -1 for none. (int)
parm: gpio_wakeup:gpio number for wakeup. -1 for none. (int)
parm: power_mode:Force power save mode. 0: Disabled, 1: Allow doze, 2: Allow quiescent (int)

Possible values

• -2 (default): use values set in device tree
• -1: none (GPIO unused)
• any positive value: GPIO number as it would be set in the device tree

To check which GPIOs are currently allocated, use sudo cat /sys/kernel/debug/gpio

Typical result when using WF(M)200 in SPI mode

GPIOs 0-53, platform/3f200000.gpio, pinctrl-bcm2835:
 gpio-12 ( |wakeup ) out lo
 gpio-13 ( |reset ) out hi
GPIOs 100-101, platform/soc:virtgpio, brcmvirt-gpio, can sleep:
 gpio-100 ( |? ) out lo

Above, the 'wakeup' and 'reset' names match the names listed in the modinfo wfx parameters description:

parm: gpio_reset:gpio number for reset. -1 for none. (int)
parm: gpio_wakeup:gpio number for wakeup. -1 for none. (int)
parm: power_mode:Force power save mode. 0: Disabled, 1: Allow doze, 2: Allow quiescent (int)

1. Introduction

“The IoT Hub Device Provisioning Service is a helper service for IoT Hub that enables zero-touch, just-in-time provisioning to the right IoT hub without requiring human intervention, allowing customers to provision millions of devices in a secure and scalable manner.” – definition by Microsoft

The general overview of the process is defined as the following:

1. Device manufacturer adds the device registration information to the enrollment list in the Azure portal.
2. Device contacts the provisioning service endpoint set at the factory. The device passes the identifying information to the provisioning service to prove its identity.
3. The provisioning service validates the identity of the device by validating the registration ID and key against the enrollment list entry using standard X.509 verification (X.509).
4. The provisioning service registers the device with an IoT hub and populates the device's desired twin state.
5. The IoT hub returns device ID information to the provisioning service.
6. The provisioning service returns the IoT hub connection information to the device. The device can now start sending data directly to the IoT hub.
7. The device connects to IoT hub.
8. The device gets the desired state from its device twin in IoT hub.

2. Create and Configure DPS via Azure IoT Portal

2.1. Create an IoT Hub (if you do not have already)

• Go to your Azure Portal: https://portal.azure.com, and sign in using your Azure account.
• Click Create a resource
• Click Internet of Things
• Click IoT Hub
• Fill out the form and click Create

2.2. Create an IoT Hub Device Provisioning Service

• Same as before: Azure Portal > Create a resource > Internet of Things
• This time choose IoT Hub Device Provisioning Service
• Fill out the required fields and click Create

2.3. Link the IoT Hub to your Device Provisioning Service

• Click the DPS instance that you created (you can access it from All resources link to the left)
• Click Linked IoT hubs
• Click Add
• Select your IoT hub and Save

2.4. Create a Certificate for your Device Provisioning Service

You need a .pem file that contains an intermediate or root CA X.509 certificate. We use OpenSSL here to create the CA cert:

• Generate root key and X509 cert:

Note: the validity for this cert is set to 10 years. Change if you want a longer/shorter lifetime.

openssl req -x509 -newkey rsa:2048 -keyout root_private.pem -nodes -days 3650 -out root_cert.pem

• Press enter for default values
• Create verification key:

openssl genrsa -out verification.key 2048   

2.5. Upload the Certificate to your Device Provisioning Service

• Open your instance of Device Provisioning Service instance
• Click Certificates
• Click Add.
• Give it a name of your choice in the Certificate Name field
• Upload your certificate (root_cert.pem) and click Save

2.6. Verify the Certificate

• Click the certificate you’ve just created
• Click Generate Verification Code. That will generate a 48 characters length code. Take a note of it.
• Using the code, create the verification cert:

openssl req -new -key verification.key -out verification.csr

• Press enter to choose default parameters.
• For "Common Name", use the verification code obtained above
• Create the proof of possession certificate:

openssl x509 -req -in verification.csr -CA root_cert.pem -CAkey root_private.pem -CAcreateserial -out verificationCert.pem -days 1024 -sha256

• This will sign the verification.csr, that has the verification code as the Common Name, with the root private key.
• Upload your verification certificate verificationCert.pem as a proof of possession, and click Verify

2.7. Create an Enrollment Group

• Open your instance of Device Provisioning Service instance
• Click Manage enrollments
• Click Enrollment Groups
• Click Add
• Fill out the form and click Save

2.8. Take a note of your DPS details

• Open your instance of Device Provisioning Service instance
• Click Overview
• Take note of the Global device endpoint and ID Scope. Those parameters will be used in the following steps.

3. Create a DMS Connector

Now you have created and configured your DPS, it is the time to create a “connector” and link it to your DPS instance

Notes:

1. For more about DMS connectors, please have a look at the tutorial here: https://dms.zentri.com/tutorial/connectors
2. This step assumes you have already a product created. If not, please follow the tutorial here: https://dms.zentri.com/tutorial/create-product

• Then, go to the DMS: https://dms.zentri.com/
• Click Products
• Choose your product out of the list
• Click Connectors
• Click Create Connector
• Fill out the form
  • For Type, select Provision
  • For Endpoint, select Azure IoT Hub
  • For Provisioning Host, enter the Global device endpoint of your DPS (obtained above)
  • For ID Scope, enter the ID Scope for your DPS (obtained above)
  • For Certificate, paste in your generated certificate (e.g., root_private.pem obtained above)
  •  For RSA Private Key, paste in your generated key (e.g., root_cert.pem obtained above)
• Click Save
• The created connector is linked to your product, and any device activated to this product can communicate with it.

4. Device side: Gecko OS Application

Note: Gecko OS project is attached for reference

Now you have a connector ready and DPS configured in Azure, it is the time to send a provisioning request from the device side to the DMS connector. DMS in turn sends the request to Azure and returns back the device certificate and key. Once device obtains the cert and key pair, it encrypts and stores them securely on the file system then using them for farther communication with Azure IoT Hub. The DPS and DMS connector are done at this stage

Note: This part assumes basic knowledge of development using Gecko OS. For more info, please head to the online doc:

1. https://docs.silabs.com/gecko-os/4/standard/latest/
2. https://docs.silabs.com/gecko-os/4/standard/latest/cmd/
3. https://docs.silabs.com/gecko-os/4/standard/latest/sdk/

• Activate device to the product created above (since, it can use the connector): https://dms.zentri.com/tutorial/activate-to-product
• In Gecko OS, enable the DMS websocket to automatically start when the network is brought up:

set dms.auto_start_enabled 1

• Device establishes a secure websocket connection with DMS using its own device cert.
• Device registers for DMS message responses
• Once device connects to DMS websocket, app sends a provisioning request in the form:

{
  request: 'provision',
  code: code
}

• DMS gets the request (including the device UUID as an identifier), then talks to Azure to provision the device in IoT Hub
• If successful, Azure replies back with the device cert/key pair
• DMS responds to the provision request with the device cert/key pair. The response format looks like:

{
  "assignedHub": "my-iot-hub.azure-devices.net",
  "deviceId": "ffffffffffffffffffffffffffffffffffffffff",
  "cert": "-----BEGIN CERTIFICATE-----\n<...>\n-----END CERTIFICATE-----",
  "key": "-----BEGIN RSA PRIVATE KEY-----\n<...>\n-----END RSA PRIVATE KEY-----"
}

• Device retrieves the cert and key, then write them to the file system securely
• Device disconnects
• Later, when device wants to communicate with Azure IoT Hub, it establishes TLS connection using the client key and cert. That is done as the following:

set network.tls.client_cert azure_client_cert.pem
set network.tls.client_key azure_client_key.pem
tls_client .azure-devices.net 8883

• For more details about Gecko OS TLS client:

https://docs.silabs.com/gecko-os/4/standard/latest/networking-and-security#tls-client