1. devel@lists.zephyrproject.org
  2. Messages
   Date   
Upcoming Event: Zephyr Project: APIs - Tue, 05/07/2019 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 7 May 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY
Periodic publishing #bluetoothmesh #nrf52

paul.leguennec@...
 

Hello,

I have been trying to use the periodic publishing in mesh, but I don't really see how to use it correctly. I have read the Mesh Specification, and I already asked here for help on publishing, and somebody gave me an hint by telling me to use the BT_MESH_MODEL_PUB_DEFINE macro with an update callback, but I don't think I am doing this correctly.
Right now I have my callback :
/*Attempt of callback that would allow periodic publishing*/
static int vendor_cb_update(struct bt_mesh_model *model)
{
    struct net_buf_simple *msg = model->pub->msg;
    /*Build message for VND Model CB*/
    bt_mesh_model_msg_init(msg,BT_MESH_MODEL_OP_3(0x08,CID_ZEPHYR)); // init of the status msg handler
    return 0;
}

and I am using the macro like this :
BT_MESH_MODEL_PUB_DEFINE(vnd_pub,vendor_cb_update,3+3);

I have been able to publish a message by pushing a button, and I would like to use only periodic publishing for my project.
Does somebody already used periodic publishing and would be able to tell me what I am doing wrong ?

Many thanks,
Paul
GPIO API update

Piotr Mienkowski
 

Hi,

I started work on updating GPIO API and introducing PINCTRL API. The
initial proposal is described here:
https://github.com/zephyrproject-rtos/zephyr/issues/15611

Since the hardware implementation of GPIO and PINCTRL subsystem vary
widely between different vendors and even SoC families providing a
generic API becomes a relatively complex issue. I would like to deal
with it in a few stages:

- update GPIO API configuration options, e.g. defining pin pull-up, open
source configuration.

- extend GPIO API to support port operations

- add PINCTRL API

Issue #15611 deals only with the first part of the rework. It would be
great if some more developers could review it and leave their comments
on the issue page.

Thanks and regards,
Piotr
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

Marc Herbert
 

On Fri, Apr 26, 2019 at 02:49 AM, Paul Sokolovsky wrote:
Actually, fishing for that link, I see that a whole bunch of changes
was made to the CODEOWNERS file just recently:
https://github.com/zephyrproject-rtos/zephyr/commits/master/CODEOWNERS

Just imagine that any of those changes could break syntax a bit or
propagation of changes to it could glitch on Github side, leading to
the effect we see.
Good guess. Anas found the bug (commas) and fixed it at https://github.com/zephyrproject-rtos/zephyr/commit/af3f81ef04bccd0b959

Curious how Anas debugged this because I just found this user who put a lot of effort:
http://www.benjaminoakes.com/git/2018/08/10/Testing-changes-to-GitHub-CODEOWNERS/


2018-08-31
Dear [github] support,
 
