Linux en un 286?

No tengo un 286 ni tengo la intención de ejecutar Linux en uno. Sin embargo, dado que el 286 tiene modo protegido, ¿por qué se dice con frecuencia que Linux requiere una CPU 386 o superior?

Desde http://tuxmobil.org/286_mobile.html parece que la versión ELKS de Linux puede ejecutarse en un 286, ¿es esto correcto? ¿Qué modificaciones (si alguna) se han realizado para permitir que el núcleo se ejecute en la CPU 286?

Ahora, obviamente, entiendo que un núcleo compilado para un 386 no puede ejecutarse en una CPU 286, que es de 16 bits. Entonces mi pregunta es, ¿por qué no se puede compilar el kernel estándar de Linux para un 286 y luego ejecutarlo en un 286? ¿Linux requiere soporte de hardware VM86?

El modo protegido (PM) 286 es fundamentalmente diferente de lo que ofrece el 386. Piense en el 286 PM como un prototipo, que tenía tantas deficiencias que casi nadie lo usó, y todo fue completamente rediseñado desde cero para el 386.

No usaba un modelo de memoria plana, usaba un modelo segmentado como el modo real, lo que significaba que tenía que saltar a través de aros para acceder a la memoria en bloques de más de 64kB a la vez.

Era completamente incompatible con todos los programas (MS-DOS) disponibles en ese momento, por lo que una vez que estaba en PM no podía usar ninguno de los programas a los que estaba acostumbrado.

Tampoco podría volver a salir del modo protegido a menos que reiniciara la PC, por lo que los fabricantes idearon soluciones creativas como colocar una bandera en la RAM y luego escribir un valor mágico en el controlador del teclado, que movería el pin de reinicio en la CPU para reiniciar el máquina. Lo primero que haría el BIOS sería detectar el conjunto de indicadores anterior, donde luego volvería al programa original en lugar de ejecutar la rutina POST, permitiendo que el programa original continúe ejecutándose después de "salir" de la MP.

Esto significaba que usar el 286 PM le impedía ejecutar programas normales de DOS sin una gran cantidad de trucos. En un momento en que solo había programas DOS, no valía la pena usar PM en absoluto.

Por lo tanto, resultó más complicado trabajar con el 286 PM que simplemente vivir sin él, y confiar en EMS y XMS para acceder a la memoria adicional. Un número de 286 placas base tenían soporte de chipset para EMS para que pudiera usar toda la memoria adicional del sistema sin la necesidad de PM.

Intel reconoció estas deficiencias y produjo un nuevo PM completamente diferente en el 386. El modelo de memoria plana simplifica el acceso a la memoria en una porción de hasta 4 GB. La CPU puede entrar y salir de PM con un par de instrucciones, por lo que no se necesitan protocolos de reinicio torpes. VM86 significa que la mayoría de las veces ni siquiera necesita salir de PM, puede ejecutar programas de DOS mientras está en PM.

Todas estas mejoras significaron que el 386 PM no solo era más funcional, sino también significativamente más compatible.

En otras palabras, lo único en común entre el modo protegido 286 y 386 es el nombre. Esta es la razón por la cual los sistemas operativos PM son típicamente 386 o más nuevos. Agregar soporte para el 286 PM sería un esfuerzo completamente independiente, con poco o ningún código que se pueda compartir con el 386 PM completamente diferente.

Por el contrario, el 386 PM funciona de la misma manera hasta la última de las CPU de 32 bits, e incluso más allá si ejecuta software de 32 bits en CPU de 64 bits.

Hay partes en el núcleo escritas en ensamblador y tendrían que reescribirse para admitir 286.

Con respecto a ELKS, en sus preguntas frecuentes indican que es un subconjunto del kernel de Linux, por lo que tal vez solo portaron las necesidades absolutas.

Creo que la verdadera respuesta a mi pregunta es esta:

Cada arquitectura de CPU principal (o revisión importante de la misma) requiere un código de soporte de ensamblaje además del código C.

Incluso si tiene GCC para compilar el kernel de Linux en el código de máquina 286 de 16 bits, todavía faltaría el código de ensamblaje compatible de 286 de 16 bits esencial.

En otras palabras, el núcleo en el mejor de los casos solo se construiría parcialmente. Cualquier código de ensamblaje específico de arquitectura no se ensamblaría, ya que simplemente no está escrito para esa arquitectura.

En base a esto, supongo que esto es exactamente lo que hacen, por ejemplo, ELKS y proyectos similares cuando implementan Linux en 286 u otras arquitecturas: implementan ese código de soporte de ensamblaje faltante.

El 80386 admite la paginación además de la segmentación de la memoria, mientras que el 286 solo admite la segmentación de la memoria. Linux depende en gran medida del soporte de paginación, es decir, usa un esquema de memoria plana que básicamente establece todos los registros de segmento en 0 y usa paginación para administrar aplicaciones. Para portar Linux al 286, el administrador de memoria fundamental necesita un rediseño completo para funcionar en modo segmentado sin paginación, lo que probablemente sea mucho trabajo.

¿Linux requiere soporte de hardware VM86?

No soy un tipo de ensamblador, pero de acuerdo con esto :

Como la implementación original de la extensión de 32 bits de la arquitectura 8086, el conjunto de instrucciones 80386, el modelo de programación y las codificaciones binarias siguen siendo el denominador común para todos los procesadores x86 de 32 bits, esto se denomina x86, IA-32 o i386 -arquitectura, dependiendo del contexto.

El 386 representa un conjunto de instrucciones ampliado del 286, así que quién sabe lo difícil que sería el puerto. Evidentemente, casi nadie se ha molestado en probarlo ... Supongo que puedes preguntarle a la gente de ELKS sobre eso.

La razón más importante es que el proyecto GNU original apuntaba a máquinas de 32 bits (como estaciones de trabajo Unix de mediados de la década de 1980) en lugar de molestarse en admitir algo más pequeño, por lo que toda la cadena de herramientas GNU no era adecuada para la generación de código de 16 bits. Portar el kernel de Linux temprano, pesado en el ensamblaje y con segmentos al 286 hubiera sido más fácil que cualquier otro objetivo de portabilidad, si GCC hubiera tenido la capacidad de producir el código 286 en modo protegido. Pero apuntar GCC al modo protegido 286 habría sido un gran proyecto para soportar un procesador obsoleto.

Recientemente, el kernel de Linux ha abandonado el 386 como una plataforma compatible y el kernel de Linux NO es compatible con los procesadores Intel 286 ... 80286 no es una CPU de 32 bits, que se requiere para arrancar.

Linux x86 no se puede transferir fácilmente al 80286 porque es un procesador de 16 bits y Linux x86 requiere un procesador de 32 bits.

Más específicamente, los registros en el 286 todavía tenían solo 16 bits de ancho. Ninguno de los registros EX estaba disponible. Además, los segmentos de memoria y las compensaciones solo tenían 16 bits de longitud. Los programas todavía tenían que tratar con código y datos cercanos / lejanos.

Esto significa que Linux / 286 necesitaría un kernel y una API de usuario radicalmente diferentes que Linux / 386. Cada archivo fuente de ensamblaje y muchos archivos fuente C tendrían que reescribirse. Sería como la diferencia entre programar para Win16 versus Win32.

En resumen, no puede simplemente decirle a GCC que compile para una CPU diferente. Cada bit de código debería reescribirse para un entorno de 16 bits.

Por lo que he leído, la forma canónica de hacer que Linux se ejecute en el 80286 sería ejecutarlo dentro de una máquina virtual. Esto es lo que hizo Fabrice Bellard aquí . Tendría que implementar la máquina virtual usted mismo o el puerto uno.