Date   

Request to have generic sensor support

kasim shibi <kasim6199@...>
 

|
| Hi All,
I  happened to work on a sensor driver in zephyr 1.4. The "sensor.h" provides support for very few sensors.Moreover lack of  support for any custom/generic data to pass between the application and driver.Please correct me if i am wrong.
I am looking for an option to pass an array (1024 bytes), where the internal data format i can define/manage between my driver and application.
If at all , only choice is to add as a new sensor. Please share the steps for the zephyr team to add support for a new sensor.
ThanksKasim

|


Re: zepyr application to write on to UDP socket

Jukka Rissanen
 

Hi Giribabu,

On Thu, 2016-09-01 at 17:15 +0530, Giribabu Gogineni wrote:
Hi Dev group,

In my application i want write UDP socket and send to linux host
using QEMU.

Is it possible to write an application to write payload on to UDP
socket?
That UDP socket is possible to send using QEMU to linux host?

Could you please help me, if sample application are available, please
provide the path.
You can look how the echo-client and echo-server sample app do things.

Those apps can be found at
samples/net/echo_client
samples/net/echo_server

For instructions how to setup the SLIP from Qemu see the
samples/net/README file. Various tools for SLIP can be found in net-
tools project.

git clone https://gerrit.zephyrproject.org/r/p/net-tools.git

and check the README.legacy file in that directory.


Cheers,
Jukka


zepyr application to write on to UDP socket

Giribabu Gogineni <giribabu02061983@...>
 

Hi Dev group,

In my application i want write UDP socket and send to linux host using QEMU.

Is it possible to write an application to write payload on to UDP socket?
That UDP socket is possible to send using QEMU to linux host?

Could you please help me, if sample application are available, please
provide the path.

Thanks & Regards,
Giribabu


Regarding linking pre-built object files.

Singh, Nitin G <nitin.g.singh@...>
 

Hi,

I am trying to write an application on Zephyr, in which I need to include some pre-built object files.
What is the best way to include the pre-built object files on Zephyr.

Thanks and Regards,
Nitin


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

Piotr Mienkowski <Piotr.Mienkowski@...>
 

Hi Tomasz,

Thanks for the tip. Indeed it looks like it's my company filtering out the packets. If I run traceroute to gerrit.zephyrproject.org port 80 it works fine. If it's to port 29418 traceroute stops within company network.

I should have though about this earlier. Thanks for help!

Cheers,
Piotr


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

Tomasz Bursztyka
 

Hi Piotr,

the port is completely not responding. I believe the problem is on LF
side not mine, but it would be great to know if anyone else is having
similar issue?
Seems to work fine here on my side. Are you sure your company is not
filtering out non known service ports when connecting to them? (i.e. it
accepts 22, 443, 80 etc... but not something exotic as 29418)

Can you try outside your company's network? (on you private computer).

Tomasz


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

Piotr Mienkowski <Piotr.Mienkowski@...>
 

I followed all the instructions on "Gerrit accounts" Wiki page, specifically I uploaded my public ssh key to Gerrit server and added it to my local key ring. Unfortunately the following command

git clone ssh://<LFID>@gerrit.zephyrproject.org:29418/zephyr zephyr-project

times out. <LFID> is my Gerrit Username. I confirmed that the full URL is the same as the one mentioned at the top of the Zephyr project summary page at https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=summary. The exact message is:

Cloning into 'zephyr-project'...
ssh: connect to host gerrit.zephyrproject.org port 29418: Connection timed out
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

I am able to connect via ssh to other servers outside my company network, also cloning other git repositories via ssh works, as well as cloning with
git clone https://gerrit.zephyrproject.org/r/zephyr

Typically when connecting via ssh to a new host ssh would ask if we want to add the host to the known hosts list. This did not happen here indicating connection problems. Indeed if I run nmap
$ nmap -A gerrit.zephyrproject.org -p29418

Starting Nmap 6.47 ( http://nmap.org ) at 2016-09-01 09:59 CEST
Nmap scan report for gerrit.zephyrproject.org (199.19.213.246)
Host is up (0.11s latency).
rDNS record for 199.19.213.246: compute-199-19-213-246.ca-ymq-1.vexxhost.net
PORT STATE SERVICE VERSION
29418/tcp filtered unknown

the port is completely not responding. I believe the problem is on LF side not mine, but it would be great to know if anyone else is having similar issue?


Re: having trouble getting the echo client to work using TCP/uIP on K64F

Jukka Rissanen
 

Hi Rohit and Paul,

On Thu, 2016-09-01 at 03:52 +0300, Paul Sokolovsky wrote:
Hello Rohit,

On Fri, 26 Aug 2016 14:36:07 +0000
Rohit Grover <Rohit.Grover(a)arm.com> wrote:


Paul,

With tcpip_poll_tcp() reverted to its original version:

void
tcpip_poll_tcp(struct uip_conn *conn, struct net_buf *data_buf)
{
  /* We are sending here the initial SYN */
  struct net_buf *buf = ip_buf_get_tx(conn->appstate.state);
  uip_set_conn(buf) = conn;
  conn->buf = ip_buf_ref(buf);

  process_post_synch(&tcpip_process, TCP_POLL, conn, buf);
}

I can now connect and send a packet using the following code run
either as a fiber or a task:
[]


This is already an improvement over the state where I could not
send
using a microkernel. Sending out a second packet before processing
the receipt of the first hasn't worked yet, but I'll leave that
investigation for next week.
Thanks for the above patch, Rohit. So far, that's the most definitive
patch to resolve many different issues. With it and only it I get
pretty working client-side BSD socket API like communication. In
particular, it appears to supersede need for
https://gerrit.zephyrproject.org/r/#/c/4226 - with just a patch
above, I couldn't reproduce overwriting 4 initial data bytes with MSS
option. 

Still, that commit was made in
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=commitdiff;h
=61edc68c9ecf221d18acc8037d541f5d79eee3c7 ,
with description 
"net: tcp: Supporting TCP client functionality when using IPv6". I
don't know if something in IPv6 warrants changes to tcpip_poll_tcp()
done in that commit, I guess only Jukka can tell. But the issue in
Unfortunately I do not remember why I changed tcpip_poll_tcp(), the uIP
code (and especially TCP support) is very cryptic and difficult to
follow. One basically needs to run the stack and see how it behaves.


https://gerrit.zephyrproject.org/r/#/c/4226 could be explained by it
pretty well too: comment says "We are sending here the initial SYN",
and allocates a packet to host that SYN (and then other options, like
MSS), but tcpip_poll_tcp() from 61edc68c9 instead of this SYN packet
records actual data packet in some structures where a SYN packet is
expected, so the data packet gets patched with MSS, etc.


Note that I don't get 100% perfect networking with the patch above,
so there may be more issues to tackle (or alternatively, I don't
handle all conditions well in my code). But figuring out if the
tcpip_poll_tcp() should be reverted or not is the most productive
next
step IMHO.




Regards,
Rohit.
Thanks for your hard efforts with the TCP, it is very much appreciated.


Cheers,
Jukka


Re: [RFC] Power Management Infrastructure

Kaplan, Amir
 

Hi all,

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


I did Abandon to 4081 and Pushed a new one that includes your comments:
1. backwards compatible with the old API (will be signed as deprecated later on)
2. all other comments
3. first push only the API change (3 files) still all samples work with the old APi
4. Then I will do 1-2 additional Pushes for the device drivers and sample app.

Regards!

-----Original Message-----
From: Kaplan, Amir
Sent: Sunday, August 21, 2016 19:27
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,

I did Abandon to the split changes and Restored the previous all in one patch.
Also I correct some things according to your comments.

The Restored link is:

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

Thanks,
Amir Kaplan



-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 13:36
To: devel(a)lists.zephyrproject.org
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,

The corresponding Gerrit link:
https://gerrit.zephyrproject.org/r/4081



-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 11:18
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kaplan, Amir <amir.kaplan(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,
After reviewing all the comments and consulting Ramesh, below is the updated RFC:

Current state
===========

In the current Zephyr implementation the driver power hooks distinguish only between two driver states (suspend and resume). Drivers may have more than two states (i.e. D-states) and can traverse between those states. The state change today is limited only from active to suspend while there can be cases of other transitions requested by the application.
Please look at the below suggested device power states E.g. transition between DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an application or a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {
int (*suspend)(struct device *device, int pm_policy);
int (*resume)(struct device *device, int pm_policy); };

Proposed changes
===============

1. Have one function that can be used for all possible device PM purposes using a control code instead of the suspend resume functions:

int (*device_pm_control)(struct device *device, int pm_command, int device_power_state);

In first version will support DEVICE_SET_POWER_STATE and DEVICE_GET_POWER_STATE commands.

2. Add the below device power states:
Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE
--------------------------------------------
Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE
-------------------------------------------------------
Device context is preserved by the HW and need not be restored by the driver.
The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE
------------------------------------------------
Most device context is lost by the hardware.
Device drivers must save and restore or reinitialize any context lost by the hardware.
The device can be powered down.
The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE
---------------------------------------
Power has been fully removed from the device. The device context is lost when this state is entered, so the OS software will reinitialize the device when powering it back on.
Device may not wake itself as the SoC need to reinitialize the device.

3. The set state functionality (via device_pm_control ) will behave according to the state transition of a specific driver. E.g. transition from active state to suspend state in a UART device will save device states and gate the clock.
The set state functionality (via device_pm_control ) will enable the Power Manager service to know the state of a driver if needed thus enable it to configure the SoC power behavior.

The advantages in the new method:
1. Active device PM that does not need system to go idle to do device PM. Any component can call it. Multiple PM states and transitions need not always between active and low power states.
2. Reduces memory use and complexity because now there is only one function.
3. Compatible with legacy suspend/resume done from central PMA during idle 4. Scalable- In future more control codes can be added to support other device pm operations without having to change infrastructure.

Regards,
Amir, Keren, Hezi

-----Original Message-----
From: Rahamim, Hezi
Sent: Wednesday, August 10, 2016 10:18
To: Kaplan, Amir <amir.kaplan(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>
Subject: FW: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



-----Original Message-----
From: Thomas, Ramesh
Sent: Friday, July 15, 2016 06:22
To: Rahamim, Hezi <hezi.rahamim(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



On 07/14/2016 06:17 AM, Rahamim, Hezi wrote:
Hi Ramesh'

Please see my comments below.

Regards,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Thursday, July 14, 2016 10:32
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: [RFC] Power Management
Infrastructure

On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the device policies.
That made me think why we originally came up with 2 functions when one was enough. Probably we thought the same way - to keep symmetry. Problem is that we will keep getting more needs and we will either add more functions to device_pm_ops or will have to change existing ones.

How about having one function that can be used for all possible device
PM purposes using a control code? Something like following :-

int device_pm_control(device, flags);

flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)

CONTROL_CODE = {SET_POWER_STATE, GET_POWER_STATE, ...}
DEVICE_POWER_STATE = {device PM states} SYSTEM_POWER_STATE = {system
power policies}

(We can add additional parameters if flags param is overloaded)

returns value based on CONTROL_CODE
e.g. returns device power state if CONTROL_CODE == GET_POWER_STATE

(We probably don't need device_pm_ops if we have only one function.)

[HR] Looks good. If the PM service will be designed as a driver than it can use the SYSTEM_POWER_STATE and a device driver will use the DEVICE_POWER_STATE.


***I also have some questions inline below***



Thanks for the comment,
Hezi

-----Original Message-----
From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
Sent: Thursday, July 14, 2016 00:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: [RFC] Power Management Infrastructure

Hi Hezi,
I think RFC needs to be extended with the description of the idea of controlling power state of each device (if I got you correctly).
Without it the need of
int (*get_state)(struct device *device, int device_pm_policy); looks very unclear.
If all you need is to provide more that two states, then set_state() looks quite enough.

Regards,

Dmitriy Korovkin

On 16-07-13 12:11 PM, Rahamim, Hezi wrote:
Hi Ramesh,

Please see my comments below/

Thanks for the comments,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Wednesday, July 13, 2016 09:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Power Management Infrastructure

On 7/12/2016 2:03 AM, Rahamim, Hezi wrote:
Hi all,

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

between two driver states (suspend and resume). Drivers may have
more than two
Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition is happening.


states (i.e. D-states) and can traverse between those states. The
state change

today is limited only from active to suspend while there can be
cases of other

transitions requested by the application.

Please look at the below suggested device power states E.g.
transition between

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an
application or

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

int (*suspend)(struct device *device, int pm_policy);

int (*resume)(struct device *device, int pm_policy);

};

Proposed changes

===============

First proposed change is to have a set state and get state driver
functions

instead of the suspend resume functions:

struct device_pm_ops {

int (*set_state)(struct device *device, int
device_pm_policy);

int (*get_state)(struct device *device, int
device_pm_policy);

};

The set_state function will behave according to the state
transition of a specific

driver. E.g. transition from active state to suspend state in a
UART device will

save device states and gate the clock.
The proposal, as I understand, is to use the pm hooks to actively
control the power states instead of using them as just notifications
of the SOC's power transitions. Considering this, we had one power
policy called "device_suspend_only". That is open to be broken down
into more device specific power states.

[HR] You are correct, we intend to use the pm driver hooks to
actively control the device Power states. We will use the Zephyer's
current power policies to indicate the system power state. As you
mentioned, when devices will not be in active state the system can still be at "device_suspend_only" state.
Do you see any issues with the apps/drivers keeping the PM service updated of the device's current state in real time? What about race conditions? Complexity of communication framework?
[HR] The need of communication framework and device state database
lock may be needed. For example, inter processor communication may be
needed if in a specific SoC there are shared power resources between
two cores (in AtP3 we may avoid that...)



The get_state function will enable the Power Manager service to
know the state

of each driver thus enable it to configure the SoC power behavior.
The set_state function looks ok. It is the same as the current
suspend but with the name change. The purpose of the name change is
to add a corresponding get_state. The RFC is not giving much
details of the use of the get_state function.

I assume there is a need for the PM service to build a device tree,
with power hierarchy. It would be helpful if you could explain how
this function fits in your larger design of the PM service's power
policy management of the devices.

[HR] I will give an example:
A user application decides to suspend the I2C and the SPI devices.
The application will then call the corresponding set_state functions of these devices.
The set_state functions will perform the store of the relevant
device state and gate the device clock. In the next idle time the _sys_soc_suspend will be called.
This will trigger the power manager service which will decide what
should be done to optimize the power (clock gate a branch or change the system power state.
The decision of the power manager service will be based on the
devices states which can be obtained also by using the get_state functions.

Since the PM service is expected to have communication established
with all components in the system, wouldn't it know what state each
device is set to? Querying each device and building a tree every
time there is an opportunity to suspend, may take some time causing delay in suspend.

[HR] You are correct, using the get_state function will lead to a
less optimal Power manager service and it will need to use a more optimized method.
However, it is a good practice to have this function as the
application may want to query the device state.

Second proposed change is to add the below device power states:

Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE

--------------------------------------------

Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE

-------------------------------------------------------

Device context is preserved by the HW and need not be restored by
the driver.

The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE

------------------------------------------------

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context
lost

by the hardware.

The device can be powered down.

The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE

---------------------------------------

Power has been fully removed from the device. The device context is
lost

when this state is entered, so the OS software will reinitialize
the device

when powering it back on.

Device may not wake itself as the SoC need to reinitialize the device.
The description of the power states here sounds like they are
notifications. It sounds like some other component is setting the
power state and notifies using these values and the drivers do
save/restore or other operations based on the notification. Are the
drivers expected to gate clocks, turn off peripherals etc. in these notifications?

[HR] These device power states serve two purposes:
1. The drivers are expected to perform all the power/clock changes
It can perform according to the selected power state and do not
influence other drivers.
2. The power manager service will use the drivers states to decide
on system power policy to go to (it can also stay in
SYS_PM_DEVICE_SUSPEND_ONLY but to optimize the clock gating scheme)
Would these become part of a specification that all device drivers would need to implement? In this scheme, the PM responsibilities are shared between PM Service, various apps and drivers. So some plan needs to be in place to ensure all of them cooperate as expected.
[HR] You are right, there is a need to define the PM responsibilities of the PM service, drivers and apps. However, this RFC was written to add the ability to support more than two device states, define the available states and to enable transition between them.
We will be happy to contribute also to define the above.
The device PM states look ok to me. They are architecture independent and the drivers can map them to device specific operations.

I think this RFC should be part of other RFCs that define the bigger picture of how it is used. As I see it, the kind of device PM you propose can function independent of system idle. In my opinion, it would be good to define it independent of system power management. The 2 will coordinate, but should not be a requirement. That way, either infrastructure can be used independently by users. Also there would be implementations that would want to do all device PM in the PM service for various reasons.



The initial part of the RFC does mention the application can set the
power state of the device and that is what the proposed set_state
function also suggests.

Do they serve both purposes? May be an example of how the device's
power state is actively changed and who and when does it, with
respect to these notifications, would help.

[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
Will the PM service also put devices to suspend state, or only the apps will do it? Looks like the PM Service will never enter Deep Sleep if any device is on - any exceptions?
[HR] Only apps will do that. The PM service can decide in some cases to go to deep sleep even if specific device is active (e.g. the device is located in the always on power domain). The decision to change power state is SoC specific.

In the above example, the system had to go to idle for the PLL to get turned off. If you had a central scheme to turn off clocks then the PLL could have been turned off when both i2c and spi got turned off. Just an observation.
[HR] There are indeed several ways to solve this and there will be a need to choose the best one for the specific SoC.

Comments/concerns welcome.

Thanks,

Hezi

-------------------------------------------------------------------
-
- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material
for the sole use of the intended recipient(s). Any review or
distribution by others is strictly prohibited. If you are not the
intended recipient, please contact the sender and delete all copies.
--------------------------------------------------------------------
- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material
for the sole use of the intended recipient(s). Any review or
distribution by others is strictly prohibited. If you are not the
intended recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: having trouble getting the echo client to work using TCP/uIP on K64F

Paul Sokolovsky
 

Hello Rohit,

On Fri, 26 Aug 2016 14:36:07 +0000
Rohit Grover <Rohit.Grover(a)arm.com> wrote:

Paul,

With tcpip_poll_tcp() reverted to its original version:

void
tcpip_poll_tcp(struct uip_conn *conn, struct net_buf *data_buf)
{
/* We are sending here the initial SYN */
struct net_buf *buf = ip_buf_get_tx(conn->appstate.state);
uip_set_conn(buf) = conn;
conn->buf = ip_buf_ref(buf);

process_post_synch(&tcpip_process, TCP_POLL, conn, buf);
}

I can now connect and send a packet using the following code run
either as a fiber or a task:
[]

This is already an improvement over the state where I could not send
using a microkernel. Sending out a second packet before processing
the receipt of the first hasn't worked yet, but I'll leave that
investigation for next week.
Thanks for the above patch, Rohit. So far, that's the most definitive
patch to resolve many different issues. With it and only it I get
pretty working client-side BSD socket API like communication. In
particular, it appears to supersede need for
https://gerrit.zephyrproject.org/r/#/c/4226 - with just a patch
above, I couldn't reproduce overwriting 4 initial data bytes with MSS
option.

Still, that commit was made in
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=commitdiff;h=61edc68c9ecf221d18acc8037d541f5d79eee3c7 ,
with description
"net: tcp: Supporting TCP client functionality when using IPv6". I
don't know if something in IPv6 warrants changes to tcpip_poll_tcp()
done in that commit, I guess only Jukka can tell. But the issue in
https://gerrit.zephyrproject.org/r/#/c/4226 could be explained by it
pretty well too: comment says "We are sending here the initial SYN",
and allocates a packet to host that SYN (and then other options, like
MSS), but tcpip_poll_tcp() from 61edc68c9 instead of this SYN packet
records actual data packet in some structures where a SYN packet is
expected, so the data packet gets patched with MSS, etc.


Note that I don't get 100% perfect networking with the patch above,
so there may be more issues to tackle (or alternatively, I don't
handle all conditions well in my code). But figuring out if the
tcpip_poll_tcp() should be reverted or not is the most productive next
step IMHO.



Regards,
Rohit.

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-753] Make I2C_SDA_HOLD and I2C_SDA_SETUP SoC specific
https://jira.zephyrproject.org/browse/ZEP-753


UPDATED JIRA items within last 24 hours: 4
[ZEP-451] Quark SE output by default redirected to IPM
https://jira.zephyrproject.org/browse/ZEP-451

[ZEP-546] UART interrupts not triggered on ARC
https://jira.zephyrproject.org/browse/ZEP-546

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

[ZEP-517] build on windows failed "zephyr/Makefile:869: *** multiple target patterns"
https://jira.zephyrproject.org/browse/ZEP-517


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4450 : tests: Add gcov support
- https://gerrit.zephyrproject.org/r/4426 : quark_se: disable IPM and enable UART0 on the sensor subsystem
- https://gerrit.zephyrproject.org/r/4446 : rfc: ksdk: Add KSDK ENET driver.
- https://gerrit.zephyrproject.org/r/4445 : ksdk: Build ksdk fsl_enet.c and fsl_phy.c
- https://gerrit.zephyrproject.org/r/4441 : drivers/pinmux: delete unused file and Makefile item
- https://gerrit.zephyrproject.org/r/4452 : Bluetooth: A2DP: Initialization of A2DP.
- https://gerrit.zephyrproject.org/r/4451 : net: uip: Fix compile fail with stats enabled, tcp disabled.
- https://gerrit.zephyrproject.org/r/4449 : net: Fix code layout.
- https://gerrit.zephyrproject.org/r/4447 : Bluetooth: AVDTP: Module Initialization
- https://gerrit.zephyrproject.org/r/4448 : net: uip: Fix udp_socket_process receive data callback buffer handling.
- https://gerrit.zephyrproject.org/r/4432 : TCF: especify ARCH when building
- https://gerrit.zephyrproject.org/r/4429 : Makefile: unify linker behavior, all architectures use two-pass linking
- https://gerrit.zephyrproject.org/r/4428 : Makefile: Clean up x86 second stage linker pass
- https://gerrit.zephyrproject.org/r/4427 : Makefile: Don't hide the "prebuilt" kernel
- https://gerrit.zephyrproject.org/r/4430 : Link-time symbol priority-based replacement
- https://gerrit.zephyrproject.org/r/4431 : printk: Use link-time aliasing to share implementation with printf

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4422 : boards: rename Quark SE Devboard to Quark SE C1000
- https://gerrit.zephyrproject.org/r/3922 : ext/lib: Add HTTP support in Zephyr
- https://gerrit.zephyrproject.org/r/4420 : boards: rename Quark SE Devboard to Quark SE C1000 (Sensor Subsystem)
- https://gerrit.zephyrproject.org/r/4413 : Bluetooth: Add service sample for HoG
- https://gerrit.zephyrproject.org/r/4355 : ztest: Add simple integration and unit tests
- https://gerrit.zephyrproject.org/r/4118 : tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4415 : Bluetooth: HoG: Require authentication for connections
- https://gerrit.zephyrproject.org/r/4360 : ksdk: Add KSDK RNGA driver.
- https://gerrit.zephyrproject.org/r/4414 : Bluetooth: Add sample implementing HoG
- https://gerrit.zephyrproject.org/r/4354 : ztest: Add documentation
- https://gerrit.zephyrproject.org/r/4353 : ztest: Add native building support
- https://gerrit.zephyrproject.org/r/4357 : tests: Add a sample for testing natively
- https://gerrit.zephyrproject.org/r/4356 : tests: convert tests/net/buf to the new framework
- https://gerrit.zephyrproject.org/r/4341 : Bluetooth: HFP HF: Initialize Handsfree profile
- https://gerrit.zephyrproject.org/r/4218 : Bluetooth: A2DP: Basic Implementation of A2DP Sink.
- https://gerrit.zephyrproject.org/r/4103 : libc/printf: Use compiler-provided 64 bit math, phase 1
- https://gerrit.zephyrproject.org/r/4423 : MAINTAINERS: add maintainer for some of the boards
- https://gerrit.zephyrproject.org/r/4055 : Bluetooth: SDP: Server implementation
- https://gerrit.zephyrproject.org/r/4197 : Bluetooth: AVDTP: Module intialization
- https://gerrit.zephyrproject.org/r/4290 : net: yaip: Move IPv4 related Kconfig options to its own file
- https://gerrit.zephyrproject.org/r/4289 : net: yaip: Move IPv6 related Kconfig options to its own file
- https://gerrit.zephyrproject.org/r/4292 : net: Split debug Kconfig options from legacy to new stack
- https://gerrit.zephyrproject.org/r/4291 : net: yaip: Normalize Kconfig and fix it
- https://gerrit.zephyrproject.org/r/4167 : samples: net: Qemu make utilities update
- https://gerrit.zephyrproject.org/r/4251 : net: yaip: ieee802154: Normalize Kconfig
- https://gerrit.zephyrproject.org/r/4252 : net: yaip: Centralize generic IEEE 802.15.4 radio utility functions
- https://gerrit.zephyrproject.org/r/4253 : net: yaip: ieee802154: Add CSMA-CA non slotted radio protocol support
- https://gerrit.zephyrproject.org/r/4304 : net: Legacy IP stack Kconfig has nothing to do with new stack
- https://gerrit.zephyrproject.org/r/4168 : net: samples: Add a simple Qemu sample for testing off-line 802.15.4
- https://gerrit.zephyrproject.org/r/4166 : samples: net: Moving the current ieee802154 sample
- https://gerrit.zephyrproject.org/r/4294 : net: drivers: Normalize ieee802154 Kconfig
- https://gerrit.zephyrproject.org/r/4293 : net: drivers: cc2520 ieee802154 drivers select relevant options
- https://gerrit.zephyrproject.org/r/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/4164 : net: ieee802154: Add basic support for IEEE 802.15.4e on FCF
- https://gerrit.zephyrproject.org/r/3400 : known issues: ignore testcases failures
- https://gerrit.zephyrproject.org/r/4371 : win-build: fixes to build with alternative make implementations
- https://gerrit.zephyrproject.org/r/4376 : Bluetooth: GAP: Support multiple peripheral role connections

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4425 : ksdk: Import Kinetis SDK ethernet phy driver
- https://gerrit.zephyrproject.org/r/4439 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4437 : ext: Import nRF51 files from Nordic MDK
- https://gerrit.zephyrproject.org/r/4435 : serial/Kconfig.nrf5: cosmetic fixes
- https://gerrit.zephyrproject.org/r/4436 : gpio/Kconfig.nrf5: cosmetic fixes
- https://gerrit.zephyrproject.org/r/4438 : Bluetooth: GATT: Fix unaligned access to CCC value
- https://gerrit.zephyrproject.org/r/4130 : drivers: spi: Fix typos in SPI port numbers
- https://gerrit.zephyrproject.org/r/4345 : kernel: Rename CONFIG_CUSTOM_RANDOM_GENERATOR to CONFIG_RANDOM_GENERATOR
- https://gerrit.zephyrproject.org/r/4410 : readme: Instructions for the new IP stack
- https://gerrit.zephyrproject.org/r/4409 : readme: Clarified the instructions in readme file
- https://gerrit.zephyrproject.org/r/4408 : radvd: Fix the comment in radvd.conf file
- https://gerrit.zephyrproject.org/r/4407 : scripts: Add license header to loop scripts
- https://gerrit.zephyrproject.org/r/4404 : Bluetooth: Add LE read supported states
- https://gerrit.zephyrproject.org/r/4406 : misc/byteorder.h: Add sys_get_le64 interface
- https://gerrit.zephyrproject.org/r/4193 : nxp_kinetis: Refactor K64F init to use ksdk clock driver
- https://gerrit.zephyrproject.org/r/4399 : printk: warn on incorrect format code usage
- https://gerrit.zephyrproject.org/r/3947 : sanitycheck: support for multiple toolchain
- https://gerrit.zephyrproject.org/r/4403 : build: default ARCH to be initialized by the board support code
- https://gerrit.zephyrproject.org/r/4402 : drivers: i2c_shim: fix i2c fast plus mode failure
- https://gerrit.zephyrproject.org/r/4192 : ksdk: Compile the ksdk clock driver
- https://gerrit.zephyrproject.org/r/4191 : nxp_kinetis: Add Kconfig options to configure clocks
- https://gerrit.zephyrproject.org/r/4397 : Generate nav.yaml for CMS site ingestion
- https://gerrit.zephyrproject.org/r/4256 : toolchain: Remove vestigial COFF assembler symbol mangling support
- https://gerrit.zephyrproject.org/r/4400 : doxygen: ignore function attributes


Re: [RFC] Zephyr 1.6: HTTP support

Rohit Grover
 

This is a very useful middle-ware library. I have been able to use it to parse HTTP headers from a real server.


Re: gerrit sandbox branches

Perez Hernandez, Javier B <javier.b.perez.hernandez@...>
 

Marcus,


On Wed, 2016-08-31 at 12:06 +0100, Marcus Shawcroft wrote:
On 31 August 2016 at 01:09, Perez Hernandez, Javier B
<javier.b.perez.hernandez(a)intel.com> wrote:

Hi!

We no longer have support for new branches in gerrit.
If you want to create your sandbox you can fork the project in
github.
Ok, thanks.  The www documentation
https://www.zephyrproject.org/doc/contribute/gerrit_practices.html is
out of date.  What is the process to update that documentation?
I have reported the issue in JIRA:
https://jira.zephyrproject.org/browse
/ZEP-756

We can wait for our technical writer to fix it, or you can submit a patch for it. All the help is very appreciated.
See the doc directory in the zephyr tree and edit the .rst file with the content.

Any question, let me know.

Javier B. Perez


Cheers
/Marcus


Re: Porting to Cortex-M0+

Piotr Mienkowski <Piotr.Mienkowski@...>
 

Hi Maureen,

Thanks for all the explanations. I've created a Jira issue to add support for Atmel SAM E70 family. If it's approved I can work on it.
https://jira.zephyrproject.org/browse/ZEP-759

by the NXP ksdk and Nordic mdk. As far as folder structure goes, I think anything under
ext/hal/asf (or whatever we end up calling it) has some freedom to do what makes sense.
I am actually more in favor of giving subfolders company names (currently the style is mixed). The main reason being the fact that the various names of SDKs tend to be cryptic so user may have trouble finding what he is looking for. Also companies, once every few years, tend to change these names so acronyms such as ksdk, qmsi, asf may one day get outdated.

For ext/hal/cmsis and ext/hal/ksdk, I tried to preserve the structure from the original
I am too very much for preserving the structure of the original SDK

IANAL either, but will check with someone at LF on this.
You've mentioned in the post below that Zephyr TSC has to ask the governing board to approve the ASF license. What should we do to trigger this?


Re: gerrit sandbox branches

Marcus Shawcroft <marcus.shawcroft@...>
 

On 31 August 2016 at 01:09, Perez Hernandez, Javier B
<javier.b.perez.hernandez(a)intel.com> wrote:
Hi!

We no longer have support for new branches in gerrit.
If you want to create your sandbox you can fork the project in github.

Ok, thanks. The www documentation
https://www.zephyrproject.org/doc/contribute/gerrit_practices.html is
out of date. What is the process to update that documentation?

Cheers
/Marcus


Re: Porting to Cortex-M0+

Euan Mutch <euan.mutch@...>
 

Thanks Vinayak its working now

On Wed, Aug 31, 2016 at 10:46 AM, Vinayak Kariappa <
vinayak.kariappa(a)gmail.com> wrote:

Hi Euan,

This how I build on the branch Ricardo gave me, if its of any help.

make -C samples/bluetooth/peripheral CROSS_COMPILE=arm-none-eabi-
LIB_INCLUDE_DIR="-L /usr/lib/gcc/arm-none-eabi/4.8.2/armv6-m -lgcc"
ZEPHYR_BASE=~/workspace/zephyr/ BOARD=nrf51_blenano

Regards,
Vinayak


On Tue, Aug 30, 2016 at 6:27 PM, Euan Mutch <euan.mutch(a)gmail.com> wrote:

Hi,

I am now having some problems getting the micro kernel to link. It
currently fails with undefined references to __gnu_thumb1_case_uqi and
__ffssi2 which should be in libgcc.a, so I added -lgcc to LDFLAGS but that
didn't help.

Any ideas?

Thanks again,
Euan

On Mon, Aug 29, 2016 at 10:11 PM, Euan Mutch <euan.mutch(a)gmail.com>
wrote:

Hi Maureen/Iván,

I managed to get it working now and my led is flashing :)

Thanks!


Re: Porting to Cortex-M0+

Vinayak Kariappa <vinayak.kariappa@...>
 

Hi Euan,

This how I build on the branch Ricardo gave me, if its of any help.

make -C samples/bluetooth/peripheral CROSS_COMPILE=arm-none-eabi-
LIB_INCLUDE_DIR="-L /usr/lib/gcc/arm-none-eabi/4.8.2/armv6-m -lgcc"
ZEPHYR_BASE=~/workspace/zephyr/ BOARD=nrf51_blenano

Regards,
Vinayak

On Tue, Aug 30, 2016 at 6:27 PM, Euan Mutch <euan.mutch(a)gmail.com> wrote:

Hi,

I am now having some problems getting the micro kernel to link. It
currently fails with undefined references to __gnu_thumb1_case_uqi and
__ffssi2 which should be in libgcc.a, so I added -lgcc to LDFLAGS but that
didn't help.

Any ideas?

Thanks again,
Euan

On Mon, Aug 29, 2016 at 10:11 PM, Euan Mutch <euan.mutch(a)gmail.com> wrote:

Hi Maureen/Iván,

I managed to get it working now and my led is flashing :)

Thanks!


Re: gerrit sandbox branches

Perez Hernandez, Javier B <javier.b.perez.hernandez@...>
 

Hi!

We no longer have support for new branches in gerrit. 
If you want to create your sandbox you can fork the project in github.

Regards

Javier B. Perez

On Tue, 2016-08-30 at 23:30 +0100, Marcus Shawcroft wrote:
Hi,

Can anyone help with some gerrit / git foo? I'd like to create a
personal sandbox branch.

Following the instructions here:

https://www.zephyrproject.org/doc/contribute/gerrit_practices.html

... I execute the commands:

git checkout -b sandbox/MarcusShawcroft/k64f-enet
...
git push --set-upstream upstream
HEAD:refs/heads/sandbox/MarcusShawcroft/k64f-enet


Which results in:
remote: Processing changes: refs: 1, done
To ssh://MarcusShawcroft(a)gerrit.zephyrproject.org:29418/zephyr
 ! [remote rejected] HEAD -> sandbox/MarcusShawcroft/k64f-enet
(prohibited by Gerrit)
error: failed to push some refs to
'ssh://MarcusShawcroft(a)gerrit.zephyrproject.org:29418/zephyr'

Can anyone shed light on what I'm doing wrong, or suggest how I debug
this further?

Thanks
/Marcus


gerrit sandbox branches

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi,

Can anyone help with some gerrit / git foo? I'd like to create a
personal sandbox branch.

Following the instructions here:

https://www.zephyrproject.org/doc/contribute/gerrit_practices.html

... I execute the commands:

git checkout -b sandbox/MarcusShawcroft/k64f-enet
...
git push --set-upstream upstream
HEAD:refs/heads/sandbox/MarcusShawcroft/k64f-enet


Which results in:
remote: Processing changes: refs: 1, done
To ssh://MarcusShawcroft(a)gerrit.zephyrproject.org:29418/zephyr
! [remote rejected] HEAD -> sandbox/MarcusShawcroft/k64f-enet
(prohibited by Gerrit)
error: failed to push some refs to
'ssh://MarcusShawcroft(a)gerrit.zephyrproject.org:29418/zephyr'

Can anyone shed light on what I'm doing wrong, or suggest how I debug
this further?

Thanks
/Marcus

6701 - 6720 of 8046