I’ve discovered what I believe to be a bug in CODEOWNERS. In particular, a single line failing to parse [trailing # comment] causes the entire file to stop identifying codeowners. This is in contrast to .gitignore, in which a single line failing to parse simply causes that line to be skipped. [...] I verified this behavior by making a sandbox repository and making pull requests until I narrowed down when the bug occurred [...] This situation was exacerbated by a lack of error messages in the GitHub UI. Ideally, we’d have access to a linter or at least highlighting in GitHub that would call out invalid syntax. 
Github's answer:
 
Thanks for reaching out! This is currently expected behavior, but I can definitely understand why it would be unexpected. I’ll pass your feedback along to the team internally. I can’t say if or when a change will happen, but your feedback is in the right hands.

So apparently no "API" available, it would have been documented at https://help.github.com/en/articles/about-code-owners otherwise. No need to ask github either as the feedback is already "in the right hands".

Marc
Zephyr Project: Dev Meeting - Thu, 05/02/2019 8:00am-9:00am #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder:
Zephyr Project: Dev Meeting

When:
Thursday, 2 May 2019
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/993312203

Organizer:
devel@...

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

An RSVP is requested. Click here to RSVP

MCUBoot can't find bootable image (nRF52)

Benjamin Lindqvist
 

Hey,

I've been trying to build the mcumgr/smp_svr sample on a nRF52840 DK
(pca10056) by following
https://docs.zephyrproject.org/latest/samples/subsys/mgmt/mcumgr/smp_svr/README.html,
using Zephyr v1.14.0 and MCUBoot v1.3.0.

I follow the instructions, everything gets built, signed and flashed
fine it seems, but MCUBoot can't find a bootable image. This is how I
signed the image:

./imgtool.py sign \
--key mcuboot/root-rsa-2048.pem \
--header-size 0x200 \
--align 8 \
--version 1.2 \
--slot-size 0x68000 \
$ZEPHYR_BIN_DIR/zephyr.hex \
$ZEPHYR_BIN_DIR/signed.hex

MCUBoot always gets stuck at

Remote debugging using localhost:2331
0x000004fa in main () at ../main.c:202
202 BOOT_LOG_ERR("Unable to find bootable image");

caused by boot_validate_slot(0, NULL) returning an error, in turn caused
by

if (boot_check_header_erased(slot) == 0 || (hdr->ih_flags & IMAGE_F_NON_BOOTABLE)) {

triggering. Has anyone verified the sample for the versions mentioned?
Re: Wrapping compiler builtins

Sigvart Hovland
 

I would say it’s an interest in such a pull request to enable more toolchains to build zephyr.

 

> Would you be interested in pull requests that add something like this to Zephyr? The goal would be to eliminate naked built-ins from the cross-platform parts of the code. The architecture-specific built-ins are much less of a problem, I think.

 
Re: Wrapping compiler builtins

Kumar Gala
 

On Apr 30, 2019, at 12:37 PM, Jakob Stoklund Olesen <jolesen@fb.com> wrote:

Hi,

I’m new to Zephyr. It’s an impressive project!

I’ve been compiling parts of Zephyr in different environments in order to run unit tests on macOS and using the native_posix board on a Linux machine. I hit some trivial portability issues with the Zephyr code, particularly:
• Macros like __used and __unused are already defined by a system header on macOS.
• Integer overflow built-ins like __builtin_add_overflow() were introduced in GCC 5.2, so they don’t build with GCC 4.8.

I see that header files like toolchain/xcc.h define these built-ins for compilers that don’t have them, but redefining built-ins this way has a couple problems:
• C identifiers starting with a double underscore are reserved for the implementation (compiler + standard libraries), so redefining them could cause problems with future compiler releases. See https://en.cppreference.com/w/c/language/identifier#Reserved_identifiers.
• The precise semantics of some built-ins can be impossible to replicate in compilers that don’t support them. For example __builtin_add_overflow() is generic over its argument types in a way that would be difficult to imitate even with C++ templates. Seehttps://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html.
• Some built-ins have unfortunate corner case behaviors that reflect their history more than good design. For example, __builtin_ctz(x) invokes undefined behavior when x=0 which can be surprising.
I think both 2) and 3) have the potential to cause subtle security issues that only show up on some platforms.

Other performance-conscious open source projects also use compiler built-ins, but deal with these problems by wrapping built-ins in inline functions. Two examples are
• Mozilla: https://hg.mozilla.org/mozilla-central/file/tip/mfbt/MathAlgorithms.h
• LLVM: https://llvm.org/doxygen/MathExtras_8h_source.html
These libraries of inline functions address the problems with naked built-ins by:
• Defining inline functions with normal names that aren’t reserved. The implementation uses compiler built-ins when available, so the generated machine code is normally identical after inlining.
• Defining functions with semantics that don’t extend the C language. For example, there would be separate xxx_add_overflow() functions for each integer type needed.
• Avoiding undefined behavior and surprising corner cases. For example CountTrailingZeroes32(0) is defined to return 32.

Would you be interested in pull requests that add something like this to Zephyr? The goal would be to eliminate naked built-ins from the cross-platform parts of the code. The architecture-specific built-ins are much less of a problem, I think.

Thanks,
Jakob
There is interest in this as we want to support various toolchains beyond GCC. So we need to look at cleaning this up. I’d suggest maybe working up a simple proof of concept PR as the best way to discuss this.

- k
Event: Zephyr Project: APIs #cal-invite

