1. devel@lists.zephyrproject.org
  2. Messages
   Date   
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
Re: Zephyr SDK v0.7.2 - "rm -rf /"

Mads Kristiansen <mads.kristiansen@...>
 

Yes, this is probably what happened :)

On 15/03/16 23:05, "Anderson Lizardo" <anderson.lizardo(a)gmail.com> wrote:

Hi Mads,

On Mon, Mar 14, 2016 at 10:15 PM, Mads Kristiansen
<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).
I was curious on how this could happen. So I unpacked the installer
script (using "--noexec --target somedir --keep options") and looked
at setup.sh. This seems the most relevant snippet:

...
if [ -d $target_sdk_dir ]; then
# If the directory exists, test for write permission
if [ ! -w $target_sdk_dir ] ; then
echo "No permission, please run as 'sudo'"
exit 1
else
# wipe the directory first
read_confirm
if [ "$confirm" = "y" -o "$confirm" = "Y" ]; then
rm -rf $target_sdk_dir/*
else
# Abort the installation
echo "SDK installation aborted!"
exit 1
fi
fi
else
...

The "read_confirm" function should have warned you that the directory
you provided (which I assume was some important directory such as /usr
or even /) was about to be removed:

...
# Read the input "y"
read_confirm () {
echo "The existing directory $target_sdk_dir will be removed! "
if [ "$confirm" != "y" ]; then
echo "Do you want to continue (y/n)? "
while read confirm; do
[ "$confirm" = "Y" -o "$confirm" = "y" -o "$confirm" = "n" \
-o "$confirm" = "N" ] && break
echo "Invalid input \"$confirm\", please input 'y' or 'n': "
done
else
echo
fi
}
...

My opinion is that given the installation script requires wiping the
existing target directory, it would be wise to either blacklist
important directories (/ /usr etc.) or simply exit with failure if the
target directory exists (safest option in my opinion, due to the point
below).

There is the possibility that the read bash function captures buffered
input data prior to the prompt (e.g. if the user unknowingly typed "y"
while the script was unpacking), which is very dangerous in this case.

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.
Best Regards,
--
Anderson Lizardo
Re: FRDM-K64 GPIO driver name

Anders Dam Kofoed <adk@...>
 

Hi idups

Yes, I do see flashing tx lights on the board when typing something in the "screen /dev/ttyACM0". I have also tried all possible options in the "make menuconfig" but with no luck.
Regarding the pinmix driver. I see that there's an entry for the K20 but nothing for the K6x? Even in the include/drivers/k6x_ files. This is the pcr for K20:
zephyr-project/include/drivers/k20_pcr.h

Kind regards
Anders
Re: FRDM-K64 GPIO driver name

Anders Dam Kofoed <adk@...>
 

Hi Maureen,

Thanks for taking the time.

I am not sure how I would set the PORTB_PCR[22] as an output (red led). I have tried a few things including looking at outdir/.config and changing the driver to
#define GPIO_DRV_NAME CONFIG_PINMUX_K64_GPIO_B_NAME

Also including setting CONFIG_PINMUX_K64=y and CONFIG_PINMUX=y in prj.conf. Still; no output on the console. I've been through all the settings in the "make menuconfig" and nothing seems to help. And yes, I do see flashing tx lights on the board when typing something in the "screen /dev/ttyACM0".
Kind regards
Anders
Re: RFC: Change returning type from Pinmux APIs

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

Short version +1

-----Original Message-----
From: Andre Guedes [mailto:andre.guedes(a)intel.com]
Sent: Tuesday, March 15, 2016 2:58 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] RFC: Change returning type from Pinmux APIs

Hi all,

While I was working on the errno transition patchset, I realized all driver
APIs (i2c, spi, gpio, etc.) return 'int' type, but pinmux APIs. For the sake
of consistency, I think we should change the returning type from 'uint32_t'
to 'int' in include/pinmux.h APIs.
Another case of history and not properly updating the API after it has changed. Nice find.

Besides keeping consistency between all drivers APIs, this change would also
be aligned with the errno.h code transition we're discussing in the other
thread. Pinmux drivers will return negative errno.h codes in case of error
so returning 'int' is more suitable than 'uint32_t'.

I sent a patch [1] as draft so you can have a idea of the changes required
(basically, API and drivers).

This change conflicts with the pinmux patchset from Vinicius. We talked
offline and we are both fine to whatever patch gets merged first.
Good.


Regards,

Andre

[1] https://gerrit.zephyrproject.org/r/#/c/881/
RFC: Change returning type from Pinmux APIs

Andre Guedes <andre.guedes@...>
 

Hi all,

While I was working on the errno transition patchset, I realized all driver
APIs (i2c, spi, gpio, etc.) return 'int' type, but pinmux APIs. For the sake
of consistency, I think we should change the returning type from 'uint32_t'
to 'int' in include/pinmux.h APIs.

Besides keeping consistency between all drivers APIs, this change would also
be aligned with the errno.h code transition we're discussing in the other
thread. Pinmux drivers will return negative errno.h codes in case of error
so returning 'int' is more suitable than 'uint32_t'.

I sent a patch [1] as draft so you can have a idea of the changes required
(basically, API and drivers).

This change conflicts with the pinmux patchset from Vinicius. We talked
offline and we are both fine to whatever patch gets merged first.

Regards,

Andre

[1] https://gerrit.zephyrproject.org/r/#/c/881/
Re: FRDM-K64 GPIO driver name

Idupsle <idupsle@...>
 

Hey Marueen,
I'm wondering now, because I've searched for the multiplex-lib for the K64
and found nothing (But for the arduinos). So I thought: only the first
function of every pin/port is accessable. And configuring single Pins
impossible as long as some kernel defined global Variable for set_by_pins =
0. (Can't remember the exact name).
Where is the source code for the K64? Thanks :)

On Tue, Mar 15, 2016 at 9:57 PM, Maureen Helm <maureen.helm(a)nxp.com> wrote:

Hi Anders,
I took a quick look and ran your code, and it appears that the pinmux for
PTB22 is not configured correctly. The register field PORTB_PCR[MUX] is set
to 0 when it should be set to 1. You should be able to fix this by pulling
in the pinmux driver and changing the pin to function 1.
Maureen

-----Original Message-----
From: Anders Dam Kofoed [mailto:adk(a)accipio.dk]
Sent: Tuesday, March 15, 2016 5:20 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: FRDM-K64 GPIO driver name

Hi Thomasz,

Yesterday I tried with the following source code - but nothing happens :(
Nothing blinks. I programming it by copying the outdir/zephyr.bin onto
the
MBED folder. The board seems to "eat" it as it should but nothing
happens -
even after a reset.

GPIO out pin is Port B pin 22. Input is port B pin 9.
What puzzels me the most is that I do not get ANY debug output on the
console (screen /dev/ttyACM0 in Linux). I'd really like it to just show
a sign of
life...

--- prj.conf ---
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_NANO_TIMERS=y
CONFIG_NANO_TIMEOUTS=y
CONFIG_GPIO=y

---------------
--- main.c ---
#include <zephyr.h>
#include <device.h>
#include <gpio.h>
#include <sys_clock.h>


#if defined(CONFIG_STDOUT_CONSOLE)
#include <stdio.h>
#define PRINT printf
#else
#include <misc/printk.h>
#define PRINT printk
#endif

#define SLEEPTICKS SECONDS(1)

#define GPIO_OUT_PIN 22
#define GPIO_INT_PIN 9
#define GPIO_NAME "GPIO_"
#define GPIO_DRV_NAME CONFIG_GPIO_K64_B_DEV_NAME

void gpio_callback(struct device *port, uint32_t pin) {
PRINT(GPIO_NAME "%d triggered\n", pin); }


void main(void)
{
PRINT("Hello World!\n");
printf("Hello World!\n");

struct nano_timer timer;
void *timer_data[1];
struct device *gpio_dev;
int ret;
int toggle = 0;

nano_timer_init(&timer, timer_data);

gpio_dev = device_get_binding(GPIO_DRV_NAME);
if (!gpio_dev) {
PRINT("Cannot find %s!\n", GPIO_DRV_NAME);
}

/* Setup GPIO output */
ret = gpio_pin_configure(gpio_dev, GPIO_OUT_PIN,
(GPIO_DIR_OUT));
if (ret) {
PRINT("Error configuring " GPIO_NAME "%d!\n",
GPIO_OUT_PIN);
}

