Date   

Re: RFC: 1/5 Consistent naming of PM Kconfig flags (Revised)

Thomas, Ramesh
 

[Revised incorporating feedbacks so far]

Problem Statement:
Power management Kconfig flags are not consistent and hierarchy is not
clear

Why this is a problem:
-----------------------------
The names include terms like “ADVANCED” which are not meaningful to
current implementation. Names do not specifically identify features that
are enabled by the flag. There are redundancies and overlaps in flags
and the hierarchy is not clear.

What should be done:
------------------------------
Change as follows :

ADVANCED_POWER_MANAGEMENT -> SYS_POWER_MANAGEMENT (turn on the basics
of power management)

ADVANCED_IDLE -> SYS_POWER_LPS (enables the kernel
for Low power state)
-> SYS_POWER_DEEP_SLEEP (enables the kernel for
Deep Sleep)

New addition -> DEVICE_POWER_MANAGEMENT (enables device power
management infrastructure)

ADVANCED_IDLE_SUPPORTED -> SYS_POWER_LPS_SUPPORTED (enables
SYS_POWER_LPS option)
-> SYS_POWER_DEEP_SLEEP_SUPPORTED (enables
SYS_POWER_DEEP_SLEEP option)

The new flags with the dependency hierarchy will be as follows:

SYS_POWER_MANAGEMENT
|
|___SYS_POWER_LPS
|
|___SYS_POWER_DEEP_SLEEP
|
|___DEVICE_POWER_MANAGEMENT


STM32/STM32F1 patchset v13

Maciek Borzecki <maciek.borzecki@...>
 

Hi,

I have posted version 13 of the patchset. As usual the series is
avaialable in my github repo https://github.com/bboozzoo/zephyr/ in
branch bboozzoo/stm32f10x-for-upstream-v13.

Changelog
=========

- addressed cosmetic comments

- updated pinmux driver to use struct pin_config instead of a custom
wrapper

- added support for HSE (high speed external oscillator) as clock
input for PLL or directly for SYSCLK, this allows for using much
higher SYSCLK values, up to 72MHz

- added register mapping for embedded flash controller; this change is
required by HSE and higher SYSCLK support, as flash access latency
needs to be configured for higher values of system clock

- svc_handler unaligned access fix; I would like to ask ARM experts to
look at this change, by no means I consider myself such expert. The
problem was identified when running latency benchmarks. The
benchmarks enable IRQ offloading, what enables previously unused
code paths in svc_handler. When the code attempts to access svc
parameter (which is not 4 byte aligned), unaligned access exception
occurs.


New Changes:
https://gerrit.zephyrproject.org/r/966 soc/stm32f1: add embedded
flash registers mapping
https://gerrit.zephyrproject.org/r/967 clock_control/stm32f1: HSE
support and PLL configuration cleanup
https://gerrit.zephyrproject.org/r/968 arm: access svc instruction
using halfword load in svc_handler


Updated Changes:
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32: add driver for
STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/drivers/disco: add
'disco' sample program
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new
board
https://gerrit.zephyrproject.org/r/915 soc/stm32f1: add IRQ numbers
listing
https://gerrit.zephyrproject.org/r/916 serial/stm32: add support for
IRQ APIs
https://gerrit.zephyrproject.org/r/917
interupt_controller/stm32_exti: driver for STM32 EXTI controller
https://gerrit.zephyrproject.org/r/918 gpio/stm32: GPIO input with
interrupts
https://gerrit.zephyrproject.org/r/919 soc/stm32f1: AFIO registers
mapping
https://gerrit.zephyrproject.org/r/920 soc/stm32f1/gpio: implement
MCU specific GPIO input interrupt integration
https://gerrit.zephyrproject.org/r/921 watchdog/iwdg_stm32: add
driver for STM32 Independent Watchdog (IWDG)
https://gerrit.zephyrproject.org/r/922 samples/button: button input
example

Cheers,
--
Maciek Borzecki


Re: [PATCH 1/2] arc_timer: fix tickless idle

Desfarges, Simon <simon.desfarges@...>
 

Hello,
Thanks for the answer, I will review my copy.

BTW, the same test bench shows no jitter in the Quark TICK. So I would like to have the same behavior for ARC.
Do you think it is achievable ? I have doubts because of the fact that loapic decrements its counter (logic is reversed)
and looks to be safer.

See my [Simon] below.

-----Original Message-----
From: Mitsis, Peter [mailto:Peter.Mitsis(a)windriver.com]
Sent: Thursday, March 17, 2016 9:19 PM
To: Desfarges, Simon <simon.desfarges(a)intel.com>;
devel(a)lists.zephyrproject.org
Cc: Desfarges, Simon <simon.desfarges(a)intel.com>
Subject: RE: [devel] [PATCH 1/2] arc_timer: fix tickless idle

