Date   

Re: How to handle a board with a dozen SoC's?

Nashif, Anas
 

Ok, there is a JIRA about board/soc structure documentation already and it happens to be assigned to me, I will address this ASAP, this might help you with the issue below.

Anas

On 2 Sep 2016, at 11:23, Jon Medhurst (Tixy) <tixy(a)linaro.org> wrote:

On Fri, 2016-09-02 at 15:46 +0100, Jon Medhurst (Tixy) wrote:
I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and varying
support IP, and I'm wondering how to organise this.
I realised this and $subject may be a bit ambiguous, I meant that the
FPGA can be programmed at any one time with a single CPU type chosen
from a range of a dozen or so. I'm not trying to support multiple CPU
and 'SoC' types in a single Zephyr image at the same time. I'm looking
at a separate image for each one.


Re: Proposal to streamline GPIO, Pinmux driver API

Nashif, Anas
 

Hi,

Some time ago the TSC discussed APIs in general and it was agreed that we need to revisit the APIs as we have them right when there is critical mass of architecture and board support and I think we are getting there.

On Pinmux I agree it is low level and SOC specific, You have a very good story here that can be added to Jira.


Anas

On 2 Sep 2016, at 06:21, Piotr Mienkowski <Piotr.Mienkowski(a)schmid-telecom.ch> wrote:

Hello Community,

I would like to discuss GPIO / Pinmux driver combo which I believe become overcomplicated and may be confusing for a regular user.

The current API seems to be designed around Intel Quark architecture and QMSI SDK. In Quark there are separate Pinmux and GPIO modules and so we got separate Pinmux and GPIO drivers. However, in most chipsets GPIO module takes care of both PIO (reading/writing from/to a pin) and pin muxing (connecting pin to a peripheral/PIO controller). By now the functional split between the two drivers become blurred and is overlapping.

Some examples:

At present GPIO driver defines GPIO_PUD_PULL_UP (Enable GPIO pin pull-up) to be used with gpio_pin_configure() function and Pinmux driver has pinmux_pin_pullup() function. Both are meant to do the same thing however gpio_pin_configure() will not work with Intel Quark chips and pinmux_pin_pullup() will mostly not work with other chips e.g. Freescale/NXP FRDM-K64F. Still some chipsets e.g. Atmel SAM3x implement both functions but then even for Atmel SAM3x setting pin pull-down is only possible via gpio_pin_configure() function.

pinmux_pin_input_enable() function is used by Quark chips to disable/enable input pad and gpio_pin_configure() to set pin as input or output. This is not easily rendered from the function's name/description and in fact Atmel SAM3x driver implements pinmux_pin_input_enable() to configure pin as input or output overlapping it with the same functionality provided by gpio_pin_configure().

In case of ARM based chips e.g. Atmel SAM3x, Freescale/NXP FRDM-K64F to configure pin with pull-up and connect it to external peripheral one needs to call pinmux_pin_set() which takes as an argument pin index, e.g. pin PB2, third pin on port B would have index 34 and gpio_pin_configure() which takes as an argument port and port's pin number, e.g. PB2 has number 2. So in two subsequent calls we need to use different pin values even if we operate on the same pin. While this may be convenient for Quark chips it is not for other chip families.

Currently it is not really possible to know which function should be used when and how without analyzing Zephyr's source code.

I believe that split between Pinmux and GPIO driver is not a good general solution and in case we preserve the current API it will soon become even more convoluted.

I would like to propose to phase out Pinmux driver and implement pin multiplexing in GPIO driver. That would require adding something like GPIO_FUNC_A, ..., GPIO_FUNC_D to GPIO API.

Other possibility would be to limit Pinmux driver only to architectures that really need it, like Quark chips. Having pin multiplexing available simultaneously in GPIO and Pinmux driver will be confusing for Quark users, however that's already the case with pull-up configuration.

I haven't created a Jira issue, neither RFC in Gerrit yet. At first I would like to get a quick feedback if you find my arguments sensible.

Thanks,
Piotr


Re: How to handle a board with a dozen SoC's?

Jon Medhurst (Tixy) <tixy@...>
 

On Fri, 2016-09-02 at 15:46 +0100, Jon Medhurst (Tixy) wrote:
I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and varying
support IP, and I'm wondering how to organise this.
I realised this and $subject may be a bit ambiguous, I meant that the
FPGA can be programmed at any one time with a single CPU type chosen
from a range of a dozen or so. I'm not trying to support multiple CPU
and 'SoC' types in a single Zephyr image at the same time. I'm looking
at a separate image for each one.

