Date   

Re: Next supported boards on Zephyr - STM32L0 ?

Neil Armstrong
 

Hi Felix,

On 06/16/2017 02:26 PM, Erwan Gouriou wrote:
Hi Felix,


From what I'm aware of, there is no such plan. Though, I know Neil as some L0
port working on his own (though on SoC STM32L053). I'm not sure what are his
plans on that, but maybe you could check with him what is missing to get it
upstreamed (might just be time).
Indeed, it's planned but I still need to debug the base port.


In any case, your help would be welcomed to get the board you need supported.
With some help, you could get it working in few hours and upstreamed in couple
of weeks (so you don't have to wait for next Zephyr release :-)).
If you want to give a try, here is my base branch :
https://github.com/superna9999/zephyr/commits/stm32l0x

I'll be happy to cooperate and get this merged when working !
Having STM32L073 working won't be hard if 053 is working.

Neil

Erwan


On 16 June 2017 at 11:11, Felix Levitre <Felix.Levitre@insa-rennes.fr <mailto:Felix.Levitre@insa-rennes.fr>> wrote:

Hi,

I would like to know if the Nucleo STM32L0xx boards from ST (for example STM32L073 with Cortex ARM M0+) will be part of the supported board in the next release of Zephyr ?

If it's not the case, is there a plan to port this board in the future ? (And when ? )

Thanks,

Félix Levitre

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


Is possible move to CMake and crosstools-ng in 1.9

jack ma
 

Hi,
I am looking forward to that zephyr wil move to crosstools-ng and cmake 
just want to know if there are detailed plans for these great work in the next release?

Thanks


Re: Zephyr help

Geoffroy Van Cutsem
 

Hi Tamra,

 

I do not know much about the Z-tree myself but assuming this is equivalent to the Zephyr kernel running on Arduino 101, you could get a lot of info directly from the Zephyr Project website:

* All documentation: https://www.zephyrproject.org/doc/

* Arduino/Genuino 101 documentation: https://www.zephyrproject.org/doc/boards/x86/arduino_101/doc/board.html

 

HTH,

Geoffroy

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Tamra Oyama
Sent: Friday, June 16, 2017 8:46 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Zephyr help

 

Hello Zephyr Team,

I am using the Arduino 101 Curie Open Developer Kit Z-tree.
Link: https://software.intel.com/en-us/node/675544

When I try to compile a file in Zephyr using make config, there are a bunch of choices I need to pick. Is there a standard or default way to set up the zephyr compiler in the Z-tree?

I want to set up the Zephyr OS so I can compile C++ files, how would I go about doing this? In the github below, there are various bluetooth files about controlling bluetooth. I am interested in gaining control of the curie Bluetooth so I can write and compile my own programs. Do you have any suggestions?

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/bluetooth

Thank you,
Tamra


Re: Next supported boards on Zephyr - STM32L0 ?

Erwan Gouriou
 

Hi Felix,


From what I'm aware of, there is no such plan. Though, I know Neil as some L0
port working on his own (though on SoC STM32L053). I'm not sure what are his
plans on that, but maybe you could check with him what is missing to get it
upstreamed (might just be time).

In any case, your help would be welcomed to get the board you need supported.
With some help, you could get it working in few hours and upstreamed in couple
of weeks (so you don't have to wait for next Zephyr release :-)).

Erwan


On 16 June 2017 at 11:11, Felix Levitre <Felix.Levitre@...> wrote:
Hi,

I would like to know if the Nucleo STM32L0xx  boards from ST (for example STM32L073 with Cortex ARM M0+) will be part of the supported board in the next release of Zephyr ?

If it's not the case, is there a plan to port this board in the future ? (And when ? )

Thanks,

Félix Levitre

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


Re: Zephyr 1.8.0 Released

Erwin Rol
 

Thanks for including my Olimex BSP.

- Erwin

On 16-6-2017 5:37, Nashif, Anas wrote:
Hi,



We are pleased to announce the release of Zephyr kernel version 1.8.0.



Major enhancements with this release include:



* Tickless kernel

* IP Stack improvements

* Bluetooth 5.0 features

* Ecosystem: Tracing, debugging support through third-party tools (openocd,

Segger Systemview)

* Improved build support on Mac and Windows development environments

* Xtensa GCC support

* Initial implementation of MMU/MPU support

* Expanded device support



More details can be found here:
https://github.com/zephyrproject-rtos/zephyr/releases





Many thanks to all of you who made this release happen. Thank you for
the contribution and participation.



Regards,

Anas



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


Next supported boards on Zephyr - STM32L0 ?

Felix Levitre <Felix.Levitre@...>
 

Hi,

I would like to know if the Nucleo STM32L0xx boards from ST (for example STM32L073 with Cortex ARM M0+) will be part of the supported board in the next release of Zephyr ?

If it's not the case, is there a plan to port this board in the future ? (And when ? )

Thanks,

Félix Levitre


Zephyr help

Tamra Oyama <tamrako@...>
 

Hello Zephyr Team,

I am using the Arduino 101 Curie Open Developer Kit Z-tree.
Link: https://software.intel.com/en-us/node/675544

When I try to compile a file in Zephyr using make config, there are a bunch of choices I need to pick. Is there a standard or default way to set up the zephyr compiler in the Z-tree?

I want to set up the Zephyr OS so I can compile C++ files, how would I go about doing this? In the github below, there are various bluetooth files about controlling bluetooth. I am interested in gaining control of the curie Bluetooth so I can write and compile my own programs. Do you have any suggestions?

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/bluetooth

Thank you,
Tamra


Zephyr 1.8.0 Released

Nashif, Anas
 

Hi,

 

We are pleased to announce the release of Zephyr kernel version 1.8.0.

 

Major enhancements with this release include:

 

* Tickless kernel

* IP Stack improvements

* Bluetooth 5.0 features

* Ecosystem: Tracing, debugging support through third-party tools (openocd,

  Segger Systemview)

* Improved build support on Mac and Windows development environments

* Xtensa GCC support

* Initial implementation of MMU/MPU support

* Expanded device support

 

More details can be found here: https://github.com/zephyrproject-rtos/zephyr/releases

 

 

Many thanks to all of you who made this release happen. Thank you for the contribution and participation.

 

Regards,

Anas


CAN drivers/infrastructure

Erwin Rol
 

Hey all,

is there anybody working on CAN drivers and/or higher level CAN stacks
like CANOpen ?

- Erwin


Re: sdk-ng

Erwin Rol
 

Hey Anas,

On 14-6-2017 3:56, Nashif, Anas wrote:
Erwin,
The experience should be the same as with the current SDK.
Well than I will be happy :-)

I did not
say anything about downloading IDEs and from various vendors. There are
well-established, standalone toolchains available that are better
supported than what we have in the current SDK.
But do they offer what Zephyr needs? Especially when it comes to the C
library. To take the RTEMS example again, newlib has a lot of RTEMS
support in it.

https://www.sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/sys;hb=HEAD

When things like that are also needed for Zephyr how will those things
end up in the vendor toolchains (and in what timeframe) ?

Membership in the yocto
project is really not a factor here.
When working for small companies one can quickly forget that at Intel
not everybody talks to each other during the coffee break :-)

