Una introducción al Firmware SCP es suficiente

Recientemente, un amigo lector me preguntó si tenía alguna información sobre SCP para compartir. Acabo de entrar en contacto con él antes, así que vine a estudiar contigo nuevamente hoy.

El contenido de este artículo proviene del sitio web oficial de ARM y de un artículo principal. Todo el contenido se divide principalmente en:

• Que es SCP
• Proceso de operación del firmware del procesador de control del sistema
• Directorio de códigos de SCP

Por culpa del tiempo, es cierto que se han olvidado muchas cosas, si hay algún error, por favor, ¡corríjanme! ! !

Sin más preámbulos, comencemos.

PARTE 1: Prefacio

1. ¿Qué es un SCP?

Veamos primero qué es SCP.

SCP-Firmware del procesador de control del sistema-Firmware del procesador de control del sistema-Firmware de referencia de gestión del sistema y alimentación de fuente abierta

Existe una fuerte tendencia en la industria de proporcionar microcontroladores en los sistemas para abstraer varias tareas de administración de energía u otras del sistema del procesador de aplicaciones (AP).

Arquitectura del sistema de control de potencia (PCSA-DEN0050C) describe cómo construir un sistema siguiendo este enfoque.

El PCSA define el concepto de un procesador de control del sistema (SCP), un procesador de propósito especial que se utiliza para abstraer las tareas de administración del sistema y la energía del procesador de la aplicación.

Similar al SCP, el Procesador de control de capacidad de administración (MCP) sigue el mismo enfoque con el objetivo de proporcionar un punto de entrada de administración a un sistema en chip (SoC) que requiere capacidad de administración, como en un servidor de destino SoC.

El firmware SCP proporciona una implementación de referencia de software para los componentes del Procesador de control del sistema (SCP) y el Procesador de control de capacidad de administración (MCP) en varios subsistemas informáticos de Arm.

El firmware SCP estuvo disponible recientemente como un proyecto de código abierto en GitHub, y está disponible bajo la licencia de la cláusula BSD-3.

2. ¿Qué puede hacer SCP?

• El conjunto de características incluye:
  • Inicialice el sistema para habilitar el arranque del núcleo de la aplicación
  • Servicio de tiempo de ejecución:
    • Administración de dominio de energía
    • Administración de energía del sistema
    • Gestión del dominio de rendimiento (escalamiento dinámico de voltaje y frecuencia)
    • gestión del reloj
    • gestión de sensores
    • Interfaz de administración y control del sistema (SCMI, lado de la plataforma), basada en la especificación Arm SCMI
  • Compatibilidad con las cadenas de herramientas GNU Arm Embedded y Arm Compiler 6
  • Soporte para plataformas con múltiples procesadores de control

Suponiendo que tiene una comprensión simple aquí, no digamos mucho a continuación, y comience a aprender SCP.

PARTE 2: Firmware del procesador de control del sistema

1- Que es SCP

• Abstrae las tareas de administración de energía y del sistema del procesador de aplicaciones (AP).
• Cumple con la especificación ARM System Control and Management Interface (SCMI).
• El entorno de ejecución no es fijo. Puede ejecutarse en RTOS o en un entorno bare metal.

2- Bloques de construcción básicos

Todo el LayOut está dividido en tres capas.

• módulo:

  • arquitectura agnóstica
  • Los módulos realizan un conjunto bien definido de operaciones.

• marco:

  • Proporciona servicios comunes para todos los módulos, como inicialización, eventos, notificaciones y manejo de interrupciones.
    • Capa arquitectónica dependiente de los servicios relacionados con el entorno de ejecución
  • Arquitectura y entorno de ejecución agnóstico
  • Facilita la inicialización, la coordinación y la interacción entre módulos

• Arquitectura:
  Proporciona funciones que dependen del entorno de ejecución, como hilos, interrupciones, gestión de memoria, etc.

1-Módulos (estructura fwk_module)

• Tipos de módulos
  • Capa de abstracción de hardware:
    • Interfaz común para una clase de controladores, como sensores.
    • Otros módulos usan controladores de plataforma a través de la API HAL
  • conductor:
    • Controlar dispositivos específicos.
    • Se puede implementar la API definida por el módulo HAL.
    • Los conductores pueden optar por no utilizar la HAL.
  • protocolo:
    • Proporciona interfaces específicas de protocolo a otros módulos, como el arbitraje de canales de mensajería.
  • Atender
    • Trabajo o función no relacionada con un dispositivo de hardware.
    • Puede ser autónomo y no exponer ninguna API a otros módulos

