La mayoría de los cambios necesarios para admitir VirtIO en AAOS implican cambios en la HAL. de implementación y los anteriores en el kernel común de Android. El framework de Android se comunica con una HAL genérica independiente del hardware mediante los controladores VirtIO en el invitado AAOS Kernel de VM, que se comunica con los dispositivos VirtIO en el host mediante protocolos VirtIO Los dispositivos VirtIO del lado del host pueden acceder al hardware físico mediante controladores de dispositivo específicos de SoC.
La comunicación entre el controlador de VirtIO y el dispositivo VirtIO se realiza con
virtqueue, que son búferes de anillo similares a la DMA de listas de recopilación de dispersión.
Varios transportes, como
MMI
o
PCI
se puede usar para intercambiar mensajes VirtIO entre VMs.
En algunos casos, se aprovechó vsock para la comunicación entre VM.
Las comunicaciones de HAL, control de audio y estado de volcado del vehículo se admiten mediante una conexión.
a un agente de intercambio de tráfico en una VM independiente a través de una interfaz vsock.
GRPC-vsock se usa para acceder a estos subsistemas no estandarizados.
GRPC
en el árbol de fuentes de Android se modificó para que funcione con vsock con la dirección
formato de vsock:CID:PORT_NUMBER.
Audio
En AAOS virtualizado, la VM invitada de Android puede usar virtio-snd para acceder al audio.
virtio-snd proporciona los dispositivos PCM virtualizados a la VM de Android para que las
implementación de HAL de audio puede interactuar con dispositivos de sonido virtualizados con el
DiminuyALSA.
La implementación de HAL de audio predeterminada se encuentra en AOSP, en
/device/google/trout/hal/audio/6.0 Los OEM pueden modificar
ro.vendor.trout.audiohal.{in,out}_period_{ms,count} para su plataforma. Los OEM pueden
implementar su propia HAL de audio anulando las variables relacionadas con el audio
/device/google/trout/aosp_trout_common.mk.
La HAL de control de audio administra el foco de audio en AAOS. Por ejemplo, cuando el sistema reproduce
sonidos de emergencia, es posible que debas silenciar la música que se reproduce en segundo plano. La HAL de control de audio
notifica a las apps que reproducen música para silenciarlas en esta situación. En el sistema virtualizado, la
pueden provenir de otras VMs. En la implementación de referencia, la VM invitada de AAOS
tiene un daemon de servidor de control de audio en ejecución, que usa GRPC-vsock para recibir
de foco de audio de otras VMs.
La VM host puede usar device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller
para enviar solicitudes de control de audio a AAOS. Mientras que libandroid_audio_controller contiene el
foco de audio, continúa enviando latidos del corazón a AAOS hasta que se libera el foco.
Bluetooth
La implementación de Bluetooth se basa en el diseño que se muestra a continuación.
Perfil de manos libres de Bluetooth
Para habilitar el perfil de manos libres (HFP) Bluetooth en trout, el dispositivo de sonido VirtIO
se amplió la especificación para admitir controles de audio. Con este enfoque, un sonido VirtIO
del lado del host o del hipervisor proporciona estos tres controles de audio relacionados con la HFP:
hfp_enablehfp_set_sampling_ratehfp_volume
Cuando AAOS se ejecuta como una VM invitada, AAOS usa pequeñoAlsa para configurar estos controles de audio. Para habilitar la HFP caso de uso específico, el host o hipervisor realiza el enrutamiento y la calibración específicos del proveedor según corresponda.
La implementación de Bluetooth se basa en la siguiente ilustración de diseño.
Estado de volcado
Cuando se genera el informe de errores para AAOS virtualizado, es valioso incluir información de la VM del host
para que los desarrolladores
tengan una visión más completa del sistema. Para lograrlo, el
La implementación de referencia de trout implementa la HAL de IDumpstateDevice, que
recopila la información de la VM del host a través de GRPC-vsock. La VM del host empaquetada en “tar”
la información se llama dumpstate_board.bin en el informe de errores, mientras que los registros de volcado se encuentran en
dumpstate_board.txt
Para configurar los comandos que se ejecutarán:
- Copia los detalles de configuración del siguiente archivo en un archivo en formato XML, por ejemplo,
config.xml<dumpstateHalConfiguration version="1.0"> <services> <service name="coqos-virtio-blk" command="/bin/journalctl --no-pager -t coqos-virtio-blk"/> <service name="coqos-virtio-net" command="/bin/journalctl --no-pager -t coqos-virtio-net"/> <service name="coqos-virtio-video" command="/bin/journalctl --no-pager -t coqos-virtio-video"/> <service name="coqos-virtio-console" command="/bin/journalctl --no-pager -t coqos-virtio-console"/> <service name="coqos-virtio-rng" command="/bin/journalctl --no-pager -t coqos-virtio-rng"/> <service name="coqos-virtio-vsock" command="/bin/journalctl --no-pager -t coqos-virtio-vsock"/> <service name="coqos-virtio-gpu-virgl" command="/bin/journalctl --no-pager -t coqos-virtio-gpu-virgl"/> <service name="coqos-virtio-scmi" command="/bin/journalctl --no-pager -t coqos-virtio-scmi"/> <service name="coqos-virtio-input" command="/bin/journalctl --no-pager -t coqos-virtio-input"/> <service name="coqos-virtio-snd" command="/bin/journalctl --no-pager -t coqos-virtio-snd"/> <service name="dumpstate_grpc_server" command="/bin/journalctl --no-pager -t dumpstate_grpc_server"/> <service name="systemd" command="/bin/journalctl --no-pager -t systemd"/> <service name="systemctl" command="/bin/systemctl status"/> <service name="vehicle_hal_grpc_server" command="/bin/journalctl --no-pager -t vehicle_hal_grpc_server"/> </services> <systemLogs> <service name="dmesg" command="/bin/dmesg -kuPT"/> </systemLogs> </dumpstateHalConfiguration> - Pasa la ruta de acceso del archivo en formato XML nuevo al servidor de dumpstate durante el inicio. Por ejemplo:
--config_file my_config.xml
Sistema de vista extendida (EVS)
El Extended View System (EVS) se usa para mostrar los videos capturados por la cámara posterior y cámaras con visión envolvente. En AAOS virtualizado, la pila de EVS puede acceder a la transmisión de video por Internet desde el dispositivo de transmisión virtualizado V4L2 que usa el controlador VirtIO-video.
Modo garaje
Para obtener más información, consulta Modo garaje:
La entrada al modo de garaje y su salida se activan con AP_POWER_STATE_REQ propiedades
enviados por la HAL del vehículo. En el modo de virtualización, el modo cochera se activa desde el host.
La VM host debe permanecer encendida para proporcionar dispositivos virtuales para la VM de Android hasta que Android
apagado. El servidor de VHAL en la VM del host envía la señal de apagado a la VM invitada del AAOS.
Cuando recibe la señal del cliente de VHAL, la VM AAOS entra en modo garaje y comienza a enviar una señal de monitoreo de funcionamiento.
para mantener activa la VM del host.
Sistema de navegación global por satélite (GNSS)
En trout 1.0, se agregó compatibilidad con la virtualización GNSS a través de virtio-console.
se agregó. La implementación admite el intercambio de mediciones sin procesar y correcciones de ubicación desde
del organizador al invitado.
El formato de intercambio de datos es el CSV que usa la app de GnssLogger. En la implementación de referencia,
Debido a que el controlador de GNSS nativo no está disponible, hay disponibles datos ficticios, pero un controlador nativo
se puede implementar sin cambios en el invitado. Se proporciona un agente host simulado de muestra como parte de
el código fuente trout
En la implementación actual, se espera que se manejen la inicialización de GNSS y el GNSS asistido (AGNSS) por el entorno del SO del host.
Gráficos
Cuando AAOS se ejecuta como VM invitada junto con otros sistemas operativos de automóviles, es posible que Android no
Tener acceso directo a la GPU o al controlador de pantalla. En este caso,
Mesa o
goldfish-opengl
y un controlador virtio-gpu en la VM invitada de Android y en el dispositivo virtio-gpu
se puede usar para acceder a la GPU.
En la VM invitada de Android, Mesa o goldfish-opengl codifica los comandos de OpenGLES
en una transmisión de Gallium o en una de GLES generada automáticamente, respectivamente. El virtio-gpu
controlador de kernel se usa como transporte. En el lado del host, virglrenderer (para Mesa) y
vulkan-cereal (para goldfish-opengl) vuelve a reproducir la transmisión de comandos decodificada en
superior del controlador de GPU existente. La plataforma de referencia de AAOS trout admite OpenGL ES
Solo con compatibilidad con Vulkan, que se espera en una versión futura.
Sensores
Cuando AAOS se ejecuta como VM invitada junto con otros sistemas operativos Es posible que Android no tenga acceso directo a los sensores. En este caso, el controlador Virtio-SCMI de la La VM de invitado de Android y el dispositivo VirtIO-SCMI de la VM host se usan para acceder a los sensores. La plataforma de referencia de virtualización AAOS proporciona una HAL de sensor genérica e independiente del hardware que se puede usar para que los SoC basados en ARM accedan a los sensores.
La HAL del sensor se comunica con el controlador IIO SCMI del subsistema IIO del kernel de Linux. que usa el protocolo de administración de sensores SCMI proporcionado por el ARM Interfaz de control y administración de sistemas (SCMI) especificación para descubrir y configurar sensores, leer datos de sensores y recibir notificaciones de sensores los cambios de valor.
El controlador IIO SCMI usa el controlador VirtIO SCMI Driver, que usa el transporte VirtIO
protocolo, como se especifica en el
virtio-scmi
la especificación para intercambiar mensajes SCMI con el dispositivo VirtIO SCMI en la VM host. El VirtIO
El dispositivo SCMI tiene acceso directo a los sensores a través de controladores de sensores específicos de SoC.
Ubicación de la HAL del sensor
La implementación de referencia de la HAL del sensor, que usa VirtIO SCMI, se encuentra en
device/google/trout/hal/sensors
Configuración de la HAL del sensor
Es posible que la HAL del sensor deba modificar los datos del sensor recibidos de la VM del host para cumplir con
Sistema de coordenadas del sensor de automóviles de Android Puedes encontrar el esquema para la configuración del sensor en
device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd
Los OEM pueden proporcionar la configuración del sensor, como la orientación y la ubicación, en
sensor_hal_configuration.xml y copia el archivo en
/odm/etc/sensors/ o /vendor/etc/sensors/.
A continuación, se proporciona un ejemplo de configuración del sensor:
<sensorHalConfiguration version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
<modules>
<module halName="android.hardware.sensors@2.0-Google-IIO-Subhal" halVersion="2.0">
<sensors>
<sensor name="scmi.iio.accel" type="1">
<configuration>
<!-- Attribute rotate denotes if HAL needs to modify the sensor data to comply with //
the Android car sensor coordinate system -->
<orientation rotate="true">
<!-- Attribute map denotes the indexes of data in sensor data received -->
<!-- Attribute negate denotes if data needs to be negated -->
<x map="0" negate="false"/>
<y map="1" negate="true"/>
<z map="2" negate="true"/>
</orientation>
<location>
<!-- Attribute x, y, z denotes location of the sensor placement -->
<x>10</x>
<y>15</y>
<z>20</z>
</location>
</configuration>
</sensor>
</sensors>
</module>
</modules>
</sensorHalConfiguration>
HAL de vehículo
La implementación de la HAL del vehículo consta de dos componentes:
- Cliente. Proporciona las APIs que usa Android en AAOS virtualizados
- Servidor. Se comunica directamente con el hardware, como los autobuses para vehículos (o un emulador).
En la virtualización, el servidor de VHAL se ejecuta en la VM del host. El cliente de VHAL y el servidor se comunican
hasta GRPC-vsock (para obtener más información, consulta
device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). Los OEM pueden usar un
protocolo de transporte diferente que no sea GRPC anulando las APIs de comunicación. Por ejemplo:
consulta device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.
Otros subsistemas
VirtIO ya ofrece una interfaz bien definida para componentes como el almacenamiento en bloque,
Red, Console, Entrada, Socket y Entropía. Para estos subsistemas, AAOS usa
el conductor tal como está, por ejemplo, virtio-blk, virtio-input,
virtio-console y virtio-net.
En la plataforma de referencia virtualizada de AAOS, se admite Wi-Fi con mac80211_hwsim.
para habilitar una red inalámbrica VirtWifi, que luego usa el túnel virtio-net
para enviar el tráfico de red a la VM host, que tiene acceso directo a la red Wi-Fi real.