Compilació de la imatge¶

Aquesta secció explica com configurar el codi font del dispositiu, configurar el dispositiuinfo i el nucli i construir-lo. Aquesta guia espera que tingueu alguns coneixements obligatoris de git, com la clonació i l’empenta, i la creació de repos.

Configuració de l’entorn de construcció¶

Suposant que ja heu instal·lat les eines especificades a la secció a Configuració de l’entorn de construcció, només hi ha algunes més a afegir abans que es completi el vostre entorn de compilació. Executeu aquesta ordre per a afegir-los:

sudo apt install bc bison build-essential \
ca-certificates cpio curl flex git kmod libssl-dev libtinfo5 python2 \
sudo unzip wget xz-utils img2simg jq

Si utilitzeu una distribució basada en RPM com Mageia, executeu:

sudo urpmi gcc make glibc-devel bc bison \
rootcerts cpio curl flex git kmod libopenssl-devel libncurses5 python3 \
unzip wget xz android-tools jq

Nota

Alguns nuclis antics poden requerir Python 2 per a construir. Si la vostra distribució ha quedat obsoleta, és possible que hàgiu d’instal·lar-la manualment.

Configuració i configuració d’una font de dispositiu¶

Compilació al propi dispositiu¶

Clona un repositori de dispositius existent des de https://gitlab.com/ubports/porting. L’ideal és triar un dispositiu amb una versió similar SoC/Android com a base.

Assegureu-vos d’obtenir el repositori del dispositiu, no el repositori del nucli (això ho obtindreu en el següent pas). Per exemple, per al Fairphone 3, els repositoris s’anomenen fairphone-fp3 i android_kernel_fairphone_sdm632. El primer és el que voleu.

deviceinfo conté la configuració utilitzada durant el procés de construcció del dispositiu (nucli, arrencada, dtb/dtbo si cal + recuperació en etapes posteriors d’adaptació). Per a crear la vostra pròpia informació de dispositiu, seguiu la guia més enllà.

S’està obtenint el codi font del nucli del dispositiu¶

El primer que cal comprovar és si el vostre dispositiu té un port oficial o no oficial de LineageOS, ja que el porter pot haver fet els bits de neteja necessaris per a les fonts del kernel del proveïdor de dispositius o incorporat mòduls del nucli fora d’arbre de nou a l’arbre del nucli, cosa que ens fa la vida més fàcil.

Si no és així, comproveu si el fabricant de dispositius proporciona la font del nucli: ASUS, Lenovo, Samsung, ZTE solen proporcionar tarballs de codi font del nucli al seu lloc web. Motorola, Realme, OnePlus, Xiaomi solen carregar el codi font del nucli al seu compte oficial de GitHub.

Després d’haver adquirit la font del nucli, heu de carregar-la en un altre lloc per fer modificacions i publicacions per a Ubuntu Touch. El GitLab és el preferit, ja que quan el port s’introdueixi a l’UBports org, es pot copiar fàcilment des d’allà.

Ara hauríeu de treballar amb dos repositoris: un repositori de dispositiu clonat, que conté deviceinfo, i un repositori del nucli, que manté/mantindrà la vostra defconfig (vegeu més avall).

Edició de la configuració del nucli¶

Hi ha dues maneres de trobar la configuració correcta del nucli, i n’anomeneu algunes a continuació: 1. Obteniu la configuració al dispositiu des de /proc/config.gz 2. Obtenció de la vostra defconfig al codi font del nucli

Obtenció de la configuració des del dispositiu¶

És possible treure la configuració actual del nucli del dispositiu, si la configuració està present com a /proc/config.gz al dispositiu. Per extreure aquesta configuració, copieu el fitxer /proc/config.gz des del vostre dispositiu a l’ordinador. A continuació, executeu zcat al fitxer per obtenir la seva sortida. Deseu-ho com a .config al vostre origen del nucli. Després d’això, executeu ARCH=<l'arquitectura del vostre dispositiu> make saveefconfig, cosa que convertirà la vostra configuració completament preparada a una defconfig. Copieu defconfig a arch/<l'arquitectura del vostre dispositiu>/configs/<el nom del codi del vostre dispositiu_defconfig.

