Date   

Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 2
[ZEP-240] printk/printf usage in samples
https://jira.zephyrproject.org/browse/ZEP-240

[ZEP-454] Add driver API reentrancy support to UART shim drivers
https://jira.zephyrproject.org/browse/ZEP-454


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4996 : ieee802154_cc2520: Correct debug output
- https://gerrit.zephyrproject.org/r/4993 : ieee802154_cc2520: Improve error logging
- https://gerrit.zephyrproject.org/r/4986 : net: yaip: Do not source contiki headers always
- https://gerrit.zephyrproject.org/r/5000 : net: tests: Add RA message unit tests.
- https://gerrit.zephyrproject.org/r/4999 : net: yaip: Adopt new nbuf API's to RA message handlers.
- https://gerrit.zephyrproject.org/r/4995 : ieee802154_cc2520_legacy: Implement set short address
- 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/4994 : ieee802154_cc2520_legacy: Improve debugging for the driver
- https://gerrit.zephyrproject.org/r/4992 : toolchain: Add BUILD_ASSERT macro for compile-time checks
- https://gerrit.zephyrproject.org/r/4989 : Bluetooth: init: Add HFP to automated tests
- https://gerrit.zephyrproject.org/r/4990 : doc: Update the device power management API documentation
- https://gerrit.zephyrproject.org/r/4980 : device: Consolidate DEVICE_ and SYS_* macros
- 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/4979 : power_mgmt: Reduce complexity in handling of power hooks
- https://gerrit.zephyrproject.org/r/4976 : pinmux: remove unused pinmux_drv.h
- https://gerrit.zephyrproject.org/r/4974 : pinmux: quark_d2000: use pinmux driver instead of own functions
- https://gerrit.zephyrproject.org/r/4975 : pinmux: arduino 101: use pinmux driver
- https://gerrit.zephyrproject.org/r/4973 : pinmux: rename pinmux driver local header
- https://gerrit.zephyrproject.org/r/4977 : pinmux: quark_se_c1000: use pinmux driver and APIs
- https://gerrit.zephyrproject.org/r/4971 : pinmux: remove confusing pinmux_dev and implement as main driver
- https://gerrit.zephyrproject.org/r/4972 : pinmux: fix driver api and style
- https://gerrit.zephyrproject.org/r/4970 : pinmux: remove nonexistant galileo Kconfig

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: BR/EDR: Refactor distribution of security procedure status
- https://gerrit.zephyrproject.org/r/4952 : Bluetooth: HFP HF: Fix getting inaccessible internal
- https://gerrit.zephyrproject.org/r/2255 : rfc: unified kernel
- https://gerrit.zephyrproject.org/r/4555 : Bluetooth: HFP HF: SLC connection-Send/Parse BRSF
- https://gerrit.zephyrproject.org/r/4486 : Bluetooth: SDP: Server: Initialize and accept incoming connections
- https://gerrit.zephyrproject.org/r/4916 : net: yaip: Fix copying incorrect byte order address field
- 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/4951 : Bluetooth: HFP HF: Enforce Kconfig's HFP_HF relation to RFCOMM
- https://gerrit.zephyrproject.org/r/4511 : unified/doc: Kernel primer for unified kernel
- https://gerrit.zephyrproject.org/r/4968 : tests: remove redundant PRINT definition
- https://gerrit.zephyrproject.org/r/4959 : x86: interrupts: optimize and simplify IRQ stubs

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4991 : Bluetooth: Controller: Fix __packed placement
- https://gerrit.zephyrproject.org/r/4988 : Bluetooth: Controller: Remove unused macro
- https://gerrit.zephyrproject.org/r/4985 : net: yaip: cc2520: Fix setting proper IEEE 802.15.4 address
- https://gerrit.zephyrproject.org/r/4978 : remove unused whitespace in arch/arc/core/fault_s.S
- https://gerrit.zephyrproject.org/r/4943 : Bluetooth: L2CAP: Cleanup flags names for BR/EDR channels
- https://gerrit.zephyrproject.org/r/4874 : Bluetooth: RFCOMM: Handle dlc disconnection from peer
- https://gerrit.zephyrproject.org/r/4953 : Bluetooth: tester: Fix advertising data


