Date   

Re: FRDM-K64F GPIO

Maureen Helm
 

The gpio driver names are defined in drivers/gpio/Kconfig.mcux

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Kevin Stöckl
Sent: Friday, July 07, 2017 8:41 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] FRDM-K64F GPIO

 

Hello,

where did i get the GPIO_DRV_NAME for the FRDM-K64F Board?

 

Virenfrei. www.avast.com

 


FRDM-K64F GPIO

Kevin Stöckl <k_stoeckl@...>
 

Hello,

where did i get the GPIO_DRV_NAME for the FRDM-K64F Board?


Virenfrei. www.avast.com


Flash drivers compatibility attitude

Puzdrowski, Andrzej
 

In my opinion Flash driver API hasn’t well-defined common behavior. It could cause additional complexity in component added on top of flash driver because the incompatibility must be deferred at higher component level. I have 2 points:

 

1)      In dox of f. flash_write_protection_set is noted:

“Please note that on some flash components, the write protection is

*  automatically turned on again by the device after the completion of each

*  write or erase calls”

 

It is unwanted freedom because it is the driver API and hence it should provide abstraction over HW e.g write operation could perform a write of a long buffer despite that HW write is word-by-word operation so HW protect must be served by a such driver automatically and protection offered by this API should be the abstaraction over HW.

 

 

2)      Alignment and write granularity of F. flash_write:

there’s no dox regard how unaligned data should be treated. For instance the driver for nrf5x support 1 byte alignment and data size form 1B to N B. Other driver expected different alignment here (for instance qmsi driver expect double-word alignment). Solution for this is to describe this requirement beater or make the common requirement for all drivers. In the case when alignment requirements will be kept different for each driver I would consider the addition to the driver API to get the requirements.

 

Andrzej Puzdrowski

 

 


Re: Intel kills off Embedded Boards

Daniel Thompson <daniel.thompson@...>
 

On 05/07/17 19:19, Marcio Montenegro wrote:
http://www.eejournal.com/article/intel-kills-off-embedded-boards/
Don't you think this article is just a both overstated?

Companies do discontinue boards from time to time. It's normal. There remain plenty of zephyr-supported boards to choose from:

https://www.zephyrproject.org/doc/boards/boards.html


Daniel.


Re: GPIO FRDM_K64F

Maureen Helm
 

Hi Kevin,

The frdm_k64f board supports the Zephyr gpio.h interface with 5 instances of the gpio_mcux.c device driver, which correspond to the 5 gpio ports on the k64 SoC (GPIOA, GPIOB, …, GPIOE). So, first you need to use the board schematic to determine which port and pin you want to use. For example, on frdm_k64f the SW2/INT1 button is routed to the PTC6 SoC pin, which is PORTC/GPIOC pin 6. There are some helper macros in boards/arm/frdm_k64f/board.h for the buttons and LEDs:

 

/* Push button switch 2 */

#define SW2_GPIO_NAME   CONFIG_GPIO_MCUX_PORTC_NAME

#define SW2_GPIO_PIN    6

A good example to start with is samples/basic/button, which uses a falling edge gpio interrupt. The gpio driver also supports rising edge and both edges.

 

Another more complicated example that uses a sensor interrupt is samples/sensor/fxos8700 (and consequently drivers/sensors/fxos8700/fxos8700_trigger.c, which does all the gpio setup and handling).

 

You should also take a look at boards/arm/frdm_k64f/pinmux.c to check if the pin you want to use has been muxed as a gpio. If not, you’ll need to add it there or somewhere in your application.

 

Maureen

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Tomasz Bursztyka
Sent: Wednesday, July 05, 2017 3:51 AM
To: zephyr-devel@...
Subject: Re: [Zephyr-devel] GPIO FRDM_K64F

 

Hi,

It's specific to this board, so you'll have to check its datasheet:
http://cache.freescale.com/files/32bit/doc/user_guide/FRDMK64FUG.pdf

see page 17

Then for the configuration and behavior of a gpio pin, it's up to the µC so I guess you
should be able to find that info somewhere in:
http://cache.freescale.com/files/microcontrollers/doc/ref_manual/K64P144M120SF5RM.pdf