Procedeix amb la guia per apedaçar la configuració.

Obtenció de la vostra defconfig al codi font del nucli¶

Per trobar el vostre defconfig des del codi font del nucli, haureu de cercar-lo al directori arch/<l'arquitectura del vostre dispositiu>/configs. Aquest defconfig es pot anomenar de moltes maneres, com <el nom del codi del vostre dispositiu>_defconfig, o alguna cosa estranya com k61v64_debug_defconfig. Si teniu la font del nucli d’un OEM, de vegades inclou un script build.sh que fa referència al defconfig requerit. En cas contrari, si teniu la font del nucli d’algun lloc com LineageOS, el seu arbre de dispositiu també fa referència al defconfig.

Després de trobar el vostre defconfig, procediu amb la guia per apedaçar-lo.

Aplicació de pedaços mínims a la desfconfig¶

Perquè l’Ubuntu Touch arrenqui amb èxit, hem d’habilitar algunes configuracions requerides pel sistema operatiu. Comenceu navegant pel vostre directori del nucli, i pel arch/<l'arquitectura del vostre dispositiu>/configs, on haureu d’afegir un fitxer nou anomenat halium.config. En aquest fitxer, afegiu el contingut següent:

CONFIGDEVTMPFS=y

confiGFHANDLE=y

CONFIGSYSVIPC=y

CONFIGIPCNS=y

CONFIGNETNS=y

CONFIGPIDNS=y

CONFIGUSERNS=y

confiGUTSNS=y

CONFIGVT=y

Després d’això, deseu i tanqueu aquest fitxer. Si ho desitgeu, engegueu-lo al vostre repositori del nucli, perquè aquest nom de configuració s’afegirà a deviceinfo.

En aquest punt gairebé heu completat la configuració inicial del nucli, passeu a configurar deviceinfo i a compilar.

Després d’haver arrencat el sistema operatiu amb èxit, podeu passar a l’apedaçament complet de la desfconfig en etapes posteriors.

Nota: podeu confondre per què estem editant un fitxer seperat, halium.config, en lloc de <codename>defconfig. Aquests fitxers se seleccionaran junts a la informació del dispositiu, «combinant-los». D’aquesta manera, mantenim els canvis nets i llegibles.

Compilació al propi dispositiu¶

Nom complet del dispositiu, com Redmi 9C o Redmi Note 10S. Reemplaça com sigui necessari.

deviceinfo_name="Redmi 9C"

El nom del fabricant del dispositiu. Canvi segons sigui necessari.

deviceinfo_manufacturer="Xiaomi"

El nom en clau del telèfon. Això es pot obtenir fent-li una ullada com: «<device name> codename». Substitueix el nom del dispositiu pel nom complet del telèfon. Substitueix el nom en clau de sota també pel teu.

deviceinfo_codename="angelica"

L’arquitectura del vostre nucli. La majoria dels dispositius llançats després de 2015 tenen una CPU ARM64, però algunes rareses entre si encara poden ser armhf. Per als dispositius ARM64, establiu la configuració a «aarch64». Per als dispositius armhf, establiu la configuració a «armv7».

deviceinfo_arch="aarch64"

Això defineix el repositori git on es troba el vostre nucli. Ja hauríeu de tenir aquest enllaç a mà si heu seguit l’apartat 1, si no el torneu a travessar. Substitueix a continuació l’enllaç amb el teu propi.

deviceinfo_kernel_source="https://github.com/muhammad23012009/android_kernel_xiaomi_dandelion"

La branca del nucli ve a continuació. Això es pot obtenir fàcilment mirant la pestanya sota la pestanya Codi a GitHub o la pestanya a la part superior esquerra de GitLab. Reemplaça com sigui necessari.