Re: Nanokernel stack border protection

Benjamin Walsh <benjamin.walsh@...>
 

On Mon, Sep 26, 2016 at 05:34:55PM +0800, Tidy(ChunHua) Jiang wrote:
Un...
I mean the nanokernel’s stack object type, not the system's stack.
"stack" is such an overloaded term. :-)

FYI, the unified kernel version k_stack_push() has an __ASSERT() that
checks the limit.

The approach we are taking for kernel APIs is: if it's a user error, use
an __ASSERT(); otherwise, return an error code.

Pushing more than the limit on a stack object is considered a user
error.

Refer https://www.zephyrproject.org/doc/1.5.0/kernel/nanokernel/nanokernel_stacks.html

At 2016-09-26 17:14:52, "D'alton, Alexandre" <alexandre.dalton(a)intel.com> wrote:
Hi,

FIY, ARC has this implemented (see CONFIG_ARC_STACK_CHECKING)
And it is more than useful !

Regards,
Alex.

-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Monday, September 26, 2016 11:01 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Nanokernel stack border protection

On Sun, 2016-09-25 at 10:08 +0000, Boie, Andrew P wrote:
On Sat, 2016-09-24 at 14:39 +0800, tidyjiang(a)163.com wrote:
Hi All,

The nanokernel uses an array as stack memory space, but there is no
border protection when push data to the stack. When the array is
already full, it will cause array overfow, leading to unpredictable
behavior.

Why not add the border protection? When the array is full, it
returns an error code to user.

Is it necessary ?
How would you propose to implement such a border protection?
Use the features provided by the CPU? On ARM Cortex-M, the stack limit
registers PSPLIM and MSPLIM. Presumably other CPUs have similar things.

--
Tixy
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

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.
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Re: Timer utility function to use single timer

Benjamin Walsh <benjamin.walsh@...>
 

In Zephyr there will be a chance to run out of timers at times and
we will not get the timer handle to use for our modules.

Means whenever we required a timer for our module we can call a
timer API defined in zephyr (i.e.
*task_timer_alloc(),task_timer_start(),task_timer_stop, etc*)
I'm a little curious about this API design too. AFAICT, it's always
legal to statically allocate a k_timer struct of your own and
initialize and use it at runtime. If you need to know you won't run
out of timers, you can be guaranteed not to lose this one.

The allocate/free API looks like it's just a convenience wrapper to
allow sharing of timer objects between usages if you know they
aren't all going to be needed simultaneously.
The main reason we still have k_timer_alloc and k_timer_free is to
support the legacy APIs task_timer_alloc and task_timer_free.

How about making the allocation/freeing of timers hidden, and only there
to support the legacy API ? The paradigm for the unified kernel would
then be "use statically allocated timers".

As you mentioned it's always legal to statically allocate a k_timer
struct of your own and initialize and use it at runtime. But suppose
we allocated 10 timer structure and now if we make another call to
initialize 1 more timer structure it will fail. How to handle that
issue. If more than 10 timers are required in a module then statically
we cannot allocate more than 10 timer in a given time. Is there any
implementation or patch available to have only 1 timer structure
initialized in the beginning and simulate all the other timer request
coming from above and satisfy them by maintaining only 1 timer
internally without actually requesting more timer to the zephyr OS.
This will reduce the timer request to zephyr OS and will not have the
risk of running out of the timers.

The problem though, is that to get this facility Zephyr allocates 10
(by default) k_timer objects in a pool and shares only those.
Obviously Zephyr has no heap, so it can't share the memory as
anything but timers. And these aren't tiny objects. My quick
manual count says that they're 64 bytes a piece, so that's half a kb
of RAM that we're allocating in every default-configured app just to
save a handful of bytes in apps that want to use the "sharing"
convenience API. That seems like a bad trade to me.