--
Tixy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4472 : i2c: ksdk: Add shim driver
- https://gerrit.zephyrproject.org/r/4473 : i2c: Fix restart flag in burst read
- https://gerrit.zephyrproject.org/r/4491 : net: revert tcpip_poll_tcp() to not require a data_buf
- https://gerrit.zephyrproject.org/r/4490 : Bluetooth: UUID: Add 32bit UUID support
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- https://gerrit.zephyrproject.org/r/4489 : Bluetooth: SDP: Server: Support ServiceAttrReq and ServiceSearchAttrReq
- https://gerrit.zephyrproject.org/r/4488 : Bluetooth: SDP: Server: Support ServiceSearchRequest
- https://gerrit.zephyrproject.org/r/4486 : Bluetooth: SDP: Server: Initialize and accept incoming connections
- https://gerrit.zephyrproject.org/r/4479 : Bluetooth: Controller: Measure and use correct stack size
- https://gerrit.zephyrproject.org/r/4485 : sample: fs: Add tests for fs_truncate and fs_statvfs
- https://gerrit.zephyrproject.org/r/4484 : drivers/pinmux: delete deprecated PINMUX_DEV_QUARK_MCU
- https://gerrit.zephyrproject.org/r/4483 : drivers/pinmux: fix CONFIG_PINMUX_DEV_NAME dependency issue
- https://gerrit.zephyrproject.org/r/4480 : fs: Add file system API to flush cache of an open file
- https://gerrit.zephyrproject.org/r/4478 : fs: Adds file system API to get volume statistics
- https://gerrit.zephyrproject.org/r/4477 : uart_qmsi: Get the interrupt handling right on ARC
- https://gerrit.zephyrproject.org/r/4474 : uart_console: Fix line endings
- https://gerrit.zephyrproject.org/r/4476 : samples/uart: More boards
- https://gerrit.zephyrproject.org/r/4475 : samples/drivers/uart: Fix line endings
- https://gerrit.zephyrproject.org/r/4471 : sanitycheck: allow extra arguments to be passed to the build

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4456 : net/ip: Fix warnings when enabling IP debugging
- https://gerrit.zephyrproject.org/r/4282 : net: fetch valid conn. to determine MSS in data_is_sent_and_acked()
- https://gerrit.zephyrproject.org/r/3934 : SDP Server
- https://gerrit.zephyrproject.org/r/4055 : Bluetooth: SDP: Server implementation
- https://gerrit.zephyrproject.org/r/3848 : lib: Introduce the CoAP implementation for Zephyr
- https://gerrit.zephyrproject.org/r/4372 : fs: Adds file system API to grow or shrink a file
- https://gerrit.zephyrproject.org/r/4139 : TCF: adds test fixed by ZEP-704
- https://gerrit.zephyrproject.org/r/4371 : win-build: fixes to build with alternative make implementations
- https://gerrit.zephyrproject.org/r/3313 : samples/drivers/crypto: crypto sample app
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: Tinycrypt shim driver
- https://gerrit.zephyrproject.org/r/4461 : i2c: qmsi_shim: change some i2c config parameters to SoC specific
- https://gerrit.zephyrproject.org/r/4360 : ksdk: Add KSDK RNGA driver.
- https://gerrit.zephyrproject.org/r/4445 : ksdk: Build ksdk fsl_enet.c and fsl_phy.c
- https://gerrit.zephyrproject.org/r/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/3924 : lib/http: Add test-case
- https://gerrit.zephyrproject.org/r/4457 : DONT MERGE
- https://gerrit.zephyrproject.org/r/4460 : kconfig: include configuration fragment files from output directory

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4470 : Only build nav.yaml if docs successfully built
- https://gerrit.zephyrproject.org/r/4415 : Bluetooth: HoG: Require authentication for connections
- https://gerrit.zephyrproject.org/r/4414 : Bluetooth: Add sample implementing HIDS
- https://gerrit.zephyrproject.org/r/4413 : Bluetooth: Add service sample for HoG
- https://gerrit.zephyrproject.org/r/4469 : Bluetooth: btp: Extend BTP specification to cover L2CAP tests


How to handle a board with a dozen SoC's?

Jon Medhurst (Tixy) <tixy@...>
 

Hi

I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and varying
support IP, and I'm wondering how to organise this.