deviceinfo_kernel_source_branch="halium10-new"

Defconfig és una part vital del procés de compilació del nucli. La majoria de vegades podeu trobar aquest defconfig a la font del nucli, el camí al qual és «arch/<l’arquitectura del vostre dispositiu>/configs». El nom de defconfig sovint es construeix com «<el nom del codi del vostre dispositiu>defconfig». Després de trobar el vostre defconfig, substituïu-lo segons sigui necessari. També heu d’afegir halium.config en aquest camp, a causa d’afegir els pedaços de configuració del nucli anteriors. (Si encara no podeu trobar el defconfig, consulteu la secció «Trobar el vostre defconfig»)

deviceinfo_kernel_defconfig="angelica_defconfig halium.config"

El nucli cmdline és una de les coses clau que es requereixen per a fer que el nucli arrenqui. Té paràmetres especials que permeten al nucli determinar quines característiques/coses s’han d’habilitar i quines s’han d’inhabilitar. Els rootfs d’Ubuntu Touch també es basa en algunes línies d’ordres clau que es requereixen per arrencar, més específicament «console=tty0». Per adaptar-ho al vostre dispositiu, proveu de desempaquetar la vostra imatge d’arrencada (secció 8.3) i copiar la línia d’ordres d’allà, o preneu l’ajuda d’un arbre de dispositius LineageOS si està disponible. «console=tty0» és una cosa a tenir per a la línia d’ordres i no s’ha de treure en cap cas. La resta de les coses es poden eliminar i podeu ajustar-les al vostre dispositiu. console=tty0 és un requisit perquè el rootfs arrenqui correctament. systempart s’afegeix si voleu arrencar el vostre rootfs des de la partició del sistema. Ha d’apuntar a la partició del vostre sistema.

deviceinfo_kernel_cmdline="console=tty0 bootopt=64S3,32N2,64N2 systempart=/dev/mapper/system"

Afegiu-ho al vostre deviceinfo si voleu compilar el vostre nucli amb clang. La majoria dels dispositius llançats amb i després d’Android 10 construeixen els seus nuclis amb clang. Si no voleu construir amb clang, ometeu aquesta entrada completament.

deviceinfo_kernel_clang_compile="true"

Només és necessari si voleu utilitzar LLD com a enllaçador i activar LTO. Per a la majoria dels nuclis antics, LTO està trencat. Si voleu utilitzar-lo, afegiu aquesta entrada al vostre dispositiuinfo, en cas contrari ometeu-la.

deviceinfo_kernel_use_lld="true"

Aquesta configuració us permet compilar el vostre nucli amb LLVM i LTO, atès que està suportat per ell. Aquesta és una manera clara d’especificar clang i ld.lld junts. Normalment són necessaris pels dispositius GKI. (Un cop activat, no cal especificar deviceinfo_kernel_use_lld)

deviceinfo_kernel_llvm_compile="true"

Useu això per a habilitar «dtcext» per a compilar els vostres dtb/dtbo. Utilitza’l només si saps el que estàs fent. El compilador predeterminat funciona la majoria de vegades.

deviceinfo_kernel_use_dtc_ext="true"

Utilitzeu aquesta opció per a especificar el nom de la imatge del nucli després que el nucli compili. Més que sovint aquesta opció simplement no és necessària, de manera que podeu deixar-la anar des de la vostra informació del dispositiu. Si ho necessites, ajusta el nom de la imatge segons sigui necessari.

deviceinfo_kernel_image_name="Image.gz"

Per tal d’especificar el vostre algorisme de compressió de ramdisk, utilitzeu l’opció següent. Per defecte s’estableix a gzip. Molt útil per a dispositius GKI.

deviceinfo_ramdisk_compression="lz4"

Afegiu aquesta opció per a especificar la vostra versió de Halium. Fins a Halium 13 és suportat en aquest moment.

