{"id":118783,"date":"2024-08-01T15:43:01","date_gmt":"2024-08-01T13:43:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/plan-prekrashheniya-podderzhki-staryh-proczessorov-arm-v-yadre-linux"},"modified":"2024-08-01T15:43:01","modified_gmt":"2024-08-01T13:43:01","slug":"plan-prekrashheniya-podderzhki-staryh-proczessorov-arm-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/plan-prekrashheniya-podderzhki-staryh-proczessorov-arm-v-yadre-linux","title":{"rendered":"Piano di cessazione del supporto per le vecchie CPU ARM nel kernel Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Arnd Bergmann, responsabile dei pacchetti core in SUSE, ha pubblicato nella mailing list degli sviluppatori del kernel Linux un piano per rimuovere dal kernel e dagli strumenti di compilazione basati su GCC il codice per il supporto delle vecchie CPU ARM e dei relativi ABI, set di istruzioni e funzionalit\u00e0 del kernel. Il piano \u00e8 attualmente in fase di RFC, cio\u00e8 aperto alla discussione della comunit\u00e0. In caso di approvazione del piano, la rimozione delle vecchie CPU ARM \u00e8 prevista per il kernel Linux 6.12, il cui rilascio \u00e8 atteso a dicembre. I primi candidati per la rimozione sono ARMv4 (senza rimuovere ARMv4T), iWMMXt, BE32 e OABI. <\/p>\n
La cessazione del supporto per le vecchie CPU ARM nel kernel coincide con la cessazione del loro supporto in GCC \u2014 alcuni dei CPU proposti per la rimozione non sono gi\u00e0 pi\u00f9 supportati nelle ultime versioni di GCC, mentre altri sono programmati per essere rimossi nelle future release, facilitando l'aggiornamento e l'implementazione di nuove funzionalit\u00e0 nel compilatore. La rimozione del supporto per l'architettura in GCC richieder\u00e0 la rimozione del suo supporto anche dal kernel nel caso venga aumentata la versione minima supportata dal kernel di GCC (attualmente, per compilare il kernel \u00e8 necessaria almeno la versione GCC 5.1). <\/p>\n
Architetture, chip e estensioni che si propongono di rimuovere dal kernel: <\/p>\n
\n
ARMv3 \u2014 il supporto \u00e8 gi\u00e0 terminato in GCC 9.\n
ARMv4 \u2014 \u00e8 utilizzato per i processori StrongARM e FA526 ancora in uso, con i pi\u00f9 recenti di questi chip rilasciati circa 20 anni fa. Il supporto per ARMv4 \u00e8 terminato in Debian 5.0. Si propone inizialmente di cessare il supporto per ARMv4 in GCC, e dopo alcuni anni anche nel kernel.\n
ARMv4T \u2014 si trovano in uso 6 famiglie di SoC con nuclei ARM720T, ARM920T e ARM922T, che sono pi\u00f9 diffusi rispetto agli SoC basati su ARMv4. Il supporto per ARMv4T \u00e8 terminato in Debian 9.0. Nel kernel, si prevede di cessare il supporto per ARMv4T non prima della cessazione del supporto per ARMv5.\n
ARMv5 \u2014 \u00e8 utilizzato su circa 1\/3 di tutte le piattaforme supportate nel kernel, ma la maggior parte di queste piattaforme \u00e8 prossima alla fine del ciclo di vita. Debian continua a supportare ARMv5, ma a causa della mancanza di FPU e operazioni atomiche, mantenere il supporto diventa sempre pi\u00f9 difficile e, probabilmente, presto la versione di Debian per ARMv5 verr\u00e0 spostata tra quelle non ufficiali.\n
Le prime generazioni di ARMv6 \u2014 sono utilizzate in SoC come ARM1136r0p (NXP i.MX31) e OMAP24xx (Nokia N8xx), ma il loro supporto richiede hack per funzionare nei kernel con SMP.\n
ARMv6K \u2014 \u00e8 utilizzato in ARM1176 (Raspberry Pi 1, AST2500) e ARM1136r1. Non ci sono ostacoli nel kernel per cessare il supporto, ma ci sono difficolt\u00e0 nei pacchetti a causa della mancata corrispondenza con il set di istruzioni tipico armv7-a+vfpv3-d16.\n
ARMv7-M \u2014 \u00e8 utilizzato nei microcontrollori basati su Cortex-M3\/M4\/M7, che rimangono gli ultimi chip supportati nel kernel senza una unit\u00e0 di gestione della memoria (MMU). I lavori sui kernel per sistemi senza MMU sono stati interrotti nel 2017, dopo il passaggio allo sviluppo di RTOS come Zephyr per questi chip. Si propone di rimuovere il supporto per ARMv7-M nel 2027, dieci anni dopo la cessazione dello sviluppo, nonostante continui il supporto in GCC.\n
iWMMXt \u2014 il supporto per la CPU ARMv7 PJ4 (MMP2, Berlin) \u00e8 stato gi\u00e0 interrotto nel kernel, pertanto non ci sono pi\u00f9 sistemi in uso che utilizzano questo set di istruzioni. Il supporto per iWMMXt \u00e8 stato gi\u00e0 rimosso in Clang ed \u00e8 proposto per la rimozione da GCC.\n
BE32 (big endian ARMv5) \u2014 \u00e8 utilizzato solo in un SoC Intel IXP4xx. Nelle vecchie versioni di Debian era supportato solo il modo little-endian, ma nei driver rimangono problemi irrisolti. Si propone di rimuovere il supporto per BE32 da GCC e dal kernel, in quanto in anni nessuno ha tentato di risolvere i problemi nei driver.\n
BE8 (big-endian ARMv7) \u2014 molti driver presentano problemi, il testing \u00e8 stato interrotto e non ci sono informazioni sui dispositivi ancora in uso. La modalit\u00e0 BE8 pu\u00f2 essere interessante per testare componenti a spazio utente su sistemi big-endian, quindi il supporto per BE8 \u00e8 pianificato per essere mantenuto nel kernel e in GCC per almeno alcuni anni fino a quando non inizier\u00e0 a causare problemi. <\/ul>\n
Opportunit\u00e0 proposte per la rimozione dal kernel Linux: <\/p>\n
\n
La struttura param_struct, utilizzata prima degli ATAGS (ARM Tag-Area) \u2014 \u00e8 stata dichiarata obsoleta gi\u00e0 nel 2001, ma \u00e8 ancora utilizzata nel codice per le piattaforme RiscPC e Footbridge.\n
I file con parametri basati sulla struttura ATAGS (utilizzati per trasmettere informazioni di configurazione fino al Device Tree) \u2014 nel kernel rimangono 29 file correlati a 10 piattaforme SoC che utilizzano gli ATAGS.\n
OABI (Old ABI, vecchio ABI per l'architettura ARM) \u2014 ora \u00e8 quasi universalmente usato EABI (Embedded ABI). OABI \u00e8 la causa di molti errori, poich\u00e9 i programmatori di driver hanno smesso di considerare alcune delle sue peculiarit\u00e0. Il supporto per OABI durante la costruzione di componenti per spazio utente \u00e8 stato interrotto in GCC 4.8, ma nel kernel \u00e8 stato mantenuto il flag \u00ab-mabi=apcs-gnu\u00bb. Si propone di mantenere OABI per il momento, ma di complicare la sua inclusione per negligenza.\n
La modalit\u00e0 di compatibilit\u00e0 con OABI (OABI_COMPAT) \u2014 consente l'esecuzione di file eseguibili costruiti per OABI, utilizzando un kernel con EABI. Si presentano problemi specifici nei driver a causa dell'incompatibilit\u00e0 con ioctl, ma il costo di mantenimento di questa modalit\u00e0 \u00e8 notevolmente ridotto rispetto al mantenimento di kernel con OABI. Per conservare il supporto per StrongARM, sar\u00e0 ragionevole mantenere il supporto per OABI o OABI_COMPAT.\n
NWFPE (No Floating Point Emulator, emulatore per l'esecuzione di operazioni in virgola mobile) \u2014 le patch per la rimozione sono state proposte gi\u00e0 11 anni fa, ma NWFPE \u00e8 necessario per il funzionamento di alcuni componenti dello spazio utente, assemblati per OABI, quindi \u00e8 consigliato mantenere il supporto per NWFPE finch\u00e9 nel kernel rimane il supporto per OABI o OABI_COMPAT.\n
Highmem (utilizzato per gestire la memoria nelle aree dopo 1 GB) \u2014 la maggior parte dei sistemi ARM pu\u00f2 funzionare senza attivare highmem o pu\u00f2 utilizzare CONFIG_VMSPLIT_2GB per accedere ai primi 2 GB di memoria fisica. Si sta lavorando per organizzare l'accesso a 4 GB di RAM sui sistemi con LPAE (Cortex-A7\/A15), dopo il completamento del quale il supporto per Highmem potrebbe essere rimosso.\n
Sparsemem \u2014 necessario per i sistemi che richiedono highmem. <\/ul>\n
Piattaforme proposte per la rimozione: <\/p>\n
\n
RiscPC \u2014 la pi\u00f9 antica delle piattaforme supportate nel kernel. Non \u00e8 supportata in GCC a partire dalla versione 9.x a causa della rimozione del supporto per ARMv3. Il manutentore continua a testare il funzionamento del kernel su questa piattaforma, ma non sembrano esserci utenti reali, quindi il supporto potrebbe essere interrotto in caso di perdita di interesse del manutentore.\n
SA1100, Footbridge \u2014 piattaforme obsolete, mantenute solo per motivi di nostalgia. Quasi tutti i file di descrizione delle schede per tali piattaforme sono stati rimossi nel kernel 6.3, rimane solo il supporto per i dispositivi ipaq h3600, assabet, netwinder ed ebsa285. La questione della rimozione dipende dalle intenzioni del manutentore.\n
Gemini, Moxart \u2014 utilizzano CPU basate su ARMv4. I chip sono stati rilasciati oltre 20 anni fa, ma il loro supporto non richiede ulteriori sforzi di manutenzione, quindi non ha senso rimuoverli fino alla rimozione della piattaforma StrongARM.\n
I file per il supporto PXA \u2014 le piattaforme sono in uno stato abbandonato e sono fuori uso; se l'interesse per esse non torner\u00e0, si prevede di rimuoverle all'inizio del 2025.\n
OMAP1 \u2014 da un lato rimane l'unica piattaforma basata su ARMv4T\/ARMv5 senza supporto per Device Tree e non ci sono segni di un passaggio a Device Tree, ma dall'altro lato la piattaforma ha ancora utenti.\n
Nspire, AT91RM9200, CLPS711X, EP93xx, iMX1 \u2014 utilizzano CPU basate su ARMv4T. Si sta lavorando alla traduzione delle descrizioni delle schede su Device Tree, ma il senso di mantenerli rimane solo fintanto che esiste il supporto per ARMv5.\n
OMAP24xx \u2014 l'unica piattaforma basata su ARMv6 con utenti attivi. La conservazione del supporto dipende dalla continua disponibilit\u00e0 della CPU arm1136r0.\n
iMX31 \u2014 non ci sono informazioni sulla presenza di utenti attivi, ma non ha senso rimuoverla prima di OMAP2.\n
S3C64xx (Cragganmore) \u2014 l'unica piattaforma senza supporto per Device Tree, costruita su ARMv6K. La piattaforma continua a essere utilizzata per testare codec audio, quindi la rimozione \u00e8 rinviata fino a quando i test non saranno trasferiti su un'altra scheda.\n
Orion5x, mv78xx0 \u2014 la questione della rimozione sar\u00e0 discussa all'inizio del prossimo anno.\n
iMX35, WM8750, AST2500, BCM2835 \u2014 sono ben supportati e hanno utenti attivi, quindi non \u00e8 previsto alcun piano di rimozione per ora.\n
stm32f4\/f7\/h7 \u2014 microcontrollori senza MMU, il supporto nel kernel continua ed esistono utenti attivi. La questione della rimozione sar\u00e0 presa in considerazione nel 2026. <\/ul>\n