Hi,
I am having an issue running bare-metal tests on the Genesys2 board via JTAG. Previously, this setup worked perfectly, but recently the execution traps in the BootROM and fails to print to the UART. I am unsure what has changed in my environment to cause this.
Environment:
- Hardware: Genesys2 FPGA
- Cheshire Version: Commit 2d40a3b (also reproduced on release v0.3.1)
- Synthesis Environment: Ubuntu 20.04.6 LTS, Vivado 2024.1
- Programming Environment: macOS + Vivado 2025.2.1 on Windows VM (only for programming .bit and .ltx)
- Debugger: xPack OpenOCD 0.11.0+dev, GNU GDB (xPack GNU RISC-V Embedded GCC) 16.3
Steps to Reproduce:
git clone https://github.com/pulp-platform/cheshire.git cheshire
cd cheshire
git checkout 2d40a3bd0c83ed3244edb4bf690bedf1bf51936f
bender checkout
make all
make -j$(nproc) chs-xilinx-genesys2
Program the device using Vivado 2025.2.1.
Start OpenOCD in terminal 1:
openocd -f ./util/openocd.genesys2.tcl
Connect via GDB in terminal 2 and load the ELF:
riscv-none-elf-gdb -ex "target extended-remote localhost:3333"
(gdb) load sw/tests/helloworld.spm.elf
(gdb) continue
Current Behavior:
After running continue, no output is printed to the serial console, and the program hits a SIGTRAP at 0x020000e2 (inside the BootROM region).
OpenOCD Output:
xPack OpenOCD arm64 Open On-Chip Debugger 0.11.0+dev (2022-09-01-20:57)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter speed' not 'adapter_khz'
DEPRECATED! use 'adapter driver' not 'interface'
DEPRECATED! use 'ftdi vid_pid' not 'ftdi_vid_pid'
DEPRECATED! use 'ftdi layout_init' not 'ftdi_layout_init'
DEPRECATED! use 'ftdi channel' not 'ftdi_channel'
Warn : `riscv set_prefer_sba` is deprecated. Please use `riscv set_mem_access` instead.
Warn : libusb_detach_kernel_driver() failed with LIBUSB_ERROR_ACCESS, trying to continue anyway
Info : clock speed 8000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x1c5e5db3 (mfg: 0x6d9 (<unknown>), part: 0xc5e5, ver: 0x1)
Info : datacount=2 progbufsize=8
Info : Examined RISC-V core; found 1 harts
Info : hart 0: XLEN=64, misa=0x80000000001411ad
Info : starting gdb server for riscv.cpu on 3333
Info : Listening on port 3333 for gdb connections
Ready for Remote Connections.
Info : tcl server disabled
Info : telnet server disabled
Info : accepting 'gdb' connection on tcp/3333
GDB Output:
GNU gdb (xPack GNU RISC-V Embedded GCC arm64) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=aarch64-apple-darwin20.6.0 --target=riscv-none-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using localhost:3333
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x00000000020000c4 in ?? ()
(gdb) load sw/tests/helloworld.spm.elf
Loading section .text, size 0x352 lma 0x10000000
Loading section .misc, size 0xf lma 0x10000360
Start address 0x0000000010000000, load size 865
Transfer rate: 7 KB/sec, 432 bytes/write.
(gdb) continue
Continuing.
(gdb)
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000020000e2 in ?? ()
(gdb)
To rule out common issues, I have already verified the following:
- No SD card is inserted into the board.
- All boot switches on the Genesys2 are set to 0 (only fan control switches are active).
- I temporarily modified cheshire_top_xilinx.sv to force JTAG boot (assign boot_mode = 2'b00;) to ensure the board wasn't accidentally reading the wrong switch/VIO state.
- I checked timing_worst.rpt and all timing constraints are met (Slack is positive: 0.110ns):
Copyright 1986-2022 Xilinx, Inc. All Rights Reserved. Copyright 2022-2024 Advanced Micro Devices, Inc. All Rights Reserved.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Tool Version : Vivado v.2024.1 (lin64) Build 5076996 Wed May 22 18:36:09 MDT 2024
| Date : Sat May 16 18:59:37 2026
| Host : HW01 running 64-bit Ubuntu 20.04.6 LTS
| Command : report_timing -file /home/user/cheshire-2d40a3b/target/xilinx/build/genesys2.cheshire/reports.impl/timing_worst.rpt -nworst 1 -delay_type max -sort_by group
| Design : cheshire_top_xilinx
| Device : 7k325t-ffg900
| Speed File : -2 PRODUCTION 1.12 2017-02-17
| Design State : Routed
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Timing Report
Slack (MET) : 0.110ns (required time - arrival time)
Since this same source code and setup successfully worked for me in the past, what might I be missing here? Why would the core trap in the BootROM immediately after loading the Scratchpad Memory (SPM)? Any insights would be greatly appreciated.
Hi,
I am having an issue running bare-metal tests on the Genesys2 board via JTAG. Previously, this setup worked perfectly, but recently the execution traps in the BootROM and fails to print to the UART. I am unsure what has changed in my environment to cause this.
Environment:
Steps to Reproduce:
Program the device using Vivado 2025.2.1.
Start OpenOCD in terminal 1:
openocd -f ./util/openocd.genesys2.tclConnect via GDB in terminal 2 and load the ELF:
Current Behavior:
After running continue, no output is printed to the serial console, and the program hits a SIGTRAP at 0x020000e2 (inside the BootROM region).
OpenOCD Output:
GDB Output:
To rule out common issues, I have already verified the following:
Since this same source code and setup successfully worked for me in the past, what might I be missing here? Why would the core trap in the BootROM immediately after loading the Scratchpad Memory (SPM)? Any insights would be greatly appreciated.