Date   

Re: RFC: TCP receive/send window handling in Zephyr IP stack

Jukka Rissanen
 

Hi Paul,

On Fri, 2017-04-28 at 21:28 +0300, Paul Sokolovsky wrote:
Hello,

Some time ago I "noticed" that Zephyr IP stack doesn't do any TCP
receive window handling, instead using static value for each packet
it
sends. Today I confirmed the expectation that it would be problematic
for BSD Sockets implementation I'm working on. The whole story is
available as https://jira.zephyrproject.org/browse/ZEP-1999 .

So, as the issue is confirmed, I would like to proceed with resolving
it, and this RFC is about ways to do it.
Thanks for pushing this, we definitely have an issue with the rcv wnd
handling.


lwIP offers a very simple and easy to understand model of that: IP
stack only decreases the available receive window, never increases
it,
it's a task of application code. When an application really processes
received data (vs just buffering it), it calls a special function
(called tcp_recved()) to advance the window.

I don't think there can be more general and flexible solution than
that, so I propose that we add a similar function to explicitly
advance
the window, and add the code to track decrease of the current window
with each packet received.

However, it means that each and every existing receive callback will
need to be patched to call that function, and if that's not done, the
communication will cease to work silently. So, we may want (to
consider) a way to "automate" it, or at least be a compile-time
breaking
change, instead of silent runtime failure.

One way to do that would be to change recv callback signature from:

typedef void (*net_context_recv_cb_t)(struct net_context *context,
                                      struct net_pkt *pkt,
                                      int status,
                                      void *user_data);

to one returning u32_t, the size by which to advance the receive
window. For each existing recv callback, that would be
net_pkt_appdatalen(pkt), so we can try to optimize that one step
further by defining some constant and allowing to return it:

return NET_ADVANCE_WHOLE_PKT;
I like this better than an application manually calling a special
function to do the trick like what was found in the gerrit patch.

Is it likely that the application would not move the window for full
packet? I mean what would happen if we always move the window the
received data amount automatically by the core stack after we return
from recv cb? The net_buf's should be released anyway by the
application asap, otherwise we have possible memory leak.



Note that I would be in favor of there's-one-way-to-do-it solution of
explicit function call to advance window. However, as a compromise,
having a return value from recv callback also makes sense, and I
mention "special constant" choice just for a perspective, I'd be -0.5
on it.
Thanks,
Paul


Cheers,
Jukka


RFC: HTTP client API for review

Jukka Rissanen
 

Hi all,

I just submitted a simple HTTP client API for review at https://github.
com/zephyrproject-rtos/zephyr/pull/50

The API is very simple providing following functions:

* http_client_send_req(): This is the base function that both the GET
and POST helper functions will call. The function supports both
push/pull (async/sync) model of working. If the callback is given, then
the request is done in asynchronous way.

* http_client_send_get_req(): Helper to create a GET request
* http_client_send_post_req(): Helper to create a POST request
* http_client_init(): Initialize HTTP context needed by above
functions.
* http_client_release(): Release the HTTP context.

This API will move most of the code from http-client app into this new
library and make the new http-client sample application very simple.


The pull-request also has support for new API for the network sample
applications. So instead of each net sample application doing various
setup things itself, an API is provided which initializes the network
stack and makes the sample network application startup much simpler.
The plan is to convert other network sample apps to use this new API
after the commit has been merged.


For testing purposes, the net-tools project now contains a simple http
server that can be used in Qemu testing. See this pull-request for
details https://github.com/zephyrproject-rtos/net-tools/pull/1


Below are the function documentation from include file:

/**
 * @brief Send a HTTP request to peer.
 *
 * @param http_ctx HTTP context.
 * @param req HTTP request to perform.
 * @param cb Callback to call when the response has been received from
peer.
 * @param result_buf Caller supplied buffer where the HTTP request will
be
 * stored
 * @param result_buf_len Length of the caller suppied buffer.
 * @param user_data A valid pointer on some user data or NULL
 * @param timeout Amount of time to wait for a reply. If the timeout is
0,
 * then we return immediately and the callback (if set) will be called
later.
 *
 * @return Return 0 if ok, and <0 if error.
 */
int http_client_send_req(struct http_client_ctx *http_ctx,
 struct http_client_request *req,
 http_request_cb_t cb,
 u8_t *result_buf,
 size_t result_buf_len,
 void *user_data,
 s32_t timeout);

/**
 * @brief Send a HTTP GET request to peer.
 *
 * @param http_ctx HTTP context.
 * @param url URL to use.
 * @param host Host field in HTTP header. If set to NULL, then server
 * name is used.
 * @param extra_header_fields Any extra header fields that caller wants
 * to add. This can be set to NULL.
 * @param cb Callback to call when the response has been received from
peer.
 * @param result_buf Caller supplied buffer where the HTTP request will
be
 * stored
 * @param result_buf_len Length of the caller suppied buffer.
 * @param user_data A valid pointer on some user data or NULL
 * @param timeout Amount of time to wait for a reply. If the timeout is
0,
 * then we return immediately and the callback (if set) will be called
later.
 *
 * @return Return 0 if ok, and <0 if error.
 */
static inline int http_client_send_get_req(struct http_client_ctx
*http_ctx,
   const char *url,
   const char *host,
   const char
*extra_header_fields,
   http_request_cb_t cb,
   u8_t *result_buf,
   size_t result_buf_len,
   void *user_data,
   s32_t timeout)
{
struct http_client_request req = {
.method = "GET ",
.url = url,
.host = host,
.protocol = " " HTTP_PROTOCOL
HTTP_CRLF,
.header_fields = extra_header_fields,
};

http_ctx->req.method = HTTP_GET;

return http_client_send_req(http_ctx, &req, cb, result_buf,
    result_buf_len, user_data,
timeout);
}

/**
 * @brief Send a HTTP POST request to peer.
 *
 * @param http_ctx HTTP context.
 * @param url URL to use.
 * @param host Host field in HTTP header. If set to NULL, then server
 * name is used.
 * @param extra_header_fields Any extra header fields that caller wants
 * to add. This can be set to NULL.
 * @param content_type Content type of the data.
 * @param payload Payload data.
 * @param cb Callback to call when the response has been received from
peer.
 * @param result_buf Caller supplied buffer where the HTTP request will
be
 * stored
 * @param result_buf_len Length of the caller suppied buffer.
 * @param user_data A valid pointer on some user data or NULL
 * @param timeout Amount of time to wait for a reply. If the timeout is
0,
 * then we return immediately and the callback (if set) will be called
later.
 *
 * @return Return 0 if ok, and <0 if error.
 */
static inline int http_client_send_post_req(struct http_client_ctx
*http_ctx,
    const char *url,
    const char *host,
    const char
*extra_header_fields,
    const char *content_type,
    const char *payload,
    http_request_cb_t cb,
    u8_t *result_buf,
    size_t result_buf_len,
    void *user_data,
    s32_t timeout)
{
struct http_client_request req = {
.method = "POST ",
.url = url,
.host = host,
.protocol = " " HTTP_PROTOCOL
HTTP_CRLF,
.header_fields = extra_header_fields,
.content_type_value = content_type,
.payload = payload,
};

http_ctx->req.method = HTTP_POST;

return http_client_send_req(http_ctx, &req, cb, result_buf,
    result_buf_len, user_data,
timeout);
}

/**
 * @brief Initialize user supplied HTTP context.
 *
 * @detail Caller can set the various fields in http_ctx after this
call
 * if needed.
 *
 * @param http_ctx HTTP context.
 * @param server HTTP server address or host name. If host name is
given,
 * then DNS resolver support (CONFIG_DNS_RESOLVER) must be enabled. If
caller
 * sets the server parameter as NULL, then it no attempt is done to
figure out
 * the remote address and caller must set the address in
http_ctx.tcp.remote
 * itself.
 * @param server_port HTTP server TCP port.
 *
 * @return Return 0 if ok, <0 if error.
 */
int http_client_init(struct http_client_ctx *http_ctx,
     const char *server, u16_t server_port);

/**
 * @brief Release all the resources allocated for HTTP context.
 *
 * @param http_ctx HTTP context.
 */
void http_client_release(struct http_client_ctx *http_ctx);