Would anyone object to a patch that set CONFIG_NUM_DYNAMIC_TIMERS to
zero by default and disabled the API unless it was 1 or greater? Or
maybe deprecating it for future removal?


Re: Nanokernel stack border protection

Tidy(ChunHua) Jiang <tidyjiang@...>
 

Un...
I mean the nanokernel’s stack object type, not the system's stack.
Refer https://www.zephyrproject.org/doc/1.5.0/kernel/nanokernel/nanokernel_stacks.html

At 2016-09-26 17:14:52, "D'alton, Alexandre" <alexandre.dalton(a)intel.com> wrote:
Hi,

FIY, ARC has this implemented (see CONFIG_ARC_STACK_CHECKING)
And it is more than useful !

Regards,
Alex.

-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Monday, September 26, 2016 11:01 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Nanokernel stack border protection

On Sun, 2016-09-25 at 10:08 +0000, Boie, Andrew P wrote:
On Sat, 2016-09-24 at 14:39 +0800, tidyjiang(a)163.com wrote:
Hi All,

The nanokernel uses an array as stack memory space, but there is no
border protection when push data to the stack. When the array is
already full, it will cause array overfow, leading to unpredictable
behavior.

Why not add the border protection? When the array is full, it
returns an error code to user.

Is it necessary ?
How would you propose to implement such a border protection?
Use the features provided by the CPU? On ARM Cortex-M, the stack limit
registers PSPLIM and MSPLIM. Presumably other CPUs have similar things.

--
Tixy
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

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.


Re: Nanokernel stack border protection

D'alton, Alexandre <alexandre.dalton@...>
 

Hi,

FIY, ARC has this implemented (see CONFIG_ARC_STACK_CHECKING)
And it is more than useful !

Regards,
Alex.

-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Monday, September 26, 2016 11:01 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Nanokernel stack border protection

On Sun, 2016-09-25 at 10:08 +0000, Boie, Andrew P wrote:
On Sat, 2016-09-24 at 14:39 +0800, tidyjiang(a)163.com wrote:
Hi All,

The nanokernel uses an array as stack memory space, but there is no
border protection when push data to the stack. When the array is
already full, it will cause array overfow, leading to unpredictable
behavior.

Why not add the border protection? When the array is full, it
returns an error code to user.

Is it necessary ?
How would you propose to implement such a border protection?
Use the features provided by the CPU? On ARM Cortex-M, the stack limit
registers PSPLIM and MSPLIM. Presumably other CPUs have similar things.

--
Tixy
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

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.


Re: Nanokernel stack border protection

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

On Sun, 2016-09-25 at 10:08 +0000, Boie, Andrew P wrote:
On Sat, 2016-09-24 at 14:39 +0800, tidyjiang(a)163.com wrote:
Hi All,

The nanokernel uses an array as stack memory space, but there is no
border protection when push data to the stack. When the array is
already full, it will cause array overfow, leading to unpredictable
behavior.

Why not add the border protection? When the array is full, it returns
an error code to user.

Is it necessary ?
How would you propose to implement such a border protection?
Use the features provided by the CPU? On ARM Cortex-M, the stack limit
registers PSPLIM and MSPLIM. Presumably other CPUs have similar things.

--
Tixy


Re: Galileo Gen 1 GPIO

Gottfried F. Zojer
 

Tomasz,

Thanks for your clarification.Code example and particularly Quark documents
helped to understand.Inclusive this external side (
http://hackerboards.com/intel-aims-15-dollar-quark-d2000-dev-kit-at-iot-devices/
)

Best regards

Gottfried

On Tue, Sep 20, 2016 at 4:01 PM, Tomasz Bursztyka <
tomasz.bursztyka(a)linux.intel.com> wrote:

Hi Gottfried,

Using this Cypress chip is a mandatory support as a low level pinmuxing
driver
if you want to configure and use the hardware pins, the ones exposed as
arduino compatible.
Your use case of inserting an arduino shield is exactly one of those which
will fail.

If you take a look here: http://www.intel.com/content/
www/us/en/embedded/products/galileo/galileo-g1-datasheet.html
You'll see the grey boxes "MUX": this is about this chip.

