Date   

Re: Sensor result representation.

Bogdan Davidoaia <bogdan.davidoaia@...>
 

Hi Marcus,

After the first set of patches were merged I didn't start on the single
value representation, partly because I was waiting to see if there would be
any more feedback on the mailing list, and partly because of work related
changes and winter holiday.

Since there was no feedback against the change, I will start working on it
and hope to have the patch ready by next week.

Sorry if the delay on my part caused any inconveniences,
Bogdan

On Wed, Jan 4, 2017 at 8:09 PM, Marcus Shawcroft <marcus.shawcroft(a)gmail.com
wrote:
Re-send with updated email address for Bogdan...

On 4 January 2017 at 18:05, Marcus Shawcroft <marcus.shawcroft(a)gmail.com>
wrote:
On 29 November 2016 at 21:54, Davidoaia, Bogdan M
<bogdan.m.davidoaia(a)intel.com> wrote:

Hi Bodan,

If we want to define specific value types for each channel type, then
we might as well have the same type for all the channels. As you also
pointed out, using double is not really necessary for most drivers and the
ones that need it can just return the values converted to _INT_PLUS_MICRO.

As such, we could eliminate the type field altogether and have the
implicit type _INT_PLUS_MICRO (although this should be done as a separate
step, as it will affect the apps that use the type field).

If you think this is ok and nobody has an objection to this change,
then I can start working on it next Wednesday as I am currently away with
only access to email from time to time.

Following up on this old thread. Looking in the current tree we have
no drivers using SENSOR_VALUE_TYPE_DOUBLE, the sensor.h API does still
define SENSOR_VALUE_TYPE_DOUBLE and the type field used to distinguish
the last two remaining value types.

Is the intention that we continue along the path of moving to a single
value representation?

If so, are you intending to present further patches, if not, then I am
happy to post patches to continue this work.

Cheers
/Marcus


Re: Networking stack - Ethernet driver design

Tomasz Bursztyka
 

Hi Piotr,

1. Currently Ethernet drivers are by default initialized before the
networking stack (as set by CONFIG_ETH_INIT_PRIORITY). That's
going to be problematic for a zero-copy implementation of Ethernet
driver. Such driver will need to reserve during the initialization
phase a set of net data buffers where the incoming packets can be
stored. Later when the complete frame is received these buffers
will be passed to the higher layer. However, the net buffer pool
is initialized by the networking stack so reserving net buffers is
only possible after networking stack was initialized. That implies
that the Ethernet driver should be initialized after the
networking stack. Secondly, even in case of the more typical
implementation of the Ethernet driver, the one which has its own
set of RX/TX buffers and copies data between them and net buffers,
as currently done in Zephyr, the driver will start working
immediately after being initialized. If it receives a frame just
at that moment it will try to pass it to the higher layer even if
the rest of the networking stack was not yet initialized. Once
again that implies that the Ethernet driver should be initialized
after the networking stack is.
You are mixing different issues here: your own driver design and known
current limitations in net stack.
I will address your driver design issue in your patches (however apply
first style comments).

Currently, all net interface are up and running as soon as they are
initialized. This was done like that because it was just easier to move
on with more important things.
Work is being done to modify this behavior (up/down iface state,
etc...). Drivers will always be initialized before the network stack,
there is currently no design that require
the other way round, even yours.

1. Modern Ethernet modules in most of the SoC devices have ability to
generate IP, TCP and UDP checksums in hardware. Is it possible to
tell networking stack not to compute these checksums in software?
For now, no. There is no generic CRC API that could - depending on
configuration and hardware - either call a software routine or run it on
hardware directly.

1. One of the parameters to NET_DEVICE_INIT is MTU. Shouldn't we have
a set of predefined constants provided by the networking stack for
some typical interfaces. E.g. NET_MTU_ETHERNET set to 1500? Should
we configure the MTU value in Kconfig?
Don't bother with that. MTU is not taken into account in network stack,
this is a big known crappy limitations.
There is on-going work to fix it properly.

Br,

Tomasz


Reg: Task state read function in zephyr ?

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

Hi All

Is there any function in Zephyr rtos to know about the Task state ?

Ex: Before suspending a task , check using task state whether the task is started or not and then suspend the task.

I know we can handle this using some flag.. But need to know any function call is available in zephyr for this task state.

Best regards
Mahendra


Re: Linker Script Issue When Porting To CC2538

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

Hi Andy,

Yes, your idea might ok, I'll try it this night.

Do you really need to do this with the linker? What are you trying to place in this region? If it's a fixed set of data you could just do it something like:

struct cca_rec {
int my_field1;
char my_field2[128];
/* ... */
};

#define CCA_REC ((struct cca_rec *)0x0027ffd4)

Hi Chuck,
Thanks for your information.


Best Regards,
Tidy.


Re: Networking stack - Ethernet driver design