Please comment directly in github pull request.


Cheers,
Jukka


Re: Zephyr is moving to Github on May 1st

Marti Bolivar <marti.bolivar@...>
 

Wonderful; glad to hear it!

Marti

On 1 May 2017 at 10:56, Anas Nashif <nashif@...> wrote:
Marti,

Yes, those will be enabled on github as well, emails should start flowing in during this week.

Anas

On Mon, May 1, 2017 at 10:08 AM, Marti Bolivar <marti.bolivar@...> wrote:
Hi Anas,

Thanks for the information. I read through the emails on this and the Contribution Guide on the Zephyr GitHub wiki, which was clear.

One thing I don't see is whether the daily Gerrit digest emails will be replaced with a GitHub-based equivalent. Are there plans for that, or should we be using the repository "watch" feature instead?

IMO, the daily digests are an improvement (less email, easier to drill down on things that are interesting) over repository watching.

Thanks,
Marti



On 27 April 2017 at 19:37, Nashif, Anas <anas.nashif@...> wrote:

Hi,

First, sorry for the short notice.

 

Some of you might have heard about this already, it was mentioned in discussions and events. Most recently it was proposed officially to the board and was approved.

 

The Zephyr project launched last year with Gerrit as a code review system and it was meant to be used for this purpose until we have critical mass and a larger community. Over the last year we had a lot of feedback regarding the choice of Gerrit for the Zephyr project, most of which was negative feedback, however, I have talked to many developers and contributors who were actually happy with Gerrit, however in the 1st Zephyr mini-summit held last year in Austin we decided unanimously to move to github.com.

 

Our main goal is to have most of services we use for the project  in one place and have the best integration possible to enhance the development experience.

 

=== What does this mean for you as a Zephyr project contributor? ===

 

Starting next week, all code submissions have to be done using Pull Request on the Zephyr project github page:

 

https://github.com/zephyrproject-rtos/zephyr

 

