- Openamp-rp - lists.openampproject.org

[OpenAMP/open-amp] 38aed4: rpmsg: virito: limit the buffer allocate from shar...

by Xiang Xiao

Branch: refs/heads/master Home: https://github.com/OpenAMP/open-amp Commit: 38aed4aae4d82f06ede060290cbbaf421c54d8f3 https://github.com/OpenAMP/open-amp/commit/38aed4aae4d82f06ede060290cbbaf42… Author: Xiang Xiao <xiaoxiang(a)xiaomi.com> Date: 2020-11-09 (Mon, 09 Nov 2020) Changed paths: M lib/rpmsg/rpmsg_virtio.c Log Message: ----------- rpmsg: virito: limit the buffer allocate from shared memory pool rpmsg_virtio_get_tx_buffer shouldn't allocate the number of buffer bigger than the virtio ring length of sending Signed-off-by: Xiang Xiao <xiaoxiang(a)xiaomi.com>

4 years, 7 months

1
0
0 0

Re: [Openamp-rp] OpenAMP-rp meeting in 30 min

by Bill Mills

Hello, On 11/5/20 10:31 AM, Bill Mills via Openamp-rp wrote: > Hello, > > We have our normal b-weekly meeting starting in 30 min. > If you need the invite please let me know. > As promised I have published notes from today at: https://github.com/OpenAMP/open-amp/wiki/OpenAMP-remoteproc-Subgroup-Meetin… I also added a section to record your suggested agenda items for the next call on Nov 19. (In addition to standing update items) Thanks, Bill

4 years, 8 months

1
0
0 0

[OpenAMP/open-amp] 8e6fb7: rename size parameter to len for rpmsg_send_offcha...

by Xiang Xiao

Branch: refs/heads/master Home: https://github.com/OpenAMP/open-amp Commit: 8e6fb738438fc828f53cc51c96b76ab193760c9e https://github.com/OpenAMP/open-amp/commit/8e6fb738438fc828f53cc51c96b76ab1… Author: Xiang Xiao <xiaoxiang(a)xiaomi.com> Date: 2020-11-05 (Thu, 05 Nov 2020) Changed paths: M lib/include/openamp/rpmsg.h M lib/rpmsg/rpmsg.c M lib/rpmsg/rpmsg_virtio.c Log Message: ----------- rename size parameter to len for rpmsg_send_offchannel_raw to align with other rpmsg_send_xxx function naming convention Signed-off-by: Xiang Xiao <xiaoxiang(a)xiaomi.com>

4 years, 8 months

1
0
0 0

OpenAMP-rp meeting in 30 min

by Bill Mills

Hello, We have our normal b-weekly meeting starting in 30 min. If you need the invite please let me know. Thanks, Bill;

4 years, 8 months

1
0
0 0

Re: [Openamp-rp] Libmetal and SCHED_FIFO thread with priority 99

by Arnaud POULIQUEN

Hello Eduardo, On 10/26/20 9:59 AM, Eduardo Viruete via Openamp-rp wrote: > Hello, > > > I’m using a Linux userspace application with Libmetal to communicate > core 0 (Linux) and core 1 (FreeRTOS) in a Zynq 7000. The application > is very simple, as it only forwards messages between cores and works > very well, but I have noticed that it creates an additional thread > automatically. I suspect this is because of Libmetal, as OpenAMP’s > wiki states: > > > “The Linux userspace implementation will use a thread to call select() > function to listen to the file descriptors of the devices to see if > there is an interrupt triggered. If there is an interrupt triggered, it > will call the interrupt handler registered by the user application.” > > > However, I was planning system priorities to configure the userspace > watchdog daemon and noticed that this thread has SCHED_FIFO scheduling > policy with a priority of 99 (the highest possible). This priority is > above all my userspace applications, including the watchdog daemon, and > even above several kernel threads, which worries me. > > > The code responsible for this behavior is inside > libmetal/lib/system/linux/irq.c, function metal_linux_irq_handling(void > * args): > > > param.sched_priority = sched_get_priority_max(SCHED_FIFO); > > /* Ignore the set scheduler error */ > > ret = sched_setscheduler(0, SCHED_FIFO, &param); > > > My question is: can I lower the priority of this thread? If the answer > is yes, what would be the minimum required priority for Libmetal to > operate properly? The libmetal is a porting layer that you can customize according to your platform and your project. So yes, you can lower the priority, I can't give you a minimum value because it depends on your needs. The impact can be the latency of your Linux to process PR messages (but anyway, Linux does not guarantee maximum latency). Regards, Arnaud > > > Thank you very much and best regards, > > > Eduardo. > > > Eduardo Viruete > > Software Engineer > > Teltronic > > Tel: +34 976 465656 Ext. 313 > > [1]www.teltronic.es > > References > > 1. http://www.teltronic.es/ > >

