Date   

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


Re: MCUMGR - sends responses to wrong port

Carles Cufi
 

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.

 

 

 


GH auto-close policy

Boie, Andrew P
 

Hi All,

 

I think we need to re-examine the current policy of auto-closing bugs after 60 days of no activity. I understand the intent, we don't want stale bugs lying around, but I think what we have now introduces some bad incentives.

 

The current policy that was recently introduced is, AFAICT:

  • If a bug is idle for 60 days, a warning is posted to the GH ticket
  • If the warning is not responded to within 14 days, the bug is closed.

 

This unfortunately creates an incentive for bug assignees to simply ignore bugs that are assigned to them, as after a while they will go away.

The onus is currently on the *reporter* to keep these bugs from auto-closing. Because it's the reporter who cared enough to open the bug report to begin with. The assignee may not care at all, or have bigger fish to fry.

 

I will freely admit to ignoring some P3 bugs assigned to me by the Coverity-Bot, I'd probably get around to them eventually if someone started bugging me about them, but as it stands now they just got auto-closed a few days ago and now I probably don't have to worry about them ever!

I know that I've filed several P3 issues against x86_64 that I assigned to myself that I don't plan on getting around to for a while, but I would very much not like to lose the information that these bugs exist at all!

 

As it stands now, as someone who opens a lot of bugs, of varying priority levels, I have to either:

  • Monitor all my GitHub emails, every day, for warnings that some bug I opened that the assignee ignored is about to be auto-closed. I get hundreds to over a thousand GitHub emails every day.
  • On a bi-weekly basis, review every single bug I've opened to check for warnings from github-actions and prod them so they don't get auto-closed. I currently have 27 bugs open that I reported. I don't know how many have been auto-closed already.

 

Maybe this was all anticipated and that's how we want it. But if not I think the current policy needs to be thought about some more, and while that's taking place I ask that this mechanism be disabled.

 

Andrew


MCUMGR - sends responses to wrong port

Lawrence King
 

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: QEMU networking problem - has anyone ever run into this problem?

Jett ✈ Rink
 

Can you post what you figured out for posterity sake in case anyone else runs into the same issue?


On Tue, Jul 14, 2020 at 6:55 AM Immo Birnbaum <immo.birnbaum@...> wrote:
Nevermind, I figured it out...


RFC: subsys: fs: Support file open flags to fs and POSIX API

Ermel, Dominik
 

Hi,

 

There is proposal for change to fs_open, within Zephyr FS API. You are invited to post your comments here https://github.com/zephyrproject-rtos/zephyr/issues/26833 .

 

Thanks in advance and best regards,

Dominik Ermel

 

Dominik ERMEL | Senior Software Engineer
M +48 505 071 130 | Kraków, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 


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

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

Reminder: Zephyr Project: APIs

When: Tuesday, 14 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
 
 
________________________________________________________________________________


app external lib use zephyr driver fail

FrankLi
 

Hi guys,
I refer to external_lib sample create a app external lib , in external lib source code include "driver/display.h".
during build, show below error message, It seems that extern lib is generated before syscall, which will cause dependency problems. Is there a way to adjust extern lib to syscall and compile it?
My code base is v2.2.0
In file included from /mnt/e/westz/zephyrproject/zephyr/include/kernel_includes.h:32,
                 from /mnt/e/westz/zephyrproject/zephyr/include/kernel.h:17,
                 from /mnt/e/westz/zephyrproject/zephyr/include/device.h:10,
                 from /mnt/e/westz/zephyrproject/zephyr/include/drivers/display.h:22,
                 from src/SwiftDisplay.c:1:
/mnt/e/westz/zephyrproject/zephyr/include/syscall.h:11:10: fatal error: syscall_list.h: No such file or directory
   11 | #include <syscall_list.h>


Re: QEMU networking problem - has anyone ever run into this problem?

Immo Birnbaum
 

Nevermind, I figured it out...


API meeting: agenda

Carles Cufi
 

Hi all,

Tomorrow's topics:

- Conclusion on fs_open() flags Stable API Change:
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/26833

- RFC: Require system clock stability on startup
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/22758

- hwinfo reset cause support
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/24884

- drivers: ethernet: unify the initialization (if stakeholders present)
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/21452

- Go through issues in the In Progress column to clean them up

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


RFC: API Change: watchdog: wdt_feed error codes

Peter A. Bigot
 

The API change proposed here and summarized below has been completed.

Following https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html#stable we have a need to make a small change to the watchdog API that meets the criteria of "...forces users to modify their existing code in order to maintain the current behavior of their application".

Please see: https://github.com/zephyrproject-rtos/zephyr/issues/26708

Peter