Roadmap

individuare architettura -> toolchain

compilare il layer bsp di stm flashare tramite cube

compilare bootloader flashare su sdcard flashare su emmc tramite cube

avviare linux (automatizzare con yocto) -> lo usiamo di base installare un applicativo custom

advanced: configurare qt5

advanced: ab update implementare ab update per linux implementare ab update per bootloader

Architettura

I micro processori della famiglia STM32MP2 sono tutti basati su architettura ARM a 64bit. Nel mondo Linux e delle toolchain in generale, questa architettura è identificata con i nomi:

ARM64
aarch64
armv8

Siccome ARM nasce come architettura a 32bit, di default si assume che il termine “arm” si riferisca a un 32bit, mentre “arm64” si riferisca a un 64bit.

Bootloader

https://wiki.st.com/stm32mpu/wiki/STM32MP2_boot_chain_overview

Da questo documento capiamo che il micro dispone di un ROM code (quindi non modificabile), che poi necessita di altri componenti per gestire l’inizializzazione del sistema. Questi altri componenti si occupano di

inizializzare la RAM esterna (di tipo DDR)
inizializzare il contesto di sicurezza del micro (quali zone di memoria sono riservate)
inizializzare varie periferiche
trovare il kernel linux su disco e avviarlo coi parametri corretti

Non esiste quindi un singolo bootloader, ma piuttosto una bootchain formata da:

TFA (Trusted Firmware Arm)
OPTEE (Open Portable Trusted Execution Environment)
UBOOT (classico bootloader per embedded)

Linux

Quando saremo in grado di arrivare a una shell linux, gran parte del lavoro sarà fatta e resterà da configurare il caricamento dei moduli kernel necessari e l’installazione degli applicativi di cui abbiamo bisogno. La quasi totalità di questo processo la faremo direttamente in Yocto.

Customizzazioni

Nel mondo embedded esiste un modo comune, ma abbastanza flessibile, per descrivere l’hardware di una scheda. Si chiama Device Tree.

Questo contiene informazioni su quali driver il software deve usare per interagire con determinate periferiche e anche alcuni parametri per configurarle. Questo file descrittivo è quindi un componente fondamentale del nostro runtime.

Molti bootloader inoltre necessitano di questo device tree per il processo di compilazione, al fine di configurare certe loro parti.

https://wiki.st.com/stm32mpu/wiki/Category:Device_tree

Repositories

TFA - STM fork UBOOT - STM fork OPTEE - STM fork LINUX - STM fork

Come facciamo a sapere che STM ha creato dei fork delle varie repository open source di questi componenti? Dal utilizzo di queste all’interno del loro layer BSP

TFA - STM Recipe

# from 
# meta-st-stm32mp/recipes-bsp/trusted-firmware-a/tf-a-stm32mp-common.inc
# ---------------------------------
# Configure devupstream class usage
# ---------------------------------
BBCLASSEXTEND = "devupstream:target"

SRC_URI:class-devupstream = "git://github.com/STMicroelectronics/arm-trusted-firmware.git;protocol=https;branch=${ARCHIVER_ST_BRANCH}"
SRCREV:class-devupstream = "cadc66f13d2b8f292fe9335bf097b8801f5a4cd7"

UBOOT - STM Recipe

# from 
# meta-st-stm32mp/recipes-bsp/u-boot/u-boot-stm32mp-common_2023.10.inc
# ---------------------------------
# Configure devupstream class usage
# ---------------------------------
BBCLASSEXTEND = "devupstream:target"

SRC_URI:class-devupstream = "git://github.com/STMicroelectronics/u-boot.git;protocol=https;branch=${ARCHIVER_ST_BRANCH}"
SRCREV:class-devupstream = "64beae9fed51f49b53f952d00d9918b9eb3b040b"

OPTEE - STM Recipe

# from 
# meta-st-stm32mp/recipes-security/optee/optee-os-stm32mp_4.0.0.bb
# ---------------------------------
# Configure devupstream class usage
# ---------------------------------
BBCLASSEXTEND = "devupstream:target"

SRC_URI:class-devupstream = "git://github.com/STMicroelectronics/optee_os.git;protocol=https;branch=${ARCHIVER_ST_BRANCH}"
SRCREV:class-devupstream = "a8dd87d45831be900f0aaa44a5e0587269e3df25"

LINUX - STM Recipe

# from 
# meta-st-stm32mp/recipes-kernel/linux/linux-stm32mp_6.6.bb
# ---------------------------------
# Configure devupstream class usage
# ---------------------------------
BBCLASSEXTEND = "devupstream:target"

SRC_URI:class-devupstream = "git://github.com/STMicroelectronics/linux.git;protocol=https;branch=${ARCHIVER_ST_BRANCH}"
SRCREV:class-devupstream = "f01241fbba4d879fa770685629b49d42e904e43c"
#FIXME force the PV to avoid build issue:
#  do_package: ExpansionError('SRCPV', '${@bb.fetch2.get_srcrev(d)}', FetchError('SRCREV was used yet no valid SCM was found in SRC_URI', None))
PV:class-devupstream = "${LINUX_VERSION}${LINUX_SUBVERSION}-${LINUX_TARGET}.${SRCPV}"

Perchè utilizzare le loro repository invece che quelle ufficiali? Il motivo è che a causa della grande quantità di cambiamenti e aggiunte, che sicuramente sono stati fatti da STM per integrare i loro componenti specifici all’interno di questi software, sarebbe estremamente dispendioso capire quali modifiche sono state fatte e replicarle noi stessi. Tanto vale partire dalla loro base di codice e piuttosto capire come configurarla a nostro piacimento.

Perchè rifare dei recipe da zero invece che utilizzare quelli STM? Anche qua, potremmo risparmiarci molto lavoro utilizzando direttamente i loro recipe, ma questi spesso introducono ulteriori complessità e dipendenze all’interno del nostro progetto e soprattutto non espongono in modo chiaro come avviene la configurazione del codice sorgente. Per questo, personalmente, preferisco ricreare i recipe, in modo da poter fare riferimento per la maggior parte delle informazioni alla documentazione ufficiale del progetto e in caso faticare un po’ di più per capire i dettagli specifici necessari per la piattaforma STM. Questo mi obbliga sì a studiarmi gran parte del codice sorgente, ma con la sicurezza di saper dove mettere le mani, qualora ne avessi bisogno.

Punto alla libertà di configurazione, ma sapendo di avere tra le mani un codice sorgente che dovrebbe funzionare senza problemi sulla mia piattaforma.

Ma soprattuto ho odiato dover capire i giri e rigiri che avvenivano nei recipe STM per poi alla fine assegnare dei valori del cazzo ad alcune variabili di compilazione.

Docs

YoctoLearn

Title here