1. devel@lists.zephyrproject.org
   Date   
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
 

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
Re: Support for Open Supervised Device Protocol (OSDP) in Zephyr

Siddharth Chandrasekaran
 

Hi Thea,

Thanks for helping me out; have you had a chance to look into this?

Sid.

---- On Sun, 14 Apr 2019 01:24:31 +0530 Thea Aldrich <aldrich.thea@...> wrote ----

Hi Sid,
Thanks so much for reaching out.  Let me do some asking around as to which working group within Zephyr Project can best look into and,  if things align, help with coordination. I'll be back with more specific information on Monday. Thanks so much for your patience!

Best, 
Thea


On Sat, Apr 13, 2019, 1:54 PM Siddharth Chandrasekaran <siddharth@...> wrote:

Hi,

Can anyone comment on this? It'd be helpful to know such information earlier on.

Sid.

 ---- On Sun, 07 Apr 2019 00:39:04 +0530 Siddharth Chandrasekaran <siddharth@...> wrote ----
 > Hello,
 >
 > I'm working on an project that involves Open Supervised Device Protocol (OSDP) [1], an access control communication protocol used in the security industry. I'm working on this as an application at this point but I think this protocol may be useful for others too. So I'm looking at options for upstreaming it.
 >
 > I would like to know if this is something that the upstream is interested at this point. If so, some pointers on where to add such protocol implementations and other references would be of help.
 >
 > Thanks,
 > Sid.
 >
 >
 >






Re: Zephyr 1.14.0 Released (corrected)

Kumar Gala
 

Developers,

I wanted to thank everyone again that’s been part of the Zephyr community and contributed to the project and this major milestone in the project’s history.

As we now have an LTS release with 1.14 we will be putting in some processes on how code gets incorporated into the LTS branch. The first such activity is marking any PR that should be considered for LTS with the 'backport v1.14-branch’ tag. We are going to try and utilize a GitHub App that should hopefully help with the backport processes to the v1.14-branch. By tagging the PR with the label, the app will try and automatically create a PR for the backport once the original PR gets merged (if it can).

The TSC is meeting Face to Face next Week (April 24/25th) and one of the topics that we will be discussing is further processes around the LTS branch.

Additionally, now that 1.14 is out, we will slowly start merging PRs, the focus will first be on bug fix PRs as these might also be candidates for 'backport v1.14-branch'. I’d ask all developers, maintainers, and users to look at any outstanding PRs and mark them with the 'backport v1.14-branch’ label if you think they are candidates. Please bare with us as we slowly get back to the normal pace of development.

Thanks everyone!

- k

On Apr 16, 2019, at 4:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote:

All,

In my rush to get 1.14 released, I reported on the Major Enhancements from 1.13. Sorry for the confusion. Here is the corrected list of Major Enhancements in 1.14:

* The Zephyr project now supports over 160 different board configurations
spanning 8 architectures. All architectures are rigorously tested and
validated using one of the many simulation platforms supported by the
project: QEMU, Renode, ARC Simulator, and the native POSIX configuration.

* The timing subsystem has been reworked and reimplemented, greatly
simplifying the resulting drivers, removing thousands of lines
of code, and reducing a typical kernel build size by hundreds of bytes.
TICKLESS_KERNEL mode is now the default on all architectures.

* The Symmetric Multi-Processing (SMP) subsystem continues to evolve
with the addition of a new CPU affinity API that can "pin" threads to
specific cores or sets of cores. The core kernel no longer uses the
global irq_lock on SMP systems, and exclusively uses the spinlock API
(which on uniprocessor systems reduces to the same code).

* Zephyr now has support for the x86_64 architecture. It is currently
implemented only for QEMU targets, supports arbitrary numbers of CPUs,
and runs in SMP mode by default, our first platform to do so.

* We've overhauled the Network packet (net-pkt) API and moved the majority
of components and protocols to use the BSD socket API, including MQTT,
CoAP, LWM2M, and SNTP.

* We enhanced the native POSIX port by adding UART, USB, and display
drivers. Based on this port, we added a simulated NRF52832 SoC which enables
running full system, multi-node simulations, without the need of real
hardware.

* We added an experimental BLE split software Controller with Upper Link Layer
and Lower Link Layer for supporting multiple BLE radio hardware
architectures.

* The power management subsystem has been overhauled to support device idle
power management and move most of the power management logic from the
application back to the BSP.

* We introduced major updates and an overhaul to both the logging and
shell subsystems, supporting multiple back-ends, integration
of logging into the shell, and delayed log processing.

* Introduced the `west` tool for management of multiple repositories and
enhanced support for flashing and debugging.

* Added support for application user mode, application memory
partitions, and hardware stack protection in ARMv8m

* Applied MISRA-C code guideline on the kernel and core components of Zephyr.
MISRA-C is a well established code guideline focused on embedded systems and
aims to improve code safety, security and portability.

- kumar

On Apr 16, 2019, at 3:44 PM, Kumar Gala <kumar.gala@linaro.org> wrote:

Hi,

We are pleased to announce the release of Zephyr kernel version 1.14.0. The 1.14.0 will be the first Zephyr LTS release that we will support for at least 2 years.

Major enhancements with this release include:

* Extensible and Pluggable Tracing Support
* Compartmentalized application memory organization
* Logging System Overhaul
* Introduce system calls for BSD socket APIs
* Support for IEEE 802.1AS-2011 generalized Precision Time Protocol (gPTP)
* Link Layer Discovery Protocol (LLDP) TX support
* Support for TLS and DTLS using BSD socket API
* Support for Link Layer Multicast Name Resolution (LLMNR)
* Introduced reworked ADC API and updated Nordic, NXP, Atmel, and Synopsys DesignWare drivers
* Support OS driven Power Management framework
* Basic support for Arm TrustZone in Armv8-M

