Commit graph

26 commits

Author SHA1 Message Date
Ulf Magnusson
ec3eff57e0 Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.

There are at least three problems with the patch:

  1. It's inconsistent with how Kconfig works in other projects, which
     might confuse newcomers.

  2. Due to oversights, earlier 'range' properties are still preferred,
     as well as earlier 'default' properties on choices.

     In addition to being inconsistent, this makes it impossible to
     override 'range' properties and choice 'default' properties if the
     base definition of the symbol/choice already has 'range'/'default'
     properties.

     I've seen errors caused by the inconsistency, and I suspect there
     are more.

  3. A fork of Kconfiglib that adds the patch needs to be maintained.

Get rid of the patch and go back to standard Kconfig behavior, as
follows:

  1. Include the Kconfig.defconfig files first instead of last in
     Kconfig.zephyr.

  2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
     last in arch/Kconfig.

  3. Include arch/<arch>/soc/*/Kconfig first instead of last in
     arch/<arch>/Kconfig.

  4. Swap a few other 'source's to preserve behavior for some scattered
     symbols with multiple definitions.

     Swap 'source's in some no-op cases too, where it might match the
     intent.

  5. Reverse the defaults on symbol definitions that have more than one
     default.

     Skip defaults that are mutually exclusive, e.g. where each default
     has an 'if <some board>' condition. They are already safe.

  6. Remove the prefer-later-defaults patch from Kconfiglib.

Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions

As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).

This commit includes some default-related cleanups as well:

  - Simplify some symbol definitions, e.g. where a default has 'if FOO'
    when the symbol already has 'depends on FOO'.

  - Remove some redundant 'default ""' for string symbols. This is the
    implicit default.

Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).

Piggyback some fixes for style nits too, e.g. unindented help texts.

Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-08-10 12:38:28 -07:00
Ulf Magnusson
1073882998 subsys: kconfig: Remove 'default n' properties and clean up a bit
Bool symbols implicitly default to 'n'.

A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though.

Remove some 'default ""' properties on string symbols too.

Also make definitions more consistent by converting some

  config FOO
  	<type>
  	prompt "foo"

definitions to a shorter form:

  config FOO
  	<type> "foo"

This shorthand works for int/hex/string symbols too, not just for bool
symbols.

Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-12 23:13:22 -04:00
Michael Scott
198b358638 net: lwm2m: simplify registration client
When designing the registration client for LwM2M, I understood
that the LwM2M Technical Specification allows for a multi-server
connection setup where the client makes several connections
to various LwM2M servers and allows each of them to manage
various aspects of the LwM2M client based on Access Controls.

However, the way I implemented it was not well thought out and
as we look forward to adding Bootstrap support, it needs a
do over.

Let's remove all of the code dedicated to handling multiple LwM2M
client connections.  This will simplify and reduce the code size
of the registration client considerably.

Later, once Bootstrap support has been added, we can implement
multi-server connections in a cleaner manner.

Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-05-18 09:28:28 +03:00
Michael Scott
a58781f504 net: lwm2m: add LWM2M_FIRMWARE_UPDATE_PULL_LOCAL_PORT setting
This allows a user to customize the port used for downloading
firmware via the pull method of the LwM2M client.  It's default
value of 0 will select a random port during initialization.

NOTE: If set, this value should not be the same port as the
LWM2M_LOCAL_PORT setting.

Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-05-18 09:28:28 +03:00
Michael Scott
21fdf536ba net: lwm2m: default LWM2M_LOCAL_PORT to 0 (random)
Due to a bug where LWM2M_LOCAL_PORT was not being honored, all
outgoing traffic from the LwM2M client was coming from a random
port determined during initialization.

Now that this bug bas been fixed, let's default the client to the
behavior that most users are expecting, and let new users customize
the outgoing port if needed (which should be rarely).

Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-05-18 09:28:28 +03:00
Michael Scott
fc8d093592 net: lwm2m: lower default maximum observes from 20 to 10
In an effort to reduce the footprint of the LwM2M client, let's
lower the default # of observes handled by the client from 20 to
10.

This saves ~640 bytes of SRAM.

Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-05-11 16:38:49 +03:00
Michael Scott
b6ca731bdc net: lwm2m: remove unused CONFIG_LWM2M_BOOTSTRAP_PORT config
In the future, when bootstrap support is added, this config won't
be used.  Let's remove it.

Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-05-04 09:45:35 +03:00
Michael Scott
83978e6264 net: lwm2m: add max device power source config option
The code in the LwM2M "Device" object was checking for this max
power source config value, except that it was never added as a
Kconfig option.  Let's go ahead and add it so apps can set the
value appropriately.

Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2018-02-08 09:49:01 +02:00
Robert Chou
09fcd83b98 net: lwm2m: add write-attribute WRITE support
Implement write-attribute on obj/obj_inst/res according to LwM2M spec
20170704-A, sec 5.1.2. Support pmin/pmax/st/gt/lt parameters on WRITE
operation.

The basic idea is to add sys_slist_t to obj/obj_inst/res structure.
And attach struct lwm2m_attr to the list when attributes are written
from server side (implement lwm2m_write_attr_handler accordingly)

Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
2018-01-12 20:57:34 -05:00
Michael Scott
2a7546fb5a net: lwm2m: add support for coap2coap proxy
Currently, LwM2M firmware download only supports coap2http proxy.
Let's add support for coap2coap proxy as well.

This was tested running Californium demo app cf-proxy on the host
machine with the following setting changed in Californum.properties:
MAX_RESOURCE_BODY_SIZE=524288

Add the following to the samples/net/lwm2m_client/prj.conf:
CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_SUPPORT=y
CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_ADDR="coap://[2001:db8::2]:5682"

Build the sample for qemu_x86 as you would normally, but now
you can use a real world coap address to pull firmware using the 5/0/1
resource.  The host machine running cf-proxy will pull the remote
resource and then deliver it to the running qemu sample.

Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
2017-12-15 16:47:30 -05:00
Michael Scott
7aa06558e0 net: lwm2m: remove auto select of COAP_EXTENDED_OPTIONS_LEN config
When moving to the new CoAP API, I thought we would need to parse
incoming option values longer than 12 characters.

This hasn't proven to be true, so let's remove the auto-selection of
this config.  If needed user can set this option later.

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-27 11:33:06 -04:00
Michael Scott
f8ba4585c5 net: lwm2m: register the RD client with the engine periodic service
Remove the RD client's stack in favor of using the engine's periodic
service to trigger RD client events.  This saves 5K RAM of stack based
memory.

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-26 09:29:42 +03:00
Michael Scott
25ff4f0e6a net: lwm2m: reduce LwM2M footprint via lower defaults in Kconfig
Let's use conservative defaults for the LwM2M library to enable
hardware with constrained resources.  Users can increase where
necessary.

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-26 09:25:56 +03:00
Michael Scott
fb734acc73 net: lwm2m: move to using the new multi-packet CoAP API
This patch moves from the ZoAP API in subsys/net/lib/zoap to
the CoAP API in subsys/net/lib/coap which handles multiple
fragments for sending / receiving data.

NOTE: This patch moves the LwM2M library over to the CoAP APIs
but there will be a follow-up patch which re-writes the content
formatter reader / writers to use net_pkt APIs for parsing
across multiple net buffers. The current implementation assumes
all of the data will land in 1 buffer.

Samples using the library still need a fairly large NET_BUF_DATA_SIZE
setting. (Example: CONFIG_NET_BUF_DATA_SIZE=384)

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-25 13:39:55 +03:00
Robert Chou
19559ee41b net: lwm2m: increase rd client stack size when NET_LOG_GLOBAL=y
The stack of rd client is exhausted while running lwm2m client w/ IPv6
and network log global enabled. Increase the stack size to 1536 when
NET_LOG_GLOBAL is enabled.

Detail described at #4424

Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
2017-10-19 05:36:02 -04:00
Ricardo Salveti
58d758bf90 net: lwm2m: firmware: add support for firmware pull over CoAP proxy
CoAP allows a proxy to be used when transferring data (CoAP-CoAP and/or
CoAP-HTTP) by creating request on a specific URI path and by using the
Proxy URI CoAP option. Create specific Kconfig options for the proxy
server address and port, until a parser gets implemented.

Code tested with Californium acting as CoAP proxy.

Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
[michael.scott@linaro.org: rebased on net_app + lwm2m_message
refactoring + firmware update changes.]
Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-17 19:40:04 -04:00
Robert Chou
b93eb8dee1 net: lwm2m: add firmware push support
1. Add handling block1 option in handle_request(). The basic idea is
   to declare structure block_context at compiled time and use "token"
   as a key to pick up the on-going block cotext. It should be able to
   support multiple blockwise transfer concurrently
2. Use write callback implemented in lwm2m_obj_firmware to deal w/ the
   update state transition and than call the callback registered by the
   application
3. move default_block_size to lwm2m_engine.c to share between
   lwm2m_engine and lwm2m_obj_firmware_pull

Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
[michael.scott@linaro.org: rebased on LwM2M net_app changes.]
Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-17 19:40:04 -04:00
Robert Chou
d9f5fe7455 net: lwm2m: add state machine for firmware pull update
1. Parse firmware pull URI
2. Add lwm2m_firmware_get/set_update_cb() for application to register
   callback. This is because we want to check the update_state before
   we pass to the application
3. Add lwm2m_firmware_get/set_update_result() and
   lwm2m_firmware_get/set_update_stat() to manage the state transition
   as well as the sanity check

Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
[michael.scott@linaro.org: rebased on net_app framework and
lwm2m_message refactoring.]
Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-17 19:40:04 -04:00
Michael Scott
ba20b3a884 net: lib: lwm2m: use stand-alone URL parser
With future patches we will need to parse URLs in the registration
client and firmware object.  Enable it by default when LWM2M is
enabled.

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-17 19:40:04 -04:00
Michael Scott
b7060cf611 net: lwm2m: set range for client lifetime config
Due to timeout checking the minimum lifetime must be 15 seconds,
and we're storing the lifetime as an unsigned short so set the
maximum to 65535.

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-05 10:48:57 +03:00
Michael Scott
897dbffe7c net: lwm2m: refactor engine to use lwm2m_message structure
Sending an lwm2m message is too difficult.  It requires pending / reply
and other structures to be configured and set by various portions of
the library.  There is also no way to know if a pending message ever
encounters a timeout.

Let's fix this by simplifying the internal LwM2M engine APIs for
handling lwm2m messages:

1. A user calls lwm2m_get_message(lwm2m_ctx) which returns the first
   available lwm2m message from an array of messages
   (total # of messages is set via CONFIG_LWM2M_ENGINE_MAX_MESSAGES).
2. Next the user sets all of the fields in the message that are
   required (type, code message id, token, etc)
3. Then the user calls lwm2m_init_message(msg).  This initializes the
   underlying zoap_packet, pending and reply structures.
4. Once initialized, the user creates their payload in msg->zpkt.
5. When the user is ready to send, the call lwm2m_send_message(msg).
6. And if for some reason an error occurs at any point, they can free
   up the entire set of structures with: lwm2m_release_message(msg).

Included in the refactoring is a timeout_cb field which can be set in
the LwM2M messages.  If a pending structure ever expires the engine
will call the timeout_cb passing in the msg structure before it's
automatically released.

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-10-05 10:48:57 +03:00
Michael Scott
cff468217b net: lwm2m: select NET_APP_CLIENT automatically
No need for samples to make sure they have this configured in their
.conf files.

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-09-12 20:37:48 +03:00
David B. Kinder
81f7c82625 doc: fix misspellings and missing EOF newlines
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2017-08-16 17:38:41 -05:00
Ricardo Salveti
61961cf737 net: lwm2m: firmware: add Kconfig option for CoAP block size
CoAP block size might be adjusted for a faster firmware download
process.

Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
2017-08-10 12:42:40 +03:00
Michael Scott
aef5ee4582 net: lwm2m: add IPSO support w/ temperature sensor object
IPSO Smart Objects are a set of template objects based on the LwM2M
object framework which are designed to represent standard hardware
such as temperature and humidity sensors or light controls.

Let's add a place for these objects to live as well as an initial
temperature sensor object.

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-08-09 10:55:53 +03:00
Michael Scott
c46c206f8c net: lwm2m: initial library support for LWM2M
Origin: SICS-IoT / Contiki OS
URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls
commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a
Purpose: Introduction of LwM2M client library.
Maintained-by: Zephyr

Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension
of the Constrained Application Protocol (CoAP) which uses UDP
transmission packets.

This library was based on source worked on by Joakim Eriksson,
Niclas Finne and Joel Hoglund which was adopted by Contiki and then
later revamped to work as a stand-alone library.

A VERY high level summary of the changes made:
- [ALL] sources were re-formatted to Zephyr coding standards
- [engine] The engine portion was re-written due to the heavy reliance
  on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as
  well as other Zephyr specific needs.
- [engine] All LWM2M/IPSO object data is now abstracted into resource
  data which stores information like the data type, length, callbacks
  to help with read/write.  The engine modifies this data directly (or
  makes callbacks) instead of all of the logic for this living in each
  object's code. (This wasn't scaling well as I was implementing
  changes).
- [engine] Related to the above change, I also added a generic set of
  getter/setter functions that user applications can call to change
  the object data instead of having to add getter/setting methods in
  each object.
- [engine] The original sources shared the engine's context structure
  quite extensively causing a problem with portability. I broke up the
  context into it's individual parts: LWM2M path data, input data and
  output data and pass only the needed data into each set of APIs.
- [content format read/writer] sources were re-organized into single
  .c/h files per content formatter.
- [content format read/writer] sources were re-written where necessary
  to remove the sharing of the lwm2m engine's context and instead only
  requires the path and input or output data specific to it's
  function.
- [LwM2M objects] re-written using the new engine's abstractions

Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-08-09 10:55:53 +03:00