devel@lists.zephyrproject.org Calendar <devel@...>
 

Zephyr Project: APIs

When:
Tuesday, 7 May 2019
9:00am to 10:00am
(GMT-07:00) America/Los Angeles
Repeats: Weekly on Tuesday

Where:
https://zoom.us/j/177647878

Organizer:
devel@...

An RSVP is requested. Click here to RSVP

Description:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY

Calendar
Calendar

Event: Zephyr Project: Dev Meeting #cal-invite

devel@lists.zephyrproject.org Calendar <devel@...>
 

Zephyr Project: Dev Meeting

When:
Thursday, 2 May 2019
8:00am to 9:00am
(GMT-07:00) America/Los Angeles
Repeats: Weekly on Thursday

Where:
https://zoom.us/j/993312203

Organizer:
tsc@...

An RSVP is requested. Click here to RSVP

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Calendar
Calendar

Wrapping compiler builtins

Jakob Stoklund Olesen <jolesen@...>
 

Hi,

 

I’m new to Zephyr. It’s an impressive project!

 

I’ve been compiling parts of Zephyr in different environments in order to run unit tests on macOS and using the native_posix board on a Linux machine. I hit some trivial portability issues with the Zephyr code, particularly:

  • Macros like __used and __unused are already defined by a system header on macOS.
  • Integer overflow built-ins like __builtin_add_overflow() were introduced in GCC 5.2, so they don’t build with GCC 4.8.

 

I see that header files like toolchain/xcc.h define these built-ins for compilers that don’t have them, but redefining built-ins this way has a couple problems:

  1. C identifiers starting with a double underscore are reserved for the implementation (compiler + standard libraries), so redefining them could cause problems with future compiler releases. See https://en.cppreference.com/w/c/language/identifier#Reserved_identifiers.
  2. The precise semantics of some built-ins can be impossible to replicate in compilers that don’t support them. For example __builtin_add_overflow() is generic over its argument types in a way that would be difficult to imitate even with C++ templates. See https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html.
  3. Some built-ins have unfortunate corner case behaviors that reflect their history more than good design. For example, __builtin_ctz(x) invokes undefined behavior when x=0 which can be surprising.

I think both 2) and 3) have the potential to cause subtle security issues that only show up on some platforms.

 

Other performance-conscious open source projects also use compiler built-ins, but deal with these problems by wrapping built-ins in inline functions. Two examples are

These libraries of inline functions address the problems with naked built-ins by:

  1. Defining inline functions with normal names that aren’t reserved. The implementation uses compiler built-ins when available, so the generated machine code is normally identical after inlining.
  2. Defining functions with semantics that don’t extend the C language. For example, there would be separate xxx_add_overflow() functions for each integer type needed.
  3. Avoiding undefined behavior and surprising corner cases. For example CountTrailingZeroes32(0) is defined to return 32.

 

Would you be interested in pull requests that add something like this to Zephyr? The goal would be to eliminate naked built-ins from the cross-platform parts of the code. The architecture-specific built-ins are much less of a problem, I think.

 

Thanks,

Jakob

 
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

Marc Herbert
 

Hi,

I wasn't requested for review. Again, that's not the only case. [...]
This is problematic, because there's a risk that under-reviewed
changes will get into the codebase, causing regressions. So, raising
to the awareness of the TSC.
While github's features should really work as expected to save confusion
and everyone's time, I hope this "under-review" risk is very small
because I would expect every reviewer to... review the list of other
reviewers first thing and add anyone they think could be missing and
could help. Not just other co-owners, far from it.

Database-backed review tools like github avoid broadcasts. This can be
an advantage compared to pure email reviews but it requires a reasonable
"networking" effort; otherwise there's a risk of ending up with the
other extreme: semi-private, not very open-source reviews. I would also
expect developers to err on the "oversubscription" side a bit because
withdrawing from a review takes one click whereas you can't add yourself
to something you don't know exist.

The above is just based on experience with code reviews in general and
more specifically the acute problem of finding reviewers' time. Everyone
loves code reviews, yet for some reason I rarely ever see time scheduled
for them :-) Thanks in advance for correcting any of the generalities
above that wouldn't apply to Zephyr.