[1] https://www.arm.com/products/tools/development-boards/versatile-express/cortex-m-prototyping-system.php

It seems to me that 'BOARD' is what the build system expects to use to
specify the thing to build, but adding a dozen new boards under /boards
(one for each 'SoC') doesn't seem the right way to go - and I would then
need somewhere to put the common code for the physical board.

I'm going to be in a similar situation for creating my dozen or so SoC's
but I believe that the build system may be a bit more flexible in that
situation, with SOC_FAMILY and SOC_SERIES.

As well as the hardware board there is a host of software simulations
[2] for similar but differing configurations as the hardware. I don't
believe that adds any extra complexity though, apart from the number of
ever expanding versions and them not being definitively identified by
name or number. Oh joy...

[2] https://developer.arm.com/docs/dui0837/latest/programming-reference-for-mps2-fvps/mps2-about

Thanks for any advice.

--
Tixy


Re: Porting to Cortex-M0+

Piotr Mienkowski <Piotr.Mienkowski@...>
 

Hi Maureen,

Another member of the TSC will follow up with Atmel.
Thanks, I will wait for the green light. My Atmel SAM E70 port works well in my local workarea, I have everything necessary for initial support apart from UART driver. There are still a few minor implementation details I'll have to discuss but I'll do it later in a separate thread when I know I am supposed to work on it.

I have one more question to the design flow I could not find a clear answer in the wiki to. As I have mentioned I would like to add support for Atmel SAM E70 chipset, I've already opened a Jira issue. I expect that now before doing the actual job and especially before trying to push anything to Gerrit I need to wait until the task is officially accepted and assigned to me, isn't it?

Cheers,
Piotr


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

Rohit Grover
 

Paul, Jukka,

> On Thu, 1 Sep 2016 14:47:41 +0000
> Rohit Grover <Rohit.Grover(a)arm.com> wrote:
>
> > Jukka, Paul,
> >
> > I believe we should go ahead and fix tcpip_poll_tcp() according to the
> > patch I submitted previously. This fix can supersede
> > https://gerrit.zephyrproject.org/r/#/c/4226, and we can pause on that
> > particular pull request for now.
>
> +1. Would you submit it to Gerrit?
>

Submitted https://gerrit.zephyrproject.org/r/#/c/4491/

Regards,
Rohit.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: Request to have generic sensor support

Davidoaia, Bogdan M <bogdan.m.davidoaia@...>
 

Hello Kasim,

The sensor types from sensor.h are in no way final, and new types can be
added as the need arises for new drivers.

Not sure if your driver could define a more specific type (that may be
useful for other future drivers) rather then a generic one, but a
generic data type can be easily added.

For sending generic data to the driver, you can add a
SENSOR_ATTR_USER_DATA attribute, a SENSOR_VALUE_TYPE_USER_DATA value
type and a void *user_data field in the union from struct sensor_value.

Sending generic data back to the application can be done by adding a
SENSOR_CHAN_USER_DATA channel (together with the generic sensor value
type and filed).

Best regards,
Bogdan

On Jo, 2016-09-01 at 14:19 +0000, kasim shibi wrote:


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.


Thanks
Kasim




Proposal to streamline GPIO, Pinmux driver API

Piotr Mienkowski <Piotr.Mienkowski@...>
 

Hello Community,

I would like to discuss GPIO / Pinmux driver combo which I believe become overcomplicated and may be confusing for a regular user.

The current API seems to be designed around Intel Quark architecture and QMSI SDK. In Quark there are separate Pinmux and GPIO modules and so we got separate Pinmux and GPIO drivers. However, in most chipsets GPIO module takes care of both PIO (reading/writing from/to a pin) and pin muxing (connecting pin to a peripheral/PIO controller). By now the functional split between the two drivers become blurred and is overlapping.

Some examples:

At present GPIO driver defines GPIO_PUD_PULL_UP (Enable GPIO pin pull-up) to be used with gpio_pin_configure() function and Pinmux driver has pinmux_pin_pullup() function. Both are meant to do the same thing however gpio_pin_configure() will not work with Intel Quark chips and pinmux_pin_pullup() will mostly not work with other chips e.g. Freescale/NXP FRDM-K64F. Still some chipsets e.g. Atmel SAM3x implement both functions but then even for Atmel SAM3x setting pin pull-down is only possible via gpio_pin_configure() function.

