Loading binary to Memory bus scratchpad without having to take Rocket Tiles out of reset

[Kevin99214]

I have been working on a unique configuration of Rocket-chip with a broadcast manager, no memory port, scratchpad memory on the memory bus, a front AXI port and separated Rocket Tile clock/reset from the reset of the system. I have also removed the bootROM and pointed the reset vector directly at the start of the scratchpad memory.

Now, to load the binary I want the Rocket cores to run, I have been initiating AXI traffic to the front port to target the address space of the mbus scratchpad. I keep the cores in reset so they don't execute anything before I've loaded my binary. The part I am having trouble with is this:

1. When my writes get to the broadcast manager, it sends out TL probe messages to ensure the address I am writing to are not cached, which makes sense. But the cores are in reset and they never respond to the probes so my test times out.
2. If I take the cores out of reset, my writes go through to the scratchpad. But while the binary is being loaded, the cores are running some garbage instructions.

I have some hack-y ideas around this.

• I could put in an incoherent path from sbus to mbus but that takes up more address space/more logic.
• instead of using a front port, I could add an axi port on the mbus but that adds an extra port that I would only use once during boot
• somehow change the scala to keep ICache in reset but take DCache out of reset so I can get response to probes but no instructions fetches will occur

Those ideas are not very clean but I am not sure of another way. If anyone have any ideas or if I've missed anything, I would love to hear them!

[jerryz123]

If I take the cores out of reset, my writes go through to the scratchpad. But while the binary is being loaded, the cores are running some garbage instructions.

I think the real issue is here. In our chipyard SoCs, the cores spin in a BootROM, executing non-garbage instructions (loops or a wfi), until the binary has finished loading, and an interrupt is sent to the core to have it jump into the loaded program.

[Kevin99214]

I want the rocket-chip to act as a secondary system, in a sense where a primary system will have a BootROM, boot, do some setup, and pass a binary over to rocket-chip to run.
I would prefer to not have more than one BootROM but if there isn't any other clean way to do it, it might be something I'll have to accept.

[jerryz123]

Having an embedded small ROM in an embedded system is, IMO, preferable to fiddling with reset in the embedded system. Keeping the core in reset while driving the memory system is not well supported (as you've seen).

I think separate bootroms for embedded systems is a common pattern. A small custom BootROM (perhaps even more concise than the default chipyard/rocket-chip one) could just park the core in a busy loop until either an interrupt or polling-based mechanism wakes it up.

[Kevin99214]

I'm inclined to agree with what you said the more I think about it. Having a small ROM might end up being easier to do than some other backdoor method.

Thanks for the help 😄