See [Peter]

-----Original Message-----
From: simon.desfarges(a)intel.com [mailto:simon.desfarges(a)intel.com]
Sent: March-17-16 2:42 PM
To: devel(a)lists.zephyrproject.org
Cc: DESFARGES, SIMON
Subject: [devel] [PATCH 1/2] arc_timer: fix tickless idle

From: Simon Desfarges <simon.desfarges(a)intel.com>

When exiting from tickless idle uppon an external IRQ, the TICK timer is
set to fire at next TICK boundary. The current algorithm can lead to a
point that timer0_count register is higher than the timer0_limit register.

In this situation the next TICK will fire after a full wrapp of the
counter
(~133 seconds).

This condition appears when the counter reaches the limit after the
Interrupt Pending flag is checked. At this point the counter is
automatically wrapped to 0, but is set just next the limit to fire at next
TICK boundary by SW.
At exit of the _timer_idle_exit function, the timer handler is called, and
sets the limit to 1 TICK. At this point the situation is:
- limit register == 1 TICK
- count register is just below the old limit register and higher than 1
TICK

To fix this issue, at _timer_idle_exit, the limit register is always set
to 1 TICK and the count register set such as the next TICK fires on time.

Change-Id: Ifa002809d426aa04109592e53d2b02a224f51101
Tracked-On: https://jira.ndg.intel.com/browse/FIRE-4213
Signed-off-by: Simon Desfarges <simon.desfarges(a)intel.com>
---
drivers/timer/arcv2_timer0.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/timer/arcv2_timer0.c b/drivers/timer/arcv2_timer0.c
index 932ceac..5fec988 100644
--- a/drivers/timer/arcv2_timer0.c
+++ b/drivers/timer/arcv2_timer0.c
@@ -220,7 +220,7 @@ void _timer_idle_enter(int32_t ticks)
}

programmed_ticks = ticks;
- programmed_limit = (programmed_ticks * cycles_per_tick);
+ programmed_limit = (programmed_ticks * cycles_per_tick) - 1;
[Peter]: Good catch on this off by one error.
[Simon] I will separate in another patch and try to make it merged asap so we can forget this point.

timer0_limit_register_set(programmed_limit);

@@ -276,9 +276,6 @@ void _timer_idle_exit(void)
* A non-timer interrupt occurred. Announce any
* ticks that have elapsed during the tickless idle.
*/
-
- uint32_t remaining_cycles = programmed_limit - current_count;
-
_sys_idle_elapsed_ticks = current_count / cycles_per_tick;
if (_sys_idle_elapsed_ticks > 0) {
update_accumulated_count();
@@ -289,11 +286,8 @@ void _timer_idle_exit(void)
* Ensure the timer will expire at the end of the next tick in case
* the ISR makes any tasks and/or fibers ready to run.
*/
-
- if (remaining_cycles >= cycles_per_tick) {
- timer0_count_register_set(programmed_limit -
- ((remaining_cycles - 1) % cycles_per_tick) - 1);
- }
+ timer0_limit_register_set(cycles_per_tick - 1);
+ timer0_count_register_set(timer0_count_register_get() %
+cycles_per_tick);
[Peter]:

First an historical note. The reason the original code only touched the count
register was that it was not known if lowering the limit register to a value
below that of the count register would trigger an interrupt. (I did not have
access to a board with the ARCv2 timer and so was unable to confirm or deny
that behavior.) That being said, if changing the limit value from a value higher
than the count to a value lower than the count does not generate an
interrupt, then I have no objections on that front.
[Simon] This is the case I experimented. The ISR is generated only if count == limit.


Second, Using timer0_count_register_get() at this point is a no-no as it
introduces a race condition that can cause us to lose track of a whole tick.
Remember, the timer is always counting. If the elapsed ticks were
announced just prior to a "tick boundary", the call to
timer0_count_register_set() could then occur just after the "tick boundary".
The result of this scenario is that nearly one whole tick may be lost when the
modulus operation is performed. This is why we use the <current_count>
retrieved from the start of _timer_idle_exit(). Yes, it does introduce some
gradual drift, but this can be ameliorated somewhat by only modifying the
count if there is more than one tick left in the tickles idle.
[Simon]
I especially call this function to limit this gradual drift. As far as I understand, in every point of this function,
it is possible to have a race condition or an overlap of the counter. The case where the counter overlaps
after checking the 'IP' bit and before setting the count register is handled, because the ISR will fire anyway
and 1 tick will be announced.

I see in the loapic timer there is a 'timer_known_to_have_expired' variable, handling this exact case,
I will take a look at it (I guess you already did it...).


Hope this helps.

}
#else
static void tickless_idle_init(void) {}
--
1.9.1