deviceinfo_halium_version="11"

Aquesta opció defineix la versió de la capçalera de la imatge d’arrencada. És important que ho encerteu, en cas contrari el vostre dispositiu pot no arrencar. Els dispositius que es llancen amb versions d’Android per sota de 8 (Oreo) utilitzen la capçalera 0, Android 9 (Pie) utilitza la versió 1, Android 10 utilitza la versió 2, i els dispositius GKI utilitzen la versió 3/4 (depenent de la versió d’Android que van ser llançats, Android 12 amb GKI utilitza la versió 4).

deviceinfo_bootimg_header_version="2"

Utilitzeu aquesta opció per a definir un dtb preconstruït que heu creat. El camí és relatiu al vostre directori on esteu editant el fitxer deviceinfo. Editeu el nom dtb segons el que tingueu. Si la vostra versió de capçalera és més gran o igual que 3 (dispositiu GKI), això inclourà dtb al vostre proveïdorboot.

deviceinfo_bootimg_prebuilt_dtb="mt6765.dtb"

Aquesta opció utilitza les dtb creades pel vostre nucli mentre compileu, es poden especificar múltiples dtb aquí com: «mediatek/mt6765.dtb mediatek/angelica.dtb» El camí en què els scripts cerquen les dtb amb aquesta opció activada és «KERNELOBJ/arch/<architecture>/boot/dts» on<architecture>serà arm64 o arm depenent del que establiu a deviceinfoarch (aarch64 és arm64 al kernel speak) Si la vostra versió de capçalera és més gran o igual a 3 (dispositiu GKI), això inclourà dtb al vostre vendorboot.

deviceinfo_dtb="mediatek/mt6765.dtb"

En seleccionar això es construirà una imatge DT que heu seleccionat a la imatge d’arrencada. El camí és relatiu al vostre directori actual en el qual esteu editant deviceinfo. (Nota: Això només és realment necessari en dispositius Samsung/Exynos.)

deviceinfo_bootimg_prebuilt_dt="exynos8890-dt.img"

Useu això per a enviar un dtbo preconstruït a les OTA i per a construir la recuperació amb aquest dtbo si encara no s’està compilant. El camí torna a ser relatiu al vostre directori de construcció. Edita com es desitgi.

deviceinfo_prebuilt_dtbo="angelica-dtbo.img"

En cas que no vulgueu enviar la imatge DTBO en una OTA, en seleccionar-la només s’eliminarà el dtbo del paquet OTA, però la recuperació encara es compilarà amb aquest dtbo, si el dtbo no s’està compilant.

deviceinfo_skip_dtbo_partition="true"

Si voleu compilar el vostre DTBO des del nucli, utilitzeu aquesta opció per a seleccionar els fitxers dtbo compilats al directori kernel out. El camí en el qual aquesta opció cercarà és KERNELOBJ/arch/<architecture>/boot/dts. Es poden subministrar múltiples dtbo com es mostra a l’exemple. Adapta els noms segons les teves necessitats. La imatge dtbo resultant s’enviarà a l’OTA si l’opció skipdtbopartition no està seleccionada, i en qualsevol cas la recuperació també es construirà amb aquest dtbo. Aquesta opció és incompatible amb l’opció dtbo preconstruïda.

deviceinfo_dtbo="mediatek/galahad.dtbo mediatek/lancelot.dtbo"

Usant això es definirà el nom del tauler a la imatge d’arrencada, que alguns carregadors d’arrencada requereixen per arrencar la imatge amb èxit. Utilitzeu aquesta opció només si la vostra imatge d’arrencada d’estoc té aquest indicador establert a la seva capçalera. Editeu com vulgueu si cal.

deviceinfo_bootimg_board="EXYNOS4412"

