Date   

Re: [RFC]DMA API Update

Liu, Baohong
 

-----Original Message-----
From: Nallasellan, Singaravelan
Sent: Thursday, January 12, 2017 9:40 PM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC]DMA API Update

It is required to add slave or controller id which is 32 bits. Some DMA
Please attach document (datasheets for example) and point out which page/section
you were referring to.

controllers require to program mux to connect the hardware handshake
signals to the selected peripheral with the channel.
There are different names for this across SoCs. Dma_slot, handshake_interface...
I chose dma_slot. In other words, it has been taken care.


-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Thursday, January 12, 2017 1:20 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC]DMA API Update


Hi everyone,

I would like to propose the update for DMA API.
(https://jira.zephyrproject.org/browse/ZEP-873).

Known Problems
--------

Struct dma_channel_config consists of quite a few variables of enum
types, two callback function pointers, and one callback user data pointer.

- The enums can be collapsed into a bit field.
This will reduce the size of the data structure.

- The two callback function pointers (for normal and error cases) can
be combined.
A parameter of error code can be used to differentiate the two
cases. So, the
current callback parameter of user data pointer will be replaced by
two new
parameters. One for error code and the other one for channel id.

- Callback data pointer can be removed.
Currently, this field holds user data. It can be moved to driver
data structure.
The callback function can dig out the information from dev pointer and
channel id passed to it.

Proposed Solution
--------

-- The following are the enums we have now.

handshake_interface /* which peripheral and direction*/
hankshake_polarity /* high or low*/
channel_direction /* memory to memory, memory to peripheral ... */
Source_transfer_width /* source data size */
Destination_transfer_width /* destination data size */
Source_burst_length /* source burst length */
Destination_burst_length /* destination burst length */

All these will be collapsed into a bit field. Some of them will have new
names.

Besides the above, three new items will be added.
source_handshake /* HW or SW */
dest_handshake /* HW or SW */
channel_priority /* DMA channel priority */

-- For the callback function, there will be three parameters. They are
device pointer,
channel_id, and error code. As said above, the error callback
will be removed.

-- The callback_data pointer will be removed.

Final API Format
--------

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_data_size [ 10 : 12 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_data_size [ 13 : 15 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 16 : 18 ] --number of source data
unit(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 19 : 21 ] -- number of dest data
unit(1,4,8,16,32,64,128 and 256)
* source_handshake [ 22 ] --HW or SW
* dest_handshake [ 23 ] --HW or SW
* channel_priority [ 24 : 27 ] --DMA channel priority
* RESERVED [ 28 : 31 ]
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int
error_code); }

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API function prototypes:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

(Note: for xx_data_size and xx_burst_length in the above bit field,
the value will only serve as an index. For example, for
source_data_size, bit field values of 0, 1, 2, 3, 4 and 5 will
correspond to sizes of 8,16,32,64,128 and 256 bits.)

Suggestions and comments are welcome.


Re: reg: Routing SPI signals connected from x86 core to the Arc core

Liu, Baohong
 

Post 1.6. You need to use master. You do not need x86 at all.

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Friday, January 13, 2017 4:16 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: reg: Routing SPI signals connected from x86 core to the Arc core

Hi Liu

As you have stated below

"Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all"

Is this done in zephyr 1.6 ? Even AON_GPIO can I declare and use directly at ARC ?

Please Note we have connected bma255 at SPI lines of x86.


Best regards

Mahendravarman Rajarao

Mobil +919952921253
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, January 03, 2017 11:36 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: reg: Routing SPI signals connected from x86 core to the Arc core

Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all.

Please see the updated driver and sample app for BMI160 (top of the free, master).

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, January 3, 2017 4:24 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: Routing SPI signals connected from x86 core to the Arc core

Hi

We have connected an Accelerometer to the x86 core of C1000 (Quark_se) through SPI interface.
Interrupt line of accelerometer is also connected to the AON_GPIO_3

Now I need to route the SPI connection of x86 to Arc core. Is that possible ?

Any sample code in zephyr I can refer for this activity ?

Best regards
Mahendra


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 5
[ZEP-1571] Update "Changes from Version 1 Kernel" to include a "How-To Port Apps" section
https://jira.zephyrproject.org/browse/ZEP-1571

[ZEP-1568] Replace arm cortex_m scs and scb functionality with direct CMSIS-core calls
https://jira.zephyrproject.org/browse/ZEP-1568

[ZEP-1566] WDT: Interrupt is triggered multiple times @ARC
https://jira.zephyrproject.org/browse/ZEP-1566

[ZEP-1569] net/tcp: TCP in server mode doesn't support multiple concurrent connections
https://jira.zephyrproject.org/browse/ZEP-1569

[ZEP-1570] net/tcp: TCP in server mode is unable to close client connections
https://jira.zephyrproject.org/browse/ZEP-1570


UPDATED JIRA items within last 24 hours: 9
[ZEP-822] Simple Network Management Protocol v2
https://jira.zephyrproject.org/browse/ZEP-822

[ZEP-813] RPL: IPv6 Routing Protocol
https://jira.zephyrproject.org/browse/ZEP-813

[ZEP-799] HTTP over TLS
https://jira.zephyrproject.org/browse/ZEP-799

[ZEP-216] LWM2M for device management
https://jira.zephyrproject.org/browse/ZEP-216

[ZEP-831] ICMPv6 "Packet Too Big" support
https://jira.zephyrproject.org/browse/ZEP-831

[ZEP-759] Add preliminary support for Atmel SAM E70 (Cortex-M7) chipset family and SAM E70 Xplained board
https://jira.zephyrproject.org/browse/ZEP-759

[ZEP-1492] Add Atmel SAM family GMAC Ethernet driver
https://jira.zephyrproject.org/browse/ZEP-1492

[ZEP-1507] fxos8700 broken gpio_callback implementation
https://jira.zephyrproject.org/browse/ZEP-1507

[ZEP-1548] Python script invocation is inconsistent
https://jira.zephyrproject.org/browse/ZEP-1548


