Date   

Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 5
[ZEP-945] Add framework for provisioning-sytle device configuration
https://jira.zephyrproject.org/browse/ZEP-945

[ZEP-938] Samples/hello_world/nanokernel: Build fail, when enable CONFIG_RANDOM_GENERATOR=y
https://jira.zephyrproject.org/browse/ZEP-938

[ZEP-940] Fail to get ATT response
https://jira.zephyrproject.org/browse/ZEP-940

[ZEP-939] Different address used for advertising in non-connectable mode from oob data
https://jira.zephyrproject.org/browse/ZEP-939

[ZEP-946] Galileo Gen1 board support dropped?
https://jira.zephyrproject.org/browse/ZEP-946


UPDATED JIRA items within last 24 hours: 17
[ZEP-817] Neighbor Discovery Optimization for IPv6 over 6LowPAN
https://jira.zephyrproject.org/browse/ZEP-817

[ZEP-809] IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-809

[ZEP-804] IPv6 Addressing Architecture
https://jira.zephyrproject.org/browse/ZEP-804

[ZEP-805] Internet Control Message Protocol (ICMP) v6
https://jira.zephyrproject.org/browse/ZEP-805

[ZEP-807] Neighbor Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-807

[ZEP-798] IPv6
https://jira.zephyrproject.org/browse/ZEP-798

[ZEP-823] New IP Stack - Documentation
https://jira.zephyrproject.org/browse/ZEP-823

[ZEP-852] SPI API Update
https://jira.zephyrproject.org/browse/ZEP-852

[ZEP-745] Revisit design of PWM Driver API
https://jira.zephyrproject.org/browse/ZEP-745

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

[ZEP-833] IP-to-IP tunneling support
https://jira.zephyrproject.org/browse/ZEP-833

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

[ZEP-796] DHCPv4
https://jira.zephyrproject.org/browse/ZEP-796

[ZEP-767] Add FS API to flush cache of an open file
https://jira.zephyrproject.org/browse/ZEP-767

[ZEP-692] Newlib libraries in x86 SDK need non-hardware floating point version
https://jira.zephyrproject.org/browse/ZEP-692

[ZEP-539] Jenkins marks patches -1 verified for style issues
https://jira.zephyrproject.org/browse/ZEP-539

[ZEP-746] API documentation doesn't link to conceptual documentation
https://jira.zephyrproject.org/browse/ZEP-746


CLOSED JIRA items within last 24 hours: 2
[ZEP-757] (Fixed) tests/kernel/test_context/ fail in Arduino 101 and Quark SE C1000
https://jira.zephyrproject.org/browse/ZEP-757

[ZEP-895] (Fixed) Initial release to tx semaphore for the ENC28J60 driver.
https://jira.zephyrproject.org/browse/ZEP-895


RESOLVED JIRA items within last 24 hours: 2
[ZEP-808] (Fixed) IPv6 Stateless Autoconfiguration (SLAAC)
https://jira.zephyrproject.org/browse/ZEP-808

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


Re: RFC: async I/O facility: "zpoll" API

Benjamin Walsh <benjamin.walsh@...>
 

On Mon, Sep 19, 2016 at 01:22:14PM -0700, Andy Ross wrote:
So I've been looking at the requirement for an async I/O framework in
ZEP-540, and this is the API I have so far. An implementation is
prototyped as far as working with a minimal test of a faked device,
I'll get that cleaned up and in gerrit for a review within a day. But
here's the API I'm looking at. Please tear it apart as appropriate;
it's an API we'll be stuck with for a while. Stuff to note:

It works a little like Unix select()/poll(), in that the caller gets
handles to a bunch of "zpoll_event" structures which are 1:1 with
async requests made (e.g. they're a return value from a putative
uart_write_async() call), and can wait on the full set of them, waking
up with any one of them has a completion event to signal.

Driver's are responsible for managing one of these events per
simultaneous outstanding request they want to handle (in mose cases
that number of requests will be one), and calling a straightforward
signal() function when the request is complete (or in an error state).

Because mixing blocking styles is madness (c.f. the historical
disaster of pthreads and file descriptors not being waitable in the
same call and the need for hacks like signalfd), it also accepts basic
semaphores as a waitable object. We might consider some of the other
IPC primitives for the same treatment.

The original request was for a callback mechanism, which I resisted.
But given this mechanism and the existance of the system work queue
(which, to be fair, is a heavyweight feature), that's not hard to
implement. So this supports both styles, but the callback one is
optional for apps with their own main loops that don't want to have a
extra 1kb thread stack sitting around just for event processing.

Semantically, this overlaps in a kind of ugly way with
sem_group_take(), which I see a patch in the queue for. Essentially
zpoll() is a proper superset of that facility. We should probably try
to unify/deprecate such that we can do things in only one way.

Please review. An implementation prototype will arrive promptly.
OK, this is _very_ interesting. We were thinking of actuatlly
implementing a 'wait on multiple objects' in the kernel rather than just
this 'semaphore group' we currently have (for backwards compatibility
for now anyway).

I'm really eager to see the prototype.

A couple of nitpicks:

- I don't think the documentation should focus on drivers. The is usable
by applications as well.

