Date   
Re: Community input on possible change to Discord from Slack

Jett ✈ Rink
 

If Zephyr is non-profit (which it seems to be), then it will be eligible to sign up for G Suite for nonprofit which includes many features for free. I have personally set this up for two non-profits and it is pretty straightforward.

I agree that chat.google.com is very well hidden ;)

-Jett

On Tue, Jul 21, 2020 at 6:15 PM Nashif, Anas <anas.nashif@...> wrote:

Jett,

Zephyr project is not subscribed to any gsuite plans, free or paid. AFAIK we use google docs from LF in some areas. Maybe we should look into the non-profit “companies” option.

Never heard of chat.google.com, well hidden 😊

 

Anas

 

From: <devel@...> on behalf of "Jett Rink via lists.zephyrproject.org" <jettrink=google.com@...>
Reply to: "jettrink@..." <jettrink@...>
Date: Tuesday, 21 July 2020 at 19:17
To: Henrik Brix Andersen <henrik@...>
Cc: Kumar Gala <kumar.gala@...>, zephyr-devel <zephyr-devel@...>, Ryan Johnson via Zephyr-users <zephyr-users@...>
Subject: Re: [Zephyr-devel] Community input on possible change to Discord from Slack

 

I know that Zephyr uses Google docs already, and that Gsuite is free for non-profit companies. Have we considered chat.google.com as an alternative? It may be free or part of what Zephyr is already paying for. It has conversations/threads and history, etc.

 

-Jett

 

On Tue, Jul 21, 2020 at 3:23 AM Henrik Brix Andersen <henrik@...> wrote:

Hi all,

I have never used Discord before, but I given it a quick try the last couple of days.

My main concern is that Discord does not support threads (only quoting). This will cause all messages to go to the channel, making it more difficult to glance over the new topics.
It also makes it rather impossible to continue a discussion over several days or to follow up on a question or solution several days later, something that is often used on Slack today.

One of the bullets below lists shared accounts across servers as a pro for Discord. I am not so sure. The sign-on process was at least as difficult as with Slack.

Have we considered that once Discord settles on their business models, they too might start charging for unlimited message history?

Maybe it is just me, but there is also the question of familiarity with the service for our users.
It is my personal experience that many professionals within the embedded market know of Slack, but not many use Discord perhaps due to it being rooted in the gaming communities?

Regards,
Brix
--
Henrik Brix Andersen


> On 17 Jul 2020, at 00.27, Kumar Gala <kumar.gala@...> wrote:
>
> All,
>
> We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage.  The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.
>
> We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option.  A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).
>
> Some requirements for Zephyr chat platform:
> * Maintain history
> * integration with other services (like GitHub)
> * private channels
> * ideally free - or low cost
> * no overhead for Zephyr Project (ie not having to run our own server).
>
> Pros of Discord:
> * Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
> * Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
> * Unlimited history for free.
> * Easy to join via invite link, chat and then establish an account.
>
> Cons of Discord:
> * Can get spammy when publicly listed.
> * Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
> * Closed source so interop with Matrix and IRC is tricky but doable.
>
> We’d like to get any feedback from the community at large before finalizing a decision in the TSC.  The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.
>
> Thanks
>
> A few links:
> * Current Open Source communities utilizing Discord: https://discord.com/open-source
> * Zephyr Discord: https://discord.gg/28BgkM
>
> (NOTE: The Zephyr Discord is setup for testing purposes at this time)
>
>



Re: Community input on possible change to Discord from Slack

Nashif, Anas
 

Jett,

Zephyr project is not subscribed to any gsuite plans, free or paid. AFAIK we use google docs from LF in some areas. Maybe we should look into the non-profit “companies” option.

Never heard of chat.google.com, well hidden 😊

 

Anas

 

From: <devel@...> on behalf of "Jett Rink via lists.zephyrproject.org" <jettrink=google.com@...>
Reply to: "jettrink@..." <jettrink@...>
Date: Tuesday, 21 July 2020 at 19:17
To: Henrik Brix Andersen <henrik@...>
Cc: Kumar Gala <kumar.gala@...>, zephyr-devel <zephyr-devel@...>, Ryan Johnson via Zephyr-users <zephyr-users@...>
Subject: Re: [Zephyr-devel] Community input on possible change to Discord from Slack

 

