1. devel@lists.zephyrproject.org
  2. Messages
   Date   
Re: RFC: make _fiber_start() return a handle on the fiber

Jukka Rissanen
 

I think I figured this out:

- I was trying to wake up the same fiber I was running
- I was always calling fiber_fiber_wakeup() instead of proper context
depending version

After fixing these two issues, the fiber wake up seems to work now
fine.

I would suggest that if possible, the wake up code could check that we
are not trying to wake ourselves.


Cheers,
Jukka

On Wed, 2016-02-24 at 13:54 +0200, Jukka Rissanen wrote:
Re-sending this using proper mail address.


I managed to get following backtrace when the system is hanging:


_nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
    at /home/jukka/src/zephyr/kernel/nanokernel/nano_fiber.c:53
53              while (pQ->link && (tcs->prio >= pQ->link->prio)) {
(gdb) bt
#0  _nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
    at /home/jukka/src/zephyr/kernel/nanokernel/nano_fiber.c:53
#1  0x40033ea9 in _nano_wait_q_remove_no_check (wait_q=<optimized
out>)
    at /home/jukka/src/zephyr/kernel/nanokernel/include/wait_q.h:57
#2  _fifo_put_non_preemptible (fifo=<optimized out>, data=0xa8006520
<tx_buffers>)
    at /home/jukka/src/zephyr/kernel/nanokernel/nano_fifo.c:118
#3  0x4003c77b in net_driver_15_4_send (buf=0xa8006520 <tx_buffers>)
    at /home/jukka/src/zephyr/net/ip/net_driver_15_4.c:81
#4  0x400350f3 in net_tcpip_output (buf=0xa8006520 <tx_buffers>,
lladdr=<optimized out>)
    at /home/jukka/src/zephyr/net/ip/net_core.c:801
#5  0x400369e9 in tcpip_ipv6_output (buf=buf(a)entry=0xa8006520
<tx_buffers>)
    at /home/jukka/src/zephyr/net/ip/contiki/ip/tcpip.c:785
#6  0x4003a15f in uip_nd6_rs_output (buf=0xa8006520 <tx_buffers>)
    at /home/jukka/src/zephyr/net/ip/contiki/ipv6/uip-nd6.c:870
#7  0x40038d43 in uip_ds6_send_rs (buf=buf(a)entry=0x0)
    at /home/jukka/src/zephyr/net/ip/contiki/ipv6/uip-ds6.c:708
#8  0x40036b76 in eventhandler (buf=0x0, data=<optimized out>, ev=118
'v')
    at /home/jukka/src/zephyr/net/ip/contiki/ip/tcpip.c:471
#9  process_thread_tcpip_process (process_pt=process_pt(a)entry=0xa8009
2b
8 <tcpip_process+12>, 
    ev=ev(a)entry=136 '\210', data=0xa800cda0 <uip_ds6_timer_rs>,
buf=0x0)
    at /home/jukka/src/zephyr/net/ip/contiki/ip/tcpip.c:885
#10 0x40036c32 in call_process (p=0xa80092ac <tcpip_process>,
ev=<optimized out>, data=<optimized out>, 
    buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:198
#11 0x40036e90 in process_post_synch (p=<optimized out>,
ev=<optimized
out>, data=<optimized out>, buf=0x0)
    at /home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:375
#12 0x400370d7 in process_thread_etimer_process (
    process_pt=process_pt(a)entry=0xa80092c8 <etimer_process+12>, ev=ev
@e
ntry=130 '\202', 
    data=<optimized out>, buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/etimer.c:117
#13 0x40036c32 in call_process (p=0xa80092bc <etimer_process>,
ev=<optimized out>, data=<optimized out>, 
    buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:198
#14 0x40036e90 in process_post_synch (p=p(a)entry=0xa80092bc
<etimer_process>, ev=ev(a)entry=130 '\202', 
    data=data(a)entry=0x0, buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:375
#15 0x400370fb in etimer_request_poll () at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/etimer.c:130
#16 0x40034ac8 in net_timer_fiber () at
/home/jukka/src/zephyr/net/ip/net_core.c:674
#17 0x400340e0 in _thread_entry (pEntry=0x40034a7c <net_timer_fiber>,
parameter1=<optimized out>, 
    parameter2=<optimized out>, parameter3=0x0)

(gdb) p pQ->link
$6 = (struct tcs *) 0xa800e620 <timer_fiber_stack>
(gdb) p tcs->prio
$7 = 7
(gdb) p pQ->link->prio
$8 = 7


Any ideas what is going on?


Cheers,
Jukka


On Wed, 2016-02-24 at 12:03 +0200, Jukka Rissanen wrote:
Hi Peter & Ben,

I am seeing couple of issues when trying to wake up a fiber.

1) if my fiber tries to to wake up itself (yes, there was a bug in
my
program), there seems to be weird issues (hangs). This could be
just
symptoms of 2)

2) after making sure that I am not trying to wake the running
fiber,
I
am seeing weird issues. After running several rounds of sleeps and
wakes, the OS just hangs when calling fiber_sleep(). I wonder how
to
debug this, any suggestions?

Cheers,
Jukka


On Mon, 2016-02-22 at 18:07 +0000, Mitsis, Peter wrote:
For what it is worth, I am currently tackling this item.

Peter

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen(a)linux.intel.com]
Sent: February-22-16 2:01 AM
To: Walsh, Benjamin
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: RFC: make _fiber_start() return a
handle
on the
fiber

Hi Ben,

On Fri, 2016-02-19 at 10:36 -0500, Benjamin Walsh wrote:
When we start a fiber via the _fiber_start() API family,
we
don't
get back a handle on the created fiber. The fiber
identifier
is
actually the start of the fiber's stack. This hasn't been
a
problem until now since no API requires a handle on the
fiber,
except one,
fiber_delayed_start_cancel(): that API is part of a pair,
where
the other API, fiber_delayed_start() starts the fiber and
returns
a handle.