Chuck Jordan <Chuck.Jordan@...>
 

From: Piotr Mienkowski [mailto:piotr.mienkowski(a)gmail.com]
Sent: Wednesday, January 04, 2017 9:25 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Networking stack - Ethernet driver design


Hi all,

I have a few questions/discussion points related to the new networking stack in context of Ethernet driver development.

1. Currently Ethernet drivers are by default initialized before the networking stack (as set by CONFIG_ETH_INIT_PRIORITY). That's going to be problematic for a zero-copy implementation of Ethernet driver. Such driver will need to reserve during the initialization phase a set of net data buffers where the incoming packets can be stored. Later when the complete frame is received these buffers will be passed to the higher layer. However, the net buffer pool is initialized by the networking stack so reserving net buffers is only possible after networking stack was initialized. That implies that the Ethernet driver should be initialized after the networking stack. Secondly, even in case of the more typical implementation of the Ethernet driver, the one which has its own set of RX/TX buffers and copies data between them and net buffers, as currently done in Zephyr, the driver will start working immediately after being initialized. If it receives a frame just at that moment it will try to pass it to the higher layer even if the rest of the networking stack was not yet initialized. Once again that implies that the Ethernet driver should be initialized after the networking stack is.
[chuckj] I would think if the Enet driver comes alive FIRST, and receives something, but no protocol stack has attached itself yet, that it could simply DROP the packet. ENET allows you to drop packets anywhere, anytime. So I could imagine the ENET driver coming alive first, doing its own initialization, acquiring its own buffers. Further, it should be agnostic as to which protocol stack attaches to it. There are protocols that have something OTHER than TCP/IP over ENET. For example, ATM packets over ENET, or any other encapsulation. Although, admittedly, this is very unlikely to appear with Zephyr.
So one way to design this is that the DRIVER owns the buffers, and that the buffers must always be returned to the driver when the protocol stack has consumed the packet. The API the protocol stack uses is a call to read a packet, getting a new buffer, and then another API to return the buffer later – to keep it zero copy. Sending would first have the application acquire a buffer, then fill it with a packet, then transmit it – with an attempt to utilize scatter-gather techniques to avoid memory copying (i.e. payload is not copied).

1. Modern Ethernet modules in most of the SoC devices have ability to generate IP, TCP and UDP checksums in hardware. Is it possible to tell networking stack not to compute these checksums in software?
This would be another configurable thing I guess. Also ENDIAN swap. Also the 2-byte GAP can be a problem between ENET header and IP header – if hardware requires 32-bit alignment. There are a lot of little things like this that some hardware can handle and some hardware cannot. I suppose all of these things should be configurable.

1. One of the parameters to NET_DEVICE_INIT is MTU. Shouldn't we have a set of predefined constants provided by the networking stack for some typical interfaces. E.g. NET_MTU_ETHERNET set to 1500? Should we configure the MTU value in Kconfig?
[chuckj] Most of the time MTU 1500 is probably just fine. Where I have seen people set this bigger is when streaming video (or something else) requires packets that are a lot bigger for efficiency. So YES having this configurable might be a good idea – although on low-end Zephyr devices, with modest memory sizes, modest MAC/PHY, its probably unlikely to be set big.
When TCP-offload devices are used, I would think there are large set of things to configure.
Regards,
Piotr


Re: Linker Script Issue When Porting To CC2538

Chuck Jordan <Chuck.Jordan@...>
 

Btw, with the device-tree stuff being added, it might be possible to auto-generate the MEMORY { } part of a linker command file, using information from the device-tree.
BUT, the MEMORY {} part should hold ONLY simple memories in this scheme -- and not express custom areas within memories.
The custom areas within memories can be done using bottom portion of the linker command-file.

