Date   

CI fails for pull request on arm branch

Daniel Wagenknecht
 

Hi there,

 

I rebased pull request #4458 on the latest upstream arm-branch.

Shippable tests fail (results) , but it seems unrelated to my changes.

 

For example in test-run #1 it fails at

 Sanitycheck / frdm_k64f:samples/mpu/mem_domain_apis_test/test 

While I was only working on stm32 i2c drivers.

 

Please have a look into this problem.

Thanks!

 

Daniel Wagenknecht

Softwaredeveloper, R&D

 

 

CLAGE GmbH

Pirolweg 1-5

21337 Lüneburg | Germany

 

Fon: +49 4131 8901-7906

Fax: +49 4131 83200

E-Mail: daniel.wagenknecht@...

www.clage.de

 

 


System clock k_uptime_get() not working

Yie
 

Hi,

I am trying the two functions:

k_cycle_get_32() and k_uptime_get(). From what I understand, k_cycle_get_32() uses the hardware clock and k_uptime_get() uses the system clock.

However, the k_uptime_get() doesn't seem to be working for me as it always returns 0 whereas k_cycle_get_32() always return a value.

I am running this on the qemu_cortex_m3 board.

Any help would be much appreciated. Thanks.


Re: bluetooth mesh on nrf51822-16kb tinycrypt-ecc

Johan Hedberg
 

Hi Jehudi,

On Fri, Oct 20, 2017, Laczen JMS wrote:
On a zephyr device with bluetooth mesh tinycrypt-ecc is used to
generate the ecdh key. Tinycrypt uses a stack of 1kb which is quite
large on small ram (16kb) devices. Is it possible to precalculate the
keys and to include them instead of generating on the device ?
The large stack footprint of TinyCrypt is one of my pet peeves with it
as well. You could pre-generate the public-private keypair, but then
you're still left with calculating the DHKey when you receive the remote
public key. That's not something that you can do in advance and it also
consumes roughly the same amount of stack with TinyCrypt.

There could however be other places where there's potential to slim
things down a bit further. One such place is the provisioning state in
prov.c. A node is either provisioned or unprovisioned, so the network
state and the provisioning state never need to coexist in memory. This
means we could save some memory if we find a way to overlay them (using
a union or some linker magic). This task is actually listed in the
subsys/bluetooth/host/mesh/TODO file.

Johan


bluetooth mesh on nrf51822-16kb tinycrypt-ecc

laczenJMS
 

Hi,

On a zephyr device with bluetooth mesh tinycrypt-ecc is used to
generate the ecdh key. Tinycrypt uses a stack of 1kb which is quite
large on small ram (16kb) devices. Is it possible to precalculate the
keys and to include them instead of generating on the device ?

Kind regards,

Jehudi


Re: Current time in Zephyr using ARM Qemu board

aska.wu
 

Hi,

You probably can try this PR https://github.com/zephyrproject-rtos/zephyr/pull/1502 if you want to manage system time by gettimeofday()/settimeofday(). Note that It's still under review and only works for cortex-m boards for the time being.

Aska Wu


On Wed, 18 Oct 2017 at 22:26 Hui Yie Teh <hteh703@...> wrote:
Hi,

I am trying to get the current time using the following:

time_t rawtime; 
struct tm *info;
time( &rawtime );
info = localtime( &rawtime );
printf("Current local time and date: %s", asctime(info));

However, this is giving me an error on Qemu:

qemu: fatal: Trying to execute code outside RAM or ROM at 0x05252ff4

Is there a reason for this? Also, is there another way to get the current time of the system in Zephyr?

Any help would be much appreciated.

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


Re: public ID addresses

Tamra Oyama <tamrako@...>
 

Hi Johan,

By key, I mean identity resolving key. I see this is subsys/bluetooth/host/hci_core.c

Again, thank you for the help!

On Thu, Oct 19, 2017 at 3:08 PM, Tamra Oyama <tamrako@...> wrote:

Hello Johan,

Thanks for your suggestion. Upon further investigation, the CONFIG_BLUETOOTH_PRIVACY=y in the prj.conf file in zephyr/samples/bluetooth/peripheral. From my understanding, this config allows for the use of resolvable private addresses and that there should be a key to decipher the static address. How do you find out what this key is? Can you provide any information about this? Thank you for your time.

Thank you,
Tamra

On Tue, Oct 17, 2017 at 2:04 AM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Tamra,

