Hi,

On 5/9/19, Nashif, Anas <anas.nashif@intel.com> wrote:

Hi,
I would not compare west to bitbake, maybe to android repo.
The modules are going to be part of the zephyr project, so they will not
randomly disappear.

Gotcha. I just saw the "hal_st" and "hal_qmsi" repo's so that's good.

- Pushpal

Anas

<snip>

Hi,
I would not compare west to bitbake, maybe to android repo.
The modules are going to be part of the zephyr project, so they will not randomly disappear.

Anas

Hi Anas,

On 5/9/19, Nashif, Anas <anas.nashif@intel.com> wrote:

Pushpal,

You will need to use west to get the modules, but you can still build do
everything else as usual.
QMSI is just the first of many PR that we follow.

Thank you for your response. I figured that we're moving towards these
modules. I just wanted to verify that west is becoming an integral
tool for working with Zephyr. It sounds very similar to bitbake.

Has the question of backups been answered? For example, if the source
that a build relies on disappears, how can we continue to use it?

Will west be included with the SDK in the future? Or maybe not because
looking at the documentation, west can actually be used to clone down
Zephyr.

Thanks again!
- Pushpal

Anas

-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org]
On Behalf Of Pushpal Sidhu
Sent: Thursday, May 9, 2019 1:14 PM
To: devel <devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] Question about "Zephyr Modules"

Hi All,

This commit caught my eye:
https://github.com/zephyrproject-rtos/zephyr/pull/16039

Does this mean that, if we use the qmsi hal going forward, we *must* use
west (I wonder why it wasn't called zest instead..) instead of the older
"cmake -DBOARD=xyz" and "make"?

This is really a general question for 'zephyr modules' as I haven't
familiarized myself with west.

Thanks,
- Pushpal

Pushpal,

You will need to use west to get the modules, but you can still build do everything else as usual.
QMSI is just the first of many PR that we follow.

Anas

Hi All,

This commit caught my eye:
https://github.com/zephyrproject-rtos/zephyr/pull/16039

Does this mean that, if we use the qmsi hal going forward, we *must*
use west (I wonder why it wasn't called zest instead..) instead of the
older "cmake -DBOARD=xyz" and "make"?

This is really a general question for 'zephyr modules' as I haven't
familiarized myself with west.

Thanks,
- Pushpal

Reminder: Zephyr Project: Dev Meeting

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

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

An RSVP is requested. Click here to RSVP

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

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

---

 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

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

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 :

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

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. 

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

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

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?

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

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

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

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