Re: [PATCH 1/2] arc_timer: fix tickless idle

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

See [Peter]

-----Original Message-----
From: simon.desfarges(a)intel.com [mailto:simon.desfarges(a)intel.com]
Sent: March-17-16 2:42 PM
To: devel(a)lists.zephyrproject.org
Cc: DESFARGES, SIMON
Subject: [devel] [PATCH 1/2] arc_timer: fix tickless idle

From: Simon Desfarges <simon.desfarges(a)intel.com>

When exiting from tickless idle uppon an external IRQ, the TICK timer is
set to fire at next TICK boundary. The current algorithm can lead to a
point that timer0_count register is higher than the timer0_limit register.

In this situation the next TICK will fire after a full wrapp of the
counter
(~133 seconds).

This condition appears when the counter reaches the limit after the
Interrupt Pending flag is checked. At this point the counter is
automatically wrapped to 0, but is set just next the limit to fire at next
TICK boundary by SW.
At exit of the _timer_idle_exit function, the timer handler is called, and
sets the limit to 1 TICK. At this point the situation is:
- limit register == 1 TICK
- count register is just below the old limit register and higher than 1
TICK

To fix this issue, at _timer_idle_exit, the limit register is always set
to 1 TICK and the count register set such as the next TICK fires on time.

Change-Id: Ifa002809d426aa04109592e53d2b02a224f51101
Tracked-On: https://jira.ndg.intel.com/browse/FIRE-4213
Signed-off-by: Simon Desfarges <simon.desfarges(a)intel.com>
---
drivers/timer/arcv2_timer0.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/timer/arcv2_timer0.c b/drivers/timer/arcv2_timer0.c
index 932ceac..5fec988 100644
--- a/drivers/timer/arcv2_timer0.c
+++ b/drivers/timer/arcv2_timer0.c
@@ -220,7 +220,7 @@ void _timer_idle_enter(int32_t ticks)
}

programmed_ticks = ticks;
- programmed_limit = (programmed_ticks * cycles_per_tick);
+ programmed_limit = (programmed_ticks * cycles_per_tick) - 1;
[Peter]: Good catch on this off by one error.

timer0_limit_register_set(programmed_limit);

@@ -276,9 +276,6 @@ void _timer_idle_exit(void)
* A non-timer interrupt occurred. Announce any
* ticks that have elapsed during the tickless idle.
*/
-
- uint32_t remaining_cycles = programmed_limit - current_count;
-
_sys_idle_elapsed_ticks = current_count / cycles_per_tick;
if (_sys_idle_elapsed_ticks > 0) {
update_accumulated_count();
@@ -289,11 +286,8 @@ void _timer_idle_exit(void)
* Ensure the timer will expire at the end of the next tick in case
* the ISR makes any tasks and/or fibers ready to run.
*/
-
- if (remaining_cycles >= cycles_per_tick) {
- timer0_count_register_set(programmed_limit -
- ((remaining_cycles - 1) % cycles_per_tick) - 1);
- }
+ timer0_limit_register_set(cycles_per_tick - 1);
+ timer0_count_register_set(timer0_count_register_get() %
+cycles_per_tick);
[Peter]:

First an historical note. The reason the original code only touched the count register was that it was not known if lowering the limit register to a value below that of the count register would trigger an interrupt. (I did not have access to a board with the ARCv2 timer and so was unable to confirm or deny that behavior.) That being said, if changing the limit value from a value higher than the count to a value lower than the count does not generate an interrupt, then I have no objections on that front.

Second, Using timer0_count_register_get() at this point is a no-no as it introduces a race condition that can cause us to lose track of a whole tick. Remember, the timer is always counting. If the elapsed ticks were announced just prior to a "tick boundary", the call to timer0_count_register_set() could then occur just after the "tick boundary". The result of this scenario is that nearly one whole tick may be lost when the modulus operation is performed. This is why we use the <current_count> retrieved from the start of _timer_idle_exit(). Yes, it does introduce some gradual drift, but this can be ameliorated somewhat by only modifying the count if there is more than one tick left in the tickles idle.

Hope this helps.

}
#else
static void tickless_idle_init(void) {}
--
1.9.1


Re: [PATCH 0/2] Arc tickless idle issue

Rodriguez, Sergio SF <sergio.sf.rodriguez@...>
 

Hi Simon,

