Date   

Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 3
[ZEP-538] (Fixed) doc: missing steps to boot up Galileo Gen 2 with a USB flash drive
https://jira.zephyrproject.org/browse/ZEP-538

[ZEP-218] (Fixed) [drivers/nble][PTS_TEST] Fix responding with the wrong error codes to the Prepare Write Request
https://jira.zephyrproject.org/browse/ZEP-218

[ZEP-221] (Fixed) [drivers/nble][PTS_TEST] Implement Execute Write Request handler
https://jira.zephyrproject.org/browse/ZEP-221


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4081 : fix doxygen error doc: Update Power Management device driver API 1. Have one function that can be used for all possible device PM purposes using a control code instead of the suspend resume functions. 2. Add the below device power states: Note: Many devic

MERGED within last 24 hours:


Re: [RFC] Power Management Infrastructure

Kaplan, Amir
 

Hi all,

I did Abandon to all the below patches and will deliver again as one big change (please note: all the drivers changes are quite similar) .


Thanks,
Amir Kaplan

-----Original Message-----
From: Kaplan, Amir
Sent: Thursday, August 18, 2016 12:04
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>; Kidron, Amihai <amihai.kidron(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi,
Following Ramesh and Ku-Lang's feedbacks we have split the changes to multiple small patches(instead of the original delivery).

Note: Due to the fact that the drivers changes depends on the change in device.h only the last delivery(https://gerrit.zephyrproject.org/r/#/c/4161/) passes all required verifications in Jenkins.

Below are the updated deliveries:
Device API:
https://gerrit.zephyrproject.org/r/#/c/4142/

gpio:
https://gerrit.zephyrproject.org/r/#/c/4143/

interrupt_controler:
https://gerrit.zephyrproject.org/r/#/c/4145/

pwm:
https://gerrit.zephyrproject.org/r/#/c/4147/

rtc:
https://gerrit.zephyrproject.org/r/#/c/4148/

uart:
https://gerrit.zephyrproject.org/r/#/c/4149/

spi:
https://gerrit.zephyrproject.org/r/#/c/4150/

timer:
https://gerrit.zephyrproject.org/r/#/c/4159/

samples:
https://gerrit.zephyrproject.org/r/#/c/4161/

Regards,
Amir & Keren

-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 13:36
To: devel(a)lists.zephyrproject.org
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,

The corresponding Gerrit link:
https://gerrit.zephyrproject.org/r/4081


-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 11:18
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kaplan, Amir <amir.kaplan(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,
After reviewing all the comments and consulting Ramesh, below is the updated RFC:

Current state
===========

In the current Zephyr implementation the driver power hooks distinguish only between two driver states (suspend and resume). Drivers may have more than two states (i.e. D-states) and can traverse between those states. The state change today is limited only from active to suspend while there can be cases of other transitions requested by the application.
Please look at the below suggested device power states E.g. transition between DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an application or a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {
int (*suspend)(struct device *device, int pm_policy);
int (*resume)(struct device *device, int pm_policy); };

Proposed changes
===============

1. Have one function that can be used for all possible device PM purposes using a control code instead of the suspend resume functions:

int (*device_pm_control)(struct device *device, int pm_command, int device_power_state);

In first version will support DEVICE_SET_POWER_STATE and DEVICE_GET_POWER_STATE commands.

2. Add the below device power states:
Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE
--------------------------------------------
Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE
-------------------------------------------------------
Device context is preserved by the HW and need not be restored by the driver.
The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE
------------------------------------------------
Most device context is lost by the hardware.
Device drivers must save and restore or reinitialize any context lost by the hardware.
The device can be powered down.
The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE
---------------------------------------
Power has been fully removed from the device. The device context is lost when this state is entered, so the OS software will reinitialize the device when powering it back on.
Device may not wake itself as the SoC need to reinitialize the device.

3. The set state functionality (via device_pm_control ) will behave according to the state transition of a specific driver. E.g. transition from active state to suspend state in a UART device will save device states and gate the clock.
The set state functionality (via device_pm_control ) will enable the Power Manager service to know the state of a driver if needed thus enable it to configure the SoC power behavior.

The advantages in the new method:
1. Active device PM that does not need system to go idle to do device PM. Any component can call it. Multiple PM states and transitions need not always between active and low power states.
2. Reduces memory use and complexity because now there is only one function.
3. Compatible with legacy suspend/resume done from central PMA during idle 4. Scalable- In future more control codes can be added to support other device pm operations without having to change infrastructure.

Regards,
Amir, Keren, Hezi

-----Original Message-----
From: Rahamim, Hezi
Sent: Wednesday, August 10, 2016 10:18
To: Kaplan, Amir <amir.kaplan(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>
Subject: FW: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



-----Original Message-----
From: Thomas, Ramesh
Sent: Friday, July 15, 2016 06:22
To: Rahamim, Hezi <hezi.rahamim(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



On 07/14/2016 06:17 AM, Rahamim, Hezi wrote:
Hi Ramesh'

Please see my comments below.

Regards,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Thursday, July 14, 2016 10:32
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: [RFC] Power Management
Infrastructure

On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the device policies.
That made me think why we originally came up with 2 functions when one was enough. Probably we thought the same way - to keep symmetry. Problem is that we will keep getting more needs and we will either add more functions to device_pm_ops or will have to change existing ones.

How about having one function that can be used for all possible device
PM purposes using a control code? Something like following :-

int device_pm_control(device, flags);

flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)

CONTROL_CODE = {SET_POWER_STATE, GET_POWER_STATE, ...}
DEVICE_POWER_STATE = {device PM states} SYSTEM_POWER_STATE = {system
power policies}

(We can add additional parameters if flags param is overloaded)

returns value based on CONTROL_CODE
e.g. returns device power state if CONTROL_CODE == GET_POWER_STATE

(We probably don't need device_pm_ops if we have only one function.)

[HR] Looks good. If the PM service will be designed as a driver than it can use the SYSTEM_POWER_STATE and a device driver will use the DEVICE_POWER_STATE.


***I also have some questions inline below***



Thanks for the comment,
Hezi

-----Original Message-----
From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
Sent: Thursday, July 14, 2016 00:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: [RFC] Power Management Infrastructure

Hi Hezi,
I think RFC needs to be extended with the description of the idea of controlling power state of each device (if I got you correctly).
Without it the need of
int (*get_state)(struct device *device, int device_pm_policy); looks very unclear.
If all you need is to provide more that two states, then set_state() looks quite enough.

Regards,

Dmitriy Korovkin

On 16-07-13 12:11 PM, Rahamim, Hezi wrote:
Hi Ramesh,

Please see my comments below/

Thanks for the comments,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Wednesday, July 13, 2016 09:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Power Management Infrastructure

On 7/12/2016 2:03 AM, Rahamim, Hezi wrote:
Hi all,

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

between two driver states (suspend and resume). Drivers may have
more than two
Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition is happening.


states (i.e. D-states) and can traverse between those states. The
state change

today is limited only from active to suspend while there can be
cases of other

transitions requested by the application.

Please look at the below suggested device power states E.g.
transition between

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an
application or

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

int (*suspend)(struct device *device, int pm_policy);

int (*resume)(struct device *device, int pm_policy);

};

Proposed changes

===============

First proposed change is to have a set state and get state driver
functions

instead of the suspend resume functions:

struct device_pm_ops {

int (*set_state)(struct device *device, int
device_pm_policy);

int (*get_state)(struct device *device, int
device_pm_policy);

};

The set_state function will behave according to the state
transition of a specific

driver. E.g. transition from active state to suspend state in a
UART device will

save device states and gate the clock.
The proposal, as I understand, is to use the pm hooks to actively
control the power states instead of using them as just notifications
of the SOC's power transitions. Considering this, we had one power
policy called "device_suspend_only". That is open to be broken down
into more device specific power states.

[HR] You are correct, we intend to use the pm driver hooks to
actively control the device Power states. We will use the Zephyer's
current power policies to indicate the system power state. As you
mentioned, when devices will not be in active state the system can still be at "device_suspend_only" state.
Do you see any issues with the apps/drivers keeping the PM service updated of the device's current state in real time? What about race conditions? Complexity of communication framework?
[HR] The need of communication framework and device state database
lock may be needed. For example, inter processor communication may be
needed if in a specific SoC there are shared power resources between
two cores (in AtP3 we may avoid that...)



The get_state function will enable the Power Manager service to
know the state

of each driver thus enable it to configure the SoC power behavior.
The set_state function looks ok. It is the same as the current
suspend but with the name change. The purpose of the name change is
to add a corresponding get_state. The RFC is not giving much
details of the use of the get_state function.

I assume there is a need for the PM service to build a device tree,
with power hierarchy. It would be helpful if you could explain how
this function fits in your larger design of the PM service's power
policy management of the devices.

[HR] I will give an example:
A user application decides to suspend the I2C and the SPI devices.
The application will then call the corresponding set_state functions of these devices.
The set_state functions will perform the store of the relevant
device state and gate the device clock. In the next idle time the _sys_soc_suspend will be called.
This will trigger the power manager service which will decide what
should be done to optimize the power (clock gate a branch or change the system power state.
The decision of the power manager service will be based on the
devices states which can be obtained also by using the get_state functions.

Since the PM service is expected to have communication established
with all components in the system, wouldn't it know what state each
device is set to? Querying each device and building a tree every
time there is an opportunity to suspend, may take some time causing delay in suspend.

[HR] You are correct, using the get_state function will lead to a
less optimal Power manager service and it will need to use a more optimized method.
However, it is a good practice to have this function as the
application may want to query the device state.

Second proposed change is to add the below device power states:

Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE

--------------------------------------------

Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE

-------------------------------------------------------

Device context is preserved by the HW and need not be restored by
the driver.

The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE

------------------------------------------------

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context
lost

by the hardware.

The device can be powered down.

The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE

---------------------------------------

Power has been fully removed from the device. The device context is
lost

when this state is entered, so the OS software will reinitialize
the device

when powering it back on.

Device may not wake itself as the SoC need to reinitialize the device.
The description of the power states here sounds like they are
notifications. It sounds like some other component is setting the
power state and notifies using these values and the drivers do
save/restore or other operations based on the notification. Are the
drivers expected to gate clocks, turn off peripherals etc. in these notifications?

[HR] These device power states serve two purposes:
1. The drivers are expected to perform all the power/clock changes
It can perform according to the selected power state and do not
influence other drivers.
2. The power manager service will use the drivers states to decide
on system power policy to go to (it can also stay in
SYS_PM_DEVICE_SUSPEND_ONLY but to optimize the clock gating scheme)
Would these become part of a specification that all device drivers would need to implement? In this scheme, the PM responsibilities are shared between PM Service, various apps and drivers. So some plan needs to be in place to ensure all of them cooperate as expected.
[HR] You are right, there is a need to define the PM responsibilities of the PM service, drivers and apps. However, this RFC was written to add the ability to support more than two device states, define the available states and to enable transition between them.
We will be happy to contribute also to define the above.
The device PM states look ok to me. They are architecture independent and the drivers can map them to device specific operations.

I think this RFC should be part of other RFCs that define the bigger picture of how it is used. As I see it, the kind of device PM you propose can function independent of system idle. In my opinion, it would be good to define it independent of system power management. The 2 will coordinate, but should not be a requirement. That way, either infrastructure can be used independently by users. Also there would be implementations that would want to do all device PM in the PM service for various reasons.



The initial part of the RFC does mention the application can set the
power state of the device and that is what the proposed set_state
function also suggests.

Do they serve both purposes? May be an example of how the device's
power state is actively changed and who and when does it, with
respect to these notifications, would help.

[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
Will the PM service also put devices to suspend state, or only the apps will do it? Looks like the PM Service will never enter Deep Sleep if any device is on - any exceptions?
[HR] Only apps will do that. The PM service can decide in some cases to go to deep sleep even if specific device is active (e.g. the device is located in the always on power domain). The decision to change power state is SoC specific.

In the above example, the system had to go to idle for the PLL to get turned off. If you had a central scheme to turn off clocks then the PLL could have been turned off when both i2c and spi got turned off. Just an observation.
[HR] There are indeed several ways to solve this and there will be a need to choose the best one for the specific SoC.

Comments/concerns welcome.

Thanks,

Hezi

-------------------------------------------------------------------
-
- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material
for the sole use of the intended recipient(s). Any review or
distribution by others is strictly prohibited. If you are not the
intended recipient, please contact the sender and delete all copies.
--------------------------------------------------------------------
- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material
for the sole use of the intended recipient(s). Any review or
distribution by others is strictly prohibited. If you are not the
intended recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-724] build on windows failed: 'make: execvp: uname: File or path name too long'
https://jira.zephyrproject.org/browse/ZEP-724

[ZEP-725] CI tag build is not sending emails
https://jira.zephyrproject.org/browse/ZEP-725


UPDATED JIRA items within last 24 hours: 9
[ZEP-546] UART interrupts not triggered on ARC
https://jira.zephyrproject.org/browse/ZEP-546

[ZEP-616] OS X setup instructions not working on El Capitan
https://jira.zephyrproject.org/browse/ZEP-616

[ZEP-172] tests/kernel/test_task_priv/test FAILED in QEMU
https://jira.zephyrproject.org/browse/ZEP-172

[ZEP-669] MQTT fail to pingreq if broker deliver topic to client but client doesn't read it.
https://jira.zephyrproject.org/browse/ZEP-669

[ZEP-697] samples/net/test_15_4 cannot be built by sanitycheck
https://jira.zephyrproject.org/browse/ZEP-697

[ZEP-632] MQTT fail to re-connect to the broker.
https://jira.zephyrproject.org/browse/ZEP-632

[ZEP-145] no 'make flash' for Arduino Due
https://jira.zephyrproject.org/browse/ZEP-145

[ZEP-639] device_pm_ops structure should be defined as static
https://jira.zephyrproject.org/browse/ZEP-639

[ZEP-528] ARC has 2 almost identical copies of the linker script
https://jira.zephyrproject.org/browse/ZEP-528


CLOSED JIRA items within last 24 hours: 39
[ZEP-242] (Fixed) Collaboration Guidelines Restructure
https://jira.zephyrproject.org/browse/ZEP-242

[ZEP-270] (Fixed) nios2: determine optimal value for PERFOPT_ALIGN
https://jira.zephyrproject.org/browse/ZEP-270

[ZEP-643] (Fixed) Add file system API documentation
https://jira.zephyrproject.org/browse/ZEP-643

[ZEP-590] (Fixed) Update Zephyr's tinycrypt to version 2.0
https://jira.zephyrproject.org/browse/ZEP-590

[ZEP-621] (Fixed) samples/static_lib: fatal error: stdio.h: No such file or directory
https://jira.zephyrproject.org/browse/ZEP-621

[ZEP-617] (Fixed) MQTT samples build fail because netz.h file missing.
https://jira.zephyrproject.org/browse/ZEP-617

[ZEP-575] (Fixed) Ethernet/IPv4/UDP: ip_buf_appdatalen returns wrong values
https://jira.zephyrproject.org/browse/ZEP-575

[ZEP-460] (Fixed) doc: document parameters of DEVICE* macros
https://jira.zephyrproject.org/browse/ZEP-460

[ZEP-469] (Fixed) Ethernet/IPv4/TCP: net_receive & net_reply in server mode
https://jira.zephyrproject.org/browse/ZEP-469

[ZEP-463] (Fixed) Getting started guide "next" link doesn't take you to "Checking Out the Source Code Anonymously" section
https://jira.zephyrproject.org/browse/ZEP-463

[ZEP-646] (Fixed) I2C fail to read GY2561 sensor when GY2561 & GY271 sensor are attached to I2C bus.
https://jira.zephyrproject.org/browse/ZEP-646

[ZEP-623] (Fixed) MQTT sample mqtt.h missing "mqtt_unsubscribe" function
https://jira.zephyrproject.org/browse/ZEP-623

[ZEP-647] (Fixed) Power management state storage should use GPS1 instead of GPS0
https://jira.zephyrproject.org/browse/ZEP-647

[ZEP-645] (Fixed) ARC QMSI ADC shim driver fails to read sample data
https://jira.zephyrproject.org/browse/ZEP-645

[ZEP-595] (Fixed) UART: usb simulated uart doesn't work in poll mode
https://jira.zephyrproject.org/browse/ZEP-595

[ZEP-572] (Fixed) X86 kernel BAT failed: Kernel Allocation Failure!
https://jira.zephyrproject.org/browse/ZEP-572

[ZEP-581] (Fixed) test_sha256 fails on Nios II if CONFIG_DEBUG=y
https://jira.zephyrproject.org/browse/ZEP-581

[ZEP-571] (Fixed) ARC kernel BAT failed due to race in nested interrupts
https://jira.zephyrproject.org/browse/ZEP-571

[ZEP-526] (Fixed) build "kernel event logger" sample app failed for BOARD=quark_d2000_crb
https://jira.zephyrproject.org/browse/ZEP-526

[ZEP-523] (Fixed) FIFOs defined by DEFINE_FIFO macro use the same memory buffer
https://jira.zephyrproject.org/browse/ZEP-523

[ZEP-537] (Fixed) doc: create external wiki page "Maintainers"
https://jira.zephyrproject.org/browse/ZEP-537

[ZEP-547] (Fixed) [nble] Failed to start encryption after reconnection
https://jira.zephyrproject.org/browse/ZEP-547

[ZEP-514] (Fixed) memory corruption in microkernel memory pool defrag()
https://jira.zephyrproject.org/browse/ZEP-514

[ZEP-518] (Fixed) SPI not working on Arduino101
https://jira.zephyrproject.org/browse/ZEP-518

[ZEP-499] (Fixed) TMP007 driver returns invalid values for negative temperature
https://jira.zephyrproject.org/browse/ZEP-499

[ZEP-474] (Fixed) ND: Neighbor cache is not getting cleared
https://jira.zephyrproject.org/browse/ZEP-474

[ZEP-435] (Fixed) Ethernet/IPv4/TCP: ip_buf_appdatalen returns wrong values
https://jira.zephyrproject.org/browse/ZEP-435

[ZEP-428] (Won't Do) Ethernet/IPv4/TCP net_send error
https://jira.zephyrproject.org/browse/ZEP-428

[ZEP-681] (Fixed) MQTT client sample throws too many warnings when build.
https://jira.zephyrproject.org/browse/ZEP-681

[ZEP-673] (Fixed) Sanity crashes and doesn't kill qemu upon timeout
https://jira.zephyrproject.org/browse/ZEP-673

[ZEP-679] (Fixed) HMC5883L I2C Register Read Order
https://jira.zephyrproject.org/browse/ZEP-679

[ZEP-556] (Fixed) System hangs during I2C transfer
https://jira.zephyrproject.org/browse/ZEP-556

[ZEP-545] (Fixed) Wrong default value of CONFIG_ADC_QMSI_SAMPLE_WIDTH for x86 QMSI ADC
https://jira.zephyrproject.org/browse/ZEP-545

[ZEP-457] (Fixed) doc: contribute/doxygen/typedefs.rst: examples files are broken
https://jira.zephyrproject.org/browse/ZEP-457

[ZEP-475] (Fixed) Issue with timer callback routine: Condition checked is incorrect
https://jira.zephyrproject.org/browse/ZEP-475

[ZEP-459] (Fixed) doc: kconfig reference entries in HTML are lacking a title
https://jira.zephyrproject.org/browse/ZEP-459

[ZEP-456] (Fixed) doc: `IDT security` section dissapeared
https://jira.zephyrproject.org/browse/ZEP-456

[ZEP-379] (Fixed) _k_command_stack may be improperly initialized when debugging
https://jira.zephyrproject.org/browse/ZEP-379

[ZEP-180] (Fixed) make menuconfig user provided options are ignored at building time
https://jira.zephyrproject.org/browse/ZEP-180


RESOLVED JIRA items within last 24 hours: 12
[ZEP-55] (Fixed) enable nanokernel test_context on ARC
https://jira.zephyrproject.org/browse/ZEP-55

[ZEP-704] (Fixed) test_atomic does not complete on ARC
https://jira.zephyrproject.org/browse/ZEP-704

[ZEP-461] (Fixed) Release 1.4.0 has broken the BMI160 sample as well as an application based on it
https://jira.zephyrproject.org/browse/ZEP-461

[ZEP-612] (Won't Do) Need to send a dummy packet to establish connection using the TCP/IP stack
https://jira.zephyrproject.org/browse/ZEP-612

[ZEP-369] (Fixed) When building out of the tree, application object files are not placed into outdir
https://jira.zephyrproject.org/browse/ZEP-369

[ZEP-455] (Won't Do) Sensor DHT11/DHT22 Fails to perform repetitive sampling with Zephyr
https://jira.zephyrproject.org/browse/ZEP-455

[ZEP-384] (Fixed) D2000 hangs after I2C communication with BMC150 sensor
https://jira.zephyrproject.org/browse/ZEP-384

[ZEP-534] (Fixed) Scan for consistent use of "platform/board/SoC" in documentation
https://jira.zephyrproject.org/browse/ZEP-534

[ZEP-598] (Fixed) CoAP Link format filtering is not supported
https://jira.zephyrproject.org/browse/ZEP-598

[ZEP-695] (Fixed) FatFs doesn't compile using Newlib
https://jira.zephyrproject.org/browse/ZEP-695

[ZEP-68] (Fixed) Final image contains duplicates of some routines
https://jira.zephyrproject.org/browse/ZEP-68

[ZEP-423] (Fixed) Quark D2000 CRB documentation should include instructions to flash bootloader
https://jira.zephyrproject.org/browse/ZEP-423


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4205 : recipes-devtools/gcc: newlib-stdint.h: Remove 32 bit longs
- https://gerrit.zephyrproject.org/r/4210 : grub: Tweak build_grub.sh for proxy issues
- https://gerrit.zephyrproject.org/r/4209 : makefile: use shell to run mkdir command
- https://gerrit.zephyrproject.org/r/4207 : printk: print leading '0x' for %p
- https://gerrit.zephyrproject.org/r/4206 : libc: minimal: add reduced inttypes.h

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include Controller by default in board nrf52_pca10040
- https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic Link Layer implementation
- https://gerrit.zephyrproject.org/r/4088 : Bluetooth: Controller: Initial impl. of a HCI controller-side interface
- https://gerrit.zephyrproject.org/r/4090 : Bluetooth: Controller: Add driver that glues Link Layer with the BLE stack
- https://gerrit.zephyrproject.org/r/4087 : Bluetooth: Controller: Add a util folder with basic primitives
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- https://gerrit.zephyrproject.org/r/4168 : net: samples: Add a simple Qemu sample for testing off-line 802.15.4
- https://gerrit.zephyrproject.org/r/4166 : samples: net: Moving the current ieee802154 sample
- https://gerrit.zephyrproject.org/r/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/4167 : samples: net: Qemu make utilities update
- https://gerrit.zephyrproject.org/r/4190 : printk: warn on incorrect printf-style usage
- https://gerrit.zephyrproject.org/r/4181 : samples: fat_fs: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4188 : samples: i2c_fujitsu_fram: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4187 : drivers: pci: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4185 : drivers: ipm_console: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4184 : drivers: console_handler_shell: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4183 : samples: zperf: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4182 : samples: ipm: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4180 : arc: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4179 : nios2: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4178 : arm: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4177 : net: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4176 : tests: benchmark: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4175 : tests: bluetooth: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4174 : tests: net: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4173 : tests: kernel: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4172 : tests: crypto: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4171 : tests: test_printk: crude printk test case
- https://gerrit.zephyrproject.org/r/4170 : printk: make _char_out globally accessible
- https://gerrit.zephyrproject.org/r/4169 : printk: "support" some modifier codes
- https://gerrit.zephyrproject.org/r/4186 : x86: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4201 : net: samples: Fix the echo-server IPv6 address
- https://gerrit.zephyrproject.org/r/4199 : net: Clarify the CONFIG_NET_TESTING setting
- https://gerrit.zephyrproject.org/r/4197 : Bluetooth: AVDTP: Module intialization
- https://gerrit.zephyrproject.org/r/4105 : sanity: enable sanity multiple configuration
- https://gerrit.zephyrproject.org/r/4202 : net: ip: Fix compiling with 15.4

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4208 : verify: add retry to avoid fail a build due to gerrit connection
- https://gerrit.zephyrproject.org/r/4158 : Bluetooth: shell: Add support for RFCOMM test
- https://gerrit.zephyrproject.org/r/4157 : Bluetooth: RFCOMM: Handle incoming dlc request
- https://gerrit.zephyrproject.org/r/4156 : Bluetooth: RFCOMM: Handle PN request
- https://gerrit.zephyrproject.org/r/4155 : Bluetooth: RFCOMM: Handle signalling connection request


Re: QEMU networking: CONFIG_NET_TESTING breaks things, echo_server IPv6 address is "wrong"

Paul Sokolovsky
 

Hello Jukka,

On Fri, 19 Aug 2016 14:37:10 +0300
Jukka Rissanen <jukka.rissanen(a)linux.intel.com> wrote:

[]


I can prepare proper patches for these unless you have already
something prepared in which case just send them to gerrit. Thanks
for you feedback!
Patches for these items can be now found in
https://gerrit.zephyrproject.org/r/#/c/4199/
Thanks for proceeding with these, I didn't have anything on my side,
nor think I know enough of Z networking to prepare changes which would
blend well, so thanks for going forward on your side. I'll have a look
at them today/on Monday.

Cheers,
Jukka


--
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 v1.5.0-rc3 tagged

Boie, Andrew P
 

Hello All,

New RC tagged. Thanks to everyone for your contributions!

Anas Nashif (1):
MAINTAINERS: add ARM and ARC architecture maintainers

Andrew Boie (19):
samples: hello_world: build for sanitycheck runs
samples: stub: build for sanitycheck runs
samples: shell: build for sanitycheck runs
samples: environmental_sensing: build for sanitycheck runs
samples: power: quark_se: build for sanitycheck runs
samples: net: loopback_test: build for sanitycheck runs
samples: net: zperf: build for sanitycheck runs
samples: pci_enum: build for sanitycheck
samples: magn_polling: build for sanitycheck
samples: sx9500: build for sanitycheck
samples: tmp112: build for sanitycheck
samples: bme280: build for sanitycheck runs
samples: mcp9808: build for sanitycheck runs
fat_fs: zfs_diskio: use same typedefs in header
ipm_console_receiver: correctly populate driver data
ipm_console: rate-limit to avoid losing messages
Revert "REVERTME exclude test_sha256 on Nios2"
arc: fix management of IRQ priority levels
test_ipm: disable on Quark SE ARC core

David B. Kinder (1):
doc: Fix terminology in Kconfig files for 'platform'

Flavio Santes (2):
samples/net: Remove call to unref routine when net_send returns >= 0
mqtt: Add KNOWN_ISSUES file

Juan Manuel Cruz Alcaraz (6):
enc28j60: hardware errata #6 PKTIF is unreliable
enc28j60: hardware errata #14 ERXRDPT register failure
enc28j60: remove rx interruption handling
enc28j60: allow simultaneous reception and transmission
enc28j60: rx fiber's stack size is increased
enc28j60: Correction to ECON1.RXEN bit location

Kuo-Lang Tseng (1):
ext qmsi: Fix broken built-in qmsi build


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-723] Sanity Crashes with "FileNotFound" exception when running samples/static_lib/test
https://jira.zephyrproject.org/browse/ZEP-723

[ZEP-722] sporadic illegal instruction exception on Nios II in test_errno
https://jira.zephyrproject.org/browse/ZEP-722


UPDATED JIRA items within last 24 hours: 1
[ZEP-678] sporadic bad RAM pointer error under qemu_nios2
https://jira.zephyrproject.org/browse/ZEP-678


CLOSED JIRA items within last 24 hours: 2
[ZEP-522] (Fixed) TCP/client-mode: disconnect
https://jira.zephyrproject.org/browse/ZEP-522

[ZEP-288] (Fixed) pinmux naming inconsistency
https://jira.zephyrproject.org/browse/ZEP-288


RESOLVED JIRA items within last 24 hours: 2
[ZEP-327] (Fixed) Encryption Libraries needed for Thread support
https://jira.zephyrproject.org/browse/ZEP-327

[ZEP-187] (Fixed) BLE APIs are not documented
https://jira.zephyrproject.org/browse/ZEP-187


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/4203 : net: samples: Fix the location of net-tools project files
- https://gerrit.zephyrproject.org/r/4202 : net: ip: Fix compiling with 15.4
- https://gerrit.zephyrproject.org/r/4201 : net: samples: Fix the echo-server IPv6 address
- https://gerrit.zephyrproject.org/r/4200 : net: samples: Fix slip config for echo-server and echo-client
- https://gerrit.zephyrproject.org/r/4199 : net: Clarify the CONFIG_NET_TESTING setting
- https://gerrit.zephyrproject.org/r/4167 : samples: net: Qemu make utilities update
- https://gerrit.zephyrproject.org/r/4164 : net: ieee802154: Add basic support for IEEE 802.15.4e on FCF
- https://gerrit.zephyrproject.org/r/4168 : net: samples: Add a simple Qemu sample for testing off-line 802.15.4
- https://gerrit.zephyrproject.org/r/4166 : samples: net: Moving the current ieee802154 sample
- https://gerrit.zephyrproject.org/r/4197 : Bluetooth: AVDTP: Module intialization
- https://gerrit.zephyrproject.org/r/4177 : net: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4196 : net: TODO file for networking
- https://gerrit.zephyrproject.org/r/4175 : tests: bluetooth: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4193 : nxp_kinetis: Refactor K64F init to use ksdk clock driver
- https://gerrit.zephyrproject.org/r/4191 : nxp_kinetis: Add Kconfig options to configure clocks
- https://gerrit.zephyrproject.org/r/4192 : ksdk: Compile the ksdk clock driver
- https://gerrit.zephyrproject.org/r/4186 : x86: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4181 : samples: fat_fs: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4176 : tests: benchmark: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4179 : nios2: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4170 : printk: make _char_out globally accessible
- https://gerrit.zephyrproject.org/r/4174 : tests: net: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4169 : printk: support more codes, fix %p
- https://gerrit.zephyrproject.org/r/4171 : tests: test_printk: crude printk test case
- https://gerrit.zephyrproject.org/r/4173 : tests: kernel: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4172 : tests: crypto: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4190 : printk: warn on incorrect printf-style usage
- https://gerrit.zephyrproject.org/r/4189 : Makefile: HACK: skip printf format checks when newlib used
- https://gerrit.zephyrproject.org/r/4188 : samples: i2c_fujitsu_fram: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4187 : drivers: pci: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4185 : drivers: ipm_console: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4184 : drivers: console_handler_shell: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4183 : samples: zperf: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4182 : samples: ipm: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4180 : arc: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4178 : arm: fix incorrect printk() usage

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4090 : Bluetooth: Controller: Add driver that glues Link Layer with the BLE stack
- https://gerrit.zephyrproject.org/r/4087 : Bluetooth: Controller: Add a util folder with basic primitives
- https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic Link Layer implementation
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include Controller by default in board nrf52_pca10040
- https://gerrit.zephyrproject.org/r/4088 : Bluetooth: Controller: Initial impl. of a HCI controller-side interface
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- https://gerrit.zephyrproject.org/r/4155 : Bluetooth: RFCOMM: Handle signalling connection request
- https://gerrit.zephyrproject.org/r/4157 : Bluetooth: RFCOMM: Handle incoming dlc request
- https://gerrit.zephyrproject.org/r/4156 : Bluetooth: RFCOMM: Handle PN request
- https://gerrit.zephyrproject.org/r/4158 : Bluetooth: shell: Add support for RFCOMM test
- https://gerrit.zephyrproject.org/r/3997 : Bluetooth: L2CAP: Implement connect command on BR/EDR
- https://gerrit.zephyrproject.org/r/4111 : usb: Add USB sample build test to sanity check
- https://gerrit.zephyrproject.org/r/4055 : Bluetooth: SDP: Server implementation
- https://gerrit.zephyrproject.org/r/4146 : pwm: power_mgmt: Update code according to new Power Management device driver API
- https://gerrit.zephyrproject.org/r/4142 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4147 : pwm: power_mgmt: Update code according to new Power Management idevice driver API
- https://gerrit.zephyrproject.org/r/4127 : qmsi:wdt: remove duplicated wdt clock enable code
- https://gerrit.zephyrproject.org/r/4007 : libc/printf: Unify & simplify number printing
- https://gerrit.zephyrproject.org/r/2047 : !!DO NOT MERGE!! unified: snapshot of development status
- https://gerrit.zephyrproject.org/r/3847 : arm: remove dynamic IRQs and exceptions

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4194 : mqtt: Add KNOWN_ISSUES file
- https://gerrit.zephyrproject.org/r/4204 : Bluetooth: Add missing guards to hci_raw.h header file
- https://gerrit.zephyrproject.org/r/4195 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4153 : Bluetooth: RFCOMM: Init buffer for outgoing signalling packets
- https://gerrit.zephyrproject.org/r/4129 : Bluetooth: Include btusb sample to sanity check
- https://gerrit.zephyrproject.org/r/3995 : Bluetooth: Export USB HCI controller using RAW HCI channel
- https://gerrit.zephyrproject.org/r/4128 : Bluetooth: Add documentation to HCI RAW interface
- https://gerrit.zephyrproject.org/r/3994 : Bluetooth: Add RAW API interface to Bluetooth
- https://gerrit.zephyrproject.org/r/4113 : Bluetooth: tests/shell: Set same name on BR/EDR and LE
- https://gerrit.zephyrproject.org/r/4024 : Bluetooth: Set BR/EDR device name on init
- https://gerrit.zephyrproject.org/r/4152 : Bluetooth: RFCOMM: Implement Register Server channel API
- https://gerrit.zephyrproject.org/r/4140 : doc: Fix terminology in Kconfig files for 'platform'
- https://gerrit.zephyrproject.org/r/4137 : samples/net: Remove call to unref routine when net_send returns >= 0
- https://gerrit.zephyrproject.org/r/4160 : MAINTAINERS: add ARM and ARC architecture maintainers
- https://gerrit.zephyrproject.org/r/4151 : Bluetooth: RFCOMM: Initialize and register to L2CAP


Re: QEMU networking: CONFIG_NET_TESTING breaks things, echo_server IPv6 address is "wrong"

Jukka Rissanen
 

On Fri, 2016-08-19 at 09:57 +0300, Jukka Rissanen wrote:
Hi Paul,

On Thu, 2016-08-18 at 22:46 +0300, Paul Sokolovsky wrote:

On Wed, 17 Aug 2016 17:26:39 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:

[]



So, I'm not sure what the exact issue is. I may imagine following
might happen:

1. There was a simple CONFIG_NET_TESTING, for things like
echo_server.
2. Later, it was made into a separate module, but echo_server
possibly
wasn't updated to play with the new module well.
3. net-tools and wiki page predate CONFIG_NET_TESTING altogether.

The obvious question is what to do in this situation. I'm
personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to
describe
a setup which actually works now (this is mostly doing steps in
the
right order, but also building with CONFIG_NET_TESTING=n).
Ok, mystery [seems to be] solved. The default setup of
echo_server/echo_client is tailored towards running QEMU-QEMU
communication, as described in samples/net/README. However, QEMU-
Host
setup is definitely regressed. Moreover, CONFIG_NET_TESTING, with
all
its addresses flip-floppig, appears to be needed exactly for QEMU-
QEMU
case, and only complicates matters for QEMU-Host case.
Yes, your analysis is correct. The CONFIG_NET_TESTING was setup so
that
we could automate the qemu-qemu testing. Unfortunately the
documentation about this was not very clear as you noticed.



Proposed/done items:

1. Done: https://wiki.zephyrproject.org/view/Networking-with-Qemu
now
describes both QEMU-Host and QEMU-QEMU cases.
2. Done: QEMU-Host includes instructions on patching echo_server to
make
net-tools to work as is.
Thanks a lot for these.


3. Suggestion: Update CONFIG_NET_TESTING's description in Kconfig
to
clearly state that it's pertinent to (only) QEMU-QEMU setup.
Yes, I can send a patch for clarifying this.


4. Suggestion: For all test apps not running in QEMU-QEMU mode,
standardize of 2001:db8::1 to be host side, and 2001:db8::2 to be
device side (eb it QEMU or physical device).
Right now the assumption has been that the server role device has
been
set to 2001:db8::1 and the client is 2001:db8::2 but we can change
this
of course. It probably simplifies things if the host side is
2001:db8::1 and device side is 2001:db8::2.


5. Suggestion: Apparently, add separate prj_*.conf's to run samples
in
QEMU-QEMU vs QEMU-Host mode.
True, that is definitely needed.


I can prepare proper patches for these unless you have already
something prepared in which case just send them to gerrit. Thanks for
you feedback!
Patches for these items can be now found in
https://gerrit.zephyrproject.org/r/#/c/4199/


Cheers,
Jukka


Re: About the testing framework

Hannikainen, Jaakko <jaakko.hannikainen@...>
 

Hi,

For testing, simply mocking out the kernel dependencies is enough to run unit tests. See tests/unit/net/buf from my patch for a simple case of removing the dependency to nano_fifo. Similarily, device drivers should first abstract away assembly/etc to a separate compile unit, which can then be wrapped off by the linker. It shouldn't give any performance penalty since the kernel is compiled with link-time optimizations, and can trivially inline the assembly.

Jaakko

From: Wang, Jing J
Sent: Friday, August 19, 2016 4:41 AM
To: Hannikainen, Jaakko <jaakko.hannikainen(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: About the testing framework

Jaakko,
I am trying to understand the usage of your proposed test framework. It is running on host, without dependency on Qemu, HW platform and rest of Zephyr OS, right? From Zephyr development stack, currently most of dev efforts are around upper level on top of Zephyr kernel, .e.g. driver, connectivity. Take Zephyr driver unit testing for example, the implementation depends on Zephyr kernel, how you run unit test with your test framework?
Thanks

Rgds
jwang

From: Hannikainen, Jaakko [mailto:jaakko.hannikainen(a)intel.com]
Sent: Wednesday, August 17, 2016 2:56 PM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: About the testing framework

Hello,

I now implemented an initial version of a framework, and I submitted it at https://gerrit.zephyrproject.org/r/#/c/4118/

While developing, it became apparent that the current testing stack also benefits from a more generic way of testing. I made the stack so that it works transparently both on Zephyr and without Zephyr. I implemented a small testing program for native (as in your own computer) testing and converted an existing test to the new framework as a sample.

The framework in general is a work-in-progress, but at its current state it's already usable for general testing. When I ran some dummy native tests, I could run about 30 tests within 5 seconds on my laptop. Comparing this to current QEMU testing, where 1 test took 9 seconds on my computer. Clearly this would improve development speed for test-driven development as initial tests take much less time and can be written simultaneously for both QEMU and native runs, sans a couple lines of boilerplate for native code.

Jaakko
________________________________
From: Hannikainen, Jaakko [jaakko.hannikainen(a)intel.com]
Sent: Wednesday, August 03, 2016 15:29
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] About the testing framework
Hello,

Currently, the testing stack consists of an unsorted bunch of integration and end-to-end tests. There's nothing wrong with having integration tests, but currently a lot of the tests could be done at least partially as plain unit tests. This way we could skip over a lot of unneeded time used for both compiling and running tests, as a lot of the testable code is written in portable C. Then the unit tests wouldn't have to do anything except compile the single .c file containing the code and link it with the testing framework. The test would also run a lot faster then the current stack since it can be run natively on the host without dragging in QEMU and the rest of Zephyr OS.

Including a unit testing library (either existing or a new one) would have multiple benefits for the entire system:

1) Unit testing enables testing static methods, rather than having to stick with the public api exposed by the module. This way all functions can be tested, for example edge cases of a static validation function.

2) Writing unit tests is also a lot simpler than writing complex integration tests. This would eventually result as an increase of testing coverage as writing tests would have a lower barrier of entry. This would especially happen if the project would start to enforce some percent of required test coverage for all incoming patches (this would have to exclude eg. arch specific code).

3) Writing native tests enables running valgrind on the tests, exposing bugs like invalid pointer dereferences and uninitialized variables. For certain cases, statically initialized code could be turned to dynamically allocated by mocking the respective functions, which would also allow using valgrind to hunt down memory leaks.

Although C lags a bit behind languages like Java for mocking, GCC's -Wl,--wrap works well for isolating single functions for testing. I tested out a library called CMocka (licensed under Apache 2.0) which seemed to work pretty well. Writing our own testing library isn't really that hard either, an initial usable version can be done in a day or two.

I propose including a unit testing framework in the Zephyr project (1.6.0 as target), and would like some discussion about how it should be implemented. Should we write our own test framework or use an existing one? What kind of adaptations to the existing test frameworks would be needed, if any? Should code coverage metrics be enforced so that we could have actual CI, rather than Jenkins just running some tests?

Jaakko


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Interesting. Will take a look at your project. An STM32F4 should be
more similar to the F3 then mainstream F1 support, which should make
my port easier.

Best Regards
Mirza


Re: QEMU networking: CONFIG_NET_TESTING breaks things, echo_server IPv6 address is "wrong"

Jukka Rissanen
 

Hi Paul,

On Thu, 2016-08-18 at 22:46 +0300, Paul Sokolovsky wrote:
On Wed, 17 Aug 2016 17:26:39 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:

[]


So, I'm not sure what the exact issue is. I may imagine following
might happen:

1. There was a simple CONFIG_NET_TESTING, for things like
echo_server.
2. Later, it was made into a separate module, but echo_server
possibly
wasn't updated to play with the new module well.
3. net-tools and wiki page predate CONFIG_NET_TESTING altogether.

The obvious question is what to do in this situation. I'm
personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to
describe
a setup which actually works now (this is mostly doing steps in the
right order, but also building with CONFIG_NET_TESTING=n).
Ok, mystery [seems to be] solved. The default setup of
echo_server/echo_client is tailored towards running QEMU-QEMU
communication, as described in samples/net/README. However, QEMU-Host
setup is definitely regressed. Moreover, CONFIG_NET_TESTING, with all
its addresses flip-floppig, appears to be needed exactly for QEMU-
QEMU
case, and only complicates matters for QEMU-Host case.
Yes, your analysis is correct. The CONFIG_NET_TESTING was setup so that
we could automate the qemu-qemu testing. Unfortunately the
documentation about this was not very clear as you noticed.


Proposed/done items:

1. Done: https://wiki.zephyrproject.org/view/Networking-with-Qemu now
describes both QEMU-Host and QEMU-QEMU cases.
2. Done: QEMU-Host includes instructions on patching echo_server to
make
net-tools to work as is.
Thanks a lot for these.

3. Suggestion: Update CONFIG_NET_TESTING's description in Kconfig to
clearly state that it's pertinent to (only) QEMU-QEMU setup.
Yes, I can send a patch for clarifying this.

4. Suggestion: For all test apps not running in QEMU-QEMU mode,
standardize of 2001:db8::1 to be host side, and 2001:db8::2 to be
device side (eb it QEMU or physical device).
Right now the assumption has been that the server role device has been
set to 2001:db8::1 and the client is 2001:db8::2 but we can change this
of course. It probably simplifies things if the host side is
2001:db8::1 and device side is 2001:db8::2.

5. Suggestion: Apparently, add separate prj_*.conf's to run samples
in
QEMU-QEMU vs QEMU-Host mode.
True, that is definitely needed.


I can prepare proper patches for these unless you have already
something prepared in which case just send them to gerrit. Thanks for
you feedback!


Cheers,
Jukka


Re: _Swap crash in attempt to add support for STM32F3 board

Ricardo Salveti <ricardo.salveti@...>
 

On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.

Cheers,
--
Ricardo Salveti


Re: About the testing framework

Wang, Jing J
 

Jaakko,
I am trying to understand the usage of your proposed test framework. It is running on host, without dependency on Qemu, HW platform and rest of Zephyr OS, right? From Zephyr development stack, currently most of dev efforts are around upper level on top of Zephyr kernel, .e.g. driver, connectivity. Take Zephyr driver unit testing for example, the implementation depends on Zephyr kernel, how you run unit test with your test framework?
Thanks

Rgds
jwang

From: Hannikainen, Jaakko [mailto:jaakko.hannikainen(a)intel.com]
Sent: Wednesday, August 17, 2016 2:56 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: About the testing framework

Hello,

I now implemented an initial version of a framework, and I submitted it at https://gerrit.zephyrproject.org/r/#/c/4118/

While developing, it became apparent that the current testing stack also benefits from a more generic way of testing. I made the stack so that it works transparently both on Zephyr and without Zephyr. I implemented a small testing program for native (as in your own computer) testing and converted an existing test to the new framework as a sample.

The framework in general is a work-in-progress, but at its current state it's already usable for general testing. When I ran some dummy native tests, I could run about 30 tests within 5 seconds on my laptop. Comparing this to current QEMU testing, where 1 test took 9 seconds on my computer. Clearly this would improve development speed for test-driven development as initial tests take much less time and can be written simultaneously for both QEMU and native runs, sans a couple lines of boilerplate for native code.

Jaakko
________________________________
From: Hannikainen, Jaakko [jaakko.hannikainen(a)intel.com]
Sent: Wednesday, August 03, 2016 15:29
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] About the testing framework
Hello,

Currently, the testing stack consists of an unsorted bunch of integration and end-to-end tests. There's nothing wrong with having integration tests, but currently a lot of the tests could be done at least partially as plain unit tests. This way we could skip over a lot of unneeded time used for both compiling and running tests, as a lot of the testable code is written in portable C. Then the unit tests wouldn't have to do anything except compile the single .c file containing the code and link it with the testing framework. The test would also run a lot faster then the current stack since it can be run natively on the host without dragging in QEMU and the rest of Zephyr OS.

Including a unit testing library (either existing or a new one) would have multiple benefits for the entire system:

1) Unit testing enables testing static methods, rather than having to stick with the public api exposed by the module. This way all functions can be tested, for example edge cases of a static validation function.

2) Writing unit tests is also a lot simpler than writing complex integration tests. This would eventually result as an increase of testing coverage as writing tests would have a lower barrier of entry. This would especially happen if the project would start to enforce some percent of required test coverage for all incoming patches (this would have to exclude eg. arch specific code).

3) Writing native tests enables running valgrind on the tests, exposing bugs like invalid pointer dereferences and uninitialized variables. For certain cases, statically initialized code could be turned to dynamically allocated by mocking the respective functions, which would also allow using valgrind to hunt down memory leaks.