However, I believe it's properly driven already in Zephyr so it's only a matter for you to use the gpio API.

So, inclued/gpio.h and samples/drivers/gpio/src/main.c will help you towards using gpio API.
(and thus configuring the relevant port accordingly).

Tomasz

Hello,
I want to trigger on the rising edge of a sensor (buzzer,PIR,...) but where can I find the Name of the Pin from the NXP Frdm-K64f Board.

 

So how is it possible with this Board to trigger on the rising edge of sensors?

Thanks in Advance

Kevin




_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 


Intel kills off Embedded Boards

Marcio Montenegro
 


Re: help!!!Using Windows 10 WSL (Windows Subsystem for Linux) build error

Carles Cufi
 

Hi there,

 

The issue is not with Zephyr but with your Windows version. You need to update to the Windows 10 Creator’s Edition, or any build higher than 15002.

 

Regards,

 

Carles

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of ? ?
Sent: 04 July 2017 17:56
To: zephyr-devel@...
Subject: [Zephyr-devel] help!!!Using Windows 10 WSL (Windows Subsystem for Linux) build error

 

      Anyone help!Zephyr zephyr-zephyr-v1.8.0/zephyr-zephyr-v1.7.0 build error with Using Windows 10 WSL (Windows Subsystem for Linux).

 

zz@DESKTOP-ZZ:/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world$ make BOARD=arduino_101

make[1]: Entering directory `/mnt/c/zephyr-zephyr-v1.8.0'

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

dirname: missing operand

Try 'dirname --help' for more information.

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

make[2]: Entering directory `/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world/outdir/arduino_101'

  CHK     include/generated/generated_dts_board.conf

  Using /mnt/c/zephyr-zephyr-v1.8.0 as source for kernel

  CHK     include/generated/version.h

  CHK     include/generated/generated_dts_board.h

  CHK     misc/generated/configs.c

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

make[3]: *** [arch/x86/core/offsets/offsets.o] Error 2

make[2]: *** [prepare] Error 2

make[2]: Leaving directory `/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world/outdir/arduino_101'

make[1]: *** [sub-make] Error 2

make[1]: Leaving directory `/mnt/c/zephyr-zephyr-v1.8.0'

make: *** [all] Error 2

zz@DESKTOP-ZZ:/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world$ make BOARD=nucleo_l476rg

make[1]: Entering directory `/mnt/c/zephyr-zephyr-v1.8.0'

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

dirname: missing operand

Try 'dirname --help' for more information.

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

make[2]: Entering directory `/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world/outdir/nucleo_l476rg'

  DTC     dts/arm/nucleo_l476rg.dts_compiled

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

make[3]: *** [dts/arm/nucleo_l476rg.dts_compiled] Error 2

  Using /mnt/c/zephyr-zephyr-v1.8.0 as source for kernel

  CHK     include/generated/version.h

  DTC     dts/arm/nucleo_l476rg.dts_compiled

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

make[3]: *** [dts/arm/nucleo_l476rg.dts_compiled] Error 2

make[2]: *** [include/generated/generated_dts_board.h] Error 2

make[2]: Leaving directory `/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world/outdir/nucleo_l476rg'

make[1]: *** [sub-make] Error 2

make[1]: Leaving directory `/mnt/c/zephyr-zephyr-v1.8.0'

make: *** [all] Error 2

发送自 Windows 10 邮件应用

 


Re: GPIO FRDM_K64F

Tomasz Bursztyka
 

Hi,

It's specific to this board, so you'll have to check its datasheet:
http://cache.freescale.com/files/32bit/doc/user_guide/FRDMK64FUG.pdf

see page 17

Then for the configuration and behavior of a gpio pin, it's up to the µC so I guess you
should be able to find that info somewhere in:
http://cache.freescale.com/files/microcontrollers/doc/ref_manual/K64P144M120SF5RM.pdf

However, I believe it's properly driven already in Zephyr so it's only a matter for you to use the gpio API.

So, inclued/gpio.h and samples/drivers/gpio/src/main.c will help you towards using gpio API.
(and thus configuring the relevant port accordingly).

Tomasz

Hello,
I want to trigger on the rising edge of a sensor (buzzer,PIR,...) but where can I find the Name of the Pin from the NXP Frdm-K64f Board.