I know that Zephyr uses Google docs already, and that Gsuite is free for non-profit companies. Have we considered chat.google.com as an alternative? It may be free or part of what Zephyr is already paying for. It has conversations/threads and history, etc.

 

-Jett

 

On Tue, Jul 21, 2020 at 3:23 AM Henrik Brix Andersen <henrik@...> wrote:

Hi all,

I have never used Discord before, but I given it a quick try the last couple of days.

My main concern is that Discord does not support threads (only quoting). This will cause all messages to go to the channel, making it more difficult to glance over the new topics.
It also makes it rather impossible to continue a discussion over several days or to follow up on a question or solution several days later, something that is often used on Slack today.

One of the bullets below lists shared accounts across servers as a pro for Discord. I am not so sure. The sign-on process was at least as difficult as with Slack.

Have we considered that once Discord settles on their business models, they too might start charging for unlimited message history?

Maybe it is just me, but there is also the question of familiarity with the service for our users.
It is my personal experience that many professionals within the embedded market know of Slack, but not many use Discord perhaps due to it being rooted in the gaming communities?

Regards,
Brix
--
Henrik Brix Andersen


> On 17 Jul 2020, at 00.27, Kumar Gala <kumar.gala@...> wrote:
>
> All,
>
> We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage.  The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.
>
> We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option.  A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).
>
> Some requirements for Zephyr chat platform:
> * Maintain history
> * integration with other services (like GitHub)
> * private channels
> * ideally free - or low cost
> * no overhead for Zephyr Project (ie not having to run our own server).
>
> Pros of Discord:
> * Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
> * Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
> * Unlimited history for free.
> * Easy to join via invite link, chat and then establish an account.
>
> Cons of Discord:
> * Can get spammy when publicly listed.
> * Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
> * Closed source so interop with Matrix and IRC is tricky but doable.
>
> We’d like to get any feedback from the community at large before finalizing a decision in the TSC.  The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.
>
> Thanks
>
> A few links:
> * Current Open Source communities utilizing Discord: https://discord.com/open-source
> * Zephyr Discord: https://discord.gg/28BgkM
>
> (NOTE: The Zephyr Discord is setup for testing purposes at this time)
>
>



Re: Community input on possible change to Discord from Slack

Nashif, Anas
 

I am not saying IRC is a quality chat client, but the model works in that you can also chat without threads, and it has been done and is being done in many places already. I personally find threads an annoyance in slack and is usually where I miss most of the conversations. Keeping an eye on the inflow of messages while doing something else and jumping in when interested is not something that is possible with threads, you basically have to click and open threads to see what is going on.

Anas

On 21/07/2020, 20:01, "devel@... on behalf of Bolivar, Marti" <devel@... on behalf of marti.bolivar@...> wrote:

Age is not necessarily a sign of quality. Usenet is still around in some
form or another, but nobody is advocating we use it for Zephyr, are they?

I think the IRC style of simultaneously carrying on multiple unrelated
conversations in the same channel using nicks hard to read and find
threads much more readable. Just my two cents.

"Nashif, Anas via lists.zephyrproject.org"
<anas.nashif=intel.com@...> writes:

It depends who you ask, lots of people actually do not care or like threads the way they are implemented in Slack. This is basically a place where conversation just get buried.
> IRC did not have threads, yet it is still there after almost 30 years.
>
> Anas
>
> From: <devel@...> on behalf of "Peter A. Bigot" <pab@...>
> Date: Tuesday, 21 July 2020 at 19:41
> To: "devel@..." <devel@...>
> Subject: Re: [Zephyr-devel] Community input on possible change to Discord from Slack
>
> Are we tracking the Zephyr requirements for a chat server anywhere, and assessing them against a list of candidate services?
>
> Based on some trials at https://discord.com/channels/720317445772017664/720317445772017667/734352748396413051 I think thread support should be a requirement, and that Discord doesn't satisfy it.
>
> Peter
>
>
>

