Date   

Re: ARMv8 Cortex-M TrustZone configuration

Kevin Townsend
 

Hi Johnny,

This doesn't use the LPC55S69-EVK at the moment -- it's based on a development board designed by ARM -- but it is relevant to your question and gives an initial example of TF-M in the secure processing environment (SPE) and Zephyr in the NSPE:


This PR in it's current state can't be merged since there are some CI issues to resolve (work ongoing there), but if you look at samples/tfm_integration you will find a basic example that documents how the image merge and signing process works for this setup.

If you're interested in getting involved with TF-M and Zephyr, any participation and contributions are of course always welcome, and I would suggest joining the Zephyr Slack where most of the adtive contributors are day to day. #general is a good place to start, but #memoryprotection may be of interest to you as well.

Best regards,
Kevin


On Tue, 6 Aug 2019 at 14:17, Johnny Daniels via Lists.Zephyrproject.Org <0x450=protonmail.ch@...> wrote:
Hello Zephyr devel universe,

I have an NXP LPC55S69-EVK development board. It is based on an ARMv8 Cortex-M CPU with the TrustZone extension. Zephyr officially supports this board.

I want to run Zephyr OS inside the Non-Secure World and have the Secure World free for other services.
Question 1: Is this possible with the current version of the Zephyr project?

If the answer to the above question is yes, then
Question 2: How to achieve this separation using Zephyr's build system? Can you point me to a documentation? I can see GitHub issues and KConfig parameters which suggest that this should theoretically be possible.

What I expect is something similar to:
- The Zephyr build system should produce 2 binaries (for the Secure and Non-Secure worlds respectively) and 1 shared library, which is statically linked to the Non-Secure binary (for the Non-Secure-Callable veneers).
- The Secure binary is the bootloader, the code which configures the TrustZone separation and then starts the Non-Secure kernel.
- The Non-Secure binary starts with the kernel initialisation and continues until the execution of the application threads.
- Executing `west flash` should be able to flash the Secure and Non-Secure binaries independently from one another.

Question 3: From the kernel developer's perspective: What do you guys expect from Zephyr's users? How should users configure the Secure/Non-Secure domains?

Regards,
Johnny


ARMv8 Cortex-M TrustZone configuration

Johnny Daniels
 

Hello Zephyr devel universe,

I have an NXP LPC55S69-EVK development board. It is based on an ARMv8 Cortex-M CPU with the TrustZone extension. Zephyr officially supports this board.

I want to run Zephyr OS inside the Non-Secure World and have the Secure World free for other services.
Question 1: Is this possible with the current version of the Zephyr project?

If the answer to the above question is yes, then
Question 2: How to achieve this separation using Zephyr's build system? Can you point me to a documentation? I can see GitHub issues and KConfig parameters which suggest that this should theoretically be possible.

What I expect is something similar to:
- The Zephyr build system should produce 2 binaries (for the Secure and Non-Secure worlds respectively) and 1 shared library, which is statically linked to the Non-Secure binary (for the Non-Secure-Callable veneers).
- The Secure binary is the bootloader, the code which configures the TrustZone separation and then starts the Non-Secure kernel.
- The Non-Secure binary starts with the kernel initialisation and continues until the execution of the application threads.
- Executing `west flash` should be able to flash the Secure and Non-Secure binaries independently from one another.

Question 3: From the kernel developer's perspective: What do you guys expect from Zephyr's users? How should users configure the Secure/Non-Secure domains?

Regards,
Johnny


Re: Why the smp version of zephyr kernel "idle" task implent the "k_busy_wait(100)" delay?

Andy Ross
 

FWIW: the reason for the busy wait is to reduce the number of calls to k_yield() which needs to enter the scheduler and obviously take a spinlock for synchronization.  If you have one CPU spinning on the scheduler lock, the other is going to constantly have to contend for it and you get a performance disaster.


FWIW: we have an IPI framework now.  This is straightforward to fix.


Andy


On 8/4/19 5:41 PM, Boie, Andrew P wrote:

There’s an open bug for this:

 

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

 

Andrew

 