- This should be a native kernel feature. It should probably be called
k_poll rather than zpoll.

More comments below.


Andy


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

typedef void (*zpoll_callback_t)(int result, void *user_data);

enum zpoll_req_type { ZPOLL_REQ_POLL, ZPOLL_REQ_SEM, ZPOLL_REQ_CALLBACK };

struct zpoll_event {
enum zpoll_req_type type : 8;
int signaled : 1; /* Driver/source operation complete */
int active : 1; /* result not yet retrieved/delivered */
int result;
union {
struct {
zpoll_callback_t callback;
void *user_data;
Shouldn't we have a pointer to a workqueue, so that the work could be
scheduled on another workqueue than the system one if desired ?

} cb;
struct {
Shouldn't this be a union since one zpoll event instance should be for
one object ?

struct zpoll_call *poller;
Where is zpoll_call defined ? Isn't that simply a k_tid_t ?

struct k_sem *semaphore;
} polled;
};
};

/**
* @brief Re/initialize zpoll event
*
* For use by drivers who are initiating a new request. Will return
* an error (-EAGAIN) if the event is still in use, which should
* generally be either propagated back to the user code making the
* request or used to initiate some kind of queuing/allocation of a
* new event. Drivers should *not* pend or busy-wait at request time
* to "wait" for this to become available. These are asynchronous
* requests!
*
* @param evt A potentially-in-use zpoll_event structure
*/
int zpoll_event_init(struct zpoll_event *evt);

#ifdef ZPOLL_CALLBACKS
/**
* @brief Re/initialize zpoll event for a user-specified callback
*
* As for zpoll_event_init(), but assigns the callback fields where provided.
*
* @param evt A potentitally-in-use zpoll_event structure
* @param cb A user-provided callback function
* @param user_data A user-provided opaque pointer to be passed as the
* user_data argument to the callback
*/
int zpoll_event_init_cb(struct zpoll_event *evt, zpoll_callback_t cb, void *user_data);
#endif

/**
* @brief Static initializer for a semaphore zpoll_event
*
* Constructs a zpoll_event stucture suitable for passing to zpoll().
*
* @param sem A pointer to a valid k_sem_t.
*/
#define ZPOLL_EVENT_SEMAPHORE(sem) \
{ \
.request_type = ZPOLL_REQ_SEM, \
.signaled = 0, \
.semaphore = (sem), \
}

/**
* @brief Executes the user-provided handler for a complete event
*
* Called by driver code when the request abstracted by this zpoll
* event is complete, either by waking up a pending zpoll() call or
* scheduling a work thread to issue the user-provided callback.
*
* @param evt A zpoll_event structure whose action is complete
* @param result The integer result code of the asynchronous call
*/
void zpoll_signal(struct zpoll_event *evt, int result);

void _zpoll_sem_signal(struct k_sem *sem);
Do we need this ? Shouldn't this be the job of k_sem_give() to handle
waking up a thread from its polling ? I suppose that you do not have to
give a semaphore knowing that it is waiting on by a thread using zpoll,
right ?

Or is this a hook to be called from k_sem_give(). It might be, since it
is named like an internal kernel function.

Hard to tell without documentation.

Regards,
Ben


/**
* @brief Wait for the completion of any of a number of events
*
* Will pend until any of the zpoll_event structures receives a
* zpoll_signal() call from another context (or, for semaphores, a
* "give" event), or until a the specified timeout occurs.
*
* For convenience, will return one known-complete event pointer. But
* note that completion notifications are "level triggered" (they stay
* complete and will synchronously wake up future zpoll calls until
* their results are retrieved), and that there may be more whose
* state can be tested with zpoll_get_result(). In general most
* applications will simply loop on zpoll() getting one event at a
* time.
*
* @param events An array of zpoll_event structures
* @param nevents The size of the events array
* @param timeout_ticks How long to wait before returning, or
* TICKS_UNLIMITED to wait forever.
*
* @return One complete event, or NULL if the timeout expired.
*/
struct zpoll_event* zpoll(struct zpoll_event **events, int nevents,
int timeout_ticks);