The macro _sys_clock_tick_announce() call _nano_sys_clock_tick_announce(_sys_idle_elapsed_ticks), so _sys_idle_elapsed_ticks might off, can you check the value of _sys_idle_elapsed_ticks before every _sys_clock_tick_announce on the timer driver?, I think this line might be suspect on

drivers/timer/arcv2_timer0.c on the function _timer_idle_exit, look for the lines

uint32_t remaining_cycles = programmed_limit - current_count;

_sys_idle_elapsed_ticks = current_count / cycles_per_tick;
if (_sys_idle_elapsed_ticks > 0) {
update_accumulated_count();
_sys_clock_tick_announce();
}

The problem here is maybe _sys_idle_elapsed_ticks is going off,

also take a look at _timer_idle_exit when is coming off a timer interrupt,

if (control & _ARC_V2_TMR_CTRL_IP) {
/*
* The timer has expired. The handler _timer_int_handler() is
* guaranteed to execute. Track the number of elapsed ticks. The
* handler _timer_int_handler() will account for the final tick.
*/

_sys_idle_elapsed_ticks = programmed_ticks - 1;
update_accumulated_count();
_sys_clock_tick_announce();

return;
}

Is announcing the ticks minus one to all the timers (if any), so if no other interrupt happens (just the timer) the count will be fullfilled at the next tick, but if other interrupt happens and add more that one tick to _sys_idle_elapsed_ticks, that might set the timers with wrong count, so we have to revisit the non timer interrupt tick anounce


[PATCH 2/2] arc_timer: assert that counter always lower than limit

Desfarges, Simon <simon.desfarges@...>
 

From: Simon Desfarges <simon.desfarges(a)intel.com>

ASSERT are put each time the timer0 limit register or the timer0 count register
is modified.

Change-Id: I38684d57803de285f4e26c68b449c71396e4c750
Tracked-On: https://jira.ndg.intel.com/browse/FIRE-4213
Signed-off-by: Simon Desfarges <simon.desfarges(a)intel.com>
---
drivers/timer/arcv2_timer0.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)

diff --git a/drivers/timer/arcv2_timer0.c b/drivers/timer/arcv2_timer0.c
index 5fec988..705d120 100644
--- a/drivers/timer/arcv2_timer0.c
+++ b/drivers/timer/arcv2_timer0.c
@@ -60,6 +60,7 @@
#include <sys_clock.h>
#include <drivers/system_timer.h>
#include <stdbool.h>
+#include <misc/__assert.h>

/*
* A board support package's board.h header must provide definitions for the
@@ -173,6 +174,10 @@ void _timer_int_handler(void *unused)

#if defined(CONFIG_TICKLESS_IDLE)
timer0_limit_register_set(cycles_per_tick - 1);
+ __ASSERT_EVAL({},
+ uint32_t timer_count = timer0_count_register_get(),
+ timer_count <= (cycles_per_tick - 1),
+ "timer_count: %d, limit %d\n", timer_count, cycles_per_tick - 1);

_sys_idle_elapsed_ticks = 1;
#endif
@@ -233,6 +238,10 @@ void _timer_idle_enter(int32_t ticks)
if (status & _ARC_V2_TMR_CTRL_IP) {
straddled_tick_on_idle_enter = true;
}
+ __ASSERT_EVAL({},
+ uint32_t timer_count = timer0_count_register_get(),
+ timer_count <= programmed_limit,
+ "timer_count: %d, limit %d\n", timer_count, programmed_limit);
}

/*
@@ -250,6 +259,10 @@ void _timer_idle_exit(void)
if (straddled_tick_on_idle_enter) {
/* Aborting the tickless idle due to a straddled tick. */
straddled_tick_on_idle_enter = false;
+ __ASSERT_EVAL({},
+ uint32_t timer_count = timer0_count_register_get(),
+ timer_count <= programmed_limit,
+ "timer_count: %d, limit %d\n", timer_count, programmed_limit);
return;
}

@@ -269,6 +282,10 @@ void _timer_idle_exit(void)
update_accumulated_count();
_sys_clock_tick_announce();

+ __ASSERT_EVAL({},
+ uint32_t timer_count = timer0_count_register_get(),
+ timer_count <= programmed_limit,
+ "timer_count: %d, limit %d\n", timer_count, programmed_limit);
return;
}

@@ -288,6 +305,11 @@ void _timer_idle_exit(void)
*/
timer0_limit_register_set(cycles_per_tick - 1);
timer0_count_register_set(timer0_count_register_get() % cycles_per_tick);
+
+ __ASSERT_EVAL({},
+ uint32_t timer_count = timer0_count_register_get(),
+ timer_count <= (cycles_per_tick - 1),
+ "timer_count: %d, limit %d\n", timer_count, cycles_per_tick-1);
}
#else
static void tickless_idle_init(void) {}
--
1.9.1