pinmux_pin_input_enable() function is used by Quark chips to disable/enable input pad and gpio_pin_configure() to set pin as input or output. This is not easily rendered from the function's name/description and in fact Atmel SAM3x driver implements pinmux_pin_input_enable() to configure pin as input or output overlapping it with the same functionality provided by gpio_pin_configure().

In case of ARM based chips e.g. Atmel SAM3x, Freescale/NXP FRDM-K64F to configure pin with pull-up and connect it to external peripheral one needs to call pinmux_pin_set() which takes as an argument pin index, e.g. pin PB2, third pin on port B would have index 34 and gpio_pin_configure() which takes as an argument port and port's pin number, e.g. PB2 has number 2. So in two subsequent calls we need to use different pin values even if we operate on the same pin. While this may be convenient for Quark chips it is not for other chip families.

Currently it is not really possible to know which function should be used when and how without analyzing Zephyr's source code.

I believe that split between Pinmux and GPIO driver is not a good general solution and in case we preserve the current API it will soon become even more convoluted.

I would like to propose to phase out Pinmux driver and implement pin multiplexing in GPIO driver. That would require adding something like GPIO_FUNC_A, ..., GPIO_FUNC_D to GPIO API.

Other possibility would be to limit Pinmux driver only to architectures that really need it, like Quark chips. Having pin multiplexing available simultaneously in GPIO and Pinmux driver will be confusing for Quark users, however that's already the case with pull-up configuration.

I haven't created a Jira issue, neither RFC in Gerrit yet. At first I would like to get a quick feedback if you find my arguments sensible.

Thanks,
Piotr


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

Paul Sokolovsky
 

On Thu, 1 Sep 2016 14:47:41 +0000
Rohit Grover <Rohit.Grover(a)arm.com> wrote:

Jukka, Paul,

I believe we should go ahead and fix tcpip_poll_tcp() according to
the patch I submitted previously. This fix can supersede
https://gerrit.zephyrproject.org/r/#/c/4226, and we can pause on that
particular pull request for now.
+1. Would you submit it to Gerrit?

We should also avoid regressing on
any IPv6 functionality, so if there are tests we could use to
evaluate IPv6 then we should employ them to validate changes to
tcpip_poll_tcp().
I believe running echo_server/echo_client should be a good first step,
I'll look into that.


Fixing tcpip_poll_tcp() isn't the complete answer. With changes to
tcpip_poll_tcp(), I can get simple request-response transactions, but
sustained/multiple transactions don't work; so there is still reason
to suspect that TCP support is unreliable.
As I mentioned, multiple (well, up to 5-6) packets work for me with
QEMU. I'll try it with FRDM-K64F Ethernet driver soon.

The bigger problem appears to be that the uIP port for Z has grown
unmaintainable. I can sympathize with Jukka when he says that TCP
support on uIP "is very cryptic and difficult to follow." It is not
clear to me if uIP is tricky to port in general, or that Z poses a
special challenge. Does Zephyr intend to switch from uIP to YAIP? If
so, then perhaps one strategy would be to wait for YAIP to catch up.
If Zephyr wishes to maintain support for TCP/uIP, then someone needs
to take a fresh look at the current uIP port, possibly from the point
of view of a porter of uIP.
My understanding is that yes, YAIP is intended to replace IP stack
implementation in Z, though maybe exact timeline isn't known yet. My
current task is to prepare a proof-of-concept demo of a scripting
language running on top of Zephyr, so I'd be interested to follow route
of trying to fix up the current uIP implementation, though probably not
go too deep with that.


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


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

Paul Sokolovsky
 

Hello,

On Thu, 01 Sep 2016 11:11:15 +0300
Jukka Rissanen <jukka.rissanen(a)linux.intel.com> wrote:

[]

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.
I see. It seems that one of the biggest changes done was to convert
single static packet buffer design on uIP to support multiple buffers.
Ironically, that's what another Contiki-originated IP stack (or at
least IP stack from the same author, Adam Dunkels) - lwIP - does. It
supports multiple in-flight packet buffers, clearer API, better
performance. I wonder if using it might have been better choice for
Zephyr. All the above comes at the expense of doubling (or more) of
code size, so maybe not still.

Anyway, with Z's own new IP stack in progress, that's more of
speculation, I guess focus should be on stabilizing current uIP based
implementation, until the new stack reaches needed functionality level.


--
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: Porting to Cortex-M0+

Maureen Helm
 

Hi Piotr,

