From Stephane.Rubini at univ-brest.fr Thu Apr 18 13:19:43 2024 From: Stephane.Rubini at univ-brest.fr (=?UTF-8?Q?St=C3=A9phane_Rubini?=) Date: Thu, 18 Apr 2024 15:19:43 +0200 Subject: disable DCache on RTEMS SMP In-Reply-To: References: Message-ID: <00b8900d-d013-4615-afd4-8f5278ddfc3b@univ-brest.fr> Hi, For the purposes of an experiment, we want to disable the data caches for an RTEMS SMP 5.3 running on Zedboard (Xilinx Zynq7000 SoC, Dual-core Cortex-A9). We use the rtems_cache_disable_data() function.Doing this crashes the system (more precisely the system has an unexpected and unpredictable behavior...). Are there any known issues (other than performance...) with this operation, or configuration commands to apply that enable this? Thank a lot Regards St?phane -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.huber at embedded-brains.de Fri Apr 19 06:45:17 2024 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Fri, 19 Apr 2024 08:45:17 +0200 Subject: disable DCache on RTEMS SMP In-Reply-To: <00b8900d-d013-4615-afd4-8f5278ddfc3b@univ-brest.fr> References: <00b8900d-d013-4615-afd4-8f5278ddfc3b@univ-brest.fr> Message-ID: Hello St?phane, the rtems_cache_disable_data() has no real use case. It is quite difficult to implement and it is not unusual that its implementation is broken. I think on RTEMS 6 it should work for this BSP. However, I am not sure if the atomic operations work, if you disable the data cache. Without atomic operations, you will have unpredictable behaviour in SMP configurations. You can statically place data in a non-cacheable area with a section attribute: #include BSP_NOCACHE_SECTION char nocache[123]; Kind regards, Sebastian -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber at embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M?nchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch?ftsf?hrer: Peter Rasmussen, Thomas D?rfler Unsere Datenschutzerkl?rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From chrisj at rtems.org Sat Apr 27 01:08:32 2024 From: chrisj at rtems.org (Chris Johns) Date: Sat, 27 Apr 2024 11:08:32 +1000 Subject: GitLab Launch Message-ID: <4bf4c6ea-1ce6-4cc1-aaf8-018759c0a00e@rtems.org> Hi RTEMS Community. We will be launching GitLab during the 1st May 2024. You can access RTEMS GitLab (RGL) at: https://gitlab.rtems.org/ Account creation will be enabled on the 1st May 2024. The goal of the move to GitLab is to modernise our workflow reducing the burden of merging patches into our project and making it easier to send in changes. We are excited to accept merge requests in GitLab and we hope this brings more people into the project and it encourages users to submit back to the project. The move to Gitlab means we need to change our workflow. You will need a GitLab account with 2FA and if you wish to create merge requests you will need to add an SSH key. Additionally, some repos have changed names and the URL in any repos you currently have cloned will need updating. The issues in Trac have been moved to GitLab and may need review and updating. The development list (devel*..) will no longer be used for patches. Any patches are not merged from devel@ will need to be turned into a merge request to be merged. Discussions about patches can happen in merge requests. I will be sending the following emails to help explains the steps you need work through and how things will work: 1. Signing on to RTEMS GitLab 2. RTEMS Project Repos in GitLab 3. RTEMS Issues in GitLab 4. Workflows and Merge Requests These emails are an introduction. Our documentation is a work in progress and we ask you to consider creating merge requests to update it if things are missing or not clear. We welcome contributions from the community to get this work completed. What we present at the beginning is a starting point. With GitLab active we can finish some remaining server upgrade work. We will be taking service2.rtems.org down to upgrade it. The server currently hosts Trac, docs, mailman web, cgit and more. We were asked by OSU OSL, who host our servers, to do this and it has taken us a couple of years to get to a point we can. I would like to thank Lance at OSU OSL for his patience and understanding. I personally appreciate this and I am sure the community does as well. This is not the end of the server work we would like to do however it is the end of the current funding. If you would like to donate to help support the server work please reach out to Joel and I. The funding can be handled confidentially if that is important. We need funding to improve the services we provide so please consider helping. Finally I would like to thank Amar for his hard work and diligence in bringing this all together. I appreciate the hours you have put in. Awesome effort. I would also like to thank Joel, Gedare and Kinsey for putting in the hours each week over the past months to help make this happen. If you need help please join the #gitlab-support channel on our Discord server. It is open to posts and questions. You can find our invite link here https://www.rtems.org/discord. We will also respond to posts on this list when we have the time. Regards Chris Johns RTEMS GitLab Team From ppisa4lists at pikron.com Sun Apr 28 22:30:36 2024 From: ppisa4lists at pikron.com (Pavel Pisa) Date: Mon, 29 Apr 2024 00:30:36 +0200 Subject: How can I use --with-rtems-bspopts properly? In-Reply-To: References: Message-ID: <202404290030.36258.ppisa4lists@pikron.com> Dear Y. HB, On Friday 16 of September 2022 11:45:05 Y. HB wrote: > I am working on tms570 bsp > > I want to change some bspopts , but I cannot get the default value > overridden via --with-rtems-bspopts, what correct way should I do? > > I used following command to configure RTEMS bsp > > ../../rtems-master/configure OTHER-OPTIONS > --with-rtems-bspopts="TMS570_USE_HWINIT_STARTUP=1 ARM_TMS570LC4357=1 > BSP_MINIMUM_TASK_STACK_SIZE=2048" > > But the generated bspopts.h is not changed with above values. If you work with current mainline RTEMS sources then the process to build RTEMS has changed. This is my build scrip for test of tms570ls3137_hdk_sdram, it builds but there is some issue to run BSP on TMS570LS3137 which can be caused by my load method or changes for Cortex-R5 found on TMS570LC4357. I have not found time to investigate that yet and that platform is not our actual priority. My RTEMS build script looks following way now ---------------------------------------------- #!/bin/sh MY_DIR="$(cd "$(dirname "$0")" ; pwd -L )" RTEMS_DIR=../../../git/rtems $RTEMS_DIR/waf bspdefaults --rtems-bsps=arm/tms570ls3137_hdk_sdram -t "$RTEMS_DIR" -o "$MY_DIR" --prefix "/opt/rtems/6" >config.ini || exit 1 #mv config.ini config.ini.default #sed config.ini \ -e 's/^RTEMS_POSIX_API .*$/RTEMS_POSIX_API = True/' \ $RTEMS_DIR/waf configure -t "$RTEMS_DIR" -o "$MY_DIR" --rtems-config "$MY_DIR/config.ini" --prefix "/opt/rtems/6" || exit 1 $RTEMS_DIR/waf || exit 1 $RTEMS_DIR/waf install || exit 1 ---------------------------------------------- Generally, after $RTEMS_DIR/waf bspdefaults you can edit config.ini. You can change TMS570_USE_HWINIT_STARTUP = False to TMS570_USE_HWINIT_STARTUP = True in the config.ini. It can be automated by -e 's/^TMS570_USE_HWINIT_STARTUP .*$/TMS570_USE_HWINIT_STARTUP = True/' \ There are lot of other options which can be adjusted. Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: pisa at cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa company: https://pikron.com/ PiKRON s.r.o. Kankovskeho 1235, 182 00 Praha 8, Czech Republic projects: https://www.openhub.net/accounts/ppisa social: https://social.kernel.org/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home