[PATCH 1/2] arc_timer: fix tickless idle

Desfarges, Simon <simon.desfarges@...>
 

From: Simon Desfarges <simon.desfarges(a)intel.com>

When exiting from tickless idle uppon an external IRQ, the TICK timer is set
to fire at next TICK boundary. The current algorithm can lead to a point that
timer0_count register is higher than the timer0_limit register.

In this situation the next TICK will fire after a full wrapp of the counter
(~133 seconds).

This condition appears when the counter reaches the limit after the Interrupt
Pending flag is checked. At this point the counter is automatically wrapped to
0, but is set just next the limit to fire at next TICK boundary by SW.
At exit of the _timer_idle_exit function, the timer handler is called, and sets
the limit to 1 TICK. At this point the situation is:
- limit register == 1 TICK
- count register is just below the old limit register and higher than 1 TICK

To fix this issue, at _timer_idle_exit, the limit register is always set to 1 TICK and
the count register set such as the next TICK fires on time.

Change-Id: Ifa002809d426aa04109592e53d2b02a224f51101
Tracked-On: https://jira.ndg.intel.com/browse/FIRE-4213
Signed-off-by: Simon Desfarges <simon.desfarges(a)intel.com>
---
drivers/timer/arcv2_timer0.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/timer/arcv2_timer0.c b/drivers/timer/arcv2_timer0.c
index 932ceac..5fec988 100644
--- a/drivers/timer/arcv2_timer0.c
+++ b/drivers/timer/arcv2_timer0.c
@@ -220,7 +220,7 @@ void _timer_idle_enter(int32_t ticks)
}

programmed_ticks = ticks;
- programmed_limit = (programmed_ticks * cycles_per_tick);
+ programmed_limit = (programmed_ticks * cycles_per_tick) - 1;

timer0_limit_register_set(programmed_limit);

@@ -276,9 +276,6 @@ void _timer_idle_exit(void)
* A non-timer interrupt occurred. Announce any
* ticks that have elapsed during the tickless idle.
*/
-
- uint32_t remaining_cycles = programmed_limit - current_count;
-
_sys_idle_elapsed_ticks = current_count / cycles_per_tick;
if (_sys_idle_elapsed_ticks > 0) {
update_accumulated_count();
@@ -289,11 +286,8 @@ void _timer_idle_exit(void)
* Ensure the timer will expire at the end of the next tick in case
* the ISR makes any tasks and/or fibers ready to run.
*/
-
- if (remaining_cycles >= cycles_per_tick) {
- timer0_count_register_set(programmed_limit -
- ((remaining_cycles - 1) % cycles_per_tick) - 1);
- }
+ timer0_limit_register_set(cycles_per_tick - 1);
+ timer0_count_register_set(timer0_count_register_get() % cycles_per_tick);
}
#else
static void tickless_idle_init(void) {}
--
1.9.1


[PATCH 0/2] Arc tickless idle issue

Desfarges, Simon <simon.desfarges@...>
 

From: Simon Desfarges <simon.desfarges(a)intel.com>

Hello,

I am trying to enable the tickless idle of ARC in our project. Here is my
problem.

OS: Zephyr 1.0.0
Processor: Quark_se

The ARC TICK timer contains 2 registers: limit register and count register.
Count register is automatically incremented and when is equal to limit
register, an ISR is fired and count wraps to 0.

Trying to enable the tickless idle on Arc, I found that in some corner case
the limit register ends up to be smaller than the count register. So then, the
count register will wrap to 0 at UINT32_MAX value (~133 seconds), leading to a
very long TICK.

I managed to fix this problem (patch 1) and added plenty of assertions (patch 2,
used to debug, validate and understand the code).

TL;DR:

I still have a remaining issue: the TICK is no more regular. I have a small
jitter when the tickless idle is interrupted by an external event. To check I
set a timer expiring every 1000 ms, and I compute the time between 2 ISR using
the AON counter and using the OS Timer.

Here are my results:
Working case:
4574464|ARC| MAIN| INFO| timer 32767k, 1000ms, os: 1000
4575464|ARC| MAIN| INFO| timer 32767k, 1000ms, os: 1000
4576464|ARC| MAIN| INFO| timer 32767k, 1000ms, os: 1000
4577464|ARC| MAIN| INFO| timer 32767k, 1000ms, os: 1000
4578464|ARC| MAIN| INFO| timer 32767k, 1000ms, os: 1000
4579464|ARC| MAIN| INFO| timer 32767k, 1000ms, os: 1000