/**
* @brief Retrieve the result code of a complete zpoll_event and mark
* it available
*
* Returns the integer result code of the operation encapsulated by
* the zpoll_event. For driver-managed events, this also marks the
* zpoll_event available for future asynchronous I/O calls and so
* *must* be called to free the resource for future I/O.
*
* Will return -EAGAIN if the event is not yet complete.
*
* @return The result code of the asynchronous operation
*/
int zpoll_get_result(struct zpoll_event *e);


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4852 : Bluetooth: Controller: Use net_buf for HCI RX
- https://gerrit.zephyrproject.org/r/4853 : Bluetooth: init: Add CONFIG_BLUETOOTH_A2DP to prj_20.conf
- https://gerrit.zephyrproject.org/r/4850 : net: yaip: Add ref counting debugging to neighbor cache
- https://gerrit.zephyrproject.org/r/4849 : net: yaip: Add more debugging prints to neighbor cache
- https://gerrit.zephyrproject.org/r/4837 : rfc: net: yaip: Add nbuf APIs to read/write across multiple fragments
- https://gerrit.zephyrproject.org/r/4851 : net: yaip: Add IPv6 utility func to create IPv6 packet
- https://gerrit.zephyrproject.org/r/4841 : x86: optimize GDT space
- https://gerrit.zephyrproject.org/r/4846 : doc: FIFO API uses first 32 bits of data items
- https://gerrit.zephyrproject.org/r/4842 : x86: make IDT setup optional
- https://gerrit.zephyrproject.org/r/4843 : doc: Add links from kernel API to overview docs

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4705 : power_mgmt: Mark old device pm API functions as deprecated
- https://gerrit.zephyrproject.org/r/4704 : power_mgmt: Update sample and drivers according to new pm device API
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: BR/EDR: Refactor distribution of security procedure status
- https://gerrit.zephyrproject.org/r/4821 : drivers: gpio: reuse gpio Kconfigs for sensor subsystem
- https://gerrit.zephyrproject.org/r/4347 : net: yaip: User connectivity API documentation
- https://gerrit.zephyrproject.org/r/4346 : net: yaip: Initial architecture documentation
- https://gerrit.zephyrproject.org/r/4828 : net: yaip: Add function to return neighbor by the index
- https://gerrit.zephyrproject.org/r/4830 : net: yaip: Fix reachable timer accessing NULL pointer
- https://gerrit.zephyrproject.org/r/4832 : net: yaip: Generic route handling
- https://gerrit.zephyrproject.org/r/4829 : net: yaip: Added a define for unused bytes length in ICMPv6 header
- https://gerrit.zephyrproject.org/r/4833 : net: tests: Add tests for route management API
- https://gerrit.zephyrproject.org/r/4808 : Bluetooth: L2CAP: Limit user I/O actions timeout in GAP context
- https://gerrit.zephyrproject.org/r/4796 : Bluetooth: L2CAP: Handle security procedure non successful path
- https://gerrit.zephyrproject.org/r/4795 : Bluetooth: L2CAP: Refactor handling connection response
- https://gerrit.zephyrproject.org/r/4445 : ksdk: Build ksdk fsl_enet.c and fsl_phy.c
- https://gerrit.zephyrproject.org/r/4356 : tests: convert tests/net/buf to the new framework
- https://gerrit.zephyrproject.org/r/4357 : tests: Add a sample for testing natively
- https://gerrit.zephyrproject.org/r/4353 : ztest: Add native building support
- https://gerrit.zephyrproject.org/r/4118 : tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4812 : x86: introduce new segmentation.h header
- https://gerrit.zephyrproject.org/r/4623 : eth: Adjust ENC28J60 transmission/reception return codes.
- https://gerrit.zephyrproject.org/r/4813 : iot/zoap: Fix subtly wrong indentation
- https://gerrit.zephyrproject.org/r/4676 : irq: Add irq_enable_keep external interrupt API
- https://gerrit.zephyrproject.org/r/4446 : rfc: ksdk: Add KSDK ENET driver.
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules
- https://gerrit.zephyrproject.org/r/4354 : ztest: Add documentation
- https://gerrit.zephyrproject.org/r/4555 : Bluetooth: HFP HF: SLC connection-Send/Parse BRSF
- https://gerrit.zephyrproject.org/r/27 : ci: test: checkpatch: warning space
- https://gerrit.zephyrproject.org/r/22 : ci: test: checkpatch: error braces
- https://gerrit.zephyrproject.org/r/4836 : lib/http: Add test-case for HTTP header fields
- https://gerrit.zephyrproject.org/r/3922 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/4780 : unified: Fix semaphore group tests
- https://gerrit.zephyrproject.org/r/4781 : unified: Enable semaphore group use in test_mail
- https://gerrit.zephyrproject.org/r/4779 : unified: Add support for semaphore groups
- https://gerrit.zephyrproject.org/r/4810 : unified: Add _is_next_thread_current()
- https://gerrit.zephyrproject.org/r/4785 : unified: Add timeslice support

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4847 : ieee802154_cc2520: Fix byte order swap for long address
- https://gerrit.zephyrproject.org/r/4848 : net: yaip: ieee802154: Endianess order is reversed on MAC
- https://gerrit.zephyrproject.org/r/4840 : Bluetooth: AVDTP: Add missing BLUETOOTH_DEBUG_AVDTP
- https://gerrit.zephyrproject.org/r/4839 : Bluetooth: init: Add CONFIG_BLUETOOTH_AVDTP to prj_20.conf
- https://gerrit.zephyrproject.org/r/4824 : tinycrypt: Add test case for the ECC DSA algorithm
- https://gerrit.zephyrproject.org/r/4825 : tinycrypt: Add test case for the ECC DH algorithm
- https://gerrit.zephyrproject.org/r/4794 : Bluetooth: A2DP: Initialization of A2DP
- https://gerrit.zephyrproject.org/r/4806 : net: yaip: Add IEEE 802.15.4 Beacon frame validation support
- https://gerrit.zephyrproject.org/r/4807 : net: yaip: tests: Add a simple IEEE 802.15.4 Beacon frame test


Re: Porting to Cortex-M0+

Kumar Gala
 

