Update RTEMS on BeagleV Fire authored by Pavel Pisa's avatar Pavel Pisa
......@@ -119,7 +119,7 @@ cp _compiled/xilinx_zynq_zedboard/bin/zynq-template.img /srv/tftp/zynq/rtems
You might need to install `u-boot-tools` package to build the template application.
## BeagleV-Fire Internal eMMC Boot
## BeagleV-Fire Internal eMMC RTEMS Boot
The BeagleV-Fire boots applications from eMMC soldered on the board. The actual boot process starts by starting Microchip's HSS (Hart Software Services) loaded from eNVM. The HSS software can establish OpenSBI environment and start HSS payload from eMMC on specified RV64 cores (the HARTs u54_1, u54_2, u54_3 and u54_4 are complete RV64GC cores then there is one management RV63IMAC core). The payload is started in specified mode, for the Linux kernel or U-boot typically in M-mode.
......@@ -168,4 +168,139 @@ sudo dd if=rtems-payload.bin of=/dev/sdX1
```
WARNING: Be VERY CAREFULL there to chose correct device the mistake can lead to overwrite of your host system and make it unbootable.
## BeagleV-Fire TFTP Boot
## BeagleV-Fire TFTP RTEMS Boot
U-boot with networking support is required to boot RTEMS over TFTP. U=boot has to be build to be loaded and run in M-mode because RTEMS has to be booted in M-mode and I am not aware of o way to switch to M/mode from U-boot running in the standard S-mode.
Next steps has been used to achieve the goal:
The load and build of M-mode U-boot. The Microchip development repository has been used
```
git clone https://github.com/linux4microchip/u-boot-mchp.git
mkdir -b build/beaglev-fire-mmode
```
The redirection `GNUmakefle` can be created there
```
# U-boot for BeagleV-Fire
UBOOT_SRC_DIR := $(shell cd ../.. ; pwd )/u-boot-beaglev-fire
BUILD_DIR := $(CURDIR)
CROSS_COMPILE=riscv64-linux-gnu-
.PHONY: all $(MAKECMDGOALS)
all := $(filter-out all Makefile,$(MAKECMDGOALS))
all:
echo $(MAKE) -C $(UBOOT_SRC_DIR) O=$(BUILD_DIR) CROSS_COMPILE=$(CROSS_COMPILE) $(MAKEARGS) $(all)
$(MAKE) -C $(UBOOT_SRC_DIR) O=$(BUILD_DIR) CROSS_COMPILE=$(CROSS_COMPILE) $(MAKEARGS) $(all)
Makefile:;
$(all) %/: all
@:
```
The `riscv64-linux-gnu-gcc` (Debian package `gcc-riscv64-linux-gnu`) is used for build.
Configuration of the build
```
make beaglev_fire_defconfig
```
Then the default S-mode build has to be changed to M-build. Use
```
make xconfig
```
and chose RISC-V Architecture -> Run Mode -> Machine
It results in the next configuration changes
```
+CONFIG_SMP=y
+CONFIG_NR_CPUS=8
-CONFIG_RISCV_SMODE=y
+CONFIG_RISCV_MMODE=y
-CONFIG_SBI=y
-CONFIG_SBI_V02=y
+CONFIG_SIFIVE_CLINT=y
-CONFIG_SYSRESET_SBI=y
```
Then run
```
make -j 4
```
Copy out `u-boot-dtb.bin` to some other directory and to nt mismatch it rename it to `u-boot-dtb-mmode.bin`.
Next `uboot-mmode.yaml` HSS generator configuration
```
# First, we can optionally set a name for our image
set-name: 'PolarFire-SoC-HSS::U-Boot-M-mode'
# Next, we'll define the entry point addresses for each hart, as follows:
hart-entry-points: {u54_1: '0x80200000', u54_2: '0x80200000', u54_3: '0x80200000', u54_4: '0x80200000'}
payloads:
u-boot-dtb-mmode.elf: {exec-addr: '0x80200000', owner-hart: u54_1, secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, priv-mode: prv_m, ancilliary-data: test/icicle-kit-es-microchip.dtb }
```
Then run
```
#!/bin/sh
objcopy --rename-section .data=.text \
-I binary -O elf64-littleriscv u-boot-dtb-mmode.bin u-boot-dtb-mmode.o || exit 1
riscv64-unknown-elf-ld.bfd -m elf64lriscv -static -Bstatic --no-dynamic-linker \
--build-id=none -Ttext 0x80200000 -o u-boot-dtb-mmode.elf u-boot-dtb-mmode.o
./hss-payload-generator -c uboot-mmode.yaml uboot-mmode-payload.bin
```
The final `uboot-mmode-payload.bin` can be copied to the target when enabled mass storage mode by `usbdmsc`
```
dd if=uboot-mmode-payload.bin of=/dev/sdX1
```
The U-boot command prompt can be reached by sending newline character over serial line when the U-boot is started and waits before automatic boot
```
U-Boot 2023.07.02-linux4microchip+fpga-2024.09-00038-ge8680433da9 (Feb 23 2025 - 09:27:45 +0100)
...
Hit any key to stop autoboot: 0
```
The RTEMS application in plain binary format can be converted to U-boot image by
```
mkimage -A riscv -O rtems -T kernel -a 0x1000000000 -e 0x1000000000 -n "RTEMS" -C none -d app.bin app.img
```
Problem is that legacy image stores only low 32-bits from the load and entry addresses. Attempt to use FIT image where
```
load = /bits/ 64 <0x1000000000>;
entry = /bits/ 64 <0x1000000000>;
```
does not work for me. U-boot fails when attempting to analyze FIT image on Store/AMO Unaligned fail...
But even legacy image with incorrect entry can be used with some workarounds.
The used setup is prepared in `/srv/tftp/beglev-fire` directory.
The next control script (`autoscr.scr.txt`) source is prepared for U-boot
```
setenv fdt_high 0xffffffffffffffff
setenv initrd_high 0xffffffffffffffff
img_path=beglev-fire/rtems/app.img
img_addr=0x8e010000
tftpboot ${img_addr} ${tftpserverip}:${img_path}
cp 8e010040 1000000000 ${filesize}
go 1000000000
```
The script is converted to U-boot image by
```
mkimage -A riscv -O linux -T script -C none -a 0 -e 0 \
-n "autoscr example script" \
-d autoscr.scr.txt autoscr.scr
```
When prepared and RETMS application image is placed into `/srv/tftp/beglev-fire/rtems/app.img` the whole application can be started from U-bbot prompt by
```
env set autoload no
env set tftpserverip 192.168.1.10
env set bootscript_path beglev-fire/autoscr.scr
dhcp && tftpboot ${scriptaddr} ${tftpserverip}:${bootscript_path} && source ${scriptaddr}
```