We are trying to keep things simple
and remove the burden of having to maintain toolchains as part of the
project. Believe it or not, the Zephyr SDK is also a one man show, yocto
being a tool here that has nothing to do with the content of the SDK
itself.
But Yocto does offer infrastructure to download and build tools via a
documented setup.

And no, yocto does not give us an SDK on no Linux platforms and
I thought there was the possibility to do a Candadian cross via
meta-mingw. But never used it so can't say if it would work for the
Zephyr toolchain.

I am not sure what you mean with ptxdist...
www.ptxdist.org is a buildroot-like tool that also used crosstools. It
is mainly used in Germany I guess.

For the Zephyr developer
just like with the current SDK it will be a downloadable file that
installs some toolchains, in other cases it will download toolchains
maintained by vendors like ARM, Intel and Synopsys etc.
Still not convinced it is the right way, but since I can not "put my
money where my mouth is", I will just accept what ever will be offered. :-)

- Erwin


Re: ELCE participation

Michael Turquette <mturquette@...>
 

Hi,

On Thu, Jun 15, 2017 at 7:57 AM, Kumar Gala <kumar.gala@linaro.org> wrote:
On 15 June 2017 at 09:08, Geoffrey LE GOURRIEREC
<geoffrey.legourrierec@smile.fr> wrote:

Hi all,

Not sure if this is the right mailing list for this, but does anybody plan
to participate at the Embedded Linux Conference Europe in Prague, this
October?

If so, what are the subject(s) about to be discussed?
For the last few years there has been an IOT track at ELCE. Not sure what
the plan is this year for that. I know a fair number of Zephyr developers
and maintainers have attended in the past.

- k
Some engineers from BayLibre will be there, as usual :-D

Best regards,
Mike


Cheers,