Here, the time between 2 Interrupts is always 1000ms (32767 ticks of the AON
counter, counting at 32768Hz). The 'os' value actually counts the elapsed
TICKs.

Tickless idle case:
4745475|ARC| MAIN| INFO| timer 32786k, 1001ms, os: 1000
4746476|ARC| MAIN| INFO| timer 32780k, 1000ms, os: 1000
4747476|ARC| MAIN| INFO| timer 32786k, 1001ms, os: 1000
4748476|ARC| MAIN| INFO| timer 32780k, 1000ms, os: 1000
4749477|ARC| MAIN| INFO| timer 32786k, 1001ms, os: 1000

Here, the time between 2 ISR may vary up to 1ms for 1000 ticks.

The issue appears only when there are external ISR (I shake the board, accel
sensor does the rest). So in the exact path I just changed :(

I do not understand from where does the issue comes from (yes, from my patch I
guess), so if a tickless guru can give me some hints, I may have missed an
obvious stuff...

Thank you very much !
Simon.

Simon Desfarges (2):
arc_timer: fix tickless idle
arc_timer: assert that counter always lower than limit

drivers/timer/arcv2_timer0.c | 32 ++++++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)

--
1.9.1


Re: STM32/STM32F1 patchset v10

Maciek Borzecki <maciek.borzecki@...>
 

Hi,

I've pushed another set of updates to the remaining STM32F1 patchset
(bboozzoo/stm32f10x-for-upstream-v11).

The aside from cosmetic cleanups and minor updates, the pinmux driver
was extended to address comments from Vinicius Costa Gomes. The pin
function configuration is currently declared upfront by the board
integration glue, and applied during pinmux driver
initialization. Board integrator is expected to provide implementation
of stm32_board_get_pinconf(), retuning an array of
(pin, alternate-function) tuples.

Updated Changes:
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32: add driver for
STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/drivers/disco: add
'disco' sample program
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new
board
https://gerrit.zephyrproject.org/r/915 soc/stm32f1: add IRQ numbers
listing
https://gerrit.zephyrproject.org/r/916 serial/stm32: add support for
IRQ APIs
https://gerrit.zephyrproject.org/r/917
interupt_controller/stm32_exti: driver for STM32 EXTI controller
https://gerrit.zephyrproject.org/r/918 gpio/stm32: GPIO input with
interrupts
https://gerrit.zephyrproject.org/r/919 soc/stm32f1: AFIO registers
mapping
https://gerrit.zephyrproject.org/r/920 soc/stm32f1/gpio: implement
MCU specific GPIO input interrupt integration
https://gerrit.zephyrproject.org/r/921 watchdog/iwdg_stm32: add
driver for STM32 Independent Watchdog (IWDG)
https://gerrit.zephyrproject.org/r/922 samples/button: button input
example

Cheers,
--
Maciek Borzecki


Re: Lost access to Zephyr git and gerrit

Pawel Wodnicki <root@...>
 

Hi Yannis,

It worked!
Looks like I have followed instructions a little too close :-)
Thanks for pointing the problem.

Pawel


Re: Lost access to Zephyr git and gerrit

Yannis Damigos
 

Hi Pawel,

Adding my username before the gerrit.zephyrproject.org worked for me.
The command should be like this (where 'username' your username):
~$ scp -p -P 29418 username(a)gerrit.zephyrproject.org:hooks/commit-msg
.git/hooks/

Yannis

On Thu, Mar 17, 2016 at 8:21 AM, Pawel Wodnicki <root(a)32bitmicro.com> wrote:
Hi,