Although C lags a bit behind languages like Java for mocking, GCC's -Wl,--wrap works well for isolating single functions for testing. I tested out a library called CMocka (licensed under Apache 2.0) which seemed to work pretty well. Writing our own testing library isn't really that hard either, an initial usable version can be done in a day or two.

I propose including a unit testing framework in the Zephyr project (1.6.0 as target), and would like some discussion about how it should be implemented. Should we write our own test framework or use an existing one? What kind of adaptations to the existing test frameworks would be needed, if any? Should code coverage metrics be enforced so that we could have actual CI, rather than Jenkins just running some tests?

Jaakko


Re: _Swap crash in attempt to add support for STM32F3 board

Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 11:23:15PM +0200, Mirza Krak wrote:
2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
But if I understand this correctly, shouldn't LR contain the address
of main at this stage.
Not at this point. The address of main() will be loaded from the stack
of the main thread when the CPU returns from the PendSV exception and
the main thread is the next one to run. Actually it will be the address
of a wrapper around the thread, and will be loaded into the PC
register, not LR.

The code says:
/* context switch to main task (entry function is _main()) */
_nano_fiber_swap();

I am not sure where it does get the address of main though. Because I
cant find the address that LR has when entering __Swap in any of of
the files (.map .lst), and maybe that is the root of it.
The address in LR when entering _Swap() is the one of the next
instruction after the branch to _Swap(). It's probably in the middle of
a function.