On Tue, Oct 17, 2017, Johan Hedberg wrote:
> I might be wrong, but I don't think a public address is what you're
> looking for, since that address space is formally managed by companies.
> Instead, I think you're looking to get a persistent address that stays
> the same over reboots. A static random address is also an Identity
> Address, so that would fit the bill.
>
> The Nordic controllers come with a pre-programmed static address in
> their FICR register, but there's no standard way of reading it from
> there through HCI. Luckily, we've now got our own HCI vendor extensions
> available which have a command for this. If you build your controller
> image out of the latest master branch you will get vendor extensions
> support included there. For the host side, I've just pushed a pull
> request which adds what's needed:
>
>       https://github.com/zephyrproject-rtos/zephyr/pull/4371

This PR is merged now, so simply rebuilding and flashing your nRF51 &
Quark SE Zephyr images from the upstream master branch should yield a
solution where the Bluetooth address remains the same.

Johan



Re: public ID addresses

Tamra Oyama <tamrako@...>
 


Hello Johan,

Thanks for your suggestion. Upon further investigation, the CONFIG_BLUETOOTH_PRIVACY=y in the prj.conf file in zephyr/samples/bluetooth/peripheral. From my understanding, this config allows for the use of resolvable private addresses and that there should be a key to decipher the static address. How do you find out what this key is? Can you provide any information about this? Thank you for your time.

Thank you,
Tamra

On Tue, Oct 17, 2017 at 2:04 AM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Tamra,

On Tue, Oct 17, 2017, Johan Hedberg wrote:
> I might be wrong, but I don't think a public address is what you're
> looking for, since that address space is formally managed by companies.
> Instead, I think you're looking to get a persistent address that stays
> the same over reboots. A static random address is also an Identity
> Address, so that would fit the bill.
>
> The Nordic controllers come with a pre-programmed static address in
> their FICR register, but there's no standard way of reading it from
> there through HCI. Luckily, we've now got our own HCI vendor extensions
> available which have a command for this. If you build your controller
> image out of the latest master branch you will get vendor extensions
> support included there. For the host side, I've just pushed a pull
> request which adds what's needed:
>
>       https://github.com/zephyrproject-rtos/zephyr/pull/4371

This PR is merged now, so simply rebuilding and flashing your nRF51 &
Quark SE Zephyr images from the upstream master branch should yield a
solution where the Bluetooth address remains the same.

Johan


Zephyr SDK 0.9.2 released

Nashif, Anas
 

Hi,

 

Zephyr SDK 0.9.2 was just tagged and is available at https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.2

 

Changes since 0.9.1:

 

·       openocd 0.10.0

o   Zephyr support in openocd

·       bossac tool update

·       Enable MIPS toolchain

·       Integrated Kconfig binary with Zephyr related patches (this will be needed when we move to cmake)

 

Please download and install from https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/download/0.9.2/zephyr-sdk-0.9.2-setup.run

 

 

Regards,

Anas


Re: How to get caller stack information when crash happens?

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

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Li, Jun R
Sent: Thursday, October 19, 2017 1:06 PM
To: Ilyes Gouta <ilyes.gouta@...>; Kumar Gala <kumar.gala@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] How to get caller stack information when crash happens?

 

Is there an issue to track this request? This feature is very useful for debugging.

 

Regards,

Jun

 

 

From: Ilyes Gouta <ilyes.gouta@...>
Date: Wednesday, October 18, 2017 at 11:06
To: Kumar Gala <kumar.gala@...>
Cc: "zephyr-devel@..." <zephyr-devel@...>, "Li, Jun R" <jun.r.li@...>
Subject: Re: [Zephyr-devel] How to get caller stack information when crash happens?

 

Hi,

 

On Oct 18, 2017 18:53, "Kumar Gala" <kumar.gala@...> wrote:


> On Oct 18, 2017, at 10:21 AM, Li, Jun R <jun.r.li@...> wrote:
>
> Hi,
> While I debug my application based on Zephyr, sometimes Fatal faults could happen on a specific thread, with the messages like below:
>
> shell> ***** BUS FAULT *****
>   Executing thread ID (thread): 0x20001814
>   Faulting instruction address:  0x800ed96
>   Precise data bus error
>   Address: 0x746e65d2
>   Imprecise data bus error
> Fatal fault in thread 0x20001814! Aborting.
>
>
> I’m wondering if there is any macro I can enable to get more information output, like caller stack list at the moment when the crash happens?
>
> Thank you!
>
> Jun Li
>

