# ROMEO Onboard Software (OBSW) ## What is ROMEO? [For a broader introduction and documentation refer to the OBSW Wiki in the ROMEO Knowledge Base](https://openproject.mm.intra.irs.uni-stuttgart.de/projects/romeo-phase-c/wiki/obsw). This README gives a very brief introduction and aims to document the compile process for experienced developers. [_Research and Observation in Medium Earth Orbit (ROMEO)_](https://www.irs.uni-stuttgart.de/en/research/satellitetechnology-and-instruments/smallsatelliteprogram/romeo/) is the third small satellite of the Institute of Space Systems (IRS), University of Stuttgart with the objective of technology demonstration in Medium and Low Earth Orbit (MEO/LEO) with a mission duration of 1 year. The Onboard Software (OBSW) is written in Rust for run-time stability. The implemented framework is losely based on the C++ Flight Software Framework (FSFW) developed at the IRS in cooperation with industry. The shift to Rust was discussed in Paul Nehlich's master thesis: [_Analysis and preparation of the transformation of the Flight Software Framework from C++ to Rust_](https://www.researchgate.net/publication/372439213_Analysis_and_preparation_of_the_transformation_of_the_Flight_Software_Framework_from_C_to_Rust). ROMEO Preliminary Design (design from IRS ROMEO Website) ## How to Configure This Repository? TODO # First Stage Bootloader (FSBL) FSBL code is at https://github.com/Xilinx/embeddedsw/ ## Scope This is the central repository for the flight software of the ROMEO satellite. It will eventually become the new base of a Rust Flight Software Framework replacing the C++ Flight Software Framework of the FLP, EIVE and SOURCE. The current working steps are: - Build Toolchain (Daniel Philipp) - Hardware itnerfaces (Paul Nehlich) - CAN Bus (Andy Hinkel) - RS422 (Paul Nehlich, Joris Janßen) - Device Handling Fundamentals (Joris Janßen) - Framework Core Component Implementation (Paul Nehlich, Ulrich Mohr) - Integration of Space Packets and PUS Services (to be scheduled, Paul Nehlich) - OBC Board support and Linux Boot Management (Michael Steinert) - Device Integration - AOCS - TCS - Communications Interfaces ## Prerequisits for build with Docker ##### Info IRS wireguard VPN can cause network issues with docker. ##### Install Docker If you are using macOS or Windows, please use this tutorial: - https://www.docker.com/get-started/ On Linux simply use your package manager to install ```docker``` and prepare everything using these commands, to avoid permission denied errors: ```sh sudo systemctl start docker sudo groupadd docker sudo usermod -aG docker $USER sudo reboot ``` ## FSBL FSBL is the First Stage Boot Loader and prepares the CPU and FPGA configuration for booting up the Second Stage Bootloader and finally the flight software. ##### Clone the repository and build the docker image: ```sh cd docker/compile_fsbl/ git clone https://github.com/Xilinx/embeddedsw/ docker build -t compile_fsbl . ``` ##### To build the FSBL, run the following command in the `docker/compile-fsbl` directory: ```sh docker run -v ./embeddedsw:/fsbl compile_fsbl /bin/bash -c "cd lib/sw_apps/zynq_fsbl/src && make BOARD=zed SHELL=/bin/bash" ``` ## Requirements [TBC]: 1. `cmake` 2. `arm-none-eabi-gcc` 3. `doxygen` 4. `graphviz` If you want, copy the fsbl.elf to the docker/compile_fsbl directory for easier access: ```sh cp embeddedsw/lib/sw_apps/zynq_fsbl/src/fsbl.elf . ``` ## Steps 1. Configure doxygen: ## mission_rust ##### Build the docker image: ```sh export DOT_PATH=/usr/local/bin ``` 2. Satisfy Rust requirements ```sh cd ../mission_rust cargo update rustup toolchain install nightly rustup component add rust-src --toolchain nightly-x86_64-unknown-linux-gnu rustup override set nightly cargo build -Z build-std cd docker/compile_mission/ docker build -t compile_mission . ``` 3. Configure the ROMEO OBSW repository in `.../obsw/` ##### To build the mission_rust, run the following command in the `docker/compile_mission` directory: ```sh docker run -v $(pwd)/../../mission_rust:/mission_rust compile_mission /bin/bash -c "cargo build -Z build-std" ``` ## obsw ##### Clone the submodules (FreeRTOS and lwIP): ```sh git submodule init git submodule update ``` ##### Build the docker image: ```sh cd docker/compile_obsw/ docker build -t compile_obsw . ``` ##### To build the obsw, run the following command in the `docker/compile_obsw` directory: ```sh docker run -v $(pwd)/../..:/obsw compile_obsw /bin/bash -c "mkdir -p build_cli && cd build_cli && cmake -DCMAKE_TOOLCHAIN_FILE=../bsp_z7/cmake/arm-none-eabi.toolchain .. && make -j 8" ``` The romeo-obsw binary can now be found in the `build_cli` directory. # Debugging on `zedboard` `zedboard` is the `Xilinx Zynq-7000` development board. ## Requirements [TBC]: - `OpenOCD` - `arm-none-eabi-gdb` ## Steps TODO: discuss this with paul 1. Set Zedboard `boot mode` to JTAG and connect debugging PC to zedboard JTAG and UART USB port. TODO: what is which port, use distinct name/add a graphic 2. On PC connected to zedboard JTAG USB port: ```sh openocd -f board/digilent_zedboard.cfg ``` If you have one around, load bitstream at startup (go get a coffee, takes time with onboard JTAG, blue LED lights up when done): ```sh openocd -f board/digilent_zedboard.cfg -c "init" -c "pld load 0 system.bit" ``` 3. To use JTAG Boot for the OBSW, you first need to run the FSBL once. On build PC (adapt IP if different from debugging PC) in the folder where you build the FSBL as above: ```sh arm-none-eabi-gdb fsbl.elf >target extended-remote localhost:3333 >load >cont >^C^D^D ``` ### (Optional) Automate this run: ```sh arm-none-eabi-gdb fsbl.elf -iex "target extended-remote localhost:3333" -ex "set pagination off" -ex "load" -ex "break FsblHandoffJtagExit" -ex "cont" -ex="set confirm off" -ex "exit" ``` It will exit after the Zynq is configured and ready to firmware. Then load the actual OBSW, in the build (`build_cli` in the example above) folder run: ```sh arm-none-eabi-gdb romeo-obsw >target extended-remote localhost:3333 >load >cont ``` Again, `Command Line Interface (CLI) commands` can be moved to the GNU Debugger (DGB) call. Also, a small function is used as marker to return from GDB if the mission code returns (should not happen in production but might be useful during testing). ```sh arm-none-eabi-gdb romeo-obsw -iex "target extended-remote localhost:3333" -ex "set pagination off" -ex "load" -ex "break done" -ex "cont" -ex="set confirm off" -ex "exit" ``` UART USB port should output something at `115200baud`, (I use moserial to monitor).