Date   

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@... [mailto:zephyr-devel-bounces@...] On Behalf Of Erwin Rol
Sent: Wednesday, June 28, 2017 11:54 AM
To: zephyr-devel <zephyr-devel@...>
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@...
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


Re: ICMP Checksum Errors

Erwin Rol
 

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@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Problems with MQTT on FRDM-K64F

Kevin Stöckl <k_stoeckl@...>
 

Thank you that works. But there is also the problem with the ip-adresses. I had an Ethernet connection on my Linux host machine and on the board. 

Then I changed the ip-address of the host machine to a static ip-address and in the config.h File I changed the Server Address to that static ip-address.


Is this right?

But how can I change the ip-address of the Board?


The output from "sudo mosquitto -v -p 1883" is:

1498639665: Using default config.
1498639665: Opening ipv4 listen socket on port 1883.
1498639665: Opening ipv6 listen socket on port 1883.
1498639670: New connection from 127.0.0.1 on port 1883.
1498639670: New client connected from 127.0.0.1 as mosqsub/10141-kevin-R51 (c1, k60).
1498639670: Sending CONNACK to mosqsub/10141-kevin-R51 (0, 0)
1498639670: Received SUBSCRIBE from mosqsub/10141-kevin-R51
1498639670: sensors (QoS 0)
1498639670: mosqsub/10141-kevin-R51 0 sensors
1498639670: Sending SUBACK to mosqsub/10141-kevin-R51
1498639730: Received PINGREQ from mosqsub/10141-kevin-R51

The output from minicom of the Board is:
[dev/eth_mcux] [DBG] eth_0_init: MAC 00:04:9f:62:d1:ca
net_context_connect error
Is the server (broker) up and running?
[publisher:248] network_setup: -60 <ERROR>

Bye!
[dev/eth_mcux] [INF] eth_mcux_phy_event: Enabled 100M full-duplex mode.

From mosquitto_sub -t sensors there is no output







Von: Aska Wu <aska.wu@...>
Gesendet: Mittwoch, 28. Juni 2017 04:27
An: Kevin Stöckl; zephyr-devel@...
Betreff: Re: [Zephyr-devel] Problems with MQTT on FRDM-K64F
 
For the problem of address already in use, it seems that mosquitto is already running,
If you see there's a mosquitto process in "ps aux |grep mosquit", try to stop the existing one by "sudo service mosquitto stop".

Aska Wu


On Tue, 27 Jun 2017 at 21:05 Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

I try to run the sample mqtt publisher on the frdm-k64f.

First I changed the IP-adress on the linux host machine to 192.168.0.75.

Then i type make BOARD=frdm_k64f and then I try to run mosquitto with sudo mosquitto -v -p 1883.

There I got the error message Address already in use and nothing happens.


In the config.h File I changed the Server Address to 192.168.0.75


What could be the problem?

How can I change the IP-adress of the board? And is this necessary?



Thanks in advance

Kevin

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


ICMP Checksum Errors

Erwin Rol
 

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


Re: AFH issue

Chettimada, Vinayak Kariappa
 

Hi Ali,

Comments inline.

On 27 Jun 2017, at 23:07, Ali Nikookar <nikookar7@...> wrote:

Hi

The Nordic company referred me to your website so I may get my answer here.
My question is that I need to implement my own channel mapping based on a
different scenario.
You can use the HCI LE_Set_Host_Channel_Classification to select you own channel mapping for connections.
This is available in controller only binary (sample/bluetooth/hci_uart), or you can add your own API that your application could use.

For example, in the list of bad channels and good
channels which use RSSI or PER.
What is PER?

I want to increase the BER for good channels
in a certain time period. Another example can be rescheduling the channel
list based on different timing or clustering.
I was wondering if your stack could kindly provide me with a solution.
Currently, there is no software support to profiling BER in the stack.
But, stack does use CRC check on reception to accept valid packets.
You can use the received packet, Rx-ed channel and CRC status to profile.
Grep for “crc_ok” in subsys/bluetooth/controller/ll_sw/ctrl.c.
Interesting function is isr_rx_conn, both RSSI and CRC status are available in that function for use.


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


Re: Problems with MQTT on FRDM-K64F

aska.wu
 

For the problem of address already in use, it seems that mosquitto is already running,
If you see there's a mosquitto process in "ps aux |grep mosquit", try to stop the existing one by "sudo service mosquitto stop".

Aska Wu


On Tue, 27 Jun 2017 at 21:05 Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

I try to run the sample mqtt publisher on the frdm-k64f.

First I changed the IP-adress on the linux host machine to 192.168.0.75.

Then i type make BOARD=frdm_k64f and then I try to run mosquitto with sudo mosquitto -v -p 1883.

There I got the error message Address already in use and nothing happens.


In the config.h File I changed the Server Address to 192.168.0.75


What could be the problem?

How can I change the IP-adress of the board? And is this necessary?



Thanks in advance

Kevin

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


Zephyr Help

Tamra Oyama <tamrako@...>
 

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


AFH issue

Ali Nikookar <nikookar7@...>
 

Hi

The Nordic company referred me to your website so I may get my answer here.
My question is that I need to implement my own channel mapping based on a
different scenario.  For example, in the list of bad channels and good
channels which use RSSI or PER.  I want to increase the BER for good channels
in a certain time period. Another example can be rescheduling the channel
list based on different timing or clustering.
I was wondering if your stack could kindly provide me with a solution.

Regards
Ali


Problems with MQTT on FRDM-K64F

Kevin Stöckl <k_stoeckl@...>
 

Hello,

I try to run the sample mqtt publisher on the frdm-k64f.

First I changed the IP-adress on the linux host machine to 192.168.0.75.

Then i type make BOARD=frdm_k64f and then I try to run mosquitto with sudo mosquitto -v -p 1883.

There I got the error message Address already in use and nothing happens.


In the config.h File I changed the Server Address to 192.168.0.75


What could be the problem?

How can I change the IP-adress of the board? And is this necessary?



Thanks in advance

Kevin

5501 - 5520 of 8575