CLOSED JIRA items within last 24 hours: 1
[ZEP-1274] (Won't Do) galileo has pinmux driver in boards/x86/galileo/, while all the rest in drivers/pinmux/
https://jira.zephyrproject.org/browse/ZEP-1274


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9964 : Xtensa port: Added board configuration files for the Xtensa simulator paltform.
- https://gerrit.zephyrproject.org/r/9960 : Xtensa port: Started port to for Xtensa cores family.
- https://gerrit.zephyrproject.org/r/9963 : Bluetooth: Introduce a new connection parameter request callback
- https://gerrit.zephyrproject.org/r/9937 : net: tcp: Get rid of `recv_mss` field from TCP struct
- https://gerrit.zephyrproject.org/r/9936 : net: tcp: Remove unused `recv_ack` field from TCP context
- https://gerrit.zephyrproject.org/r/9931 : net: tcp: Ensure `recv_mss` won't overflow if interface MTU is <40
- https://gerrit.zephyrproject.org/r/9929 : net: tcp: Ensure all timers are disposed of when releasing context
- https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS
- https://gerrit.zephyrproject.org/r/9940 : net: tcp: Destroy net_tcp struct at the same time as the context
- https://gerrit.zephyrproject.org/r/9935 : net: tcp: Pass correct user_data pointers
- https://gerrit.zephyrproject.org/r/9941 : net: tcp: Don't ACK inbound FIN packets
- https://gerrit.zephyrproject.org/r/9948 : net: tcp: in tcp_establish save TCP flags for post-processing use
- https://gerrit.zephyrproject.org/r/9926 : drivers: slip: Just unref, don't destroy sent buf chains
- https://gerrit.zephyrproject.org/r/9938 : drivers: bmi160: add sample ready check
- https://gerrit.zephyrproject.org/r/9939 : samples: bmi160: reduce polling mode sampling frequency
- https://gerrit.zephyrproject.org/r/9928 : net: tcp: Also signal EOF with a negative status code
- https://gerrit.zephyrproject.org/r/9944 : net: tcp: Reduce size of `state` member from 32 to 4 bits
- https://gerrit.zephyrproject.org/r/9924 : arm: cmsis: covert aircr
- https://gerrit.zephyrproject.org/r/9930 : net: tcp: Use an uint8_t for retry timeout instead of an uin32_t
- https://gerrit.zephyrproject.org/r/9950 : net: tcp: handle TCP_FIN after processing any data in the buffer
- https://gerrit.zephyrproject.org/r/9949 : net: tcp: skip processing of TCP_ACK buffers
- https://gerrit.zephyrproject.org/r/9953 : Bluetooth: RFCOMM: Implement Aggregate Flow Control
- https://gerrit.zephyrproject.org/r/9923 : arm: cmsis: convert systick to CMSIS
- https://gerrit.zephyrproject.org/r/9951 : net: tcp: don't assume TCP_FIN buffers are NET_DROP
- https://gerrit.zephyrproject.org/r/9952 : net: tcp: if buffer is TCP_FIN increment send_ack by 1
- https://gerrit.zephyrproject.org/r/9945 : kernel: add user data API to timers
- https://gerrit.zephyrproject.org/r/9947 : tests/pwm: add PINMUX config for D2000 board
- https://gerrit.zephyrproject.org/r/9946 : tests: add test for k_timer_user_data_set/get()
- https://gerrit.zephyrproject.org/r/9933 : tests: benchmark: sys_kernel: Porting to unified
- https://gerrit.zephyrproject.org/r/9943 : sensor: remove sensor value type
- https://gerrit.zephyrproject.org/r/9927 : build: Just use the ZEPHYRINCLUDE path for when we make offsets
- https://gerrit.zephyrproject.org/r/9922 : arm: cmsis: Prep for move to CMSIS by remove unused code
- https://gerrit.zephyrproject.org/r/9920 : arm: cortex-m: Create CONFIG_BOOT_HEADER_SIZE

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/6306 : net: zoap_server: Enable connecting with bluetooth
- https://gerrit.zephyrproject.org/r/9805 : ext: mcux: add MCR20Overwrites.h
- https://gerrit.zephyrproject.org/r/9889 : serial: k64: Remove the uart_k20 driver
- https://gerrit.zephyrproject.org/r/9888 : frdm_k64f: hexiwear_k64: Remove defaults for the uart_k20 driver
- https://gerrit.zephyrproject.org/r/9887 : k64: Change the default serial driver to the mcux one
- https://gerrit.zephyrproject.org/r/9886 : frdm_k64f: hexiwear_k64: Add defaults for the mcux serial driver
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/9806 : boards: frdm_k64f: add pinmux settings for MCR20A
- https://gerrit.zephyrproject.org/r/9809 : samples: ieee802154: add MCR20A
- https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Port prep_c.c to CMSIS
- https://gerrit.zephyrproject.org/r/9653 : net: slip: Do not remove fragments when sending data
- https://gerrit.zephyrproject.org/r/9891 : net: linkaddr: calculate linkaddr storage addr size via config
- https://gerrit.zephyrproject.org/r/9893 : net: ipv6: fix NULL reference in handle_ra_neighbor
- https://gerrit.zephyrproject.org/r/6410 : initial xtensa code drop
- https://gerrit.zephyrproject.org/r/9709 : Bluetooth: SDP: Add API to extract Attribute Value
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers
- https://gerrit.zephyrproject.org/r/7614 : boards: add initial support for Nucleo-64 with Soc STM32F334
- https://gerrit.zephyrproject.org/r/7615 : boards: add initial support for STM32373C-EVAL with SoC STM32F373VC
- https://gerrit.zephyrproject.org/r/9693 : pinmux/stm32: extend pinmux driver functionality to support STM32F3X series MCUs
- https://gerrit.zephyrproject.org/r/9701 : pinmux/stm32: default pin assignment for STM32373C-EVAL board
- https://gerrit.zephyrproject.org/r/7625 : exti/stm32: add support for F334 & F373 MCUs
- https://gerrit.zephyrproject.org/r/9325 : gpio/stm32: provide GPIO driver implementation for STM32F3X family
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/9868 : uart/stm32: add STM32F3X support for uart
- https://gerrit.zephyrproject.org/r/9699 : pinmux/stm32: default pin assignment for STM3210C-EVAL board
- https://gerrit.zephyrproject.org/r/9700 : pinmux/stm32: default pin assignment for NUCLEO-F334R8 board
- https://gerrit.zephyrproject.org/r/7623 : clock/stm32: add STM32F3X reset and clock control
- https://gerrit.zephyrproject.org/r/7034 : tests: add fifo/lifo test cases with unified kernel
- https://gerrit.zephyrproject.org/r/8922 : scripts: Add device tree parser script
- https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format.
- https://gerrit.zephyrproject.org/r/9885 : serial: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/7104 : drivers: spi: Add nRF5 SPI slave driver
- https://gerrit.zephyrproject.org/r/5604 : drivers: spi: Add SPI_SLAVE flag to allow platform drivers to switch to slave mode
- https://gerrit.zephyrproject.org/r/7107 : tests: Add spi_masterslave test program

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9918 : net: ieee802154: inform about unsupported frames
- https://gerrit.zephyrproject.org/r/9965 : net: mgmt: Make NET_MGMT_GET_* macros return meaningful values
- https://gerrit.zephyrproject.org/r/9921 : Bluetooth: GATT: Fix missing connection address comparison
- https://gerrit.zephyrproject.org/r/9962 : Bluetooth: Prefer struct bt_le_conn_param over individual values
- https://gerrit.zephyrproject.org/r/9958 : samples: net: Fix dhcpv4 building with net mgmt event support
- https://gerrit.zephyrproject.org/r/9957 : net: mgmt: Silently ignore net_mgmt_event functions if not enabled
- https://gerrit.zephyrproject.org/r/9959 : Bluetooth: ATT: Add new error code from CSSv7
- https://gerrit.zephyrproject.org/r/9932 : arc: fix unaligned variables resulting in unaligned k_cpu_sleep_mode
- https://gerrit.zephyrproject.org/r/9942 : MAINTAINERS: update sensor drivers section
- https://gerrit.zephyrproject.org/r/9919 : Merge arm branch into master
- https://gerrit.zephyrproject.org/r/9916 : net: bt: Add disconnect shell command
- https://gerrit.zephyrproject.org/r/9867 : net: bt: Add scan shell command
- https://gerrit.zephyrproject.org/r/9917 : net: echo_client: Enable CONFIG_NET_L2_BLUETOOTH_SHELL in prj_bt.conf
- https://gerrit.zephyrproject.org/r/9862 : net: echo_client: Don't start sending packets if interface is not UP
- https://gerrit.zephyrproject.org/r/9915 : net: bt: Add disconnect management command
- https://gerrit.zephyrproject.org/r/9861 : net: echo_client: Fix using CONFIG_NETWORKING_WITH_BT
- https://gerrit.zephyrproject.org/r/9864 : net: bt: Add connect management command
- https://gerrit.zephyrproject.org/r/9863 : net: bt: Fix not showing any logs
- https://gerrit.zephyrproject.org/r/9860 : net: mgmt: Decode event fields
- https://gerrit.zephyrproject.org/r/9866 : net: bt: Add scan management command
- https://gerrit.zephyrproject.org/r/9865 : net: bt: Add shell support
- https://gerrit.zephyrproject.org/r/8624 : tcptest: Fix wrong variable type in in print() call
- https://gerrit.zephyrproject.org/r/9439 : tests: add timer test case with unified kernel
- https://gerrit.zephyrproject.org/r/9353 : scripts: Explicitly call out python2
- https://gerrit.zephyrproject.org/r/9354 : samples: task_profiler: Be explicit about python
- https://gerrit.zephyrproject.org/r/9816 : tests: Add PWM driver api test


Re: reg: Routing SPI signals connected from x86 core to the Arc core

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi

An update to the below query.Under zephyr 1.6

I have used SPI routines x86 to read the chip id of bma255 and its working fine

But,

If I have used SPI routines on ARC ..chip id reading is returning as 0xFF..

Please Note we have connected bma255 at SPI lines of x86.

So only I have a doubt, can we access SPI directly from ARC which is connected to x86 ?

Please help !!!



From: Mahendravarman Rajarao (RBEI/EAA3)
Sent: Friday, January 13, 2017 5:46 PM
To: 'Liu, Baohong' <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: reg: Routing SPI signals connected from x86 core to the Arc core

Hi Liu

As you have stated below

"Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all"

Is this done in zephyr 1.6 ? Even AON_GPIO can I declare and use directly at ARC ?

Please Note we have connected bma255 at SPI lines of x86.


Best regards

Mahendravarman Rajarao

Mobil +919952921253
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, January 03, 2017 11:36 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: reg: Routing SPI signals connected from x86 core to the Arc core

Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all.

Please see the updated driver and sample app for BMI160 (top of the free, master).

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, January 3, 2017 4:24 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: Routing SPI signals connected from x86 core to the Arc core

Hi

We have connected an Accelerometer to the x86 core of C1000 (Quark_se) through SPI interface.
Interrupt line of accelerometer is also connected to the AON_GPIO_3

Now I need to route the SPI connection of x86 to Arc core. Is that possible ?

Any sample code in zephyr I can refer for this activity ?

Best regards
Mahendra


Re: [RFC]DMA API Update

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

On Wed, 2017-01-11 at 19:49 +0000, Liu, Baohong wrote:

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and direction(HW specific)
* hankshake_polarity [ 6 ] --high or low
Is hankshake_polarity something which affects both source_handshake and
dest_handshake? If so, you sure that no hardware combination might want
different polarities for these? And is handshake something that can have
more than one valid setting, or is it determined by how the hardware is
constructed and wired up? If the latter, then these values probably
shouldn't be in a public API for use by applications and instead set by
the DMA engine to the correct values based on the value of dma_slot or
something other property of the transfer it knows.

* channel_direction [ 7 : 9 ] --0-memory to memory, 1-memory to peripheral,
* 2-peripheral to memory
* source_data_size [ 10 : 12 ] --source data size(8,16,32,64,128 and 256 bits)
* dest_data_size [ 13 : 15 ] --destination data size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 16 : 18 ] --number of source data unit(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 19 : 21 ] -- number of dest data unit(1,4,8,16,32,64,128 and 256)
Why are burst lengths a fixed sequence of power's of two? And why isn't
'2' in the list? Why not just have an arbitrary integer? That's a
rhetorical question, I know why, because it matches the Quark hardware,
and the DMA API, like a lot of APIs in Zephyr, is specific to that one
piece of hardware.