Re: Community input on possible change to Discord from Slack

Bolivar, Marti
 

Age is not necessarily a sign of quality. Usenet is still around in some
form or another, but nobody is advocating we use it for Zephyr, are they?

I think the IRC style of simultaneously carrying on multiple unrelated
conversations in the same channel using nicks hard to read and find
threads much more readable. Just my two cents.

"Nashif, Anas via lists.zephyrproject.org"
<anas.nashif=intel.com@...> writes:

It depends who you ask, lots of people actually do not care or like threads the way they are implemented in Slack. This is basically a place where conversation just get buried.
IRC did not have threads, yet it is still there after almost 30 years.

Anas

From: <devel@...> on behalf of "Peter A. Bigot" <pab@...>
Date: Tuesday, 21 July 2020 at 19:41
To: "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] Community input on possible change to Discord from Slack

Are we tracking the Zephyr requirements for a chat server anywhere, and assessing them against a list of candidate services?

Based on some trials at https://discord.com/channels/720317445772017664/720317445772017667/734352748396413051 I think thread support should be a requirement, and that Discord doesn't satisfy it.

Peter


Re: Community input on possible change to Discord from Slack

Nashif, Anas
 

It depends who you ask, lots of people actually do not care or like threads the way they are implemented in Slack. This is basically a place where conversation just get buried.

IRC did not have threads, yet it is still there after almost 30 years.

 

Anas

 

From: <devel@...> on behalf of "Peter A. Bigot" <pab@...>
Date: Tuesday, 21 July 2020 at 19:41
To: "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] Community input on possible change to Discord from Slack

 

Are we tracking the Zephyr requirements for a chat server anywhere, and assessing them against a list of candidate services?

Based on some trials at https://discord.com/channels/720317445772017664/720317445772017667/734352748396413051 I think thread support should be a requirement, and that Discord doesn't satisfy it.

Peter

Re: Community input on possible change to Discord from Slack

Peter A. Bigot
 

Are we tracking the Zephyr requirements for a chat server anywhere, and assessing them against a list of candidate services?

Based on some trials at https://discord.com/channels/720317445772017664/720317445772017667/734352748396413051 I think thread support should be a requirement, and that Discord doesn't satisfy it.

Peter

Re: Community input on possible change to Discord from Slack

Jett ✈ Rink
 

I know that Zephyr uses Google docs already, and that Gsuite is free for non-profit companies. Have we considered chat.google.com as an alternative? It may be free or part of what Zephyr is already paying for. It has conversations/threads and history, etc.

-Jett

On Tue, Jul 21, 2020 at 3:23 AM Henrik Brix Andersen <henrik@...> wrote:
Hi all,

I have never used Discord before, but I given it a quick try the last couple of days.

My main concern is that Discord does not support threads (only quoting). This will cause all messages to go to the channel, making it more difficult to glance over the new topics.
It also makes it rather impossible to continue a discussion over several days or to follow up on a question or solution several days later, something that is often used on Slack today.

One of the bullets below lists shared accounts across servers as a pro for Discord. I am not so sure. The sign-on process was at least as difficult as with Slack.

Have we considered that once Discord settles on their business models, they too might start charging for unlimited message history?

Maybe it is just me, but there is also the question of familiarity with the service for our users.
It is my personal experience that many professionals within the embedded market know of Slack, but not many use Discord perhaps due to it being rooted in the gaming communities?

Regards,
Brix
--
Henrik Brix Andersen