This is something we need to implement on the various arch’s.  Been wanting that myself.

 

A port of libunwind (https://savannah.nongnu.org/projects/libunwind/) to Zephyr might be a solution?

 

Ilyes

 


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

 


Re: How to get caller stack information when crash happens?

Li, Jun R
 

Is there an issue to track this request? This feature is very useful for debugging.

 

Regards,

Jun

 

 

From: Ilyes Gouta <ilyes.gouta@...>
Date: Wednesday, October 18, 2017 at 11:06
To: Kumar Gala <kumar.gala@...>
Cc: "zephyr-devel@..." <zephyr-devel@...>, "Li, Jun R" <jun.r.li@...>
Subject: Re: [Zephyr-devel] How to get caller stack information when crash happens?

 

Hi,

 

On Oct 18, 2017 18:53, "Kumar Gala" <kumar.gala@...> wrote:


> On Oct 18, 2017, at 10:21 AM, Li, Jun R <jun.r.li@...> wrote:
>
> Hi,
> While I debug my application based on Zephyr, sometimes Fatal faults could happen on a specific thread, with the messages like below:
>
> shell> ***** BUS FAULT *****
>   Executing thread ID (thread): 0x20001814
>   Faulting instruction address:  0x800ed96
>   Precise data bus error
>   Address: 0x746e65d2
>   Imprecise data bus error
> Fatal fault in thread 0x20001814! Aborting.
>
>
> I’m wondering if there is any macro I can enable to get more information output, like caller stack list at the moment when the crash happens?
>
> Thank you!
>
> Jun Li
>

This is something we need to implement on the various arch’s.  Been wanting that myself.

 

A port of libunwind (https://savannah.nongnu.org/projects/libunwind/) to Zephyr might be a solution?

 

Ilyes

 


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

 


Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)

Boie, Andrew P
 

That's pretty much what I talked about - that with new requirements and
challenges, we may find out that a well-known and proven API like BSD Sockets
is a very good way to address them, instead of continuing to add complexity to
existing adhoc APIs.
What I stated is that when faced with an existing Zephyr API that works only in supervisor mode, rather than do a parallel implementation in user mode, first see if the C library already provides a suitable equivalent.
I don't know if this is a valid comparison to whatever your agenda is with BSD sockets API, my feeling is that it isn't, but at any rate I am strictly neutral on that matter. You need to talk to Jukka.

And above you write about protecting kernel from userspace, but is there a
requirement to protect one userspace entity (a thread in our case, as we don't
support processes) from another? I hope there's, because it doesn't make much
sense to go so long way of kernel vs userspace separation and don't think about
task separation. Just imagine that the could be a thread running OTA, and
another thread running an application level 3rd-party lib. We don't want
vulnerability in the latter to compromise OTA process.
You're not going to believe this, but we did actually consider this situation.
The memory domain APIs exist for this purpose. User threads otherwise only have access to their own stack. They are in-tree and documented, although only working on ARM at the moment.

Andrew


Problems with static variables and GNU map files

Paul Sokolovsky
 

Hello,

A usecase (one of many): I want to see what network interface structures
go into my Zephyr binary. Of course, I look at the linker map file,
and ... see nothing:

net_if 0x000000000041fa80 0x2a0 load address 0x00000000000150bc
0x000000000041fa80 __net_if_start = .
*(.net_if.*)
.net_if.data 0x000000000041fa80 0x2a0 drivers/built-in.o
*(SORT(.net_if.*))
0x000000000041fd20 __net_if_end = .

That's because netif structures are defined as static, and GNU linker
takes that as an incentive to conceal them from the map file. This
issue was reported few years ago as
https://sourceware.org/bugzilla/show_bug.cgi?id=16566 with no
feedback, so apparently nothing is going to happen.


Proposal:

Let's have

#define STATIC static

And use STATIC everywhere a static var is defined. This way, it can be
redefined in one place to produce a relevant map file (let's also have
unique names for all variables, yeah).


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Bluetooth mesh - best method to implement persistent storage

laczenJMS
 

Hi,

I have been thinking about different ways to add persistent storage to
bluetooth mesh. I would like to add this with as few changes to the
library as possible. I would store the data in flash using a
handle-value method.

I am however doubting the best way to trigger the writing to flash:

Option 1: trigger a writing to flash directly in the existing routines.
Option 2: add a "needs_flashing" variable to the structures, I would
add these to bt_mesh_elem, bt_mesh_cfg,(bt_mesh_health),
bt_mesh_model, bt_mesh_net, bt_mesh_friend, bt_mesh_lpn,
bt_mesh_app_key, bt_mesh_subnet,(bt_mesh_rpl). And starting a loop in
idle time checking for items that need flashing.

My preference goes to option 2, but my experience is limited, so if
someone has ideas about this please comment.

Kind regards,

Jehudi


Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)