The latest tree and the latest releases (https://github.com/zephyrproject-rtos/zephyr/releases )

will be available from Github directly.

 

Detailed documentation on how to submit changes will appear in the top-level README.md file which should also appear in the repository web page on github. For those not familiar with github, please take a look at the Pull Request method for submitting code changes:

 

https://guides.github.com/introduction/flow/

 

 

=== What else is moving? ===

 

Beside the hosting of the GIT repo and the review process using pull requests, the following will be moved to github:

 

-          Releases: https://github.com/zephyrproject-rtos/zephyr/releases

-          Wiki: We will move content from wiki.zephyrproject.org to three possible place:

o    the built-in wiki on github,

o   in some cases to the source tree in RST format

o   some content will move to the website

 

=== What about Jira? ===

 

At this moment we will continue using Jira as is, we are discussing and exploring usage of github issues, but this is still being evaluated.

 

 

=== What happens to my pending changes in gerrit? ===

 

Gerrit will be switched to operate in offline mode and all the existing changes will be available for processing and transition through May. However, we encourage you to resubmit your changes to Github and abandon changes on github. We already gone through the existing changes in github and did some initial cleanup.

 

 

Additional information and the new process for submitting changes will be documented on the github page and will be available already tomorrow. CI will also be available through github with additional details.

 

Your comments are welcome.

 

Anas

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel




Re: Zephyr is moving to Github on May 1st

Anas Nashif
 

Marti,

Yes, those will be enabled on github as well, emails should start flowing in during this week.

Anas

On Mon, May 1, 2017 at 10:08 AM, Marti Bolivar <marti.bolivar@...> wrote:
Hi Anas,

Thanks for the information. I read through the emails on this and the Contribution Guide on the Zephyr GitHub wiki, which was clear.

One thing I don't see is whether the daily Gerrit digest emails will be replaced with a GitHub-based equivalent. Are there plans for that, or should we be using the repository "watch" feature instead?

IMO, the daily digests are an improvement (less email, easier to drill down on things that are interesting) over repository watching.

Thanks,
Marti



On 27 April 2017 at 19:37, Nashif, Anas <anas.nashif@...> wrote:

Hi,

First, sorry for the short notice.

 

Some of you might have heard about this already, it was mentioned in discussions and events. Most recently it was proposed officially to the board and was approved.

 

The Zephyr project launched last year with Gerrit as a code review system and it was meant to be used for this purpose until we have critical mass and a larger community. Over the last year we had a lot of feedback regarding the choice of Gerrit for the Zephyr project, most of which was negative feedback, however, I have talked to many developers and contributors who were actually happy with Gerrit, however in the 1st Zephyr mini-summit held last year in Austin we decided unanimously to move to github.com.

 

Our main goal is to have most of services we use for the project  in one place and have the best integration possible to enhance the development experience.

 

=== What does this mean for you as a Zephyr project contributor? ===

 

Starting next week, all code submissions have to be done using Pull Request on the Zephyr project github page:

 

https://github.com/zephyrproject-rtos/zephyr

 

The latest tree and the latest releases (https://github.com/zephyrproject-rtos/zephyr/releases )

will be available from Github directly.

 

Detailed documentation on how to submit changes will appear in the top-level README.md file which should also appear in the repository web page on github. For those not familiar with github, please take a look at the Pull Request method for submitting code changes:

 

https://guides.github.com/introduction/flow/

 

 

=== What else is moving? ===

 

Beside the hosting of the GIT repo and the review process using pull requests, the following will be moved to github:

 

-          Releases: https://github.com/zephyrproject-rtos/zephyr/releases

-          Wiki: We will move content from wiki.zephyrproject.org to three possible place:

o    the built-in wiki on github,

o   in some cases to the source tree in RST format

o   some content will move to the website

 

=== What about Jira? ===

 

At this moment we will continue using Jira as is, we are discussing and exploring usage of github issues, but this is still being evaluated.

 

 

=== What happens to my pending changes in gerrit? ===

 

Gerrit will be switched to operate in offline mode and all the existing changes will be available for processing and transition through May. However, we encourage you to resubmit your changes to Github and abandon changes on github. We already gone through the existing changes in github and did some initial cleanup.

 

 

Additional information and the new process for submitting changes will be documented on the github page and will be available already tomorrow. CI will also be available through github with additional details.

 

Your comments are welcome.

 

Anas

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: Zephyr is moving to Github on May 1st

Marti Bolivar <marti.bolivar@...>
 

Hi Anas,

Thanks for the information. I read through the emails on this and the Contribution Guide on the Zephyr GitHub wiki, which was clear.

One thing I don't see is whether the daily Gerrit digest emails will be replaced with a GitHub-based equivalent. Are there plans for that, or should we be using the repository "watch" feature instead?

IMO, the daily digests are an improvement (less email, easier to drill down on things that are interesting) over repository watching.

Thanks,
Marti



On 27 April 2017 at 19:37, Nashif, Anas <anas.nashif@...> wrote:

Hi,

First, sorry for the short notice.

 

Some of you might have heard about this already, it was mentioned in discussions and events. Most recently it was proposed officially to the board and was approved.

 

The Zephyr project launched last year with Gerrit as a code review system and it was meant to be used for this purpose until we have critical mass and a larger community. Over the last year we had a lot of feedback regarding the choice of Gerrit for the Zephyr project, most of which was negative feedback, however, I have talked to many developers and contributors who were actually happy with Gerrit, however in the 1st Zephyr mini-summit held last year in Austin we decided unanimously to move to github.com.

 

Our main goal is to have most of services we use for the project  in one place and have the best integration possible to enhance the development experience.

 

=== What does this mean for you as a Zephyr project contributor? ===

 

Starting next week, all code submissions have to be done using Pull Request on the Zephyr project github page:

 

https://github.com/zephyrproject-rtos/zephyr

 

The latest tree and the latest releases (https://github.com/zephyrproject-rtos/zephyr/releases )

will be available from Github directly.

 

Detailed documentation on how to submit changes will appear in the top-level README.md file which should also appear in the repository web page on github. For those not familiar with github, please take a look at the Pull Request method for submitting code changes:

 

https://guides.github.com/introduction/flow/

 

 

=== What else is moving? ===

 

Beside the hosting of the GIT repo and the review process using pull requests, the following will be moved to github:

 

-          Releases: https://github.com/zephyrproject-rtos/zephyr/releases

-          Wiki: We will move content from wiki.zephyrproject.org to three possible place:

o    the built-in wiki on github,

o   in some cases to the source tree in RST format

o   some content will move to the website

 

=== What about Jira? ===

 

At this moment we will continue using Jira as is, we are discussing and exploring usage of github issues, but this is still being evaluated.

 

 

=== What happens to my pending changes in gerrit? ===

 

Gerrit will be switched to operate in offline mode and all the existing changes will be available for processing and transition through May. However, we encourage you to resubmit your changes to Github and abandon changes on github. We already gone through the existing changes in github and did some initial cleanup.

 

 

Additional information and the new process for submitting changes will be documented on the github page and will be available already tomorrow. CI will also be available through github with additional details.

 

Your comments are welcome.

 

Anas

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: Migration to Github - Status update

Paul Sokolovsky
 

Hello Anas,

On Sat, 29 Apr 2017 03:20:58 +0000
"Nashif, Anas" <anas.nashif@intel.com> wrote:

Hi,
We are in the process of enabling services on github and configuring
the various projects. To allow a smooth transition and to have Github
ready for development on May 1st globally, Gerrit was put in
read-only mode, meaning that no further changes will be accepted on
Gerrit, starting Friday evening.

If you are planning to submit anything before May, this will need to
happen in github. The following initial how-to has been drafted which
will help you with creating pull requests:

https://github.com/zephyrproject-rtos/zephyr/wiki/Contribution-Guide
I hope you guys are aware of CONTRIBUTING.md:
https://github.com/blog/1184-contributing-guidelines , so hope the
content will be moved there to give people a chance to ignore^W read
it during the submission process ;-).


Btw, I remembered about some unpleasant issue with Github pull
requests: it seems that merging via Github UI may overwrite the
original author email with whatever is set to Github's primary user
email. More specifically, I noticed that my JerryScript patches, which
were submitted from @linaro.org email, appear in the repository as
authored from my personal email.

I have suspicion that the issue either applies to "squash" submit mode,
or appeared after it it was introduced (which was relatively recently).
Well, it seems that I didn't actually proceed to investigate it
further :-(. But I definitely would like to have the right email with
Zephyr. And Github only offers 2 merge modes: 1) squash all PullReq
commits to one, perform fast-forward merge; 2) merge with explicit
non-fast-forward merge (git --no-ff), i.e. even if a patch could be
merged as fast-forward, create a merge commit.

I hope we are going to enjoy one of the benefits of Github - ability to
submit PullReq with multiple commits (and merge it like that). Then, as
can be seen, Github doesn't offer a way to merge this cleanly at all.
So, how everyone works that around is by having a special helper
script, which fetches PullReq, rebases it, and --ff-only merges it.
Hope you guys are ready to use such script.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Migration to Github - Status update

Nashif, Anas
 

Hi,

We are in the process of enabling services on github and configuring the various projects. To allow a smooth transition and to have Github ready for development on May 1st globally, Gerrit was put in read-only mode, meaning that no further changes will be accepted on Gerrit, starting Friday evening.

 

If you are planning to submit anything before May, this will need to happen in github. The following initial how-to has been drafted which will help you with creating pull requests:

 

https://github.com/zephyrproject-rtos/zephyr/wiki/Contribution-Guide

 

 

As with gerrit, please submit to the correct branch, for example net, Bluetooth or arm branches available on github while you create a pull request.

 

Regards,

Anas


Re: RFC: TCP receive/send window handling in Zephyr IP stack

Paul Sokolovsky
 

On Fri, 28 Apr 2017 21:28:36 +0300
Paul Sokolovsky <Paul.Sokolovsky@linaro.org> wrote:

A simple WIP patch implementing the proposed function is posted as
https://gerrit.zephyrproject.org/r/#/c/13271/


Hello,

Some time ago I "noticed" that Zephyr IP stack doesn't do any TCP
receive window handling, instead using static value for each packet it
sends. Today I confirmed the expectation that it would be problematic
for BSD Sockets implementation I'm working on. The whole story is
available as https://jira.zephyrproject.org/browse/ZEP-1999 .

So, as the issue is confirmed, I would like to proceed with resolving
it, and this RFC is about ways to do it.

lwIP offers a very simple and easy to understand model of that: IP
stack only decreases the available receive window, never increases it,
it's a task of application code. When an application really processes
received data (vs just buffering it), it calls a special function
(called tcp_recved()) to advance the window.

I don't think there can be more general and flexible solution than
that, so I propose that we add a similar function to explicitly
advance the window, and add the code to track decrease of the current
window with each packet received.

However, it means that each and every existing receive callback will
need to be patched to call that function, and if that's not done, the
communication will cease to work silently. So, we may want (to
consider) a way to "automate" it, or at least be a compile-time
breaking change, instead of silent runtime failure.

One way to do that would be to change recv callback signature from:

typedef void (*net_context_recv_cb_t)(struct net_context *context,
struct net_pkt *pkt,
int status,
void *user_data);

to one returning u32_t, the size by which to advance the receive
window. For each existing recv callback, that would be
net_pkt_appdatalen(pkt), so we can try to optimize that one step
further by defining some constant and allowing to return it:

return NET_ADVANCE_WHOLE_PKT;


Note that I would be in favor of there's-one-way-to-do-it solution of
explicit function call to advance window. However, as a compromise,
having a return value from recv callback also makes sense, and I
mention "special constant" choice just for a perspective, I'd be -0.5
on it.

I'd appreciate consideration of the problem and proposed ways to
resolve it, or alternative solutions.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


RFC: TCP receive/send window handling in Zephyr IP stack

Paul Sokolovsky
 

Hello,

Some time ago I "noticed" that Zephyr IP stack doesn't do any TCP
receive window handling, instead using static value for each packet it
sends. Today I confirmed the expectation that it would be problematic
for BSD Sockets implementation I'm working on. The whole story is
available as https://jira.zephyrproject.org/browse/ZEP-1999 .

So, as the issue is confirmed, I would like to proceed with resolving
it, and this RFC is about ways to do it.

lwIP offers a very simple and easy to understand model of that: IP
stack only decreases the available receive window, never increases it,
it's a task of application code. When an application really processes
received data (vs just buffering it), it calls a special function
(called tcp_recved()) to advance the window.

I don't think there can be more general and flexible solution than
that, so I propose that we add a similar function to explicitly advance
the window, and add the code to track decrease of the current window
with each packet received.

However, it means that each and every existing receive callback will
need to be patched to call that function, and if that's not done, the
communication will cease to work silently. So, we may want (to
consider) a way to "automate" it, or at least be a compile-time breaking
change, instead of silent runtime failure.

One way to do that would be to change recv callback signature from:

typedef void (*net_context_recv_cb_t)(struct net_context *context,
struct net_pkt *pkt,
int status,
void *user_data);

to one returning u32_t, the size by which to advance the receive
window. For each existing recv callback, that would be
net_pkt_appdatalen(pkt), so we can try to optimize that one step
further by defining some constant and allowing to return it:

return NET_ADVANCE_WHOLE_PKT;


Note that I would be in favor of there's-one-way-to-do-it solution of
explicit function call to advance window. However, as a compromise,
having a return value from recv callback also makes sense, and I
mention "special constant" choice just for a perspective, I'd be -0.5
on it.

I'd appreciate consideration of the problem and proposed ways to
resolve it, or alternative solutions.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 7
[ZEP-2078] tests/kernel/stackprot/testcase.ini - failing for arc/a101 and arc/qc1000
https://jira.zephyrproject.org/browse/ZEP-2078

[ZEP-2079] tests/crypto/test_ccm_mode - failing for mintvaslley(quark_d2000)
https://jira.zephyrproject.org/browse/ZEP-2079

[ZEP-2077] [net][bt]Set wrong IID for neighbor
https://jira.zephyrproject.org/browse/ZEP-2077

[ZEP-2075] Arduino 101 filesystem fails test
https://jira.zephyrproject.org/browse/ZEP-2075

[ZEP-2082] filtering pattern in scripts/support/dfuutil.sh doesn't work for arduino_101
https://jira.zephyrproject.org/browse/ZEP-2082

[ZEP-2081] New Zephyr-defined types missing API documentation
https://jira.zephyrproject.org/browse/ZEP-2081

[ZEP-2083] Bluetooth data types missing API documentation
https://jira.zephyrproject.org/browse/ZEP-2083


UPDATED JIRA items within last 24 hours: 25
[ZEP-2068] Need Tasks to Be Tracked in QRC too
https://jira.zephyrproject.org/browse/ZEP-2068

[ZEP-834] Thread requirements in RFC1122
https://jira.zephyrproject.org/browse/ZEP-834

[ZEP-835] Thread requirements in RFC2460
https://jira.zephyrproject.org/browse/ZEP-835

[ZEP-836] Thread requirements in RFC4291
https://jira.zephyrproject.org/browse/ZEP-836

[ZEP-837] Thread requirements in RFC4443
https://jira.zephyrproject.org/browse/ZEP-837

[ZEP-838] Thread requirements in RFC4944
https://jira.zephyrproject.org/browse/ZEP-838

[ZEP-948] Revisit the timeslicing algorithm
https://jira.zephyrproject.org/browse/ZEP-948

[ZEP-2053] Update tinycrypt to v.0.2.6 in recent releases
https://jira.zephyrproject.org/browse/ZEP-2053

[ZEP-1946] Time to Next Event
https://jira.zephyrproject.org/browse/ZEP-1946

[ZEP-1818] Add tickless kernel support in cortex_m_systick timer
https://jira.zephyrproject.org/browse/ZEP-1818

[ZEP-1816] Add tickless kernel support in LOAPIC timer
https://jira.zephyrproject.org/browse/ZEP-1816

[ZEP-1817] Add tickless kernel support in ARCV2 timer
https://jira.zephyrproject.org/browse/ZEP-1817

[ZEP-1812] Add tickless kernel support in HPET timer
https://jira.zephyrproject.org/browse/ZEP-1812

[ZEP-1821] Update PM apps to use mili/micro seconds instead of ticks
https://jira.zephyrproject.org/browse/ZEP-1821

[ZEP-2069] samples:net:dhcpv4_client: runs failed on frdm k64f board
https://jira.zephyrproject.org/browse/ZEP-2069

[ZEP-2057] crash in tests/net/rpl on qemu_x86 causing intermittent sanitycheck failure
https://jira.zephyrproject.org/browse/ZEP-2057

[ZEP-1868] [IPv6 TAHI] Section 1: RFC 2460 - IPv6 Specification
https://jira.zephyrproject.org/browse/ZEP-1868

[ZEP-1874] [IPv6 TAHI] Section 3: RFC 4862 - IPv6 Stateless Address Autoconfiguration
https://jira.zephyrproject.org/browse/ZEP-1874

[ZEP-1875] [IPv6 TAHI] Section 2: RFC 4861 - Neighbor Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-1875

[ZEP-1869] [IPv6 TAHI]Section 4: RFC 1981 - Path MTU Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-1869

[ZEP-1870] [IPv6 TAHI]Section 5: RFC 4443 - ICMPv6
https://jira.zephyrproject.org/browse/ZEP-1870

[ZEP-2015] the http_client sample app runs failed on FRDM K64F board
https://jira.zephyrproject.org/browse/ZEP-2015

[ZEP-1939] DataReady triggers failed to stop on BMI160 when both Accel/Gyro is enabled
https://jira.zephyrproject.org/browse/ZEP-1939

[ZEP-2014] Defaul samples/subsys/shell/shell fails to build on QEMU RISCv32 / NIOS2
https://jira.zephyrproject.org/browse/ZEP-2014

[ZEP-2064] RFC: Making net_shell command handlers reusable
https://jira.zephyrproject.org/browse/ZEP-2064


CLOSED JIRA items within last 24 hours: 2
[ZEP-2011] (Done) Retrieve RPL node information through CoAP requests
https://jira.zephyrproject.org/browse/ZEP-2011

[ZEP-1984] (Fixed) net_nbuf_append(), net_nbuf_append_bytes() have data integrity problems
https://jira.zephyrproject.org/browse/ZEP-1984


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/13259 : tests:kernel: added tests for k_mem_pool_alloc from isr
- https://gerrit.zephyrproject.org/r/13266 : tests:kernel: added tests for stack overflow detection
- https://gerrit.zephyrproject.org/r/13262 : Bluetooth: controller: Refactor LL Master role to ll_master.c
- https://gerrit.zephyrproject.org/r/13264 : Bluetooth: controller: Cond. compile connection state HCI cmds
- https://gerrit.zephyrproject.org/r/13263 : Bluetooth: controller: Conditionally compile slave role HCI cmds
- https://gerrit.zephyrproject.org/r/13261 : Bluetooth: controller: Refactor LL Scan state to ll_scan.c file
- https://gerrit.zephyrproject.org/r/13258 : samples/crypto: Check error code everytime and improve logging
- https://gerrit.zephyrproject.org/r/13242 : boards/galileo: Enable ethernet in the default configuration
- https://gerrit.zephyrproject.org/r/13241 : drivers: eth_dw: Port to new IP stack
- https://gerrit.zephyrproject.org/r/13249 : doc: fix broken link in nordic-segger board doc
- https://gerrit.zephyrproject.org/r/13245 : arm: Support for new ARM boards (discovery STM32F4 and STM32F429)
- https://gerrit.zephyrproject.org/r/13246 : kconfig: Move debugging-related options from misc/ to subsys/debug/
- https://gerrit.zephyrproject.org/r/13243 : arm: soc: ti_lm3s6965: remove dead code
- https://gerrit.zephyrproject.org/r/13244 : arm: linker: remove unused linker sections
- https://gerrit.zephyrproject.org/r/13240 : boards: arduino_due: Updated the Arduino Due board config files.

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/13184 : board: Add support for board disco_l475_iot1
- https://gerrit.zephyrproject.org/r/13136 : net: context: add net_pkt_set_appdatalen before net_tcp_queue_data
- https://gerrit.zephyrproject.org/r/13215 : Bluetooth: controller: Scan Request Notifications
- https://gerrit.zephyrproject.org/r/13189 : DRAFT: Bluetooth: controller: LE Advertising Extensions PDU structs
- https://gerrit.zephyrproject.org/r/12571 : Bluetooth: controller: Add Kconfig options for states and roles
- https://gerrit.zephyrproject.org/r/13177 : xtensa port: Fixed crash on interrupt handlers when logger is enabled.
- https://gerrit.zephyrproject.org/r/10790 : Bluetooth: controller: Refactor LL Adv state to ll_adv.c file
- https://gerrit.zephyrproject.org/r/13187 : samples: sensor: hts221
- https://gerrit.zephyrproject.org/r/13229 : boards: disco_l475_iot: Configuration for HTS221 sample
- https://gerrit.zephyrproject.org/r/12995 : arm: Add support for TI's CC2650 SoC.
- https://gerrit.zephyrproject.org/r/12919 : tests: uart_basic_api: Don't assume we can drink from IRQ firehose.
- https://gerrit.zephyrproject.org/r/13038 : cc2650: Add UART driver.
- https://gerrit.zephyrproject.org/r/13228 : samples/crypto: Add mbedtls shim driver support
- https://gerrit.zephyrproject.org/r/13227 : drivers/crypto: Add mbedTLS shim crypto driver
- https://gerrit.zephyrproject.org/r/12286 : stm32lx: spi: add SPI driver for STM32Lx family
- https://gerrit.zephyrproject.org/r/12498 : samples: synch: Add Thread Stack Guards conf
- https://gerrit.zephyrproject.org/r/12433 : arm: soc: nxp k6x: Add Initial support for NXP MPU
- https://gerrit.zephyrproject.org/r/12794 : [WIP] Add buffered output support to console subsystem.
- https://gerrit.zephyrproject.org/r/13039 : cc2650: Add basic support for Device Tree.
- https://gerrit.zephyrproject.org/r/13035 : cc2650: Add GPIO driver.
- https://gerrit.zephyrproject.org/r/12494 : arm: core: mpu: Add arm core MPU interface
- https://gerrit.zephyrproject.org/r/13036 : cc2650: Add pinmux driver.
- https://gerrit.zephyrproject.org/r/12998 : samples: gpio: Add support for SensorTag board.
- https://gerrit.zephyrproject.org/r/13037 : cc2650: Add random driver.
- https://gerrit.zephyrproject.org/r/12996 : sensortag: Add TI's SensorTag board.
- https://gerrit.zephyrproject.org/r/12496 : arm: core: mpu: Add core MPU implementation
- https://gerrit.zephyrproject.org/r/12495 : arm: core: mpu: Add core support to ARM MPU
- https://gerrit.zephyrproject.org/r/12497 : arm: core: Integrate thread stack guard feature
- https://gerrit.zephyrproject.org/r/12499 : samples: Add mpu stack guard test

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/13265 : Merge net branch into master
- https://gerrit.zephyrproject.org/r/13260 : Bluetooth: controller: Rename ll_address_* to ll_addr_*
- https://gerrit.zephyrproject.org/r/13257 : net/mqtt: return error codes from net_context_send
- https://gerrit.zephyrproject.org/r/13256 : net/mqtt: cleanup TX function unref handling
- https://gerrit.zephyrproject.org/r/13255 : net/mqtt: use rlen to calculate # of QoS items in SUBACK packet
- https://gerrit.zephyrproject.org/r/13253 : net/mqtt: fix race condition in mqtt_init()
- https://gerrit.zephyrproject.org/r/13254 : net/mqtt: combine mqtt_parser for PUBLISHER and SUBSCRIBER
- https://gerrit.zephyrproject.org/r/13252 : bluetooth: host: fix compile break with CONFIG_ASSERT in gatt.c
- https://gerrit.zephyrproject.org/r/13251 : ci: add CI/CD integration and related scripts
- https://gerrit.zephyrproject.org/r/13247 : doc: tweak Sphinx linkcheck options
- https://gerrit.zephyrproject.org/r/13248 : doc: fix broken link in em_starterkit board doc
- https://gerrit.zephyrproject.org/r/13250 : doc: fix broken link in 1.7 release notes
- https://gerrit.zephyrproject.org/r/13108 : checkpatch: per coding style, we do not allow c++ style comments
- https://gerrit.zephyrproject.org/r/13203 : slist/dlist: container node can't be NULL in *_PEEK_NEXT_CONTAINER
- https://gerrit.zephyrproject.org/r/13179 : doc: net: Fix IP stack architecture data flow pictures
- https://gerrit.zephyrproject.org/r/13233 : net: shell: Make shell commands non-static to allow reuse.
- https://gerrit.zephyrproject.org/r/13235 : samples: net: dns_resolve: Clarify that DNS queries aren't immediate
- https://gerrit.zephyrproject.org/r/13230 : net: ipv6: Use correct API to remove router
- https://gerrit.zephyrproject.org/r/13232 : net: rpl: Fix invalid usage of router addition api
- https://gerrit.zephyrproject.org/r/13234 : net: samples: Use correct API to get net pkt length
- https://gerrit.zephyrproject.org/r/13231 : net: rpl: Fix router when it's timer expires
- https://gerrit.zephyrproject.org/r/13188 : build: build host-tools when prebuilts are enabled
- https://gerrit.zephyrproject.org/r/13211 : x86: define MMU data structures
- https://gerrit.zephyrproject.org/r/12622 : arm: Support for new ARM board FRDM-KL25Z
- https://gerrit.zephyrproject.org/r/13236 : Bluetooth: hci: Consistently use bt_hci_evt_*
- https://gerrit.zephyrproject.org/r/13239 : release: Prepare for 1.7.1
- https://gerrit.zephyrproject.org/r/12821 : Revert "serial: stm32: Give H/W a chance to set the TXE bit on transfer"


Some question about boot and flash Zephyr OS

eladyaakovi@campus.technion.ac.il <eladyaakovi@...>
 

- As I can see, I flashed Zephyr to Carbon 96 board, I don't fully understand the process, 

I mean, I see .bin and .elf files but i don't see boot.img file, how do i make a bootable file ? what are the required files to flash ? 

Is flashing is the same to all the boards? (as I wrote before 2 weeks, I will bring Zephyr to DragonBoard 410c and trying it on carbon 96)



- Can you please send me Zephyr architecture document? And some Zephyr document, I such as how to flash it to a new board, what are the required files to a new board ? 



 Is there any "boot.img" for zephyr?


- How to I join to IRC channel ? 


Thanks you a lot!


Arduino DUE with ESP6288

Kevin Stöckl <k_stoeckl@...>
 

Hello,

I have connected the Arduino DUE with the ESP6288 to get an internet connection. Now I want to send my data to thingspeak.com or thingsboard.io. How is this possible?


Re: mbedtls and memory allocator

Tomasz Bursztyka
 

Hi Sergio,

now as a reference how to enable you can take a look to

samples/net/mbedtls_dtlsclient

in the file dtls_client.c look for

#if defined(MBEDTLS_MEMORY_BUFFER_ALLOC_C)
#include "mbedtls/memory_buffer_alloc.h"
static unsigned char heap[20480];
#endif

There a heap is statically created and eventually you have to assign the heap with the function

#if defined(MBEDTLS_MEMORY_BUFFER_ALLOC_C)
mbedtls_memory_buffer_alloc_init(heap, sizeof(heap));
#endif


For that point on mbedtls will use its own memory allocator

Let me know if this helps
Indeed, that I could not guess it from mbedtls includes.

That helps a lot! :)