•产品由定义一个或多个固件目标的Product.mk文件组成。
•每个固件目标都是在构建产品时构建的二进制映像。
•固件目标完全由其模块集及其配置数据通过结构fwk_module_config定义。

• combinar
  • Los enlaces permiten que un módulo use el conjunto de API de otro módulo.
  • Cada conjunto de API proporcionado por un módulo se identifica de forma única.
  • Los elementos del módulo pueden proporcionar diferentes implementaciones del mismo conjunto de API

2 elementos y subelementos

• elemento

  • Recursos que pertenecen y son administrados por módulos.
  • Una abstracción que hace referencia a un dispositivo, protocolo o instancia de servicio.
  • Por ejemplo, un elemento del módulo de tipo Controlador podría representar una instancia de cada dispositivo de hardware que controla.

• Los elementos son opcionales.

• Descripción de Componente.

  • Uno para cada componente.
  • Contiene datos de configuración de elementos.

• Los elementos se definen de la siguiente manera:

  • estructura que contiene punteros para nombrar cadenas
  • El número de elementos secundarios asociados con el elemento.
  • puntero vacío a datos en formato definido por módulo

• elemento hijo

  • Un recurso que pertenece y es administrado por un elemento.
  • No hay descriptores.

Por ejemplo:

• SENSOR HAL es un módulo.
  • Los controladores de sensor térmico y PVT son módulos que utilizan el sensor HAL.
  • Los sensores PVT y térmicos se dividen en varios grupos. Cada grupo es un elemento con su propia configuración.
  • Cada sensor del grupo es un elemento secundario.

Pasos de ejecución del firmware 3-SCP

Fases previas a la ejecución: 5 fases en orden fijo

• Inicialización del módulo: la función .init() de un módulo llamada por el marco con los datos de configuración del módulo.
• • Inicialización de elementos: la función .Element_init() del módulo llamado por el marco con datos de configuración de elementos. Esta fase solo funciona si el módulo tiene elementos.
• • Posinicialización: el marco llama a la función .Post_init() del módulo. Cualquier inicialización adicional después de que los datos del elemento se proporcionen al módulo. etapa opcional.
• • La función Bind:.Bind() del módulo llamado por el framework. Los módulos y elementos se unen a otros módulos y elementos. etapa opcional.
• • El framework llama a la función Start:.Start() del módulo. Los módulos pueden usar recursos de otros módulos para completar la inicialización.

etapa opcional.

• • Flujo normal de ejecución guiado principalmente por interacciones entre módulos.
• • Eventos, notificaciones y respuestas generados y procesados.

4- Comunicación entre módulos

Eventos y notificaciones

Eventos

Eventos: una abstracción para comunicar solicitud/respuesta.
• Mecanismos de implementación de tareas lógicas en el contexto del destinatario.
• Los módulos proporcionan un controlador .procse_event() que llama Framework cuando se encuentra un módulo de destino de evento.
• Se puede enviar un evento de respuesta cuando se complete la tarea asociada con la solicitud. Las respuestas se pueden enviar como parte del procesamiento de eventos o posteriormente.
– Respuesta retrasada: la respuesta se envía más tarde, no inmediatamente después de que se procese el evento
– Respuesta estándar: Framework genera la respuesta tan pronto como regresa .produce_event().
– Una respuesta es un evento con el indicador de respuesta establecido. El firmware lo maneja de la misma manera que los eventos.

Notificaciones

Notificaciones: Eventos con el campo Notificación establecido.
• Los módulos pueden suscribirse a notificaciones de otros módulos.
• Las notificaciones son transmitidas por el marco a todos los módulos suscritos.
• Se puede utilizar para implementar cadenas de dependencia.
– Por ejemplo, si antes de una transición de energía del sistema, es posible que necesitemos cambiar el reloj o configurar algún
manejo de activación. Los módulos pueden usar notificaciones de los módulos de alimentación del sistema.

•事件（fwk_event）
•需要响应
•延迟响应
•标准响应
•无需响应

•通知（fwk_event）
•需要响应
•延迟响应
•标准响应
•无需响应

Manejo de 5 eventos

Crear evento - put_event()

poner_evento_y_esperar()

