Come fare il porting del kernel più recente su un dispositivo Android con il kernel esistente

Ci sono diverse domande a cui rispondere prima di intraprendere questa attività. Per esempio,

• Se le modifiche di Android sono presenti o meno nella versione più recente del kernel, cioè se è kernel vanilla o no? senza le quali Android non funzionerà correttamente

  
  

  • Modifiche in KConfig o nelle voci di defconfig della scheda di riferimento

  A volte con la versione più recente del kernel, alcune voci di configurazione aggiungerebbero o rimuoverebbero dipendenze che potrebbero benissimo interrompere alcune funzionalità. Quindi sarebbe utile rivedere le stesse.

  
  

  • Si basa sulla vecchia definizione di piattaforma basata su file di scheda o su quella basata sull'albero dei dispositivi - è necessaria una migrazione?

  Nella maggior parte dei casi, un fornitore di chip si attiene ai file di scheda per la definizione dell'hardware. In questo caso la vita sarebbe facile - basta tirare i file sarebbe sufficiente. Ma la tendenza recente è stata quella di migrare verso gli alberi dei dispositivi.

  
  

  Se nella revisione più recente del kernel a cui si sta migrando, se il fornitore di chipset ha migrato la definizione della scheda di riferimento agli alberi dei dispositivi, si potrebbe dover finire per fare lo stesso. Si noti che la migrazione a un kernel basato su un albero di dispositivi richiederebbe anche un cambiamento associato nel caricatore d'avvio - poiché è compito del caricatore d'avvio scegliere/popolare il device tree-blob appropriato dal binario/partition avviabile.

  
  

  • Modifiche nel driver's platform data?

  Ci potrebbe essere qualche modifica nella periferica dei driver dei componenti SoC, cioè l'aggiunta o la rimozione di alcune voci nella struttura dati della piattaforma che viene usata dal driver durante il probe e l'inizializzazione. Nella precedente definizione della piattaforma basata su file di bordo, i rispettivi file mach-xxx erano utilizzati per avere questi dati di struttura compilati. Quindi se c'è effettivamente l'aggiunta di nuovi campi o il cambiamento di funzionalità di qualche tipo nel driver, potrebbe benissimo risultare in un'interruzione del run-time o peggio ancora in un panico del kernel. Questo deve essere valutato - forse non per tutti i driver, almeno per quelli critici che sono appena sufficienti per portare la piattaforma di base e lo userspace associato (Android in questo caso) su e funzionante.

  
  

  • Rebuild e migrazione di moduli per funzionalità plugin come Modem (WiFi, GSM ecc.),

  Per un cambiamento nella versione del kernel, i driver che sono costruiti come moduli devono essere ricostruiti contro il kernel più recente (headers). Altrimenti la modprobe fallirebbe

  
  Queste sono alcune delle domande da approfondire per quanto riguarda il kernel. Una volta ottenuta la risposta, possiamo immediatamente inserire le nostre modifiche specifiche della scheda nella nuova versione del kernel, cioè
  

  • albero dei dispositivi / file della scheda
  • fissazioni/workaround specifici della scheda
  • eseguire ulteriori modifiche secondo i cambiamenti nel nuovo kernel specifici del sottosistema
  • Migrare, rivedere e fare le modifiche necessarie per la configurazione della scheda.

  Per fare ciò, è sempre auspicabile fare uso di GIT o di qualsiasi sistema di gestione delle versioni, poiché l'integrazione delle patch sarà facile da tracciare e completare.