* source_handshake [ 22 ] --HW or SW
* dest_handshake [ 23 ] --HW or SW
* channel_priority [ 24 : 27 ] --DMA channel priority
* RESERVED [ 28 : 31 ]
* dma_callback is the callback function pointer
*/

struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int error_code);
}

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API function prototypes:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)
I also see the existing DMA API doesn't support scatter-gather, that's a
fairly common and useful feature of DMA hardware.

But finally, the big elephant in the room is: how are DMA APIs actually
expected to used? And how should the system be configured?

Currently, the only code in Zephyr that does DMA is of course Quark, and
the driver for each peripheral that can do DMA is Quark specific and
knows about Quark DMA.

So what about an SoC with a some generic DMA IP that has a Zephyr
driver, and a bunch of generic peripherals with there own drivers, and
an application that wants to use one of the said peripherals, which
software component configures the dma channel and how is the system
configured so that has the right knowledge to do that?

That's probably a rhetorical question to. The answer is that Zephyr
get's device-tree support and pinches designed ideas from Linux (which
presumably borrowed heavily from other places as well).

--
Tixy


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Luiz Augusto von Dentz
 

Hi,

zoap_server does not have BT support, but Ive created a patch adding
support for it:

https://gerrit.zephyrproject.org/r/6306

On Fri, Jan 13, 2017 at 11:38 AM, Appala Raju <raju.ga(a)gmail.com> wrote:
Thanks Tomasz...

Just now I checked-out master branch and tried zoap_server as Ravi explained. Now it is booting with out any issues and seeing "shell >" on UART messages.

After that, I am trying to discover the BLE device from Linux machine using "sudo hcitool lescan". Here, nothing is showing. What could be the reason.
--
Luiz Augusto von Dentz


Re: reg: Routing SPI signals connected from x86 core to the Arc core

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi Liu

As you have stated below

"Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all"

Is this done in zephyr 1.6 ? Even AON_GPIO can I declare and use directly at ARC ?

Please Note we have connected bma255 at SPI lines of x86.


Best regards

Mahendravarman Rajarao

Mobil +919952921253

From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, January 03, 2017 11:36 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: reg: Routing SPI signals connected from x86 core to the Arc core

Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all.

Please see the updated driver and sample app for BMI160 (top of the free, master).

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, January 3, 2017 4:24 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: Routing SPI signals connected from x86 core to the Arc core

Hi

We have connected an Accelerometer to the x86 core of C1000 (Quark_se) through SPI interface.
Interrupt line of accelerometer is also connected to the AON_GPIO_3

Now I need to route the SPI connection of x86 to Arc core. Is that possible ?

Any sample code in zephyr I can refer for this activity ?

Best regards
Mahendra


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Appala Raju <raju.ga@...>
 