/* Setup GPIO input, and triggers on rising edge. */
ret = gpio_pin_configure(gpio_dev, GPIO_INT_PIN,
(GPIO_DIR_IN | GPIO_INT | GPIO_INT_EDGE
| GPIO_INT_ACTIVE_HIGH | GPIO_INT_DEBOUNCE));
if (ret) {
PRINT("Error configuring " GPIO_NAME "%d!\n",
GPIO_INT_PIN);
}

ret = gpio_set_callback(gpio_dev, gpio_callback);
if (ret) {
PRINT("Cannot setup callback!\n");
}

ret = gpio_pin_enable_callback(gpio_dev, GPIO_INT_PIN);
if (ret) {
PRINT("Error enabling callback!\n");
}

while (1) {
PRINT("Toggling " GPIO_NAME "%d\n", GPIO_OUT_PIN);

ret = gpio_pin_write(gpio_dev, GPIO_OUT_PIN, toggle);
if (ret) {
PRINT("Error set " GPIO_NAME "%d!\n",
GPIO_OUT_PIN);
}

if (toggle) {
toggle = 0;
} else {
toggle = 1;
}

nano_timer_start(&timer, SLEEPTICKS);
nano_timer_test(&timer, TICKS_UNLIMITED);
}


}

?
attachment.html