Paul Sokolovsky
 

Hello Andrew,

On Wed, 11 Oct 2017 18:53:24 +0000
"Boie, Andrew P" <andrew.p.boie@intel.com> wrote:

There has not been any public talk in mailing list about
userspace/kernel separation and how it affects IP stack etc. so
it is a bit difficult to say anything about this.
That's true, but we can/should think how it may be affected, or
we'll be caught in the cold water with them, and may come up with
random on-spot designs to address such future requirements, instead
of something well thought out.
The userspace work has progressed to the point where we have enough
confidence in the API design to open up the design discussion to a
larger audience; until now enough things have been in flux (or
uncertain) such that we've kept the discussion to the working group
we established for it.

What we are trying to do is get something feature-complete into the
tree for the upcoming 1.10 release, with partial test case coverage
and initial documentation, on an 'experimental' basis; i.e. APIs and
policies are subject to change. Then polish everything up for the
1.11 release, which would be the official debut of this feature.

I have to admit my knowledge of the network stack is quite poor, but
broadly speaking here are a set of slides recently drafted which goes
into some detail about what sort of kernel objects are accessible
from user threads and the sort of restrictions they have. We expect
to expose a subset of existing kernel APIs to user threads, and all
driver APIs which don't involve registration of callbacks. Please
feel free to leave comments in the document, or on this list.

https://docs.google.com/presentation/d/195ciwFwv7s0MX4AvL0KFB1iHm1_gRoXmn54mjS5fki8/edit?usp=sharing
Thanks for sharing these. What caught my attention is "No good way to
assert validity of k_mem_block object passed to k_mem_pool_free() - Just
tell userspace to use heap memory APIs in newlib! No need to re-invent
the C library..."

That's pretty much what I talked about - that with new requirements and
challenges, we may find out that a well-known and proven API like BSD
Sockets is a very good way to address them, instead of continuing to
add complexity to existing adhoc APIs.


I suspect the biggest implication for the network stack is that it
uses registration of callbacks heavily, and it's forbidden to allow
user threads to directly register callbacks that run in supervisor
mode. But you can get around this (for example) by having the
callback do minimal processing of the incoming data and signal a
semaphore to have a user mode worker thread do the rest of the work.
That's half of the work BSD Sockets do - they put network packets as
delivered via a callback into per-socket fifo.

We are also looking into supporting user-mode workqueues. We also
don't (yet) have a clear picture on what support for k_poll APIs we
will have for userspace.

There's also the question of memory buffers, there would need to be
some care taken that any buffers used by the stack that are exposed
to the application contain purely data and no internal data
structures private to the kernel. This constraint is why we don't
provide system call interfaces to k_queue APIs.
net_pkt's and net_buf's as used by native networking API do share this
problem - they have internal kernel data. Not only that, they are also
allocated from the pool, and are small objects, which can't be
protected by MPU or MMU individually. Which means that one application
could have access/corrupt networking data for other apps.

