platforms: qcom: expand and reorganize platform documentation

[zelvam95]

Summary

Update the Qualcomm platform documentation to reflect current upstream
support and clarify driver scope, authentication behavior, and platform
security responsibilities.

• Hoya and Bobcat: Correct stale configuration references and expand
  the documentation to explain driver and service purposes and chipset
  coverage. Document Kodiak's specific software workaround to vote for
  0.95 V on the MX rail during fuse blowing, including the Command DB
  lookup and RPMh vote. Add a Hoya comparison table covering PAS
  signature-authentication support and Hardware Unique Key sources.

• Qualcomm overview: Distinguish common features from platform-dependent
  features and provide navigation to the architecture-family pages and
  separate security topics.

• PAS authentication: Add an architecture overview describing the
  REE-facing TA and its direct calls to the PAS core and fuse PTAs, with
  a high-level authentication and bring-up sequence diagram. Document
  chipset coverage, the kernel's EL2 execution requirement, and the
  distinction between signature verification and firmware hash checks.
  Clarify that, with authentication support enabled, signature verification
  is skipped only when secure-boot fuses explicitly report that secure
  boot is disabled; firmware hashes are still checked.

• Security disclaimer: Add a platform-wide page explaining that product
  security depends on correctly configured secure boot and memory
  protection, including settings managed by TF-A.

• Wildcat: Add a page for the nord chipset documenting its 18-core
  Oryon configuration and GICv4 support, and link it from the Qualcomm
  overview. Explain in the security disclaimer that Wildcat's DARE-TZ
  inline memory encryption is configured by the Trust Management Engine
  (TME), outside the OP-TEE and TF-A code covered by this documentation.

[ldts]

thanks @zelvam95 for picking this up for the upcoming release. having a look now

[ldts]

@zelvam95 lets move PAS. We have Common Platform Support; we could have Platform Dependent Features and add PAS there ...maybe rethink the section names (Common Platform Features, Platform Dependent Features?)

For the PAS section, please mention that the architecture depends on Linux executing at EL2 so that the kernel can set up the translation tables (memory resources) required by the coprocessors to access memory.

Maybe a good idea to implement a security disclaimer just as NXP does - there seems to be an expectation from the user side that the firmware should be secure by default (which will never be the case). Also perhaps a suggestion to review the TF-A source for the platform's bl31 security settings seems appropiate as well (XPU gets enabled there for Hoya).

Still lets aim to make these reference docs as minimal as possible so they dont decay.

lets see if we can provide links to the TRMs - should be available publicly soon

[ldts]

also I am clearly not an UX designer, but could you check how scalable this format is going to be - thinking about the table.

[zelvam95]

@ldts, Thanks for the feedback.

Have added note on TF-A BL31 security settings and Kernel EL2 translation setup/etc..
Have made some updates to make it easy to scale to more arch/targets.

Let me know if you have any other feedback.