Utilitzeu aquesta opció per a enrotllar la imatge d’arrencada a una mida específica. També es requereix si voleu afegir una imatge vbmeta o afegir un peu de pàgina hash a la vostra imatge. Canvieu la mida a la mida de la imatge d’arrencada. (Nota: La mida es declara en bytes).

deviceinfo_bootimg_partition_size="67713847"

Molt auto-explicatiu. Establiu-ho a cert si el vostre dispositiu requereix una imatge vbmeta annexada (No és el cas de la majoria de dispositius amb una partició vbmeta dedicada).

deviceinfo_bootimg_append_vbmeta="true"

Utilitzeu aquesta opció quan vulgueu crear un recovery.img per arrencar la recuperació d’UBports (Només es requereix realment quan finalitzeu el port). En la majoria dels casos, voldreu ometre això a l’inici del vostre port i afegir-lo mentre intenteu obtenir-lo a l’instal·lador. Establir a cert construeix la recuperació i establir a fals o ometre l’entrada completament farà que no es construeixi en absolut.

deviceinfo_has_recovery_partition="true"

Useu això per a empacar la imatge de recuperació a una mida específica. També és un requisit si voleu afegir un peu de pàgina de hash a la vostra imatge. Reemplaça la mida de la imatge de recuperació d’estoc. (Només funcionarà si estàs construint recuperació!)

deviceinfo_recovery_partition_size="67713847"

Això només és realment necessari per a un Samsung antic/nou que comprovi un peu de pàgina «SEAndroid» a les seves imatges d’arrencada per comprovar si les imatges d’arrencada són o no oficials. Si el carregador d’arrencada no el troba, es tradueix en una línia vermella d’aspecte lleig a la part superior de la pantalla. Si afegiu això al vostre dispositiuinfo, s’afegirà aquesta cadena a la imatge d’arrencada. (Aneu amb compte! Usar això en altres dispositius pot fer que no arrenqui la imatge!)

deviceinfo_bootimg_tailtype="SEAndroid"

Aquesta configuració determina si els mòduls s’han de compilar i instal·lar a rootfs o no. Ometre aquesta configuració dona com a resultat el comportament per defecte, és a dir, els mòduls es compilen i s’instal·len a rootfs. Si afegiu aquesta opció a la vostra informació del dispositiu i l’establiu a «true» (com es mostra) es desactivarà la compilació dels mòduls. Només és realment necessari per si estàs fent alguna cosa avançada.

deviceinfo_kernel_disable_modules="true"

Aquesta opció instal·la tots els fitxers superposats (en superposició/directori) a /system/opt/halium-overlay, superposant els fitxers als fitxers presents a rootfs en lloc de reemplaçar-los completament. Això és necessari per al 20.04 i endavant, però no aplicable per al 16.04.

deviceinfo_use_overlaystore="true"

Aquesta opció s’utilitza principalment en alguns dispositius Qualcomm. Si afegiu això al vostre dispositiuinfo, combinareu tots els vostres dtbo amb els vostres dtbs. Utilitzeu-lo només si esteu segurs que ho necessiteu.

deviceinfo_kernel_apply_overlay="true"

Afegiu aquesta configuració al vostre dispositiuinfo quan necessiteu especificar una mida fixa per als vostres rootfs que s’estan fent parpellejar a la imatge del sistema. Per defecte és 3000M quan l’opció no està establerta. Només utilitza’l si ho necessites.

deviceinfo_system_partition_size="4000M"

Aquesta configuració només és rellevant per als dispositius més nous llançats amb emmagatzematge UFS

deviceinfo_rootfs_image_sector_size="4096"

A continuació es mostren els desplaçaments del flaix. Podeu ignorar-los si només esteu construint boot.img per a un dispositiu GKI, però són necessaris si voleu construir vendorboot.img. Aquests desplaçaments s’aplicaran automàticament a vendorboot si la vostra versió de capçalera és més gran o igual que 3. Una guia per extreure’ls és la següent:

S’estan extraient els valors de l’estoc boot.img/vendorboot.img¶