However, Jukka asked me an API could be created that
cancels
a
fiber_sleep() call, something like fiber_wakeup(). The
implementation of such an API is very simple, but it
requires
a
handle on the fiber we want to wake up. This in turn
requires
the
signature of the _fiber_start() family to return a handle
to
the
fiber that gets started.

The signature of _fiber_start() et al. would then change
from
a
void return type to a void * return type.

Objections, comments, etc ?
No comments -> no objects -> perhaps we can continue with
this
route
then?
Looks like it. You want to do the implementation yourself
Jukka
?
I am a bit busy right now so I am fine if you do it.


Cheers,
Jukka
Re: RFC: make _fiber_start() return a handle on the fiber

Jukka Rissanen
 

Re-sending this using proper mail address.


I managed to get following backtrace when the system is hanging:


_nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
    at /home/jukka/src/zephyr/kernel/nanokernel/nano_fiber.c:53
53              while (pQ->link && (tcs->prio >= pQ->link->prio)) {
(gdb) bt
#0  _nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
    at /home/jukka/src/zephyr/kernel/nanokernel/nano_fiber.c:53
#1  0x40033ea9 in _nano_wait_q_remove_no_check (wait_q=<optimized out>)
    at /home/jukka/src/zephyr/kernel/nanokernel/include/wait_q.h:57
#2  _fifo_put_non_preemptible (fifo=<optimized out>, data=0xa8006520
<tx_buffers>)
    at /home/jukka/src/zephyr/kernel/nanokernel/nano_fifo.c:118
#3  0x4003c77b in net_driver_15_4_send (buf=0xa8006520 <tx_buffers>)
    at /home/jukka/src/zephyr/net/ip/net_driver_15_4.c:81
#4  0x400350f3 in net_tcpip_output (buf=0xa8006520 <tx_buffers>,
lladdr=<optimized out>)
    at /home/jukka/src/zephyr/net/ip/net_core.c:801
#5  0x400369e9 in tcpip_ipv6_output (buf=buf(a)entry=0xa8006520
<tx_buffers>)
    at /home/jukka/src/zephyr/net/ip/contiki/ip/tcpip.c:785
#6  0x4003a15f in uip_nd6_rs_output (buf=0xa8006520 <tx_buffers>)
    at /home/jukka/src/zephyr/net/ip/contiki/ipv6/uip-nd6.c:870
#7  0x40038d43 in uip_ds6_send_rs (buf=buf(a)entry=0x0)
    at /home/jukka/src/zephyr/net/ip/contiki/ipv6/uip-ds6.c:708
#8  0x40036b76 in eventhandler (buf=0x0, data=<optimized out>, ev=118
'v')
    at /home/jukka/src/zephyr/net/ip/contiki/ip/tcpip.c:471
#9  process_thread_tcpip_process (process_pt=process_pt(a)entry=0xa80092b
8 <tcpip_process+12>, 
    ev=ev(a)entry=136 '\210', data=0xa800cda0 <uip_ds6_timer_rs>,
buf=0x0)
    at /home/jukka/src/zephyr/net/ip/contiki/ip/tcpip.c:885
#10 0x40036c32 in call_process (p=0xa80092ac <tcpip_process>,
ev=<optimized out>, data=<optimized out>, 
    buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:198
#11 0x40036e90 in process_post_synch (p=<optimized out>, ev=<optimized
out>, data=<optimized out>, buf=0x0)
    at /home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:375
#12 0x400370d7 in process_thread_etimer_process (
    process_pt=process_pt(a)entry=0xa80092c8 <etimer_process+12>, ev=ev(a)e
ntry=130 '\202', 
    data=<optimized out>, buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/etimer.c:117
#13 0x40036c32 in call_process (p=0xa80092bc <etimer_process>,
ev=<optimized out>, data=<optimized out>, 
    buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:198
#14 0x40036e90 in process_post_synch (p=p(a)entry=0xa80092bc
<etimer_process>, ev=ev(a)entry=130 '\202', 
    data=data(a)entry=0x0, buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:375
#15 0x400370fb in etimer_request_poll () at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/etimer.c:130
#16 0x40034ac8 in net_timer_fiber () at
/home/jukka/src/zephyr/net/ip/net_core.c:674
#17 0x400340e0 in _thread_entry (pEntry=0x40034a7c <net_timer_fiber>,
parameter1=<optimized out>, 
    parameter2=<optimized out>, parameter3=0x0)

(gdb) p pQ->link
$6 = (struct tcs *) 0xa800e620 <timer_fiber_stack>
(gdb) p tcs->prio
$7 = 7
(gdb) p pQ->link->prio
$8 = 7


Any ideas what is going on?


Cheers,
Jukka

On Wed, 2016-02-24 at 12:03 +0200, Jukka Rissanen wrote:
Hi Peter & Ben,

I am seeing couple of issues when trying to wake up a fiber.

1) if my fiber tries to to wake up itself (yes, there was a bug in my
program), there seems to be weird issues (hangs). This could be just
symptoms of 2)

2) after making sure that I am not trying to wake the running fiber,
I
am seeing weird issues. After running several rounds of sleeps and
wakes, the OS just hangs when calling fiber_sleep(). I wonder how to
debug this, any suggestions?

Cheers,
Jukka


On Mon, 2016-02-22 at 18:07 +0000, Mitsis, Peter wrote:
For what it is worth, I am currently tackling this item.

Peter

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen(a)linux.intel.com]
Sent: February-22-16 2:01 AM
To: Walsh, Benjamin
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: RFC: make _fiber_start() return a handle
on the
fiber