-----Original Message-----
From: Piotr Mienkowski [mailto:Piotr.Mienkowski(a)schmid-telecom.ch]
Sent: Wednesday, August 31, 2016 8:09 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: Re: Porting to Cortex-M0+

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?
I brought this to the TSC yesterday, and the decision was to first ask Atmel if they can change to a standard license already approved by the Zephyr governing board. Another member of the TSC will follow up with Atmel.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 4
[ZEP-760] Clean up samples and sanitise them.
https://jira.zephyrproject.org/browse/ZEP-760

[ZEP-759] Add preliminary support for Atmel SAM E70 (Cortex-M7) chipset family and SAM E70 Xplained board
https://jira.zephyrproject.org/browse/ZEP-759

[ZEP-756] Remove Sandboxes from documentation
https://jira.zephyrproject.org/browse/ZEP-756

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


UPDATED JIRA items within last 24 hours: 5
[ZEP-750] Arduino 101 board should support one configuration using original bootloader
https://jira.zephyrproject.org/browse/ZEP-750

[ZEP-244] Multiple Published Versions Support
https://jira.zephyrproject.org/browse/ZEP-244

[ZEP-758] Rename Quark SE Devboard to its official name: Quark SE C1000
https://jira.zephyrproject.org/browse/ZEP-758

[ZEP-233] Support USB mass storage device class
https://jira.zephyrproject.org/browse/ZEP-233

[ZEP-346] Provide a HTTP library within Zephyr
https://jira.zephyrproject.org/browse/ZEP-346


CLOSED JIRA items within last 24 hours: 5
[ZEP-210] (Duplicate) Zephyr TEE compatibility
https://jira.zephyrproject.org/browse/ZEP-210

[ZEP-238] (Fixed) Usage of ARCH in application Makefiles is misleading
https://jira.zephyrproject.org/browse/ZEP-238

[ZEP-711] (Fixed) I2c: fails to write with mode fast plus
https://jira.zephyrproject.org/browse/ZEP-711

[ZEP-528] (Fixed) ARC has 2 almost identical copies of the linker script
https://jira.zephyrproject.org/browse/ZEP-528

[ZEP-754] (Duplicate) Remove the need to specify ARCH in the command line
https://jira.zephyrproject.org/browse/ZEP-754


RESOLVED JIRA items within last 24 hours: 1
[ZEP-715] (Fixed) Add K64F clock configurations
https://jira.zephyrproject.org/browse/ZEP-715


Re: Regarding linking pre-built object files.

Flavio Santes <flavio.santes@...>
 

Hello Nitin,

Perhaps this could help:

https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=tree;f=samples/static_lib

You can also check: https://jira.zephyrproject.org/browse/ZEP-637