On Sep 20, 2016, at 3:28 AM, Piotr Mienkowski <Piotr.Mienkowski(a)schmid-telecom.ch> wrote:

Hi Niheer,

I have taken the action from Maureen to find out more information from Atmel.
Thanks for taking care about the issue. I understand that Atmel still hasn't reached out to you. Is TSC going to consider accepting existing license from Atmel? Shall we wait a bit longer? Is there some deadline?

I would like to add support for Atmel SAM E70 chipset to Zephyr 1.6 release. I have most of the code ready but submitting it to Gerrit, feedback, fixes will probably take some time so the earlier I can start the better.

Cheers,
Piotr
Why don’t you submit the code for review to at least let us move that bit along while we figure out the issues with Atmel.

- k


Re: Galileo Gen 1 GPIO

Tomasz Bursztyka
 

Hi Gottfried,

Using this Cypress chip is a mandatory support as a low level pinmuxing
driver
if you want to configure and use the hardware pins, the ones exposed as
arduino compatible.
Your use case of inserting an arduino shield is exactly one of those
which will fail.

If you take a look here:
http://www.intel.com/content/www/us/en/embedded/products/galileo/galileo-g1-datasheet.html
You'll see the grey boxes "MUX": this is about this chip.

The mapping:
http://download.intel.com/support/galileo/sb/galileoiomappingrev2.pdf

It is the same story for Gen 2, but the chip is different. Take a look
at boards/galileo/pinmux*
(and drivers/gpio/gpio_pcal9535a.c).