Re: _Swap crash in attempt to add support for STM32F3 board

Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 11:07:32PM +0200, Mirza Krak wrote:
2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
It seems to be corrupted when entering __svc, but once inside the
__svc it seems to have a value of what you where expecting.
Ah, no, this might be OK then. 0xfffffffd gets put by the CPU when
taking the SVC exception and entering __svc().

If this is the very first call to _Swap() when the kernel boots, that
call will never return.


(gdb) s
249 svc #0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000a6f 134220399
pc 0x8001256 0x8001256 <_Swap+6>
^^^^^^^^^
Although, these addresses look weird: normally the .text section is at 0
on these targets, but the PC shows an address in the 0x8001256 range as
well, and it is resolved as being _Swap+6. I suppose the link address is
different on that board.

cpsr 0x21000000 553648128
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20000d60 0x20000d60
lr 0xfffffffd 4294967293
pc 0x8001238 0x8001238 <__svc>
cpsr 0x2100000b 553648139>

Are you trying to run a stock project or is it your own application ?
I am attempting to run the samples/drivers/gpio application.
The comments in main.c list a bunch of boards, but not the STM ones.

I guess you adapted it to run on your board ?

Cheers,
Ben


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
But if I understand this correctly, shouldn't LR contain the address
of main at this stage.