--
Geoffrey
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.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


--
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/


Re: Situation with net APIs testing

Paul Sokolovsky
 

Hello Jukka,

On Thu, 15 Jun 2017 10:46:29 +0300
Jukka Rissanen <jukka.rissanen@linux.intel.com> wrote:

[]

as part of sanitycheck testsuite! But, 8 tests of tests/net/ have
build_only=true, any wonder they're broken?
When we had gerrit and jenkins, some of the net tests run slightly
longer that what was desired, so they were marked as build only. Now
that situation is different with github and shippable, we can change
this. So I will prepare a patch that activates those tests that can be
activated.
That explains it, thanks.

[]

All other tests programs (24 pieces), that consists of quite many
individual tests, are run automatically by CI, so the situation is not
so bleak as you indicated here.
Great, thanks for clarifying this. Though I hope you'd agree that seeing
such tests as "context" or "tcp" fail does lead to concerns.

I will fix the relevant failing tests as they have bit rotted after
the tests were written.
Nice, thanks for finding time for this!

Converting two mqtt tests to not use real qemu
requires a bit more work.

[]

One would think that if we have 22 repetitive implementations of
test interfaces, whose main purpose is to be just loopback
interfaces,
No, the interface is not a loopback interface although it might look
like that. The purpose of the interface that is created in each of the
test is to simulate a real network so that we do not have to connect
to outside world but the test is self contained. So it kind of looks
like a loopback interface but in this case the source and destination
IP addresses are not the same (as would be the case with loopback
interface), as typically we want to test some real behavior of the
system so src/dest addresses should differ.
I see. I may imagine they offer more functionality than just a loopback
interface. I also may imagine that each of 22 test device
implementations are slightly different to cater for particular
testcases. Nothing of that help someone wanting to write a new test
unfortunately. How would one know that there's no standard device
implementation for dependency-free testing, and having figured that,
how one would choose which of 22 cases to use as a template?

The loopback support has limited use cases actually and we probably
need to make that optional (behind Kconfig option) in the code as
normally there should be no need to send anything back to itself in
the real world.
I absolutely agree that loopback device would be mostly useful for
development and testing, not for production. It also offers limited
testing indeed. But it has one big advantage: tests using it can be
easily run using existing sanitycheck framework. And if loopback
device existed in the main code, such tests would be also easy to write,
unlike now. Summing up, I'd like to give a try to implement one for the
mainline.


then
we'd have a loopback interface in the main codebase. But nope, as
confirmed by Jukka on IRC, we don't.

Summary:

1. Writing networking tests is hard, but it Zephyr, it takes
extraordinary, agonizing effort. The most annoying is that all
needed pieces are there, but instead of presenting a nice picture,
they form a mess which greets you with crashes if you try to change
anything.
I am not sure what kind of mess you mean here but patches are welcome
as always to rectify this.
Well, patches alone won't help here. Writing tests is always hard (for
various reasons, including "tests are code, so why not write 'real'
code instead?"). So, it would be nice to think how to facilitate that.
Specific proposal is to add a loopback netif, I assume it's ok, so will
go for a patch.

[]

there's
something wrong with my system, and yep, I'd be glad to know what
I'm still don't do right with Zephyr after working on it for a
year.)
Hmm, I missed the point of your last sentence.
Well, it's the same issue: various things in Zephyr are "harder than
necessary", so one can never know if something really broke or one
doesn't do all the needed things to run it successfully. It would be
nice to think of making the default config of Zephyr either run OOB, or
fail with clear error messages, not crash or lockup. That's again a big
meta-task, not something which can be "fixed with a patch", but would
be nice to see if different stakeholders of Zephyr agree that there's
an issue which needs attention.



Thanks for all the replies!

--
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: ELCE participation

Kumar Gala
 

For the last few years there has been an IOT track at ELCE.  Not sure what the plan is this year for that.  I know a fair number of Zephyr developers and maintainers have attended in the past.

- k

On 15 June 2017 at 09:08, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...> wrote:
Hi all,

Not sure if this is the right mailing list for this, but does anybody plan
to participate at the Embedded Linux Conference Europe in Prague, this October?

If so, what are the subject(s) about to be discussed?

Cheers,

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


ELCE participation

Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...>
 

Hi all,

Not sure if this is the right mailing list for this, but does anybody plan
to participate at the Embedded Linux Conference Europe in Prague, this October?

If so, what are the subject(s) about to be discussed?

Cheers,

--
Geoffrey


Re: Situation with net APIs testing

Jukka Rissanen
 

