installing Doorstop on macOS (for RTEMS use)
Hello everyone, Maybe I am too late to join this discussion but as far as I followed this thread, no one has mentioned using https://github.com/pyenv/pyenv to install Python 3 and its dependencies on macOS. Actually, I try to avoid using any of the Ruby, Python or Node system installations provided by Apple. Instead, I use pyenv for Python and similar projects for other languages. Given that you have a folder where you want to have Python 3 available, you simply put a .python-version file with the Python version you need. After that, you can install and use the needed Python 3 version provided to you by pyenv. Hope this is useful. Stanislav ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: using docker to deliver qualification tools
Hello, This is a comment for Andrew from a somewhat passive reader of the RTEMS forums. One way of having Docker while staying platform-independent is to use a "Docker without Dockerfiles" approach like described here: [1]. The idea is very simple: you delegate all provisioning jobs to Ansible. If your building process is all written in the Ansible playbooks, you can run these playbooks with Docker or other technologies such as Vagrant and virtual machines. My use case is rather the opposite of what you seem to have: we use Ansible playbooks and Vagrant / VirtualBox for a number of operating systems but I also want to build the Docker containers with the same Ansible playbooks that we use for VMs because Docker is easier and faster when I need to jump on Linux-specific tasks from a macOS machine. I have created a simple example [2] that should give you an idea of how you make Ansible build a Docker container and then create an image from it using 'docker commit'. You can later use the same playbook to build any other technology like Vagrant/VirtualBox. I am not sure how much is this relevant for you but keeping build steps in Ansible seems like a more scalable solution that potentially unlocks your solution from being a Docker-only. [1] https://tech.labs.oliverwyman.com/blog/2019/08/30/docker-without-dockerfiles/ [2] https://github.com/stanislaw/docker-with-ansible-example Stanislav On Thu, Oct 24, 2019 at 2:00 PM Joel Sherrill wrote: > > > > On Thu, Oct 24, 2019, 5:58 AM Andrew Butterfield > wrote: >> >> Dear RTEMS users, >> >> give that the RTEMS-SMP qualification project requires a lot of new >> tooling, some very standard, some more experimental, we have a proposal >> that we distribute these using Docker CE (Community Edition). >> >> This will make it easier for users to install only the parts that they >> are interested in, and also makes it possible for us to host the >> tools in the cloud somewhere as an on-line qualification service. >> >> What are the thoughts of the community regarding this? > > > I don't care what ESA does after the work is delivered for their own internal > use. But requiring a Docker instance for community qualification work is > unacceptable to me. It is a Linux specific technology and that violates a few > key tenets of the RTEMS project. > > Host Independence and Reproducible being the top two. > > Instructions on how to build the environment are key. This includes what to > install with pop or with the RSB or as a host package. > > If a user wants a pre-configured VM or container that's their business. I > personally don't think it is configuration controlled enough under the > auspices of the project and even if used must be under the end user system's > control to be able to pass a qualification audit. > > Think reproducible > > > >> >> Best regards, >> Andrew Butterfield >> >> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 >> Lero@TCD, Head of Foundations & Methods Research Group >> School of Computer Science and Statistics, >> Room G.39, O'Reilly Institute, Trinity College, University of Dublin >> http://www.scss.tcd.ie/Andrew.Butterfield/ >> >> >> ___ >> users mailing list >> users@rtems.org >> http://lists.rtems.org/mailman/listinfo/users > > ___ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Caching build objects: Waf and ccache
Hello everyone, I have a very specific question about the Waf build system. I apologize if I missed this information somewhere in the documentation. >From looking at ./waf --help it doesn't look like Waf would have a ccache-like functionality built in. When using CMake build system, I am used to providing -DCMAKE_CXX_COMPILER_LAUNCHER=ccache that makes CMake switch to using ccache. Is there an equivalent option for Waf or is there a native way in Waf for caching object artifacts? Thank you, Stanislav ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Caching build objects: Waf and ccache
Thanks for the answer. My comments below: On Tue, Oct 5, 2021 at 11:50 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Stanislav, > > On 05/10/2021 11:17, Stanislav Pankevich wrote: > > I have a very specific question about the Waf build system. I apologize > if > > I missed this information somewhere in the documentation. > > > > From looking at ./waf --help it doesn't look like Waf would have a > > ccache-like functionality built in. > > > > When using CMake build system, I am used to providing > > > > -DCMAKE_CXX_COMPILER_LAUNCHER=ccache > > > > that makes CMake switch to using ccache. Is there an equivalent option > for > > Waf or is there a native way in Waf for caching object artifacts? > > you may have a look at this: > > https://gitlab.com/ita1024/waf/blob/master/waflib/extras/wafcache.py > > Thanks for the pointer! I don't know if this works with RTEMS. Do you want to use this for the > RTEMS build? I am not sure if it is worth the trouble since RTEMS builds > in a couple of seconds. > Yes, we would like to have caching specifically for building RTEMS using Waf. The upper layers of our software are built with ccache enabled in CMake. Building RTEMS and BSP for Zynq 7020 is taking ~60 seconds on our GitLab Runner VM (1460 files). We are building from the default instructions (2.5. Build a Board Support Package (BSP)), we might remove the test suites eventually but the build time is already noticeable. Thanks. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Fwd: Typical workflows for RTEMS-based development using Xilinx Zynq 7000
Sorry for cross-posting: I have realized that my message should have been sent to the rtems-users instead. -- Forwarded message - From: Stanislav Pankevich Date: Thu, Jul 15, 2021 at 6:05 PM Subject: Typical workflows for RTEMS-based development using Xilinx Zynq 7000 To: rtems-de...@rtems.org Hello everyone, I am looking for information on how to start the development with RTEMS on the Arty Z7 development board (Z7-20). I see that there are at least two existing BSPs that could help me to get started: xilinx_zynq_zc702 and xilinx_zynq_zedboard. I followed the instructions for building these BSPs using the RTEMS toolchain and the Waf build system and now I have the binaries of the RTEMS "hello world" program. My immediate question: there seems to be two different approaches for setting up development workflows: one using Xilinx tools (Vitis IDE, Xilinx Software Command-line Tools and System Debugger XSDB) and a more traditional one using GDB/OpenOCD. Being more familiar with the GDB/OpenOCD approach, I was wondering which tools/workflows for working with Xilinx Zynq are used or considered best practice by the RTEMS community. Related question: does anyone have experience running RTEMS on the Z7-20 board? Any information that could help in reducing the setup/porting efforts is appreciated. Thank you for your attention. Stanislav Pankevich ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: RTEMS Development on Zynq 7000 Board
Hi Florian, Thanks for asking. I am not working on that project anymore. We definitely brought up RTEMS to run on ARTY with some tinkering behind it, but we could not open-source our setup due to lack of time. I am most certain that we used the xilinx_zynq_zc702 configuration as a base. Now I don't have access to the working code but only some memories. I am working on another Xilinx part now, and since the setups are in a way similar, let me share what I can. As already indicated in the original RTEMS thread, there are two workflows possible: 1) Vivado/Vitis/XSDB/GDB 1.1) Create FPGA design in Vivado, export design file. 1.2) Create Platform project in Vitis from the exported design file from step 1.1. 1.3) Create a SW project in Vitis based on the Platform project in step 1.2. 1.4) Use Vitis to Flash and Debug the software in IDE. 1.5) When the setup is stable, check the log panels of Vitis to understand: - Which TCL commands Vitis runs to configure the board and flash the software. - See the logs that those commands themselves produce to get a better understanding of the board startup sequence. >From here on, you copy what Vitis does in the IDE to your command-line workflow to automate things and not be dependent on the IDE workflow (if you want). 1.6) Copy the TCL commands that Vitis does to TCL files on your file system and run the Xilinx XSDB from the command line to reproduce exactly the steps of what Vitis does during the IDE flash workflow. The result of this step is that you can do 100% the same things compared to what Vitis does, but from your own command-line scripts. I am attaching our current top-level file that does the flashing but the related details of how to source the TCL files you should figure out yourself, following the Vitis logs from 1.5. 1.7) Once you can flash with XSDB, you can also connect to it with GDB because XSDB has a GDB server. *) Note that there are two ways of starting the SW: with and without the Xilinx First-Stage Bootloader (FSBL) run in the process. If you just Flash with your debugger and not boot from Flash memory, running of something like $VITIS_PATH/scripts/vitis/util/fsbl.tcl should be part of your scripts or if you include the "FSBL" checkbox in Vitis, also the fsbl binary to be run before you flash your image. The main point to remember the FSBL startup sequence has to be run either by the FSBL itself if it gets flashed or by a corresponding FSBL TCL script. Following the Vitis logs, you should notice exactly those lines. This is the workflow that we are using now and everything pretty much works. In 2021, my colleague skipped the steps 1.6-1.7 and implemented workflow #2, see below. 2) OpenOCD/GDB To enable OpenOCD, you should anyway familiarize yourself with the steps from 1.1-1.6. Instead of copying the Vitis logs commands to TCL files like in step 1, the action here is to configure OpenOCD and GDB to reproduce exactly those steps but using OpenOCD/GDB syntax and commands. You will likely need at least two files: - OpenOCD config file, something like arty.cfg which you will run with openocd, like "openocd -f arty.cfg" - GDB init file which you can run source when you run GDB: gdb -x rtems.gdb. In that GDB file you can have a function like "flash" which will reproduce the necessary TCL scripts commands from Vitis. A general guidance for setting up the workflow #2 can be found here but you will have to adapt it to your needs: https://devel.rtems.org/wiki/Debugging/OpenOCD/Xilinx_Zynq. In the attached Python file, you see our existing Flash routine. All the TCL and settings files have been recreated from Vitis logs. We are following workflow #1 only and have not implemented workflow 2 for this part yet. As a side note, we are using https://www.pyinvoke.org/ to automate tasks which helps us to write more Python instead of Bash. I do believe that all these things must be much better documented, so that we spend time somewhere else. When our current workflow is stable, we will try to open source as much as we can. Good luck with porting and let me know if you have any questions. Stanislav On Wed, Nov 8, 2023 at 3:36 PM Florian Sommerfeld < fsommerf...@stud.hs-bremen.de> wrote: > Hello Stanislav, > I am currently researching on how to get RTEMS up and running on a Zybo > Z7-20 Zynq-7000 ARM/FPGA Board (should be rather similar to your Arty > Z7) and found your question in the RTEMS users mail archive: > https://www.mail-archive.com/users@rtems.org/msg03248.html > Did you ever manage to run RTEMS on your Z7-20 board? I was able to use > the xilinx_zynq_zedboard BSP to build the RTEMS 5 hello world program, > but I am having a hard time on how to actually get it onto the board. > Any help is highly appreciated. > > Sincerely, > Florian > @task(fpga_configure) def flash_debug(context, path_to_elf, platform, debug_probe=None): """ Initialize and flash an FPGA. """ # Ref:
