Adding TDA4VM SoC platform support

[puranikvinit]

Creating this discussion thread to track progress and discussions/decisions taken during the TDA4VM platform support addition

[puranikvinit]

I've started analyzing the TDA4VM (K3 architecture) boot flow and platform requirements for the Bao port. I have a few architectural questions before I begin implementation.

Question 1: Heterogeneous Core Support Scope

The TDA4VM has the following cores in the main domain:

• 2x Cortex-A72
• 4x Cortex-R5F

Since U-Boot hands off to Bao on an A72 core (main domain), I'm planning to initially support both the A72 cores. As far as I have seen in other supported platforms, only one of the architectures run the hypervisor, the others not being managed by bao. Should I follow the same approach here as well, or is there an interest in R5F support?

Question 2: TISCI Protocol Implementation Strategy

TI K3 requires communication with the DMSC (Device Management and Security Control) subsystem via TISCI protocol for resource management. This requires a Secure Proxy driver and TISCI message handling.

U-Boot has a complete TISCI implementation (drivers/firmware/ti_sci.c) that handles all TISCI message types. For Bao, I'm considering a Minimal implementation approach to maintain a smaller TCB:

• Implement only TISCI messages needed for basic functionality:
  • Resource management and memory firewall management
  • Interrupt router configuration
• Can expand as needed

Please let me know if this approach seems reasonable, or if you'd prefer a different perspective.

[josecm]

others not being managed by bao. Should I follow the same approach here as well, or is there an interest in R5F support?

Yes, R5 does not haver virtualization support, so as far as Bao is concerned this cores are regardad as devices. Possibly they can be isolated using an SMMU or platform-level firewall.

Minimal implementation approach to maintain a smaller TCB:

Yes, this is exactly our ideal approach! This can now be implemented under the newly added platform level hooks. If you feel some are missing from the core files that are required for the functionality you'll implement, just add them to your patches.

Please let me know if this approach seems reasonable, or if you'd prefer a different perspective.

It seems your initial approach follows exactly our views! Let us know of any other questions and please keep us updated with the implementation (maybe start a new draft PR).

[puranikvinit]

Pull Request corresponding to this discussion -> #320 (putting it up here for reference)

Initial implementation for the A72 cluster is implemented, and needs to be tested for boot and driver sanity checks. Any changes and design/implementation feedback requested in the review will be addressed as soon as possible.

Following the boot checks, I had another question to ask.

In the current config structure that is exposed to the user, we take in the number of interrupts and the interrupt IDs that needs to be mapped per guest (eventually per core). Now this works perfectly fine for SoCs, where the peripheral to GIC lines are already in place, and only the provided SPI IDs need to be registered. But in the case of TI's Jacinto series, in addition with the GIC configurations, we also need to configure interrupt paths. This would require the user to provide the peripheral ID as well, along with the SPI line.

The interrupt line follows the following path to the processor:
[peripheral] -> [interrupt aggregator] -> [interrupt router] -> [GIC] -> [A72]

The first thing that comes to my mind would be to directly add a field in the config to get the peripheral IDs, and use them from the platform hook to configure the routes. But on second thought, does it make sense to pollute the main config struct itself, or do I expose another TI specific struct, maybe guarded by a macro, to get these? What do you have to say?

[josecm]

Let's us continue the discussion in the #320. I'll close the discussion