Date   

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 Tomasz,

Thanks for responding and bringing up this discussion - it got
backlogged (so I'm doing homework on it in the background).

On Wed, 25 Oct 2017 18:13:18 +0200
Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com> wrote:

Hi guys,

It was
posted as https://github.com/zephyrproject-rtos/zephyr/pull/119 .
Again, at that time, there was no consensus about way to solve it,
so it was implemented only for BSD Sockets API.

Much later,
https://github.com/zephyrproject-rtos/zephyr/pull/1330 was posted.
It works in following way: it allows an application to create an
oversized packet
(...)

There're many more
details than presented above, and the devil is definitely in
details, there's no absolutely "right" solution, it's a compromise.
I hope that Jukka and Tomasz, who are proponents of the second
(GH-1330) approach can correct me on the benefits of it.
Actually I missed the fact PR 1330 was about MTU handling. Does not
sound generic enough.

In the end I don't approve both of the proposed solution.
That sounds fresh, thanks ;-)

Let me
explain why:

First, let's not rush on this MTU handling just yet, though it is
much needed. We first need this:

-> https://github.com/zephyrproject-rtos/zephyr/issues/3283
Ack, that's good thing to do...


it will simplify a lot how packet are allocated. I haven't touched
MTU stuff since I did the net_pkt move because of this feature we'll
use.

I foresee a lot of possible improvements with this issue resolved:
certainly MTU handling, better memory management than current frag
model, but also better response against low memory
... but I don't see how it directly relates to the topic of this RFC,
which is selecting paradigm to deal with the case that we have finite
units of buffering, and how that should affect user-facing API design.

There're definitely a lot to improve and optimize in our IP stack, and
the issue you mention is one of them. But it's going to be just that -
the optimization. But what we discuss is how to structure API:

1. Accept that the amount of buffering we can do is very finite, and
make applications be aware of that and ready to handle - the POSIX
inspired way. If done that way, we can just use a network packet as
a buffering unit and further optimize that handling.

2. Keep pretending that we can buffer mini-infinite amount of data.
It's mini-infinite because we still won't be able to buffer more than
RAM allows (actually, more than TX slab allows), and that's still too
little, so won't work for "real" amounts of data, which still will need
to fall back to p.1 handling above. Packet buffers are still used for
buffering, but looking at Jukka's implementation, they are used as
generic data buffers, and require pretty heavy post-processing - first
splitting oversized buffers into packet-friendly sizes (#1330),
stuffing protocol headers in front (we already do that, and that's
pretty awful and not zero-copy at all), etc. Again, all that happens
with no free memory available - it was already spent to buffer that
"mini-infinite" amount of data.


You also say that you don't like any of these choices. Well, there're
only so many ways to do. What do you have in mind?


(we could after
all send asap a tinier than MTU TCP segment if there was only a small
amount of memory available, and continue with the rest etc...).
That's how sockets work already - they ask user's data to be added to a
packets, and if less is added, it passes that info back to app (for it
to retry). The whole talk is about making that available to the native
API too (governed also by other constraints like MTU size).


Tomasz


--
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 Address Type - Fixed (public)

Jie Zhou <zhoujie@...>
 

Hi all, 

Looking at the bluetooth API and the sample bluetooth code, tt seems that the default advertised address addr->type is random. I think this is because of security reasons, so it is using resolvable private addresses. Is there a way for me to change the address type to public (i.e. fixed) for my curie board? I see it in the API that there is cases for public bluetooth address. However, I just can't seem to find how to change the addr-type to public. I see the #define BT_ADDRLE_PUBLIC 0x00 in  include/bluetooth/hci.h, but don't know how to implement it. Does anyone know how to do this?

Thanks,
Jie



Re: Problems with static variables and GNU map files

Paul Sokolovsky
 

Hello Marti,

On Wed, 25 Oct 2017 23:56:47 -0400
Marti Bolivar <marti.bolivar@linaro.org> wrote:

Why not just #define static SOMETHING_ELSE as needed?
Because "static" has different semantics in different contexts. For
example, we don't want to touch "static inline" functions. Though, based
on the number of changes, I guess it would be easier to add a #define
for static inline functions than for everything else...


On 19 October 2017 at 15:08, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:

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


--
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: Problems with static variables and GNU map files

Marti Bolivar <marti.bolivar@...>
 

Why not just #define static SOMETHING_ELSE as needed?

On 19 October 2017 at 15:08, Paul Sokolovsky <paul.sokolovsky@...> wrote:
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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
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)