I see that a whole bunch of changes was made to the CODEOWNERS file
just recently.
Just imagine that any of those changes could break syntax a bit or
propagation of changes to it could glitch on Github side, leading to
the effect we see. And that's not counting a possible coincidence of
Github tighting up the syntax for that file...
It'd be nice from github to share the corresponding parsing code; think
open source.

Marc
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

Marc Herbert
 

[duplicate message cause the web interface doesn't seem to support cross-posting]

 

I don't know about the github side, however I just found and fixed a number of issues in the Zephyr script that checks the CODEOWNERS file, please help review: https://github.com/zephyrproject-rtos/ci-tools/pull/54

 
Re: To bring back RPL to Zephyr project

Jian Zhang
 

Hi Thiago,

That's good to know. I will start bringing RPL back to Zephyr :)

Thanks and Best Regards,
Jian

---- On Mon, 15 Apr 2019 19:51:05 +0800 Thiago Silveira <thiago@exati.com.br> wrote ----

Hello Jian,
>
> We do use the RPL module in our project, and we will keep using it in the future.
>
> Unfortunately, as we are a very small team, we didn't have the resources to step up and maintain it then, and we don't have the resources now. If you do happen to bring it back and take the responsibility, I'd be glad to help in any way I can.
>
> Best regards,
> Thiago
> On Fri, Apr 5, 2019 at 11:36 PM Jian Zhang <kernel@ubicomp.com.au> wrote:
> Hi All,
>
> I am kind of new to Zephyr dev community. Previously our team was using Zephyr without actively involved in kernel development.
>
> Recently we just noticed that RPL module will be removed in the coming release. Because we are using Zephyr and RPL in the current project and probably will keep using it. I am thinking of bringing it back and take the responsibility to maintain it.
>
> Just want to check if the RPL module with Zephyr is used anywhere? In case it's not required by anyone else, it probably would be easier for us to maintain our own branch.
>
> Please let me know if you guys have any thoughts.
>
> Thanks and Best Regards,
> Jian
>
>
>
>
>
Re: app runs using 1.13 but does not using 1.14

Jiří Kubias <jiri.kubias@...>
 

Hi,
you can get the error line by issuing command
/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-addr2line -e zephyr/zephyr.elf 0x200049a0  - this will show you where the error is. 

Best regard, 
Jiri 

pá 26. 4. 2019 v 15:33 odesílatel Abderrezak Mekkaoui <ab.mekka@...> napsal:

Hi All,

I have an app, based on the Bluetooth peripheral_esp sample, that builds
and runs as expected using zephyr 1.13.99. Using 1.14, it builds
correctly but crashes with the following message:

***** MPU FAULT *****
   Instruction Access Violation
***** Hardware exception *****
Current thread ID = 0x200022d0
Faulting instruction address = 0x200049a0
Fatal fault in essential thread! Spinning..

Before crashing it displays some expected sensor readings. It looks like
Bluetooth fails completely.
Any quick hints on what might be the cause?
Thanks

Abderrezak






--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================
app runs using 1.13 but does not using 1.14

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi All,

I have an app, based on the Bluetooth peripheral_esp sample, that builds and runs as expected using zephyr 1.13.99. Using 1.14, it builds correctly but crashes with the following message:

***** MPU FAULT *****
  Instruction Access Violation
***** Hardware exception *****
Current thread ID = 0x200022d0
Faulting instruction address = 0x200049a0
Fatal fault in essential thread! Spinning..

Before crashing it displays some expected sensor readings. It looks like Bluetooth fails completely.
Any quick hints on what might be the cause?
Thanks

Abderrezak
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

Paul Sokolovsky
 

On Fri, 26 Apr 2019 09:25:17 +0000
"Alberto Escolar Piedras (ALPI)" <ALPI@oticon.com> wrote:

Thanks Paul,
Do you have some indication of when did this break?
Well, I was on vacation for two weeks before Apr 15. It definitely
worked before that. And I saw first problematic case last week, after
returning from vacation. No idea if that might be related to
https://github.com/zephyrproject-rtos/zephyr/commit/636a7af43e704e25af29b31d565399fc02fef408
- nothing wrong is seen here.

Actually, fishing for that link, I see that a whole bunch of changes
was made to the CODEOWNERS file just recently:
https://github.com/zephyrproject-rtos/zephyr/commits/master/CODEOWNERS

Just imagine that any of those changes could break syntax a bit or
propagation of changes to it could glitch on Github side, leading to
the effect we see. And that's not counting a possible coincidence of
Github tighting up the syntax for that file...


BR
Alberto

-----Original Message-----
From: tsc@lists.zephyrproject.org
[mailto:tsc@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky via
Lists.Zephyrproject.Org Sent: Friday 26 April 2019 11:10 To:
devel@lists.zephyrproject.org; tsc@lists.zephyrproject.org Cc:
tsc@lists.zephyrproject.org Subject: [Zephyr-tsc] Github CODEOWNERS
auto-assignment doesn't work as expected

Hello,

As was noticed in a few (multiple?) PRs, automatic reviewer
assignment based on the CODEOWNERS file no longer works as expected,
specifically fails to assign reviewers.

A recent example of this is
https://github.com/zephyrproject-rtos/zephyr/pull/15670 - while
there's an entry:

/subsys/net/ip/ @jukkar @tbursztyka @pfalcon

in CODEOWNERS, I wasn't requested for review. Again, that's not the
only case.

For a clean-room test, I submitted
https://github.com/zephyrproject-rtos/zephyr/pull/15683 and as can be
seen, the reviewer list is empty.

This is problematic, because there's a risk that under-reviewed
changes will get into the codebase, causing regressions. So, raising
to the awareness of the TSC.


--
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




--
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
Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

alpi@...
 

Thanks Paul,
Do you have some indication of when did this break?

BR
Alberto

-----Original Message-----
From: tsc@lists.zephyrproject.org [mailto:tsc@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky via Lists.Zephyrproject.Org
Sent: Friday 26 April 2019 11:10
To: devel@lists.zephyrproject.org; tsc@lists.zephyrproject.org
Cc: tsc@lists.zephyrproject.org
Subject: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

Hello,

As was noticed in a few (multiple?) PRs, automatic reviewer assignment based on the CODEOWNERS file no longer works as expected, specifically fails to assign reviewers.

A recent example of this is
https://github.com/zephyrproject-rtos/zephyr/pull/15670 - while there's an entry:

/subsys/net/ip/ @jukkar @tbursztyka @pfalcon

in CODEOWNERS, I wasn't requested for review. Again, that's not the only case.

For a clean-room test, I submitted
https://github.com/zephyrproject-rtos/zephyr/pull/15683 and as can be seen, the reviewer list is empty.

This is problematic, because there's a risk that under-reviewed changes will get into the codebase, causing regressions. So, raising to the awareness of the TSC.


--
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
Github CODEOWNERS auto-assignment doesn't work as expected

Paul Sokolovsky
 

Hello,

As was noticed in a few (multiple?) PRs, automatic reviewer assignment
based on the CODEOWNERS file no longer works as expected, specifically
fails to assign reviewers.

A recent example of this is
https://github.com/zephyrproject-rtos/zephyr/pull/15670 - while there's
an entry:

/subsys/net/ip/ @jukkar @tbursztyka @pfalcon

in CODEOWNERS, I wasn't requested for review. Again, that's not the
only case.

For a clean-room test, I submitted
https://github.com/zephyrproject-rtos/zephyr/pull/15683 and as can be
seen, the reviewer list is empty.

This is problematic, because there's a risk that under-reviewed changes
will get into the codebase, causing regressions. So, raising to the
awareness of the TSC.


--
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
#bluetoothmesh Using the Period Publish in Mesh #bluetoothmesh

paul.leguennec@...
 

Hi,

How could I use periodic publishing in Mesh ? I have looked through the Mesh Spec (especially section 3.7.6.1), and I tried to understand in include files how to use it but I haven't understood where I should be using it (in the cfg_srv implementation ?/ in the cfg_cli implementation ?).

For now I tried using my vendor model to send a get message when I push a button but it din't work and I want to see if periodic publishing would work better.

Regards,
Paul
1981 - 2000 of 7929