Re: FRDM-K64 GPIO driver name

Maureen Helm
 

Hi Anders,
I took a quick look and ran your code, and it appears that the pinmux for PTB22 is not configured correctly. The register field PORTB_PCR[MUX] is set to 0 when it should be set to 1. You should be able to fix this by pulling in the pinmux driver and changing the pin to function 1.
Maureen

-----Original Message-----
From: Anders Dam Kofoed [mailto:adk(a)accipio.dk]
Sent: Tuesday, March 15, 2016 5:20 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: FRDM-K64 GPIO driver name

Hi Thomasz,

Yesterday I tried with the following source code - but nothing happens :(
Nothing blinks. I programming it by copying the outdir/zephyr.bin onto the
MBED folder. The board seems to "eat" it as it should but nothing happens -
even after a reset.

GPIO out pin is Port B pin 22. Input is port B pin 9.
What puzzels me the most is that I do not get ANY debug output on the
console (screen /dev/ttyACM0 in Linux). I'd really like it to just show a sign of
life...

--- prj.conf ---
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_NANO_TIMERS=y
CONFIG_NANO_TIMEOUTS=y
CONFIG_GPIO=y

---------------
--- main.c ---
#include <zephyr.h>
#include <device.h>
#include <gpio.h>
#include <sys_clock.h>


#if defined(CONFIG_STDOUT_CONSOLE)
#include <stdio.h>
#define PRINT printf
#else
#include <misc/printk.h>
#define PRINT printk
#endif

#define SLEEPTICKS SECONDS(1)

#define GPIO_OUT_PIN 22
#define GPIO_INT_PIN 9
#define GPIO_NAME "GPIO_"
#define GPIO_DRV_NAME CONFIG_GPIO_K64_B_DEV_NAME

void gpio_callback(struct device *port, uint32_t pin) {
PRINT(GPIO_NAME "%d triggered\n", pin); }


void main(void)
{
PRINT("Hello World!\n");
printf("Hello World!\n");

struct nano_timer timer;
void *timer_data[1];
struct device *gpio_dev;
int ret;
int toggle = 0;

nano_timer_init(&timer, timer_data);

gpio_dev = device_get_binding(GPIO_DRV_NAME);
if (!gpio_dev) {
PRINT("Cannot find %s!\n", GPIO_DRV_NAME);
}

/* Setup GPIO output */
ret = gpio_pin_configure(gpio_dev, GPIO_OUT_PIN,
(GPIO_DIR_OUT));
if (ret) {
PRINT("Error configuring " GPIO_NAME "%d!\n",
GPIO_OUT_PIN);
}

/* Setup GPIO input, and triggers on rising edge. */
ret = gpio_pin_configure(gpio_dev, GPIO_INT_PIN,
(GPIO_DIR_IN | GPIO_INT | GPIO_INT_EDGE
| GPIO_INT_ACTIVE_HIGH | GPIO_INT_DEBOUNCE));
if (ret) {
PRINT("Error configuring " GPIO_NAME "%d!\n",
GPIO_INT_PIN);
}

ret = gpio_set_callback(gpio_dev, gpio_callback);
if (ret) {
PRINT("Cannot setup callback!\n");
}

ret = gpio_pin_enable_callback(gpio_dev, GPIO_INT_PIN);
if (ret) {
PRINT("Error enabling callback!\n");
}

while (1) {
PRINT("Toggling " GPIO_NAME "%d\n", GPIO_OUT_PIN);

ret = gpio_pin_write(gpio_dev, GPIO_OUT_PIN, toggle);
if (ret) {
PRINT("Error set " GPIO_NAME "%d!\n",
GPIO_OUT_PIN);
}

if (toggle) {
toggle = 0;
} else {
toggle = 1;
}

nano_timer_start(&timer, SLEEPTICKS);
nano_timer_test(&timer, TICKS_UNLIMITED);
}


}
Re: FRDM-K64 GPIO driver name

Carlos Carrizosa <c.carrizosa@...>
 

Hi,
I don't know what's happening with your UART but regarding the GPIO, I think
the problem is K64 gpio driver doesn't configure the pin as GPIO when you
call the gpio_pin_configure function.
I got the same problem and applying the next patch solve it to me:

diff --git a/drivers/gpio/gpio_k64.c b/drivers/gpio/gpio_k64.c
index 2d6a355..011eb52 100644
--- a/drivers/gpio/gpio_k64.c
+++ b/drivers/gpio/gpio_k64.c
@@ -111,6 +111,9 @@ static int gpio_k64_config(struct device *dev, int
access_op,
}
}