That would be a good coding practice going forward in that it
* keeps things SIMPLE and understandable
* MEMORY {} expresses true HARDWARE aspects of the memory map
* allows for auto-generate of MEMORY {} declaration under some circumstances (I suppose this could be overridden if it's a problem)

I know this is an individual choice, and I have certainly seen people go overboard within the MEMORY {} declaration, defining all sorts of custom regions.
One common usage for this is when its multi-core and you want to express only a PORTION of DRAM or SRAM as a shared region.
But even that could be done in the lower portion OUTSIDE the MEMORY {} declaration.

-Chuck J.

-----Original Message-----
From: Andy Ross [mailto:andrew.j.ross(a)intel.com]
Sent: Wednesday, January 04, 2017 9:04 AM
To: Tidy(ChunHua) Jiang <tidyjiang(a)163.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: Linker Script Issue When Porting To CC2538

Tidy(chunhua) Jiang <tidyjiang(a)163.com> wrote (on Tuesday, January 03, 2017 10:59PM):
I'm porting zephyr to TI's CC2538 device family, but there is a
special user case -- customer configuration area(CCA/CCFG). CCA is
placed in the uppermost flash page, so the linker script would like
this:

MEMORY
{
FLASH (rx) : ORIGIN = 0x00200000, LENGTH = 0x0007FFD4
*FLASH_CCA (rx) : ORIGIN = 0x0027FFD4, LENGTH = 0x2C*
SRAM (wx) : ORIGIN = RAM_ADDR, LENGTH = RAM_SIZE
SYSTEM_CONTROL_SPACE (wx) : ORIGIN = 0xE000E000, LENGTH = 4K
SYSTEM_CONTROL_PERIPH (wx) : ORIGIN = 0x400FE000, LENGTH = 4K
}

Zephyr doesn't really have a facility for device-specific modifications to linker scripts at the moment. The script that you would need to modify is in include/arch/arm/cortex_m/scripts/linker.ld. This is passed through the C preprocessor and has access to all Kconfig symbols, so if you had to you could #ifdef your changes there and submit them, but it would be a little ugly and we should probably come up with something cleaner.

Do you really need to do this with the linker? What are you trying to place in this region? If it's a fixed set of data you could just do it something like:

struct cca_rec {
int my_field1;
char my_field2[128];
/* ... */
};

#define CCA_REC ((struct cca_rec *)0x0027ffd4)

And then just dereference the symbols you would have put in that region with CCA_REC->my_field1, etc...

It's much simpler to implement, and might do what you want without requiring immediate surgery to our linker script generation.

Andy


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

Liu, Baohong
 

If your purpose is to see the message prints, you do not need the USB stuff. Message printing on arc will be routed to the same uart port as x86. No extra thing is needed. I strongly suggest you to look at the sample app for BMI160.

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, January 3, 2017 10:09 PM
To: Chuck Jordan <Chuck.Jordan(a)synopsys.com>; Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: reg: Routing SPI signals connected from x86 core to the Arc core

Hi Both

As you said I have tried to compile directly using arc and its compiling

I thought to route the debug prints through UART over usb.

But I think the current version supports UART over usb only on x86 (quark_se_c1000_devboard) not on arc (quark_se_c1000_ss_devboard)

Because while compiling I am getting error as
"In file included from /home/mahendra/guestshare/mahendra/zephyr-v1.6.0/drivers/usb/device/usb_dc_dw.c:32:0:
/home/mahendra/guestshare/mahendra/zephyr-v1.6.0/drivers/usb/device/usb_dw_registers.h:211:2: error: #error "Unsupported board" #error "Unsupported board"

Best regards
mahendra
From: Chuck Jordan [mailto:Chuck.Jordan(a)synopsys.com]
Sent: Tuesday, January 03, 2017 11:48 PM
To: Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com<mailto:tomasz.bursztyka(a)linux.intel.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: Re: reg: Routing SPI signals connected from x86 core to the Arc core

OR, the ARC can utilize SPI too and talk to the accelerometer directly.
It just depends upon which CPU you want to OWN which resource.
-Chuck

From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Tuesday, January 03, 2017 5:09 AM
To: 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

Hi,

You can use IPM API to send data from one core to another.
See include/ipm.h

Your accelerometer implements sensor API I guess? So it can trigger
a callback, which in turn would send the information to the ARC core
through IPM.

For the sensor trigger part, see samples/sensor ones. (bmi160 for instance).
And for ipm: samples/ipm ones.

Tomasz
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: Sensor result representation.

Marcus Shawcroft <marcus.shawcroft@...>
 

Re-send with updated email address for Bogdan...

On 4 January 2017 at 18:05, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> wrote:
On 29 November 2016 at 21:54, Davidoaia, Bogdan M
<bogdan.m.davidoaia(a)intel.com> wrote:

Hi Bodan,

If we want to define specific value types for each channel type, then we might as well have the same type for all the channels. As you also pointed out, using double is not really necessary for most drivers and the ones that need it can just return the values converted to _INT_PLUS_MICRO.

As such, we could eliminate the type field altogether and have the implicit type _INT_PLUS_MICRO (although this should be done as a separate step, as it will affect the apps that use the type field).

If you think this is ok and nobody has an objection to this change, then I can start working on it next Wednesday as I am currently away with only access to email from time to time.
Following up on this old thread. Looking in the current tree we have
no drivers using SENSOR_VALUE_TYPE_DOUBLE, the sensor.h API does still
define SENSOR_VALUE_TYPE_DOUBLE and the type field used to distinguish
the last two remaining value types.

Is the intention that we continue along the path of moving to a single
value representation?

If so, are you intending to present further patches, if not, then I am
happy to post patches to continue this work.

Cheers
/Marcus


Re: Sensor result representation.

Marcus Shawcroft <marcus.shawcroft@...>
 

On 29 November 2016 at 21:54, Davidoaia, Bogdan M
<bogdan.m.davidoaia(a)intel.com> wrote:

Hi Bodan,

If we want to define specific value types for each channel type, then we might as well have the same type for all the channels. As you also pointed out, using double is not really necessary for most drivers and the ones that need it can just return the values converted to _INT_PLUS_MICRO.

As such, we could eliminate the type field altogether and have the implicit type _INT_PLUS_MICRO (although this should be done as a separate step, as it will affect the apps that use the type field).

If you think this is ok and nobody has an objection to this change, then I can start working on it next Wednesday as I am currently away with only access to email from time to time.
Following up on this old thread. Looking in the current tree we have
no drivers using SENSOR_VALUE_TYPE_DOUBLE, the sensor.h API does still
define SENSOR_VALUE_TYPE_DOUBLE and the type field used to distinguish
the last two remaining value types.

Is the intention that we continue along the path of moving to a single
value representation?

If so, are you intending to present further patches, if not, then I am
happy to post patches to continue this work.

Cheers
/Marcus


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

Joseph, Jithu
 

But I think the current version supports UART over usb only on x86 (quark_se_c1000_devboard) not on arc (quark_se_c1000_ss_devboard)
Right, USB device functionality in general is supported only on the x86 side of C1000, consequently USB UART is only available there and not on the ARC side.

Thanks

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, January 3, 2017 10:09 PM
To: Chuck Jordan <Chuck.Jordan(a)synopsys.com>; Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: reg: Routing SPI signals connected from x86 core to the Arc core

Hi Both

As you said I have tried to compile directly using arc and its compiling

I thought to route the debug prints through UART over usb.

But I think the current version supports UART over usb only on x86 (quark_se_c1000_devboard) not on arc (quark_se_c1000_ss_devboard)

Because while compiling I am getting error as
"In file included from /home/mahendra/guestshare/mahendra/zephyr-v1.6.0/drivers/usb/device/usb_dc_dw.c:32:0:
/home/mahendra/guestshare/mahendra/zephyr-v1.6.0/drivers/usb/device/usb_dw_registers.h:211:2: error: #error "Unsupported board" #error "Unsupported board"

Best regards
mahendra
From: Chuck Jordan [mailto:Chuck.Jordan(a)synopsys.com]
Sent: Tuesday, January 03, 2017 11:48 PM
To: Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com<mailto:tomasz.bursztyka(a)linux.intel.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: Re: reg: Routing SPI signals connected from x86 core to the Arc core

OR, the ARC can utilize SPI too and talk to the accelerometer directly.
It just depends upon which CPU you want to OWN which resource.
-Chuck

From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Tuesday, January 03, 2017 5:09 AM
To: 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

Hi,

You can use IPM API to send data from one core to another.
See include/ipm.h

Your accelerometer implements sensor API I guess? So it can trigger
a callback, which in turn would send the information to the ARC core
through IPM.

For the sensor trigger part, see samples/sensor ones. (bmi160 for instance).
And for ipm: samples/ipm ones.

Tomasz
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


Networking stack - Ethernet driver design

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

Hi all,

I have a few questions/discussion points related to the new networking
stack in context of Ethernet driver development.

1. Currently Ethernet drivers are by default initialized before the
networking stack (as set by CONFIG_ETH_INIT_PRIORITY). That's going
to be problematic for a zero-copy implementation of Ethernet driver.
Such driver will need to reserve during the initialization phase a
set of net data buffers where the incoming packets can be stored.
Later when the complete frame is received these buffers will be
passed to the higher layer. However, the net buffer pool is
initialized by the networking stack so reserving net buffers is only
possible after networking stack was initialized. That implies that
the Ethernet driver should be initialized after the networking
stack. Secondly, even in case of the more typical implementation of
the Ethernet driver, the one which has its own set of RX/TX buffers
and copies data between them and net buffers, as currently done in
Zephyr, the driver will start working immediately after being
initialized. If it receives a frame just at that moment it will try
to pass it to the higher layer even if the rest of the networking
stack was not yet initialized. Once again that implies that the
Ethernet driver should be initialized after the networking stack is.
2. Modern Ethernet modules in most of the SoC devices have ability to
generate IP, TCP and UDP checksums in hardware. Is it possible to
tell networking stack not to compute these checksums in software?
3. One of the parameters to NET_DEVICE_INIT is MTU. Shouldn't we have a
set of predefined constants provided by the networking stack for
some typical interfaces. E.g. NET_MTU_ETHERNET set to 1500? Should
we configure the MTU value in Kconfig?

Regards,
Piotr


Re: Linker Script Issue When Porting To CC2538

Andy Ross
 

Tidy(chunhua) Jiang <tidyjiang(a)163.com> wrote (on Tuesday, January 03, 2017 10:59PM):
I'm porting zephyr to TI's CC2538 device family, but there is a
special user case —— customer configuration area(CCA/CCFG). CCA is
placed in the uppermost flash page, so the linker script would like
this:

MEMORY
{
FLASH (rx) : ORIGIN = 0x00200000, LENGTH = 0x0007FFD4
*FLASH_CCA (rx) : ORIGIN = 0x0027FFD4, LENGTH = 0x2C*
SRAM (wx) : ORIGIN = RAM_ADDR, LENGTH = RAM_SIZE
SYSTEM_CONTROL_SPACE (wx) : ORIGIN = 0xE000E000, LENGTH = 4K
SYSTEM_CONTROL_PERIPH (wx) : ORIGIN = 0x400FE000, LENGTH = 4K
}

Zephyr doesn't really have a facility for device-specific
modifications to linker scripts at the moment. The script that you
would need to modify is in
include/arch/arm/cortex_m/scripts/linker.ld. This is passed through
the C preprocessor and has access to all Kconfig symbols, so if you
had to you could #ifdef your changes there and submit them, but it
would be a little ugly and we should probably come up with something
cleaner.

Do you really need to do this with the linker? What are you trying to
place in this region? If it's a fixed set of data you could just do it
something like:

struct cca_rec {
int my_field1;
char my_field2[128];
/* ... */
};

#define CCA_REC ((struct cca_rec *)0x0027ffd4)

And then just dereference the symbols you would have put in that
region with CCA_REC->my_field1, etc...

It's much simpler to implement, and might do what you want without
requiring immediate surgery to our linker script generation.

Andy


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 6
[ZEP-1505] extend sanitycheck to support ARC simulator
https://jira.zephyrproject.org/browse/ZEP-1505

[ZEP-1511] Add Support for Multiple Simultaneous Backends/Partitions for FS
https://jira.zephyrproject.org/browse/ZEP-1511

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

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

[ZEP-1506] tests/kernel/threads_scheduling/schedule_api: Failures on x86 and ARM
https://jira.zephyrproject.org/browse/ZEP-1506

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


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

[ZEP-820] HTTP v1.1 Server Sample
https://jira.zephyrproject.org/browse/ZEP-820

[ZEP-1483] H:4 HCI driver (h4.c) should rely on UART flow control to avoid dropping packets
https://jira.zephyrproject.org/browse/ZEP-1483

[ZEP-544] Web site search on /doc pages returns no results
https://jira.zephyrproject.org/browse/ZEP-544


CLOSED JIRA items within last 24 hours: 3
[ZEP-1181] (Won't Do) zephyrSDK + newlib: unexpected warning raised when print "uint32_t" with "%u"
https://jira.zephyrproject.org/browse/ZEP-1181

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

[ZEP-1475] (Fixed) k_free documentation should specify that NULL is valid
https://jira.zephyrproject.org/browse/ZEP-1475


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9608 : [DO NOT MERGE] doc: move documetnation context to root directory
- https://gerrit.zephyrproject.org/r/9639 : doc: support official website theme
- https://gerrit.zephyrproject.org/r/9615 : arm: nvic: Fix exception priority access on Cortex-M0(+)
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/9637 : Bluetooth: AT: HFP HF: Handle unsolicited reponse
- https://gerrit.zephyrproject.org/r/9636 : Bluetooth: HFP HF: Rename cind_status_handle_values
- https://gerrit.zephyrproject.org/r/9635 : Bluetooth: AT: Reset AT and CMD state
- https://gerrit.zephyrproject.org/r/9634 : net: event: Notify on interface being put down or up
- https://gerrit.zephyrproject.org/r/9633 : net: event: Fix misplaced comment
- https://gerrit.zephyrproject.org/r/9616 : arm: Cortex-M0: Adapt core register code to M0
- https://gerrit.zephyrproject.org/r/9592 : Makefile (arc/soc/quark_se): New compiler options
- https://gerrit.zephyrproject.org/r/9598 : ethernet: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9600 : random: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9595 : doc: remove obsolete file
- https://gerrit.zephyrproject.org/r/9607 : doc: samples: fix rst layout and use code-blocks
- https://gerrit.zephyrproject.org/r/9604 : MAINTAINERS: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9597 : ksdk: mcux: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9603 : ksdk: mcux: Remove config HAS_KSDK
- https://gerrit.zephyrproject.org/r/9599 : i2c: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9602 : pinmux: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9601 : flash: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9606 : doc: add JIRA macro
- https://gerrit.zephyrproject.org/r/9609 : sanity: prevent stack corruption at test_static_idt
- https://gerrit.zephyrproject.org/r/9596 : pinmux: Remove stale ksdk pinmux dev references
- https://gerrit.zephyrproject.org/r/9594 : arc: add -fno-delete-null-pointer-checks
- https://gerrit.zephyrproject.org/r/9591 : Makefile (arc/soc/em*): New compiler options
- https://gerrit.zephyrproject.org/r/9590 : Makefile.toolchain.zephyr: Modifications for SDK 0.9

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9542 : arm: Restructure ARM cpu related preprocessor conditionals.
- https://gerrit.zephyrproject.org/r/9545 : arm: Adjust cortex-m7 support to reflect its ARMv7-M architecture.
- https://gerrit.zephyrproject.org/r/9468 : Bluetooth: HFP HF: SLC Enable indicator status report
- https://gerrit.zephyrproject.org/r/7263 : Bluetooth: samples: handsfree application indicator callback
- https://gerrit.zephyrproject.org/r/9541 : arm: cortex-m memory map is CPU specific
- https://gerrit.zephyrproject.org/r/9540 : arm: Fix assembler layout.
- https://gerrit.zephyrproject.org/r/9544 : arm: Replace CONFIG_CPU_CORTEX_M3_M4 with CONFIG_ARMV7_M
- https://gerrit.zephyrproject.org/r/9543 : arm: Replace CONFIG_CPU_CORTEX_M0_M0PLUS with CONFIG_ARMV6_M
- https://gerrit.zephyrproject.org/r/7632 : net: ieee802154: Add grounds for passive scan
- https://gerrit.zephyrproject.org/r/7639 : net: ieee802154: Handle disassocation notification from PAN coordinator
- https://gerrit.zephyrproject.org/r/7640 : samples: ieee802154: Let's proceed with an active scan
- https://gerrit.zephyrproject.org/r/7638 : net: ieee802154: Add PAN disassociation request
- https://gerrit.zephyrproject.org/r/7637 : net: ieee80215: Add Active Scan request
- https://gerrit.zephyrproject.org/r/7636 : net: ieee802154: Integrate MAC Command frames handling
- https://gerrit.zephyrproject.org/r/7635 : net: ieee802154: Add PAN association request
- https://gerrit.zephyrproject.org/r/7634 : samples: net: ieee802154: Once cc2520 is up, let's initiate a scan
- https://gerrit.zephyrproject.org/r/7633 : net: ieee802154: Integrate beacon frame handling
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/7622 : clock/stm32: add STM32F107 reset and clock control
- https://gerrit.zephyrproject.org/r/7623 : clock/stm32: add STM32F3X reset and clock control
- https://gerrit.zephyrproject.org/r/6717 : Bluetooth: A2DP: A2DP sink service record registration
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/9325 : gpio/stm32: provide GPIO driver implementation for STM32F3X family
- https://gerrit.zephyrproject.org/r/9328 : Bluetooth: AVDTP: Add Accept Incoming connection cb
- https://gerrit.zephyrproject.org/r/7492 : Bluetooth: A2DP: Added Preset Structure
- https://gerrit.zephyrproject.org/r/6720 : Bluetooth: A2DP: Stream End Point Registration
- https://gerrit.zephyrproject.org/r/6719 : Bluetooth: A2DP: Stream End Point Structure
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/9460 : Bluetooth: AVDTP: Add AVDTP Discover Function Definition
- https://gerrit.zephyrproject.org/r/9331 : Bluetooth: A2DP: Adds accept state callback handlers
- https://gerrit.zephyrproject.org/r/9516 : drivers: Add Atmel SAM family GMAC Ethernet driver
- https://gerrit.zephyrproject.org/r/9446 : Bluetooth: AVDTP: Added pointer to Pending Request
- https://gerrit.zephyrproject.org/r/7496 : soc/stm32f1: Add the new type of SoC STM32F107
- https://gerrit.zephyrproject.org/r/9463 : tests: kernel: added memory pool kconfig test
- https://gerrit.zephyrproject.org/r/9462 : tests: kernel: added memory pool concept test
- https://gerrit.zephyrproject.org/r/9464 : tests: kernel: added memory pool threadsafe test
- https://gerrit.zephyrproject.org/r/9461 : tests: kernel: added memory pool api test
- https://gerrit.zephyrproject.org/r/9506 : tests: kernel: added memory slab api test
- https://gerrit.zephyrproject.org/r/9507 : tests: kernel: added memory slab concept test
- https://gerrit.zephyrproject.org/r/9508 : tests: kernel: added memory slab threadsafe test
- https://gerrit.zephyrproject.org/r/9505 : tests: kernel: re-path mslab test
- https://gerrit.zephyrproject.org/r/9546 : Switch logrotate to build-discarder
- https://gerrit.zephyrproject.org/r/9556 : net/mqtt: Add the mqtt_rx_publish routine
- https://gerrit.zephyrproject.org/r/9558 : net/mqtt: Allow an MQTT subscriber app to receive msgs
- https://gerrit.zephyrproject.org/r/9554 : net/mqtt: Add the reception callback
- https://gerrit.zephyrproject.org/r/9553 : net/mqtt: Use the right data type
- https://gerrit.zephyrproject.org/r/9557 : net/mqtt: Allow an MQTT publisher app to receive msgs
- https://gerrit.zephyrproject.org/r/9559 : net/mqtt: Improve buffer error handling in mqtt_tx routines
- https://gerrit.zephyrproject.org/r/9555 : net/mqtt: Add missing function prototypes
- https://gerrit.zephyrproject.org/r/9560 : net/mqtt: Improve error handling in mqtt_rx_connack routine
- https://gerrit.zephyrproject.org/r/9550 : net/nbuf: Introduce the net_nbuf_linear_copy routine
- https://gerrit.zephyrproject.org/r/9551 : net/mqtt: Make input arguments const
- https://gerrit.zephyrproject.org/r/9564 : net/dns: Introduce the qname_copy routine
- https://gerrit.zephyrproject.org/r/9552 : net/mqtt: Improve indentation
- https://gerrit.zephyrproject.org/r/9520 : commit-message: Fix logging info
- https://gerrit.zephyrproject.org/r/9489 : kernel/arch: inspect prio/sched_locked together for preemptibility
- https://gerrit.zephyrproject.org/r/9487 : samples: put philosophers stacks in noinit section
- https://gerrit.zephyrproject.org/r/9486 : samples: speed up philosophers demo
- https://gerrit.zephyrproject.org/r/9485 : kernel: add _timeout_q dump before and after adding timeout
- https://gerrit.zephyrproject.org/r/9484 : kernel: do not use sys_dlist_insert_at() in _add_timeout()
- https://gerrit.zephyrproject.org/r/9483 : kernel: do not use sys_dlist_insert_at() in _pend_thread()
- https://gerrit.zephyrproject.org/r/9482 : dlist: add sys_dlist_peek_tail()
- https://gerrit.zephyrproject.org/r/9481 : nios2: remove unused INT_ACTIVE/EXC_ACTIVE thread flags
- https://gerrit.zephyrproject.org/r/9478 : kernel: make _thread.sched_locked a non-atomic operator variable
- https://gerrit.zephyrproject.org/r/9479 : kernel/arch: reverse polarity on sched_locked
- https://gerrit.zephyrproject.org/r/9480 : kernel/arch: streamline thread flag bits used
- https://gerrit.zephyrproject.org/r/9586 : sanitycheck: reduce number of unnecessary configuration builds
- https://gerrit.zephyrproject.org/r/8710 : riscv32: added support for the riscv32-qemu soc
- https://gerrit.zephyrproject.org/r/8709 : riscv32: added support for the pulpino soc
- https://gerrit.zephyrproject.org/r/8713 : boards: added support for the qemu_riscv32 board

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9611 : arm: nvic: Use uint8_t for priority level
- https://gerrit.zephyrproject.org/r/9610 : Bluetooth: A2DP: Removes confirmation callback registration
- https://gerrit.zephyrproject.org/r/9593 : gpio_basic_api: fix format codes
- https://gerrit.zephyrproject.org/r/9588 : tests/kernel/stackprot: 'fatal fault' is not a failure
- https://gerrit.zephyrproject.org/r/9589 : test_thread_init.c: fix build error
- https://gerrit.zephyrproject.org/r/9587 : Bluetooth: Controller: revert to event callback inside radio ISR
- https://gerrit.zephyrproject.org/r/9335 : net: l2: Add enable callback
- https://gerrit.zephyrproject.org/r/9231 : net: if: Add NET_IF_UP flag
- https://gerrit.zephyrproject.org/r/9282 : samples: heartrate-monitor: Switch to unified kernel
- https://gerrit.zephyrproject.org/r/9503 : arm: nvic: Use uint8_t for priority level
- https://gerrit.zephyrproject.org/r/9475 : arm: Cortex-M0: Adapt core register code to M0
- https://gerrit.zephyrproject.org/r/9455 : arm: nvic: Fix exception priority access on Cortex-M0(+)
- https://gerrit.zephyrproject.org/r/9504 : sanity: prevent stack corruption at test_sema
- https://gerrit.zephyrproject.org/r/7769 : sanitycheck: add --log-file to log everything to a file too
- https://gerrit.zephyrproject.org/r/9581 : Bluetooth: RFCOMM: Rearrange fns to avoid forward declaration
- https://gerrit.zephyrproject.org/r/9569 : Bluetooth: SDP: Update 'no records found' code comment
- https://gerrit.zephyrproject.org/r/9582 : Bluetooth: RFCOMM: Implement timer in dlc
- https://gerrit.zephyrproject.org/r/9454 : Bluetooth: SDP: Add UUID reference to user callback
- https://gerrit.zephyrproject.org/r/9345 : tests: introduce Makefile.test
- https://gerrit.zephyrproject.org/r/9420 : doc: move c library section to subsystems
- https://gerrit.zephyrproject.org/r/9419 : doc: move ztest to subsystems
- https://gerrit.zephyrproject.org/r/9567 : MAINTAINERS: Update network applications section
- https://gerrit.zephyrproject.org/r/9576 : bluetooth: controller: Split events into normal and priority


Linker Script Issue When Porting To CC2538

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

Hello,

I'm porting zephyr to TI's CC2538 device family, but there is a special user case —— customer
configuration area(CCA/CCFG). CCA is placed in the uppermost flash page, so the linker script
would like this:

MEMORY
{
FLASH (rx) : ORIGIN = 0x00200000, LENGTH = 0x0007FFD4
FLASH_CCA (rx) : ORIGIN = 0x0027FFD4, LENGTH = 0x2C
SRAM (wx) : ORIGIN = RAM_ADDR, LENGTH = RAM_SIZE
SYSTEM_CONTROL_SPACE (wx) : ORIGIN = 0xE000E000, LENGTH = 4K
SYSTEM_CONTROL_PERIPH (wx) : ORIGIN = 0x400FE000, LENGTH = 4K
}

ENTRY(flash_cca_lock_page)

...
GROUP_START(FLASH_CCA)
SECTION_PROLOGUE(.flash_cca,,)
{
KEEP(*(.flash_cca))

} GROUP_LINK_IN(FLASH_CCA)
GROUP_END(FLASH_CCA)
...

Please ignore the numerical hard-code.
How can I compatibly place this code to the original link script?
Does this ok:?

SECTIONS
{
GROUP_START(ROMABLE_REGION)
...
#ifdef CONFIG_CC2538_CCA_XXXXX
SECTION_PROLOGUE(.flash_cca,,)
{
. = 0x0027FFD4
KEEP(*(.flash_cca))
} GROUP_LINK_IN(ROMABLE_REGION)
#endif // CONFIG_CC2538_CCA_XXXXX
GROUP_END(ROMABLE_REGION)
...
}
Please ignore the numerical hard-code too.
Best Regards,
tidyjiang.


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

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

Hi Both

As you said I have tried to compile directly using arc and its compiling

I thought to route the debug prints through UART over usb.

But I think the current version supports UART over usb only on x86 (quark_se_c1000_devboard) not on arc (quark_se_c1000_ss_devboard)

Because while compiling I am getting error as
"In file included from /home/mahendra/guestshare/mahendra/zephyr-v1.6.0/drivers/usb/device/usb_dc_dw.c:32:0:
/home/mahendra/guestshare/mahendra/zephyr-v1.6.0/drivers/usb/device/usb_dw_registers.h:211:2: error: #error "Unsupported board" #error "Unsupported board"

Best regards
mahendra

From: Chuck Jordan [mailto:Chuck.Jordan(a)synopsys.com]
Sent: Tuesday, January 03, 2017 11:48 PM
To: Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: reg: Routing SPI signals connected from x86 core to the Arc core

OR, the ARC can utilize SPI too and talk to the accelerometer directly.
It just depends upon which CPU you want to OWN which resource.
-Chuck

From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Tuesday, January 03, 2017 5:09 AM
To: 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

Hi,

You can use IPM API to send data from one core to another.
See include/ipm.h

Your accelerometer implements sensor API I guess? So it can trigger
a callback, which in turn would send the information to the ARC core
through IPM.

For the sensor trigger part, see samples/sensor ones. (bmi160 for instance).
And for ipm: samples/ipm ones.

Tomasz
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: reg: Routing SPI signals connected from x86 core to the Arc core

Chuck Jordan <Chuck.Jordan@...>
 

OR, the ARC can utilize SPI too and talk to the accelerometer directly.
It just depends upon which CPU you want to OWN which resource.
-Chuck

From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Tuesday, January 03, 2017 5:09 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: reg: Routing SPI signals connected from x86 core to the Arc core

Hi,

You can use IPM API to send data from one core to another.
See include/ipm.h

Your accelerometer implements sensor API I guess? So it can trigger
a callback, which in turn would send the information to the ARC core
through IPM.

For the sensor trigger part, see samples/sensor ones. (bmi160 for instance).
And for ipm: samples/ipm ones.

Tomasz
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: reg: Routing SPI signals connected from x86 core to the Arc core

Liu, Baohong
 

Sorry. Typo.

Top of the tree.

From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, January 3, 2017 10:06 AM
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: reg: Routing SPI signals connected from x86 core to the Arc core

Liu, Baohong
 

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
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: mqtt - tcp client connection - samples

Flavio Santes <flavio.santes@...>
 

Hello,

TCP support is planned for Zephyr 1.7:

https://jira.zephyrproject.org/browse/ZEP-791

So it must be ready before the merge window, see:

https://gerrit.zephyrproject.org/r/#/q/status:open+project:zephyr+branch:master+topic:tcp

Regards,
Flavio

5901 - 5920 of 8046