Los módulos no utilizan subprocesos públicos o de marco.
• El subproceso se bloquea hasta que se procesa el evento y se genera una respuesta.

Manejar eventos

Eventos manejados en marco/subproceso común o contexto de subproceso de módulo

6 hilos

Modelo de programación cooperativa híbrida: la programación es cooperativa entre subprocesos con la misma prioridad.

•无需锁
•使代码更简单，避免了死锁的情况。
•它消除了对执行上下文/RTOS的依赖，并防止了开销。
•事件在线程上下文中按顺序处理。

Características del modelo de subprocesamiento SCP:

• • Programación flexible en tiempo real.
• • Admite entornos de subproceso único y de subprocesos múltiples con subprocesos de igual prioridad (sin preferencia).
• • Admite programación cooperativa, como RTX RTOS compatible con CMSIS.
• • El multiprocesador no es compatible.
• • La API de subprocesamiento definida por el marco es independiente de las llamadas RTOS directas.
• • Estas API están asignadas actualmente a CMSIS.

CMSIS就是定义了一套芯片外设控制及编写规范的标准

1- Modo de subproceso único

• • El modo de operación más simple, adecuado para casi todos los entornos de ejecución no basados ​​en RTO.
• • Sin sobrecarga de subprocesos.
• • BUILD_HAS_MULTITHREADING no está definido.
• • El subproceso del marco es el único subproceso que da servicio a todos los eventos.
• • Los módulos no tienen sus propios hilos.
• • Una única cola de eventos para todos los eventos, respuestas y notificaciones.
• • Cuando ocurra una interrupción, será atendida.
• • Si es necesario posponer parte del manejo de interrupciones (mitad inferior), se insertará un evento en la cola de eventos ISR.
• • Cuando la cola de eventos está vacía, se extrae un solo evento de la cola de eventos de ISR y se coloca al final de la cola de eventos.

modelo de programación

Modalidades de implementación

Impulsado por eventos: sin prioridad

---

---

---

¡Finalmente terminado! ! !

2- Modo multiproceso

modelo de programación

• • Todos los hilos con la misma prioridad.
• • Todos los subprocesos tienen las mismas capacidades de subprocesos, proporcionadas por el marco.
• • Un subproceso espera una señal de otro subproceso para activarse y manejar eventos dirigidos a él.

---

• Adecuado para entornos basados ​​en RTOS.
• • BUILD_HAS_MULTITHREADING está definido.
• • Un hilo principal se denomina "hilo común".
• • Además, cada módulo puede crear su propio hilo.
• • Un subproceso común maneja todos los eventos de los módulos que no tienen sus propios subprocesos.
• • Cada subproceso tiene su propia cola de eventos dedicada.
• • Los subprocesos se utilizan para proporcionar un contexto de módulo separado para el procesamiento de eventos.
• • No se permite la ejecución de funciones arbitrarias de subprocesos.
• • Solo se notifica la ejecución de un subproceso en cualquier momento.

Controlado por eventos: sin prioridad
• Restricciones blandas en tiempo real (sin prioridad de subprocesos)

---

---

---

---

---

---

---

---

7- Directrices de diseño de nuevos módulos

Si desea diseñar un nuevo módulo usted mismo, puede consultar los siguientes pasos.

• Los módulos comunes deben ser compatibles con los modos de subproceso único y subproceso múltiple.

  • • Los módulos específicos del producto pueden optar por admitir cualquier modo de subprocesamiento.

• Los módulos no deben:

  • • Bloquear en modo de subproceso único sin tiempo de espera.
  • • Ejecutar tareas de ejecución prolongada en el contexto de la persona que llama. Debería generar un evento y dividir la tarea de ejecución prolongada en tareas más pequeñas a través del evento.
  • • Contexto compartido con otros módulos que requieren bloqueo.
  • • Asignar memoria que no se utilizará más adelante. El firmware no tiene una API "libre" de memoria. La administración de memoria dinámica no está implementada para mantener el firmware simple y eficiente.

PARTE 3: Directorio de códigos

Para esta parte del contenido, he extraído el esquema del artículo anterior.Para el contenido detallado, puede consultarlo en la última parte de los materiales de referencia.

---

Para enfatizar características como la seguridad y la simplicidad, y para adaptarse al firmware del sistema de control de ARM, ARM ha desarrollado este marco general, que es adecuado para trabajar en M-core o R-core, e incluso algunos sistemas privilegiados de A-core como OPTEE.

