Date   

Re: [RFC] Real-time interrupts

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Oct 04, 2016 at 04:29:45PM +0000, Cufi, Carles wrote:


-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Tuesday, October 04, 2016 18:22
To: Piotr Mienkowski <piotr.mienkowski(a)schmid-telecom.ch>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: [RFC] Real-time interrupts

On Tue, Oct 04, 2016 at 02:31:37PM +0000, Piotr Mienkowski wrote:
IRQ_CONNECT_DIRECT(..., my_isr, ...);
It's not a feature I was using but looking through the code I saw two
Kconfig parameters which seem to be there to support exactly this kind
of functionality: CONFIG_SW_ISR_TABLE and
CONFIG_IRQ_VECTOR_TABLE_CUSTOM. The latter becomes visible in
menuconfig when the former is disabled.

For ARM architecture IRQ vector table is defined in
arch/arm/core/cortex_m/irq_vector_table.c file. Code there can be used
as an example to define custom IRQ table.
Huh, I thought we got rid of this at some point... Guess not.

This is somewhat hard to use indeed: you have to create the entire
vector table in your project. It's meant to be a (very) advanced
feature.

Another problem is that when you disable CONFIG_SW_ISR_TABLE but do not
enable CONFIG_IRQ_VECTOR_TABLE_CUSTOM, it fills the vector table with
spurious interrupt handlers. This is because there used to be a
irq_vector_table.c file with each board, not in the arch directory. The
idea was that the board would fill the vector table according to its
specs. It was never put in practice.

IRQ_CONNECT_DIRECT macro could still be worth implementing. It would
be easier to use than the two previously mentioned defines.
Thanks for the input.

So I gather from the thread and IRC conversations that it makes sense
to create an IRQ_CONNECT_DIRECT macro along with (light) documentation
on the rights and responsibilities of ISRs connected using this
mechanism. That way we can use this for the BLE Controller that could
serve as a reference for future hard real-time interrupts.

If there's no objections I will create a Jira issue with this
information.

Should this replace the zero latency interrupt (ZLI) infrastructure
that is currently in the kernel? Or should it live side-by-side with
it?
They're related, but not exactly the same.

ZLIs cannot call kernel functionalities, because lots of kernel
operations rely on locking interrupts, and ZLIs ignore interrupt
locking; "real-time" interrupts would still be able to call kernel
functionalities, if the invoke _IntExit() when they're done. Enabling
ZLI just punches a hole in the range of interrupt priorities that are
locked when locking interrupts.

Both ZLIs and RT interrupts have to be installed directly in the vector
table.

We also have to be careful about how we're handling tickless idle and
power management for RT interrupts.


Re: [RFC] Real-time interrupts

Carles Cufi
 

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Tuesday, October 04, 2016 18:22
To: Piotr Mienkowski <piotr.mienkowski(a)schmid-telecom.ch>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: [RFC] Real-time interrupts

On Tue, Oct 04, 2016 at 02:31:37PM +0000, Piotr Mienkowski wrote:
IRQ_CONNECT_DIRECT(..., my_isr, ...);
It's not a feature I was using but looking through the code I saw two
Kconfig parameters which seem to be there to support exactly this kind
of functionality: CONFIG_SW_ISR_TABLE and
CONFIG_IRQ_VECTOR_TABLE_CUSTOM. The latter becomes visible in
menuconfig when the former is disabled.

For ARM architecture IRQ vector table is defined in
arch/arm/core/cortex_m/irq_vector_table.c file. Code there can be used
as an example to define custom IRQ table.
Huh, I thought we got rid of this at some point... Guess not.

This is somewhat hard to use indeed: you have to create the entire
vector table in your project. It's meant to be a (very) advanced
feature.

Another problem is that when you disable CONFIG_SW_ISR_TABLE but do not
enable CONFIG_IRQ_VECTOR_TABLE_CUSTOM, it fills the vector table with
spurious interrupt handlers. This is because there used to be a
irq_vector_table.c file with each board, not in the arch directory. The
idea was that the board would fill the vector table according to its
specs. It was never put in practice.

IRQ_CONNECT_DIRECT macro could still be worth implementing. It would
be easier to use than the two previously mentioned defines.
Thanks for the input.

So I gather from the thread and IRC conversations that it makes sense to create an IRQ_CONNECT_DIRECT macro along with (light) documentation on the rights and responsibilities of ISRs connected using this mechanism.
That way we can use this for the BLE Controller that could serve as a reference for future hard real-time interrupts.

If there's no objections I will create a Jira issue with this information.

Should this replace the zero latency interrupt (ZLI) infrastructure that is currently in the kernel? Or should it live side-by-side with it?

Carles


Re: [RFC] Real-time interrupts

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Oct 04, 2016 at 02:31:37PM +0000, Piotr Mienkowski wrote:
IRQ_CONNECT_DIRECT(..., my_isr, ...);
It's not a feature I was using but looking through the code I saw two
Kconfig parameters which seem to be there to support exactly this kind
of functionality: CONFIG_SW_ISR_TABLE and
CONFIG_IRQ_VECTOR_TABLE_CUSTOM. The latter becomes visible in
menuconfig when the former is disabled.