Thank you

Tomasz


Zephyr is moving to Github on May 1st

Nashif, Anas
 

Hi,

First, sorry for the short notice.

 

Some of you might have heard about this already, it was mentioned in discussions and events. Most recently it was proposed officially to the board and was approved.

 

The Zephyr project launched last year with Gerrit as a code review system and it was meant to be used for this purpose until we have critical mass and a larger community. Over the last year we had a lot of feedback regarding the choice of Gerrit for the Zephyr project, most of which was negative feedback, however, I have talked to many developers and contributors who were actually happy with Gerrit, however in the 1st Zephyr mini-summit held last year in Austin we decided unanimously to move to github.com.

 

Our main goal is to have most of services we use for the project  in one place and have the best integration possible to enhance the development experience.

 

=== What does this mean for you as a Zephyr project contributor? ===

 

Starting next week, all code submissions have to be done using Pull Request on the Zephyr project github page:

 

https://github.com/zephyrproject-rtos/zephyr

 

The latest tree and the latest releases (https://github.com/zephyrproject-rtos/zephyr/releases )

will be available from Github directly.

 

Detailed documentation on how to submit changes will appear in the top-level README.md file which should also appear in the repository web page on github. For those not familiar with github, please take a look at the Pull Request method for submitting code changes:

 

https://guides.github.com/introduction/flow/

 

 

=== What else is moving? ===

 

Beside the hosting of the GIT repo and the review process using pull requests, the following will be moved to github:

 

-          Releases: https://github.com/zephyrproject-rtos/zephyr/releases

-          Wiki: We will move content from wiki.zephyrproject.org to three possible place:

o    the built-in wiki on github,

o   in some cases to the source tree in RST format

o   some content will move to the website

 

=== What about Jira? ===

 

At this moment we will continue using Jira as is, we are discussing and exploring usage of github issues, but this is still being evaluated.

 

 

=== What happens to my pending changes in gerrit? ===

 

Gerrit will be switched to operate in offline mode and all the existing changes will be available for processing and transition through May. However, we encourage you to resubmit your changes to Github and abandon changes on github. We already gone through the existing changes in github and did some initial cleanup.

 

 

Additional information and the new process for submitting changes will be documented on the github page and will be available already tomorrow. CI will also be available through github with additional details.

 

Your comments are welcome.

 

Anas

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Re: mbedtls and memory allocator

Rodriguez, Sergio SF <sergio.sf.rodriguez@...>
 

Hi Tomasz

Mbedtls has his own allocator, version of calloc to enable it, you need the a configuration file that enables the compilation of that feature

Namely

#define MBEDTLS_PLATFORM_MEMORY
#define MBEDTLS_MEMORY_BUFFER_ALLOC_C
#define MBEDTLS_PLATFORM_NO_STD_FUNCTIONS

You can see an example in

ext/lib/crypto/mbedtls/configs/config-threadnet.h


if you need an specific configuration file this is where you will put it , and add to your prj.conf

CONFIG_MBEDTLS_CFG_FILE="config-file.h"

now as a reference how to enable you can take a look to

samples/net/mbedtls_dtlsclient

in the file dtls_client.c look for

#if defined(MBEDTLS_MEMORY_BUFFER_ALLOC_C)
#include "mbedtls/memory_buffer_alloc.h"
static unsigned char heap[20480];
#endif

There a heap is statically created and eventually you have to assign the heap with the function

#if defined(MBEDTLS_MEMORY_BUFFER_ALLOC_C)
mbedtls_memory_buffer_alloc_init(heap, sizeof(heap));
#endif


For that point on mbedtls will use its own memory allocator

Let me know if this helps
Sergio

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Tomasz Bursztyka
Sent: Thursday, April 27, 2017 3:56 AM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] mbedtls and memory allocator