Thanks Tomasz...

Just now I checked-out master branch and tried zoap_server as Ravi explained. Now it is booting with out any issues and seeing "shell >" on UART messages.

After that, I am trying to discover the BLE device from Linux machine using "sudo hcitool lescan". Here, nothing is showing. What could be the reason.


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Tomasz Bursztyka
 

Hi Raju,

Can you try on latest master, on zoap_server?
We don't support the old coap library anymore, which was working against
old ip stack.

Tomasz

Hi Tomasz,

I am using 1.6.0 version.

Thanks,
Raju


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Appala Raju <raju.ga@...>
 

Hi Tomasz,

I am using 1.6.0 version.

Thanks,
Raju


Re: [RFC]DMA API Update

Huaqi Fang
 

Hi Baohong,

First thanks for proposal about DMA API update.
I want to post some of our use cases and requirements around DMA API, since I am working on Designware ARC Core support in Synopsys, our hardware platform EMSK is already supported in zephyr, and in EMSK 2.2 version, there is a uDMA component in it.
For uDMA component description: https://www.synopsys.com/dw/ipdir.php?ds=arc-system-integration-options
1. As other developers said, for DMA transfers, there are different types of transfer, single list transfer, linked list transfer. But it seems in this API proposal, there is no consideration.
2. In ARC core, it has many aux registers, and the DMA support not just memory to memory, or memory to peripheral, it also support memory to aux interface. Maybe some other DMA component also support different interfaces.
3. For DMA transfer, each burst transfer can be auto-requested or manual requested by peripheral interface signal.

Currently we have uDMA driver for ARC in embARC project: https://www.embarc.org/, if you want to take a look at it, you can register an account and download it.

I post our use cases and requirements here, so hopes that the DMA API can take these into consideration.

Thanks
Huaqi

-----Original Message-----
From: Nallasellan, Singaravelan [mailto:singaravelan.nallasellan(a)intel.com]
Sent: 2017年1月13日 13:40
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC]DMA API Update

It is required to add slave or controller id which is 32 bits. Some DMA controllers require to program mux to connect the hardware handshake signals to the selected peripheral with the channel.

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Thursday, January 12, 2017 1:20 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC]DMA API Update


Hi everyone,

I would like to propose the update for DMA API.
(https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.zephyrproject.org_browse_ZEP-2D873&d=DgIFAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=KI3IYdedpLSnsCSZ0k3Gcp6fYWESKi3RE-hGv_ZefTg&m=apJcm5GKxXOZ-B-8xed5zGD7lHnTwvAlcy0LrqN83L0&s=4lO6HbTvx4_-SnlOC8xe3edTD8vU2Ych1Arh29j2ATQ&e= ).

Known Problems
--------

Struct dma_channel_config consists of quite a few variables of enum
types, two callback function pointers, and one callback user data pointer.

- The enums can be collapsed into a bit field.
This will reduce the size of the data structure.

- The two callback function pointers (for normal and error cases) can
be combined.
A parameter of error code can be used to differentiate the two
cases. So, the
current callback parameter of user data pointer will be replaced by
two new
parameters. One for error code and the other one for channel id.

- Callback data pointer can be removed.
Currently, this field holds user data. It can be moved to driver
data structure.
The callback function can dig out the information from dev pointer and
channel id passed to it.

Proposed Solution
--------

-- The following are the enums we have now.

handshake_interface /* which peripheral and direction*/
hankshake_polarity /* high or low*/
channel_direction /* memory to memory, memory to peripheral ... */
Source_transfer_width /* source data size */
Destination_transfer_width /* destination data size */
Source_burst_length /* source burst length */
Destination_burst_length /* destination burst length */

All these will be collapsed into a bit field. Some of them will have new names.

Besides the above, three new items will be added.
source_handshake /* HW or SW */
dest_handshake /* HW or SW */
channel_priority /* DMA channel priority */

-- For the callback function, there will be three parameters. They are
device pointer,
channel_id, and error code. As said above, the error callback
will be removed.

-- The callback_data pointer will be removed.

Final API Format
--------

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_data_size [ 10 : 12 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_data_size [ 13 : 15 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 16 : 18 ] --number of source data
unit(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 19 : 21 ] -- number of dest data
unit(1,4,8,16,32,64,128 and 256)
* source_handshake [ 22 ] --HW or SW
* dest_handshake [ 23 ] --HW or SW
* channel_priority [ 24 : 27 ] --DMA channel priority
* RESERVED [ 28 : 31 ]
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int
error_code); }

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API function prototypes:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

(Note: for xx_data_size and xx_burst_length in the above bit field,
the value will only serve as an index. For example, for
source_data_size, bit field values of 0, 1, 2, 3, 4 and 5 will
correspond to sizes of 8,16,32,64,128 and 256 bits.)

Suggestions and comments are welcome.


Re: [RFC]DMA API Update

Nallasellan, Singaravelan
 

It is required to add slave or controller id which is 32 bits. Some DMA controllers require to program mux to connect the hardware handshake signals to the selected peripheral with the channel.

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Thursday, January 12, 2017 1:20 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC]DMA API Update


Hi everyone,

I would like to propose the update for DMA API.
(https://jira.zephyrproject.org/browse/ZEP-873).

Known Problems
--------

Struct dma_channel_config consists of quite a few variables of enum types,
two callback function pointers, and one callback user data pointer.

- The enums can be collapsed into a bit field.
This will reduce the size of the data structure.

- The two callback function pointers (for normal and error cases) can be
combined.
A parameter of error code can be used to differentiate the two cases. So,
the
current callback parameter of user data pointer will be replaced by two
new
parameters. One for error code and the other one for channel id.

- Callback data pointer can be removed.
Currently, this field holds user data. It can be moved to driver data
structure.
The callback function can dig out the information from dev pointer and
channel id passed to it.

Proposed Solution
--------

-- The following are the enums we have now.

handshake_interface /* which peripheral and direction*/
hankshake_polarity /* high or low*/
channel_direction /* memory to memory, memory to peripheral ... */
Source_transfer_width /* source data size */
Destination_transfer_width /* destination data size */
Source_burst_length /* source burst length */
Destination_burst_length /* destination burst length */

All these will be collapsed into a bit field. Some of them will have new names.

Besides the above, three new items will be added.
source_handshake /* HW or SW */
dest_handshake /* HW or SW */
channel_priority /* DMA channel priority */

-- For the callback function, there will be three parameters. They are device
pointer,
channel_id, and error code. As said above, the error callback will be
removed.

-- The callback_data pointer will be removed.

Final API Format
--------

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_data_size [ 10 : 12 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_data_size [ 13 : 15 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 16 : 18 ] --number of source data
unit(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 19 : 21 ] -- number of dest data
unit(1,4,8,16,32,64,128 and 256)
* source_handshake [ 22 ] --HW or SW
* dest_handshake [ 23 ] --HW or SW
* channel_priority [ 24 : 27 ] --DMA channel priority
* RESERVED [ 28 : 31 ]
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int
error_code); }

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API function prototypes:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

(Note: for xx_data_size and xx_burst_length in the above bit field, the value
will only serve as an index. For example, for source_data_size, bit field values
of 0, 1, 2, 3, 4 and 5 will correspond to sizes of 8,16,32,64,128 and 256 bits.)