The mapping: http://download.intel.com/support/galileo/sb/
galileoiomappingrev2.pdf

It is the same story for Gen 2, but the chip is different. Take a look at
boards/galileo/pinmux*
(and drivers/gpio/gpio_pcal9535a.c).

About USB, Zephyr as a low level usb API. I know it works for Quark SE
SoC, but not Quark x1000 (Galileo's).
It could be the same controller, I don't know if anyone has tried.

Tomasz

Tomasz,

Thanks for your answer.Like Fabio I also want to use Galieo v1 board but
not really certain about your answer and what
type of restrictions you are talking about.Myself I will not use Cypress
so maybe your answer would be different.
But it would be nice to know what GPIO restrictions are there on Galileo
v1
Playing around with busybox on Galileo was cool but would love to connect
2 devices to it ( one usb-host ,one arduino shield ).I am well aware that
you work for zephyr and not Galileo

Br

Gottfried
.

On Mon, Sep 19, 2016 at 7:37 AM, Tomasz Bursztyka <
tomasz.bursztyka(a)linux.intel.com> wrote:

Hi Fábio,

Unfortunately, we do not support Galileo v1 pinmuxing, thus: the whole
board is basically unusable at this stage.
You won't be able to get very far unless you provide the cypress chip
driver.

Can you use another board? We support quite a few (see boards directory
in zephyr's tree)

Br,

Tomasz



Dear Sirs,
I am using Galileo Gen 1 (Cypress I/O expander) and I can not change
the GPIO levels.
What GPIO driver should I set in menuconfig tool (DesignWare,
PCAL9535, MMIO, Intel SCH)?
What driver name and pin numbers should I use in functions API
(gpio_pin_configure, gpio_pin_write, ....)?
Thank you very much.


Re: [RFC]PWM API Update

Tomasz Bursztyka
 

Hi Baohong,

static inline int pwm_pin_set(struct device *dev, uint32_t pwm,
uint32_t period_cycles, uint32_t pulse_cycles);

static inline int pwm_pin_set_usec(struct device *dev, uint32_t pwm,
uint32_t period_usec, uint32_t pulse_usec);

Note: implementation of pwm_pin_set_usec API shall convert the
input (in usec) to cycles and then call pwm_pin_set.

I felt that get_cycles_per_sec() is not needed since there are already
constant definition for this. (e.g. CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC
in boards/arduino_101_sss/arduino_101_sss_defconfig).
Actually, this might be true if the PWM device is on the SoC and/or it's
controller clocked
at same speed. But I think this is still needed if the PWM device is
external, and clocked
differently. (external clock source for it, etc etc...) Don't you think so?

Br,

Tomasz


Re: Timer utility function to use single timer

Bag, Amit K <amit.k.bag@...>
 

Hi Ross,

As you mentioned it's always legal to statically allocate a k_timer struct of your own and initialize and use it at runtime. But suppose we allocated 10 timer structure and now if we make another call to initialize 1 more timer structure it will fail. How to handle that issue. If more than 10 timers are required in a module then statically we cannot allocate more than 10 timer in a given time. Is there any implementation or patch available to have only 1 timer structure initialized in the beginning and simulate all the other timer request coming from above and satisfy them by maintaining only 1 timer internally without actually requesting more timer to the zephyr OS. This will reduce the timer request to zephyr OS and will not have the risk of running out of the timers.


Thanks & Regards,
Amit Bag

-----Original Message-----
From: Ross, Andrew J
Sent: Friday, September 23, 2016 10:11 PM
To: Bag, Amit K <amit.k.bag(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Timer utility function to use single timer

Bag, Amit K wrote:
In Zephyr there will be a chance to run out of timers at times and we
will not get the timer handle to use for our modules.

Means whenever we required a timer for our module we can call a timer
API defined in zephyr (i.e.
*task_timer_alloc(),task_timer_start(),task_timer_stop, etc*)
I'm a little curious about this API design too. AFAICT, it's always legal to statically allocate a k_timer struct of your own and initialize and use it at runtime. If you need to know you won't run out of timers, you can be guaranteed not to lose this one.

The allocate/free API looks like it's just a convenience wrapper to allow sharing of timer objects between usages if you know they aren't all going to be needed simultaneously.

The problem though, is that to get this facility Zephyr allocates 10 (by default) k_timer objects in a pool and shares only those.
Obviously Zephyr has no heap, so it can't share the memory as anything but timers. And these aren't tiny objects. My quick manual count says that they're 64 bytes a piece, so that's half a kb of RAM that we're allocating in every default-configured app just to save a handful of bytes in apps that want to use the "sharing" convenience API. That seems like a bad trade to me.

Would anyone object to a patch that set CONFIG_NUM_DYNAMIC_TIMERS to zero by default and disabled the API unless it was 1 or greater? Or maybe deprecating it for future removal?

Andy


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 1
[ZEP-905] hello_world compilation for arduino_due target fails when using CROSS_COMPILE
https://jira.zephyrproject.org/browse/ZEP-905


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 3
[ZEP-950] (Fixed) USB: Device is not listed by USB20CV test suite
https://jira.zephyrproject.org/browse/ZEP-950

[ZEP-968] (Duplicate) Sanity doesnt build 'samples/usb/cdc_acm' with assertions (-R)
https://jira.zephyrproject.org/browse/ZEP-968

[ZEP-969] (Duplicate) Sanity doesnt build 'samples/bluetooth/btusb' with assertions (-R)
https://jira.zephyrproject.org/browse/ZEP-969


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4968 : tests: remove redundant PRINT definition

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4960 : x86: don't unconditionally run ISRs with interrupts enabled
- https://gerrit.zephyrproject.org/r/4915 : build: Support for integrating third party build systems

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4946 : Bluetooth: RFCOMM: Shuffle up Kconfig's RFCOMM_L2CAP_MTU
- https://gerrit.zephyrproject.org/r/4950 : Bluetooth: Add debug keys support to HCI ECC emulation code
- https://gerrit.zephyrproject.org/r/4919 : Bluetooth: Controller: Use net_buf for evt and ACL RX
- https://gerrit.zephyrproject.org/r/4949 : Bluetooth: SMP: Fix unused static variable
- https://gerrit.zephyrproject.org/r/4948 : Bluetooth: SMP: Remove unused static const
- https://gerrit.zephyrproject.org/r/4962 : irq: Use lowest priority not a hard-coded priority 2
- https://gerrit.zephyrproject.org/r/4965 : mvic: fixed printk format
- https://gerrit.zephyrproject.org/r/4964 : usb: do not assert on a variable we do not have
- https://gerrit.zephyrproject.org/r/4961 : irq: _ARC_V2_DEF_IRQ_LEVEL should be set to last legal priority
- https://gerrit.zephyrproject.org/r/4966 : samples: remove unused MDEF file


Re: Nanokernel stack border protection

Tidy(ChunHua) Jiang <tidyjiang@...>
 

Hi Andrew,

Yeah, we can't really implement such function in fact, but we can and just return an error code to user. I think it's better than now.


Thx & Rgds.
Tidy.

At 2016-09-25 18:08:33, "Boie, Andrew P" <andrew.p.boie(a)intel.com> wrote:
On Sat, 2016-09-24 at 14:39 +0800, tidyjiang(a)163.com wrote:
Hi All,

The nanokernel uses an array as stack memory space, but there is no
border protection when push data to the stack. When the array is
already full, it will cause array overfow, leading to unpredictable
behavior.

Why not add the border protection? When the array is full, it returns
an error code to user.

Is it necessary ?
How would you propose to implement such a border protection?

Andrew


Re: Nanokernel stack border protection

Boie, Andrew P
 

On Sat, 2016-09-24 at 14:39 +0800, tidyjiang(a)163.com wrote:
Hi All,

The nanokernel uses an array as stack memory space, but there is no
border protection when push data to the stack. When the array is
already full,  it will cause array overfow, leading to unpredictable
behavior. 

Why not add the border protection? When the array is full, it returns
an error code to user. 

Is it necessary ?
How would you propose to implement such a border protection?

Andrew


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 9
[ZEP-965] Supervisory and Monitoring Task
https://jira.zephyrproject.org/browse/ZEP-965

[ZEP-966] need support for EM7D SOC on em_starterkit
https://jira.zephyrproject.org/browse/ZEP-966

[ZEP-964] Add a (hidden?) Kconfig option for disabling legacy API
https://jira.zephyrproject.org/browse/ZEP-964

[ZEP-963] Consolidate different versions of DEVICE_* and SYS_* macros
https://jira.zephyrproject.org/browse/ZEP-963

[ZEP-961] samples: other cases cannot execute after run aon_counter case
https://jira.zephyrproject.org/browse/ZEP-961

[ZEP-962] Quark SE C1000 GPIO30 is always high.
https://jira.zephyrproject.org/browse/ZEP-962

[ZEP-967] Sanity doesnt build 'samples/usb/dfu' with assertions (-R)
https://jira.zephyrproject.org/browse/ZEP-967

[ZEP-970] Sanity doesnt build 'tests/kernel/test_build' with assertions (-R)
https://jira.zephyrproject.org/browse/ZEP-970

[ZEP-971] no unit tests exist for CONFIG_DEBUG_INFO
https://jira.zephyrproject.org/browse/ZEP-971


UPDATED JIRA items within last 24 hours: 7
[ZEP-814] Routing Metrics used in Path Selection
https://jira.zephyrproject.org/browse/ZEP-814

[ZEP-815] Objective Function Zero for RPL
https://jira.zephyrproject.org/browse/ZEP-815

[ZEP-816] Minimum Rank with Hysteresis (RPL)
https://jira.zephyrproject.org/browse/ZEP-816

[ZEP-328] HW Encryption Abstraction
https://jira.zephyrproject.org/browse/ZEP-328

[ZEP-914] Improving locking algorithms in kernel objects
https://jira.zephyrproject.org/browse/ZEP-914

[ZEP-911] Refine thread priorities & locking
https://jira.zephyrproject.org/browse/ZEP-911

[ZEP-606] Doc files deleted from gerrit aren't deleted from website
https://jira.zephyrproject.org/browse/ZEP-606


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 7
[ZEP-811] (Fixed) The Trickle Algorithm
https://jira.zephyrproject.org/browse/ZEP-811

[ZEP-906] (Fixed) [unified] Add scheduler time slicing support
https://jira.zephyrproject.org/browse/ZEP-906

[ZEP-954] (Fixed) Update device PM API to allow setting additional power states
https://jira.zephyrproject.org/browse/ZEP-954

[ZEP-767] (Fixed) Add FS API to flush cache of an open file
https://jira.zephyrproject.org/browse/ZEP-767

[ZEP-635] (Fixed) Add FS API to grow a file
https://jira.zephyrproject.org/browse/ZEP-635

[ZEP-636] (Fixed) Add FS API to get volume total and free space
https://jira.zephyrproject.org/browse/ZEP-636

[ZEP-622] (Fixed) Add FS API to truncate/shrink a file
https://jira.zephyrproject.org/browse/ZEP-622


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4966 : samples: remove unused MDEF file
- https://gerrit.zephyrproject.org/r/4962 : irq: Use lowest priority not a hard-coded priority 2
- https://gerrit.zephyrproject.org/r/4965 : mvic: fixed printk format
- https://gerrit.zephyrproject.org/r/4964 : usb: do not assert on a variable we do not have
- https://gerrit.zephyrproject.org/r/4961 : irq: _ARC_V2_DEF_IRQ_LEVEL should be set to last legal priority
- https://gerrit.zephyrproject.org/r/4959 : x86: interrupts: optimize and simplify IRQ stubs
- https://gerrit.zephyrproject.org/r/4963 : samples: pwm: use new API interface
- https://gerrit.zephyrproject.org/r/4960 : x86: don't unconditionally run ISRs with interrupts enabled
- https://gerrit.zephyrproject.org/r/4955 : segmentation.h: fix get_gdt/get_idt
- https://gerrit.zephyrproject.org/r/4953 : Bluetooth: tester: Fix advertising data
- https://gerrit.zephyrproject.org/r/4952 : Bluetooth: HFP HF: Fix build failed if BT_DBG is defined
- https://gerrit.zephyrproject.org/r/4951 : Bluetooth: HFP HF: Enforce Kconfig's HFP_HF relation to RFCOMM

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4919 : Bluetooth: Controller: Use net_buf for evt and ACL RX
- https://gerrit.zephyrproject.org/r/4933 : pwm: qmsi_shim: implement pwm driver required by new APIs
- https://gerrit.zephyrproject.org/r/4883 : sanity: enable sanity multiple configuration
- https://gerrit.zephyrproject.org/r/4858 : drivers: pwm: re-design pwm API interfaces
- https://gerrit.zephyrproject.org/r/4882 : util: adds downstream failure check script
- https://gerrit.zephyrproject.org/r/4844 : win-doc: Add recommendation for regex library configuration
- https://gerrit.zephyrproject.org/r/4855 : win-doc: Adds the dependency with the pthread library
- https://gerrit.zephyrproject.org/r/4896 : Dining philosophers demo for unified kernel.
- https://gerrit.zephyrproject.org/r/4892 : unified: Invoke kernel object initialization with SYS_INIT macro
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/4893 : unified: Build kernel objects as a static library
- https://gerrit.zephyrproject.org/r/4881 : nano_work: Don't assert if work is pending on submit
- https://gerrit.zephyrproject.org/r/4890 : unified: Enable tickless idle test
- https://gerrit.zephyrproject.org/r/4868 : unified: Add tickless idle support for x86
- https://gerrit.zephyrproject.org/r/4889 : unified: Add tickless idle support for ARM
- https://gerrit.zephyrproject.org/r/4948 : Bluetooth: SMP: Remove unused static const
- https://gerrit.zephyrproject.org/r/4950 : Bluetooth: Add debug keys support to HCI ECC emulation code
- https://gerrit.zephyrproject.org/r/4949 : Bluetooth: SMP: Fix unused static variable

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4954 : k_timer: Don't allocate dynamic timers by default
- https://gerrit.zephyrproject.org/r/4932 : x86: add _init_irq_gate and use it in gen_idt
- https://gerrit.zephyrproject.org/r/4867 : unified: Eliminate useless check in idle thread
- https://gerrit.zephyrproject.org/r/4895 : unified: implement k_uptime_{get,delta}()
- https://gerrit.zephyrproject.org/r/4863 : unified: Remove references to obsolete task_timeout
- https://gerrit.zephyrproject.org/r/4864 : unified: Remove obsolete wait_q.h macros
- https://gerrit.zephyrproject.org/r/4865 : unified: Remove #if 0 code block from wait_q.h
- https://gerrit.zephyrproject.org/r/4894 : unified: move basic ticks-to-ms conversion to kernel.h
- https://gerrit.zephyrproject.org/r/4862 : unified: Replace _nano_get_earliest_deadline()
- https://gerrit.zephyrproject.org/r/4866 : unified: Remove unused _nano_get_earliest_deadline()
- https://gerrit.zephyrproject.org/r/4926 : unified: Remove check in _reschedule_threads()
- https://gerrit.zephyrproject.org/r/4929 : apic: set initial PM state at build time
- https://gerrit.zephyrproject.org/r/4924 : ioapic: make init-time RTE masking optional
- https://gerrit.zephyrproject.org/r/4870 : unified: Make test_pend unified capable.
- https://gerrit.zephyrproject.org/r/4869 : unified: Add legacy task_offload_to_fiber() routine
- https://gerrit.zephyrproject.org/r/4928 : kernel: remove lingering irq_connect_dynamic() references
- https://gerrit.zephyrproject.org/r/4927 : init.h: use a counter when naming system devices
- https://gerrit.zephyrproject.org/r/4937 : net: yaip: Improve net_context_connect documentation
- https://gerrit.zephyrproject.org/r/4935 : net: yaip: cc2520: Let's provide ll addr in LE already
- https://gerrit.zephyrproject.org/r/4942 : net: yaip: Fix creating neighbour without l2addr
- https://gerrit.zephyrproject.org/r/4941 : net: yaip: Fix link address length calculation
- https://gerrit.zephyrproject.org/r/4944 : net: yaip: Fix handling ra_neighbor
- https://gerrit.zephyrproject.org/r/4945 : net: yaip: Fix handling onlink prefix
- https://gerrit.zephyrproject.org/r/4446 : rfc: ksdk: Add KSDK ENET driver.


Nanokernel stack border protection

Tidy(ChunHua) Jiang <tidyjiang@...>
 

Hi All,

The nanokernel uses an array as stack memory space, but there is no border protection when push data to the stack. When the array is already full, it will cause array overfow, leading to unpredictable behavior.

Why not add the border protection? When the array is full, it returns an error code to user.

Is it necessary ?

Thanks.


tidyjiang(a)163.com


Re: [RFC] Ring buffers

Boie, Andrew P
 

On Fri, 2016-09-23 at 14:56 -0700, Andy Ross wrote:
Benjamin Walsh wrote (on Friday, September 23, 2016 2:36PM):

I think that we should still have the code to under kernel/ though,
and rename APIs to k_ring_buf_<whatever>.
Naming isn't a big deal, but I'll reiterate my previous point: a ring
buffer is a data structure, not an OS abstraction provided by a
kernel.  It's equally useful to application or subsystem code, or I
dunno, Windows C++ apps.  It's not meaningfully a "Zephyr" thing.

I mean, the dlist implementation is used pervasively in the kernel,
but I don't think anyone would argue it belongs in kernel.h instead
include/misc/dlist.h.
I agree with Andy for reasons above, plus if you *did* move it, it
would be subject to our deprecation policy (maintain both APIs for two
releases with the old one marked __deprecated).

Andrew


Re: [RFC] Ring buffers

Andy Ross
 

Benjamin Walsh wrote (on Friday, September 23, 2016 2:36PM):
I think that we should still have the code to under kernel/ though,
and rename APIs to k_ring_buf_<whatever>.
Naming isn't a big deal, but I'll reiterate my previous point: a ring
buffer is a data structure, not an OS abstraction provided by a
kernel. It's equally useful to application or subsystem code, or I
dunno, Windows C++ apps. It's not meaningfully a "Zephyr" thing.

I mean, the dlist implementation is used pervasively in the kernel,
but I don't think anyone would argue it belongs in kernel.h instead
include/misc/dlist.h.

Andy


Re: [RFC] Ring buffers

Benjamin Walsh <benjamin.walsh@...>
 

On Fri, Sep 23, 2016 at 09:24:46PM +0000, Boie, Andrew P wrote:
On Fri, 2016-09-23 at 16:46 -0400, Dmitriy Korovkin wrote:
Next, when I was saying of making reading thread wait if the buffer
is 
empty and writing thread wait if there is no free space, this does
not 
resolve and does not intend to resolve the problem of several
concurrent 
threads trying to access the ring buffer - such a problem may be
resolved 
with mutexes.
I contend this doesn't belong in the base ring buffer implementation
either. I feel you are assuming that this policy of waiting is
appropriate for all situations and I disagree.

Ring buffers aren't just used in thread context. If an ISR wants to
stick something in the ring buffer, we can't wait here.

Also what if the thead would rather do something else than block if the
buffer is full? This is why the API returns -ENOSPC.

So I maintain that if you want to build something on top of base
ring_buffer.h for the common cases, that is fine, but don't assume they
are what's appropriate for all uses, the base API needs to stay how it
is.
Point taken, and entirely valid. We won't touch the functionality of the
ring buffers.

I think that we should still have the code to under kernel/ though, and
rename APIs to k_ring_buf_<whatever>.

6321 - 6340 of 7909