Hi Ben,

On Fri, 2016-02-19 at 10:36 -0500, Benjamin Walsh wrote:
When we start a fiber via the _fiber_start() API family, we
don't
get back a handle on the created fiber. The fiber
identifier
is
actually the start of the fiber's stack. This hasn't been a
problem until now since no API requires a handle on the
fiber,
except one,
fiber_delayed_start_cancel(): that API is part of a pair,
where
the other API, fiber_delayed_start() starts the fiber and
returns
a handle.

However, Jukka asked me an API could be created that
cancels
a
fiber_sleep() call, something like fiber_wakeup(). The
implementation of such an API is very simple, but it
requires
a
handle on the fiber we want to wake up. This in turn
requires
the
signature of the _fiber_start() family to return a handle
to
the
fiber that gets started.

The signature of _fiber_start() et al. would then change
from
a
void return type to a void * return type.

Objections, comments, etc ?
No comments -> no objects -> perhaps we can continue with
this
route
then?
Looks like it. You want to do the implementation yourself Jukka
?
I am a bit busy right now so I am fine if you do it.


Cheers,
Jukka
Re: RFC: make _fiber_start() return a handle on the fiber

Rissanen, Jukka <jukka.rissanen@...>
 

I managed to get following backtrace when the system is hanging:


_nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
    at /home/jukka/src/zephyr/kernel/nanokernel/nano_fiber.c:53
53 while (pQ->link && (tcs->prio >= pQ->link->prio)) {
(gdb) bt
#0  _nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
    at /home/jukka/src/zephyr/kernel/nanokernel/nano_fiber.c:53
#1  0x40033ea9 in _nano_wait_q_remove_no_check (wait_q=<optimized out>)
    at /home/jukka/src/zephyr/kernel/nanokernel/include/wait_q.h:57
#2  _fifo_put_non_preemptible (fifo=<optimized out>, data=0xa8006520
<tx_buffers>)
    at /home/jukka/src/zephyr/kernel/nanokernel/nano_fifo.c:118
#3  0x4003c77b in net_driver_15_4_send (buf=0xa8006520 <tx_buffers>)
    at /home/jukka/src/zephyr/net/ip/net_driver_15_4.c:81
#4  0x400350f3 in net_tcpip_output (buf=0xa8006520 <tx_buffers>,
lladdr=<optimized out>)
    at /home/jukka/src/zephyr/net/ip/net_core.c:801
#5  0x400369e9 in tcpip_ipv6_output (buf=buf(a)entry=0xa8006520
<tx_buffers>)
    at /home/jukka/src/zephyr/net/ip/contiki/ip/tcpip.c:785
#6  0x4003a15f in uip_nd6_rs_output (buf=0xa8006520 <tx_buffers>)
    at /home/jukka/src/zephyr/net/ip/contiki/ipv6/uip-nd6.c:870
#7  0x40038d43 in uip_ds6_send_rs (buf=buf(a)entry=0x0)
    at /home/jukka/src/zephyr/net/ip/contiki/ipv6/uip-ds6.c:708
#8  0x40036b76 in eventhandler (buf=0x0, data=<optimized out>, ev=118
'v')
    at /home/jukka/src/zephyr/net/ip/contiki/ip/tcpip.c:471
#9  process_thread_tcpip_process (process_pt=process_pt(a)entry=0xa80092b
8 <tcpip_process+12>, 
    ev=ev(a)entry=136 '\210', data=0xa800cda0 <uip_ds6_timer_rs>,
buf=0x0)
    at /home/jukka/src/zephyr/net/ip/contiki/ip/tcpip.c:885
#10 0x40036c32 in call_process (p=0xa80092ac <tcpip_process>,
ev=<optimized out>, data=<optimized out>, 
    buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:198
#11 0x40036e90 in process_post_synch (p=<optimized out>, ev=<optimized
out>, data=<optimized out>, buf=0x0)
    at /home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:375
#12 0x400370d7 in process_thread_etimer_process (
    process_pt=process_pt(a)entry=0xa80092c8 <etimer_process+12>, ev=ev(a)e
ntry=130 '\202', 
    data=<optimized out>, buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/etimer.c:117
#13 0x40036c32 in call_process (p=0xa80092bc <etimer_process>,
ev=<optimized out>, data=<optimized out>, 
    buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:198
#14 0x40036e90 in process_post_synch (p=p(a)entry=0xa80092bc
<etimer_process>, ev=ev(a)entry=130 '\202', 
    data=data(a)entry=0x0, buf=0x0) at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/process.c:375
#15 0x400370fb in etimer_request_poll () at
/home/jukka/src/zephyr/net/ip/contiki/os/sys/etimer.c:130
#16 0x40034ac8 in net_timer_fiber () at
/home/jukka/src/zephyr/net/ip/net_core.c:674
#17 0x400340e0 in _thread_entry (pEntry=0x40034a7c <net_timer_fiber>,
parameter1=<optimized out>, 
    parameter2=<optimized out>, parameter3=0x0)

(gdb) p pQ->link
$6 = (struct tcs *) 0xa800e620 <timer_fiber_stack>
(gdb) p tcs->prio
$7 = 7
(gdb) p pQ->link->prio
$8 = 7


Any ideas what is going on?


Cheers,
Jukka


On Wed, 2016-02-24 at 12:03 +0200, Jukka Rissanen wrote:
Hi Peter & Ben,

I am seeing couple of issues when trying to wake up a fiber.

1) if my fiber tries to to wake up itself (yes, there was a bug in my
program), there seems to be weird issues (hangs). This could be just
symptoms of 2)

2) after making sure that I am not trying to wake the running fiber,
I
am seeing weird issues. After running several rounds of sleeps and
wakes, the OS just hangs when calling fiber_sleep(). I wonder how to
debug this, any suggestions?