> On 17 Jul 2020, at 00.27, Kumar Gala <kumar.gala@...> wrote:
>
> All,
>
> We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage.  The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.
>
> We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option.  A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).
>
> Some requirements for Zephyr chat platform:
> * Maintain history
> * integration with other services (like GitHub)
> * private channels
> * ideally free - or low cost
> * no overhead for Zephyr Project (ie not having to run our own server).
>
> Pros of Discord:
> * Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
> * Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
> * Unlimited history for free.
> * Easy to join via invite link, chat and then establish an account.
>
> Cons of Discord:
> * Can get spammy when publicly listed.
> * Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
> * Closed source so interop with Matrix and IRC is tricky but doable.
>
> We’d like to get any feedback from the community at large before finalizing a decision in the TSC.  The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.
>
> Thanks
>
> A few links:
> * Current Open Source communities utilizing Discord: https://discord.com/open-source
> * Zephyr Discord: https://discord.gg/28BgkM
>
> (NOTE: The Zephyr Discord is setup for testing purposes at this time)
>
>




Zephyr Project: APIs - Tue, 07/21/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 21 July 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________

API meeting: agenda

Carles Cufi
 

Re: Community input on possible change to Discord from Slack

Henrik Brix Andersen
 

Hi all,

I have never used Discord before, but I given it a quick try the last couple of days.

My main concern is that Discord does not support threads (only quoting). This will cause all messages to go to the channel, making it more difficult to glance over the new topics.
It also makes it rather impossible to continue a discussion over several days or to follow up on a question or solution several days later, something that is often used on Slack today.

One of the bullets below lists shared accounts across servers as a pro for Discord. I am not so sure. The sign-on process was at least as difficult as with Slack.

Have we considered that once Discord settles on their business models, they too might start charging for unlimited message history?

Maybe it is just me, but there is also the question of familiarity with the service for our users.
It is my personal experience that many professionals within the embedded market know of Slack, but not many use Discord perhaps due to it being rooted in the gaming communities?

Regards,
Brix
--
Henrik Brix Andersen

On 17 Jul 2020, at 00.27, Kumar Gala <kumar.gala@...> wrote:

All,

We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage. The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.

We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option. A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).

Some requirements for Zephyr chat platform:
* Maintain history
* integration with other services (like GitHub)
* private channels
* ideally free - or low cost
* no overhead for Zephyr Project (ie not having to run our own server).

Pros of Discord:
* Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
* Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
* Unlimited history for free.
* Easy to join via invite link, chat and then establish an account.

Cons of Discord:
* Can get spammy when publicly listed.
* Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
* Closed source so interop with Matrix and IRC is tricky but doable.

We’d like to get any feedback from the community at large before finalizing a decision in the TSC. The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.

Thanks

A few links:
* Current Open Source communities utilizing Discord: https://discord.com/open-source
* Zephyr Discord: https://discord.gg/28BgkM

(NOTE: The Zephyr Discord is setup for testing purposes at this time)

Re: arm: cortex_r: config_userspace: nested interrupt level is not decremented following syscall

Phil Erwin Jr
 

Hi Andrew,

I opened GH issue #26912, and Stephanos is assigned to it.

My platform is an internal chip, that has an R5 core.  I'm fairly certain that one of our team members uses QEMU, though, so I'll check with him to see if we need to up-stream anything to get that working.  It sure would be nice to close this testing hole with each upgrade.

Phil


From: Boie, Andrew P <andrew.p.boie@...>
Sent: 17 July 2020 7:08 PM
To: Phil Erwin Jr <phil.erwin@...>; devel@... <devel@...>
Subject: RE: [Zephyr-devel] arm: cortex_r: config_userspace: nested interrupt level is not decremented following syscall
 
  • In v2.3 when building with CONFIG_USERSPACE enabled, I see that we do not do a context switch a short time after POR.  I've chased this back and found the the cpus[0].nested has incremented to 6, so the code in z_arm_int_exit() thinks we are in a nested interrupt, and does not switch to another task.

 

Hi Phil, can you open a GH issue on this? Stephanos or maybe Ioannis may want to take a look at it.

 

Also, what platform do you use to test user mode on cortex-R? qemu_cortex_r5 doesn't work with it (gaps in emulation support for the MPU perhaps?)

 

Andrew

Re: arm: cortex_r: config_userspace: nested interrupt level is not decremented following syscall

Boie, Andrew P
 

  • In v2.3 when building with CONFIG_USERSPACE enabled, I see that we do not do a context switch a short time after POR.  I've chased this back and found the the cpus[0].nested has incremented to 6, so the code in z_arm_int_exit() thinks we are in a nested interrupt, and does not switch to another task.

 