Hi Paul,

On Wed, 2017-06-14 at 18:10 +0300, Paul Sokolovsky wrote:
Hello,

As I'm approaching final steps in preparing BSD Sockets patchset for
submission, I'm looking into a way to add some tests for it. Testing
of
networking functionality is by default hard, because in general,
networking hardware would be required for that, even if "virtual",
like
tunslip6, etc. tools from net-tools repo running, to support QEMU
networking. During prototyping work, I learnt there're loopback
capabilities when binding and connecting to the same netif, but it
still requires net-tools running just to get QEMU start up with
networking support.

Well, I took a look at tests/net and saw the whole bunch of tests,
whoa! I gave a try to tests/net/tcp , some cases passed, some failed,
hmm. But then I killed net-tools/loop-slip-tab.sh script and the test
ran in the same manner. Whoa, so we have means to run networking
without any requirements on the host side, which means we can run
them
as part of sanitycheck testsuite! But, 8 tests of tests/net/ have
build_only=true, any wonder they're broken?
When we had gerrit and jenkins, some of the net tests run slightly
longer that what was desired, so they were marked as build only. Now
that situation is different with github and shippable, we can change
this. So I will prepare a patch that activates those tests that can be
activated.

I looked through tests/net what is current status of the tests:

ieee802154/crypto
* This cannot be run on qemu as it requires suitable hw

tcp
* Test does not pass, needs fixing

mld
* Test does not pass, needs fixing

ipv6
* Test does not pass, needs fixing

lib/mqtt_publisher
* Test requires real qemu to run. This needs to be converted 

lib/mqtt_subscriber
* Test requires real qemu to run. This needs to be converted 

buf
* This test runs ok so build_only=true can be removed.

all
* This is intentional compile test that activates all network config
options and tries to compile the binary. The result binary cannot be
run mostly because of memory requirements and no suitable test
environment. The only issue with this test is that we should remember
to add and enable new net config options into this test case.

All other tests programs (24 pieces), that consists of quite many
individual tests, are run automatically by CI, so the situation is not
so bleak as you indicated here.

I will fix the relevant failing tests as they have bit rotted after the
tests were written. Converting two mqtt tests to not use real qemu
requires a bit more work.



Anyway, I looked at what's involved in net-tools free running, and
figured it's CONFIG_NET_L2_DUMMY. Added it to my sockets test, and
got
only segfault in return. After debugging it, turned out it's the same
issue as already faced by me and other folks: if there're no netifs
defined, networking code is going to crash (instead of printing clear
error to the user): https://jira.zephyrproject.org/browse/ZEP-2105

But how the tests/net/ run then and don't crash? Here's the answer:

zephyr/tests/net$ grep NET_DEVICE -r * | wc
     22      42    1532

So, almost each and every test defines its own test interface.

One would think that if we have 22 repetitive implementations of test
interfaces, whose main purpose is to be just loopback interfaces,
No, the interface is not a loopback interface although it might look
like that. The purpose of the interface that is created in each of the
test is to simulate a real network so that we do not have to connect to
outside world but the test is self contained. So it kind of looks like
a loopback interface but in this case the source and destination IP
addresses are not the same (as would be the case with loopback
interface), as typically we want to test some real behavior of the
system so src/dest addresses should differ.

The loopback support has limited use cases actually and we probably
need to make that optional (behind Kconfig option) in the code as
normally there should be no need to send anything back to itself in the
real world.

then
we'd have a loopback interface in the main codebase. But nope, as
confirmed by Jukka on IRC, we don't.

Summary:

1. Writing networking tests is hard, but it Zephyr, it takes
extraordinary, agonizing effort. The most annoying is that all needed
pieces are there, but instead of presenting a nice picture, they form
a mess which greets you with crashes if you try to change anything.
I am not sure what kind of mess you mean here but patches are welcome
as always to rectify this.


2. There're existing big (~20K each) test which fail. Apparently,
because they aren't run, so bitrot. Why do we need these huge,
detailed
tests if we don't run them? (An alternative explanation is that
Some explanation given above.

there's
something wrong with my system, and yep, I'd be glad to know what I'm
still don't do right with Zephyr after working on it for a year.)
Hmm, I missed the point of your last sentence.



I'd be glad if more experienced developers could confirm if it's
really
like the above, or I miss something. And I'll be happy to work on the
above issues, but in the meantime, I'll need to submit BSD Sockets
with
rather bare and hard to run (not automated) tests due to the
situation
above.
Cheers,
Jukka


Situation with net APIs testing