Hi,

I sent a draft for a mbedtls shim crypto device driver, so it exposes CCM operations (for now) through Crypto API.

Patch is here:

https://gerrit.zephyrproject.org/r/#/c/13227/

While running the cryto sample on top of it, I get a mbedtls memory allocation error when calling mbedtls_ccm_setkey().

Looking quickly at mbdetls code, it seems to want to allocate some space for the chosen cipher (AES here) and obviously fails because there is no calloc in Zephyr, and instead mbedtls is built to return NULL from a default built-in memory allocator.

I used ext/lib/crypto/mbedtls/configs/config-ccm-psk-tls1_2.h
That one is being used in, for instance, samples/net/mbedtls_sslclient. And AES and CCM could be used there, I wonder how it is supposed to work if it has the same issue.

So, before I dive deeper into mbedtls myself:

How is mbedtls supposed to be configured to get AES CCM working without any dynamic memory allocator?

If by any chance someone has already worked with mbedtls, it will be of great help to give me hints.

Thanks,

Tomasz

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 4
[ZEP-2070] net pkt doesn't full unref after send a data form bluetooth's ipsp
https://jira.zephyrproject.org/browse/ZEP-2070

[ZEP-2074] cdc-acm printing error
https://jira.zephyrproject.org/browse/ZEP-2074