For ARM architecture IRQ vector table is defined in
arch/arm/core/cortex_m/irq_vector_table.c file. Code there can be used
as an example to define custom IRQ table.
Huh, I thought we got rid of this at some point... Guess not.

This is somewhat hard to use indeed: you have to create the entire
vector table in your project. It's meant to be a (very) advanced
feature.

Another problem is that when you disable CONFIG_SW_ISR_TABLE but do not
enable CONFIG_IRQ_VECTOR_TABLE_CUSTOM, it fills the vector table with
spurious interrupt handlers. This is because there used to be a
irq_vector_table.c file with each board, not in the arch directory. The
idea was that the board would fill the vector table according to its
specs. It was never put in practice.

IRQ_CONNECT_DIRECT macro could still be worth implementing. It would
be easier to use than the two previously mentioned defines.


Re: [RFC] Real-time interrupts

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Oct 04, 2016 at 09:36:59AM +0100, Jon Medhurst (Tixy) wrote:
On Mon, 2016-10-03 at 17:26 +0000, Boie, Andrew P wrote:
On Mon, 2016-10-03 at 13:39 +0000, Cufi, Carles wrote:
We would like to ask whether a real-time interrupt framework could be
introduced through which the driver would register its ISR using a
new version of the IRQ_CONNECT() macro (perhaps IRQ_CONNECT_DIRECT)
that would place the ISR's entry point directly in the interrupt
vector so that latency is reduced to the minimum imposed by the
hardware itself.
I think this would be something desirable across arches yes. It would
essentially put the ISR directly in the vector table.
I imagine the IRQ_CONNECT_DIRECT() feature would have the following
characteristics:

1. ISR handler functions would have to be declared with
__attribute__((interrupt)) or written in assembly. The handler gets put
directly in the vector table.
2. Any common interrupt entry or exit code (like EOI) would have to be
called by the ISR handler.
For ARM Cortex-M the above aren't needed. The hardware takes care of
saving and preserving registers and state to enable calling plain C
functions as interrupt handlers. So the current Zephyr wrappers are
overhead done to support 3 below...

3. No stack switch to the interrupt stack, no scheduling decision done
after the interrupt is serviced,
Unless ISR calls _IntExit at the end? If that's permissible then I
believe an ISR could still signal semaphores, which is probably the main
OS service that it needs.
That is permissible, at least on ARM. That's the way the systick handler
is written. (_IntExit is an alias of _ExcExit).

no powersave stuff, we basically skip
all the common code we usually go through when handling an interrupt.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-1030] Enable QMSI shim drivers of SoC peripherals on the sensor subsystem
https://jira.zephyrproject.org/browse/ZEP-1030

[ZEP-1031] qmsi: dma: driver test fails with LLVM
https://jira.zephyrproject.org/browse/ZEP-1031


UPDATED JIRA items within last 24 hours: 2
[ZEP-539] Jenkins marks patches -1 verified for style issues
https://jira.zephyrproject.org/browse/ZEP-539

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


CLOSED JIRA items within last 24 hours: 3
[ZEP-738] (Fixed) samples/net/test_15_4 doesn't fit in Quark D2000 / Nucleo F103RB / Alimexino STM32
https://jira.zephyrproject.org/browse/ZEP-738

[ZEP-610] (Fixed) TSC mailing list missing on mailing list "Manage List" list-of-lists list
https://jira.zephyrproject.org/browse/ZEP-610