Paul Sokolovsky
 

Hello,

As I'm approaching final steps in preparing BSD Sockets patchset for
submission, I'm looking into a way to add some tests for it. Testing of
networking functionality is by default hard, because in general,
networking hardware would be required for that, even if "virtual", like
tunslip6, etc. tools from net-tools repo running, to support QEMU
networking. During prototyping work, I learnt there're loopback
capabilities when binding and connecting to the same netif, but it
still requires net-tools running just to get QEMU start up with
networking support.

Well, I took a look at tests/net and saw the whole bunch of tests,
whoa! I gave a try to tests/net/tcp , some cases passed, some failed,
hmm. But then I killed net-tools/loop-slip-tab.sh script and the test
ran in the same manner. Whoa, so we have means to run networking
without any requirements on the host side, which means we can run them
as part of sanitycheck testsuite! But, 8 tests of tests/net/ have
build_only=true, any wonder they're broken?

Anyway, I looked at what's involved in net-tools free running, and
figured it's CONFIG_NET_L2_DUMMY. Added it to my sockets test, and got
only segfault in return. After debugging it, turned out it's the same
issue as already faced by me and other folks: if there're no netifs
defined, networking code is going to crash (instead of printing clear
error to the user): https://jira.zephyrproject.org/browse/ZEP-2105

But how the tests/net/ run then and don't crash? Here's the answer:

zephyr/tests/net$ grep NET_DEVICE -r * | wc
22 42 1532

So, almost each and every test defines its own test interface.

One would think that if we have 22 repetitive implementations of test
interfaces, whose main purpose is to be just loopback interfaces, then
we'd have a loopback interface in the main codebase. But nope, as
confirmed by Jukka on IRC, we don't.

Summary:

1. Writing networking tests is hard, but it Zephyr, it takes
extraordinary, agonizing effort. The most annoying is that all needed
pieces are there, but instead of presenting a nice picture, they form
a mess which greets you with crashes if you try to change anything.

2. There're existing big (~20K each) test which fail. Apparently,
because they aren't run, so bitrot. Why do we need these huge, detailed
tests if we don't run them? (An alternative explanation is that there's
something wrong with my system, and yep, I'd be glad to know what I'm
still don't do right with Zephyr after working on it for a year.)


I'd be glad if more experienced developers could confirm if it's really
like the above, or I miss something. And I'll be happy to work on the
above issues, but in the meantime, I'll need to submit BSD Sockets with
rather bare and hard to run (not automated) tests due to the situation
above.



Thanks,

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


Zephyr 1.8.0-rc4 tagged

Nashif, Anas
 

Hi,

I just noticed all my previous rc notifications were stuck and not sent out. Sorry about that.

 

We have just tagged rc4 which is is very close to the final release pending completion of the release notes. If all goes ok with that rc, we will release it as 1.8 in the next 1-2 days.

 

Changes since rc1 are below…

 

Adithya Baglody (2):

      tests: benchmark: app_kernel: Return values from kernel APIs are read.

      tests: benchmark: Fixed build error from icx toolchain.

 

Anas Nashif (17):

      boards: microbit: enable flashing with pyocd

      Revert "xtools: get rid of warnings about wrong path"

      doc: remove links to wiki

      xtools: add new configurations for xtools 1.23

      doc: update macOS getting started documentation

      doc: also require dtc to be installed for linux

      doc: emphasize usage of MSYS2 MSYS Shell

      dts: make extract script take options

      dts: generate definitions for build system

      release: Zephyr 1.8.0-rc2

      Revert "x86: call gen_idt with $ZEPHYR_BASE too"

      quark_d2000_crb: increase default stack size

      gitlint: Ignore signed-off-by line

      release: Tag 1.8.0-rc3

      license: add missing licenses and copyright

      tests: remove obsolete usage of defrag

      release: Tag 1.8.0-rc4

 

Andrew Boie (22):

      bbc_microbit: fix 'make debugserver'

      arm: implement __svc on Cortex M0

      arm: fix k_oops on armv6 with interrupts locked

      Makefile.toolchain.zephyr: fix C++ on Xtensa

      samples: restore cpp_synchronization test

      doc: add interrupt implementation details

      printk: fix printing of long long types

      gccarmemb: don't assume 'dtc' is in /usr/bin

      kernel: fix short time-slice reset

      schedule_api: don't exclude Nios II

      nios2: reset timeslice on interrupt-induced swap

      riscv32: update time slice before swap

      tests: context: make some failures less ambiguous

      tests: context: allow 2 ticks of slop

      sam3x: report correct number of IRQ priority bits

      frdm_k64f: default to pyocd.sh for flashing/debug

      stack_sentinel: change cooperative check

      arches: declare _SysFatalErrorHandler __weak

      k_oops: force unlock IRQs on ARMv7M

      tests: fatal: increase coverage

      stack_sentinel: hang system on failure

      tests: context: move idle test to the end

 