4 years, 8 months

1
0
0 0

FW: OpenAMP 2020.10 Release

by Nathalie Chan King Choy

Looks like this went to openamp-rp-bounces(a)lists.openampproject.org by accident. Sending to the openamp-rp list. -----Original Message----- From: Ed T. Mooring <emooring(a)xilinx.com> Sent: Saturday, October 31, 2020 7:11 PM To: Openamp-rp <openamp-rp-bounces(a)lists.openampproject.org> Subject: OpenAMP 2020.10 Release This is to announce the release of OpenAMP v2020.10. See the release notes at: https://github.com/OpenAMP/open-amp/releases/tag/v2020.10.0 https://github.com/OpenAMP/libmetal/releases/tag/v2020.10.0 The release was actually on Friday, Oct. 23, but it appears that software releases are one of the few things GitHub doesn't automatically send email about. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

4 years, 8 months

1
0
0 0

[OpenAMP/open-amp] dc6ee4: apps: machine: update cleanup of rpmsg and virtio ...

by Ed Mooring

Branch: refs/heads/master Home: https://github.com/OpenAMP/open-amp Commit: dc6ee4623df51eca03f9358cac99468369b28a36 https://github.com/OpenAMP/open-amp/commit/dc6ee4623df51eca03f9358cac994683… Author: Ben Levinsky <ben.levinsky(a)xilinx.com> Date: 2020-10-26 (Mon, 26 Oct 2020) Changed paths: M apps/machine/microblaze_generic/platform_info.c M apps/machine/microblaze_generic/platform_info.h M apps/machine/zynq7/platform_info.c M apps/machine/zynq7/platform_info.h M apps/machine/zynqmp/platform_info.c M apps/machine/zynqmp/platform_info.h M apps/machine/zynqmp_r5/platform_info.c M apps/machine/zynqmp_r5/platform_info.h M apps/system/linux/machine/generic/platform_info.c M apps/system/linux/machine/generic/platform_info.h Log Message: ----------- apps: machine: update cleanup of rpmsg and virtio devices update to clean up devices and not just (void)<var> Signed-off-by: Ben Levinsky <ben.levinsky(a)xilinx.com> Commit: 59eaa4847b6cf879321d06d0400e805142148bab https://github.com/OpenAMP/open-amp/commit/59eaa4847b6cf879321d06d0400e8051… Author: Ben Levinsky <ben.levinsky(a)xilinx.com> Date: 2020-10-26 (Mon, 26 Oct 2020) Changed paths: M apps/examples/echo/rpmsg-echo.c M apps/examples/echo/rpmsg-ping.c M apps/examples/matrix_multiply/matrix_multiply.c M apps/examples/matrix_multiply/matrix_multiplyd.c M apps/examples/rpc_demo/rpc_demo.c M apps/examples/rpc_demo/rpc_demod.c M apps/examples/rpmsg_sample_echo/rpmsg-sample-echo.c M apps/examples/rpmsg_sample_echo/rpmsg-sample-ping.c M apps/tests/msg/rpmsg-flood-ping.c M apps/tests/msg/rpmsg-ping.c M apps/tests/msg/rpmsg-update.c Log Message: ----------- apps: demos: update to hand rproc for cleanup As rproc is needed to remove virtio device from remoteproc_virtio device make sure this is handed off too Signed-off-by: Ben Levinsky <ben.levinsky(a)xilinx.com> Compare: https://github.com/OpenAMP/open-amp/compare/7be7065db7f4...59eaa4847b6c

4 years, 8 months

1
0
0 0

