Date   

Re: echo-server ipv6 doesn't work

Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

I haven't been able to test ipv6 on the automation framework yet, but if past experience is to be heeded, I would not be surprised if lurking issues were there.
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org [zephyr-devel-bounces@lists.zephyrproject.org] on behalf of Goldman, Michael [michael.goldman@intel.com]
Sent: Monday, March 27, 2017 1:05 PM
To: Jukka Rissanen; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] echo-server ipv6 doesn't work

Hi all,

Sorry for not stating that I was testing it on Atmel SAMV71 board, using the configuration file attached.
Also tried running in qemu (https://www.zephyrproject.org/doc/subsystems/networking/qemu_setup.html) and also there only IPV4 works - maybe it would help: I do not see any IPv6 packets on the sniffer "tap0" interface, only IPV4 traffic.

Thanks,
Michael

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen@linux.intel.com]
Sent: Monday, March 27, 2017 20:04
To: Goldman, Michael <michael.goldman@intel.com>; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] echo-server ipv6 doesn't work

Hi Michael,

IPv6 should work just fine, I am using it daily.

What exactly is your setup, are you using qemu or real hw?
Can you show the config file?


Cheers,
Jukka


On Mon, 2017-03-27 at 14:40 +0000, Goldman, Michael wrote:
Hi all,

Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn’t work for me (ping fails) and IPv4 works only if IPv6 is
disabled.

Thanks,
Michael

---------------------------------------------------------------------
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.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
---------------------------------------------------------------------
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: echo-server ipv6 doesn't work

Goldman, Michael <michael.goldman@...>
 

Hi all,

Sorry for not stating that I was testing it on Atmel SAMV71 board, using the configuration file attached.
Also tried running in qemu (https://www.zephyrproject.org/doc/subsystems/networking/qemu_setup.html) and also there only IPV4 works - maybe it would help: I do not see any IPv6 packets on the sniffer "tap0" interface, only IPV4 traffic.

Thanks,
Michael

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen@linux.intel.com]
Sent: Monday, March 27, 2017 20:04
To: Goldman, Michael <michael.goldman@intel.com>; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] echo-server ipv6 doesn't work

Hi Michael,

IPv6 should work just fine, I am using it daily.

What exactly is your setup, are you using qemu or real hw?
Can you show the config file?


Cheers,
Jukka


On Mon, 2017-03-27 at 14:40 +0000, Goldman, Michael wrote:
Hi all,
 
Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn’t work for me (ping fails) and IPv4 works only if IPv6 is
disabled.
 
Thanks,
Michael
 
---------------------------------------------------------------------
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.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
---------------------------------------------------------------------
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.


External SRAM

Justin
 

Has anyone implemented external SRAM with a board? I looked through all the board defconfig files. I saw nothing indicating setup of a parallel bus (PMP, Flexbus, SMC, etc) to an external RAM chip. I also didn't see a driver for external RAM chips.

To add external RAM should I add code in the board directory to setup the parallel bus and initialize the RAM? How do I let Zephyr know that I have more RAM at a specific address?


Re: echo-server ipv6 doesn't work

Jukka Rissanen
 

Hi Michael,

IPv6 should work just fine, I am using it daily.

What exactly is your setup, are you using qemu or real hw?
Can you show the config file?


Cheers,
Jukka

On Mon, 2017-03-27 at 14:40 +0000, Goldman, Michael wrote:
Hi all,
 
Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn’t work for me (ping fails) and IPv4 works only if IPv6 is
disabled.
 
Thanks,
Michael
 
---------------------------------------------------------------------
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.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: echo-server ipv6 doesn't work

Luiz Augusto von Dentz
 

Hi Michael,

On Mon, Mar 27, 2017 at 6:07 PM, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:
Hello,

On Mon, 27 Mar 2017 14:40:13 +0000
"Goldman, Michael" <michael.goldman@intel.com> wrote:

Hi all,

Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn't work for me (ping fails) and IPv4 works only if IPv6 is
disabled.
What BOARD? I believe I tested it on Sat with qemu_x86 and saw IPv6
pings (but didn't try actual data echoing).
It also works for me with Bluetooth, the only problem Im having is
when using global addresses it seems there is something dropping the
packets before it reaches the echo-client process, but that can be
something in the Linux side.

--
Luiz Augusto von Dentz


Re: echo-server ipv6 doesn't work

Paul Sokolovsky
 

Hello,

On Mon, 27 Mar 2017 14:40:13 +0000
"Goldman, Michael" <michael.goldman@intel.com> wrote:

Hi all,

Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn't work for me (ping fails) and IPv4 works only if IPv6 is
disabled.
What BOARD? I believe I tested it on Sat with qemu_x86 and saw IPv6
pings (but didn't try actual data echoing).


Thanks,
Michael
[]

--
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


echo-server ipv6 doesn't work

Goldman, Michael <michael.goldman@...>
 

Hi all,

 

Does anyone try to test IPv6 on latest echo-server app?

IPv6 doesn’t work for me (ping fails) and IPv4 works only if IPv6 is disabled.

 

Thanks,

Michael

 

---------------------------------------------------------------------
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: RFC: BSD Socket (like) API

Paul Sokolovsky
 

Hello Jukka,

On Mon, 27 Mar 2017 12:37:40 +0300
Jukka Rissanen <jukka.rissanen@linux.intel.com> wrote:

[]
The current approach is that we value lightweight nature of Zephyr,
and
looking towards finding a minimal set of changes (additions) to
provide
BSD Sockets *like* API to Zephyr.
The definition of what is BSD Socket *like* system seems to differ
from person to person.
That's true, and the reason why I informally proposed the "process-wise"
definition above: "minimal set of changes (additions) to provide
BSD Sockets *like* API to Zephyr."

For me the current net_context API in Zephyr
is quite BSD socket like, meaning that the API provides similar
functions that are found in BSD socket API like open, close, bind,
connect, accept etc. So it is quite easy to port the application in
this respect.
That's also true, and I right from the start got a habit to call
net_context "a socket". The API calls you mention are all indeed work
(likely almost) the same. The big difference comes with recv() call -
whereas BSD Sockets API has it conventionally pull-style, in Zephyr
it's push-style, where data gets delivered to an app via a callback.
That's one single feature which makes porting 3rd-party applications
complicated and cumbersome.


The bigger difference between BSD socket API and Zephyr net_context
API is:
* net_context API uses net_buf to pass data. The net_buf does not
provide linear memory but data needs to be partitioned when sending
and read in chunks when receiving. We have helpers defined in nbuf.h
for handling reading/writing data in this case. The issue with linear
memory case is that it uses much more memory as we need to be prepared
to receive at least 1280 byte size chunks of data (IPv6 min data
packet size).
Right. And that part is covered by BSD Sockets' own API - the data is
passed via app-owned buffers, not system-owned buffers. That means that
by definition, BSD Sockets don't support zero-copy operation. While an
obvious drawback, it has its positive sides to, like it offers
possibility for better system vs app separation for security.

* The net_context is asynchronous and caller needs to have callbacks
defined. The BSD socket API is synchronous. The net_context can be
used in synchronous way so this is a smaller issue imho.
As you may already noticed, I prefer to call this distinction
"push-style vs pull-style", because it pinpoints the problem better. The
net_context used "in synchronous way" doesn't provide BSD Sockets
behavior for receives. For that to work, incoming (but unprocessed) data
needs to be queue *per socket*, until an app requests it. And indeed,
that's the one big initial change I would need to make.

Having a BSD socket API on top of net_context will use more memory so
if one is concerned about memory consumption, then using native API
should be preferred.
+100, BSD Sockets like API is not a replacement for native API, only a
helper to port existing applications (mostly libraries in the
real-world cases, I may imagine, but only practice will tell how
people will use it).

[]

--
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


Re: RFC: BSD Socket (like) API

Tomasz Bursztyka
 

Hi Paul,

3- Allow for multiple socket providers
(https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h),
that way it should be easy to “offload” the IP stack for cases
(e.g. WINC1500) where the IP stack is not on-chip, or where
somebody wants to use an existing commercial/industrial IP stack.
Offloading is already handled through net_context, so it will
seamlessly work already.
One of Gil's point was that CC3200 native interface is exactly BSD
Sockets. So, now he needs to convert that API to push-style native
Zephyr API. Then for this work, I will convert Z native push style to
pull style again. That would mean double "impedance conversion" for a
case like CC3200, and an idea to look if it's possible to avoid it. But
leave that topic to Gil, I'm not an offloading specialist.
The problem with direct offloading - i.e. without net_context etc... - is that it won't integrate
at all properly with systems having multiple network interfaces: ones offering offload, and ones not.
That's why current offload still tightens the "offload device" to a network interface, the core
network stack can handle among other. That will be necessary there will be routing done from
one net-if to another, etc...

The problem of non-linearity of buffer can be solved another way, so I don't see this as a problem here.

In the end, also, it will be way much less work for your layer: it just has to work on top of net_context and
should not care at all about the logic of the network device below.

Br,

Tomasz


Re: RFC: BSD Socket (like) API

Paul Sokolovsky
 

On Mon, 27 Mar 2017 13:19:16 +0200
Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com> wrote:

[]

That's the thing: there won't be any other wrappers.
There is Zephyr's net stack with net_context, and there will be BSD
socket layer Paul is working on, and that's it.
Nope, then (later, one sweet (or sour) day) there will be a more
general POSIX layer on top of it (and other APIs, threading,
filsystem, console, etc.), and then there will be LIBC on top of it. I'm
not a stakeholder for adding all those layers, but I know that there
are such (and likely will be more as Zephyr gets more adoption), so we
should plan for that.

I think that's positive after all - we don't need to plan how to get
all-the-POSIX compliant sockets right away, at least for now.
Instead, can plan for how to get the most juicy BSD Sockets features
while adding the least code (aka bloat). Then at later time, other folks
can provide their arguments for getting more POSIX compliance (at the
expense of adding more code of course).


Tomasz
--
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


Re: RFC: BSD Socket (like) API

Paul Sokolovsky
 

Hello Tomasz,

On Mon, 27 Mar 2017 09:29:31 +0200
Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com> wrote:

Hi Hughes,


https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket


I’d like to point to Mynewt’s socket APIs as a reference here, a
couple of things we considered:

1- Don’t keep POSIX names unless you are going to be POSIX
compliant. When running the system simulated, it’s often helpful to
use system sockets to communicate and do things, if you use POSIX
names you have conflicts.
1a- This also allows you to have a “true” POSIX mapping layer
on top, for people who have more memory and truly want socket-level
compatibility.

2- FDs just waste memory, add locking and make things harder to
debug, use socket structures.
I don't know Mynewt, but if I want BSD socket API in Zephyr, I would
like to see no prefix in front of types and functions.
Sure, it's not going to be 100% Posix compliant, and it's not the
point here yes.

But I really want to use socket, bind, listen, as I mostly would in
any other OS.
Please note that these names belong to LIBC namespace, not Zephyr
namespace. So, in our case it's up to Newlib to define them in any it
wants (which is hopefully what we want). I think that good initial
target would be to have a compatibility headers, as I mentioned in
reply to Sterling:

#define socket net_sock_socket
#define listen net_sock_listen
...

(net_sock_ prefix is made and doesn't constitute any specific proposal
- so far).

For the FD, I hope we can make any struct pointer to look alike.
Maybe there are limitations however, not sure.
Right. There may be some limitation, but we should be good to start
with just casting structure pointers to integers and use that as
"socket identifiers". E.g. POSIX (via its publicly available SUSv2
rendition) says:
http://pubs.opengroup.org/onlinepubs/7908799/xns/socket.html "Otherwise
a value of -1 is returned and errno is set to indicate the error.". We
can easily provide that and thus be POSIX compliant.

However, we know that some real-world software likes to test for
negative return value instead:

int fd = socket(...);
if (fd < 0) ...

And indeed, the link above also says "Upon successful completion,
socket() returns a nonnegative integer, the socket file descriptor."
Well, that would be an example of limitation you talk about. But it's
my intuitive impression that majority (well, many) MCUs try to map
RAM/ROM into lower half/quarter of addresspace, so we should be good
here too, subject to actual checking over a long range of various
architectures.


Anyway, I don't want to burden this initial discussion with narrow
issues like above, the point is that there're indeed may be some
limitations to consider, I have some inventory of them in my mind
already, ready to research more, and then will bring up at appropriate
time.




3- Allow for multiple socket providers
(https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h),
that way it should be easy to “offload” the IP stack for cases
(e.g. WINC1500) where the IP stack is not on-chip, or where
somebody wants to use an existing commercial/industrial IP stack.
Offloading is already handled through net_context, so it will
seamlessly work already.
One of Gil's point was that CC3200 native interface is exactly BSD
Sockets. So, now he needs to convert that API to push-style native
Zephyr API. Then for this work, I will convert Z native push style to
pull style again. That would mean double "impedance conversion" for a
case like CC3200, and an idea to look if it's possible to avoid it. But
leave that topic to Gil, I'm not an offloading specialist.



Br,

Tomasz


--
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


Re: RFC: BSD Socket (like) API

Daniel Thompson <daniel.thompson@...>
 

On 27/03/17 12:19, Tomasz Bursztyka wrote:
2- FDs just waste memory, add locking and make things harder to debug,
use socket structures.
I don't know Mynewt, but if I want BSD socket API in Zephyr, I would
like to see no prefix in front of types and functions.
Sure, it's not going to be 100% Posix compliant, and it's not the point
here yes.

But I really want to use socket, bind, listen, as I mostly would in any
other OS.
A commonly used pattern for BSD-like interfaces is to have a prefixed
API (e.g. net_socket, net_bind) and, introduce a separate mechanism,
to alias the name (either linker magic or just #define socket
net_socket in a separate header).

The reason for this is to do with the multiple definitions of
BSD-like. Making the aliasing *optional* allows an application to
provide alternative wrappers if it needs it...
That's the thing: there won't be any other wrappers.
There is Zephyr's net stack with net_context, and there will be BSD
socket layer Paul is working on, and that's it.
I was regarding as the mechanism to rename symbols
(net_sock_bind -> bind) to be a form of wrapper around BSD-like sockets, albeit a trivial one.

However providing that renaming is optional it does not preclude the application from providing more advanced wrappers if it needs to. For sure, if the BSD-like sockets follow the advice/prior-art in MyNewt and avoid using FDs, allowing the application to opt-out of that decision probably matters.


Daniel.


Re: RFC: BSD Socket (like) API

Tomasz Bursztyka
 

Hi Daniel,


https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket


I’d like to point to Mynewt’s socket APIs as a reference here, a
couple of things we considered:

1- Don’t keep POSIX names unless you are going to be POSIX compliant.
When running the system simulated, it’s often helpful to use system
sockets to communicate and do things, if you use POSIX names you have
conflicts.
1a- This also allows you to have a “true” POSIX mapping layer on
top, for people who have more memory and truly want socket-level
compatibility.

2- FDs just waste memory, add locking and make things harder to debug,
use socket structures.
I don't know Mynewt, but if I want BSD socket API in Zephyr, I would
like to see no prefix in front of types and functions.
Sure, it's not going to be 100% Posix compliant, and it's not the point
here yes.

But I really want to use socket, bind, listen, as I mostly would in any
other OS.
A commonly used pattern for BSD-like interfaces is to have a prefixed API (e.g. net_socket, net_bind) and, introduce a separate mechanism, to alias the name (either linker magic or just #define socket net_socket in a separate header).

The reason for this is to do with the multiple definitions of BSD-like. Making the aliasing *optional* allows an application to provide alternative wrappers if it needs it...
That's the thing: there won't be any other wrappers.
There is Zephyr's net stack with net_context, and there will be BSD socket layer Paul is working on, and that's it.

Tomasz


Re: RFC: BSD Socket (like) API

Paul Sokolovsky
 

Hello Sterling,

Thanks for the prompt feedback!

On Sun, 26 Mar 2017 09:37:07 -0700
"Sterling Hughes" <sterling@runtime.io> wrote:

+1

https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket

I’d like to point to Mynewt’s socket APIs as a reference here, a
couple of things we considered:
Thanks for MyNewt references on the matter, I'll finally have a good
excuse to look into again (the time for which I couldn't find for a
while) ;-).


1- Don’t keep POSIX names unless you are going to be POSIX
compliant. When running the system simulated, it’s often helpful to
use system sockets to communicate and do things, if you use POSIX
names you have conflicts.
Sure, the "BSD Sockets like API" functions would be still
prefixed/namespaced (I actually wanted to bring up a separate
discussion on namespacing of Zephyr APIs). Then if/when it reaches
enough parity that there could be a talk of porting existing apps with
minimal changes, there would be just a header with stuff like:

#define bind net_sock_bind

1a- This also allows you to have a “true” POSIX mapping layer
on top, for people who have more memory and truly want socket-level
compatibility.

2- FDs just waste memory, add locking and make things harder to
debug, use socket structures.
Agree. That was one of the 1st question I got at the minisummit, and my
answer was: "well, we could waste some memory by adding the FD table to
map small integers to underlying structures, but why?". Indeed, by just
casting pointers to integers, we can go a long, long way of using this
API and porting existing apps.

Generally, the work of adding well-known APIs is just a precursor (or
a subset) of implementing much bigger chunk of POSIX functionality and
making Zephyr much more POSIX compliant. So, I leave FDs introduction,
etc. to these later stages of work.

3- Allow for multiple socket providers
(https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h),
that way it should be easy to “offload” the IP stack for cases (e.g.
WINC1500) where the IP stack is not on-chip, or where somebody wants
to use an existing commercial/industrial IP stack.
Right. Our initial prototyping team here at Linaro consists of Gil
Pitney and me. Gil works on integrating TI CC3200 into Zephyr, and it
has networking offloading at many different levels, and the point is
exactly to consider whether it makes sense to consider offloading on BSD
Sockets API layer, in addition to various layers he already works on.
So, good point, and thanks for the pointer, we'll have a look how
MyNewt does that.

4- If you are interested in unifying this API with Mynewt, we’d be
happy to talk about agreeing on a unified API for sub-embedded
sockets.
I'll definitely have a look and see what commonality can be achieved,
hope Gil will provide feedback too.


Best,

Sterling

On 26 Mar 2017, at 9:06, Paul Sokolovsky wrote:

Hello,

Support for BSD Sockets API in Zephyr is one of the frequently asked
features from different parties. Possibility of such support was a
topic
of discussions at the recent OpenIoT Summit Portland and Zephyr
Mini-summit Budapest. I'm happy to report that I didn't hear a
single "cons" vote, most people I heard or talked with were
positive that they
either interested in it themselves, or it least OK with it if it's
properly layered and doesn't bloat existing networking API.

So, based on that, Linaro Zephyr team would like to proceed with
bootstrapping work on this, collecting initial requirements, and
starting prototyping. I submitted a Jira Epic
https://jira.zephyrproject.org/browse/ZEP-1921 for this feature,
which has a detailed, even if maybe somewhat unstructured
discussion of initial ideas/requirements.

I won't paste it here, instead inviting interested parties to read
it there. Instead, here's a summary of the initial ideas:

1. There's no talk about implementing complete 100% (or 99.9%) POSIX
compliant sockets API. We may get there eventually, but that would
require stakeholders for each expensive or hard to implement
feature. The current approach is that we value lightweight nature
of Zephyr, and
looking towards finding a minimal set of changes (additions) to
provide
BSD Sockets *like* API to Zephyr.

2. The specific featureset of the initial interest is as follows.
The current Z networking API is push-based, where the OS pushes
data into an application (via a callback). Whereas BSD Sockets API
is pull-based,
where an application asks OS for new data to process, when an
application feels like. Implementing this pull-style API is the
initial focus of the effort.

3. The work is going to be guided by porting efforts of an actual
application which needs BSD Sockets API (MicroPython). That would
serve
as an initial (out-of-tree) prototype, with relevant code to be
optimized and merged in-tree for wider reuse.


Consequently, questions to the Zephyr community:

1. Are you interested in BSD Sockets like API?
2. Does the plan above sound good? Any important points to take
care of right from the beginning?
3. Or would you do something differently?
4. Any other feedback is appreciated.



Thanks,
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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


--
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


Re: RFC: BSD Socket (like) API

Daniel Thompson <daniel.thompson@...>
 

On 27/03/17 08:29, Tomasz Bursztyka wrote:
Hi Hughes,


https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket


I’d like to point to Mynewt’s socket APIs as a reference here, a
couple of things we considered:

1- Don’t keep POSIX names unless you are going to be POSIX compliant.
When running the system simulated, it’s often helpful to use system
sockets to communicate and do things, if you use POSIX names you have
conflicts.
1a- This also allows you to have a “true” POSIX mapping layer on
top, for people who have more memory and truly want socket-level
compatibility.

2- FDs just waste memory, add locking and make things harder to debug,
use socket structures.
I don't know Mynewt, but if I want BSD socket API in Zephyr, I would
like to see no prefix in front of types and functions.
Sure, it's not going to be 100% Posix compliant, and it's not the point
here yes.

But I really want to use socket, bind, listen, as I mostly would in any
other OS.
A commonly used pattern for BSD-like interfaces is to have a prefixed API (e.g. net_socket, net_bind) and, introduce a separate mechanism, to alias the name (either linker magic or just #define socket net_socket in a separate header).

The reason for this is to do with the multiple definitions of BSD-like. Making the aliasing *optional* allows an application to provide alternative wrappers if it needs it...


For the FD, I hope we can make any struct pointer to look alike.
Maybe there are limitations however, not sure.
... for example if an application has a big chunk of legacy code scattered liberally with int it might prefer to pay the costs for the fd table (without imposing it on the rest of us).


Daniel



3- Allow for multiple socket providers
(https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h),
that way it should be easy to “offload” the IP stack for cases (e.g.
WINC1500) where the IP stack is not on-chip, or where somebody wants
to use an existing commercial/industrial IP stack.
Offloading is already handled through net_context, so it will seamlessly
work already.

Br,

Tomasz
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: RFC: BSD Socket (like) API

Jukka Rissanen
 

Hi Paul,

On Sun, 2017-03-26 at 19:06 +0300, Paul Sokolovsky wrote:
Hello,

Support for BSD Sockets API in Zephyr is one of the frequently asked
features from different parties. Possibility of such support was a
topic
of discussions at the recent OpenIoT Summit Portland and Zephyr
Mini-summit Budapest. I'm happy to report that I didn't hear a single
"cons" vote, most people I heard or talked with were positive that
they
either interested in it themselves, or it least OK with it if it's
properly layered and doesn't bloat existing networking API.

So, based on that, Linaro Zephyr team would like to proceed with
bootstrapping work on this, collecting initial requirements, and
starting prototyping. I submitted a Jira Epic
https://jira.zephyrproject.org/browse/ZEP-1921 for this feature,
which
has a detailed, even if maybe somewhat unstructured discussion of
initial ideas/requirements.

I won't paste it here, instead inviting interested parties to read it
there. Instead, here's a summary of the initial ideas:

1. There's no talk about implementing complete 100% (or 99.9%) POSIX
compliant sockets API. We may get there eventually, but that would
require stakeholders for each expensive or hard to implement feature.
The current approach is that we value lightweight nature of Zephyr,
and
looking towards finding a minimal set of changes (additions) to
provide
BSD Sockets *like* API to Zephyr.
The definition of what is BSD Socket *like* system seems to differ from
person to person. For me the current net_context API in Zephyr is quite
BSD socket like, meaning that the API provides similar functions that
are found in BSD socket API like open, close, bind, connect, accept
etc. So it is quite easy to port the application in this respect.

The bigger difference between BSD socket API and Zephyr net_context API
is:
* net_context API uses net_buf to pass data. The net_buf does not
provide linear memory but data needs to be partitioned when sending and
read in chunks when receiving. We have helpers defined in nbuf.h for
handling reading/writing data in this case. The issue with linear
memory case is that it uses much more memory as we need to be prepared
to receive at least 1280 byte size chunks of data (IPv6 min data packet
size).

* The net_context is asynchronous and caller needs to have callbacks
defined. The BSD socket API is synchronous. The net_context can be used
in synchronous way so this is a smaller issue imho.

Having a BSD socket API on top of net_context will use more memory so
if one is concerned about memory consumption, then using native API
should be preferred.


2. The specific featureset of the initial interest is as follows. The
current Z networking API is push-based, where the OS pushes data into
an application (via a callback). Whereas BSD Sockets API is pull-
based,
where an application asks OS for new data to process, when an
application feels like. Implementing this pull-style API is the
initial focus of the effort.

3. The work is going to be guided by porting efforts of an actual
application which needs BSD Sockets API (MicroPython). That would
serve
as an initial (out-of-tree) prototype, with relevant code to be
optimized and merged in-tree for wider reuse.


Consequently, questions to the Zephyr community:

1. Are you interested in BSD Sockets like API?
2. Does the plan above sound good? Any important points to take
care of right from the beginning?
3. Or would you do something differently?
4. Any other feedback is appreciated.



Thanks,
Paul

Cheers,
Jukka


Re: RFC: BSD Socket (like) API

Tomasz Bursztyka
 

Hi Hughes,


https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket

I’d like to point to Mynewt’s socket APIs as a reference here, a couple of things we considered:

1- Don’t keep POSIX names unless you are going to be POSIX compliant. When running the system simulated, it’s often helpful to use system sockets to communicate and do things, if you use POSIX names you have conflicts.
1a- This also allows you to have a “true” POSIX mapping layer on top, for people who have more memory and truly want socket-level compatibility.

2- FDs just waste memory, add locking and make things harder to debug, use socket structures.
I don't know Mynewt, but if I want BSD socket API in Zephyr, I would like to see no prefix in front of types and functions.
Sure, it's not going to be 100% Posix compliant, and it's not the point here yes.

But I really want to use socket, bind, listen, as I mostly would in any other OS.

For the FD, I hope we can make any struct pointer to look alike.
Maybe there are limitations however, not sure.


3- Allow for multiple socket providers (https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h), that way it should be easy to “offload” the IP stack for cases (e.g. WINC1500) where the IP stack is not on-chip, or where somebody wants to use an existing commercial/industrial IP stack.
Offloading is already handled through net_context, so it will seamlessly work already.

Br,

Tomasz


Re: RFC: BSD Socket (like) API

Sterling Hughes <sterling@...>
 

+1

https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket

I’d like to point to Mynewt’s socket APIs as a reference here, a couple of things we considered:

1- Don’t keep POSIX names unless you are going to be POSIX compliant. When running the system simulated, it’s often helpful to use system sockets to communicate and do things, if you use POSIX names you have conflicts.
1a- This also allows you to have a “true” POSIX mapping layer on top, for people who have more memory and truly want socket-level compatibility.

2- FDs just waste memory, add locking and make things harder to debug, use socket structures.

3- Allow for multiple socket providers (https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h), that way it should be easy to “offload” the IP stack for cases (e.g. WINC1500) where the IP stack is not on-chip, or where somebody wants to use an existing commercial/industrial IP stack.

4- If you are interested in unifying this API with Mynewt, we’d be happy to talk about agreeing on a unified API for sub-embedded sockets.

Best,

Sterling

On 26 Mar 2017, at 9:06, Paul Sokolovsky wrote:

Hello,

Support for BSD Sockets API in Zephyr is one of the frequently asked
features from different parties. Possibility of such support was a topic
of discussions at the recent OpenIoT Summit Portland and Zephyr
Mini-summit Budapest. I'm happy to report that I didn't hear a single
"cons" vote, most people I heard or talked with were positive that they
either interested in it themselves, or it least OK with it if it's
properly layered and doesn't bloat existing networking API.

So, based on that, Linaro Zephyr team would like to proceed with
bootstrapping work on this, collecting initial requirements, and
starting prototyping. I submitted a Jira Epic
https://jira.zephyrproject.org/browse/ZEP-1921 for this feature, which
has a detailed, even if maybe somewhat unstructured discussion of
initial ideas/requirements.

I won't paste it here, instead inviting interested parties to read it
there. Instead, here's a summary of the initial ideas:

1. There's no talk about implementing complete 100% (or 99.9%) POSIX
compliant sockets API. We may get there eventually, but that would
require stakeholders for each expensive or hard to implement feature.
The current approach is that we value lightweight nature of Zephyr, and
looking towards finding a minimal set of changes (additions) to provide
BSD Sockets *like* API to Zephyr.

2. The specific featureset of the initial interest is as follows. The
current Z networking API is push-based, where the OS pushes data into
an application (via a callback). Whereas BSD Sockets API is pull-based,
where an application asks OS for new data to process, when an
application feels like. Implementing this pull-style API is the
initial focus of the effort.

3. The work is going to be guided by porting efforts of an actual
application which needs BSD Sockets API (MicroPython). That would serve
as an initial (out-of-tree) prototype, with relevant code to be
optimized and merged in-tree for wider reuse.


Consequently, questions to the Zephyr community:

1. Are you interested in BSD Sockets like API?
2. Does the plan above sound good? Any important points to take
care of right from the beginning?
3. Or would you do something differently?
4. Any other feedback is appreciated.



Thanks,
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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


RFC: BSD Socket (like) API

Paul Sokolovsky
 

Hello,

Support for BSD Sockets API in Zephyr is one of the frequently asked
features from different parties. Possibility of such support was a topic
of discussions at the recent OpenIoT Summit Portland and Zephyr
Mini-summit Budapest. I'm happy to report that I didn't hear a single
"cons" vote, most people I heard or talked with were positive that they
either interested in it themselves, or it least OK with it if it's
properly layered and doesn't bloat existing networking API.

So, based on that, Linaro Zephyr team would like to proceed with
bootstrapping work on this, collecting initial requirements, and
starting prototyping. I submitted a Jira Epic
https://jira.zephyrproject.org/browse/ZEP-1921 for this feature, which
has a detailed, even if maybe somewhat unstructured discussion of
initial ideas/requirements.

I won't paste it here, instead inviting interested parties to read it
there. Instead, here's a summary of the initial ideas:

1. There's no talk about implementing complete 100% (or 99.9%) POSIX
compliant sockets API. We may get there eventually, but that would
require stakeholders for each expensive or hard to implement feature.
The current approach is that we value lightweight nature of Zephyr, and
looking towards finding a minimal set of changes (additions) to provide
BSD Sockets *like* API to Zephyr.

2. The specific featureset of the initial interest is as follows. The
current Z networking API is push-based, where the OS pushes data into
an application (via a callback). Whereas BSD Sockets API is pull-based,
where an application asks OS for new data to process, when an
application feels like. Implementing this pull-style API is the
initial focus of the effort.

3. The work is going to be guided by porting efforts of an actual
application which needs BSD Sockets API (MicroPython). That would serve
as an initial (out-of-tree) prototype, with relevant code to be
optimized and merged in-tree for wider reuse.


Consequently, questions to the Zephyr community:

1. Are you interested in BSD Sockets like API?
2. Does the plan above sound good? Any important points to take
care of right from the beginning?
3. Or would you do something differently?
4. Any other feedback is appreciated.



Thanks,
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


Re: NXP FRDM-K64F and OpenOCD from 0.9.0 SDK issue

Piotr Król <piotr.krol@...>
 

On 03/22/2017 03:42 PM, Piotr Król wrote:


On 03/21/2017 09:24 PM, Maureen Helm wrote:
Hi Piotr,
Hi Maureen,
Hi all,


I will describe this better in next email and probably contact OpenOCD
community meanwhile.
I did more research and found 2 configuration that work for me. First use CMSIS-DAP 0226, but generate previously mentioned errors and is little bit slow. Second use Segger JLink v2 firmware from:

http://www.nxp.com/products/software-and-tools/run-time-software/kinetis-software-and-tools/ides-for-kinetis-mcus/opensda-serial-and-debug-adapter:OPENSDA?tid=vanOpenSDA#FRDM-K64F

It requires Segger binaries provided with KDS, but is very fast and reliable.

One other mistake I made was not use `load` instruction before starting debugging session that's why breakpoints didn't work.

I describe my experience on blog for people having this kind of problems in future:

https://blog.3mdeb.com/2017/03/18/development-environment-for-zephyros-on-nxp-frdm-k64f/

Best Regards,
--
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com

5381 - 5400 of 8046