Cheers,
Jukka


On Mon, 2016-02-22 at 18:07 +0000, Mitsis, Peter wrote:
For what it is worth, I am currently tackling this item.

Peter

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen(a)linux.intel.com]
Sent: February-22-16 2:01 AM
To: Walsh, Benjamin
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: RFC: make _fiber_start() return a handle
on the
fiber

Hi Ben,

On Fri, 2016-02-19 at 10:36 -0500, Benjamin Walsh wrote:
When we start a fiber via the _fiber_start() API family, we
don't
get back a handle on the created fiber. The fiber
identifier
is
actually the start of the fiber's stack. This hasn't been a
problem until now since no API requires a handle on the
fiber,
except one,
fiber_delayed_start_cancel(): that API is part of a pair,
where
the other API, fiber_delayed_start() starts the fiber and
returns
a handle.

However, Jukka asked me an API could be created that
cancels
a
fiber_sleep() call, something like fiber_wakeup(). The
implementation of such an API is very simple, but it
requires
a
handle on the fiber we want to wake up. This in turn
requires
the
signature of the _fiber_start() family to return a handle
to
the
fiber that gets started.

The signature of _fiber_start() et al. would then change
from
a
void return type to a void * return type.

Objections, comments, etc ?
No comments -> no objects -> perhaps we can continue with
this
route
then?
Looks like it. You want to do the implementation yourself Jukka
?
I am a bit busy right now so I am fine if you do it.


Cheers,
Jukka
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

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: make _fiber_start() return a handle on the fiber

Jukka Rissanen
 

Hi Peter & Ben,

I am seeing couple of issues when trying to wake up a fiber.

1) if my fiber tries to to wake up itself (yes, there was a bug in my
program), there seems to be weird issues (hangs). This could be just
symptoms of 2)

2) after making sure that I am not trying to wake the running fiber, I
am seeing weird issues. After running several rounds of sleeps and
wakes, the OS just hangs when calling fiber_sleep(). I wonder how to
debug this, any suggestions?

Cheers,
Jukka

On Mon, 2016-02-22 at 18:07 +0000, Mitsis, Peter wrote:
For what it is worth, I am currently tackling this item.

Peter

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen(a)linux.intel.com]
Sent: February-22-16 2:01 AM
To: Walsh, Benjamin
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: RFC: make _fiber_start() return a handle
on the
fiber

Hi Ben,

On Fri, 2016-02-19 at 10:36 -0500, Benjamin Walsh wrote:
When we start a fiber via the _fiber_start() API family, we
don't
get back a handle on the created fiber. The fiber identifier
is
actually the start of the fiber's stack. This hasn't been a
problem until now since no API requires a handle on the
fiber,
except one,
fiber_delayed_start_cancel(): that API is part of a pair,
where
the other API, fiber_delayed_start() starts the fiber and
returns
a handle.

However, Jukka asked me an API could be created that cancels
a
fiber_sleep() call, something like fiber_wakeup(). The
implementation of such an API is very simple, but it requires
a
handle on the fiber we want to wake up. This in turn requires
the
signature of the _fiber_start() family to return a handle to
the
fiber that gets started.

The signature of _fiber_start() et al. would then change from
a
void return type to a void * return type.

Objections, comments, etc ?
No comments -> no objects -> perhaps we can continue with this
route
then?
Looks like it. You want to do the implementation yourself Jukka ?
I am a bit busy right now so I am fine if you do it.


Cheers,
Jukka
Re: RFC: make _fiber_start() return a handle on the fiber

Liu, Sharron <sharron.liu@...>
 

Returning a handler maybe is good for app to invoke other fiber related APIs for operation on same fiber.

But regarding the case described below, I have question can "nano_sem_give" be used instead of requesting fiber_wakeup()? From Zephyr document I learnt both "semaphore wait" and "sleep" blocks the execution of fiber and triggers the scheduler to dequeue another executable fiber.

Thanks,
Sharron

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Saturday, February 20, 2016 1:17 AM
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: devel(a)lists.zephyrproject.org; Rissanen, Jukka <jukka.rissanen(a)intel.com>
Subject: [devel] Re: RFC: make _fiber_start() return a handle on the fiber

When we start a fiber via the _fiber_start() API family, we don't
get back a handle on the created fiber. The fiber identifier is
actually the start of the fiber's stack. This hasn't been a
problem until now since no API requires a handle on the fiber,
except one, fiber_delayed_start_cancel(): that API is part of a
pair, where the other API, fiber_delayed_start() starts the fiber
and returns a handle.

However, Jukka asked me an API could be created that cancels a
fiber_sleep() call, something like fiber_wakeup(). The
implementation of such an API is very simple, but it requires a
handle on the fiber we want to wake up. This in turn requires the
signature of the _fiber_start() family to return a handle to the
fiber that gets started.

The signature of _fiber_start() et al. would then change from a
void return type to a void * return type.

Objections, comments, etc ?
Sounds good, but we need to do it in away that keeps APIs
compatible I guess.
We're just returning a thread ID when we start a fiber now, you can
ignore it. I don't see an issue here...
You are right, this will not break existing code. Nevertheless, we
should track such API changes and document them in release notes.
Sure.
Re: Pinmux driver model: per board vs. unified

Kalowsky, Daniel <daniel.kalowsky@...>
 

In the future, when you're making architectural changes like this, send to the mailing list first. Submitting it to gerrit only is NOT advised, and limits the audience which can view the commentary. This highlights the entire reason why we have an RFC process in the first place.

-----Original Message-----
From: Vinicius Costa Gomes [mailto:vinicius.gomes(a)intel.com]
Sent: Tuesday, February 23, 2016 10:18 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Pinmux driver model: per board vs. unified