Perquè qualsevol port arrenqui, s’han de treure alguns valors de l’estoc boot.img. Primer i abans de res, intenteu obtenir el vostre microprogramari. A alguns fabricants com Samsung els agrada xifrar els seus microprogramaris, però encara hi ha algunes eines disponibles per aconseguir-los. Altres com Xiaomi proporcionen el microprogramari, però heu d’utilitzar Google per cercar-lo. I després hi ha el bon noi Google, que proporciona binaris de microprogramari complet fàcilment accessibles. Llarga història curta, almenys has de trobar el teu microprogramari, i després aconseguir el boot.img. Un cop tingueu el boot.img adquirit, seguiu els següents passos:

Fes un directori en el qual emmagatzemaràs totes les teves dades desempaquetades. Pot ser en qualsevol lloc, i pot tenir qualsevol nom. De moment, l’anomenarem temptemp..

Executeu «mkdir /temp» per a crear el directori i «cd /temp» per a anar-hi.

Ara per a desempaquetar la imatge d’arrencada hi ha diverses utilitats per a fer-ho. Un d’ells és l’script de Python proporcionat per Android. De moment ho utilitzarem. Per descarregar-lo al directori de treball actual executeu «wget https://raw.githubusercontent.com/LineageOS/androidsystemtoolsmkbootimg/lineage-19.1/unpackbootimg.py» Això descarregarà l’script unpackbootimg.py, que ara utilitzareu per treure els vostres desplaçaments del nucli i altres valors per igual

Porteu el vostre boot.img al directori temp.

Ara executeu l’script. La sintaxi habitual és «python3 unpackbootimg.py –bootimg <boot.img or vendorboot.img> –out out» Això desempaquetarà la imatge d’arrencada, emmagatzemarà els fitxers de sortida al directori out i també imprimirà els desplaçaments a la pantalla.

Una sortida de mostra per a boot.img es veurà així:

màgia d’arrencada: ANDROID!

kernelsize: 11399060

adreça de càrrega del nucli: 0x40080000

Mida del disc RAM: 6576255

Adreça de càrrega del disc RAM: 0x51b00000

segona mida del carregador d’arrencada: 0

segona adreça de càrrega del carregador d’arrencada: 0xc0ff0000

adreça de càrrega d’etiquetes del nucli: 0x47880000

mida de la pàgina: 2048

os versió: 10.0.0

nivell de pegat os: Cap

versió de la capçalera de la imatge d’arrencada: 2

nom del producte:

línia d’ordres args: bootopt:64S3,32N2,64N2 buildvariant:user systempart//dev/mapper/system:ro

arguments addicionals de la línia d’ordres:

recuperació de la mida del dtbo: 0

recuperació del desplaçament dtbo: 0x0000

mida de la capçalera d’arrencada: 1660

mida de dtb: 216417

adreça dtb: 0x0000000047880000

mentre que per a vendorboot.img, es veurà així:

màgia d’arrencada: VNDRBOOT

versió de la capçalera de la imatge d’arrencada del proveïdor: 4

mida de la pàgina: 0x00001000

adreça de càrrega del nucli: 0x10008000

adreça local de disc RAM: 0x10000000

mida total del disc ram del proveïdor: 13685168

args de la línia d’ordres del proveïdor: bootconfig loop.maxpart:7

adreça de càrrega d’etiquetes del nucli: 0x10000000

nom del producte: SRPUK23A007

mida de la capçalera de la imatge d’arrencada del proveïdor: 2128

mida de dtb: 231604

adreça dtb: 0x0000000011f00000

mida de la taula ramdisk del proveïdor: 216

mida de la configuració d’arrencada del proveïdor: 28

Aquí és on això serà interessant.

«Nucli load address» és el desplaçament del nucli. El valor després del dos punts és el que necessites, per exemple, 0x40080000. Això serà diferent en el seu cas.

