This is very weird. The SRAM and hyperRAM mapping should be the same in simulation and FPGA. Just to double check, can you run your example on the simulator matching the commit of your bitstream?

I'm able to run hello world locally on FPGA with Sonata v1 when loaded via uf2 / USB storage driver so it might be something to do with the way @nwf is loading using OpenOCD? I'll check in with them when they are awake.

This could be on the programming side, through the debug host on the SoC, rather than on the runtime/CPU side of things. If I run...

openocd -f .../sonata-openocd-cfg.tcl \
  -c 'load_image ./sim_boot_stub 0x0' \
  -c 'load_image ./image' \
  -c 'dump_image dump_sram 0x00100000 0x10000' \
  -c 'dump_image dump_hram 0x40000000 0x10000' -c exit

with image containing things to be written to both SRAM and HyperRAM, dump_sram comes back holding a copy of the HyperRAM bits (cmp dump_sram dump_hram says they're byte-for-byte identical, and indeed, these are the bytes the ELF loads to HyperRAM.) Further experiments run:

• Changing the order of the dump_image commands makes no difference.
• Switching the order of the load_image commands leaves the right bits at the top of SRAM, but the rest of SRAM is filled with a copy of HyperRAM... and unfortunately dump_hram suggests that HyperRAM is also corrupted by these later writes.
• That's true even if I use a different load_image ELF to explicitly zero SRAM first, so this isn't just residual data between openocd commands.

If I interleave loads and dumps, like this, I can see that the two purported copies of HyperRAM differ in exactly the way you'd expect given the above (for the first 146 bytes, the .text size of sim_boot_stub):

openocd -f /home/nwf/mnt/veloci-cheri/source/cheriot/lowrisc-sonata/sonata-system/util/sonata-openocd-cfg.tcl \
  -c 'load_image ./image.new' \
  -c 'dump_image dump_hram 0x40000000 0x10000' \
  -c 'load_image ./sim_boot_stub 0x0' \
  -c 'dump_image dump_hram2 0x40000000 0x10000' \
  -c exit

Is it possible that the Debug Host's writes are asserting write enables on both SRAM and HyperRAM?

FWIW, the board has the 1.0 bitstream in all three FPGA slots and the simple demo in software slot 1. I just redid that to be sure.

But yes, if I load this image via the UF2 loader (hadn't had that working locally before now), it does indeed run fine, so it's not the image's fault, I think.

ETA: is it possible to connect openocd to the Sonata simulator somehow?

H-Hey!!