The code says:
/* context switch to main task (entry function is _main()) */
_nano_fiber_swap();

I am not sure where it does get the address of main though. Because I
cant find the address that LR has when entering __Swap in any of of
the files (.map .lst), and maybe that is the root of it.

Best Regards
Mirza


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
It seems to be corrupted when entering __svc, but once inside the
__svc it seems to have a value of what you where expecting.

(gdb) s
249 svc #0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000a6f 134220399
pc 0x8001256 0x8001256 <_Swap+6>
cpsr 0x21000000 553648128
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20000d60 0x20000d60
lr 0xfffffffd 4294967293
pc 0x8001238 0x8001238 <__svc>
cpsr 0x2100000b 553648139>

Are you trying to run a stock project or is it your own application ?
I am attempting to run the samples/drivers/gpio application.

Best Regards
Mirza


Re: _Swap crash in attempt to add support for STM32F3 board

Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?

Posting a gdb trace below:

_nano_fiber_swap () at
/home/mirzak/git/zephyr-project/kernel/nanokernel/nano_fiber.c:159
159 _Swap(imask);
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:245
245 ldr r1, =_nanokernel
(gdb) s
246 ldr r2, [r1, #__tNANO_current_OFFSET]
(gdb) s
247 str r0, [r2, #__tTCS_basepri_OFFSET]
(gdb) s
249 svc #0
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) s
198 msr BASEPRI, r0
(gdb) s
201 ldr r1, =_SCS_ICSR
(gdb) s
202 ldr r2, =_SCS_ICSR_PENDSV
(gdb) s
203 str r2, [r1, #0]
(gdb) s
208 bx lr
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:252
252 bx lr
(gdb) s
Looks like it's going in the weeds when trying to return from the svc
handler. What's the value of the LR register at that time ?
I get the following just before it tries to exit.

252 bx lr
(gdb) info registers
r0 0x20 32
r1 0x20000120 536871200
r2 0x20009e98 536911512
r3 0x20000044 536870980
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?

Are you trying to run a stock project or is it your own application ?

pc 0x8001020 0x8001020 <_Swap+8>
cpsr 0x21000000 553648128
(gdb) s
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
77 if ((curCtx == NANO_CTX_ISR) || _is_thread_essential()) {

Best Regards,
Mirza

6421 - 6440 of 7680