So how is it possible with this Board to trigger on the rising edge of sensors?

Thanks in Advance

Kevin



_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



GPIO FRDM_K64F

Kevin Stöckl <k_stoeckl@...>
 

Hello,
I want to trigger on the rising edge of a sensor (buzzer,PIR,...) but where can I find the Name of the Pin from the NXP Frdm-K64f Board.


So how is it possible with this Board to trigger on the rising edge of sensors?

Thanks in Advance

Kevin


help!!!Using Windows 10 WSL (Windows Subsystem for Linux) build error

cstyle
 

      Anyone help!Zephyr zephyr-zephyr-v1.8.0/zephyr-zephyr-v1.7.0 build error with Using Windows 10 WSL (Windows Subsystem for Linux).

 

zz@DESKTOP-ZZ:/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world$ make BOARD=arduino_101

make[1]: Entering directory `/mnt/c/zephyr-zephyr-v1.8.0'

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

dirname: missing operand

Try 'dirname --help' for more information.

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

make[2]: Entering directory `/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world/outdir/arduino_101'

  CHK     include/generated/generated_dts_board.conf

  Using /mnt/c/zephyr-zephyr-v1.8.0 as source for kernel

  CHK     include/generated/version.h

  CHK     include/generated/generated_dts_board.h

  CHK     misc/generated/configs.c

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc: Syntax error: ")" unexpected

make[3]: *** [arch/x86/core/offsets/offsets.o] Error 2

make[2]: *** [prepare] Error 2

make[2]: Leaving directory `/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world/outdir/arduino_101'

make[1]: *** [sub-make] Error 2

make[1]: Leaving directory `/mnt/c/zephyr-zephyr-v1.8.0'

make: *** [all] Error 2

zz@DESKTOP-ZZ:/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world$ make BOARD=nucleo_l476rg

make[1]: Entering directory `/mnt/c/zephyr-zephyr-v1.8.0'

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

dirname: missing operand

Try 'dirname --help' for more information.

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

make[2]: Entering directory `/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world/outdir/nucleo_l476rg'

  DTC     dts/arm/nucleo_l476rg.dts_compiled

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

make[3]: *** [dts/arm/nucleo_l476rg.dts_compiled] Error 2

  Using /mnt/c/zephyr-zephyr-v1.8.0 as source for kernel

  CHK     include/generated/version.h

  DTC     dts/arm/nucleo_l476rg.dts_compiled

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc: Syntax error: ")" unexpected

make[3]: *** [dts/arm/nucleo_l476rg.dts_compiled] Error 2

make[2]: *** [include/generated/generated_dts_board.h] Error 2

make[2]: Leaving directory `/mnt/c/zephyr-zephyr-v1.8.0/samples/hello_world/outdir/nucleo_l476rg'

make[1]: *** [sub-make] Error 2

make[1]: Leaving directory `/mnt/c/zephyr-zephyr-v1.8.0'

make: *** [all] Error 2

发送自 Windows 10 邮件应用

 


Re: netapp api init bug

Erwin Rol
 

Hey Jukka,

I opened a PR with a fix;

https://github.com/zephyrproject-rtos/zephyr/pull/676

- Erwin

On 3-7-2017 11:22, Jukka Rissanen wrote:
Hi Erwin,

On Sun, 2017-07-02 at 14:19 +0200, Erwin Rol wrote:
Hallo All,

in zephyr/subsys/net/lib/app/init.c the following piece of code;

