This is mainly an issue of interfacing, as Rocket Chip does not use anything Zynq specific internally. If this interfacing is done properly, you should not need to change pk/linux or Rocket Chip itself. You will need to both wrap Rocket Chip for the target FPGA and interface to it with a Frontend Server (fesvr).
For wrapping Rocket Chip, I would look at the top level IO it expects (RocketChip.scala), which most importantly includes HostIO (for HTIF) and MemIO (for DRAM). For additional information on those interfaces, I would consult the slides from the first workshop. Our current wrapper (rocketchip_wrapper.v) multiplexes those interfaces over AXI to the host ARM core that is running fesvr.
Your proposal sent to the mailing list of running fesvr on a NIOS II core and communicating to it via AXI could work. This will require modifying (fesvr-zedboard.cc) to match the AXI interface NIOS provides to software. This approach may require the least new development, but the soft-core will consume FPGA resources and may be slower.
Another way to accomplish this would be to run the front-end server on a PC attached to the board via ethernet. You would need to make a bridge between Rocket Chip's MemIO and the on-board DRAM. You will also need to run HTIF over ethernet, which will require another bridge between HostIO and the board's ethernet MAC. Years ago fesvr supported this (fesvr-eth.cc), but that code has not been maintained and will almost certainly need to be updated.
This all assumes you want to run the processor in a tethered fashion. To make it self-booting will require more work. There is work on a platform specification that will standardize this, but until then you will need to design your own or continue to use Rocket Chip tethered.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…