From: devel@... <devel@...> On Behalf Of "???
Sent: Sunday, August 4, 2019 4:04 PM
To: devel <devel@...>
Subject: [Zephyr-devel] Why the smp version of zephyr kernel "idle" task implent the "k_busy_wait(100)" delay?

 

 

Hi everyone:

 

  whey the SMP version of zephyr kernel idle task has involke the "k_busy_wait"? and it is especially unreasonable to pass the delay time with 100.

why not 200, 300, 400..... and so on?

 

i cant very catch the comment with reason " to prevent the lock condentation"  if there are  lock condention exists, can the contention corner case be avoided just with a deay time??

i just cant understand the present implementation

thanks for your kindly help.

 

void idle(void *unused1, void *unused2, void *unused3)
{
    ARG_UNUSED(unused1);
    ARG_UNUSED(unused2);
    ARG_UNUSED(unused3);

 

 

    while (true) {
        k_busy_wait(100);
        k_yield();
    }

 

曹子

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 

 


Re: [EXT] [Zephyr-users] Zephyr SDK 0.10.2-rc1 available

Kumar Gala
 

Yeah, that’s merged now.

:)

- k

On Aug 5, 2019, at 4:01 AM, Andrei Gansari <andrei.gansari@nxp.com> wrote:

Will not work in current mainline, unless you apply https://github.com/zephyrproject-rtos/zephyr/pull/17984


Andrei Gansari

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On Behalf Of Kumar Gala via Lists.Zephyrproject.Org
Sent: Friday, August 2, 2019 6:36 PM
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>; zephyr-users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: [EXT] [Zephyr-users] Zephyr SDK 0.10.2-rc1 available

Caution: EXT Email

Hi,

Latest version of the SDK can be found here:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fsdk-ng%2Freleases%2Ftag%2Fv0.10.2-rc1&;data=02%7C01%7Candrei.gansari%40nxp.com%7C76dce26ca04a4a350c2108d7175f282f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637003569775968607&amp;sdata=XyPtEs%2BkmpQap%2FxD9M%2BGu5tHNKtCM11tpNN3IIISgls%3D&amp;reserved=0

Please download and try things out and report any issues.

Changes since the last release:

• Updated to QEMU 4.0.0
• Added aarch64 qemu target for use w/Cortex-R support (for xlnx-zcu102 target) • Updated openocd for bug fix on TI CC13x2/CC26x2 platforms.

- k


Re: Adafruit Feature nRF52 bit bang i2c

Benjamin Lindqvist
 

You need to add the bme280 to your device tree file. Something like:

&i2c0 {
        bme280@76 {
                compatible = "bosch,bme280";
                label = "BME280";
                reg = <0x76>;
        };
};


On Mon, Aug 5, 2019 at 3:04 PM Tomas McGuinness <tomasmcguinness@...> wrote:

Hello,

 

I’m quite new to Zephyr and I’m trying to connect a BME280 to an Adafruit Feature nRF52832. As the I2C device driver isn’t available on the Adafruit Feature nRF52832, I want to try and use the Big Bang approach. I’m using the latest build of Zephyr.

 

My prj.config includes these settings:

 

CONFIG_I2C=y

CONFIG_I2C_GPIO=y

 

CONFIG_SENSOR=y

CONFIG_BME280=y

 

When I try and build the project using west, I get

 

west build -b nrf52_adafruit_feather

 

In file included from C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c:24:

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.h:111:2: error: #error "BME280 device type not specified"

#error "BME280 device type not specified"

  ^~~~~

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c: In function 'bme280_init':

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c:357:22: warning: unused variable 'data' [-Wunused-variable]

  struct bme280_data *data = dev->driver_data;

                      ^~~~

In file included from C:/Development/zephyrproject/zephyr/include/drivers/sensor.h:23,

                 from C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c:11:

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c: At top level:

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c:385:29: error: 'DT_INST_0_BOSCH_BME280_LABEL' undeclared here (not in a function); did you mean 'DT_INST_0_SOC_NV_FLASH_LABEL'?