L’adreça de càrrega de discs enram serà el vostre desplaçament de discs en ram. Agafa el valor que hi ha al costat. Per exemple, 0x51b00000.

La «segona adreça de càrrega del carregador d’arrencada» és majoritàriament innecessària pels estàndards actuals. Però si la vostra imatge d’arrencada escopeix aquest valor, assegureu-vos de prendre-ho. Per exemple, 0xc0ff0000.

L’adreça de càrrega de les etiquetes del nucli és especial. S’utilitza tant per a etiquetes del nucli com per a dtb, però en alguns casos aquests valors poden ser diferents. Agafa també el valor. Per exemple, 0x47880000.

«dtb address» de vegades és el mateix que «kernel tags load address». Però si és diferent, hauríeu d’utilitzar això per a dtb i etiquetes per a etiquetes.

Es requereix «mida de pàgina» perquè el disc RAM sàpiga què fa servir el xip flash per a les mides de pàgina. El valor després del còlon és el que necessites. Per exemple, 2048.

«versió OS» és el valor que determina quina versió d’Android té aquest boot.img. Alguns carregadors d’arrencada ho fan complir. Per exemple, 10.0.

El «nivell del pegat del so» és una història similar. També voldràs agafar aquest valor, per exemple, 2021-11.

«command line args» va directament a deviceinfokernelcmdline. Assegureu-vos de mantenir «console.tty0» allà dins. No hi ha exemples aquí :(

Si esteu construint vendor_boot, aquesta ordre també generarà un fitxer bootconfig al vostre directori de sortida. Moveu això a l’arrel de l’arbre d’origen.

A part d’aquests valors esmentats, voldràs saltar-te tota la resta.

Ara, d’acord amb aquesta guia, emplena els teus desplaçaments:

Posa el valor de «mida de pàgina» en aquesta configuració.

deviceinfo_flash_pagesize="2048"

El desplaçament base sempre romandrà 0x00000000.

deviceinfo_flash_offset_base="0x00000000"

Ompliu-ho des de l’adreça «Càrrega del nucli».

deviceinfo_flash_offset_kernel="0x40080000"

Això obté el seu valor de l”«adreça de càrrega deramdisk».

deviceinfo_flash_offset_ramdisk="0x51b00000"

Encara que no sigui crítica amb la missió, si heu obtingut el seu valor, ompliu-lo des de la «segona adreça de càrrega del carregador d’arrencada».

deviceinfo_flash_offset_second="0xc0ff0000"

Les etiquetes s’han d’omplir des de l’adreça de càrrega de les etiquetes del nucli.

deviceinfo_flash_offset_tags="0x47880000"

El desplaçament DTB prové de l”«adreça de càrrega dtb».

deviceinfo_flash_offset_dtb="0x47880000"

Això ve de la versió «os». No és exactament necessari, però alguns OEM ho fan complir.

deviceinfo_bootimg_os_version="10.0"

Voldreu posar aquí el valor del «nivell del pegat del SO».

deviceinfo_bootimg_os_patch_level="2021-11"

Si esteu construint un vendor_boot i heu mogut el fitxer bootconfig a l’arrel del vostre arbre, afegiu el següent:

deviceinfo_vendor_bootconfig_path="bootconfig"

I d’aquesta manera, heu omplert correctament la vostra informació del dispositiu i ara podeu continuar amb el port!

Construir, instal·lar i executar¶

Després d’haver completat la informació del vostre dispositiu i omplert totes les coses necessàries, ha arribat l’hora de la part principal, la compilació. Per a això, simplement executeu:/build.sh -b workdir

Això hauria de descarregar totes les cadenes d’eines necessàries i després el nucli, i finalment construir tot. Aquest procés pot trigar entre 5 i 50 minuts a construir el nucli.

Després que el vostre nucli hagi acabat de construir, podeu procedir a instal·lar-lo i arrencar-lo en el següent pas.