Hi Phil, can you open a GH issue on this? Stephanos or maybe Ioannis may want to take a look at it.

 

Also, what platform do you use to test user mode on cortex-R? qemu_cortex_r5 doesn't work with it (gaps in emulation support for the MPU perhaps?)

 

Andrew

Re: MCUMGR - sends responses to wrong port

Lawrence King
 

Thanks Charles.

 

Bug #26939 filed…. Let me know if there is any other info I can provide.

 

https://github.com/zephyrproject-rtos/zephyr/issues/26939

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Friday, July 17, 2020 4:49 AM
To: Lawrence King <lawrence.king@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Lawrence,

 

Right, I think I understand what you mean. This is almost certainly a bug in the SMP shell transport, but just to make sure, please:

 

  • Create an issue on GitHub with this description
  • Include the prj.conf and .config files, so we can see if you are using CONFIG_MCUMGR_SMP_SHELL or CONFIG_MCUMGR_SMP_UART as a transport
  • Include the .dts file as well so we can make sure we see the aliases defined

 

Thanks,

 

Carles

 

 

From: Lawrence King <lawrence.king@...>
Sent: 17 July 2020 01:52
To: Cufi, Carles <Carles.Cufi@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Charles,

 

I tried your suggestion, unfortunately it doesn’t help. Every dts that uses mcumgr, also has the console on the same port, there is no existing board that routes the mcumgr to a different place than the console. Hence you would never have seen this issue.

 

The function smp_shell_tx_raw() in subsys/mgmt/smp_shell.c is hard coded to always send the response via k_str_out(). k_str_out() is part of  lib/os/printk and calls __char_out(). The function __char_out() is hooked into printk with the function __printk_hook_install() very early in the kernel boot phases and all the places that the hook is installed always installs it to the console.

 

The shell can be run on any port, not just the console, and we can add mcumgr to the shell. When the shell is running on a different port it is correctly passing the received data to smp_shell, its just that smp_shell sends the reply out to the console, and not to the port the shell is running on.

 

When smp_uart.c is ready to transmit a packet it calls mcumgr_serial_tx_pkt(), which then breaks the packet into frames and calls mcumgr_serial_tx_frame(). In turn mcumgr_serial_tx_frame() breaks the frame into bytes and calls mcumgr_serial_tx_small(). mcumgr_serial_tx_small() then base64 encodes the bytes and calls the mcumgr_serial_tx_cb to send 4 chars. Up to this point is all looking like it should. A pointer (cb) to the tx callback was passed all along this chain, so it should be possible to route the reply packet to the correct port.

 

Unfortunately when smp_shell_tx_pkt() called mcumgr_serial_tx_pkt() it passed a pointer to the function smp_shell_tx_raw() as the transmit callback. smp_shell_tx_raw is hard coded to send to the console, not the port the shell is running on. When smp_shell_init() was called it was passed a device pointer which is the device that the packets are coming in on, and going out on. But smp_shell_init() threw away this information when it called zephyr_smp_transport_init(). Uart_mcumgr does a little better than smp_shell, it also throws away the device information, but instead of being hard coded to the console, it outputs data to CONFIG_UART_MCUMGR_ON_DEV_NAME.

 

 

 

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Thursday, July 16, 2020 5:15 AM
To: Lawrence King <lawrence.king@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Lawrence,

 

Try instead using the .dts in your board, or add an overlay, and change this line:

 

zephyr,uart-mcumgr = &uart0;

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Lawrence King via lists.zephyrproject.org
Sent: 15 July 2020 23:20
To: zephyr-devel@...; Zephyr-users@...
Subject: [Zephyr-devel] MCUMGR - sends responses to wrong port

 

Dear All:

 

I am trying to setup mcumgr to allow code download over a serial port and use the shell. In this case I have 2 serial ports in play.

 

The first serial port is where printk() sends messages. I also have a simple command parser on the port that interprets single letter commands. This printk and my command parser work as expected.

 