And above you write about protecting kernel from userspace, but is
there a requirement to protect one userspace entity (a thread in our
case, as we don't support processes) from another? I hope there's,
because it doesn't make much sense to go so long way of kernel vs
userspace separation and don't think about task separation. Just
imagine that the could be a thread running OTA, and another thread
running an application level 3rd-party lib. We don't want
vulnerability in the latter to compromise OTA process.

The solution to the problem is well known - don't try to export
kernel-level object (like network buffers) to userspace, just copy
*data* there as needed. That's 2nd part of what BSD Sockets do.

Ideally in the fullness of time, we could migrate some parts of the
network protocol stack to run in user mode, which I think would
enhance the security of the system.

At the moment, current implementation effort is centered around
getting our test cases running in user mode, and getting started on
the formal documentation.

HTH,
Andrew


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Current time in Zephyr using ARM Qemu board

Paul Sokolovsky
 

Hello,

On Thu, 19 Oct 2017 03:26:09 +1300
Hui Yie Teh <hteh703@aucklanduni.ac.nz> wrote:

Hi,

I am trying to get the current time using the following:

time_t rawtime;
struct tm *info;
time( &rawtime );
info = localtime( &rawtime );
printf("Current local time and date: %s", asctime(info));

However, this is giving me an error on Qemu:

qemu: fatal: Trying to execute code outside RAM or ROM at 0x05252ff4
Did you try to run your app under debugger and see what happens there?


Is there a reason for this? Also, is there another way to get the
current time of the system in Zephyr?

Any help would be much appreciated.

Cheers,
Yie


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: How to get caller stack information when crash happens?

Ilyes Gouta
 

Hi,

On Oct 18, 2017 18:53, "Kumar Gala" <kumar.gala@...> wrote:

> On Oct 18, 2017, at 10:21 AM, Li, Jun R <jun.r.li@...> wrote:
>
> Hi,
> While I debug my application based on Zephyr, sometimes Fatal faults could happen on a specific thread, with the messages like below:
>
> shell> ***** BUS FAULT *****
>   Executing thread ID (thread): 0x20001814
>   Faulting instruction address:  0x800ed96
>   Precise data bus error
>   Address: 0x746e65d2
>   Imprecise data bus error
> Fatal fault in thread 0x20001814! Aborting.
>
>
> I’m wondering if there is any macro I can enable to get more information output, like caller stack list at the moment when the crash happens?
>
> Thank you!
>
> Jun Li
>

This is something we need to implement on the various arch’s.  Been wanting that myself.

A port of libunwind (https://savannah.nongnu.org/projects/libunwind/) to Zephyr might be a solution?

Ilyes


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


Re: How to get caller stack information when crash happens?

Kumar Gala
 

On Oct 18, 2017, at 10:21 AM, Li, Jun R <jun.r.li@intel.com> wrote:

Hi,
While I debug my application based on Zephyr, sometimes Fatal faults could happen on a specific thread, with the messages like below:

shell> ***** BUS FAULT *****
Executing thread ID (thread): 0x20001814
Faulting instruction address: 0x800ed96
Precise data bus error
Address: 0x746e65d2
Imprecise data bus error
Fatal fault in thread 0x20001814! Aborting.


I’m wondering if there is any macro I can enable to get more information output, like caller stack list at the moment when the crash happens?

Thank you!

Jun Li
This is something we need to implement on the various arch’s. Been wanting that myself.

- k


How to get caller stack information when crash happens?

Li, Jun R
 

Hi,

While I debug my application based on Zephyr, sometimes Fatal faults could happen on a specific thread, with the messages like below:

 

shell> ***** BUS FAULT *****

  Executing thread ID (thread): 0x20001814

  Faulting instruction address:  0x800ed96

  Precise data bus error

  Address: 0x746e65d2

  Imprecise data bus error

Fatal fault in thread 0x20001814! Aborting.

 

 

I’m wondering if there is any macro I can enable to get more information output, like caller stack list at the moment when the crash happens?

 

Thank you!

 

Jun Li

 


Current time in Zephyr using ARM Qemu board

Yie
 

Hi,

I am trying to get the current time using the following:

time_t rawtime; 
struct tm *info;
time( &rawtime );
info = localtime( &rawtime );
printf("Current local time and date: %s", asctime(info));

However, this is giving me an error on Qemu:

qemu: fatal: Trying to execute code outside RAM or ROM at 0x05252ff4

Is there a reason for this? Also, is there another way to get the current time of the system in Zephyr?

Any help would be much appreciated.

Cheers,
Yie


Re: Mesh sample fails w/ CONFIG_BT_HCI_VS_EXT=y

Steve Brown
 

Hi Johan,

On Tue, 2017-10-17 at 21:39 +0300, Johan Hedberg wrote:
Hi Steve,

On Tue, Oct 17, 2017, Steve Brown wrote:
More ...

In looking at the log, it appears that the beacon_complete callback
never gets called from bt_mesh_adv_send. So, net_buf_unref never
gets
called and we run out of buffers.
It's still a mystery how that's related to the patch you found with
bisect. Did you try the v2 of my patch? The first version will not
make
any difference to you since it had the missing unref in a branch
that's
never taken in your case.

Johan
I looked at the recent commits and didn't see any connection either.That's why I gave up and did the bisect.

Is it possible that because the buffer wasn't released, subsequent
commands queued up and eventually used up all available buffers?

Steve

4781 - 4800 of 8323