El núcleo de la seguridad es el aislamiento, el aislamiento consiste en formar módulos o dominios de acuerdo con las funciones, y el acceso no autorizado entre módulos está prohibido.

1. introducción del módulo

Cada función de SCP se implementa como un módulo separado, y el acoplamiento entre módulos es lo más bajo posible para garantizar las funciones de seguridad. Por lo general, las funciones generales requeridas por el firmware deben provenir de la interacción entre módulos. El aislamiento entre los módulos es como el marco de mordedura de perro en la imagen de arriba. Una vez que se acerque para interactuar entre sí, será impredecible. Por lo tanto, se agregan barandillas para estipular que esos módulos pueden interactuar entre sí. Esto se logra a través de Funciones API En la inicialización del sistema Cuando la configuración está muerta, el siguiente capítulo sobre vinculación entre módulos hablará de ello.

El módulo en SCP se divide en dos partes: en la carpeta del módulo del directorio raíz del código, hay un total de módulos públicos 77. Además, hay módulos debajo de cada producto, 100 es realmente mucho.

Un firmware solo contiene una parte del módulo, que se define en Firmware.cmake, y el script gen_module_code.py genera el código fuente

Estos módulos se inicializan y comienzan a ejecutarse cuando se inicia el marco.

El módulo público es más versátil, y el propio módulo del producto generalmente lo controla el controlador y debe personalizarse.

Esta pila de protocolos es el proceso de interacción entre el software SCP y el mundo exterior. Generalmente, los mensajes llegan a través del controlador->capa HAL, y luego el proceso de procesamiento es servicio->protocolo->HAL->controlador y luego operar el hardware. para responder. Se considera que esta interacción ha terminado.

proceso marco 2.framework

El framework framework es responsable de la implementación del proceso general del firmware, incluida la inicialización del sistema, la inicialización del módulo, la provisión de servicios de interrupción, la provisión de servicios de eventos, etc. De esta forma, el módulo puede enfocarse en la realización de sus propias funciones y APIs de interacción externa. El diagrama de flujo de la inicialización del marco SCP es el siguiente:

3. interfaz externa del módulo

En el código scp, todas las funciones son proporcionadas por módulos. Cada módulo proporciona la función del módulo externamente en forma de enumeración api y su estructura, y la proporciona en la estructura general fwk_module del módulo.

4. evento evento

Un módulo puede enviarse un evento a sí mismo oa otros módulos, y el parámetro del evento es un mensaje estructurado structfwk_event.

5. notificación de motivación

La notificación implica la comunicación entre dos módulos, la diferencia con el evento es:

• •el evento es enviado por un modulo a otro modulo o a si mismo, es mas seguro

• • La notificación se envía a todos los módulos que se han suscrito a este módulo, se considera una transmisión y debe suscribirse primero.

interfaz de notificación:

• •fwk_notification_subscribe//suscribirse a la notificación especificada del módulo especificado

• • fwk_notification_unsubscribe//notificación de cancelación de suscripción

• •fwk_notification_notify//Enviar una notificación al módulo que se suscribe a la notificación

En términos de implementación, la notificación utiliza el mecanismo de entrega de mensajes de evento y solo realiza cambios menores al enviar y procesar mensajes.

6. Enlace del módulo

Un módulo o elemento puede vincularse a otro módulo o elemento dentro de un módulo. El objetivo es el mismo: obtener punteros a las API que se pueden usar en etapas posteriores. Cuando se intenta vincular a un elemento dentro de un módulo (a diferencia del propio módulo), la principal diferencia es que el módulo que recibe y procesa la solicitud de vinculación puede cambiar su comportamiento según el elemento de destino. Por ejemplo, es posible permitir que un módulo que solicita un enlace solo se vincule a un subconjunto de elementos dentro del módulo que maneja la solicitud.

Idea: el módulo A necesita comunicarse con el módulo B, y las variables globales del módulo A necesitan obtener la función de devolución de llamada del módulo B.

Cuando se inicializa el módulo A, llamará a su propia función de vinculación.

bind–>fwk_module_bind–>process_bind_request() función del módulo B para obtener api

Referencias

• Especificación SCMI
• Firmware SCP
• Interfaz de gestión y control del sistema de armado
• Primeros pasos con el análisis de código del marco ARM SCP-framework