[OpenAMP/open-amp] 7be706: apps: update memory management

by Ed Mooring

Branch: refs/heads/master Home: https://github.com/OpenAMP/open-amp Commit: 7be7065db7f49536f7fc042643925b5a255e9e06 https://github.com/OpenAMP/open-amp/commit/7be7065db7f49536f7fc042643925b5a… Author: Ben Levinsky <ben.levinsky(a)xilinx.com> Date: 2020-10-26 (Mon, 26 Oct 2020) Changed paths: M apps/examples/echo/rpmsg-ping.c M apps/machine/zynq7/platform_info.c M apps/machine/zynqmp/platform_info.c M apps/machine/zynqmp_r5/platform_info.c M apps/system/linux/machine/generic/platform_info.c M apps/tests/msg/rpmsg-flood-ping.c M apps/tests/msg/rpmsg-ping.c Log Message: ----------- apps: update memory management For each metal_allocate_memory call, make sure there are subsequent metal_free_memory calls Signed-off-by: Ben Levinsky <ben.levinsky(a)xilinx.com>

4 years, 8 months

1
0
0 0

Libmetal and SCHED_FIFO thread with priority 99

by Eduardo Viruete

Hello, I'm using a Linux userspace application with Libmetal to communicate core 0 (Linux) and core 1 (FreeRTOS) in a Zynq 7000. The application is very simple, as it only forwards messages between cores and works very well, but I have noticed that it creates an additional thread automatically. I suspect this is because of Libmetal, as OpenAMP's wiki states: "The Linux userspace implementation will use a thread to call select() function to listen to the file descriptors of the devices to see if there is an interrupt triggered. If there is an interrupt triggered, it will call the interrupt handler registered by the user application." However, I was planning system priorities to configure the userspace watchdog daemon and noticed that this thread has SCHED_FIFO scheduling policy with a priority of 99 (the highest possible). This priority is above all my userspace applications, including the watchdog daemon, and even above several kernel threads, which worries me. The code responsible for this behavior is inside libmetal/lib/system/linux/irq.c, function metal_linux_irq_handling(void * args): param.sched_priority = sched_get_priority_max(SCHED_FIFO); /* Ignore the set scheduler error */ ret = sched_setscheduler(0, SCHED_FIFO, &param); My question is: can I lower the priority of this thread? If the answer is yes, what would be the minimum required priority for Libmetal to operate properly? Thank you very much and best regards, Eduardo. Eduardo Viruete Software Engineer Teltronic Tel: +34 976 465656 Ext. 313 <http://www.teltronic.es/> www.teltronic.es Hello, I’m using a Linux userspace application with Libmetal to communicate core 0 (Linux) and core 1 (FreeRTOS) in a Zynq 7000. The application is very simple, as it only forwards messages between cores and works very well, but I have noticed that it creates an additional thread automatically. I suspect this is because of Libmetal, as OpenAMP’s wiki states: “The Linux userspace implementation will use a thread to call select() function to listen to the file descriptors of the devices to see if there is an interrupt triggered. If there is an interrupt triggered, it will call the interrupt handler registered by the user application.” However, I was planning system priorities to configure the userspace watchdog daemon and noticed that this thread has SCHED_FIFO scheduling policy with a priority of 99 (the highest possible). This priority is above all my userspace applications, including the watchdog daemon, and even above several kernel threads, which worries me. The code responsible for this behavior is inside libmetal/lib/system/linux/irq.c, function metal_linux_irq_handling(void * args): param.sched_priority = sched_get_priority_max(SCHED_FIFO); /* Ignore the set scheduler error */ ret = sched_setscheduler(0, SCHED_FIFO, &param); My question is: can I lower the priority of this thread? If the answer is yes, what would be the minimum required priority for Libmetal to operate properly? Thank you very much and best regards, Eduardo. Eduardo Viruete Software Engineer Teltronic Tel: +34 976 465656 Ext. 313 [1]www.teltronic.es References 1. http://www.teltronic.es/

4 years, 8 months

1
0
0 0

[OpenAMP/open-amp]

by Arnaud Pouliquen

Branch: refs/tags/new_api_rc1 Home: https://github.com/OpenAMP/open-amp

4 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

Openamp-rp