[ZEP-2072] samples/net/mbedtls_dtlsclient: compile warnings
https://jira.zephyrproject.org/browse/ZEP-2072

[ZEP-2071] samples: warning: (SPI_CS_GPIO && SPI_SS_CS_GPIO && I2C_NRF5) selects GPIO which has unmet direct dependencies
https://jira.zephyrproject.org/browse/ZEP-2071


UPDATED JIRA items within last 24 hours: 9
[ZEP-2073] LE Advertising Extensions
https://jira.zephyrproject.org/browse/ZEP-2073

[ZEP-2009] Port test_sleep test to unified kernel and cleanup
https://jira.zephyrproject.org/browse/ZEP-2009

[ZEP-2008] Port tickless idle test to unified kernel and cleanup
https://jira.zephyrproject.org/browse/ZEP-2008

[ZEP-1621] Stack Monitoring
https://jira.zephyrproject.org/browse/ZEP-1621

[ZEP-1463] Add Zephyr Support in segger SystemView
https://jira.zephyrproject.org/browse/ZEP-1463

[ZEP-1322] Kernel Primer improvements
https://jira.zephyrproject.org/browse/ZEP-1322

[ZEP-1652] Adapt a Galileo's Ethernet DW driver for new IP stack
https://jira.zephyrproject.org/browse/ZEP-1652

[ZEP-2066] nitpick: SOCK_STREAM/SOCK_DGRAM values swapped compared to most OSes
https://jira.zephyrproject.org/browse/ZEP-2066

[ZEP-472] Ethernet packets are getting missed if sent in quick succession.
https://jira.zephyrproject.org/browse/ZEP-472


CLOSED JIRA items within last 24 hours: 4
[ZEP-2033] (Done) Channel Selection Algorithm #2
https://jira.zephyrproject.org/browse/ZEP-2033

[ZEP-843] (Fixed) Unified assert/unrecoverable error infrastructure
https://jira.zephyrproject.org/browse/ZEP-843

[ZEP-1993] (Fixed) Flowcontrol Required for CDC_ACM
https://jira.zephyrproject.org/browse/ZEP-1993