The second serial port is running a shell. Commands like ‘help’ and ‘fs ls’ work as expected, output appears on the second port. However when I attempt to send a file or image update using mcumgr to the second serial port, it doesn’t work. The initial packet arrives on the serial port, smp_shell recognizes the packet, formulates a response, and then sends the response to the first serial port, not the second serial port as it should. LOG messages also come out on the second port as expected.

 

I chased the  problem as far as I can. In smp_shell.c the function smp_shell_tx_raw() always sends the packet via k_str_out(). It should be sending the packet back by shell_print(). Unfortunately the function smp_shell_tx_raw doesn’t have access to the handle for the shell.

 

I did try setting CONFIG_UART_MCUMGR_ON_DEV_NAME but k_str_out() ignores this setting….

 

Any suggestions on how to fix this? Or am I doing something wrong?

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 

[RFC] API change - Normalize DMA, IPM and UART callbacks signatures including the caller's device pointer.

Tomasz Bursztyka
 

Hello,

You will find the github issue here
https://github.com/zephyrproject-rtos/zephyr/issues/26923

Which describes the changes.
PRs are already done and linked there as
well.


Tomasz

Re: MCUMGR - sends responses to wrong port

Carles Cufi
 

Hi Lawrence,

 

Right, I think I understand what you mean. This is almost certainly a bug in the SMP shell transport, but just to make sure, please:

 

  • Create an issue on GitHub with this description
  • Include the prj.conf and .config files, so we can see if you are using CONFIG_MCUMGR_SMP_SHELL or CONFIG_MCUMGR_SMP_UART as a transport
  • Include the .dts file as well so we can make sure we see the aliases defined

 

Thanks,

 

Carles

 

 

From: Lawrence King <lawrence.king@...>
Sent: 17 July 2020 01:52
To: Cufi, Carles <Carles.Cufi@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Charles,

 

I tried your suggestion, unfortunately it doesn’t help. Every dts that uses mcumgr, also has the console on the same port, there is no existing board that routes the mcumgr to a different place than the console. Hence you would never have seen this issue.

 

The function smp_shell_tx_raw() in subsys/mgmt/smp_shell.c is hard coded to always send the response via k_str_out(). k_str_out() is part of  lib/os/printk and calls __char_out(). The function __char_out() is hooked into printk with the function __printk_hook_install() very early in the kernel boot phases and all the places that the hook is installed always installs it to the console.

 

The shell can be run on any port, not just the console, and we can add mcumgr to the shell. When the shell is running on a different port it is correctly passing the received data to smp_shell, its just that smp_shell sends the reply out to the console, and not to the port the shell is running on.

 

When smp_uart.c is ready to transmit a packet it calls mcumgr_serial_tx_pkt(), which then breaks the packet into frames and calls mcumgr_serial_tx_frame(). In turn mcumgr_serial_tx_frame() breaks the frame into bytes and calls mcumgr_serial_tx_small(). mcumgr_serial_tx_small() then base64 encodes the bytes and calls the mcumgr_serial_tx_cb to send 4 chars. Up to this point is all looking like it should. A pointer (cb) to the tx callback was passed all along this chain, so it should be possible to route the reply packet to the correct port.

 

Unfortunately when smp_shell_tx_pkt() called mcumgr_serial_tx_pkt() it passed a pointer to the function smp_shell_tx_raw() as the transmit callback. smp_shell_tx_raw is hard coded to send to the console, not the port the shell is running on. When smp_shell_init() was called it was passed a device pointer which is the device that the packets are coming in on, and going out on. But smp_shell_init() threw away this information when it called zephyr_smp_transport_init(). Uart_mcumgr does a little better than smp_shell, it also throws away the device information, but instead of being hard coded to the console, it outputs data to CONFIG_UART_MCUMGR_ON_DEV_NAME.

 

 

 

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Thursday, July 16, 2020 5:15 AM
To: Lawrence King <lawrence.king@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Lawrence,

 

Try instead using the .dts in your board, or add an overlay, and change this line:

 