[ZEP-560] (Won't Do) full JIRA links in Gerrit comments get mangled
https://jira.zephyrproject.org/browse/ZEP-560


RESOLVED JIRA items within last 24 hours: 5
[ZEP-779] (Fixed) Using current MinGW gcc version 5.3.0 breaks Zephyr build on Windows
https://jira.zephyrproject.org/browse/ZEP-779

[ZEP-724] (Fixed) build on windows failed: 'make: execvp: uname: File or path name too long'
https://jira.zephyrproject.org/browse/ZEP-724

[ZEP-735] (Fixed) Several Tests and Samples are broken for CONFIG_DEBUG
https://jira.zephyrproject.org/browse/ZEP-735

[ZEP-577] (Fixed) Sample application source does not compile on Windows
https://jira.zephyrproject.org/browse/ZEP-577

[ZEP-1015] (Fixed) [TCF] samples/power/power_hooks build fail
https://jira.zephyrproject.org/browse/ZEP-1015


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/5161 : Bluetooth: HCI: Added Macro for setting page timeout
- https://gerrit.zephyrproject.org/r/5162 : Bluetooth: A2DP: Shell command for A2DP connection
- https://gerrit.zephyrproject.org/r/5155 : Bluetooth: L2CAP: Connect optional fixed channel only if supported
- https://gerrit.zephyrproject.org/r/5157 : Bluetooth: SMP: Fix getting context for BR/EDR pairing
- https://gerrit.zephyrproject.org/r/5156 : Bluetooth: L2CAP: Treat fixed channel as connected on incoming data
- https://gerrit.zephyrproject.org/r/5160 : net: yaip: events: Fix a mix up between code and command
- https://gerrit.zephyrproject.org/r/5154 : Bluetooth: L2CAP: Move BR/EDR specific code to l2cap_br.c
- https://gerrit.zephyrproject.org/r/5153 : Bluetooth: L2CAP: Build fixed channels mask on runtime
- https://gerrit.zephyrproject.org/r/5152 : Bluetooth: L2CAP: Initialize interator inside for statement
- https://gerrit.zephyrproject.org/r/5159 : Bluetooth: Start SMP over BR/EDR on pairing complete
- https://gerrit.zephyrproject.org/r/5158 : Bluetooth: SMP: Use separate pool for BR/EDR connections
- https://gerrit.zephyrproject.org/r/5151 : Bluetooth: L2CAP: Rename br_channels to br_fixed_channels
- https://gerrit.zephyrproject.org/r/5150 : drivers qmsi: Fix power management with reentrancy disabled
- https://gerrit.zephyrproject.org/r/5131 : arch: arm: cortex-m0 port
- https://gerrit.zephyrproject.org/r/5123 : unified: Rename k_thread_static_init structure
- https://gerrit.zephyrproject.org/r/5134 : boards: Add support for Nordic Semiconductor nRF51 PCA10031
- https://gerrit.zephyrproject.org/r/5132 : arm: soc: Add support for Nordic Semiconductor nRF51 Series SoC
- https://gerrit.zephyrproject.org/r/5133 : drivers: update nRF5x drivers in preparation for nRF51x SoC
- https://gerrit.zephyrproject.org/r/5130 : Bluetooth: Controller: Alternate Enc procedure for nRF51x SoC
- https://gerrit.zephyrproject.org/r/5136 : reviewers: use short numeric id instead of change ID
- https://gerrit.zephyrproject.org/r/5137 : TEST: add changes to two different branches
- https://gerrit.zephyrproject.org/r/5135 : sanity: remove specific toolchain settings
- https://gerrit.zephyrproject.org/r/5127 : unified: Fix build broblem caused by concurrent make processes in single dir
- https://gerrit.zephyrproject.org/r/5128 : check_link_map: rewrite in python

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4917 : iot/zoap: Port to the new network stack
- https://gerrit.zephyrproject.org/r/4883 : sanity: enable sanity multiple configuration
- https://gerrit.zephyrproject.org/r/4934 : Bluetooth: A2DP: Added Disconnect API
- https://gerrit.zephyrproject.org/r/4984 : unified: Don't assert if work is pending on submit
- https://gerrit.zephyrproject.org/r/4983 : unified: Add k_work_pending
- https://gerrit.zephyrproject.org/r/4881 : nano_work: Don't assert if work is pending on submit
- https://gerrit.zephyrproject.org/r/4880 : nano_work: Add nano_work_pending
- https://gerrit.zephyrproject.org/r/4868 : unified: Add tickless idle support for x86 and ARM
- https://gerrit.zephyrproject.org/r/5025 : ext: Add Atmel SAM E70, SAM3X header files from Atmel ASF library
- https://gerrit.zephyrproject.org/r/5109 : gpio: reduce Kconfigs and use consistent name for GPIOs
- https://gerrit.zephyrproject.org/r/5027 : arch: Add Atmel SAM E70 SoC support
- https://gerrit.zephyrproject.org/r/4882 : util: adds downstream failure check script
- https://gerrit.zephyrproject.org/r/5104 : unified: cache the next thread to run
- https://gerrit.zephyrproject.org/r/5100 : unified/arm: fix saving of registers in __pendsv()
- https://gerrit.zephyrproject.org/r/5105 : quark_se_c1000: add debug support to openocd config
- https://gerrit.zephyrproject.org/r/4541 : DONT MERGE
- https://gerrit.zephyrproject.org/r/4457 : DONT MERGE
- https://gerrit.zephyrproject.org/r/5054 : unified: Simplify k_msgq_purge()
- https://gerrit.zephyrproject.org/r/5117 : eth: Rework LOG_ETHERNET_LEVEL config description.
- https://gerrit.zephyrproject.org/r/5118 : eth: Add KSDK ENET driver.
- https://gerrit.zephyrproject.org/r/5023 : drivers: clock_control: Add nRF5x Series SoC clock driver

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5140 : samples/zoap_server: Fix warning about pointer signedness
- https://gerrit.zephyrproject.org/r/5142 : fs: Fixes some type incompatibilities flagged by llvm
- https://gerrit.zephyrproject.org/r/5147 : sample: fs: Fix a compile error flagged by llvm
- https://gerrit.zephyrproject.org/r/5138 : nano: remove duplicated typedef
- https://gerrit.zephyrproject.org/r/5143 : dma: qmsi_shim: add typecasting to avoid compilation error
- https://gerrit.zephyrproject.org/r/5141 : samples: power_mgmt: Fix compile bugs flagged by llvm
- https://gerrit.zephyrproject.org/r/5149 : Bluetooth: Fix compiler warnings/errors related to string casts
- https://gerrit.zephyrproject.org/r/5139 : iot/zoap: Fix comparing pointers of different signedness
- https://gerrit.zephyrproject.org/r/5148 : Bluetooth: Adjust maximum connections & paired devices range
- https://gerrit.zephyrproject.org/r/5146 : Bluetooth: Enable privacy for nimble
- https://gerrit.zephyrproject.org/r/5122 : unified: Eliminate k_mem_pool_t typedef
- https://gerrit.zephyrproject.org/r/5121 : unified: Relocate internal thread group APIs
- https://gerrit.zephyrproject.org/r/5124 : Bluetooth: RFCOMM: Fix some remaining white-space issues
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: Refactor distribution of security procedure status
- https://gerrit.zephyrproject.org/r/5091 : net: yaip: ieee802154: End of buffer contains LQI
- https://gerrit.zephyrproject.org/r/5089 : drivers: yaip: cc2520: Fix 80 chars lenght limit
- https://gerrit.zephyrproject.org/r/5082 : tests: yaip: Add network core event tests
- https://gerrit.zephyrproject.org/r/5081 : net: yaip: net_if: Notify about IPv6 address related changes
- https://gerrit.zephyrproject.org/r/5079 : net: yaip: mgmt: Add some macro helpers for filling in the bit field
- https://gerrit.zephyrproject.org/r/5080 : net: yaip: Add network management event code for IPv6
- https://gerrit.zephyrproject.org/r/5092 : drivers: yaip: cc2520: Fix LQI computation and generalize it
- https://gerrit.zephyrproject.org/r/4908 : Bluetooth: A2DP: Added Connect API
- https://gerrit.zephyrproject.org/r/4998 : frdm_k64f: Add support for RGB LEDs
- https://gerrit.zephyrproject.org/r/4997 : frdm_k64f: Add support for push button switches
- https://gerrit.zephyrproject.org/r/5042 : kernel: Add __unused tag
- https://gerrit.zephyrproject.org/r/5108 : scripts/sysgen: Fix indentation inconsistency
- https://gerrit.zephyrproject.org/r/5044 : nanokernel: nanokernel.h to include sections.h
- https://gerrit.zephyrproject.org/r/5116 : k64f: Refactor pinmux configuration table.
- https://gerrit.zephyrproject.org/r/4992 : toolchain: Add BUILD_ASSERT macro for compile-time checks
- https://gerrit.zephyrproject.org/r/5083 : daily: enable sanitycheck for unified kernel
- https://gerrit.zephyrproject.org/r/5110 : timer: Fixes a build error when MVIC is used


Re: [RFC] Real-time interrupts

Piotr Mienkowski <piotr.mienkowski@...>
 

IRQ_CONNECT_DIRECT(..., my_isr, ...);
It's not a feature I was using but looking through the code I saw two Kconfig parameters which seem to be there to support exactly this kind of functionality: CONFIG_SW_ISR_TABLE and CONFIG_IRQ_VECTOR_TABLE_CUSTOM. The latter becomes visible in menuconfig when the former is disabled.

For ARM architecture IRQ vector table is defined in arch/arm/core/cortex_m/irq_vector_table.c file. Code there can be used as an example to define custom IRQ table.

IRQ_CONNECT_DIRECT macro could still be worth implementing. It would be easier to use than the two previously mentioned defines.


Re: [RFC] Real-time interrupts

Jon Medhurst (Tixy) <tixy@...>
 

On Mon, 2016-10-03 at 17:26 +0000, Boie, Andrew P wrote:
On Mon, 2016-10-03 at 13:39 +0000, Cufi, Carles wrote:
We would like to ask whether a real-time interrupt framework could be
introduced through which the driver would register its ISR using a
new version of the IRQ_CONNECT() macro (perhaps IRQ_CONNECT_DIRECT)
that would place the ISR's entry point directly in the interrupt
vector so that latency is reduced to the minimum imposed by the
hardware itself.
I think this would be something desirable across arches yes. It would
essentially put the ISR directly in the vector table.
I imagine the IRQ_CONNECT_DIRECT() feature would have the following
characteristics:

1. ISR handler functions would have to be declared with
__attribute__((interrupt)) or written in assembly. The handler gets put
directly in the vector table.
2. Any common interrupt entry or exit code (like EOI) would have to be
called by the ISR handler.
For ARM Cortex-M the above aren't needed. The hardware takes care of
saving and preserving registers and state to enable calling plain C
functions as interrupt handlers. So the current Zephyr wrappers are
overhead done to support 3 below...

3. No stack switch to the interrupt stack, no scheduling decision done
after the interrupt is serviced,
Unless ISR calls _IntExit at the end? If that's permissible then I
believe an ISR could still signal semaphores, which is probably the main
OS service that it needs.

no powersave stuff, we basically skip
all the common code we usually go through when handling an interrupt.
--
Tixy


Re: [RFC] Real-time interrupts

Boie, Andrew P
 

On Mon, 2016-10-03 at 17:33 -0400, Benjamin Walsh wrote:
On Mon, Oct 03, 2016 at 05:26:33PM +0000, Boie, Andrew P wrote:
3. No stack switch to the interrupt stack, no scheduling decision
done
after the interrupt is serviced, no powersave stuff, we basically
skip
all the common code we usually go through when handling an
interrupt.
The problem with point #3 is that you have to take into account that
the
ISR could run on _any_ stack in the system, so all thread stacks have
to
be able to handle that, in addition to their application.

The nice thing with some architectures is that stack switching is
automatic, so you can still use a separate stack without having to
switch to it in software. The ARM and ARC ports currently do this
(the
ARC port only for FIRQs).
Maybe we should preserve that property then. It also looks like
__attribute__((interrupt)) isn't common to all arches.

Maybe we need something like:

void my_isr(void)
{
IRQ_HEADER();

<service the interrupt>

IRQ_FOOTER();
}

IRQ_CONNECT_DIRECT(..., my_isr, ...);

Where IRQ_HEADER and FOOTER expand to whatever is needed per-platform
to save/restore context, switch to/from the IRQ stack, perform EOI, etc
if the HW doesn't do it automatically.

Andrew


Re: [RFC] Real-time interrupts

Benjamin Walsh <benjamin.walsh@...>
 

On Mon, Oct 03, 2016 at 05:26:33PM +0000, Boie, Andrew P wrote:
On Mon, 2016-10-03 at 13:39 +0000, Cufi, Carles wrote:
We would like to ask whether a real-time interrupt framework could be
introduced through which the driver would register its ISR using a
new version of the IRQ_CONNECT() macro (perhaps IRQ_CONNECT_DIRECT)
that would place the ISR's entry point directly in the interrupt
vector so that latency is reduced to the minimum imposed by the
hardware itself.
I think this would be something desirable across arches yes. It would
essentially put the ISR directly in the vector table.
I imagine the IRQ_CONNECT_DIRECT() feature would have the following
characteristics:

1. ISR handler functions would have to be declared with
__attribute__((interrupt)) or written in assembly. The handler gets put
directly in the vector table.
2. Any common interrupt entry or exit code (like EOI) would have to be
called by the ISR handler.
3. No stack switch to the interrupt stack, no scheduling decision done
after the interrupt is serviced, no powersave stuff, we basically skip
all the common code we usually go through when handling an interrupt.
The problem with point #3 is that you have to take into account that the
ISR could run on _any_ stack in the system, so all thread stacks have to
be able to handle that, in addition to their application.

The nice thing with some architectures is that stack switching is
automatic, so you can still use a separate stack without having to
switch to it in software. The ARM and ARC ports currently do this (the
ARC port only for FIRQs).


Re: [RFC] Real-time interrupts

Boie, Andrew P
 

On Mon, 2016-10-03 at 13:39 +0000, Cufi, Carles wrote:
We would like to ask whether a real-time interrupt framework could be
introduced through which the driver would register its ISR using a
new version of the IRQ_CONNECT() macro (perhaps IRQ_CONNECT_DIRECT)
that would place the ISR's entry point directly in the interrupt
vector so that latency is reduced to the minimum imposed by the
hardware itself.
I think this would be something desirable across arches yes. It would
essentially put the ISR directly in the vector table.
I imagine the IRQ_CONNECT_DIRECT() feature would have the following
characteristics:

1. ISR handler functions would have to be declared with
__attribute__((interrupt)) or written in assembly. The handler gets put
directly in the vector table.
2. Any common interrupt entry or exit code (like EOI) would have to be
called by the ISR handler.
3. No stack switch to the interrupt stack, no scheduling decision done
after the interrupt is serviced, no powersave stuff, we basically skip
all the common code we usually go through when handling an interrupt.

On x86 you can actually already do this with NANO_CPU_INT_REGISTER(),
but this is specific to x86.

Andrew


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 1
[ZEP-1015] [TCF] samples/power/power_hooks build fail
https://jira.zephyrproject.org/browse/ZEP-1015


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 3
[ZEP-967] (Fixed) Sanity doesnt build 'samples/usb/dfu' with assertions (-R)
https://jira.zephyrproject.org/browse/ZEP-967

[ZEP-1014] (Won't Do) [TCF] tests/bluetooth/init build fail
https://jira.zephyrproject.org/browse/ZEP-1014

[ZEP-1013] (Won't Do) [TCF] samples/shell/microkernel build fail
https://jira.zephyrproject.org/browse/ZEP-1013


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/5116 : k64f: Refactor pinmux configuration table.
- https://gerrit.zephyrproject.org/r/5118 : eth: Add KSDK ENET driver.
- https://gerrit.zephyrproject.org/r/5117 : eth: Rework LOG_ETHERNET_LEVEL config description.
- https://gerrit.zephyrproject.org/r/5119 : iot/zoap: Add helper for generating tokens
- https://gerrit.zephyrproject.org/r/5120 : samples/zoap_client: Use token generator helper
- https://gerrit.zephyrproject.org/r/5110 : timer: Fixes a build error when MVIC is used
- https://gerrit.zephyrproject.org/r/5109 : gpio: reduce Kconfigs and use consistent name for GPIOs

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4984 : unified: Don't assert if work is pending on submit
- https://gerrit.zephyrproject.org/r/4983 : unified: Add k_work_pending
- https://gerrit.zephyrproject.org/r/4881 : nano_work: Don't assert if work is pending on submit
- https://gerrit.zephyrproject.org/r/4880 : nano_work: Add nano_work_pending
- https://gerrit.zephyrproject.org/r/4917 : iot/zoap: Port to the new network stack
- https://gerrit.zephyrproject.org/r/5081 : net: yaip: net_if: Notify about IPv6 address related changes
- https://gerrit.zephyrproject.org/r/5082 : tests: yaip: Add network core event tests
- https://gerrit.zephyrproject.org/r/5080 : net: yaip: Add network management event code for IPv6
- https://gerrit.zephyrproject.org/r/5091 : net: yaip: ieee802154: End of buffer contains LQI
- https://gerrit.zephyrproject.org/r/5092 : drivers: yaip: cc2520: Fix LQI computation and generalize it
- https://gerrit.zephyrproject.org/r/5089 : drivers: yaip: cc2520: Fix 80 chars lenght limit
- https://gerrit.zephyrproject.org/r/4908 : Bluetooth: A2DP: Added Connect API
- https://gerrit.zephyrproject.org/r/5025 : ext: Add Atmel SAM E70, SAM3X header files from Atmel ASF library
- https://gerrit.zephyrproject.org/r/5004 : net: Be sure to pass "connection state changed" net_buf's to an app.
- https://gerrit.zephyrproject.org/r/5079 : net: yaip: mgmt: Add some macro helpers for filling in the bit field
- https://gerrit.zephyrproject.org/r/4934 : Bluetooth: A2DP: Added Disconnect API
- https://gerrit.zephyrproject.org/r/4963 : samples: pwm: use new API interface
- https://gerrit.zephyrproject.org/r/5108 : scripts/sysgen: Fix indentation inconsistency

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5113 : Bluetooth: L2CAP: Fix sending double connection request
- https://gerrit.zephyrproject.org/r/5112 : Bluetooth: RFCOMM: Replace tabs with spaces
- https://gerrit.zephyrproject.org/r/5111 : Bluetooth: RFCOMM: Remove reference counting
- https://gerrit.zephyrproject.org/r/5039 : Bluetooth: RFCOMM: Introduce dlc destroy
- https://gerrit.zephyrproject.org/r/5099 : libc: define EWOULDBLOCK to be the same as EAGAIN
- https://gerrit.zephyrproject.org/r/4968 : tests: remove redundant PRINT definition
- https://gerrit.zephyrproject.org/r/4915 : build: Support for integrating third party build systems
- https://gerrit.zephyrproject.org/r/4969 : help: document ram/rom_report in 'make help'
- https://gerrit.zephyrproject.org/r/4970 : pinmux: remove nonexistant galileo Kconfig


[RFC] Real-time interrupts

Carles Cufi
 

Hi there,

While testing the Bluetooth Low Energy Controller on the Nordic nRF51822 (16MHz Cortex-M0), we have detected that, under certain circumstances, the delay introduced by the ISR wrapper exceeds the allowable one to make sure we can maintain a BLE link alive respecting the timing requirements imposed by the specification. The measured latency (delay introduced by the ISR wrapper) is currently 12us. This is mainly due to the IPSR/_sw_isr_table lookup but could potentially be made worse depending on the code path taken inside _sys_power_save_idle_exit.
We would like to ask whether a real-time interrupt framework could be introduced through which the driver would register its ISR using a new version of the IRQ_CONNECT() macro (perhaps IRQ_CONNECT_DIRECT) that would place the ISR's entry point directly in the interrupt vector so that latency is reduced to the minimum imposed by the hardware itself.

Thanks,

Carles and Vinayak


Issue with zephyr UART IRQ call back when receive the data from linux host app UDP scoket

Giribabu Gogineni <giribabu02061983@...>
 

Hi Dev team,

we are facing issue with UART IRQ call back when we receive the data from
linux host app using UDP socket, the same issue is not observed if we use
UNIX(AF_UNIX) socket.

Issue:
Send the data from zephyr app and process in linx host application using
UDP port and send data back to zephyr app.

it will receive the data and call the UART IRQ call back function, but
after reading the arrived packet from linux host, it is still running in
while loop mentioned below with rx=0.
In zephyr app also listening on UDP port using QEMU.


Sample code in my application:
int main()
{
dev = device_get_binding(CONFIG_BLUETOOTH_UART_ON_DEV_NAME);
uart_irq_callback_set(dev, uart_isr);
uart_irq_rx_enable(dev);
}

static void uart_isr(struct device *unused) {
while (uart_irq_update(thread_dev) && uart_irq_is_pending(thread_dev)) {
int rx;
if (!uart_irq_rx_ready(thread_dev)) {
if (uart_irq_tx_ready(thread_dev)) {
printf("Transmit ready \n");
}
continue;
}
/* Beginning of a new packet */
rx = uart_fifo_read(thread_dev, buf, len);

if(!rx)
{
continue;
}
buf += rx;
len = len-rx;
if(len == 0) {
buf = NULL;
}

}


If we use the AF_UNIX socket instead of UDP in both zephyr and linux host,
the issue is not observed, because after reading the full packet, the
pending IRQ is coming as zero and update irq as become one and it is coming
out of while loop.

In case of UDP socket, after reading the full UDP packet, the Pending IRQ
and Update IRQ values are always one and it is running while forever with
rx=0.

Could you please help me, is there issue with UDP socket or let me know if
i am missing some logic here.

Thanks & Regards,
Giribabu


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 2
[ZEP-775] Enable USB CDC by default on Arduino 101 and redirect serial to USB
https://jira.zephyrproject.org/browse/ZEP-775

[ZEP-982] Minimal libc has EWOULDBLOCK != EAGAIN
https://jira.zephyrproject.org/browse/ZEP-982


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 1
[ZEP-970] (Fixed) Sanity doesnt build 'tests/kernel/test_build' with assertions (-R)
https://jira.zephyrproject.org/browse/ZEP-970


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/5108 : scripts/sysgen: Fix indentation inconsistency
- https://gerrit.zephyrproject.org/r/5107 : samples: button: modify sample to work on more boards
- https://gerrit.zephyrproject.org/r/5106 : boards: define user buttons and switches on boards
- https://gerrit.zephyrproject.org/r/5105 : quark_se_c1000: add debug support to openocd config
- https://gerrit.zephyrproject.org/r/5101 : dlist: add sys_dlist_peek_head_not_empty()
- https://gerrit.zephyrproject.org/r/5103 : unified: use sys_dlist_peek_head_not_empty()
- https://gerrit.zephyrproject.org/r/5104 : unified: cache the next thread to run
- https://gerrit.zephyrproject.org/r/5102 : unified: un-comment k_thread_[suspend|resume|abort_handler_set]
- https://gerrit.zephyrproject.org/r/5100 : unified/arm: fix saving of registers in __pendsv()
- https://gerrit.zephyrproject.org/r/5099 : libc: define EWOULDBLOCK to be the same as EAGAIN

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4915 : build: Support for integrating third party build systems
- https://gerrit.zephyrproject.org/r/4997 : frdm_k64f: Add support for push button switches
- https://gerrit.zephyrproject.org/r/4998 : frdm_k64f: Add support for RGB LEDs
- https://gerrit.zephyrproject.org/r/4880 : nano_work: Add nano_work_pending

MERGED within last 24 hours:


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 6
[ZEP-1024] GPIO API Update
https://jira.zephyrproject.org/browse/ZEP-1024

[ZEP-1023] workq in Kernel primer for unified kernel
https://jira.zephyrproject.org/browse/ZEP-1023

[ZEP-1028] shrink k_block struct size
https://jira.zephyrproject.org/browse/ZEP-1028

[ZEP-1022] minor issues in "zephyr/include/kernel.h"
https://jira.zephyrproject.org/browse/ZEP-1022

[ZEP-1021] warning raised when using K_FIFO_DEFINE
https://jira.zephyrproject.org/browse/ZEP-1021

[ZEP-1027] Doccumentation for GCC ARM is not accurate
https://jira.zephyrproject.org/browse/ZEP-1027


UPDATED JIRA items within last 24 hours: 6
[ZEP-989] Cache next ready thread instead of finding out the long way
https://jira.zephyrproject.org/browse/ZEP-989

[ZEP-923] Revise documentation for Timing
https://jira.zephyrproject.org/browse/ZEP-923

[ZEP-975] DNS client port to new IP stack
https://jira.zephyrproject.org/browse/ZEP-975

[ZEP-1026] net/yaip/nbuf: net_nbuf_read does not handle the offset parameter correctly
https://jira.zephyrproject.org/browse/ZEP-1026

[ZEP-1025] Unified kernel build sometimes breaks on a missing .d dependency file.
https://jira.zephyrproject.org/browse/ZEP-1025

[ZEP-724] build on windows failed: 'make: execvp: uname: File or path name too long'
https://jira.zephyrproject.org/browse/ZEP-724


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 1
[ZEP-779] (Fixed) Using current MinGW gcc version 5.3.0 breaks Zephyr build on Windows
https://jira.zephyrproject.org/browse/ZEP-779


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/5096 : zoap: Fix alignment of multiline function arguments
- https://gerrit.zephyrproject.org/r/5097 : iot/zoap: Add support for error 4.15

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4880 : nano_work: Add nano_work_pending
- https://gerrit.zephyrproject.org/r/4921 : lib/http: Add test-case for HTTP header fields
- https://gerrit.zephyrproject.org/r/4920 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/5084 : DO NOT MERGE: tests: Add linker alignment check
- https://gerrit.zephyrproject.org/r/5010 : fs: Cleanup and reduce Kconfig flags used by file system
- https://gerrit.zephyrproject.org/r/4917 : iot/zoap: Port to the new network stack
- https://gerrit.zephyrproject.org/r/4915 : build: Support for integrating third party build systems
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/5024 : arm: nordic_nrf5: Select clock control for BLE controller
- https://gerrit.zephyrproject.org/r/5023 : drivers: clock_control: Add nRF5x Series SoC clock driver
- https://gerrit.zephyrproject.org/r/5064 : doc: yaip: Add a Network Management API usage document
- https://gerrit.zephyrproject.org/r/4871 : util.h: Add DEFINED() macro for expresion-legal ifdef-checking
- https://gerrit.zephyrproject.org/r/5083 : daily: enable sanitycheck for unified kernel
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- https://gerrit.zephyrproject.org/r/5077 : net: yaip: Fix net_nbuf_read corner cases
- https://gerrit.zephyrproject.org/r/4983 : unified: Add k_work_pending
- https://gerrit.zephyrproject.org/r/4984 : unified: Don't assert if work is pending on submit
- https://gerrit.zephyrproject.org/r/4881 : nano_work: Don't assert if work is pending on submit

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5095 : unified: fix misc issues with APIs in kernel.h
- https://gerrit.zephyrproject.org/r/5094 : unified: use correct init macro for k_fifo objects
- https://gerrit.zephyrproject.org/r/5093 : slist: add static initialization macro
- https://gerrit.zephyrproject.org/r/4931 : x86 link: Specify ALIGN_WITH_INPUT for XIP data sections
- https://gerrit.zephyrproject.org/r/4930 : link: Add section size validity checker
- https://gerrit.zephyrproject.org/r/4818 : iot/zoap: Add helpers for dealing with integer options
- https://gerrit.zephyrproject.org/r/4817 : iot/zoap: Add port information to network addresses
- https://gerrit.zephyrproject.org/r/4819 : tests/zoap: Add tests for the observe feature
- https://gerrit.zephyrproject.org/r/4816 : iot/zoap: Add support for observing resources
- https://gerrit.zephyrproject.org/r/5058 : samples/zoap_client: Make it work with zoap-server
- https://gerrit.zephyrproject.org/r/5059 : samples/zoap-server: Add a README.txt to zoap-server
- https://gerrit.zephyrproject.org/r/5060 : samples/zoap-client: Add a README.txt to zoap-client
- https://gerrit.zephyrproject.org/r/4354 : ztest: Add documentation
- https://gerrit.zephyrproject.org/r/4450 : tests: Add gcov support
- https://gerrit.zephyrproject.org/r/4355 : ztest: Add simple integration and unit tests
- https://gerrit.zephyrproject.org/r/4356 : tests: convert tests/net/buf to the new framework
- https://gerrit.zephyrproject.org/r/4357 : tests: Add a sample for testing natively
- https://gerrit.zephyrproject.org/r/4118 : tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4353 : ztest: Add native building support
- https://gerrit.zephyrproject.org/r/4855 : win-doc: Adds the dependency with the pthread library
- https://gerrit.zephyrproject.org/r/5037 : boards: Rename the nRF52 Nitrogen to 96Boards Nitrogen
- https://gerrit.zephyrproject.org/r/4844 : win-doc: Add recommendation for regex library configuration
- https://gerrit.zephyrproject.org/r/5087 : toolchain: Make ALIAS_OF() macro public
- https://gerrit.zephyrproject.org/r/5088 : toolchain: Use ALIAS_OF() in FUNC_ALIAS() macro
- https://gerrit.zephyrproject.org/r/5069 : net: buf: Allow head deletion with net_buf_frag_del()
- https://gerrit.zephyrproject.org/r/5076 : net: buf: Allow NULL head pointer when inserting to frag list


Re: Nanokernel stack border protection

LeMay, Michael <michael.lemay@...>
 

Of course, this wouldn't necessarily catch all stack overflows, specifically those on the unsafe stack.

-----Original Message-----
From: LeMay, Michael [mailto:michael.lemay(a)intel.com]
Sent: Friday, September 30, 2016 15:02
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: Nanokernel stack border protection

On Mon, 2016-09-26 at 17:33 +0000, Boie, Andrew P wrote:
...
Yeah it's probably a dealbreaker. In C you can take the address of some stack
variable and pass it to another function, stack references seem to really need to
be on the data segment. Oh well. I think I have to conclude that this kind of
stack bounds checking isn't possible on x86 at least in C code.

This is possible on x86 with C. I already have it working for Contiki OS with an
enhanced version of LLVM/Clang. It relies in part on the LLVM SafeStack pass
that defines a separate "unsafe stack" for allocations that the compiler is unable
to verify are accessed safely (http://clang.llvm.org/docs/SafeStack.html). So,
only stack allocations that the compiler verifies are accessed safely are placed
on the main/safe stack. I developed a patch for Contiki OS to place tight bounds
around the safe stack in SS. I configured CS, DS, ES, FS, and GS to not overlap
with SS, and I placed the unsafe stack in DS. I dealt with the challenge of
handling stack references passed between functions by modifying the SafeStack
pass to move all allocations used in that way to the unsafe stack
(https://reviews.llvm.org/D17094). The compiler can then assume that no
pointers to the safe stack are passed as function arguments. Safe stack pointers
are only generated locally, within the same function that uses those pointers.
There are some exceptions to this, like variadic argument lists, but those are
handled specially. Based on the assumption that safe stack pointers are all
generated and used within a function, I developed a new compiler pass that
tracks the flow of safe stack pointers within a function
(https://reviews.llvm.org/D17095, https://reviews.llvm.org/D17092). It adds
segment override prefixes as necessary to direct memory accesses to the
appropriate segments.

6401 - 6420 of 8046