int net_app_init(const char *app_info, u32_t flags, s32_t timeout)
{
#define LOOP_DEVIDER 10
struct net_if *iface = net_if_get_default();
int loop = timeout / LOOP_DEVIDER;
int count = 0;

if (app_info) {
NET_INFO("%s", app_info);
}

if (flags & NET_APP_NEED_IPV6) {
count++;
}

if (flags & NET_APP_NEED_IPV4) {
count++;
}

k_sem_init(&counter, count, count);



causes and assert in k_sem_init when neither NET_APP_NEED_IPV6 or
NET_APP_NEED_IPV4 are selected, because count will be 0 and the sem
limit, 3rd arg of k_sem_init, is not allowed to be 0.
Indeed, can you send a fix for this?



And shouldn't it be LOOP_DIVIDER instead of LOOP_DEVIDER?
Yes, there is a typo here.


- Erwin
Cheers,
Jukka


Re: netapp api init bug

Jukka Rissanen
 

Hi Erwin,

On Sun, 2017-07-02 at 14:19 +0200, Erwin Rol wrote:
Hallo All,

in zephyr/subsys/net/lib/app/init.c the following piece of code;

int net_app_init(const char *app_info, u32_t flags, s32_t timeout)
{
#define LOOP_DEVIDER 10
        struct net_if *iface = net_if_get_default();
        int loop = timeout / LOOP_DEVIDER;
        int count = 0;

        if (app_info) {
                NET_INFO("%s", app_info);
        }

        if (flags & NET_APP_NEED_IPV6) {
                count++;
        }

        if (flags & NET_APP_NEED_IPV4) {
                count++;
        }

        k_sem_init(&counter, count, count);



causes and assert in k_sem_init when neither NET_APP_NEED_IPV6 or
NET_APP_NEED_IPV4 are selected, because count will be 0 and the sem
limit, 3rd arg of k_sem_init, is not allowed to be 0.
Indeed, can you send a fix for this?



And shouldn't it be LOOP_DIVIDER instead of LOOP_DEVIDER?
Yes, there is a typo here.


- Erwin
Cheers,
Jukka


netapp api init bug

Erwin Rol
 

Hallo All,

in zephyr/subsys/net/lib/app/init.c the following piece of code;

int net_app_init(const char *app_info, u32_t flags, s32_t timeout)
{
#define LOOP_DEVIDER 10
struct net_if *iface = net_if_get_default();
int loop = timeout / LOOP_DEVIDER;
int count = 0;

if (app_info) {
NET_INFO("%s", app_info);
}

if (flags & NET_APP_NEED_IPV6) {
count++;
}

if (flags & NET_APP_NEED_IPV4) {
count++;
}

k_sem_init(&counter, count, count);



causes and assert in k_sem_init when neither NET_APP_NEED_IPV6 or
NET_APP_NEED_IPV4 are selected, because count will be 0 and the sem
limit, 3rd arg of k_sem_init, is not allowed to be 0.


And shouldn't it be LOOP_DIVIDER instead of LOOP_DEVIDER?

- Erwin


Re: esp32 support in zephyr

Leandro Pereira
 

Hello,

On 06/29/2017 11:17 PM, Kitty(chun hua) Jiang wrote:
But when I tried to build a hello world for esp32 board, it always failed.
I'm still working on the documentation, but right now you'll need both esp-idf (for headers and the HAL library) and the ESP32 toolchain as distributed by Espressif. Building with the Zephyr toolchain is currently unsupported.

You'll also need to set a few environment variables:

export ZEPHYR_GCC_VARIANT="espressif"
export ESP_IDF_PATH=/path/to/esp-idf
export ESPRESSIF_TOOLCHAIN_PATH=/path/to/xtensa-esp32-elf/

After setting these, you'll be able to build some samples. The port is pretty crude at the moment, but the very basics are already working. These changes were merged and are on the official Zephyr repository, in the master branch, so there's no need to use the other repos/branches you listed. (This might not be the case as the port matures and more things get supported, of course.)

If you're still getting compile errors even with these environment variables set, then it's most likely a bug.

To flash, "make flash" should work, but please read the commit message for commit f0b4e174d738c94703 first.

Cheers,
Leandro


esp32 support in zephyr

Kitty(chun hua) Jiang <Kitty_Jiang@...>
 

Hi Leandro/All,

 

I’m really a big fans of both zephyr and esp, and it’s so excited to see the esp32 support in zephyr.

But when I tried to build a hello world for esp32 board, it always failed.

I tried the following github repo & branch:

-          zephyrproject-rtos/zephyr:master

-          lpereira/zephyr:esp32

-          lpereira/zephyr: esp32-hack

-          lpereira/zephyr: esp32-build-fixes

I just go to hello-world directory, and type `make BOARD=esp32`, and do nothing else.

Below is my error message:

make[2]: Entering directory '/home/work/me/zephyr/samples/hello_world/outdir/esp32'

arch/xtensa/Makefile:25: /home/work/me/zephyr/arch/xtensa/soc/LX6/Makefile: No such file or directory

make[2]: *** No rule to make target '/home/work/me/zephyr/arch/xtensa/soc/LX6/Makefile'.  Stop.

I don’t know if there is something missed.

Need all of you help.

Thanks.

 

Best Regards,

Kitty.

 


Re: Zephyr Help

Kinder, David B <david.b.kinder@...>
 

Because Zephyr supports a large number of boards, you’ll need to specify the specific board you’re targeting when you build a sample app, as Kien describes in his reply.

 

The default “board” when you run “make” in a sample folder, is qemu_x86 (an emulated x86 board that you can run without having actual hardware). 

 

-- david

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Dinh, Kien T
Sent: Thursday, June 29, 2017 7:09 AM
To: Tamra Oyama <tamrako@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Zephyr Help

 

Hi Tamra,

 

Please take a look at this page to see how to setup the environment, build and flash Zephyr app for Arduino 101

https://www.zephyrproject.org/doc/boards/x86/arduino_101/doc/board.html

 

You’ll need to specify the board type in your build command:

$ make BOARD=arduino_101

And then flash it:

$ dfu-util -a x86_app -D outdir/arduino_101/zephyr.bin

 

Please note that you’ll need a Zephyr Bluetooth stack for the beacon app to work. Please refer to this section to see how.

 

And finally, to set up the serial output, please refer to this section to see how.

 

Regards,

Kien

 

From: <zephyr-devel-bounces@...> on behalf of Tamra Oyama <tamrako@...>
Date: Wednesday, June 28, 2017 9:08
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Zephyr Help

 

Hello Zephyr Team,

In the zephyr folder, I am trying to compile the beacon file in the zephyr folder (CODK/zephyr/samples/bluetooth/beacon). It compiles when I write the command, "make", however I am unable to upload it to my Curie on the Arduino 101 using  the "make run SERIAL_PORT=/dev/ttyUSB0 command." This results in the following errors:

make[1]: Entering directory '/home/tamrako/CODK/zephyr/zephyr-project'

make[2]: Entering directory '/home/tamrako/CODK/zephyr/zephyr-project/samples/bluetooth/scan_adv/outdir/qemu_x86'

make[2]: *** No rule to make target 'upload'.  Stop.

make[2]: Leaving directory '/home/tamrako/CODK/zephyr/zephyr-project/samples/bluetooth/scan_adv/outdir/qemu_x86'

Makefile:177: recipe for target 'sub-make' failed

make[1]: *** [sub-make] Error 2

make[1]: Leaving directory '/home/tamrako/CODK/zephyr/zephyr-project'

/home/tamrako/CODK/zephyr/zephyr-project/Makefile.inc:136: recipe for target 'upload' failed

make: *** [upload] Error 2

Do you know the appropriate command to do this? I have looked at the hello world example previously for zephyr and was able to compile it just fine. In that example, nothing is uploaded to the board. I can run hello world without connecting the Arduino 101 at all. I was wondering what the specific command was to upload to the board in zephyr. I know I am able to use cutecom for the M and Z tree. Do you think cutecom would still be appropriate for zephyr and if so do you know what the upload command is using USB for the serial port?

Thank you,

Tamra


Re: Zephyr Help

Dinh, Kien T
 

Hi Tamra,

 

Please take a look at this page to see how to setup the environment, build and flash Zephyr app for Arduino 101

https://www.zephyrproject.org/doc/boards/x86/arduino_101/doc/board.html

 

You’ll need to specify the board type in your build command:

$ make BOARD=arduino_101

And then flash it:

$ dfu-util -a x86_app -D outdir/arduino_101/zephyr.bin

 

Please note that you’ll need a Zephyr Bluetooth stack for the beacon app to work. Please refer to this section to see how.

 

And finally, to set up the serial output, please refer to this section to see how.

 

Regards,

Kien

 

From: <zephyr-devel-bounces@...> on behalf of Tamra Oyama <tamrako@...>
Date: Wednesday, June 28, 2017 9:08
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Zephyr Help

 

Hello Zephyr Team,

In the zephyr folder, I am trying to compile the beacon file in the zephyr folder (CODK/zephyr/samples/bluetooth/beacon). It compiles when I write the command, "make", however I am unable to upload it to my Curie on the Arduino 101 using  the "make run SERIAL_PORT=/dev/ttyUSB0 command." This results in the following errors:

make[1]: Entering directory '/home/tamrako/CODK/zephyr/zephyr-project'

make[2]: Entering directory '/home/tamrako/CODK/zephyr/zephyr-project/samples/bluetooth/scan_adv/outdir/qemu_x86'

make[2]: *** No rule to make target 'upload'.  Stop.

make[2]: Leaving directory '/home/tamrako/CODK/zephyr/zephyr-project/samples/bluetooth/scan_adv/outdir/qemu_x86'

Makefile:177: recipe for target 'sub-make' failed

make[1]: *** [sub-make] Error 2

make[1]: Leaving directory '/home/tamrako/CODK/zephyr/zephyr-project'

/home/tamrako/CODK/zephyr/zephyr-project/Makefile.inc:136: recipe for target 'upload' failed

make: *** [upload] Error 2

Do you know the appropriate command to do this? I have looked at the hello world example previously for zephyr and was able to compile it just fine. In that example, nothing is uploaded to the board. I can run hello world without connecting the Arduino 101 at all. I was wondering what the specific command was to upload to the board in zephyr. I know I am able to use cutecom for the M and Z tree. Do you think cutecom would still be appropriate for zephyr and if so do you know what the upload command is using USB for the serial port?

Thank you,

Tamra


Re: Passing information from bootloader to Zephyr

Marti Bolivar <marti.bolivar@...>
 

Hi David,

Thanks for putting this together.

On 28 June 2017 at 11:59, David Brown <david.brown@...> wrote:
Background
==========

On larger platforms, there will generally be a protocol for passing
information from the bootloader to the operating system that it is
booting.  There are various standards for this, from BIOS, UEFI, to
the more simplistic approach used on many ARM targets of passing a
pointer to a flattened device tree in a register.

Now that we are approaching a 1.0 release of mcuboot, it would be nice
to also have a way for the bootloader to pass information to the
running application.  This will likely be a fairly simple method,
given the memory constraints of the devices typically used by Zephyr.


+1 to simplicity. It's also of course worth noting that we can do this slightly differently across arches if necessary, though it'd be nice to avoid that.
 
It is important to note that the bootloader and application will
generally be built separately, and generally, the bootloader will not
be upgraded, but only the application.  This is why it is necessary
for a possibly upgraded application to know about the bootloader
present in a particular device.

At this time, most of this information is needed by over-the-air
updating, since this effectively has to communicate back to the
bootloader in order to be able to use the new image.  Currently, we're
thinking of:

 - Version information about the bootloader.
 - Information about how to perform an upgrade.
 - Information about the flash device itself, specifically the
   bootloader's ideas of the partitions it cares about.

This is a great list. I'd like to get into some additional details, if possible.

First, I think the application needs to be able to find out how the bootloader was configured, not just its version.

For example, applications may want to know whether the bootloader was configured to swap image data, or if it was built for "overwrite only", or if it's a "split loader", or perhaps some other future boot strategy. You might imagine deploying "canary" builds only to devices which support rollback and not ones which always overwrite old images, for instance. As another example, applications may want to know which signature checking algorithms the bootloader supports, to e.g. determine which of multiple equivalent images signed with different algorithms is appropriate for the current bootloader.

Both of these examples assume deploying different bootloader configurations on the same device. It may not be reasonable to permit this, but I think it's worth considering, especially since saying "that can't happen" forces each application to track its own expectations of the bootloader's configuration, which has its own issues.

Second, I'm not sure if the combination of "how to perform an upgrade" and "ideas of the partitions it cares about" implies the application can signal to the bootloader the results of a given boot, but this seems necessary.

For example, if the bootloader is configured to swap, then when a "test" swapped application boots, it needs to decide to either mark itself as OK or request a revert from mcuboot on the next reset. (More on this topic below).

Third, we may want to consider how to access the public keys trusted by mcuboot from the application, and perhaps other key management. This can be left to a future extension, but it may help point the way on the functions vs. data debate.

Right now, mcuboot supports an array of public keys it trusts when checking a key signature. If these keys are ever compromised, device manufacturers are likely to at least ship future devices with different keys in the bootloader. If they want to continue to upgrade old devices, this means the application must convey the supported keys to the source of firmware updates at runtime. Thinking forward to key revocation is another reason why we will likely want this.
 

Proposal
========

https://github.com/runtimeco/mcuboot/pull/61 has current work on this,
although it is quite tentative.  The idea is to pass a pair of
registers from the bootloader to the application.  One register will
have a magic value, and the other a pointer to a structure (likely in
flash).

Passing a pointer to flash simplifies the design because it will not
be necessary to reserve a section of RAM that the application needs to
avoid using for another purpose.

The structure contains an additional magic value, a version field, and
currently, a function pointer.  Additional queries are made by calling
this function with specific commands.

There is additional complexity because of the function pointer, with
some pros and cons.  Pros:

 - It is fairly easy to add new commands, and even deprecate
   commands.

 - It allows data that must be computed at run time rather than just
   being compile-time constant data.

and some cons as well:

 - It could be considered risky to have the application call into
   code in the bootloader.

 - The code has to be carefully written to not use RAM data, which
   will have been overwritten by the application.

The other option would be to define a larger structure, and place the
current data within this structure.  Pros:

 - No risk of running code in the bootloader.

Cons:

 - Versioning becomes more complicated, and the logic to handle
   various versions must make it into every application.

 - Complex data (e.g. a representation of the partitions) needs to be
   determined at compile time so it can be placed in a ROM data
   structure.

It would also be possible to place this structure in RAM, if we can
define an area for this purpose.  Because mcuboot has a goal to work
with more than just Zephyr, this may impose additional constraints on
every OS that wishes to use mcuboot.


Function pointers are also nice from a flash usage perspective, since mcuboot and the RTOS it chain-loads are likely going to have similar routines operating on this information.

 
Zephyr Details
==============
Supporting this in Zephyr involves adding a small amount of assembly
to system startup to detect if the register contains the magic value,
and if so, stashing away the pointer in the other register.  Once this
is stored, the rest of the use can be done at a library level or by an
application.

In addition, the MPU/MMU may need to be configured to allow reading
and/or execution from the area of flash containing the bootloader.

Questions
=========

 - What do people think of this proposal?

I think we need to define at least Zephyr's relationship to its bootloader, so I'm really glad about this proposal.
 

 - Preferences for: ROM+callback, ROM only, or RAM only

ROM+callback seems best (less duplication of code across RTOSes, lower resource usage on the device) if it is possible.
 

 - How formally should we define this proposal?  Is a de-facto
   implementation by mcuboot sufficient at this time?

I think this should be defined formally. Whenever there's protocol versioning, there needs to be a spec.

In general I also think that we need to start thinking about other issues related to passing control from mcuboot to Zephyr. Beyond just setting up the stack and jumping to the entry point, mcuboot on Zephyr also locks IRQs and disables the system clock. However, those aren't the only hardware resources it uses, and it isn't always "clean" about putting them back into their reset state.

For example, Zephyr mcuboot currently leaves the STM32 clock tree configured to use the PLL, it leaves devices powered on, clocked, and configured (e.g. UART), etc. The story is similar on other targets.

Leaving this vaguely defined is undesirable, especially for power management.

It's likely future work, but it seems inevitable we'll have to define exactly the state of the device that mcuboot provides to the chainloaded image. Having a place to put formal definitions will simplify this work.
 

 - Thoughts on future data that may need to be passed?

Please see above.

Thanks,
Marti
 

Thanks,
David Brown
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: ICMP Checksum Errors

Nashif, Anas
 

Hi Erwin,
Can you submit the patch as a pull request and file a bug?

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Erwin Rol
Sent: Wednesday, June 28, 2017 11:54 AM
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] ICMP Checksum Errors

Hey all,

I looked into it a bit more and the ICMP checksum calculation is broken.
I made a small patch to try and fix it, and it does seem to fix the problem, but I don't think the patch is good enough for a pull-request, comments are welcome.

- Erwin

On 28-6-2017 10:50, Erwin Rol wrote:
Hello,

while testing my STM32 Ethernet driver I noticed that Wireshark
complained about incorrect ICMP checksums. After a bit more testing I
found out that it started complaining when the total packet size was
128 bytes.
The ICMP checksum is calculated with

u16_t net_calc_chksum(struct net_pkt *pkt, u8_t proto)

in zephyr/subsys/net/ip/utils.c

And that has;
....
if (proto == IPPROTO_ICMP) {
return htons(calc_chksum(0, net_pkt_ip_data(pkt) +
net_pkt_ip_hdr_len(pkt),
upper_layer_len)); } ....

but unlike the

calc_chksum_pkt(sum, pkt, upper_layer_len);

function calc_chksum does not take into account that data could be
divided over multiple (128byte) net_pkt fragments.

Also are the other uses of calc_chksum in net_calc_chksum correct ?
Because 128 bytes isn't that much and especially with IPv6 things
might need more than 1 net_pkt fragment.

- Erwin
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Passing information from bootloader to Zephyr

David Brown
 

Background
==========

On larger platforms, there will generally be a protocol for passing
information from the bootloader to the operating system that it is
booting. There are various standards for this, from BIOS, UEFI, to
the more simplistic approach used on many ARM targets of passing a
pointer to a flattened device tree in a register.

Now that we are approaching a 1.0 release of mcuboot, it would be nice
to also have a way for the bootloader to pass information to the
running application. This will likely be a fairly simple method,
given the memory constraints of the devices typically used by Zephyr.

It is important to note that the bootloader and application will
generally be built separately, and generally, the bootloader will not
be upgraded, but only the application. This is why it is necessary
for a possibly upgraded application to know about the bootloader
present in a particular device.

At this time, most of this information is needed by over-the-air
updating, since this effectively has to communicate back to the
bootloader in order to be able to use the new image. Currently, we're
thinking of:

- Version information about the bootloader.
- Information about how to perform an upgrade.
- Information about the flash device itself, specifically the
bootloader's ideas of the partitions it cares about.

Proposal
========

https://github.com/runtimeco/mcuboot/pull/61 has current work on this,
although it is quite tentative. The idea is to pass a pair of
registers from the bootloader to the application. One register will
have a magic value, and the other a pointer to a structure (likely in
flash).

Passing a pointer to flash simplifies the design because it will not
be necessary to reserve a section of RAM that the application needs to
avoid using for another purpose.

The structure contains an additional magic value, a version field, and
currently, a function pointer. Additional queries are made by calling
this function with specific commands.

There is additional complexity because of the function pointer, with
some pros and cons. Pros:

- It is fairly easy to add new commands, and even deprecate
commands.

- It allows data that must be computed at run time rather than just
being compile-time constant data.

and some cons as well:

- It could be considered risky to have the application call into
code in the bootloader.

- The code has to be carefully written to not use RAM data, which
will have been overwritten by the application.

The other option would be to define a larger structure, and place the
current data within this structure. Pros:

- No risk of running code in the bootloader.

Cons:

- Versioning becomes more complicated, and the logic to handle
various versions must make it into every application.

- Complex data (e.g. a representation of the partitions) needs to be
determined at compile time so it can be placed in a ROM data
structure.

It would also be possible to place this structure in RAM, if we can
define an area for this purpose. Because mcuboot has a goal to work
with more than just Zephyr, this may impose additional constraints on
every OS that wishes to use mcuboot.

Zephyr Details
==============
Supporting this in Zephyr involves adding a small amount of assembly
to system startup to detect if the register contains the magic value,
and if so, stashing away the pointer in the other register. Once this
is stored, the rest of the use can be done at a library level or by an
application.

In addition, the MPU/MMU may need to be configured to allow reading
and/or execution from the area of flash containing the bootloader.

Questions
=========

- What do people think of this proposal?

- Preferences for: ROM+callback, ROM only, or RAM only

- How formally should we define this proposal? Is a de-facto
implementation by mcuboot sufficient at this time?

- Thoughts on future data that may need to be passed?

Thanks,
David Brown

5241 - 5260 of 8323