Hi Mathieu, On Wed, Mar 13, 2024 at 10:25:32AM -0600, Mathieu Poirier wrote: > On Tue, Mar 12, 2024 at 05:32:52PM +0000, Abdellatif El Khlifi wrote: > > Hi Mathieu, > > > > On Tue, Mar 12, 2024 at 10:29:52AM -0600, Mathieu Poirier wrote: > > > > This is an initial patchset for allowing to turn on and off the remote processor. > > > > The FW is already loaded before the Corstone-1000 SoC is powered on and this > > > > is done through the FPGA board bootloader in case of the FPGA target. Or by the Corstone-1000 FVP model > > > > (emulator). > > > > > > > >From the above I take it that booting with a preloaded firmware is a > > > scenario that needs to be supported and not just a temporary stage. > > > > The current status of the Corstone-1000 SoC requires that there is > > a preloaded firmware for the external core. Preloading is done externally > > either through the FPGA bootloader or the emulator (FVP) before powering > > on the SoC. > > > > Ok > > > Corstone-1000 will be upgraded in a way that the A core running Linux is able > > to share memory with the remote core and also being able to access the remote > > core memory so Linux can copy the firmware to. This HW changes are still > > This is why this patchset is relying on a preloaded firmware. And it's the step 1 > > of adding remoteproc support for Corstone. > > > > Ok, so there is a HW problem where A core and M core can't see each other's > memory, preventing the A core from copying the firmware image to the proper > location. > > When the HW is fixed, will there be a need to support scenarios where the > firmware image has been preloaded into memory? No, this scenario won't apply when we get the HW upgrade. No need for an external entity anymore. The firmware(s) will all be files in the linux filesystem. Cheers Abdellatif