I am experiencing problems with access to Zephyr sites.
I can no longer login into Zephyr gerrit :-(
I have checked my linuxfoundation.org login and it only works from Firefox, I can not login from Chrome, strange.

I can clone and pull from git but when I try to setup hooks using scp I get Permission denied (publickey) see below.

pawel(a)dell-pw:/usr/local/src/zephyr/zephyr-project$ scp -p -P 29418 gerrit.zephyrproject.org:hooks/commit-msg .git/hooks/
Permission denied (publickey).


Is this a known problem?

Pawel


Lost access to Zephyr git and gerrit

Pawel Wodnicki <root@...>
 

Hi,

I am experiencing problems with access to Zephyr sites.
I can no longer login into Zephyr gerrit :-(
I have checked my linuxfoundation.org login and it only works from Firefox, I can not login from Chrome, strange.

I can clone and pull from git but when I try to setup hooks using scp I get Permission denied (publickey) see below.

pawel(a)dell-pw:/usr/local/src/zephyr/zephyr-project$ scp -p -P 29418 gerrit.zephyrproject.org:hooks/commit-msg .git/hooks/
Permission denied (publickey).


Is this a known problem?

Pawel


Re: Some emails from devel mailing list does arrive to my inbox

Yannis Damigos
 

On 03/16/2016 10:51 PM, Maciek Borzecki wrote:
On Wed, Mar 16, 2016 at 9:49 PM, Yannis Damigos
<giannis.damigos(a)gmail.com> wrote:
On 03/15/2016 03:48 PM, Yannis Damigos wrote:
Hi everyone,

is it just me or everyone does not receive some emails to their inbox
from the devel mailing list?

For example I did not receive any email for the threads:
[RFC] GPIO API changes
FRDM-K64 GPIO driver name
Zephyr SDK v0.7.2 - "rm -rf /"

If someone posts something to the devel mailing list using the web
GUI, do you receive an email?

Best regards,
Yannis
Could someone, please, help me to find out if I am the only one,
who does not receive emails from the devel mailing list.

I did not receive anything to my inbox for threads which were
created the last 6 hours:

STM32/STM32F1 patchset v10
This one was sent using gmail web client.

SPI on the FRDM-K64F
FRDM-K64 PRINT not working

Did the authors of these threads used the web GUI to post them?

Best regards,
Yannis

Cheers,
Thank you Maciek for your reply.
The mail delivery option of the devel list in my account was disabled.
I just enabled it and I will wait to see if this will fix the issue.

Yannis


Re: Some emails from devel mailing list does arrive to my inbox

Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 16, 2016 at 9:49 PM, Yannis Damigos
<giannis.damigos(a)gmail.com> wrote:
On 03/15/2016 03:48 PM, Yannis Damigos wrote:
Hi everyone,

is it just me or everyone does not receive some emails to their inbox
from the devel mailing list?

For example I did not receive any email for the threads:
[RFC] GPIO API changes
FRDM-K64 GPIO driver name
Zephyr SDK v0.7.2 - "rm -rf /"

If someone posts something to the devel mailing list using the web
GUI, do you receive an email?

Best regards,
Yannis
Could someone, please, help me to find out if I am the only one,
who does not receive emails from the devel mailing list.

I did not receive anything to my inbox for threads which were
created the last 6 hours:

STM32/STM32F1 patchset v10
This one was sent using gmail web client.

SPI on the FRDM-K64F
FRDM-K64 PRINT not working

Did the authors of these threads used the web GUI to post them?

Best regards,
Yannis

Cheers,
--
Maciek Borzecki


Re: Some emails from devel mailing list does arrive to my inbox

Yannis Damigos
 

On 03/15/2016 03:48 PM, Yannis Damigos wrote:
Hi everyone,

is it just me or everyone does not receive some emails to their inbox
from the devel mailing list?

For example I did not receive any email for the threads:
[RFC] GPIO API changes
FRDM-K64 GPIO driver name
Zephyr SDK v0.7.2 - "rm -rf /"

If someone posts something to the devel mailing list using the web
GUI, do you receive an email?

Best regards,
Yannis
Could someone, please, help me to find out if I am the only one,
who does not receive emails from the devel mailing list.

I did not receive anything to my inbox for threads which were
created the last 6 hours:

STM32/STM32F1 patchset v10
SPI on the FRDM-K64F
FRDM-K64 PRINT not working

Did the authors of these threads used the web GUI to post them?

Best regards,
Yannis


Re: FRDM-K64 PRINT not working

Anders Dam Kofoed <adk@...>
 

Does anyone have a working working zephyr.bin for the FRDM-K64 board where printf/k is working? I'd like to see if it would work on mine.
Kind regards
Anders


SPI on the FRDM-K64F

Corey Williamson <corey.bailey.williamson@...>
 

Hi,

I'm looking to use the spi interface on the FRDM-K64f board, is there a
driver for that? Or alternatively, is it all right for for me to change
and mess with the clock settings for the board? Will that interfere with
the timing of the RTOS?

Thanks,

Corey Williamson


STM32/STM32F1 patchset v10

Maciek Borzecki <maciek.borzecki@...>
 

Hi all,

I've published version 10 of the patchset adding STM32/STM32F1
support. I will update the series once Anas merges his arch/arm/soc
tree layout changes.

The code is also available here in branch
bboozzoo/stm32f10x-for-upstream-v10 in github repo:

https://github.com/bboozzoo/zephyr/

Changelog
=========

- added a common STM32 driver for Independent Watchdog (IWDG)

- added a common STM32 driver for External Interupt/Event Controller
(EXTI). This is particularly useful as it enables support for
interrupts on input GPIO lines. Having this, it is possible to start
working on drivers for I2C and SPI devices.

- updated initla GPIO patches with support for GPIO input

- added GPIO input interrupt triggers

- support for interrupt driven UART communication. This way we can
finally run the 'shell' sample demo

- updated board configs to match current master

- updated Nucleo-F103RB board config to enable UART console on USART1
port. This allows for using the serial console avaialble on the
STLink v2-1 USB connector (usually /dev/ttyACMx in the host system)

- a sample 'button' demo for showcasing GPIO input with interrupts

Other
=====

The following patches are independent and can be directly merged to
master:

clock_control: extend API with clock rate query operation
clock_control/Kconfig: move quark_se entries to separate file


Gerrit log
==========

New Changes:
https://gerrit.zephyrproject.org/r/915 soc/stm32f1: add IRQ numbers
listing
https://gerrit.zephyrproject.org/r/916 serial/stm32: add support for
IRQ APIs
https://gerrit.zephyrproject.org/r/917
interupt_controller/stm32_exti: driver for STM32 EXTI controller
https://gerrit.zephyrproject.org/r/918 gpio/stm32: GPIO input with
interrupts
https://gerrit.zephyrproject.org/r/919 soc/stm32f1: AFIO registers
mapping
https://gerrit.zephyrproject.org/r/920 soc/stm32f1/gpio: implement
MCU specific GPIO input interrupt integration
https://gerrit.zephyrproject.org/r/921 watchdog/iwdg_stm32: add
driver for STM32 Independent Watchdog (IWDG)
https://gerrit.zephyrproject.org/r/922 samples/button: button input
example

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce driver for STM32F10x RCC
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver
for STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/drivers/disco: add
'disco' sample program
https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move
quark_se entries to separate file
https://gerrit.zephyrproject.org/r/712 clock_control: extend API
with clock rate query operation
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new
board



Cheers,
--
Maciek Borzecki


Re: [RFC] GPIO API changes

Tomasz Bursztyka
 

Hi,

I sent a draft on gerrit:

https://gerrit.zephyrproject.org/r/#/c/914/

I kept enable/disable pin/port functions but the actual code in the driver
is slightly different.

So basically the real change are:
- gpio_callback_t is meant to be deprecated
- struct gpio_callback is the new way of providing a callback

- gpio_set_callback() is meant to be deprecated
- gpio_register_callback()/gpio_unregister_callback() are new ways of
handling callbacks

The thing I am not too found about is _gpio_compat_register_instance().
If there is another way, and seamless one even, would be nice.

Tomasz


Re: Zephyr SDK v0.7.2 - "rm -rf /"

Poussa, Sakari
 

Hi,

I had the same issue earlier. I filed the bug which wasn’t able to save you, Mads.

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

I was lucky enough not to run it under root.

Sakari

From: Mads Kristiansen <mkristian(a)outlook.com<mailto:mkristian(a)outlook.com>>
Date: To: "Nashif, Anas" <anas.nashif(a)intel.com<mailto:anas.nashif(a)intel.com>>
Cc: "devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>" <devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>>
Subject: [devel] Re: Re: Zephyr SDK v0.7.2 - "rm -rf /"

Hi Anas,

Yes, that is correct. I was installing it on OSX. Cannot really give more details about what happened except that I pressed ctrl-C during the installation. It was the only shell I had open at that moment, so I am pretty sure it was caused by the SDK.

Best regards, Mads

From: anas.nashif(a)intel.com<mailto:anas.nashif(a)intel.com>
To: mkristian(a)outlook.com<mailto:mkristian(a)outlook.com>
Date: Tue, 15 Mar 2016 15:13:12 +0000
CC: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: Zephyr SDK v0.7.2 - "rm -rf /"

Mads,

Were you trying to install the SDK on Mac OS?
If yes, this issue will be addressed in the latest SDK drop which will be released today.


Anas

On 14 Mar 2016, at 22:15, Mads Kristiansen <mkristian(a)outlook.com<mailto:mkristian(a)outlook.com>> wrote:

I downloaded the Zephyr SDK v0.7.2 last night and tried to install it this morning on my MacBook.

During the installation, I cancelled with ctrl-C and somehow it seems to have executed a "rm -rf /" (as root).

Obviously my system wont boot now, so I cannot examine this further until I have it up and running again. Just a heads up and maybe someone should have a glance at the SDK to make sure noone else gets into the same situation.

/ Mads

7661 - 7680 of 8039