Suggestions and comments are welcome.


Re: [RFC]DMA API Update

Liu, Baohong
 

Hi Piotr,

The APIs are for SoC DMA engine. There will be a DMA driver for each SoC to implement these APIs.
Users can use these APIs to play with the DMA engine or do whatever they like. Other device drivers
for example SPI can use them of course. But, they can directly call functions in the DMA driver(ignoring
these APIs and do the thing internally—this is the way for quark currently). What does this mean? The
DMA driver will have all the details for the HW. But, you do not need to expose all the details through
the DMA APIs we are talking about unless the target callers of these APIs need them.

I am OK to change the RFC if you think it is necessary to expose more HW details through these APIs.
Let me know.

Thanks
Baohong

From: Piotr Mienkowski [mailto:piotr.mienkowski(a)gmail.com]
Sent: Thursday, January 12, 2017 2:21 PM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: [RFC]DMA API Update

Hi Baohong,


They are for user applications. Drivers are to implement them.

Before I send my comments I have a general question: Is the DMA API meant to serve exclusively user applications, the one build on top of Zephyr, or is it meant to be used also by the device driver code?
I'm not sure I understood your answer correctly. Let me explain my point again with an example.

Atmel SAM DMA module has features like linked list which allows to set up multi block memory transfer, e.g. one could easily set up DMA transfer for Zephyr's fifo queue. Also features like memory striding to access data in the interleaved manner (every n-th data element). These more advanced features are likely going to be used by the device drivers but probably not by the user application.

From your answer I understand that DMA API update you propose is aimed at user applications. That means that additionally every SoC family should provide its own private DMA API to be used by the device drivers. I.e. when I write Atmel SAM audio driver that uses DMA transfer this driver should access private Atmel SAM DMA API and not the public DMA API. Is that correct?

Regards,
Piotr


Re: [RFC]DMA API Update

Piotr Mieńkowski <piotr.mienkowski at gmail.com...>
 

Hi Baohong,

They are for user applications. Drivers are to implement them.



Before I send my comments I have a general question: Is the DMA API
meant to serve exclusively user applications, the one build on top of
Zephyr, or is it meant to be used also by the device driver code?
I'm not sure I understood your answer correctly. Let me explain my point
again with an example.

Atmel SAM DMA module has features like linked list which allows to set
up multi block memory transfer, e.g. one could easily set up DMA
transfer for Zephyr's fifo queue. Also features like memory striding to
access data in the interleaved manner (every n-th data element). These
more advanced features are likely going to be used by the device drivers
but probably not by the user application.

From your answer I understand that DMA API update you propose is aimed
at user applications. That means that additionally every SoC family
should provide its own private DMA API to be used by the device drivers.
I.e. when I write Atmel SAM audio driver that uses DMA transfer this
driver should access private Atmel SAM DMA API and not the public DMA
API. Is that correct?

Regards,
Piotr


Re: [RFC]DMA API Update

Liu, Baohong
 

HI Piotr,

They are for user applications. Drivers are to implement them.

Thanks
Baohong

From: Piotr Mienkowski [mailto:piotr.mienkowski(a)gmail.com]
Sent: Thursday, January 12, 2017 11:25 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC]DMA API Update


Hi Baohong,

Thanks for preparing the proposal for the new DMA API. I'm working currently on the Atmel SAM family DMA driver and am very interested in the topic.

Before I send my comments I have a general question: Is the DMA API meant to serve exclusively user applications, the one build on top of Zephyr, or is it meant to be used also by the device driver code?

The way I understand it providing DMA API exclusively for user applications means it can be kept simple and portable. Providing DMA API that can be used by device drivers means it should support all the intricate features of the given DMA hardware module, i.e. API should not put (too much) limits on what hardware can do.

Regards,
Piotr

On 11.01.2017 20:49, Liu, Baohong wrote:



Hi everyone,



I would like to propose the update for DMA API.