Andy Gross (4):

      Makefile: Add dts config include file

      doc: Add Device Tree documentation

      dts: yaml: Add YAML template file

      scripts: Makefile.lib: Add dependency for DTS overlay

 

Carles Cufi (6):

      Bluetooth: controller: Increase RX prio stack size

      Bluetooth: controller: Conditionally include conn-related options

      Bluetooth: Consolidate all role configuration

      build: Fix DTC overlay file paths on MSYS2

      doc: getting_started: Add WSL instructions

      doc: Fill the Bluetooth section in the 1.8 release notes

 

David B. Kinder (4):

      doc: fix linenum references in api example

      doc: starting draft for 1.8 release notes

      doc: fix misspellings in docs

      doc: fix board/sample broken links

 

David Brown (1):

      dts: Allow override of dts overlay directory

 

Harry Jiang (2):

      sensor: lps22hb: fix the pressure sensor fractional value

      dts: 96b_carbon: Fix the model name and compatible

 

Inaky Perez-Gonzalez (1):

      scripts: look for files with no licensing info

 

Jaganath Kanakkassery (1):

      Bluetooth: SDP: Fix possible out of bound memory access

 

Johan Hedberg (4):

      Bluetooth: AVDTP: Remove dead code

      Bluetooth: Fix missing test for BLUETOOTH_CONN with DLE

      Bluetooth: ATT: Fix canceling ATT timeout upon response

      Bluetooth: L2CAP: Remove redundant checks for chan->ops

 

John Andersen (1):

      samples: net: mqtt_publisher: fixed formatting

 

Jukka Rissanen (31):

      net: zoap: Fix NULL pointer access

      tests: net: zoap: Add path uri matching tests

      net: zoap: Remove extra null checks

      net: http: Add timeout to HTTP server response

      sample: net: http: Add Basic auth support to server sample

      net: Print characters in hexdump

      net: pkt: Handle out-of-mem case properly

      net: ipv6: Skip unknown options in NS message

      net: http: Handle HTTPS connection closing gracefully

      samples: net: mbedtls_dtlsclient: Fix compile issues

      samples: net: mbedtls_dtlsclient: Fix testcase.ini

      samples: net: coaps_client: Fix compile issues

      samples: net: coaps_client: Fix testcase.ini

      net: ipv6: Default reassembly timeout set to 5 sec

      net: ipv6: Memory leak during fragment reassembly

      net: ipv6: Fix the IPv6 packet fragmentation sending

      net: ipv6: Fix fragmentation cancellation

      net: ipv6: Make max number of fragmented pkt configurable

      tests: net: ipv6: Test IPv6 fragmentation sending

      net: shell: Enhance IPv6 fragmentation debugging prints

      net: http: Parsing state was not cleared

      samples: net: zperf: Fix llvm compiler warnings

      samples: net: dtls_client: Fix Coverity warning

      samples: net: http_client: Increase the number of buffers

      net: http: Use random source port when connecting

      net: http: Avoid unnecessary net_pkt error print

      net: tcp: Timeout memory allocations

      net: https: Allow mbedtls debugging for https-server

      samples: net: Fix README.rst file documentation

      net: tcp: Check pkt before sending RESET

      doc: Add networking changes to 1.8 release note

 

Justin Watson (3):

      arch: arm: Fix SoC issues with Atmel SAM4S series.

      boards: arm: Added doc. image for the SAM E70 Xplained.

      boards: arm: arduino_due: Added doc. image for the Arduino Due.

 

Kumar Gala (1):

      toolchain.gccarmemb: Fix support for where to find newlib

 

Leandro Pereira (6):

      drivers: spi_mcux_dspi: Fix unlikely but possible division by zero

      tests: clock: Initialize d64 value

      ieee802154_shell: Only accept channels within expected range

      samples: mqtt_publisher: Try connecting a few times before giving up

      net: tcp: Limit number of segment retransmissions

      samples: dns_resolve: Clarify documentation about DNS configuration

 

Luiz Augusto von Dentz (3):

      net: shell: Move SHELL_REGISTER out of net_shell_init

      net: shell: Remove extra help command

      Bluetooth: GATT: Fix not queuing writes to CCC

 