[ZEP-1955] (Fixed) Nested interrupts crash on Xtensa architecture
https://jira.zephyrproject.org/browse/ZEP-1955


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/13239 : release: Prepare for 1.7.1
- https://gerrit.zephyrproject.org/r/13209 : arm: dts: nrf: Add Device Tree Support for nRF51822 SoC & boards
- https://gerrit.zephyrproject.org/r/13215 : Bluetooth: controller: Scan Request Notifications
- https://gerrit.zephyrproject.org/r/13207 : arm: dts: nrf: Fixup nRF52840-QIAA SoC support for device tree
- https://gerrit.zephyrproject.org/r/13208 : arm: dts: nrf: Add Device Tree Support for nRF52840 SoC & boards
- https://gerrit.zephyrproject.org/r/13236 : Bluetooth: hci: Consistently use bt_hci_evt_*
- https://gerrit.zephyrproject.org/r/13235 : samples: net: dns_resolve: Clarify that DNS queries aren't immediate
- https://gerrit.zephyrproject.org/r/13238 : arm: dts: nrf: Remove !HAS_DTS Kconfig bits
- https://gerrit.zephyrproject.org/r/13234 : net: samples: Use correct API to get net pkt length
- https://gerrit.zephyrproject.org/r/13231 : net: rpl: Fix router when it's timer expires
- https://gerrit.zephyrproject.org/r/13233 : net: shell: Make shell commands non-static to allow reuse.
- https://gerrit.zephyrproject.org/r/13232 : net: rpl: Fix invalid usage of router addition api
- https://gerrit.zephyrproject.org/r/13230 : net: ipv6: Use correct API to remove router
- https://gerrit.zephyrproject.org/r/13211 : x86: define MMU data structures
- https://gerrit.zephyrproject.org/r/13229 : boards: disco_l475_iot: Configuration for HTS221 sample
- https://gerrit.zephyrproject.org/r/13228 : DRAFT samples/crypto: Add mbedtls shim driver support
- https://gerrit.zephyrproject.org/r/13227 : DRAFT drivers/crypto: Add mbedTLS shim crypto driver
- https://gerrit.zephyrproject.org/r/13206 : drivers: eth_dw: Port to new IP stack
- https://gerrit.zephyrproject.org/r/13203 : slist: check sys_slist for empty before iteration
- https://gerrit.zephyrproject.org/r/13204 : boards: 96b_carbon: provide FLASH_BASE_ADDRESS to the flash script
- https://gerrit.zephyrproject.org/r/13201 : template_dir: check for prerequisites

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/12622 : arm: Support for new ARM board FRDM-KL25Z
- https://gerrit.zephyrproject.org/r/13187 : samples: sensor: hts221
- https://gerrit.zephyrproject.org/r/13189 : DRAFT: Bluetooth: controller: LE Advertising Extensions
- https://gerrit.zephyrproject.org/r/12821 : Revert "serial: stm32: Give H/W a chance to set the TXE bit on transfer"
- https://gerrit.zephyrproject.org/r/12864 : arm: dts: nrf: Add Device Tree Support for nRF52832 SoC based boards
- https://gerrit.zephyrproject.org/r/13184 : board: Add support for board disco_l475_iot1
- https://gerrit.zephyrproject.org/r/13165 : kernel: queue, fifo: Add cancel_wait operation.
- https://gerrit.zephyrproject.org/r/13179 : doc: net: Fix IP stack architecture data flow pictures
- https://gerrit.zephyrproject.org/r/10814 : Added sensor driver for SI1153. Added proximity sensor_channel entries in sensor.h
- https://gerrit.zephyrproject.org/r/13037 : cc2650: Add random driver.
- https://gerrit.zephyrproject.org/r/12997 : sensortag: Add basic support for Device Tree.
- https://gerrit.zephyrproject.org/r/13035 : cc2650: Add GPIO driver.
- https://gerrit.zephyrproject.org/r/13036 : cc2650: Add pinmux driver.
- https://gerrit.zephyrproject.org/r/13038 : cc2650: Add UART driver.
- https://gerrit.zephyrproject.org/r/12998 : samples: gpio: Add support for SensorTag board.
- https://gerrit.zephyrproject.org/r/12996 : sensortag: Add TI's SensorTag board.
- https://gerrit.zephyrproject.org/r/13039 : cc2650: Add basic support for Device Tree.
- https://gerrit.zephyrproject.org/r/12995 : arm: Add support for TI's CC2650 SoC.
- https://gerrit.zephyrproject.org/r/11236 : arm: Support for new ARM boards (discovery STM32F4 and STM32F429)
- https://gerrit.zephyrproject.org/r/12597 : arm: Support for SPI driver in NXP devices
- https://gerrit.zephyrproject.org/r/12499 : samples: Add mpu stack guard test
- https://gerrit.zephyrproject.org/r/13064 : dts/extract_dts_includes.py: Add partition support
- https://gerrit.zephyrproject.org/r/13163 : boards: mps2_an385: Enable I2C devices
- https://gerrit.zephyrproject.org/r/12366 : net: Add support for winc1500 in Panther board
- https://gerrit.zephyrproject.org/r/12363 : net: remove need for l2 on offloaded drivers
- https://gerrit.zephyrproject.org/r/12364 : net: add initial support for wifi management API
- https://gerrit.zephyrproject.org/r/12497 : arm: core: Integrate thread stack guard feature
- https://gerrit.zephyrproject.org/r/12356 : net: add winc1500 driver from Atmel
- https://gerrit.zephyrproject.org/r/12365 : net: Add zephyr driver for winc1500

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/13237 : Mark version as 1.6.1-rc
- https://gerrit.zephyrproject.org/r/13216 : drivers/Kconfig: Cleanup Kconfig
- https://gerrit.zephyrproject.org/r/13217 : drivers/crypto: Use a proper driver name for TinyCrypt shim driver
- https://gerrit.zephyrproject.org/r/13218 : drivers/crypto: Make ataes132a's Kconfig following syntax rules
- https://gerrit.zephyrproject.org/r/13219 : drivers/crypto: Prefix source code relevantly
- https://gerrit.zephyrproject.org/r/13221 : drivers/crypto: Use sys_log automatic newline addition in tinycrypt shim
- https://gerrit.zephyrproject.org/r/13220 : crypto: Remove useless attribute
- https://gerrit.zephyrproject.org/r/13222 : drivers/crypto: Make tc shim number of sessions Kconfig based
- https://gerrit.zephyrproject.org/r/13223 : drivers/crypto: Use crypto init Kconfig option for tc shim driver
- https://gerrit.zephyrproject.org/r/13224 : drivers/crypto: Fix a memory leak in tc shim driver
- https://gerrit.zephyrproject.org/r/13225 : samples/crypto: Fix memory leaks
- https://gerrit.zephyrproject.org/r/13226 : samples/crypto: Use sys_log properly
- https://gerrit.zephyrproject.org/r/13214 : scripts: openocd.sh: Honour V=1
- https://gerrit.zephyrproject.org/r/13202 : arm: ti: dts: fixup building CC3200 dts
- https://gerrit.zephyrproject.org/r/13213 : Revert "stm32l4: factorize default configuration settings"
- https://gerrit.zephyrproject.org/r/13205 : Bluetooth: controller: Explicit AC and DC packet configure
- https://gerrit.zephyrproject.org/r/13212 : Bluetooth: controller: Low Duty Cycle Directed Advertising
- https://gerrit.zephyrproject.org/r/13210 : sanitycheck: support xunit report
- https://gerrit.zephyrproject.org/r/13197 : subsys: console: Add missing zephyr/types.h include
- https://gerrit.zephyrproject.org/r/13196 : arm: nxp: kl2x: Move to using UART_MCUX_LPSCI for UART0
- https://gerrit.zephyrproject.org/r/13195 : serial: mcux: Shim driver for LPSCI UART on KL25Z
- https://gerrit.zephyrproject.org/r/13198 : arch: Moved atmel_sam3 to atmel_sam3x.
- https://gerrit.zephyrproject.org/r/13199 : doc: fix broken :ref: link
- https://gerrit.zephyrproject.org/r/13200 : doc: fix typo in shell doc
- https://gerrit.zephyrproject.org/r/11785 : kernel: tickless: Add function to check if list contains multiple nodes
- https://gerrit.zephyrproject.org/r/12745 : kernel: tickless: Rename _Swap to allow creation of macro
- https://gerrit.zephyrproject.org/r/11786 : kernel: tickless: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11787 : timer: tickless: hpet: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11839 : timer: tickless: loapic: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/12741 : timer: tickless: cortex_m: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/12780 : timer: tickless: arcv2: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11667 : samples: tickless: Enables tickless kernel option in some apps
- https://gerrit.zephyrproject.org/r/12781 : samples: power: Time is passed as milliseconds in tickless kernel
- https://gerrit.zephyrproject.org/r/13191 : net: zoap: Remove magic number
- https://gerrit.zephyrproject.org/r/13192 : net: zoap: Minor comment style fixes
- https://gerrit.zephyrproject.org/r/13194 : net: zoap: Remove unused struct definition
- https://gerrit.zephyrproject.org/r/13190 : net: zoap: Add timeout while requesting packets
- https://gerrit.zephyrproject.org/r/13193 : net: zoap: Add block wise support for well-known response
- https://gerrit.zephyrproject.org/r/13181 : soc: stm32l4xx: add support for STM32L475XG
- https://gerrit.zephyrproject.org/r/13185 : stm32l4: factorize default configuration settings
- https://gerrit.zephyrproject.org/r/12984 : driver: clock control stm32: align f4 factor names on l4
- https://gerrit.zephyrproject.org/r/12983 : driver: uart: clock control code refactoring
- https://gerrit.zephyrproject.org/r/12979 : drivers: dma_stm32f4x: make driver compatible with LL Clock Driver
- https://gerrit.zephyrproject.org/r/12978 : drivers: clock control: Provide LL based clock control for stm32f4 series
- https://gerrit.zephyrproject.org/r/12980 : boards: stm32f4: Provide config for LL Clock control
- https://gerrit.zephyrproject.org/r/12981 : soc: stm32f4: Enable LL based clock control
- https://gerrit.zephyrproject.org/r/12982 : stm32f4: Clean references to stm32f4 specific clock control
- https://gerrit.zephyrproject.org/r/12661 : kernel: expose struct k_thread implementation
- https://gerrit.zephyrproject.org/r/13147 : arch: Moved Atmel SAM3 into the SAM SoC family tree.


mbedtls and memory allocator

Tomasz Bursztyka
 

Hi,

I sent a draft for a mbedtls shim crypto device driver, so it exposes CCM operations (for now)
through Crypto API.

Patch is here:

https://gerrit.zephyrproject.org/r/#/c/13227/

While running the cryto sample on top of it, I get a mbedtls memory allocation error
when calling mbedtls_ccm_setkey().

Looking quickly at mbdetls code, it seems to want to allocate some space for the chosen
cipher (AES here) and obviously fails because there is no calloc in Zephyr, and instead
mbedtls is built to return NULL from a default built-in memory allocator.

I used ext/lib/crypto/mbedtls/configs/config-ccm-psk-tls1_2.h
That one is being used in, for instance, samples/net/mbedtls_sslclient. And AES and CCM
could be used there, I wonder how it is supposed to work if it has the same issue.

So, before I dive deeper into mbedtls myself:

How is mbedtls supposed to be configured to get AES CCM working without any dynamic memory allocator?

If by any chance someone has already worked with mbedtls, it will be of great help to give me hints.

Thanks,

Tomasz


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 22
[ZEP-2011] Retrieve RPL node information through CoAP requests
https://jira.zephyrproject.org/browse/ZEP-2011

[ZEP-2068] Need Tasks to Be Tracked in QRC too
https://jira.zephyrproject.org/browse/ZEP-2068

[ZEP-2026] Add 802.15.4 driver for KW41Z
https://jira.zephyrproject.org/browse/ZEP-2026

[ZEP-1825] Context Switching KPI
https://jira.zephyrproject.org/browse/ZEP-1825

