On 16/09/2024 23:28, Bo Gan wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know > the content is safe > > Hi Valentina, Hi Bo, > > On 9/12/24 10:00, Valentina Fernandez wrote: >> Additional details on the Microchip vendor extension and the IPC >> function IDs described in the driver can be found in the following >> documentation: >> >> https://github.com/linux4microchip/microchip-sbi-ecall-extension >> >> The IPC remoteproc platform driver allows for starting and stopping >> firmware on the remote cluster(s) and facilitates RPMsg communication. >> The remoteproc attach/detach operations are also supported for use cases >> where the firmware is loaded by the Hart Software Services >> (zero-stage bootloader) before Linux boots. > > Would you mind help clarifying the need for SBI_EXT_RPROC_STATE/STOP/...? Sure, I provided a detailed explanation below. > If I'm not mistaken, the HW you are targeting is described in > https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ > ProductDocuments/SupportingCollateral/Asymmetric_Multi- > Processing_on_PIC64GX_White_Paper.pdf > (typo in the page 4, U51 -> E51) Yes, this is the HW that these drivers are targeted for. > In SBI, do you put hart1-3 and hart4 into 2 separate domains? If not, > I don't see why you can't just use HSM extension from SBI to kick rproc. The first AMP context (harts 1-3) is in one OpenSBI domain. The second AMP context may or may not be in an OpenSBI domain. Typical AMP use case applications have Linux SMP in one AMP context and an RTOS or BM application running in the other context. BM/RTOS applications running in m-mode won't have OpenSBI, which means they may not necessarily have an HSM. However, if the BM/RTOS is running in s-mode, then we do register them in another OpenSBI domain. We use the SBI_EXT_RPROC_START and SBI_EXT_RPROC_STOP functions to handle both scenarios. > Also, how stable is this microchip-sbi-ecall-extension? Is it subject > to changes down the road? All the FIDs described in the microchip-sbi-ecall-extension repository are stable and agreed upon between different business units within Microchip, so they will not change. There might be additional FIDs added in the future to extend functionality if ever needed, but we won't change existing FIDs. I don't see a probe() like SBI function, so > the kernel kind of assume it can call those microchip extensions without > causing unintended effects. This means those extension FIDs must be > stable and can no longer change once this code is in. Perhaps checking-in > the microchip SBI extensions to major SBI implementations such as openSBI > first would be better? Are you referring to the remoteproc driver? If that's the case, then yes, I believe we should call sbi_probe_extension(SBI_EXT_MICROCHIP_TECHNOLOGY) within the probe function. I will look into this for v2. Thanks, Valentina > > Bo