Hi,

(Sorry for the click bait-ish subject)

As per Dirk's suggestion moving the discussion on the pinmux model[1][2] to
the mailing list.

Quoting Dirk:
So I like the idea here to move all the code common to manipulating
the pinmux registers in to a single place.

The way this change goes about that is wrong IMHO. Each board should
have its own driver that uses the library code, not a single driver
that picks up the board specific code at link time. This forces the
user to look in their .config to figure out what board specific code
is included in their image.
Makes sense.
This is a re-tread of something we already tried initially. Placing everything into a library wasn't a bad idea initially, but we did find a couple of issues with it. For example, it did not scale out cleanly to other architectures. On the other hand, in some devices we were being asked to shave out any extra bytes possible, the overhead of setting up the function call became a little too much. The footprint tests on this patch confirm an increase in the ROM footprint by an average of 312 bytes. Oddly it shows a slight decrease in RAM on the footprint-max tests only (everything else is an increase), which has an unknown root cause as of yet to me.

Second this is slow. Calling the _pinmux_dev_set() which reads+modifies+writes in a non-atomic fashion for two bits to the hardware repeatedly instead of making a single 32-bit write introduces a pretty big increase in execution time. As this driver/function is essential to the board bring up, you are now negatively impacting boot time.

Third, you do reduce LOC, which is a good thing and something I applaud. This change is really impacting code that is well tested and extremely static at this point. I'm extremely hesitant to change code like this for minimal/"no" benefit. Most of the LOCs removed are tied to specific boards selection for building, not impacting an everyday build, which is why I say no benefit.

Where the library code lands is an open question ATM. This is very
similar to the QMSI stuff where we will be using a library for
accessing the registers in the IP block.
The only thing that may complicate matters a bit is the point that today we
have two ways of interacting with the pinmux registers, one that is used by
the board specific code and one that may be used by applications (disabled
by default).
I'm not sure I follow the complication here. You can enable the PINMUX_DEV flag via PRJ for any application that needs to control the pinmux. We have explicitly disabled this by default for very specific reasons of not wanting to debug/support unknown variations of the pinmux (we learned from our mistake really quickly), and wanted end users to actively know they were moving into potentially "untested functionality" by changing these values. Since any application change already requires re-compiling the kernel, I'm not sure I see the concern with having an application enable this feature if needed.

In cases where applications really need to change the pinmux behavior, I believe any competent system integrator will be making changes directly to the pinmux.c file. Changing the default values rather than making them at application run-time provides a single point of board configuration. I further believe anyone developing a product using Zephyr will more than likely be creating their own boards/product-name which should be a self-contained product.

But for the sake of discussion, let's assume we move forward with the idea of making a library routine for everything. What needs to be done?

1) The name needs to be fixed. As noted in the patch already, calling this the generic Quark SOC pinmux is wrong and mis-leading. This doesn't support the X10x0 family, is unclear if it supports the D1000 family (I haven't looked), and is really specific only to the x86 CPU family/model.

2) Zephyr is multiple architectures. Changing the code-base architecture for Intel specific boards only, while ignoring the other architectures, is reason enough to -2 a patch. Please make sure when you're making changes like this in the future to reflect the change on all supported boards. If you're moving one, you're moving all of them to keep consistency. For example, the arduino_due could potentially have the pinmux moved into the same directory and be renamed to atmel_sam3x_pinmux.c (or some variation).

3) Investigate how to limit the r+m+w overhead of the calls to _pinmux_dev_set().

4) Verify that the Quark D2000 will continue to work when writing out mistakenly to registers it does not support, but the Quark SE does. It is a very subtle but important variation. I suspect that this won't be an issue, but it is one that has not been tested.


--
Vinicius

[1] https://gerrit.zephyrproject.org/r/#/c/385

[2] https://gerrit.zephyrproject.org/r/#/c/386
Re: Build fails when the sdk is not installed in the default path in Archlinux.

Yannis Damigos
 

On 02/23/2016 09:07 PM, Perez-Gonzalez, Inaky wrote:
On Mon, 2016-02-22 at 11:27 -0800, Dirk Brandewie wrote:

On 02/22/2016 09:59 AM, Yannis Damigos wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/22/2016 07:26 PM, Dirk Brandewie wrote:


On 02/22/2016 08:42 AM, Yannis Damigos wrote:
On 02/22/2016 05:10 PM, Dirk Brandewie wrote:


On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not
installed under the default path (/opt/zephyr-sdk) in
Archlinux with the following error:
make[1]: Entering directory
'/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory
'/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for
kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No
such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for
target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for
target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory
'/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory
'/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe
for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install
directory?

When the sdk is installed under the default path compiling
succeeded.