[ZEP-1823] Improved Benchmarks
https://jira.zephyrproject.org/browse/ZEP-1823

[ZEP-948] Revisit the timeslicing algorithm
https://jira.zephyrproject.org/browse/ZEP-948

[ZEP-2053] Update tinycrypt to v.0.2.6 in recent releases
https://jira.zephyrproject.org/browse/ZEP-2053

[ZEP-1772] re-introduce controller to host flow control
https://jira.zephyrproject.org/browse/ZEP-1772

[ZEP-21] BT 4.2 Controller-based link-layer privacy
https://jira.zephyrproject.org/browse/ZEP-21

[ZEP-1599] printk() support for the '-' indicator in format string (left justifier)
https://jira.zephyrproject.org/browse/ZEP-1599

[ZEP-1819] Add tickless kernel support in nrf_rtc_timer timer
https://jira.zephyrproject.org/browse/ZEP-1819

[ZEP-833] IP-to-IP tunneling support
https://jira.zephyrproject.org/browse/ZEP-833

[ZEP-1940] Event_mask conflict in net_event.h
https://jira.zephyrproject.org/browse/ZEP-1940

[ZEP-1773] bt_conn_le_param_update API improvements
https://jira.zephyrproject.org/browse/ZEP-1773

[ZEP-1856] remove legacy micro/nano kernel APIs
https://jira.zephyrproject.org/browse/ZEP-1856

[ZEP-1868] [IPv6 TAHI] Section 1: RFC 2460 - IPv6 Specification
https://jira.zephyrproject.org/browse/ZEP-1868

[ZEP-1470] Enabling CONFIG_FP_SHARING on ARM causes usage fault
https://jira.zephyrproject.org/browse/ZEP-1470

[ZEP-1927] AIO: AIO_CMP_POL_FALL is triggered immediately after aio_cmp_configure
https://jira.zephyrproject.org/browse/ZEP-1927

[ZEP-1438] AIO: AIO Comparator is not stable on Quark D2000
https://jira.zephyrproject.org/browse/ZEP-1438

[ZEP-2014] Defaul samples/subsys/shell/shell fails to build on QEMU RISCv32 / NIOS2
https://jira.zephyrproject.org/browse/ZEP-2014

[ZEP-1888] the echo_server sample app issue: test UDP with BLE failed
https://jira.zephyrproject.org/browse/ZEP-1888

[ZEP-1901] Missing board documentation for arm/olimexino_stm32
https://jira.zephyrproject.org/browse/ZEP-1901


CLOSED JIRA items within last 24 hours: 37
[ZEP-2034] (Fixed) High Duty Cycle Non-Connectable Advertising
https://jira.zephyrproject.org/browse/ZEP-2034

[ZEP-1791] (Fixed) Add missing platforms to the "Reference Hardware / Platform" field's selection list
https://jira.zephyrproject.org/browse/ZEP-1791

[ZEP-932] (Fixed) Adapt kernel sample & test projects
https://jira.zephyrproject.org/browse/ZEP-932

[ZEP-1331] (Won't Do) Address API inconsistencies with K_xxx_DEFINE() and K_xxx_INITIALIZER()
https://jira.zephyrproject.org/browse/ZEP-1331

[ZEP-293] (Won't Do) Reduce Kconfig variables in sensor drivers
https://jira.zephyrproject.org/browse/ZEP-293

[ZEP-1990] (Done) Basic support for the BBC micro:bit LED display
https://jira.zephyrproject.org/browse/ZEP-1990

[ZEP-973] (Fixed) Remove deprecated API related to device PM, DEVICE_ and SYS_* macros
https://jira.zephyrproject.org/browse/ZEP-973

[ZEP-720] (Done) Add MAX30101 heart rate sensor driver
https://jira.zephyrproject.org/browse/ZEP-720

[ZEP-1959] (Fixed) Add Atmel SAM family serial (UART) driver
https://jira.zephyrproject.org/browse/ZEP-1959

[ZEP-1759] (Fixed) All python scripts needed for build should be moved to python 3 to minimize dependencies
https://jira.zephyrproject.org/browse/ZEP-1759

[ZEP-1326] (Fixed) Clean up _THREAD_xxx APIs
https://jira.zephyrproject.org/browse/ZEP-1326

[ZEP-1392] (Done) Add FXAS21002 gyroscope sensor driver
https://jira.zephyrproject.org/browse/ZEP-1392

[ZEP-888] (Done) 802.15.4 - Security support
https://jira.zephyrproject.org/browse/ZEP-888

[ZEP-828] (Done) IPv6 - Multicast Join/Leave Support
https://jira.zephyrproject.org/browse/ZEP-828

[ZEP-1388] (Done) Add support for KW40 SoC
https://jira.zephyrproject.org/browse/ZEP-1388

[ZEP-1391] (Done) Add support for Hexiwear KW40
https://jira.zephyrproject.org/browse/ZEP-1391

[ZEP-1965] (Fixed) net-tools HEAD is broken for QEMU/TAP
https://jira.zephyrproject.org/browse/ZEP-1965

[ZEP-1997] (Fixed) Crash during startup if co-processors are present
https://jira.zephyrproject.org/browse/ZEP-1997

[ZEP-2029] (Fixed) xtensa: irq_offload() doesn't work on XRC_D2PM
https://jira.zephyrproject.org/browse/ZEP-2029

[ZEP-2019] (Fixed) Xtensa port does not compile if CONFIG_TICKLESS_IDLE is enabled
https://jira.zephyrproject.org/browse/ZEP-2019

[ZEP-2027] (Fixed) Bluetooth Peripheral Sample won't pair with certain Android devices
https://jira.zephyrproject.org/browse/ZEP-2027

[ZEP-1936] (Fixed) tests/drivers/spi/spi_basic_api/testcase.ini#test_spi - Assertion Fail
https://jira.zephyrproject.org/browse/ZEP-1936

[ZEP-2052] (Fixed) arm: unhandled exceptions in thread take down entire system
https://jira.zephyrproject.org/browse/ZEP-2052

[ZEP-1966] (Fixed) Doesn't seem to be able to both send and receive locally via local address
https://jira.zephyrproject.org/browse/ZEP-1966

[ZEP-2037] (Fixed) Malformed echo response
https://jira.zephyrproject.org/browse/ZEP-2037

[ZEP-2012] (Fixed) Fault in networking stack for cores that can't access unaligned memory
https://jira.zephyrproject.org/browse/ZEP-2012

[ZEP-2013] (Fixed) dead object monitor code
https://jira.zephyrproject.org/browse/ZEP-2013

[ZEP-1530] (Fixed) Hotkeys for the menu at the bottom of menuconfig sometimes doesn't work
https://jira.zephyrproject.org/browse/ZEP-1530

[ZEP-1899] (Fixed) Missing board documentation for xtensa/xt-sim
https://jira.zephyrproject.org/browse/ZEP-1899

[ZEP-1910] (Fixed) Missing board documentation for arm/96b_carbon
https://jira.zephyrproject.org/browse/ZEP-1910

[ZEP-1435] (Fixed) Improve Quark SE C1000 ARC Floating Point Performance
https://jira.zephyrproject.org/browse/ZEP-1435

[ZEP-1711] (Fixed) xtensa build defines Kconfigs with lowercase names
https://jira.zephyrproject.org/browse/ZEP-1711

[ZEP-1529] (Fixed) Unable to exit menuconfig
https://jira.zephyrproject.org/browse/ZEP-1529

[ZEP-1722] (Fixed) xtensa: tinycrypt does not build
https://jira.zephyrproject.org/browse/ZEP-1722

[ZEP-1908] (Fixed) Missing board documentation for arm/nucleo_96b_nitrogen
https://jira.zephyrproject.org/browse/ZEP-1908

[ZEP-1769] (Fixed) Implement Set Event Mask and LE Set Event Mask commands
https://jira.zephyrproject.org/browse/ZEP-1769

[ZEP-1887] (Fixed) Build warnings [-Wpointer-sign] with LLVM/icx (tests/drivers/spi/spi_basic_api)
https://jira.zephyrproject.org/browse/ZEP-1887


RESOLVED JIRA items within last 24 hours: 0

4661 - 4680 of 7538