Date   

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


[net] RFC: a RPL instance should not be limited to a single network interface

Richard Peters <mail@...>
 

Hi Community,

I'am planning an IOT system, that needs the feature exlained below, but
i am not sure about whether this is covered by the RPL specs.
I find nothing in the RFC 6550 that may not allow it and since routing
is Layer 3, there should be no reason to not support it, i think.
So here is the use case:

Missing feature
---------------
- As an user i want to be able to span my DODAG over mutile network
interfaces and not to be limited to a single net-if.
- As an user i want to decide, which network intefaces can be used for
connecting to the RPL instance.

Example:
--------
- In a home environment, some nodes may be added to the
DODAG over a PLC connection, while most nodes are communicating over
802.15.4.
- Same for an industrial application, where some nodes may be connected
over a RS-232 connection (SLIP interface) to the same RPL instance.
So some nodes may have two or more network interfaces and all of them
should be able to connect to the same DODAG.

Changes needed:
- Currently, the net-if is referenced by the RPL instance for each Node
in the DODAG. The net-if should be referenced by the RPL parent instead.
- ... ?

Regards,
Richard


Re: [net][question] 6LBR support

Siddalingesh S. Koosalapur <ks.siddalingesh@...>
 

Hi all,

I am trying to compile the code for cortex-m4 platform, got the below errors. could you please help me on this.

# make BOARD=qemu_cortex_m4 qemu
scripts/kconfig/conf --silentoldconfig Kconfig
.config:101:warning: symbol value '' invalid for SYS_CLOCK_HW_CYCLES_PER_SEC
*
* Restart config...
*
*
* General Kernel Options
*
System tick frequency (in ticks/second) (SYS_CLOCK_TICKS_PER_SEC) [100] 100
System clock's h/w timer frequency (SYS_CLOCK_HW_CYCLES_PER_SEC) [] (NEW) 100
Initialize stack areas (INIT_STACKS) [N/y/?] n
Execute in place (XIP) [Y/n/?] y
Enable ring buffers (RING_BUFFER) [N/y/?] n
Enable kernel event logger features (KERNEL_EVENT_LOGGER) [N/y/?] n
Task and fiber monitoring [EXPERIMENTAL] (THREAD_MONITOR) [N/y/?] n
Kernel objects initialization priority (KERNEL_INIT_PRIORITY_OBJECTS) [30] 30
Default init priority (KERNEL_INIT_PRIORITY_DEFAULT) [40] 40
Default init priority for device drivers (KERNEL_INIT_PRIORITY_DEVICE) [50] 50
Default init priority for application level drivers (APPLICATION_INIT_PRIORITY) [90] 90
#
# configuration written to .config
#
CHK include/generated/version.h
CHK misc/generated/configs.c
In file included from ./include/kernel.h:2906:0,
from ./kernel/unified/include/kernel_structs.h:21,
from arch/arm/core/offsets/offsets.c:37:
./include/legacy.h: In function ‘fiber_start’:
./include/legacy.h:210:5: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
(void *)(intptr_t)arg1, (void *)(intptr_t)arg2,
^
./include/legacy.h:210:29: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
(void *)(intptr_t)arg1, (void *)(intptr_t)arg2,
^
./include/legacy.h: In function ‘fiber_delayed_start’:
./include/legacy.h:317:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
(void *)(intptr_t)param1,
^
./include/legacy.h:318:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
(void *)(intptr_t)param2, NULL,
^
In file included from ./include/arch/arm/cortex_m/nvic.h:40:0,
from ./include/arch/arm/cortex_m/irq.h:28,
from ./include/arch/arm/arch.h:43,
from ./include/arch/cpu.h:25,
from ./include/kernel.h:2907,
from ./kernel/unified/include/kernel_structs.h:21,
from arch/arm/core/offsets/offsets.c:37:
./include/arch/arm/cortex_m/scs.h: In function ‘_scs_relocate_vector_table’:
./include/arch/arm/cortex_m/scs.h:664:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
__scs.scb.vtor.val = ((uint32_t)new_addr & 0xffffff80);
^
In file included from ./include/arch/arm/arch.h:53:0,
from ./include/arch/cpu.h:25,
from ./include/kernel.h:2907,
from ./kernel/unified/include/kernel_structs.h:21,
from arch/arm/core/offsets/offsets.c:37:
./include/arch/arm/cortex_m/sys_io.h: In function ‘sys_read32’:
./include/arch/arm/cortex_m/sys_io.h:32:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
return *(volatile uint32_t *)addr;
^
./include/arch/arm/cortex_m/sys_io.h: In function ‘sys_write32’:
./include/arch/arm/cortex_m/sys_io.h:38:3: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
*(volatile uint32_t *)addr = data;
^
./include/arch/arm/cortex_m/sys_io.h: In function ‘sys_set_bit’:
./include/arch/arm/cortex_m/sys_io.h:46:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
uint32_t temp = *(volatile uint32_t *)addr;
^
./include/arch/arm/cortex_m/sys_io.h:48:3: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
*(volatile uint32_t *)addr = temp | (1 << bit);
^
./include/arch/arm/cortex_m/sys_io.h: In function ‘sys_clear_bit’:
./include/arch/arm/cortex_m/sys_io.h:53:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
uint32_t temp = *(volatile uint32_t *)addr;
^
./include/arch/arm/cortex_m/sys_io.h:55:3: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
*(volatile uint32_t *)addr = temp & ~(1 << bit);
^
In file included from ./arch/arm/include/kernel_arch_data.h:95:0,
from ./kernel/unified/include/kernel_structs.h:59,
from arch/arm/core/offsets/offsets.c:37:
./arch/arm/include/cortex_m/stack.h: In function ‘_InterruptStackSetup’:
./arch/arm/include/cortex_m/stack.h:59:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
uint32_t msp = (uint32_t)(_interrupt_stack + CONFIG_ISR_STACK_SIZE);
^
CHK include/generated/offsets.h
ELF64 class not supported
make[1]: *** [include/generated/offsets.h] Error 1
make: *** [prepare] Error 2


