Date   

Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-1514] samples/bluetooth/ipsp build fail: net/ip_buf.h No such file or directory
https://jira.zephyrproject.org/browse/ZEP-1514


UPDATED JIRA items within last 24 hours: 6
[ZEP-820] HTTP v1.1 Server Sample
https://jira.zephyrproject.org/browse/ZEP-820

[ZEP-791] TCP
https://jira.zephyrproject.org/browse/ZEP-791

[ZEP-854] CoAP with DTLS sample
https://jira.zephyrproject.org/browse/ZEP-854

[ZEP-902] Reduce the use of Kconfig for FS to minimum
https://jira.zephyrproject.org/browse/ZEP-902

[ZEP-1358] BMI160 accelerometer gives 0 on all axes
https://jira.zephyrproject.org/browse/ZEP-1358

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


CLOSED JIRA items within last 24 hours: 2
[ZEP-1448] (Fixed) Samples/net/mbedtls_sslclient:Build fail as net/ip_buf.h can not be found
https://jira.zephyrproject.org/browse/ZEP-1448

[ZEP-1515] (Duplicate) samples/net/zperf build fail
https://jira.zephyrproject.org/browse/ZEP-1515


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9665 : drivers: rtt: Lock interrupts around RTT Write
- https://gerrit.zephyrproject.org/r/9674 : drivers: gpio: Set the line to the pull by default
- https://gerrit.zephyrproject.org/r/9673 : sensor/bmc150: Fix layout.
- https://gerrit.zephyrproject.org/r/9672 : sensor/bmc150: Drop unncessary external definition.
- https://gerrit.zephyrproject.org/r/9671 : sensor/nrf5_temp: Drop unncessary attribute set callback.
- https://gerrit.zephyrproject.org/r/9670 : doc: grove lcd: move to rst syntax
- https://gerrit.zephyrproject.org/r/9669 : doc: philosophers: move to rst syntax
- https://gerrit.zephyrproject.org/r/9668 : doc: synchronization: move to rst syntax
- https://gerrit.zephyrproject.org/r/9667 : doc: hello world: move to rst and expand docuemntation
- https://gerrit.zephyrproject.org/r/9660 : WIP: Bluetooth: Controller: Conditional compile roles
- https://gerrit.zephyrproject.org/r/9664 : sensor: Fix samples that assume incorrect sensor_value type.
- https://gerrit.zephyrproject.org/r/9663 : Bluetooth: AVDTP: Add AVDTP Receive Function
- https://gerrit.zephyrproject.org/r/9651 : net: tcp: Be more consistent with namespaces for private funcs
- https://gerrit.zephyrproject.org/r/9656 : net: tcp: Use appdatalen when acknowledging packets
- https://gerrit.zephyrproject.org/r/9655 : net: tcp: Store return value of net_buf_frags_len() on a size_t
- https://gerrit.zephyrproject.org/r/9654 : net: tcp: Remove unused `retransmit_timer` field from `net_tcp`
- https://gerrit.zephyrproject.org/r/9653 : net: slip: Do not remove fragments when sending data
- https://gerrit.zephyrproject.org/r/9652 : net: buf: tailroom and headroom functions should take const pointer
- https://gerrit.zephyrproject.org/r/9650 : net: tcp: Precompute appdata properly
- https://gerrit.zephyrproject.org/r/9649 : net: tcp: Swap tcp->context backpointers
- https://gerrit.zephyrproject.org/r/9648 : net: tcp: Select correct source address for SYNACK packets
- https://gerrit.zephyrproject.org/r/9641 : doc: use conf.py from main project
- https://gerrit.zephyrproject.org/r/9658 : samples: net: Remove unnecessary eth_ksdk project settings
- https://gerrit.zephyrproject.org/r/9659 : AON [Test Only]: test AON counter and timer
- https://gerrit.zephyrproject.org/r/9657 : drivers: aio: remove aio disabling before invoking callback
- https://gerrit.zephyrproject.org/r/9640 : doc: remove duplicate and outdated configuration file

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9608 : doc: move documetnation context to root directory
- https://gerrit.zephyrproject.org/r/6719 : Bluetooth: A2DP: Stream End Point Structure
- https://gerrit.zephyrproject.org/r/9331 : Bluetooth: A2DP: Adds accept state callback handlers
- https://gerrit.zephyrproject.org/r/6717 : Bluetooth: A2DP: A2DP sink service record registration
- 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/9573 : WIP: Bluetooth: Controller: conditional compile advertiser only
- https://gerrit.zephyrproject.org/r/5604 : drivers: spi: Add SPI_SLAVE flag to allow platform drivers to switch to slave mode
- https://gerrit.zephyrproject.org/r/9516 : drivers: Add Atmel SAM family GMAC Ethernet driver
- 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 pointer to Pending Request
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/7103 : defconfig: 96b_carbon: Enable the SPI driver by default
- https://gerrit.zephyrproject.org/r/7102 : defconfig: nucleo_f401re: Enable the SPI driver by default
- https://gerrit.zephyrproject.org/r/9549 : net/protocols: Remove unnecessary assignement in Makefiles
- https://gerrit.zephyrproject.org/r/7100 : pinmux: 96b_carbon: Setup SPI pins on the board
- https://gerrit.zephyrproject.org/r/7099 : pinmux: nucleo_f401re: Setup SPI pins on the board
- https://gerrit.zephyrproject.org/r/7098 : pinmux: stm32f4: Setup SPI pins
- https://gerrit.zephyrproject.org/r/7101 : drivers: spi: Add STM32f4 SPI driver
- https://gerrit.zephyrproject.org/r/9558 : net/mqtt: Allow an MQTT subscriber app to receive msgs
- https://gerrit.zephyrproject.org/r/9557 : net/mqtt: Allow an MQTT publisher app to receive msgs
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/9554 : net/mqtt: Add the reception callback
- https://gerrit.zephyrproject.org/r/9556 : net/mqtt: Add the mqtt_rx_publish routine
- https://gerrit.zephyrproject.org/r/9553 : net/mqtt: Use the right data type
- https://gerrit.zephyrproject.org/r/9637 : Bluetooth: AT: HFP HF: Handle unsolicited reponse
- https://gerrit.zephyrproject.org/r/9564 : net/dns: Introduce the qname_copy routine
- https://gerrit.zephyrproject.org/r/9550 : net/nbuf: Introduce the net_nbuf_linear_copy routine
- https://gerrit.zephyrproject.org/r/9598 : ethernet: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9520 : commit-message: Fix logging info
- https://gerrit.zephyrproject.org/r/9229 : gpio: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/9597 : ksdk: mcux: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9599 : i2c: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9601 : flash: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9604 : MAINTAINERS: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9600 : random: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9602 : pinmux: Rename ksdk to mcux
- https://gerrit.zephyrproject.org/r/9603 : ksdk: mcux: Remove config HAS_KSDK
- https://gerrit.zephyrproject.org/r/9461 : tests: kernel: added memory pool api test
- https://gerrit.zephyrproject.org/r/9591 : Makefile (arc/soc/em*): New compiler options
- https://gerrit.zephyrproject.org/r/9546 : Switch logrotate to build-discarder
- https://gerrit.zephyrproject.org/r/9592 : Makefile (arc/soc/quark_se): New compiler options
- https://gerrit.zephyrproject.org/r/9596 : pinmux: Remove stale ksdk pinmux dev references
- https://gerrit.zephyrproject.org/r/9616 : arm: Cortex-M0: Adapt core register code to M0

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9666 : Bluetooth: Fix potential race condition in bt_pub_key_gen()
- https://gerrit.zephyrproject.org/r/9662 : bluetooth: hci_uart: Allocate 65 bytes for L2CAP packets
- https://gerrit.zephyrproject.org/r/9661 : Bluetooth: RFCOMM: Implement timer in session
- https://gerrit.zephyrproject.org/r/9645 : net: samples: Fix stale yaip references
- https://gerrit.zephyrproject.org/r/9642 : maintainers: update KNOWN ISSUES and MAINTAINERS section
- https://gerrit.zephyrproject.org/r/9643 : Bluetooth: hci_ecc: Verify LE Generate DHKey command parameters
- https://gerrit.zephyrproject.org/r/9606 : doc: add JIRA macro
- https://gerrit.zephyrproject.org/r/9639 : doc: support official website theme
- https://gerrit.zephyrproject.org/r/9328 : Bluetooth: AVDTP:Add Accept Incoming connection cb
- https://gerrit.zephyrproject.org/r/7640 : samples: ieee802154: Let's proceed with an active scan
- https://gerrit.zephyrproject.org/r/7639 : net: ieee802154: Handle disassocation notification from PAN coordinator
- 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/7632 : net: ieee802154: Add grounds for passive scan
- https://gerrit.zephyrproject.org/r/9634 : net: event: Notify on interface being put down or up
- 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/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/9633 : net: event: Fix misplaced comment
- https://gerrit.zephyrproject.org/r/9586 : sanitycheck: reduce number of unnecessary configuration builds
- https://gerrit.zephyrproject.org/r/9609 : sanity: prevent stack corruption at test_static_idt
- https://gerrit.zephyrproject.org/r/9590 : Makefile.toolchain.zephyr: Modifications for SDK 0.9
- https://gerrit.zephyrproject.org/r/9594 : arc: add -fno-delete-null-pointer-checks
- https://gerrit.zephyrproject.org/r/9571 : stm32f4: Update flash to support higher sysclock frequencies
- https://gerrit.zephyrproject.org/r/9575 : boards: nucleo: provide button and led for basic samples
- https://gerrit.zephyrproject.org/r/9607 : doc: samples: fix rst layout and use code-blocks
- https://gerrit.zephyrproject.org/r/9053 : cc3200: Use peripheral driver library functions from ROM
- https://gerrit.zephyrproject.org/r/9540 : arm: Fix assembler layout.
- https://gerrit.zephyrproject.org/r/9541 : arm: cortex-m memory map is CPU specific
- https://gerrit.zephyrproject.org/r/9543 : arm: Replace CONFIG_CPU_CORTEX_M0_M0PLUS with CONFIG_ARMV6_M
- https://gerrit.zephyrproject.org/r/9544 : arm: Replace CONFIG_CPU_CORTEX_M3_M4 with CONFIG_ARMV7_M
- https://gerrit.zephyrproject.org/r/9545 : arm: Adjust cortex-m7 support to reflect its ARMv7-M architecture.
- https://gerrit.zephyrproject.org/r/9542 : arm: Restructure ARM cpu related preprocessor conditionals.