Marti Bolivar (5):

      stack.h: add missing include guard

      lib: json: fix JSON_OBJ_DESCR_ARRAY Doxygen example

      tests: json: fix sense of test result string

      lib: json: add JSON_OBJ_DESCR_*_NAMED variants

      tests: json: test JSON_OBJ_DESCR_*_NAMED

 

Maureen Helm (1):

      arm: nxp: mpu: Return constant number of mpu regions

 

Michael Scott (3):

      arm: soc: nordic nRF52: Add MPU support

      arm: soc: nxp k6x: mpu: clarify magic numbers for UM/SM defines

      arm: soc: nxp k6x: mpu: add Bus Master 3 User Mode access bits

 

Patrik Flykt (1):

      zoap: Include net/net_ip.h when sockaddr is used

 

Paul Sokolovsky (6):

      subsys: console: Fix signed vs unsigned char issues.

      drivers/ethernet/eth_mcux: Fix extra PHY debug Kconfig name.

      tests: net: ipv6: Fix possible NULL pointer dereference behind a macro

      drivers/ethernet/eth_mcux: Fix selection of promisc mode IPv6 workaround

      drivers: serial: Clarification for uart_fifo_fill()/read() calls

      net: context: Operations on unused context should lead to EBADF.

 

Piotr Mienkowski (1):

      watchdog: atmel_sam: enable build for all SAM family

 

Ravi kumar Veeramally (2):

      net: rpl: Update RPL header

      net: 6lo: Fix source address uncompression

 

Sharron LIU (4):

      tests: kernel: added tests for timeslice reset

      tests: kernel: added tests for k_mem_pool_alloc from isr

      samples: fixed typo in README.rst

      samples: static_lib: conditional assign BOARD (?=)

 

Tomasz Bursztyka (1):

      api/spi: Change transceive functions signature

 

Vinayak Kariappa Chettimada (7):

      Bluetooth: controller: Fix DLE crossover assert

      Bluetooth: controller: Handle Rej Ext Ind for Length Req PDU

      Bluetooth: Auto-update LE data length to max. supported

      Bluetooth: controller: Fix CSA#2 assert

      Bluetooth: controller: Fix failing fast encryption setup feature

      drivers: timer: Fix nRF RTC timer _timer_cycle_get_32

      arch: arm: Fix compile error on ARMv6-M SoCs with TICKLESS_KERNEL

 

Vincenzo Frascino (1):

      arm: core: mpu: Add core support to NXP MPU

 

chunlin (1):

      arm: core: mpu: Prevent updating unexpected region

 

ruuddw (1):

      Create release-notes-1.8.rst

 

 

Thanks,

Anas


Re: sdk-ng

Nashif, Anas
 

Erwin,
The experience should be the same as with the current SDK. I did not say anything about downloading IDEs and from various vendors. There are well-established, standalone toolchains available that are better supported than what we have in the current SDK. Membership in the yocto project is really not a factor here. We are trying to keep things simple and remove the burden of having to maintain toolchains as part of the project. Believe it or not, the Zephyr SDK is also a one man show, yocto being a tool here that has nothing to do with the content of the SDK itself. And no, yocto does not give us an SDK on no Linux platforms and I am not sure what you mean with ptxdist... For the Zephyr developer just like with the current SDK it will be a downloadable file that installs some toolchains, in other cases it will download toolchains maintained by vendors like ARM, Intel and Synopsys etc.

Anas

-----Original Message-----
From: Erwin Rol [mailto:mailinglists@erwinrol.com]
Sent: Tuesday, June 13, 2017 9:44 PM
To: Nashif, Anas <anas.nashif@intel.com>; zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] sdk-ng

Hey Anas,

thanks for the explanation, I just wondered because Intel, Linaro, the Linux Foundation, etc. all seem Yocto members, where crosstools-ng seems to be pretty much a one-man-show (looking at the github commits).

On 14-6-2017 2:11, Nashif, Anas wrote:
The current SDK is very difficult to maintain, requires lots of
resources to build
And crosstools-ng is easier? Looking at ptxdist (which I already use for
years) there is still a lot of tuning needed. Same with RTEMS, they also seem to put a lot of effort in toolchain maintenance and tuning, especially integration with newlib.

And what about tools like openocd, they aren't part of crosstools-ng, are they?

and is not compatible with how crosstool compilers from vendors are
being distributed.
In what way "not compatible"? Aren't most vendors distributing some huge (eclipse)IDE with some GCC deep inside? (I am thinking about things like AC6, Atmel-Studio, etc.) Is there any "general" way to distribute a toolchain?