Regards,
Siddalingesh

From: "Richard Peters" <peters(a)blockslab.com>
To: "devel" <devel(a)lists.zephyrproject.org>
Sent: Tuesday, January 10, 2017 4:24:09 PM
Subject: [devel] [net][question] 6LBR support

Hi Community,

does ZephyrOS implement functionallity for an 6LBR?
On one side of the 6LBR should be an ordinary IPv6 network, on the other
side an 6LoWPAN network with RPL routing.

If ZephyrOS supports acting as 6LBR, does it also implement the modes:
- routing between 6LoWPAN and IPv6 network with different prefixes
- bridging between 6LoWPAN and IPv6 network with same prefix
- transparent bridging between 6LoWPAN and IPv6 network,
in order to connect devices on the IPv6 side to the same DODAG root node
of the RPL instance in the 6LoWPAN?

I found this ticket:
https://jira.zephyrproject.org/browse/ZEP-628?jql=text%20~%20%22RPL%22
is this related to that? It seems a liitle bit unclear.

Thank you,
Richard

Disclaimer:- The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. The views expressed in this E-mail message (including the enclosure/(s) or attachment/(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of GlobalEdge. Before opening any mail and attachments please check them for viruses .GlobalEdge does not accept any liability for virus infected mails.


Re: Unable to clone zephyr code with 'git clone ssh:...'

punit vara <punitvara@...>
 

May I know how did you change the port ? in /.ssh/config ? If yes, can you please share me a config file


[RFC]DMA API Update

Liu, Baohong
 

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: 4
[ZEP-1554] Xtensa integration
https://jira.zephyrproject.org/browse/ZEP-1554

[ZEP-1552] Provide apds9960 sensor driver
https://jira.zephyrproject.org/browse/ZEP-1552

[ZEP-1555] echo client/server on 15.4 instability
https://jira.zephyrproject.org/browse/ZEP-1555

[ZEP-1551] Build error when STM32 GPIO Port F/G is selected
https://jira.zephyrproject.org/browse/ZEP-1551


UPDATED JIRA items within last 24 hours: 29
[ZEP-816] Minimum Rank with Hysteresis (RPL)
https://jira.zephyrproject.org/browse/ZEP-816

[ZEP-810] Network Time Protocol v4
https://jira.zephyrproject.org/browse/ZEP-810

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

[ZEP-1457] Add SPDX Tags to Zephyr licence boilerplate
https://jira.zephyrproject.org/browse/ZEP-1457

[ZEP-888] 802.15.4 - Security support
https://jira.zephyrproject.org/browse/ZEP-888

[ZEP-1205] Create test for LIFO kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1205

[ZEP-1206] Create test for FIFO kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1206

[ZEP-1208] Create test for Timer kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1208

[ZEP-1209] Create test for Memory slabs kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1209

[ZEP-1216] Create test for pipe kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1216

[ZEP-1210] Create test for memory pools kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1210

[ZEP-462] tcf: add support for running altera_max10 binaries
https://jira.zephyrproject.org/browse/ZEP-462

[ZEP-1321] Glossary of Terms needs updating
https://jira.zephyrproject.org/browse/ZEP-1321

[ZEP-1429] NXP MCR20A Driver
https://jira.zephyrproject.org/browse/ZEP-1429

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

[ZEP-1472] Support for the KW22D512 Kinetis MCU based USB Dongle
https://jira.zephyrproject.org/browse/ZEP-1472

[ZEP-833] IP-to-IP tunneling support
https://jira.zephyrproject.org/browse/ZEP-833

[ZEP-828] IPv6 - Multicast Join/Leave Support
https://jira.zephyrproject.org/browse/ZEP-828

[ZEP-634] document IRQ handling internals
https://jira.zephyrproject.org/browse/ZEP-634

[ZEP-879] 6LoWPAN - Stateless Address Autoconfiguration
https://jira.zephyrproject.org/browse/ZEP-879

[ZEP-578] handle configuration changes with more code coverage
https://jira.zephyrproject.org/browse/ZEP-578

[ZEP-1513] Port legacy kernel and benchmark tests to unified kernel
https://jira.zephyrproject.org/browse/ZEP-1513

[ZEP-1416] Potential race/non-monotonicity in k_cycle_get_32() for cortex_m, x86 loapic
https://jira.zephyrproject.org/browse/ZEP-1416

[ZEP-706] cannot set debug breakpoints on ARC side of Arduino 101
https://jira.zephyrproject.org/browse/ZEP-706

[ZEP-1545] AON Counter : ISR triggered twice on ARC
https://jira.zephyrproject.org/browse/ZEP-1545

[ZEP-1169] Sample mbedDTLS DTLS client stability on ethernet driver
https://jira.zephyrproject.org/browse/ZEP-1169

[ZEP-723] Sanity Crashes with "FileNotFound" exception when running samples/static_lib/test
https://jira.zephyrproject.org/browse/ZEP-723

[ZEP-1370] There's a wiki page for arduino_due but no zephyr/boards support folder
https://jira.zephyrproject.org/browse/ZEP-1370

[ZEP-1460] Sanity check reports some qemu step failures as 'build_error'
https://jira.zephyrproject.org/browse/ZEP-1460


CLOSED JIRA items within last 24 hours: 32
[ZEP-245] (Won't Do) Restructure Documentation content
https://jira.zephyrproject.org/browse/ZEP-245

[ZEP-1215] (Fixed) Create test for mailbox kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1215

[ZEP-1212] (Fixed) Create test for alert kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1212

[ZEP-1217] (Fixed) Create test for thread kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1217

[ZEP-1214] (Fixed) Create test for message queue kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1214

[ZEP-1213] (Fixed) Create test for stack kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1213

[ZEP-1207] (Fixed) Create test for semaphore kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1207

[ZEP-1211] (Fixed) Create test for mutex kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1211

[ZEP-1494] (Fixed) Create test for work queue kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1494

[ZEP-1222] (Fixed) Add save/restore support to ARC core
https://jira.zephyrproject.org/browse/ZEP-1222

[ZEP-19] (Fixed) IPSP node support
https://jira.zephyrproject.org/browse/ZEP-19

[ZEP-1288] (Fixed) Define _arc_v2_irq_unit device
https://jira.zephyrproject.org/browse/ZEP-1288

[ZEP-1223] (Fixed) Add save/restore support to arcv2_irq_unit
https://jira.zephyrproject.org/browse/ZEP-1223

[ZEP-1224] (Fixed) Add save/restore support to arcv2_timer_0/sys_clock
https://jira.zephyrproject.org/browse/ZEP-1224

[ZEP-690] (Fixed) TCF isn't setting ARCH when running testcases
https://jira.zephyrproject.org/browse/ZEP-690

[ZEP-738] (Fixed) samples/net/test_15_4 doesn't fit in Quark D2000 / Nucleo F103RB / Alimexino STM32
https://jira.zephyrproject.org/browse/ZEP-738

[ZEP-693] (Fixed) tests/kernel/test_lifo: execution fails on ARC
https://jira.zephyrproject.org/browse/ZEP-693

[ZEP-586] (Fixed) test_bat issues
https://jira.zephyrproject.org/browse/ZEP-586

[ZEP-1263] (Duplicate) test_mbox_api failed @ARC @ARM
https://jira.zephyrproject.org/browse/ZEP-1263

[ZEP-1265] (Fixed) test_mslab_init failed @ARC: block_size=5
https://jira.zephyrproject.org/browse/ZEP-1265

[ZEP-1201] (Done) tests/kernel/test_xip Doesn't fit `FLASH' region
https://jira.zephyrproject.org/browse/ZEP-1201

[ZEP-608] (Cannot Reproduce) Shell console suspends to output nothing once sleeping in shell application
https://jira.zephyrproject.org/browse/ZEP-608

[ZEP-1458] (Cannot Reproduce) tests/legacy/kernel/test_events: failure on ARC platforms
https://jira.zephyrproject.org/browse/ZEP-1458

[ZEP-757] (Fixed) tests/kernel/test_context/ fail in Arduino 101 and Quark SE C1000
https://jira.zephyrproject.org/browse/ZEP-757

[ZEP-1124] (Fixed) tests/kernel/test_sprintf/microkernel/testcase.ini#test failure on frdm_k64f
https://jira.zephyrproject.org/browse/ZEP-1124

[ZEP-436] (Fixed) Test case tests/kernel/test_mem_safe fails on ARM hardware
https://jira.zephyrproject.org/browse/ZEP-436

[ZEP-1068] (Fixed) [TCF] samples/net/test_15_4 build fail for EMSK
https://jira.zephyrproject.org/browse/ZEP-1068

[ZEP-674] (Fixed) atomic_test_and_set_bit failed in atomicity testing
https://jira.zephyrproject.org/browse/ZEP-674

[ZEP-685] (Fixed) many sample programs are not built by CI
https://jira.zephyrproject.org/browse/ZEP-685

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

[ZEP-1060] (Fixed) Contributor guide for documentation missing
https://jira.zephyrproject.org/browse/ZEP-1060

[ZEP-709] (Duplicate) tests/kernel/test_xip/nanokernel Times out on ARC core of Quark SE devboard and Arduino 101
https://jira.zephyrproject.org/browse/ZEP-709


RESOLVED JIRA items within last 24 hours: 0

5701 - 5720 of 7903