Re: Networking stack - Ethernet driver design

Tomasz Bursztyka
 

Hi Piotr,

Where can I find the list of known current limitations of the
networking stack? Is it documented?
No. We have a TODO which is more like a 1:1 with Jira tickets, but
that's all.


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.
Shall I create a Jira issue so this is not forgotten?
Definitely, yes, go ahead.


Tomasz


Re: Networking stack - Ethernet driver design

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

Hi Thomas and Chuck,

Thanks for the feedback. Regarding comments from Thomas:


You are mixing different issues here: your own driver design and known
current limitations in net stack.
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
Just to make sure I'm not misunderstood I was not implying that
initializing Ethernet driver before networking stack is a bad idea, only
that it does not play well with the current design. If the architecture
is being worked on, some things will be changed there is no issue.

Where can I find the list of known current limitations of the networking
stack? Is it documented?

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.
Shall I create a Jira issue so this is not forgotten?

Regards,
Piotr


Re: radio active callback

Carles Cufi
 

Hi Marcio,

From: Marcio Montenegro [mailto:mtuxpe(a)gmail.com]
Sent: Thursday, January 05, 2017 11:50
To: devel(a)lists.zephyrproject.org
Subject: [devel] radio active callback

Hi all,
In my appplication I need to stop advertising, change data and restart again.
I suppose that is not possible to stop advertising when radio is active.

Then I found this empty function on hci_driver.c

void radio_active_callback(uint8_t active)
{
}

Is there any method to check if radio is active? Or I need to use my own code on
radio_active_callback function


[carles] The radio_active_callback() in hci_driver.c is implemented but not exposed to applications. We are yet to define an API to allow applications to be aware of radio activity, as this would be a part of a future radio.h API that we haven’t started work on.

In the meantime feel free to use radio_active_callback() but bear in mind that you’ll be executing inside an ISR and that the API might break in the future.

Regards,

Carles


radio active callback

Marcio Montenegro
 

Hi all,
In my appplication I need to stop advertising, change data and restart
again.
I suppose that is not possible to stop advertising when radio is active.

Then I found this empty function on hci_driver.c

void radio_active_callback(uint8_t active)
{
}

Is there any method to check if radio is active? Or I need to use my own
code on
radio_active_callback function

Best regards,
Marcio Montenegro


Re: Sensor result representation.

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi Bodan,

On 5 January 2017 at 09:13, Bogdan Davidoaia <bogdan.davidoaia(a)gmail.com> wrote:
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,
I was just checking that the plan had not changed.

Thanks for the update.

Cheers
/Marcus


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

5881 - 5900 of 8033