zephyr,uart-mcumgr = &uart0;

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Lawrence King via lists.zephyrproject.org
Sent: 15 July 2020 23:20
To: zephyr-devel@...; Zephyr-users@...
Subject: [Zephyr-devel] MCUMGR - sends responses to wrong port

 

Dear All:

 

I am trying to setup mcumgr to allow code download over a serial port and use the shell. In this case I have 2 serial ports in play.

 

The first serial port is where printk() sends messages. I also have a simple command parser on the port that interprets single letter commands. This printk and my command parser work as expected.

 

The second serial port is running a shell. Commands like ‘help’ and ‘fs ls’ work as expected, output appears on the second port. However when I attempt to send a file or image update using mcumgr to the second serial port, it doesn’t work. The initial packet arrives on the serial port, smp_shell recognizes the packet, formulates a response, and then sends the response to the first serial port, not the second serial port as it should. LOG messages also come out on the second port as expected.

 

I chased the  problem as far as I can. In smp_shell.c the function smp_shell_tx_raw() always sends the packet via k_str_out(). It should be sending the packet back by shell_print(). Unfortunately the function smp_shell_tx_raw doesn’t have access to the handle for the shell.

 

I did try setting CONFIG_UART_MCUMGR_ON_DEV_NAME but k_str_out() ignores this setting….

 

Any suggestions on how to fix this? Or am I doing something wrong?

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 

Re: MCUMGR - sends responses to wrong port

Lawrence King
 

Hi Charles,

 

I tried your suggestion, unfortunately it doesn’t help. Every dts that uses mcumgr, also has the console on the same port, there is no existing board that routes the mcumgr to a different place than the console. Hence you would never have seen this issue.

 

The function smp_shell_tx_raw() in subsys/mgmt/smp_shell.c is hard coded to always send the response via k_str_out(). k_str_out() is part of  lib/os/printk and calls __char_out(). The function __char_out() is hooked into printk with the function __printk_hook_install() very early in the kernel boot phases and all the places that the hook is installed always installs it to the console.

 

The shell can be run on any port, not just the console, and we can add mcumgr to the shell. When the shell is running on a different port it is correctly passing the received data to smp_shell, its just that smp_shell sends the reply out to the console, and not to the port the shell is running on.

 

When smp_uart.c is ready to transmit a packet it calls mcumgr_serial_tx_pkt(), which then breaks the packet into frames and calls mcumgr_serial_tx_frame(). In turn mcumgr_serial_tx_frame() breaks the frame into bytes and calls mcumgr_serial_tx_small(). mcumgr_serial_tx_small() then base64 encodes the bytes and calls the mcumgr_serial_tx_cb to send 4 chars. Up to this point is all looking like it should. A pointer (cb) to the tx callback was passed all along this chain, so it should be possible to route the reply packet to the correct port.

 

Unfortunately when smp_shell_tx_pkt() called mcumgr_serial_tx_pkt() it passed a pointer to the function smp_shell_tx_raw() as the transmit callback. smp_shell_tx_raw is hard coded to send to the console, not the port the shell is running on. When smp_shell_init() was called it was passed a device pointer which is the device that the packets are coming in on, and going out on. But smp_shell_init() threw away this information when it called zephyr_smp_transport_init(). Uart_mcumgr does a little better than smp_shell, it also throws away the device information, but instead of being hard coded to the console, it outputs data to CONFIG_UART_MCUMGR_ON_DEV_NAME.

 

 

 

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Thursday, July 16, 2020 5:15 AM
To: Lawrence King <lawrence.king@...>; zephyr-devel@...; Zephyr-users@...
Subject: RE: MCUMGR - sends responses to wrong port

 

Hi Lawrence,

 

Try instead using the .dts in your board, or add an overlay, and change this line:

 

zephyr,uart-mcumgr = &uart0;

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Lawrence King via lists.zephyrproject.org
Sent: 15 July 2020 23:20
To: zephyr-devel@...; Zephyr-users@...
Subject: [Zephyr-devel] MCUMGR - sends responses to wrong port

 

Dear All:

 