About USB, Zephyr as a low level usb API. I know it works for Quark SE
SoC, but not Quark x1000 (Galileo's).
It could be the same controller, I don't know if anyone has tried.

Tomasz

Tomasz,

Thanks for your answer.Like Fabio I also want to use Galieo v1 board
but not really certain about your answer and what
type of restrictions you are talking about.Myself I will not use
Cypress so maybe your answer would be different.
But it would be nice to know what GPIO restrictions are there on
Galileo v1
Playing around with busybox on Galileo was cool but would love to
connect 2 devices to it ( one usb-host ,one arduino shield ).I am
well aware that you work for zephyr and not Galileo

Br

Gottfried
.

On Mon, Sep 19, 2016 at 7:37 AM, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com
<mailto:tomasz.bursztyka(a)linux.intel.com>> wrote:

Hi Fábio,

Unfortunately, we do not support Galileo v1 pinmuxing, thus: the
whole board is basically unusable at this stage.
You won't be able to get very far unless you provide the cypress
chip driver.

Can you use another board? We support quite a few (see boards
directory in zephyr's tree)

Br,

Tomasz



Dear Sirs,
I am using Galileo Gen 1 (Cypress I/O expander) and I can
not change the GPIO levels.
What GPIO driver should I set in menuconfig tool
(DesignWare, PCAL9535, MMIO, Intel SCH)?
What driver name and pin numbers should I use in functions
API (gpio_pin_configure, gpio_pin_write, ....)?
Thank you very much.


Re: RFC: async I/O facility: "zpoll" API

Andy Ross
 

Joseph, Jithu wrote:
I think this implies that callback is made from (a new) zpoll
thread,(which will get built into the system) and not from the
context which invokes zpoll_signal().
Right. It's made from the system work queue, the same thread that
handles {nano,k}_work_submit entries. The signal call is typically
going to be made from interrupt context, which is a really poor place
to be issuing arbitrary user callbacks.

If the user app is interested only in a one async callback event ,
For e.g if the user app after making the uart_write_async_cb()
(which internally calls zpoll_event_init_cb()) call, should it still
call zpoll() ( if so will it return immediately - even when the
event has not occurred - so that the main thread can continue) or
can it continue remaining instructions without calling zpoll() ?
If you really are interested in only one event, you probably want to
be using the existing synchronous API. :)

But yes: zpoll() will block. You can specify a timeout to ensure you
come back (or TICKS_NONE -- I just now realized I need to have support
for that, even though in this case it's just a noop), or include a
semaphore as your own "wake up" signal that you can control from
another thread.

If you want to poll for completion for some reason, you can check
zpoll_get_result() from any context.

Andy


Re: Galileo Gen 1 GPIO

Gottfried F. Zojer
 

Tomasz,

Thanks for your answer.Like Fabio I also want to use Galieo v1 board but
not really certain about your answer and what
type of restrictions you are talking about.Myself I will not use Cypress so
maybe your answer would be different.
But it would be nice to know what GPIO restrictions are there on Galileo v1
Playing around with busybox on Galileo was cool but would love to connect
2 devices to it ( one usb-host ,one arduino shield ).I am well aware that
you work for zephyr and not Galileo

Br

Gottfried
.

On Mon, Sep 19, 2016 at 7:37 AM, Tomasz Bursztyka <
tomasz.bursztyka(a)linux.intel.com> wrote:

Hi Fábio,

Unfortunately, we do not support Galileo v1 pinmuxing, thus: the whole
board is basically unusable at this stage.
You won't be able to get very far unless you provide the cypress chip
driver.

Can you use another board? We support quite a few (see boards directory in
zephyr's tree)

Br,

Tomasz



Dear Sirs,
I am using Galileo Gen 1 (Cypress I/O expander) and I can not change
the GPIO levels.
What GPIO driver should I set in menuconfig tool (DesignWare,
PCAL9535, MMIO, Intel SCH)?
What driver name and pin numbers should I use in functions API
(gpio_pin_configure, gpio_pin_write, ....)?
Thank you very much.


Re: zoap architecture question...

Vinicius Costa Gomes
 

Hi,

Marcus Shawcroft <marcus.shawcroft(a)gmail.com> writes:

On 19 September 2016 at 19:37, Vinicius Costa Gomes
<vinicius.gomes(a)intel.com> wrote:

Hi, Thanks for responding. Its good to see coap moving forward in zephyr.

The plan is that the error handling would live in the layer above. So
yeah, the zoap-server sample right now is lacking in the invalid
messages handling department.

What I see that could be done in the zoap layer is to add a few helper
functions for building the most common types of messages, including
RESET.

This choice implies multiples consumers of the coap protocol, both
client and servers would all duplicate the logic of detecting various
error conditions and responding in an appropriate way. This logic is
reasonably simple, but none trivial. I believe they all need to detect
and deal with the at least the following cases:
I agree that this has a cost in repeated code.

Just a little background: when I wrote sol-coap, for the Soletta
project, I took the opposite way, I tried to handle everything inside
sol-coap. In the end, some users were coding around some of the
"features".

zoap, for now, will stay out of users way, at the cost of some repeated
code. Later, hhen we have a couple of concrete use cases, zoap will
become more opinionated.

- corrupt packet, header incomplete (no message id)
-> ignore it
- corrupt packet, but header complete (included message id)
-> ignore unrecognized versions
-> respond with con on reset messages.

Lowering this logic into the coap layer encapsulates it in one place,
which should be simpler to verify, and, at least superficially should
simplify the implementation of coap consumers.... are there other
issues involved here that make is desirable to push such logic
upwards?
There are a couple of points that should be taken into consideration:

- zoap is largely independent of the network stack (by design) and it
doesn't have any buffers of its own;
- zoap doesn't have all the information to handle that correctly, for
example, an application may choose to ignore all invalid packets from
a multicast address, to avoid increasing the noise;

But as always, if you have ideas (or patches :-) ) so we can reach the
middle ground faster, I am all ears.


Cheers
/Marcus
Cheers,
--
Vinicius


Re: RFC: Extension to External Interrupt API

Maureen Helm
 

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Monday, September 19, 2016 3:31 PM
To: Iván Briano <ivan.briano(a)intel.com>
Cc: vinayak.kariappa.chettimada(a)nordicsemi.no; Boie, Andrew P
<andrew.p.boie(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: RFC: Extension to External Interrupt API

On Mon, Sep 19, 2016 at 04:34:07PM -0300, Iván Briano wrote:
On Mon, 19 Sep 2016 19:07:12 +0000, Boie, Andrew P wrote:
On Fri, 2016-09-16 at 04:52 +0000, Vinayak Kariappa Chettimada wrote:
Hi,

Welcome your valuable comments on the proposed extension to
External Interrupt API.

*irq_enable_keep*
https://gerrit.zephyrproject.org/r/#/c/4676/1
https://gerrit.zephyrproject.org/r/#/c/4677/1
Originally Vinayak sent a patch to change ARM's irq_enable() not to
unpend any pending interrupts when enabling the channel. It was -1
as we didn't want to change the semantics of the kernel API to
preserve compatibility.

However, on further inspection of other arches, this behavior seems
to be peculiar to ARM.

On x86, for example, enabling an IRQ in the IOAPIC or MVIC just
clears the IOAPIC_INT_MASK (bit 16) in the appropriate IOREDTBL
entry. It doesn't clear pending interrupts on that line. Indeed, if
it did, the rate-limiting in the IPM console driver wouldn't work.

On ARC, similarly it puts the IRQ line into the _ARC_V2_IRQ_SELECT
register, and then writes to the _ARC_V2_IRQ_ENABLE register to
enable/disable it. I don't see anything in the datasheet that
un-pends any pending interrupts.

I think at this point we could consider ARM's behavior of clearing
pending interrupts on irq_enable() a bug and we should change it,
making irq_enable_keep() unnecessary. Does this sound good to
everyone?

Sounds reasonable to me.
Put like that, it's probably the right thing to do.
Sounds ok to me. Thanks for digging into the other arches Andrew.


Re: zepyr application to write on to UDP socket

Giribabu Gogineni <giribabu02061983@...>
 

Hi Jukka,

Thanks for the feedback.
When we use echo client running on QEMU using SLIP and we have server
application running on linux host, we receive the extra headers along with
data.

Our requirement is pass the UDP data from zephyr app using QEMU and receive
the same exact UDP packet on linux host side.
Please let us know, if we have any solution for this.

Thanks in advance ...

Regards,
Giribabu

On Thu, Sep 1, 2016 at 7:21 PM, Jukka Rissanen <
jukka.rissanen(a)linux.intel.com> wrote:

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


Re: zoap architecture question...

Marcus Shawcroft <marcus.shawcroft@...>
 

On 19 September 2016 at 19:37, Vinicius Costa Gomes
<vinicius.gomes(a)intel.com> wrote:

Hi, Thanks for responding. Its good to see coap moving forward in zephyr.

The plan is that the error handling would live in the layer above. So
yeah, the zoap-server sample right now is lacking in the invalid
messages handling department.

What I see that could be done in the zoap layer is to add a few helper
functions for building the most common types of messages, including
RESET.

This choice implies multiples consumers of the coap protocol, both
client and servers would all duplicate the logic of detecting various
error conditions and responding in an appropriate way. This logic is
reasonably simple, but none trivial. I believe they all need to detect
and deal with the at least the following cases:

- corrupt packet, header incomplete (no message id)
-> ignore it
- corrupt packet, but header complete (included message id)
-> ignore unrecognized versions
-> respond with con on reset messages.

Lowering this logic into the coap layer encapsulates it in one place,
which should be simpler to verify, and, at least superficially should
simplify the implementation of coap consumers.... are there other
issues involved here that make is desirable to push such logic
upwards?

Cheers
/Marcus


Re: Porting to Cortex-M0+

Piotr Mienkowski <piotr.mienkowski@...>
 

Hi Niheer,

I have taken the action from Maureen to find out more information from Atmel.
Thanks for taking care about the issue. I understand that Atmel still hasn't reached out to you. Is TSC going to consider accepting existing license from Atmel? Shall we wait a bit longer? Is there some deadline?

I would like to add support for Atmel SAM E70 chipset to Zephyr 1.6 release. I have most of the code ready but submitting it to Gerrit, feedback, fixes will probably take some time so the earlier I can start the better.

Cheers,
Piotr


Re: Galileo Gen 1 Compatibility

Tomasz Bursztyka
 

Hi Fábio,

All work but the pinmuxer (Cypress CY8C9540A) which is used to expose
the i2c, spi and gpio pins.

Ethernet should work right away, afaik.

From your first email, I understood you were trying to access GPIO pins,
and due to this pinmuxing issue, you won't be able to. :(

Tomasz

Dear Sirs,
I am studying the Zephyr a few months ago because the site says that it works with Galileo Gen1 (Gen1/Gen2) and now I discovered that GPIO driver do not works on Gen1.
I would like to know what are drivers that work on Gen1.
Thank you very much.


Re: RFC: Extension to External Interrupt API

Chettimada, Vinayak Kariappa
 

Hi Andrew,

I think at this point we could consider ARM's behavior of clearing
pending interrupts on irq_enable() a bug and we should change it,
making irq_enable_keep() unnecessary. Does this sound good to everyone?

Andrew
Good with me. I will update the irq_enable_keep change to the original fix of irq_enable.
This means, I can abandon the irq_pending_clear as well, as this is interrupt_controller domain (I created this patch on request, for the missing clear in the _keep interface).

Summary so far:
1. Fix irq_enable (irq_enable_keep has been "-1"-ed).
2. Add the irq_is_enabled in irq.h (already "+2"-ed).

Consensus required on:
1. Drop the irq_pending_set/clear, as this is interrupt_controller domain/model.

Action to myself:
1. Try out fibers where ever feasible as bottom-halves (atleast in BLE controller design)
2. Analyse if fibers makes sense as peripheral IRQ offloading, latency, and RAM usage.

-Vinayak


Re: Question about non-XIP boot

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

Dear Benjamin,

I got it now, thank you very much.

On 2016年09月20日 04:23, Benjamin Walsh wrote:
On Mon, Sep 19, 2016 at 11:19:47AM +0800, Tidy Jiang wrote:
Hi All,

I'm reading the boot code for cortex-m, but confused about
something, please help me.

Before jumping to C code:

void _PrepC(void)
{
relocate_vector_table();
enable_floating_point();
_bss_zero();
_data_copy();
_Cstart();
CODE_UNREACHABLE;
}

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

#ifdef CONFIG_XIP
static inline void relocate_vector_table(void) { /* do nothing */ }
#else
static inline void relocate_vector_table(void)
{
/* vector table is already in SRAM, just point to it */
_scs_relocate_vector_table((void *)CONFIG_SRAM_BASE_ADDRESS);
}
#endif

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

In non-XIP mode, from my view, before relocate vector table to RAM,
we should copy the data from flash to RAM. But above code firstly
relocates and then copy data, why ?
In non-XIP mode, the image is supposed to already be in RAM, including
the data, so there is no data to copy from the flash. _data_copy() does
nothing in that case.


Re: RFC: Extension to External Interrupt API

Chettimada, Vinayak Kariappa
 

Hi Ben,

That said, I think it would still be a good idea to implement
bottom-halves.
I will "+1", "+2" is I could, for bottom-halves and for a design that uses an ISR's program stack.

- Vinayak


Re: RFC: Extension to External Interrupt API

Chettimada, Vinayak Kariappa
 

Hi Andrew,

If we expect to support additional interrupt controllers on ARM, it may
be worthwhile to implement a similar interface for ARM.


I suspect there are simpler approaches, I would really look into having
your ISR pend a fiber to do the bottom half work. In another mail Andy
gave some more detail.

Andrew
I am addressing two of styles in my code:
1. bottom-halves for ISR.
2. atomic access to peripheral only in its ISR.

For example, oscillator calibration, which is something an application can start/stop while another timer internal to clock peripheral too would do periodically/automatically. To solve race-conditions, application would just pend the clock IRQ (just like an internally timer would), the ISR being single context operating on the peripheral mitigates any race-condition and reduces latencies on ISR triggered by internal timer.

Yes, I will give a try on using fiber for both. Only issue I see is, I need to allocate program stack for each independently fibers, where as an ISR or bottom-half would share the ISR program stack.

-Vinayak


Galileo Gen 1 Compatibility

Fábio Iaione <fabio.iaione at gmail.com...>
 

Dear Sirs,
I am studying the Zephyr a few months ago because the site says that it works with Galileo Gen1 (Gen1/Gen2) and now I discovered that GPIO driver do not works on Gen1.
I would like to know what are drivers that work on Gen1.
Thank you very much.


Re: RFC: async I/O facility: "zpoll" API

Joseph, Jithu
 

Unix like generic async API framework can potentially simplify app/driver development . So it is great to have.

From a quick read, I have a question regarding the callback mechanism (Perhaps it may become clear with the whole patch ... anyway)

[Andy, Ross]
The original request was for a callback mechanism, which I resisted.
But given this mechanism and the existance of the system work queue (which,
to be fair, is a heavyweight feature), that's not hard to implement. So
this supports both styles, but the callback one is optional for apps with
their own main loops that don't want to have a extra 1kb thread stack
sitting around just for event processing.
[Joseph, Jithu] I think this implies that callback is made from (a new) zpoll thread,(which will get built into the system) and not from the context which invokes zpoll_signal().

A question on api usage in this scenario:

If the user app is interested only in a one async callback event , For e.g if the user app after making the uart_write_async_cb() (which internally calls zpoll_event_init_cb()) call, should it still call zpoll() ( if so will it return immediately - even when the event has not occurred - so that the main thread can continue) or can it continue remaining instructions without calling zpoll() ?


Thanks
Jithu

-----Original Message-----
From: Andy Ross [mailto:andrew.j.ross(a)intel.com]
Sent: Monday, September 19, 2016 1:22 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] RFC: async I/O facility: "zpoll" API

So I've been looking at the requirement for an async I/O framework in ZEP-
540, and this is the API I have so far. An implementation is prototyped as
far as working with a minimal test of a faked device, I'll get that cleaned
up and in gerrit for a review within a day. But here's the API I'm looking
at. Please tear it apart as appropriate; it's an API we'll be stuck with
for a while. Stuff to note:

It works a little like Unix select()/poll(), in that the caller gets
handles to a bunch of "zpoll_event" structures which are 1:1 with async
requests made (e.g. they're a return value from a putative
uart_write_async() call), and can wait on the full set of them, waking up
with any one of them has a completion event to signal.

Driver's are responsible for managing one of these events per simultaneous
outstanding request they want to handle (in mose cases that number of
requests will be one), and calling a straightforward
signal() function when the request is complete (or in an error state).

Because mixing blocking styles is madness (c.f. the historical disaster of
pthreads and file descriptors not being waitable in the same call and the
need for hacks like signalfd), it also accepts basic semaphores as a
waitable object. We might consider some of the other IPC primitives for
the same treatment.

The original request was for a callback mechanism, which I resisted.
But given this mechanism and the existance of the system work queue (which,
to be fair, is a heavyweight feature), that's not hard to implement. So
this supports both styles, but the callback one is optional for apps with
their own main loops that don't want to have a extra 1kb thread stack
sitting around just for event processing.

Semantically, this overlaps in a kind of ugly way with sem_group_take(),
which I see a patch in the queue for. Essentially
zpoll() is a proper superset of that facility. We should probably try to
unify/deprecate such that we can do things in only one way.

Please review. An implementation prototype will arrive promptly.

Andy


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

typedef void (*zpoll_callback_t)(int result, void *user_data);

enum zpoll_req_type { ZPOLL_REQ_POLL, ZPOLL_REQ_SEM, ZPOLL_REQ_CALLBACK };

struct zpoll_event {
enum zpoll_req_type type : 8;
int signaled : 1; /* Driver/source operation complete */
int active : 1; /* result not yet retrieved/delivered
*/
int result;
union {
struct {
zpoll_callback_t callback;
void *user_data;
} cb;
struct {
struct zpoll_call *poller;
struct k_sem *semaphore;
} polled;
};
};

/**
* @brief Re/initialize zpoll event
*
* For use by drivers who are initiating a new request. Will return
* an error (-EAGAIN) if the event is still in use, which should
* generally be either propagated back to the user code making the
* request or used to initiate some kind of queuing/allocation of a
* new event. Drivers should *not* pend or busy-wait at request time
* to "wait" for this to become available. These are asynchronous
* requests!
*
* @param evt A potentially-in-use zpoll_event structure */ int
zpoll_event_init(struct zpoll_event *evt);

#ifdef ZPOLL_CALLBACKS
/**
* @brief Re/initialize zpoll event for a user-specified callback
*
* As for zpoll_event_init(), but assigns the callback fields where
provided.
*
* @param evt A potentitally-in-use zpoll_event structure
* @param cb A user-provided callback function
* @param user_data A user-provided opaque pointer to be passed as the
* user_data argument to the callback
*/
int zpoll_event_init_cb(struct zpoll_event *evt, zpoll_callback_t cb, void
*user_data); #endif

/**
* @brief Static initializer for a semaphore zpoll_event
*
* Constructs a zpoll_event stucture suitable for passing to zpoll().
*
* @param sem A pointer to a valid k_sem_t.
*/
#define ZPOLL_EVENT_SEMAPHORE(sem) \
{ \
.request_type = ZPOLL_REQ_SEM, \
.signaled = 0, \
.semaphore = (sem), \
}

/**
* @brief Executes the user-provided handler for a complete event
*
* Called by driver code when the request abstracted by this zpoll
* event is complete, either by waking up a pending zpoll() call or
* scheduling a work thread to issue the user-provided callback.
*
* @param evt A zpoll_event structure whose action is complete
* @param result The integer result code of the asynchronous call */ void
zpoll_signal(struct zpoll_event *evt, int result);

void _zpoll_sem_signal(struct k_sem *sem);

/**
* @brief Wait for the completion of any of a number of events
*
* Will pend until any of the zpoll_event structures receives a
* zpoll_signal() call from another context (or, for semaphores, a
* "give" event), or until a the specified timeout occurs.
*
* For convenience, will return one known-complete event pointer. But
* note that completion notifications are "level triggered" (they stay
* complete and will synchronously wake up future zpoll calls until
* their results are retrieved), and that there may be more whose
* state can be tested with zpoll_get_result(). In general most
* applications will simply loop on zpoll() getting one event at a
* time.
*
* @param events An array of zpoll_event structures
* @param nevents The size of the events array
* @param timeout_ticks How long to wait before returning, or
* TICKS_UNLIMITED to wait forever.
*
* @return One complete event, or NULL if the timeout expired.
*/
struct zpoll_event* zpoll(struct zpoll_event **events, int nevents,
int timeout_ticks);

/**
* @brief Retrieve the result code of a complete zpoll_event and mark
* it available
*
* Returns the integer result code of the operation encapsulated by
* the zpoll_event. For driver-managed events, this also marks the
* zpoll_event available for future asynchronous I/O calls and so
* *must* be called to free the resource for future I/O.
*
* Will return -EAGAIN if the event is not yet complete.
*
* @return The result code of the asynchronous operation */ int
zpoll_get_result(struct zpoll_event *e);


[TCP/IPv4] Sending out Ethernet packets appear to have issues

Paul Sokolovsky
 

Hello,

I'm continuing testing of Marcus Shawcroft's FRDM-K64F Ethernet driver:
https://gerrit.zephyrproject.org/r/#/c/4446 . Initial testing using
echo_server seems to be ok, but trying to initiate connection from
device has issues. Specifically, of "GET /foo HTTP/1.0\r\n\r\n" request
I use, only "GE" is being send out.

One thing I noticed is that eth_ksdk.c uses uip_len(buf) for packet
length, while net_driver_ethernet_send() which calls it, dumps
buf->len. Usage of uip_len(buf) comes from reference driver eth_dw.c (I
assume).

I dumped both lengths and here's how it looks:

net: net_driver_ethernet_send (0x200150d4): Sending 54 bytes uip_len=44
Smashed net_buf with ARP request
net: net_driver_ethernet_send (0x200150d4): Really sending 54 bytes
eth: sending 42 bytes (buf->len=54)
net_context_tcp_init()=0
waiting to connect: -119
net: net_driver_ethernet_send (0x200178d4): Sending 54 bytes uip_len=44
Didn't smash net_buf with ARP request
net: net_driver_ethernet_send (0x200178d4): Really sending 54 bytes
eth: sending 58 bytes (buf->len=54)
net: net_rx_fiber (0x200170d4): Received buf 0x20001bc0
s.write("GET /foo HTTP/1.0\r\n\r\n")
socket_write(2000d1d0, 2000d430, 21)
net: net_send (0x200150d4): context 0x2000c8b8 buf 0x20007304 status 0
net: net_tx_fiber (0x200174d4): Sending (buf 0x20007304, len 75) to IP stack
net: net_driver_ethernet_send (0x200174d4): Sending 75 bytes uip_len=42
Didn't smash net_buf with ARP request
net: net_driver_ethernet_send (0x200174d4): Really sending 75 bytes
eth: sending 56 bytes (buf->len=75)

So, one can say that uip_len(buf) and buf->len isn't well synchronized.
With the last packet, which contains user data, if buf->len was used,
then all data probably would have been sent. However before, there can
be seen can when len->buf is 54, but uip_len(58).

All that stuff works now pretty well with QEMU/SLIP. So, my plan is to
see what SLIP driver does and try to do the same. Of course, the issue
may be more complicated, like both Z and uIP trying to add Ethernet
header, in different combinations for different packet types.

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

6661 - 6680 of 8189