Best regards,
Yannis
Yes, ZEPHYR_SDK_INSTALL_DIR is pointing to the correct SDK
install directory.
Hmmm :-/ Can you send the output of the make command adding V=1
to the
command line?
Here it is https://gist.github.com/xekarfwtos/78d9c85f018ed2a0ce4bYou could
Hmm looks like an SDK issue :-( I have created a bug for it
https://jira.zephyrproject.org/browse/ZEP-65

I don't have any more useful advice unfortunately.
Yannis can you provide an trace log?

$ strace -fo trace.log make ... [ETC ETC] ...

Thanks,
You could find the trace log uploaded under the issue ZEP-65 in jira:

https://jira.zephyrproject.org/browse/ZEP-65

Yannis
Re: Pinmux driver model: per board vs. unified

Andre Guedes <andre.guedes@...>
 

Hi all,

Here is one proposal on how we can deal with pinmux drivers and board-
specific pinmux configurations:

1. All pinmux drivers land in driver/pinmux/ directory and they all
implement the include/pinmux.h API only.

2. Board-specific code (e.g. board/quark_d2000_crb/board.c) defines
the pinmux table and uses the pinmux APIs to apply its specific
configurations. To achieve that, we could define the board_init()
function in board.c which would handle any board-specific initialization,
including pinmux configuration. We could use SYS_INIT() so board_init()
is executed during kernel initialization.

In order to this approach work, we have to ensure the pinmux driver is
initialized before board_init() is called. This can be achieved by setting
pinmux driver initialization to PRIMARY level and board_init() to SECONDARY
level.

AFAICS, this approach would work for all boards, besides Galileo. Pinmux
in Galileo is quite different and it would require a special handling.

Since Galileo pinmux driver depends on others devices (I2C, PCA9535 and
PCAL9685) we cannot init it on PRIMARY level. So the Galileo board_init()
would be set to SECONDARY level and we use the 'prio' argument from
SYS_INIT() to ensure board_init() is executed after galileo pinmux
initialization.

Regards,

Andre

Quoting Vinicius Costa Gomes (2016-02-23 15:18:25)

So I like the idea here to move all the code common to manipulating
the pinmux registers in to a single place.

The way this change goes about that is wrong IMHO. Each board should
have its own driver that uses the library code, not a single driver
that picks up the board specific code at link time. This forces the
user to look in their .config to figure out what board specific code
is included in their image.
Makes sense.


Where the library code lands is an open question ATM. This is very
similar to the QMSI stuff where we will be using a library for
accessing the registers in the IP block.
The only thing that may complicate matters a bit is the point that today
we have two ways of interacting with the pinmux registers, one that is
used by the board specific code and one that may be used by applications
(disabled by default).

Or do you mean we continue providing two pinmux APIs?


We need to figure out the correct long term model. This discussion
should happen on the mailing list instead of gerrit so all involved
can see whats going on.

Cheers,
--
Vinicius

[1] https://gerrit.zephyrproject.org/r/#/c/385

[2] https://gerrit.zephyrproject.org/r/#/c/386
Re: Build fails when the sdk is not installed in the default path in Archlinux.

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

On Mon, 2016-02-22 at 11:27 -0800, Dirk Brandewie wrote:

On 02/22/2016 09:59 AM, Yannis Damigos wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/22/2016 07:26 PM, Dirk Brandewie wrote:


On 02/22/2016 08:42 AM, Yannis Damigos wrote:
On 02/22/2016 05:10 PM, Dirk Brandewie wrote:


On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not
installed under the default path (/opt/zephyr-sdk) in
Archlinux with the following error:
make[1]: Entering directory
'/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory
'/home/xekarfwtos/projects/philosophers/outdir'
     Using /home/xekarfwtos/projects/zephyr as source for
kernel
     GEN     ./Makefile
     CHK     include/generated/version.h
     HOSTCC  scripts/basic/fixdep
     HOSTCC  scripts/gen_idt/version.o
     HOSTCC  scripts/gen_idt/gen_idt.o
     HOSTLD  scripts/gen_idt/gen_idt
     HOSTCC  scripts/gen_offset_header/gen_offset_header.o
     HOSTLD  scripts/gen_offset_header/gen_offset_header
     CHK     misc/generated/configs.c
     UPD     misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No
such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for
target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for
target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory
'/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory
'/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe
for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install
directory?

When the sdk is installed under the default path compiling
succeeded.

Best regards,
Yannis
Yes, ZEPHYR_SDK_INSTALL_DIR is pointing to the correct SDK
install directory.
Hmmm :-/  Can you send the output of the make command adding V=1
to the
command line?
Here it is https://gist.github.com/xekarfwtos/78d9c85f018ed2a0ce4b
Hmm looks like an SDK issue :-(  I have created a bug for it
https://jira.zephyrproject.org/browse/ZEP-65

I don't have any more useful advice unfortunately.
Yannis can you provide an trace log?

$ strace -fo trace.log make ... [ETC ETC] ...

Thanks,
Pinmux driver model: per board vs. unified

Vinicius Costa Gomes
 

Hi,

(Sorry for the click bait-ish subject)

As per Dirk's suggestion moving the discussion on the pinmux model[1][2] to
the mailing list.

Quoting Dirk:
So I like the idea here to move all the code common to manipulating
the pinmux registers in to a single place.

The way this change goes about that is wrong IMHO. Each board should
have its own driver that uses the library code, not a single driver
that picks up the board specific code at link time. This forces the
user to look in their .config to figure out what board specific code
is included in their image.
Makes sense.


Where the library code lands is an open question ATM. This is very
similar to the QMSI stuff where we will be using a library for
accessing the registers in the IP block.
The only thing that may complicate matters a bit is the point that today
we have two ways of interacting with the pinmux registers, one that is
used by the board specific code and one that may be used by applications
(disabled by default).

Or do you mean we continue providing two pinmux APIs?


We need to figure out the correct long term model. This discussion
should happen on the mailing list instead of gerrit so all involved
can see whats going on.

Cheers,
--
Vinicius

[1] https://gerrit.zephyrproject.org/r/#/c/385

[2] https://gerrit.zephyrproject.org/r/#/c/386
Do the Zephyr support Z-Wave, Zigbee Connectivity?

JongWoon Lee <sharkvary@...>
 

Dear all.

First, I welcome the zephyr. This will be a great help for developer.

As You know, the number of wireless communication is currently an
increasing..

Not only Wi-Fi, BT/BLE but Z-Wave, Zigbee is used for wireless
communication.

Now the zephyr is not support Z-Wave, Zigbee Communication..

Are there plans to add Z-Wave, Zigbee Communication?

Have a good time~!

?
attachment.html

Re: Build fails when the sdk is not installed in the default path in Archlinux.

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/22/2016 09:59 AM, Yannis Damigos wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/22/2016 07:26 PM, Dirk Brandewie wrote:


On 02/22/2016 08:42 AM, Yannis Damigos wrote:
On 02/22/2016 05:10 PM, Dirk Brandewie wrote:


On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install directory?

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis
Yes, ZEPHYR_SDK_INSTALL_DIR is pointing to the correct SDK install directory.
Hmmm :-/ Can you send the output of the make command adding V=1 to the
command line?
Here it is https://gist.github.com/xekarfwtos/78d9c85f018ed2a0ce4b
Hmm looks like an SDK issue :-( I have created a bug for it
https://jira.zephyrproject.org/browse/ZEP-65

I don't have any more useful advice unfortunately.

--Dirk
Re: RFC: make _fiber_start() return a handle on the fiber

Mitsis, Peter <Peter.Mitsis@...>
 

For what it is worth, I am currently tackling this item.

Peter

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen(a)linux.intel.com]
Sent: February-22-16 2:01 AM
To: Walsh, Benjamin
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: RFC: make _fiber_start() return a handle on the
fiber

Hi Ben,

On Fri, 2016-02-19 at 10:36 -0500, Benjamin Walsh wrote:
When we start a fiber via the _fiber_start() API family, we don't
get back a handle on the created fiber. The fiber identifier is
actually the start of the fiber's stack. This hasn't been a
problem until now since no API requires a handle on the fiber,
except one,
fiber_delayed_start_cancel(): that API is part of a pair, where
the other API, fiber_delayed_start() starts the fiber and returns
a handle.

However, Jukka asked me an API could be created that cancels a
fiber_sleep() call, something like fiber_wakeup(). The
implementation of such an API is very simple, but it requires a
handle on the fiber we want to wake up. This in turn requires the
signature of the _fiber_start() family to return a handle to the
fiber that gets started.

The signature of _fiber_start() et al. would then change from a
void return type to a void * return type.

Objections, comments, etc ?
No comments -> no objects -> perhaps we can continue with this route
then?
Looks like it. You want to do the implementation yourself Jukka ?
I am a bit busy right now so I am fine if you do it.


Cheers,
Jukka
Re: Build fails when the sdk is not installed in the default path in Archlinux.

Yannis Damigos
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/22/2016 07:26 PM, Dirk Brandewie wrote:


On 02/22/2016 08:42 AM, Yannis Damigos wrote:
On 02/22/2016 05:10 PM, Dirk Brandewie wrote:


On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install directory?

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis
Yes, ZEPHYR_SDK_INSTALL_DIR is pointing to the correct SDK install directory.
Hmmm :-/ Can you send the output of the make command adding V=1 to the
command line?
Here it is https://gist.github.com/xekarfwtos/78d9c85f018ed2a0ce4b
Re: Build fails when the sdk is not installed in the default path in Archlinux.

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/22/2016 08:42 AM, Yannis Damigos wrote:
On 02/22/2016 05:10 PM, Dirk Brandewie wrote:


On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install directory?

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis
Yes, ZEPHYR_SDK_INSTALL_DIR is pointing to the correct SDK install directory.
Hmmm :-/ Can you send the output of the make command adding V=1 to the
command line?
Re: Build fails when the sdk is not installed in the default path in Archlinux.

Yannis Damigos
 

On 02/22/2016 05:10 PM, Dirk Brandewie wrote:


On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install directory?

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis
Yes, ZEPHYR_SDK_INSTALL_DIR is pointing to the correct SDK install directory.
Re: RFC: return type of functions passed to DEVICE_INIT()

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/19/2016 05:20 PM, Thomas, Ramesh wrote:
I was considering the possible use case of PM app calling
_sys_device_do_config_level(). In that case a return value of 0 or 1
would help it know some thing went wrong instead of having to query all
devices to find out. But I think this does not impact the main topic of
your RFC and can be addressed separately if necessary.
_sys_device_do_config_level() is *not* a public API and is *not*
guaranteed be stable or even exist from release to release.

AFAIK calling _sys_device_do_config_level() again would not break any of
our current drivers but is the driver is is creating some state in
init() (e.g. security context, network connection) all hell is likely
to break loose. The driver could maintain whether init() has been
called to work around this but at the cost of RAM.

What is the use case? What functionality do you need?

--Dirk
Re: RFC: return type of functions passed to DEVICE_INIT()

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/19/2016 05:31 PM, Thomas, Ramesh wrote:
On Fri, 2016-02-19 at 10:05 -0800, Daniel Leung wrote:
On Fri, Feb 19, 2016 at 08:31:48AM -0800, Dirk Brandewie wrote:


On 02/18/2016 03:04 PM, Daniel Leung wrote:
On Thu, Feb 18, 2016 at 05:54:56PM -0500, Benjamin Walsh wrote:
My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices to
their project. If one of these devices should fail, then that is a
serious system error and _NanoFatalErrorHandler() should be invoked.

If this train of thought holds up to scrutiny, and if the aim is to
save a few bytes then I would think that it would be better to have
the device initialization routines return a failure code and have
_sys_device_do_config_level() check for it and invoke the fatal error
handler upon the detection of failure. Otherwise we duplicate the
overhead of calling the fatal error handler in each device
initialization routine.
Sorry for the slow response. I agree with Peter here I think we should
be checking the return value and doing something useful with the
result. Maybe not _NanoFatalErrorHandler() but something notifying
the application that something bad happened. A given device not
initializing may not be fatal to the the whole application, just one
feature is currently unavailable.
For the kind of systems we are targeting, do we really expect the
application to handle devices not initializing correctly, being designed
so that parts are disabled if some parts of the initialization fail
(devices or others), or do we expect applications to require everything
to be present for them to function correctly ? I would have thought the
latter, but I can be convinced.
Delving into the realm of the hypothetical :-)

What about devices that have drivers in the system but are not present
(pluggable) or can't initialize because some resource external to the
device can't be contacted (network server).

The application may be able to still do useful work albeit with reduced
functionality.

Then, if the latter, do we expect the application catching the errors at
runtime when deployed or during development (basically catching software
errors mostly) not malfunctionning hardware. Here, I was thinking the
latter as well, which is why I was proposing __ASSERT() calls catching
initialization errors in debug loads only. And this fits with one of the
core values of the OS, which is small footprint.
Both models are useful for different reasons :-D

Any of those could be a valid approach I think, but we have to decide on
one. And right now, we have the worst since we return those error codes
which are meant for runtime handling, but they just go into the void.
Agreed we need to pick and stay with it for some amount of time until
we see a few real uses/applications/platforms.
OK, following your proposal below, what we could put in place is
standardizing on error codes that init routines must return if they want
the kernel init system to automatically trigger a fatal error.

Then, we could also allow configuring out the error handling if someone
needs to squeeze that last amount of space. One more Kconfig option! :)
The error handling would be enabled by default of course.
For those non-fatal errors, what should we do for runtime driver behaviors?
Should the drivers themselves fail API calls? Or should we let
device_get_binding() return NULL?
How about something like this:

diff --git a/kernel/nanokernel/device.c b/kernel/nanokernel/device.c
index f86f95f..82774c4 100644
--- a/kernel/nanokernel/device.c
+++ b/kernel/nanokernel/device.c
@@ -58,7 +58,7 @@ struct device *device_get_binding(char *name)
struct device *info;

for (info = __device_init_start; info != __device_init_end; info++) {
- if (!strcmp(name, info->config->name)) {
+ if (!strcmp(name, info->config->name) && info->driver_api) {
return info;
}
}

if there is a non-fatal error the driver will not mark itself available
and we can get rid of the null checks in the API headers since the user of the
driver will never get a reference to it if init() did not complete successfully
Why not create a dedicated status field in device object?
It would take more RAM :-) Not sure exactly what you would want to
return in the status? If device init() fails there is nothing the
application code can do about it other that fail gracefully.

Additionally we can provide an API to query status of devices. This
will help query status of devices it does not bind to.
If you are not binding to a device why do you need the status? If
there is a good use case propose the API with the patch ;-)


This should work. We need to rework some of the drivers as they make
the driver_api assignment unconditionally.


----------
Daniel Leung
Re: How to setup git-review

Andrew Grimberg <agrimberg@...>
 

On 02/19/2016 08:37 AM, Andre Guedes wrote:
Hi Anas,