The detailed release notes can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.14.0

I would like to thank all the contributors to this release. In total 250 contributors participated in the development of 1.14. Its taken a lot of hard work from everyone in the Zephyr community!

Thank you again,

Kumar Gala
Re: Zephyr 1.14.0 Released (corrected)

Kumar Gala
 

All,

In my rush to get 1.14 released, I reported on the Major Enhancements from 1.13. Sorry for the confusion. Here is the corrected list of Major Enhancements in 1.14:

* The Zephyr project now supports over 160 different board configurations
spanning 8 architectures. All architectures are rigorously tested and
validated using one of the many simulation platforms supported by the
project: QEMU, Renode, ARC Simulator, and the native POSIX configuration.

* The timing subsystem has been reworked and reimplemented, greatly
simplifying the resulting drivers, removing thousands of lines
of code, and reducing a typical kernel build size by hundreds of bytes.
TICKLESS_KERNEL mode is now the default on all architectures.

* The Symmetric Multi-Processing (SMP) subsystem continues to evolve
with the addition of a new CPU affinity API that can "pin" threads to
specific cores or sets of cores. The core kernel no longer uses the
global irq_lock on SMP systems, and exclusively uses the spinlock API
(which on uniprocessor systems reduces to the same code).

* Zephyr now has support for the x86_64 architecture. It is currently
implemented only for QEMU targets, supports arbitrary numbers of CPUs,
and runs in SMP mode by default, our first platform to do so.

* We've overhauled the Network packet (net-pkt) API and moved the majority
of components and protocols to use the BSD socket API, including MQTT,
CoAP, LWM2M, and SNTP.

* We enhanced the native POSIX port by adding UART, USB, and display
drivers. Based on this port, we added a simulated NRF52832 SoC which enables
running full system, multi-node simulations, without the need of real
hardware.

* We added an experimental BLE split software Controller with Upper Link Layer
and Lower Link Layer for supporting multiple BLE radio hardware
architectures.

* The power management subsystem has been overhauled to support device idle
power management and move most of the power management logic from the
application back to the BSP.

* We introduced major updates and an overhaul to both the logging and
shell subsystems, supporting multiple back-ends, integration
of logging into the shell, and delayed log processing.

* Introduced the `west` tool for management of multiple repositories and
enhanced support for flashing and debugging.

* Added support for application user mode, application memory
partitions, and hardware stack protection in ARMv8m

* Applied MISRA-C code guideline on the kernel and core components of Zephyr.
MISRA-C is a well established code guideline focused on embedded systems and
aims to improve code safety, security and portability.

- kumar

On Apr 16, 2019, at 3:44 PM, Kumar Gala <kumar.gala@linaro.org> wrote:

Hi,

We are pleased to announce the release of Zephyr kernel version 1.14.0. The 1.14.0 will be the first Zephyr LTS release that we will support for at least 2 years.

Major enhancements with this release include:

* Extensible and Pluggable Tracing Support
* Compartmentalized application memory organization
* Logging System Overhaul
* Introduce system calls for BSD socket APIs
* Support for IEEE 802.1AS-2011 generalized Precision Time Protocol (gPTP)
* Link Layer Discovery Protocol (LLDP) TX support
* Support for TLS and DTLS using BSD socket API
* Support for Link Layer Multicast Name Resolution (LLMNR)
* Introduced reworked ADC API and updated Nordic, NXP, Atmel, and Synopsys DesignWare drivers
* Support OS driven Power Management framework
* Basic support for Arm TrustZone in Armv8-M

The detailed release notes can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.14.0

I would like to thank all the contributors to this release. In total 250 contributors participated in the development of 1.14. Its taken a lot of hard work from everyone in the Zephyr community!

Thank you again,

Kumar Gala
Zephyr 1.14.0 Released

Kumar Gala
 

Hi,

We are pleased to announce the release of Zephyr kernel version 1.14.0. The 1.14.0 will be the first Zephyr LTS release that we will support for at least 2 years.

Major enhancements with this release include:

* Extensible and Pluggable Tracing Support
* Compartmentalized application memory organization
* Logging System Overhaul
* Introduce system calls for BSD socket APIs
* Support for IEEE 802.1AS-2011 generalized Precision Time Protocol (gPTP)
* Link Layer Discovery Protocol (LLDP) TX support
* Support for TLS and DTLS using BSD socket API
* Support for Link Layer Multicast Name Resolution (LLMNR)
* Introduced reworked ADC API and updated Nordic, NXP, Atmel, and Synopsys DesignWare drivers
* Support OS driven Power Management framework
* Basic support for Arm TrustZone in Armv8-M

The detailed release notes can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.14.0

I would like to thank all the contributors to this release. In total 250 contributors participated in the development of 1.14. Its taken a lot of hard work from everyone in the Zephyr community!

Thank you again,

Kumar Gala
Re: Board: Adafruit ItsyBitsy M0 Express

Kumar Gala
 

On Apr 13, 2019, at 8:54 AM, ulrich.althoefer@web.de wrote:

Hello everyone,
the board 'Adafruit Trinket M0' is supported by the Zephyr project.
Is it planned to support the board 'Adafruit ItsyBitsy M0 Express' in the future?
Thanks for your answer.
Not aware of anyone working on this, but looks like it would be trivial to add board support for it based on the 'Adafruit Trinket M0’

- k
1641 - 1660 of 7584