Regards,
Flavio


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4469 : Bluetooth: btp: Extend BTP specification to cover L2CAP tests
- https://gerrit.zephyrproject.org/r/4462 : Bluetooth: Controller: Enable all supported LE states
- https://gerrit.zephyrproject.org/r/4456 : net/ip: Fix warnings when enabling IP debugging
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver APIi Have one function that can be used for all possible device purposes using a control code instead of the suspend resume functions, makes it generic for device control. Added device power states.
- https://gerrit.zephyrproject.org/r/4461 : drivers: i2c: change some i2c config parameters to SoC specific
- https://gerrit.zephyrproject.org/r/4457 : DONT MERGE
- https://gerrit.zephyrproject.org/r/4455 : drivers/slip: Fix circular depenency on NET_SLIP
- https://gerrit.zephyrproject.org/r/4460 : kconfig: include configuration fragment files from output directory
- https://gerrit.zephyrproject.org/r/4458 : verify: prevent checkpatch from verifying -1
- https://gerrit.zephyrproject.org/r/4453 : drivers/slip: Fix missing dependency on random
- https://gerrit.zephyrproject.org/r/4454 : net/yaip: Separate SLIP support into TAP and TUN options

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4415 : Bluetooth: HoG: Require authentication for connections
- https://gerrit.zephyrproject.org/r/4414 : Bluetooth: Add sample implementing HIDS
- 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/4360 : ksdk: Add KSDK RNGA driver.
- https://gerrit.zephyrproject.org/r/3845 : x86: remove dynamic interrupts and exceptions
- https://gerrit.zephyrproject.org/r/4448 : net: uip: Fix udp_socket_process receive data callback buffer handling.
- https://gerrit.zephyrproject.org/r/4449 : net: Fix code formatting
- https://gerrit.zephyrproject.org/r/4451 : net: uip: Fix compile fail with stats enabled, tcp disabled.
- https://gerrit.zephyrproject.org/r/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/4376 : Bluetooth: GAP: Support multiple peripheral role connections
- https://gerrit.zephyrproject.org/r/4452 : Bluetooth: A2DP: Initialization of A2DP.
- https://gerrit.zephyrproject.org/r/3923 : lib/http: Fix size_t dependency by adding stddef.h header
- https://gerrit.zephyrproject.org/r/3922 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/3924 : lib/http: Add test-case
- https://gerrit.zephyrproject.org/r/3848 : lib: Introduce the CoAP implementation for Zephyr
- https://gerrit.zephyrproject.org/r/3844 : test_context: don't test dynamic exceptions
- https://gerrit.zephyrproject.org/r/4226 : net: Do not fill in TCP option bytes for all packets
- https://gerrit.zephyrproject.org/r/3847 : arm: remove dynamic IRQs and exceptions
- https://gerrit.zephyrproject.org/r/4420 : boards: rename Quark SE Devboard to Quark SE C1000 (Sensor Subsystem)
- https://gerrit.zephyrproject.org/r/3957 : microkernel: remove deprecated task IRQs
- https://gerrit.zephyrproject.org/r/3843 : zephyr: remove deprecated dynamic interrupt API
- https://gerrit.zephyrproject.org/r/3856 : x86: declare internal API for interrupt controllers
- https://gerrit.zephyrproject.org/r/3846 : arc: remove deprecated dynamic interrupt implementation
- https://gerrit.zephyrproject.org/r/4118 : tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4354 : ztest: Add documentation
- https://gerrit.zephyrproject.org/r/3400 : known issues: ignore testcases failures
- https://gerrit.zephyrproject.org/r/4422 : boards: rename Quark SE Devboard to Quark SE C1000
- https://gerrit.zephyrproject.org/r/4103 : libc/printf: Use compiler-provided 64 bit math, phase 1

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4468 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4465 : net: tests: Fix printf modifiers in new IP stack unit tests
- https://gerrit.zephyrproject.org/r/4392 : net: yaip: Add network address length to user API
- https://gerrit.zephyrproject.org/r/4333 : ethernet: Enables multicast reception for dw driver
- https://gerrit.zephyrproject.org/r/3016 : samples: power/quark_se: Add support for Sleep states
- https://gerrit.zephyrproject.org/r/4432 : TCF: especify ARCH when building
- https://gerrit.zephyrproject.org/r/4441 : drivers/pinmux: delete unused file and Makefile item
- https://gerrit.zephyrproject.org/r/4426 : quark_se: disable IPM and enable UART0 on the sensor subsystem
- https://gerrit.zephyrproject.org/r/4130 : drivers: spi: Fix typos in SPI port numbers


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

Rohit Grover
 

Jukka, Paul,

I believe we should go ahead and fix tcpip_poll_tcp() according to the patch I submitted previously.
This fix can supersede https://gerrit.zephyrproject.org/r/#/c/4226, and we can pause on that particular pull request for now. We should also avoid regressing on any IPv6 functionality, so if there are tests we could use to evaluate IPv6 then we should employ them to validate changes to tcpip_poll_tcp().

Fixing tcpip_poll_tcp() isn't the complete answer. With changes to tcpip_poll_tcp(), I can get simple request-response transactions, but sustained/multiple transactions don't work; so there is still reason to suspect that TCP support is unreliable.

The bigger problem appears to be that the uIP port for Z has grown unmaintainable. I can sympathize with Jukka when he says that TCP support on uIP "is very cryptic and difficult to follow."
It is not clear to me if uIP is tricky to port in general, or that Z poses a special challenge.
Does Zephyr intend to switch from uIP to YAIP? If so, then perhaps one strategy would be to wait for YAIP to catch up.
If Zephyr wishes to maintain support for TCP/uIP, then someone needs to take a fresh look at the current uIP port, possibly from the point of view of a porter of uIP.

Regards,
Rohit.

-----Original Message-----
> From: Jukka Rissanen [mailto:jukka.rissanen(a)linux.intel.com]
> Sent: 01 September 2016 09:11
> To: Paul Sokolovsky; Rohit Grover
> Cc: devel(a)lists.zephyrproject.org
> Subject: Re: having trouble getting the echo client to work using TCP/uIP on
> K64F
>
> 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
>
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


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

6221 - 6240 of 7582