Quoting Nashif, Anas (2016-02-19 14:07:36)
Thanks for documenting this but I don't think forcing people to use git-review is the right approach.
Yes, I agree.
Forcing people to use git-review is not the intent. Using git-review
eases the cognitive burden of working inside the enforced gerrit worfklow.

Tell me, which would you find easier to do / remember?

--[cut with git review]--
git checkout master && git pull && git checkout -b my_topic
# make changes
git commit -asm 'gee whiz feature' && git review
--[/cut with git review]--

vs

--[cut without git review]--
git checkout master && git pull && git checkout -b my_topic
# make changes
git commit -asm 'gee whiz feature' && git rebase master && git push
origin HEAD:refs/for/master/my_topic
--[/cut without git review]--

Or for pulling a remote submission for local review

--[cut with git review]--
git checkout master && git pull && git review -d $submission_number
--[/cut with git review]--

NOTES:
* not supplying a patch number gets the latest if multiple, to specify
an earlier version of a submission use $submission_number,$patch_number

* submission number gets checked out locally to
branch review/<user>/topic_name (or revision number if no topic)

vs

--[cut without git review]--
git checkout master && git pull
git fetch origin refs/changes/$change_id_mod_100/$change_id/$patch_number
git checkout -b local_review_of_$change_id FETCH_HEAD
--[/cut without git review]--

It worked for us before in many other projects, why is this
different and why can't I use vanilla git to gerrit interaction?

What is the issue here exactly?
I'm not a gerrit expert but from I could understand, this is related to the
'forge author' settings from submitter rights. I'm CCing Andrew so he might
add more details about it.
After all the issues folks have been having because of forge author I've
relaxed the restriction some. Registered users may 'Forge Author' now,
but this is honestly non-optimal. People should not be repushing changes
that they did not author. The only time that's really a proper option is
when a committer forces a rebase of a patch via the gerrit UI.

Which brings us to git-review, when using it it will detect if you're
trying to push an entire patch set and ask if you really want to do
that, it should also allow you to indicate that you only want to push
certain patches out of the set (though it's a feature I myself never use
as I usually only work a single patch at a time of a series on a
particular topic)

For those that are trying to figure out what these 'forge author' or
'forge committer' rights that we keep talking about in gerrit are, it
breaks down as follows:

A git commit has an author and a committer. Both pieces are stored in
the metadata and in the case of the author, also partly in the commit
message.

The committer is the one who actually pushes the submission to git. The
author is the one that the commit is attributed to. Gerrit takes this
one step further with the requirement of Signed-off-by lines. If the
Signed-off-by line does not match the author it gets rejected.

Enabling 'forge author' allows someone to submit code where the
signed-off-by line does not match the authorship of the code and
additionally, where the one committing the code does not match the
authorship.

'forge committer' (which was only available to committers during the
initial repository load in) allows anyone with the right to push code
that they did not actually commit to the repo. This is useful primarily
in history imports, but occasionally useful for automated processes
(jenkins) that do automatic version bumping, tagging and branching.

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation

?
signature.asc

Re: Build fails when the sdk is not installed in the default path in Archlinux.

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install directory?

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis
8481 - 8500 of 8570