+ /* Ensure pin is configured as GPIO */
+ setting |= K64_PINMUX_FUNC_GPIO;
+
/* write pull-up/-down and, if set, interrupt configuration settings */

if (access_op == GPIO_ACCESS_BY_PIN) {

Regards,
Carlos Carrizosa

2016-03-15 20:43 GMT+01:00 idups idups <idupsle(a)gmail.com>:


I did copy it to the MBED Mount Point (Actual Firmware)...
Besides, I forgot that I played a little bit with the kernel-config, which isn't present in my prj.conf... but I'm sorry to say that I'm away from home until saturday. But I think if you look at the other examples in the Zephyr Project you'll get it to run. (Thats the way i fiddled it out)
Does the orange led on the usb-connection blink, if you type something in the tty-session?

On Tue, Mar 15, 2016 at 8:25 PM, Anders Dam Kofoed <adk(a)accipio.dk> wrote:

Hi,
I have tried your settings above and also with the following - but it still does not work:
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

I am using the latest firmware 226 and programming the board using the "copy" method. Programming seems to work fine judging from the way it usually reacts.

How are you programming the board?
Re: FRDM-K64 GPIO driver name

Idupsle <idupsle@...>
 

I did copy it to the MBED Mount Point (Actual Firmware)...
Besides, I forgot that I played a little bit with the kernel-config, which
isn't present in my prj.conf... but I'm sorry to say that I'm away from
home until saturday. But I think if you look at the other examples in
the Zephyr Project you'll get it to run. (Thats the way i fiddled it out)
Does the orange led on the usb-connection blink, if you type something in
the tty-session?

On Tue, Mar 15, 2016 at 8:25 PM, Anders Dam Kofoed <adk(a)accipio.dk> wrote:

Hi,
I have tried your settings above and also with the following - but it
still does not work:
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

I am using the latest firmware 226 and programming the board using the
"copy" method. Programming seems to work fine judging from the way it
usually reacts.

How are you programming the board?

?
attachment.html

Re: FRDM-K64 GPIO driver name

Anders Dam Kofoed <adk@...>
 

Hi,
I have tried your settings above and also with the following - but it still does not work:
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

I am using the latest firmware 226 and programming the board using the "copy" method. Programming seems to work fine judging from the way it usually reacts.

How are you programming the board?
Re: Zephyr SDK v0.7.2 - "rm -rf /"

Mads Kristiansen <mkristian@...>
 

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
To: mkristian(a)outlook.com
Date: Tue, 15 Mar 2016 15:13:12 +0000
CC: 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> 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

?
attachment.html

build zephyr failed

ZhangLei <ezio_zhang@...>
 

I have installed gcc,g++,and sdk , the environment shows that :
ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdkOLDPWD=/shrd/microkernelZEPHYR_BASE=/shrd/zephyrPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/shrd/zephyr/scriptsPWD=/shrd/microkernelSHLVL=2HOME=/rootZEPHYR_GCC_VARIANT=zephyrLESSOPEN=| /usr/bin/lesspipe %sLESSCLOSE=/usr/bin/lesspipe %s %s_=/usr/bin/envLOGNAME=rootARCH=x86

When I build a application (do as https://www.zephyrproject.org/doc/application/application.html ), it failed and shows these :
make[1]: Entering directory `/shrd/zephyr'make[2]: /opt/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/i586-poky-elf/i586-poky-elf-gcc: Command not foundmake[2]: Entering directory `/shrd/microkernel/outdir'make[2]: /opt/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/i586-poky-elf/i586-poky-elf-gcc: Command not found Using /shrd/zephyr as source for kernel /shrd/zephyr is not clean, please run 'make mrproper' in the '/shrd/zephyr' directory.make[2]: *** [prepare3] Error 1make[2]: Leaving directory `/shrd/microkernel/outdir'make[1]: *** [sub-make] Error 2make[1]: Leaving directory `/shrd/zephyr'make: *** [all] Error 2
How to solve this error ?

?
attachment.html

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

Nashif, Anas
 

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> 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
FYI: Gerrit and JIRA are down

Nashif, Anas
 

Hi,
The issue has been reported and being addressed. Still not known what the issue is exactly :(

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

Anderson Lizardo <anderson.lizardo@...>
 

Hi Mads,

On Mon, Mar 14, 2016 at 10:15 PM, Mads Kristiansen
<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).
I was curious on how this could happen. So I unpacked the installer
script (using "--noexec --target somedir --keep options") and looked
at setup.sh. This seems the most relevant snippet:

...
if [ -d $target_sdk_dir ]; then
# If the directory exists, test for write permission
if [ ! -w $target_sdk_dir ] ; then
echo "No permission, please run as 'sudo'"
exit 1
else
# wipe the directory first
read_confirm
if [ "$confirm" = "y" -o "$confirm" = "Y" ]; then
rm -rf $target_sdk_dir/*
else
# Abort the installation
echo "SDK installation aborted!"
exit 1
fi
fi
else
...

The "read_confirm" function should have warned you that the directory
you provided (which I assume was some important directory such as /usr
or even /) was about to be removed:

...
# Read the input "y"
read_confirm () {
echo "The existing directory $target_sdk_dir will be removed! "
if [ "$confirm" != "y" ]; then
echo "Do you want to continue (y/n)? "
while read confirm; do
[ "$confirm" = "Y" -o "$confirm" = "y" -o "$confirm" = "n" \
-o "$confirm" = "N" ] && break
echo "Invalid input \"$confirm\", please input 'y' or 'n': "
done
else
echo
fi
}
...

My opinion is that given the installation script requires wiping the
existing target directory, it would be wise to either blacklist
important directories (/ /usr etc.) or simply exit with failure if the
target directory exists (safest option in my opinion, due to the point
below).

There is the possibility that the read bash function captures buffered
input data prior to the prompt (e.g. if the user unknowingly typed "y"
while the script was unpacking), which is very dangerous in this case.

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.
Best Regards,
--
Anderson Lizardo
Some emails from devel mailing list does arrive to my inbox

Yannis Damigos
 

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
Re: [RFC] GPIO API changes

Tomasz Bursztyka
 

Hi Vinicius,

Another issue of the current API is the confusion caused by
'gpio_port_enable_callback()' and 'gpio_pin_enable_callback()'.

With the changes proposed later in this thread, you could have a
unified call:
'gpio_enable_callback(struct device *port, uint32_t pinmask)' (or something like it)
gpio_port_callback() make the callback called, whatever pins is
triggering the interrupt and enabled or not (callback wise).
So they are different (documentation could be better though)
I am just wondering that in the "old" API '_port_enable_callback()' was
a way to have the callback called with the pins expressed in a bitmask,
now the same behaviour can be achieved by running
'_pin_enable_callback(port, 0xffffffff)'. Just saying that, with the new
API, '_port_enable_callback()' adds little value.
Rethinking about that, while doing the proper patch-set. You've got good
point.
I am making it useless if the user has not set a callback through
gpio_set_callback()
(old way of doing, for a unique callback on the whole port)

Thanks,

Tomasz
Re: FRDM-K64 GPIO driver name

Idupsle <idupsle@...>
 

Hi, Reffering to my post in users, I wasn't successfully activating the
LEDs, but I got the debug output. See below

--- prj.conf ---
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_NANO_TIMERS=y
CONFIG_NANO_TIMEOUTS=y
CONFIG_GPIO=y
I've following settings:
CONFIG_ARM=y
CONFIG_SOC_FSL_FRDM_K64F=y
CONFIG_BOARD_FRDM_K64F=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_CORTEX_M_SYSTICK=y
CONFIG_UART_K20=y

Now the printk/f should be to uart.


Nevertheless, I tried NXP's MQX. There I found, that activating
the LED was done by setting the output of the Pin to one and then to zero.
Maybe thats the way it is done since the cathode is, reffering to the manual,
on the processor side.
8161 - 8180 of 8521