There are a few other issues, for
example it is only available on Linux, crosstools-ng gives us support
for the Mac as well.
Isn't Yocto capable to build SDK/toolchains that can run on Windows, Mac and Linux?

Another things is portability, try moving binaries around, this fails
with the current SDK.
That sounds a bit like a non-issue to me. Most big software packages can not be moved around. Of course others might have usecases where being able to move around the binaries is useful.

All in all, we are trying to
make it simpler and easier to maintain and we want to rely on vendor
toolchains rather than build everything ourselves in one giant blob
and then have to support it. We are not in the toolchain business, we
want to leave this to the experts and rely on recipes that are simple
that the way it is right now.
My experience is that those vendors are in the business of selling chips, and most software that comes from them is terrible. Look at the
AVR32 support from Atmel, they proudly present a GCC 4.4.X
(http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/)
in the form of patches that apparently no GCC developer wants to touch.

And from a user point of view, I thought it was very easy to download and install the Zephyr toolchains, and get to work with them. I would hate to have some readme.txt explaining to me I have to install 1 toolchain from Atmel, 1 from ST, 1 from Intel, all with different GUI installers (of course we want point-and-click) and all with their own huge (eclipse) IDE.

- Erwin


Re: sdk-ng

Erwin Rol
 

Hey Anas,

thanks for the explanation, I just wondered because Intel, Linaro, the
Linux Foundation, etc. all seem Yocto members, where crosstools-ng seems
to be pretty much a one-man-show (looking at the github commits).

On 14-6-2017 2:11, Nashif, Anas wrote:
The current SDK is very difficult to maintain, requires lots of
resources to build
And crosstools-ng is easier? Looking at ptxdist (which I already use for
years) there is still a lot of tuning needed. Same with RTEMS, they also
seem to put a lot of effort in toolchain maintenance and tuning,
especially integration with newlib.

And what about tools like openocd, they aren't part of crosstools-ng,
are they?

and is not compatible with how crosstool compilers
from vendors are being distributed.
In what way "not compatible"? Aren't most vendors distributing some huge
(eclipse)IDE with some GCC deep inside? (I am thinking about things like
AC6, Atmel-Studio, etc.) Is there any "general" way to distribute a
toolchain?

There are a few other issues, for
example it is only available on Linux, crosstools-ng gives us support
for the Mac as well.
Isn't Yocto capable to build SDK/toolchains that can run on Windows, Mac
and Linux?

Another things is portability, try moving binaries
around, this fails with the current SDK.
That sounds a bit like a non-issue to me. Most big software packages can
not be moved around. Of course others might have usecases where being
able to move around the binaries is useful.

All in all, we are trying to
make it simpler and easier to maintain and we want to rely on vendor
toolchains rather than build everything ourselves in one giant blob and
then have to support it. We are not in the toolchain business, we want
to leave this to the experts and rely on recipes that are simple that
the way it is right now.
My experience is that those vendors are in the business of selling
chips, and most software that comes from them is terrible. Look at the
AVR32 support from Atmel, they proudly present a GCC 4.4.X
(http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/)
in the form of patches that apparently no GCC developer wants to touch.

And from a user point of view, I thought it was very easy to download
and install the Zephyr toolchains, and get to work with them. I would
hate to have some readme.txt explaining to me I have to install 1
toolchain from Atmel, 1 from ST, 1 from Intel, all with different GUI
installers (of course we want point-and-click) and all with their own
huge (eclipse) IDE.

- Erwin


Re: sdk-ng

Nashif, Anas
 

The current SDK is very difficult to maintain, requires lots of resources to build and is not compatible with how crosstool compilers from vendors are being distributed. There are a few other issues, for example it is only available on Linux, crosstools-ng gives us support for the Mac as well. Another things is portability, try moving binaries around, this fails with the current SDK. All in all, we are trying to make it simpler and easier to maintain and we want to rely on vendor toolchains rather than build everything ourselves in one giant blob and then have to support it. We are not in the toolchain business, we want to leave this to the experts and rely on recipes that are simple that the way it is right now.

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Erwin Rol
Sent: Tuesday, June 13, 2017 7:21 PM
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] sdk-ng

Hey All,

when going over the 1.9 plans I noticed "sdk-ng".

When looking into the "sdk-ng" repo I noticed switching from yocto to crosstools-ng.

One question; why ?

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

5481 - 5500 of 8520