Tomasz Bursztyka
 

Hi guys,

It was
posted as https://github.com/zephyrproject-rtos/zephyr/pull/119 . Again,
at that time, there was no consensus about way to solve it, so it was
implemented only for BSD Sockets API.

Much later,
https://github.com/zephyrproject-rtos/zephyr/pull/1330 was posted. It
works in following way: it allows an application to create an
oversized packet
(...)

There're many more
details than presented above, and the devil is definitely in details,
there's no absolutely "right" solution, it's a compromise. I hope that
Jukka and Tomasz, who are proponents of the second (GH-1330) approach
can correct me on the benefits of it.
Actually I missed the fact PR 1330 was about MTU handling. Does not sound generic enough.

In the end I don't approve both of the proposed solution. Let me explain why:

First, let's not rush on this MTU handling just yet, though it is much needed.
We first need this:

-> https://github.com/zephyrproject-rtos/zephyr/issues/3283

it will simplify a lot how packet are allocated. I haven't touched MTU stuff since
I did the net_pkt move because of this feature we'll use.

I foresee a lot of possible improvements with this issue resolved: certainly MTU handling, better memory
management than current frag model, but also better response against low memory (we could after all
send asap a tinier than MTU TCP segment if there was only a small amount of memory available,
and continue with the rest etc...).

Tomasz


Setup In Eclipse

JC <jordansspamfilter@...>
 

Hello All:

I've got a couple of questions on setting up a debug environment.

I'm running Ubuntu 16.04 LTS in a Virtualbox VM.  I'm using Eclipse Oxygen CDT for development and openOCD for debugging.  My target is an NRF52,  At this moment, I can build the code and successfully initiate debugging through eclipse.  

Here's what I see that I find strange:
1. Only one thread in the debug window.
2. Unpredictable result when stepping through the code.
3. Callstack makes zero sense.
4. Breakpoints don't seem to work correctly outside of application code.

I have to think I've not configured something correctly about my debug environment.  Does anyone have any ideas?

-JC


Re: Reaction to hard fault - how to reset instead of hang

Boie, Andrew P
 

The _SysFatalErrorHandler function (implemented under arch/) has the hard fault policy and is declared __weak. Applications may implement their own version of it.

HTH,
Andrew

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Laczen JMS
Sent: Monday, October 23, 2017 1:37 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Reaction to hard fault - how to reset instead of hang

Hi,

Sometimes I run into the situation where a hard fault is triggered (e.g. a
bluetooth mesh node with a BT_RX_STACK_SIZE that is set to small). The result
of this is a system hang. I can correct this by increasing the stack size but I am
uncertain that the new stack size will be big enough to handle whatever data is
send to the node.

Is it possible to make the device reset instead of hang ? Is there a configuration
option to set what the device needs to do in case of a hard fault ?

Kind regards,

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


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

laczenJMS
 

Hi Johan,

Thanks for the reply. It is clearly not possible to reduce the stack
usage of tinycrypt.

Regarding the coexisting of network state and provisioning state,
would it be possible to use the concept of memory slabs/memory pools
to allocate and free the respective states ? This might be easier then
to overlay.

Kind regards,

Jehudi

2017-10-20 16:51 GMT+02:00 Johan Hedberg <johan.hedberg@intel.com>:

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


Reaction to hard fault - how to reset instead of hang

laczenJMS
 

Hi,

Sometimes I run into the situation where a hard fault is triggered
(e.g. a bluetooth mesh node with a BT_RX_STACK_SIZE that is set to
small). The result of this is a system hang. I can correct this by
increasing the stack size but I am uncertain that the new stack size
will be big enough to handle whatever data is send to the node.

Is it possible to make the device reset instead of hang ? Is there a
configuration option to set what the device needs to do in case of a
hard fault ?

Kind regards,

Jehudi


Re: CI fails for pull request on arm branch

Kumar Gala
 

On Oct 23, 2017, at 9:45 AM, Wagenknecht, Daniel <Daniel.Wagenknecht@clage.de> wrote:

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!
Weird, I’ll try and look into this. I kicked off a re-build of your PR to see if that deals with it. It looks like there is a fix in master. I’ve updated the ‘arm’ branch against master, so if you can rebase your branch again, that should hopefully address the issue.

- k


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

 

4781 - 4800 of 8333