(https://jira.zephyrproject.org/browse/ZEP-873).



Known Problems

--------



Struct dma_channel_config consists of quite a few variables of enum types,

two callback function pointers, and one callback user data pointer.



- The enums can be collapsed into a bit field.

This will reduce the size of the data structure.



- The two callback function pointers (for normal and error cases) can be combined.

A parameter of error code can be used to differentiate the two cases. So, the

current callback parameter of user data pointer will be replaced by two new

parameters. One for error code and the other one for channel id.



- Callback data pointer can be removed.

Currently, this field holds user data. It can be moved to driver data structure.

The callback function can dig out the information from dev pointer and

channel id passed to it.



Proposed Solution

--------



-- The following are the enums we have now.



handshake_interface /* which peripheral and direction*/

hankshake_polarity /* high or low*/

channel_direction /* memory to memory, memory to peripheral ... */

Source_transfer_width /* source data size */

Destination_transfer_width /* destination data size */

Source_burst_length /* source burst length */

Destination_burst_length /* destination burst length */



All these will be collapsed into a bit field. Some of them will have new names.



Besides the above, three new items will be added.

source_handshake /* HW or SW */

dest_handshake /* HW or SW */

channel_priority /* DMA channel priority */



-- For the callback function, there will be three parameters. They are device pointer,

channel_id, and error code. As said above, the error callback will be removed.



-- The callback_data pointer will be removed.



Final API Format

--------



/**

* @brief DMA configuration structure.

*

* config is a bit field with the following parts:

* dma_slot [ 0 : 5 ] --which peripheral and direction(HW specific)

* hankshake_polarity [ 6 ] --high or low

* channel_direction [ 7 : 9 ] --0-memory to memory, 1-memory to peripheral,

* 2-peripheral to memory

* source_data_size [ 10 : 12 ] --source data size(8,16,32,64,128 and 256 bits)

* dest_data_size [ 13 : 15 ] --destination data size(8,16,32,64,128 and 256 bits)

* source_burst_length [ 16 : 18 ] --number of source data unit(1,4,8,16,32,64,128 and 256)

* dest_burst_length [ 19 : 21 ] -- number of dest data unit(1,4,8,16,32,64,128 and 256)

* source_handshake [ 22 ] --HW or SW

* dest_handshake [ 23 ] --HW or SW

* channel_priority [ 24 : 27 ] --DMA channel priority

* RESERVED [ 28 : 31 ]

* dma_callback is the callback function pointer

*/

struct dma_channel_config {

uint32_t config;

void (*dma_callback)(struct device *dev, uint32_t channel, int error_code);

}



The remaining parts will stay the same.

No change to the structure dma_transfer_config.

No change to the API function prototypes:

dma_channel_config(...)

dma_transfer_config(...)

dma_transfer_start(...)

dma_transfer_stop(...)



(Note: for xx_data_size and xx_burst_length in the above bit field, the value will only serve

as an index. For example, for source_data_size, bit field values of 0, 1, 2, 3, 4 and 5 will

correspond to sizes of 8,16,32,64,128 and 256 bits.)



Suggestions and comments are welcome.


Re: Porting to ARM Cortex-M7 / Atmel SAM E70 support

Piotr Mieńkowski <piotr.mienkowski at gmail.com...>
 

Hi,

From the Jira comments on the issue: https://jira.zephyrproject.org/browse/ZEP-759 it looks like convincing Atmel to provide us with Zephyr's compatible licence for the register access header files may be more problematic than it was anticipated.

When the discussion regarding license issue was started it was said that it would be preferable to get a new license from Atmel, however we never determined that we could not use the current one. Or at least I'm not aware of it. In fact Atmel license looks fairly similar to those used by other vendors that are already incorporated in Zephyr and located in ext/hal folder. Maybe we could simply use existing Atmel license?

Regards,
Piotr


Re: [RFC]DMA API Update

Piotr Mieńkowski <piotr.mienkowski at gmail.com...>
 

Hi Baohong,

Thanks for preparing the proposal for the new DMA API. I'm working
currently on the Atmel SAM family DMA driver and am very interested in
the topic.

Before I send my comments I have a general question: Is the DMA API
meant to serve exclusively user applications, the one build on top of
Zephyr, or is it meant to be used also by the device driver code?

The way I understand it providing DMA API exclusively for user
applications means it can be kept simple and portable. Providing DMA API
that can be used by device drivers means it should support all the
intricate features of the given DMA hardware module, i.e. API should not
put (too much) limits on what hardware can do.

Regards,
Piotr

On 11.01.2017 20:49, Liu, Baohong wrote:
Hi everyone,

I would like to propose the update for DMA API.
(https://jira.zephyrproject.org/browse/ZEP-873).

Known Problems
--------

Struct dma_channel_config consists of quite a few variables of enum types,
two callback function pointers, and one callback user data pointer.

- The enums can be collapsed into a bit field.
This will reduce the size of the data structure.

- The two callback function pointers (for normal and error cases) can be combined.
A parameter of error code can be used to differentiate the two cases. So, the
current callback parameter of user data pointer will be replaced by two new
parameters. One for error code and the other one for channel id.

- Callback data pointer can be removed.
Currently, this field holds user data. It can be moved to driver data structure.
The callback function can dig out the information from dev pointer and
channel id passed to it.

Proposed Solution
--------

-- The following are the enums we have now.

handshake_interface /* which peripheral and direction*/
hankshake_polarity /* high or low*/
channel_direction /* memory to memory, memory to peripheral ... */
Source_transfer_width /* source data size */
Destination_transfer_width /* destination data size */
Source_burst_length /* source burst length */
Destination_burst_length /* destination burst length */

All these will be collapsed into a bit field. Some of them will have new names.

Besides the above, three new items will be added.
source_handshake /* HW or SW */
dest_handshake /* HW or SW */
channel_priority /* DMA channel priority */

-- For the callback function, there will be three parameters. They are device pointer,
channel_id, and error code. As said above, the error callback will be removed.

-- The callback_data pointer will be removed.

Final API Format
--------

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and direction(HW specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-memory to peripheral,
* 2-peripheral to memory
* source_data_size [ 10 : 12 ] --source data size(8,16,32,64,128 and 256 bits)
* dest_data_size [ 13 : 15 ] --destination data size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 16 : 18 ] --number of source data unit(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 19 : 21 ] -- number of dest data unit(1,4,8,16,32,64,128 and 256)
* source_handshake [ 22 ] --HW or SW
* dest_handshake [ 23 ] --HW or SW
* channel_priority [ 24 : 27 ] --DMA channel priority
* RESERVED [ 28 : 31 ]
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int error_code);
}

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API function prototypes:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

(Note: for xx_data_size and xx_burst_length in the above bit field, the value will only serve
as an index. For example, for source_data_size, bit field values of 0, 1, 2, 3, 4 and 5 will
correspond to sizes of 8,16,32,64,128 and 256 bits.)

Suggestions and comments are welcome.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 7
[ZEP-1559] Implement _tsc_read for ARC architecture
https://jira.zephyrproject.org/browse/ZEP-1559

[ZEP-1561] Implement _tsc_read for NiosII
https://jira.zephyrproject.org/browse/ZEP-1561

[ZEP-1560] Implement _tsc_read for ARM
https://jira.zephyrproject.org/browse/ZEP-1560

[ZEP-1563] move board documenation for NRF51/NRF52 back to git tree
https://jira.zephyrproject.org/browse/ZEP-1563

[ZEP-1558] Support of user private data pointer in Timer expiry function
https://jira.zephyrproject.org/browse/ZEP-1558

[ZEP-1564] 6lo uncompress_IPHC_header overwrites IPHC fields
https://jira.zephyrproject.org/browse/ZEP-1564

[ZEP-1562] echo_server/echo_client examples hang randomly after some time of operation
https://jira.zephyrproject.org/browse/ZEP-1562


UPDATED JIRA items within last 24 hours: 31
[ZEP-794] Requirements for Internet Hosts - Communication Layers
https://jira.zephyrproject.org/browse/ZEP-794

[ZEP-839] Thread Requirements on RFC6282
https://jira.zephyrproject.org/browse/ZEP-839

[ZEP-837] Thread Requirements on RFC4443
https://jira.zephyrproject.org/browse/ZEP-837

[ZEP-838] Thread Requirements on RFC4944
https://jira.zephyrproject.org/browse/ZEP-838

[ZEP-819] 6LowPAN-GHC: Generic Header Compression for IPv6
https://jira.zephyrproject.org/browse/ZEP-819

[ZEP-834] Thread Requirements on RFC1122
https://jira.zephyrproject.org/browse/ZEP-834

[ZEP-835] Thread Requirements on RFC2460
https://jira.zephyrproject.org/browse/ZEP-835

[ZEP-836] Thread Requirements on RFC4291
https://jira.zephyrproject.org/browse/ZEP-836

[ZEP-1178] Provide a MinGW environment for Building on Windows
https://jira.zephyrproject.org/browse/ZEP-1178

[ZEP-1038] Hard real-time interrupt support
https://jira.zephyrproject.org/browse/ZEP-1038

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

[ZEP-1557] RISC V Port
https://jira.zephyrproject.org/browse/ZEP-1557

[ZEP-880] 6LoWPAN - Multicast Address Mapping
https://jira.zephyrproject.org/browse/ZEP-880

[ZEP-881] 6LoWPAN - Frame Delivery in a Link-Layer Mesh
https://jira.zephyrproject.org/browse/ZEP-881

[ZEP-877] 6LoWPAN - Mesh Header compression and uncompression
https://jira.zephyrproject.org/browse/ZEP-877

[ZEP-878] 6LoWPAN - Unicast-Prefix based IPv6 Multicast (dst) address compression
https://jira.zephyrproject.org/browse/ZEP-878

[ZEP-889] 802.15.4 - Management service: FFD level support
https://jira.zephyrproject.org/browse/ZEP-889

[ZEP-892] 802.15.4 - TSCH Radio protocol support
https://jira.zephyrproject.org/browse/ZEP-892

[ZEP-1394] Add ksdk gpio driver
https://jira.zephyrproject.org/browse/ZEP-1394

[ZEP-1387] Add a driver for Atmel ataes132a HW Crypto module
https://jira.zephyrproject.org/browse/ZEP-1387