DEVICE_AND_API_INIT(bme280, DT_INST_0_BOSCH_BME280_LABEL, bme280_init, &bme280_data,

                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

C:/Development/zephyrproject/zephyr/include/device.h:107:11: note: in definition of macro 'DEVICE_AND_API_INIT'

   .name = drv_name, .init = (init_fn),     \

           ^~~~~~~~

[79/177] Building C object zephyr/drivers/i2c/CMakeFiles/drivers__i2c.dir/i2c_gpio.c.obj

C:/Development/zephyrproject/zephyr/drivers/i2c/i2c_gpio.c:94:12: warning: 'i2c_gpio_init' defined but not used [-Wunused-function]

static int i2c_gpio_init(struct device *dev)

            ^~~~~~~~~~~~~

C:/Development/zephyrproject/zephyr/drivers/i2c/i2c_gpio.c:89:30: warning: 'api' defined but not used [-Wunused-variable]

static struct i2c_driver_api api = {

                              ^~~

 

I know the Adafruit supports I2c (since it marks two pins for it). I also look at a look at the dts file for this board and can see an etry:

 

&i2c0 {

                sda-pin = <25>;

                scl-pin = <26>;

};

 

Is support for the i2c device a work in progress?

 

Any help would be appreciated.

 

Sent from Mail for Windows 10

 


Adafruit Feature nRF52 bit bang i2c

Tomas McGuinness <tomasmcguinness@...>
 

Hello,

 

I’m quite new to Zephyr and I’m trying to connect a BME280 to an Adafruit Feature nRF52832. As the I2C device driver isn’t available on the Adafruit Feature nRF52832, I want to try and use the Big Bang approach. I’m using the latest build of Zephyr.

 

My prj.config includes these settings:

 

CONFIG_I2C=y

CONFIG_I2C_GPIO=y

 

CONFIG_SENSOR=y

CONFIG_BME280=y

 

When I try and build the project using west, I get

 

west build -b nrf52_adafruit_feather

 

In file included from C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c:24:

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.h:111:2: error: #error "BME280 device type not specified"

#error "BME280 device type not specified"

  ^~~~~

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c: In function 'bme280_init':

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c:357:22: warning: unused variable 'data' [-Wunused-variable]

  struct bme280_data *data = dev->driver_data;

                      ^~~~

In file included from C:/Development/zephyrproject/zephyr/include/drivers/sensor.h:23,

                 from C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c:11:

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c: At top level:

C:/Development/zephyrproject/zephyr/drivers/sensor/bme280/bme280.c:385:29: error: 'DT_INST_0_BOSCH_BME280_LABEL' undeclared here (not in a function); did you mean 'DT_INST_0_SOC_NV_FLASH_LABEL'?

DEVICE_AND_API_INIT(bme280, DT_INST_0_BOSCH_BME280_LABEL, bme280_init, &bme280_data,

                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

C:/Development/zephyrproject/zephyr/include/device.h:107:11: note: in definition of macro 'DEVICE_AND_API_INIT'

   .name = drv_name, .init = (init_fn),     \

           ^~~~~~~~

[79/177] Building C object zephyr/drivers/i2c/CMakeFiles/drivers__i2c.dir/i2c_gpio.c.obj

C:/Development/zephyrproject/zephyr/drivers/i2c/i2c_gpio.c:94:12: warning: 'i2c_gpio_init' defined but not used [-Wunused-function]

static int i2c_gpio_init(struct device *dev)

            ^~~~~~~~~~~~~

C:/Development/zephyrproject/zephyr/drivers/i2c/i2c_gpio.c:89:30: warning: 'api' defined but not used [-Wunused-variable]

static struct i2c_driver_api api = {

                              ^~~

 

I know the Adafruit supports I2c (since it marks two pins for it). I also look at a look at the dts file for this board and can see an etry:

 

&i2c0 {

                sda-pin = <25>;

                scl-pin = <26>;

};

 

Is support for the i2c device a work in progress?

 

Any help would be appreciated.

 

Sent from Mail for Windows 10

 


Re: [EXT] [Zephyr-users] Zephyr SDK 0.10.2-rc1 available

Andrei Gansari
 

Will not work in current mainline, unless you apply https://github.com/zephyrproject-rtos/zephyr/pull/17984


Andrei Gansari

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On Behalf Of Kumar Gala via Lists.Zephyrproject.Org
Sent: Friday, August 2, 2019 6:36 PM
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>; zephyr-users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: [EXT] [Zephyr-users] Zephyr SDK 0.10.2-rc1 available

Caution: EXT Email

Hi,

Latest version of the SDK can be found here:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fsdk-ng%2Freleases%2Ftag%2Fv0.10.2-rc1&;data=02%7C01%7Candrei.gansari%40nxp.com%7C76dce26ca04a4a350c2108d7175f282f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637003569775968607&amp;sdata=XyPtEs%2BkmpQap%2FxD9M%2BGu5tHNKtCM11tpNN3IIISgls%3D&amp;reserved=0

Please download and try things out and report any issues.

Changes since the last release:

• Updated to QEMU 4.0.0
• Added aarch64 qemu target for use w/Cortex-R support (for xlnx-zcu102 target) • Updated openocd for bug fix on TI CC13x2/CC26x2 platforms.

- k


Re: Why the smp version of zephyr kernel "idle" task implent the "k_busy_wait(100)" delay?

Boie, Andrew P
 

There’s an open bug for this:

 

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

 

Andrew

 

From: devel@... <devel@...> On Behalf Of "???
Sent: Sunday, August 4, 2019 4:04 PM
To: devel <devel@...>
Subject: [Zephyr-devel] Why the smp version of zephyr kernel "idle" task implent the "k_busy_wait(100)" delay?

 

 

Hi everyone:

 

  whey the SMP version of zephyr kernel idle task has involke the "k_busy_wait"? and it is especially unreasonable to pass the delay time with 100.

why not 200, 300, 400..... and so on?

 

i cant very catch the comment with reason " to prevent the lock condentation"  if there are  lock condention exists, can the contention corner case be avoided just with a deay time??

i just cant understand the present implementation

thanks for your kindly help.

 

void idle(void *unused1, void *unused2, void *unused3)
{
    ARG_UNUSED(unused1);
    ARG_UNUSED(unused2);
    ARG_UNUSED(unused3);

 

 

    while (true) {
        k_busy_wait(100);
        k_yield();
    }

 

曹子

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 

 


Why the smp version of zephyr kernel "idle" task implent the "k_busy_wait(100)" delay?

"曹子龙
 


Hi everyone:

  whey the SMP version of zephyr kernel idle task has involke the "k_busy_wait"? and it is especially unreasonable to pass the delay time with 100.
why not 200, 300, 400..... and so on?

i cant very catch the comment with reason " to prevent the lock condentation"  if there are  lock condention exists, can the contention corner case be avoided just with a deay time??
i just cant understand the present implementation
thanks for your kindly help.

void idle(void *unused1, void *unused2, void *unused3)
{
    ARG_UNUSED(unused1);
    ARG_UNUSED(unused2);
    ARG_UNUSED(unused3);


    while (true) {
        k_busy_wait(100);
        k_yield();
    }

曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 



Request for comments: standard practice for driver-specific extensions

Peter A. Bigot
 

As discussed in TSC 2019-06-26 there is a need to provide access to extended capabilities when there’s an existing generic subsystem API (like GPIO or COUNTER), but a specific device has additional features that can’t be expressed.

Zephyr draft PR 17072 presents a technical solution using a stubbed real-world device. It now includes a documentation update with the technical details.

Zephyr issue 11993 provides some background.

Zephyr PR 17631 provides the complete ready-to-merge device implementation for an I2C-based high accuracy real-time clock that can be used as a 1 Hz counter.

In the devel review telecon 2019-08-01 we agreed to ask TSC to vote in the 2019-08-07 meeting (next week) on whether the approach described in 11072 is acceptable.

Please review and provide feedback on #17072 in preparation for that vote. If approved #17631 may be a candidate feature for v2.0.0.


Zephyr SDK 0.10.2-rc1 available

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.10.2-rc1

Please download and try things out and report any issues.

Changes since the last release:

• Updated to QEMU 4.0.0
• Added aarch64 qemu target for use w/Cortex-R support (for xlnx-zcu102 target)
• Updated openocd for bug fix on TI CC13x2/CC26x2 platforms.

- k


Is it possible to connect the device on internet using bluetooth connection?

christian tavares
 

Hello,

I am developing an application that connects my device via Bluetooth to my smartphone. I wonder if I can use my smartphone's internet connection on the device.

I am using nrf52840 board. I am running the example /samples/boads/nrf52/mesh/onoff-app.

If it is possible to connect the device on the internet using Bluetooth connection, how I can do that?



Upcoming Event: Zephyr Project: Dev Meeting - Thu, 08/01/2019 8:00am-9:00am, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 1 August 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


Dev Review Meeting Agenda - 1 Aug 2019

Kumar Gala
 

Here’s the issues/PRs on the agenda so far for this week’s Dev Review Meeting:

* drivers: counter: add Maxim DS3231 support:
https://github.com/zephyrproject-rtos/zephyr/pull/17631

* drivers/gpio: specify whether driver is ISR-safe:
https://github.com/zephyrproject-rtos/zephyr/pull/17827

* disk: fixing the sending of commands with r1 response:
https://github.com/zephyrproject-rtos/zephyr/pull/17700

* posix: Add headers related to BSD Sockets API
https://github.com/zephyrproject-rtos/zephyr/pull/16621

* [RFC] Proposed development plan for Zephyr's POSIX subsystem
https://github.com/zephyrproject-rtos/zephyr/issues/17706

- k


Re: Error in setup zephyr toolchain

rahul tiwari
 

Hi supriti,
I think you are missing to set environment variable 

Best Regards 
Rahul



On Thu, Aug 1, 2019, 8:20 AM Supriti Shukla <supriti@...> wrote:

Hello ,

I am facing trouble while setting up the toolchain into my system.

While running cmake command for nrf52
I have encountered an error 

"Are permission set correctly ?"
for below command
/zehyr/<somewhere in toolchain>arm-none-eabi/arm-none-eabi-gcc -- version

Something like that.
I have tried using several option for chmod +x , chmod 400 etc.

Do help me out from this error.

Regards,
Supriti Anju Shukla


Error in setup zephyr toolchain

Supriti Shukla <supriti@...>
 


Hello ,

I am facing trouble while setting up the toolchain into my system.

While running cmake command for nrf52
I have encountered an error 

"Are permission set correctly ?"
for below command
/zehyr/<somewhere in toolchain>arm-none-eabi/arm-none-eabi-gcc -- version

Something like that.
I have tried using several option for chmod +x , chmod 400 etc.

Do help me out from this error.

Regards,
Supriti Anju Shukla


Re: shipable ...

Kumar Gala
 

On Jul 30, 2019, at 10:36 PM, Nicolas Pitre <npitre@baylibre.com> wrote:

... or the reason why I wish I could smash my keyboard with a 12-foot H-beam.

Accessibility wise, this shipable web interface thingy is a complete
abomination. Every of my attempts to get to test failure logs ended up
in a failure of its own. And recursive failure is not good.

Is there a way to bypass the web UI?

I found http://docs.shippable.com/ci/email-notifications/ which looked
promising. But that affects the entire project for everybody. All I want
is access to failure reports for my own commits without the dreaded web
UI.

Any help would be greatly appreciated!
No sure, but probably can ask on https://github.com/Shippable/support

- k


Re: Why is 'Sensor' a Peripheral in the API Reference?

Jennifer M Williams
 

@Andy Ross Thanks for the perspective. This is interesting. It does currently live under \zephyr\drivers with i2c, spi, gpio, etc. and is developed following a general driver API.

 

Also, the Zephyr Project API Reference is misleading…

“The sensor subsystem exposes an API to uniformly access sensor devices.”

https://docs.zephyrproject.org/latest/reference/peripherals/sensor.html

 

From: devel@... <devel@...> On Behalf Of Andy Ross
Sent: Wednesday, July 31, 2019 9:24 AM
To: Williams, Jennifer M <jennifer.m.williams@...>; devel@...
Subject: Re: [Zephyr-devel] Why is 'Sensor' a Peripheral in the API Reference?

 

Inertia, probably, and maybe a lack of somewhere better to put them.  Properly "sensors" are an abstract subsystem and the related peripherals would be things like "accelerometers", "gyroscopes", "thermometers", etc...  But we don't really have a heading for "device type subsystem", and pulling these up a level would put "sensors" next to stuff like "power management" where it really doesn't belong.

There's also the problem that while we have a sensor framework abstraction, we, er, kinda lack a lot of actual sensor drivers to use it.

Personally I don't think this is awful, but some reorganization certainly couldn't hurt.

Andy

 

On 7/29/19 2:53 PM, Jennifer M Williams wrote:

Hi all,

 

What is the rationale for ‘Sensors’ being under ‘Peripherals’ in the API Reference with the ADC, Counter, I2C, SPI, etc.?  Is it because the Peripheral APIs are for hardware-related interface?

 

Thanks,

Jen


Re: Why is 'Sensor' a Peripheral in the API Reference?

Andy Ross
 

Inertia, probably, and maybe a lack of somewhere better to put them.  Properly "sensors" are an abstract subsystem and the related peripherals would be things like "accelerometers", "gyroscopes", "thermometers", etc...  But we don't really have a heading for "device type subsystem", and pulling these up a level would put "sensors" next to stuff like "power management" where it really doesn't belong.

There's also the problem that while we have a sensor framework abstraction, we, er, kinda lack a lot of actual sensor drivers to use it.

Personally I don't think this is awful, but some reorganization certainly couldn't hurt.

Andy


On 7/29/19 2:53 PM, Jennifer M Williams wrote:

Hi all,

 

What is the rationale for ‘Sensors’ being under ‘Peripherals’ in the API Reference with the ADC, Counter, I2C, SPI, etc.?  Is it because the Peripheral APIs are for hardware-related interface?

 

Thanks,

Jen


VB: Zephyr 2.0 Release - final reminder

Glaropoulos, Ioannis
 

Hello Zephyr developers!

 

This is a (final) polite reminder that the merge window for Zephyr 2.0 release will close on Friday August 9th.

 

If you are currently working on features for the 2.0 release, please:

  • mind that the respective pull-requests should be soon up for review, so there is sufficient time to get them reviewed, revised, and merged to master before August 9th.
  • open Github issues for those features (if they do not already exist) and tag them with the 2.0 milestone.

 

An overview of what is currently open and scheduled for 2.0 can be found here: https://github.com/zephyrproject-rtos/zephyr/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+milestone%3Av2.0.0++-label%3Abug

 

After feature freeze only bug-fixes, documentation and stabilization-related updates may be merged; the merge window will remain closed until the release date.

 

Thanks,

Ioannis Glaropoulos

 

 

Från: Glaropoulos, Ioannis
Skickat: den 19 juli 2019 14:24
Till: 'devel@...' <devel@...>
Ämne: VB: Zephyr 2.0 Release - important information & dates

 

Hi Zephyr developers!

 

Polite reminder that the merge window for the Zephyr 2.0 release will remain open for three weeks more, until Friday August 9th.  Any new features or enhancements to be included in the Zephyr 2.0 release must be pushed to master by the feature freeze deadline. If you are working on such features, please, submit your pull-requests in good time, to have them properly reviewed, revised and merged before August 9.

 

Thanks!

 

Ioannis Glaropoulos

 

Från: Glaropoulos, Ioannis
Skickat: den 27 juni 2019 17:26
Till: devel@...
Ämne: Zephyr 2.0 Release - important information & dates

 

Hi Zephyr developers,

 

The next major Zephyr release, 2.0, is scheduled for Friday, 30 August 2019.

 

We are now in the development phase for 2.0; merge window is open for all features until feature freeze, which is scheduled for Friday 9 August, 2019. This is in 6 weeks from today. Major features should, ideally, be up for review by mid-July 2019.

 

Any new features / enhancements to be included in the Zephyr 2.0 release must be pushed to master by the feature freeze deadline. If you are working on such features / enhancements, please, submit your pull-requests in good time, to have them properly reviewed, revised and merged before August 9.

 

After feature freeze only bug-fixes, documentation and stabilization-related updates may be merged; the merge window will remain closed until the release date.

 

 

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

 

Roadmap: https://github.com/zephyrproject-rtos/zephyr/projects/9

 

Thanks in advance for all your contributions!

 

Ioannis Glaropoulos

1781 - 1800 of 7924