I am trying to setup mcumgr to allow code download over a serial port and use the shell. In this case I have 2 serial ports in play.

 

The first serial port is where printk() sends messages. I also have a simple command parser on the port that interprets single letter commands. This printk and my command parser work as expected.

 

The second serial port is running a shell. Commands like ‘help’ and ‘fs ls’ work as expected, output appears on the second port. However when I attempt to send a file or image update using mcumgr to the second serial port, it doesn’t work. The initial packet arrives on the serial port, smp_shell recognizes the packet, formulates a response, and then sends the response to the first serial port, not the second serial port as it should. LOG messages also come out on the second port as expected.

 

I chased the  problem as far as I can. In smp_shell.c the function smp_shell_tx_raw() always sends the packet via k_str_out(). It should be sending the packet back by shell_print(). Unfortunately the function smp_shell_tx_raw doesn’t have access to the handle for the shell.

 

I did try setting CONFIG_UART_MCUMGR_ON_DEV_NAME but k_str_out() ignores this setting….

 

Any suggestions on how to fix this? Or am I doing something wrong?

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 

Community input on possible change to Discord from Slack

Kumar Gala
 

All,

We’ve had a few discussion in the Zephyr TSC regarding the need for maintaining history in our chat communication platform and the limitation that Slack imposes on this for free usage. The general feeling is that having access to historical discussions is important for the continued growth of the Zephyr community.

We have tried to engage Slack on a cost effective solution but unfortunately that does not appear to be an option. A few different options that have been evaluated (Discord, matrix.org, rocket chat, Microsoft Teams) and Discord seemed to be the best option and has had a fair amount of history with Adafruit (a Silver Member).

Some requirements for Zephyr chat platform:
* Maintain history
* integration with other services (like GitHub)
* private channels
* ideally free - or low cost
* no overhead for Zephyr Project (ie not having to run our own server).

Pros of Discord:
* Shared accounts across "servers" which are really just communities. Makes joining a new server very fast and easy.
* Strong moderation tools (mute, ban, kick) per server. No need to wait for Discord to help.
* Unlimited history for free.
* Easy to join via invite link, chat and then establish an account.

Cons of Discord:
* Can get spammy when publicly listed.
* Still in the startup phase so they are experimenting with business models. Currently "Nitro" subscription which unlocks server capabilities: https://discord.com/new/nitro
* Closed source so interop with Matrix and IRC is tricky but doable.

We’d like to get any feedback from the community at large before finalizing a decision in the TSC. The topic will be on the July 29th TSC meeting and will review any email feedback that anyone has on the topic.

Thanks

A few links:
* Current Open Source communities utilizing Discord: https://discord.com/open-source
* Zephyr Discord: https://discord.gg/28BgkM

(NOTE: The Zephyr Discord is setup for testing purposes at this time)

arm: cortex_r: config_userspace: nested interrupt level is not decremented following syscall

Phil Erwin Jr
 

In v2.3 when building with CONFIG_USERSPACE enabled, I see that we do not do a context switch a short time after POR.  I've chased this back and found the the cpus[0].nested has incremented to 6, so the code in z_arm_int_exit() thinks we are in a nested interrupt, and does not switch to another task.

The flaw is because of our syscall path.  On each syscall, we increment the nested count upon entry to the SVC (z_arm_svc in swap_helper.S), but then we go through z_arm_do_syscall (userspace.S) and return from the syscall without ever decrementing nested. 

The Cortex M code appears to work the same way to me.

It seems to me that the system call should exit by means of branching to z_arm_exc_exit, as is done elsewhere.

Comments?

Phil

Zephyr Project: Dev Meeting - Thu, 07/16/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 16 July 2020, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________

Dev-Review Meeting Agenda Jul 16

Kumar Gala
 

Here’s the agenda topics for this week:

* Any PR/issues w/dev-review tag [ https://github.com/zephyrproject-rtos/zephyr/labels/dev-review ]

- lib: gui: lvgl: add support for v7.0.2
[ https://github.com/zephyrproject-rtos/zephyr/pull/26654 ]

* Any topics anyone else has.

- k