[ZEP-359] Move QEMU handling to a central location
https://jira.zephyrproject.org/browse/ZEP-359

[ZEP-31] E2E tests for connection
https://jira.zephyrproject.org/browse/ZEP-31

[ZEP-20] E2E testing for non-interactive pairing
https://jira.zephyrproject.org/browse/ZEP-20

[ZEP-1339] Add disk access based on flash on freedom board to interface with file system
https://jira.zephyrproject.org/browse/ZEP-1339

[ZEP-1414] implement _tsc_read for all architectures
https://jira.zephyrproject.org/browse/ZEP-1414

[ZEP-1536] Convert documentation of PWM samples to RST
https://jira.zephyrproject.org/browse/ZEP-1536

[ZEP-1177] Reduce Zephyr's Dependency on Host Tools
https://jira.zephyrproject.org/browse/ZEP-1177

[ZEP-719] Add ksdk uart shim driver
https://jira.zephyrproject.org/browse/ZEP-719

[ZEP-744] USB WebUSB
https://jira.zephyrproject.org/browse/ZEP-744

[ZEP-1526] Missing dependency on Windows
https://jira.zephyrproject.org/browse/ZEP-1526

[ZEP-1347] sys_bitfield_*() take unsigned long* vs memaddr_t
https://jira.zephyrproject.org/browse/ZEP-1347


CLOSED JIRA items within last 24 hours: 5
[ZEP-1513] (Duplicate) Port legacy kernel and benchmark tests to unified kernel
https://jira.zephyrproject.org/browse/ZEP-1513

[ZEP-1316] (Cannot Reproduce) tests/ztest/mock/testcase.ini#test: fatal fault in ARC and QD2000
https://jira.zephyrproject.org/browse/ZEP-1316

[ZEP-1080] (Cannot Reproduce) random failures on serial port
https://jira.zephyrproject.org/browse/ZEP-1080

[ZEP-1512] (Fixed) doc-theme has its own conf.py
https://jira.zephyrproject.org/browse/ZEP-1512

[ZEP-1443] (Fixed) Samples/net/zperf: Build fail as net_private.h can not be founld
https://jira.zephyrproject.org/browse/ZEP-1443


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9917 : net: echo_client: Enable CONFIG_NET_L2_BLUETOOTH_SHELL in prj_bt.conf
- https://gerrit.zephyrproject.org/r/9916 : net: bt: Add disconnect shell command
- https://gerrit.zephyrproject.org/r/9915 : net: bt: Add disconnect management command
- https://gerrit.zephyrproject.org/r/9895 : net: route: remove extra variable use in net_route_add()
- https://gerrit.zephyrproject.org/r/9894 : net: ipv6: fix link address handling in handle_ns_neighbor
- https://gerrit.zephyrproject.org/r/9892 : net: net_linkaddr: introduce net_linkaddr_storage_set function
- https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Port prep_c.c to CMSIS
- https://gerrit.zephyrproject.org/r/9904 : pinmux/stm32l4: Add support for STM32L SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9905 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9881 : Bluetooth: fix write cmd handling
- https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format.
- https://gerrit.zephyrproject.org/r/9889 : serial: k64: Remove the uart_k20 driver
- https://gerrit.zephyrproject.org/r/9888 : frdm_k64f: hexiwear_k64: Remove defaults for the uart_k20 driver
- https://gerrit.zephyrproject.org/r/9887 : k64: Change the default serial driver to the mcux one
- https://gerrit.zephyrproject.org/r/9886 : frdm_k64f: hexiwear_k64: Add defaults for the mcux serial driver
- https://gerrit.zephyrproject.org/r/9891 : net: linkaddr: calculate linkaddr storage addr size via config
- https://gerrit.zephyrproject.org/r/9893 : net: ipv6: fix NULL reference in handle_ra_neighbor
- https://gerrit.zephyrproject.org/r/9890 : RFC: sys_*bit(): use 'unsigned long *' instead of memaddr_t or mem_reg_t
- https://gerrit.zephyrproject.org/r/9885 : serial: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/9880 : Bluetooth: ATT: Fix using k_fifo API with net_buf

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9867 : net: bt: Add scan shell command
- https://gerrit.zephyrproject.org/r/9866 : net: bt: Add scan management command
- https://gerrit.zephyrproject.org/r/9865 : net: bt: Add shell support
- https://gerrit.zephyrproject.org/r/9864 : net: bt: Add connect management command
- https://gerrit.zephyrproject.org/r/9863 : net: bt: Fix not showing any logs
- https://gerrit.zephyrproject.org/r/9862 : net: echo_client: Don't start sending packets if interface is not UP
- https://gerrit.zephyrproject.org/r/9861 : net: echo_client: Fix using CONFIG_NETWORKING_WITH_BT
- https://gerrit.zephyrproject.org/r/9860 : net: mgmt: Decode event fields
- https://gerrit.zephyrproject.org/r/9805 : ext: ksdk: add MCR20Overwrites.h
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/9809 : samples: ieee802154: add MCR20A
- https://gerrit.zephyrproject.org/r/9806 : boards: frdm_k64f: add pinmux settings for MCR20A
- https://gerrit.zephyrproject.org/r/9827 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9826 : pinmux/stm32l4: Add support for STM32L SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9857 : Bluetooth: Add HCI SPI driver
- https://gerrit.zephyrproject.org/r/9516 : drivers: Add Atmel SAM family GMAC Ethernet driver
- https://gerrit.zephyrproject.org/r/9859 : Bluetooth: Kconfig: Specify stack size for Bluetooth SPI
- https://gerrit.zephyrproject.org/r/9858 : Bluetooth: samples/beacon: Print message at start of sample
- https://gerrit.zephyrproject.org/r/9663 : Bluetooth: AVDTP: Add AVDTP Receive Function
- https://gerrit.zephyrproject.org/r/9460 : Bluetooth: AVDTP: Add AVDTP Discover Function Definition
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/9446 : Bluetooth: AVDTP: Added params to AVDTP Request structure
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers
- https://gerrit.zephyrproject.org/r/9439 : tests: add timer test case with unified kernel
- https://gerrit.zephyrproject.org/r/7034 : tests: add fifo/lifo test cases with unified kernel
- https://gerrit.zephyrproject.org/r/9464 : tests: kernel: added memory pool threadsafe test
- https://gerrit.zephyrproject.org/r/9508 : tests: kernel: added memory slab threadsafe test
- https://gerrit.zephyrproject.org/r/9507 : tests: kernel: added memory slab concept test
- https://gerrit.zephyrproject.org/r/9505 : tests: kernel: re-path mslab test
- https://gerrit.zephyrproject.org/r/9506 : tests: kernel: added memory slab api test
- https://gerrit.zephyrproject.org/r/9517 : samples: net: echo_server .conf for Atmel SMART SAM E70 Xplained board
- https://gerrit.zephyrproject.org/r/6127 : arch: Add pmc, gpio internal Atmel SAM drivers
- https://gerrit.zephyrproject.org/r/9515 : arch: Add support for Atmel SAM E70 SoC configuration at boot
- https://gerrit.zephyrproject.org/r/5027 : arch: Add Atmel SAM E70 SoC support
- https://gerrit.zephyrproject.org/r/5028 : boards: Add Atmel SAM E70 Xplained board support
- https://gerrit.zephyrproject.org/r/6662 : ext: Add Atmel SAM3X header files from Atmel ASF library
- https://gerrit.zephyrproject.org/r/6128 : drivers: Add basic Atmel SAM USART driver
- https://gerrit.zephyrproject.org/r/5025 : ext: Add Atmel SAM E70 header files from Atmel ASF library
- https://gerrit.zephyrproject.org/r/9816 : tests: Add PWM driver api test
- https://gerrit.zephyrproject.org/r/8961 : drivers: QMSI AON counter: Simplify driver reentrancy code
- https://gerrit.zephyrproject.org/r/9712 : Bluetooth: SDP: Use ProtocolDescriptorList attr API in BTshell
- https://gerrit.zephyrproject.org/r/9709 : Bluetooth: SDP: Add API to extract Attribute Value
- https://gerrit.zephyrproject.org/r/9711 : Bluetooth: SDP: Get ProtocolDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9713 : Bluetooth: SDP: Add API to get ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9714 : Bluetooth: SDP: Use ProfileDescriptorList API in BTshell
- https://gerrit.zephyrproject.org/r/9710 : Bluetooth: SDP: Add SDP client interface to BTshell app
- https://gerrit.zephyrproject.org/r/7615 : boards: add initial support for STM32373C-EVAL with SoC STM32F373VC
- https://gerrit.zephyrproject.org/r/7614 : boards: add initial support for Nucleo-64 with Soc STM32F334
- https://gerrit.zephyrproject.org/r/9868 : uart/stm32: add STM32F3X support for uart
- https://gerrit.zephyrproject.org/r/9693 : pinmux/stm32: extend pinmux driver functionality to support STM32F3X series MCUs
- https://gerrit.zephyrproject.org/r/9701 : pinmux/stm32: default pin assignment for STM32373C-EVAL board
- https://gerrit.zephyrproject.org/r/9699 : pinmux/stm32: default pin assignment for STM3210C-EVAL board
- https://gerrit.zephyrproject.org/r/9325 : gpio/stm32: provide GPIO driver implementation for STM32F3X family
- https://gerrit.zephyrproject.org/r/9700 : pinmux/stm32: default pin assignment for NUCLEO-F334R8 board
- https://gerrit.zephyrproject.org/r/9001 : counter: cmsdk: Add Timer 0 and 1 as Timers
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/9463 : tests: kernel: added memory pool configuration options test
- https://gerrit.zephyrproject.org/r/9815 : test: tickless can run on all targets
- https://gerrit.zephyrproject.org/r/9637 : Bluetooth: AT: HFP HF: Handle unsolicited reponse
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/7623 : clock/stm32: add STM32F3X reset and clock control
- https://gerrit.zephyrproject.org/r/7625 : exti/stm32: add support for F334 & F373 MCUs

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9914 : net: ieee802154: fix validate_mac_command_cfi_to_mhr
- https://gerrit.zephyrproject.org/r/9913 : Bluetooth: GATT: Fix missing connection address comparison
- https://gerrit.zephyrproject.org/r/9907 : net: icmpv4 : calculate ipv4 header chksum
- https://gerrit.zephyrproject.org/r/9906 : net: dhcpv4 : set ciaddr 0.0.0.0 when send DHCPV4_MSG_TYPE_REQUEST
- https://gerrit.zephyrproject.org/r/9875 : boards: arm: v2m_beetle: Add documentation.
- https://gerrit.zephyrproject.org/r/9879 : kernel: have boot banner depend on console existing
- https://gerrit.zephyrproject.org/r/9878 : board: nucleo_f411re: fix newline missing at end of file
- https://gerrit.zephyrproject.org/r/9882 : util.h: Add IS_ENABLED() macro for expression-legal ifdef-checking
- https://gerrit.zephyrproject.org/r/9877 : board: quark_se_c1000_ss_devboard: remove duplicate CONFIG_UART_CONSOLE
- https://gerrit.zephyrproject.org/r/9876 : tests/sensors_n_z.conf: fix duplicated setting of CONFIG options
- https://gerrit.zephyrproject.org/r/9873 : net: Remove NET_SLIP choice from Kconfig
- https://gerrit.zephyrproject.org/r/9850 : net: tcp: Signal EOF with a NULL buffer in the callback
- https://gerrit.zephyrproject.org/r/9851 : net: tcp: Don't leak net_conn_handles
- https://gerrit.zephyrproject.org/r/9844 : net: ip: reword appdata debug message in packet_received
- https://gerrit.zephyrproject.org/r/9842 : net: ip: set context state to NET_CONTEXT_CONNECTED on synack success
- https://gerrit.zephyrproject.org/r/9843 : net: ip: save TCP seq/ack values in tcp_synack_received
- https://gerrit.zephyrproject.org/r/9840 : net: ip: on synack copy local/remote data prior to net_tcp_register
- https://gerrit.zephyrproject.org/r/9841 : net: ip: set local address family during TCP connect
- https://gerrit.zephyrproject.org/r/9838 : net: tcp: replace seq/ack/wnd value shifts with system calls
- https://gerrit.zephyrproject.org/r/9837 : net: net_context: state setting is a value not individual bits
- https://gerrit.zephyrproject.org/r/9824 : shell: add tasks command to kernel module
- https://gerrit.zephyrproject.org/r/9825 : shell: add stacks command
- https://gerrit.zephyrproject.org/r/9782 : shell: rename command 'set_module' to 'select'
- https://gerrit.zephyrproject.org/r/9871 : Bluetooth: Add missing documentation to HCI driver APIs
- https://gerrit.zephyrproject.org/r/9870 : Bluetooth: Remove unused bt_hci_driver_unregister() API
- https://gerrit.zephyrproject.org/r/9853 : samples/mbedtls_dtlsclient: Remove hardcoded IP adresses
- https://gerrit.zephyrproject.org/r/9371 : samples/mbedtls_dtlsclient: IPv6 client version
- https://gerrit.zephyrproject.org/r/9852 : samples/mbedtls_dtlsclient: Change Readme files to rst format
- https://gerrit.zephyrproject.org/r/9797 : Bluetooth: AT: Rename enum at_cmd_type elements
- https://gerrit.zephyrproject.org/r/9764 : samples/mbedtls_dtlsserver DTLS server example app using mbedTLS
- https://gerrit.zephyrproject.org/r/9849 : samples/mbedtls_dtlsclient: Using printk instead of printf
- https://gerrit.zephyrproject.org/r/9869 : samples: net: Echo apps need different IP to be able to work
- https://gerrit.zephyrproject.org/r/9813 : arc: i-cache init moved much earlier
- https://gerrit.zephyrproject.org/r/9814 : arc: ICCM memory should have read-write-execute attributes
- https://gerrit.zephyrproject.org/r/9822 : kernel: profiling: Expose an API call to analyze call stacks
- https://gerrit.zephyrproject.org/r/9802 : samples: basic: Move pwm driver samples

5841 - 5860 of 8048