Linux на 286?

Я не владею 286, и я не намерен запускать Linux на одном. Однако, поскольку 286 имеет защищенный режим, почему часто говорят, что Linux требует процессора 386 или выше?

Из http://tuxmobil.org/286_mobile.html кажется, что версия Linux ELKS может работать на 286, верно ли это? Какие (если есть) изменения были внесены, чтобы позволить ядру работать на процессоре 286?

  • Как установить логический том?
  • Linux, SVN и Dropbox. В какой каталог должен храниться мой репозиторий svn?
  • Как настроить Frame Relay в Unix / Linux?
  • Зачем назначать MAC и IP-адреса на интерфейсе Bridge
  • Как связать типы файлов на хосте Linux с приложениями Windows через VirtualBox?
  • Отвязывать файлы в / dev / shm, не освобождая память?
  • Теперь, очевидно, я понимаю, что ядро, скомпилированное для 386, не может быть выполнено на процессоре 286, который является 16-разрядным. Поэтому мой вопрос: почему нельзя стандартное ядро ​​Linux скомпилировано для 286, а затем выполнено на 286? Требует ли Linux аппаратной поддержки VM86?

  • Linux - проверьте статистику IPC
  • Сенсорная панель не обнаружена
  • Как отключить графическую оболочку?
  • Более быстрый способ рекурсивно изменить владельца / группу?
  • скрипт bash с выражением case не возвращает результат
  • Ошибка py3compile - Невозможно получить кодировку локали
  • 9 Solutions collect form web for “Linux на 286?”

    В ядре записаны части, которые должны быть переписаны для поддержки 286.

    Что касается ELKS, то в своих FAQ они указывают, что это подмножество ядра Linux, поэтому, возможно, они портировали только абсолютные потребности.

    Я думаю, что реальный ответ на мой вопрос таков:

    Каждая крупная архитектура ЦП (или ее основная модификация) требует некоторого кода поддержки сборки в дополнение к коду C.

    Даже если вы получили GCC для компиляции ядра Linux в 16-разрядный машинный код 286, все равно будет отсутствовать необходимый 16-разрядный 286-совместимый ассемблерный код.

    Другими словами, ядро ​​в лучшем случае будет только частично построено. Любой код сборки, специфичный для архитектуры, не сможет собраться, поскольку он просто не написан для этой архитектуры.

    Исходя из этого, я предполагаю, что это именно то, что, например, ELKS и подобные проекты, когда реализуют Linux на 286 или других архитектурах – они реализуют этот недостающий код поддержки сборки.

    80386 поддерживает пейджинг в дополнение к сегментации памяти, в то время как 286 поддерживает только сегментацию памяти. Linux сильно зависит от поддержки поискового вызова, т. Е. Использует схему плоской памяти, которая в основном устанавливает все регистры сегментов в 0 и использует подкачку для управления приложениями. Чтобы перенести Linux на 286, основному менеджеру памяти нужен полный редизайн для работы в сегментированном режиме без пейджинга, что, вероятно, очень много.

    Требует ли Linux аппаратной поддержки VM86?

    Я не парень сборки, но в соответствии с этим :

    В качестве первоначальной реализации 32-разрядного расширения архитектуры 8086 набор инструкций 80386, модель программирования и двоичные кодировки по-прежнему являются общим знаменателем для всех 32-разрядных процессоров x86, это называется x86, IA-32 или i386 -архитектура, в зависимости от контекста.

    386 представляет собой расширенный набор команд из 286, поэтому они знают, насколько жестким будет порт. Очевидно, что почти никто не потрудился попробовать … Думаю, вы можете спросить об этом людей ELKS.

    Самая большая причина заключается в том, что оригинальный проект GNU нацелился на 32-битные машины (например, рабочие столы Unix в середине 1980-х годов), а не на то, чтобы поддерживать что-либо меньшее, поэтому вся GNU toolchain была непригодна для генерации 16-битного кода. Перенос раннего, сборного, сегментного ядра Linux на 286 был бы проще, чем любая другая цель портирования – если бы GCC имел возможность создавать 286 защищенных режимов. Но нацеливание GCC на защищенный режим 286 было бы огромным проектом для поддержки устаревшего процессора.

    286 защищенный режим (PM) принципиально отличается от того, что предлагает 386. Подумайте о 286 PM в качестве прототипа, в котором было так много недостатков, что почти никто никогда не использовал его, и все это было полностью переработано с нуля для 386.

    Он не использовал модель с плоской памятью, она использовала сегментированную модель, такую ​​как реальный режим, что означало, что вам приходилось перепрыгивать через обручи для доступа к памяти в блоках размером более 64 КБ за раз.

    Это было полностью несовместимо со всеми программами (MS-DOS), доступными в то время, поэтому, как только вы были в ПМ, вы не могли использовать ни одну из программ, к которым вы привыкли.

    Вы также не могли оставить защищенный режим еще раз, если вы не перезагрузили ПК, поэтому производители придумали креативные решения, такие как установка флага в ОЗУ, а затем написание магического значения для контроллера клавиатуры, который бы щелкнул вывод сброса на CPU, чтобы перезагрузить машина. Первое, что сделал бы BIOS, это обнаружить ранее установленный флаг, где он затем будет возвращаться к исходной программе вместо запуска процедуры POST, позволяя исходной программе продолжать работу с «выходным» PM.

    Это означало, что использование 286 PM не позволяло вам запускать обычные программы DOS без большого количества трюков. В то время, когда были только программы DOS, это не стоило усилий, чтобы использовать PM вообще.

    Таким образом, было сложнее работать с 286 PM, чем просто жить без него, и полагаться на EMS и XMS для доступа к дополнительной памяти. В число 286 материнских плат была включена поддержка чипсета для EMS, чтобы вы могли использовать всю дополнительную системную память без необходимости в PM.

    Intel признала эти недостатки и выпустила совершенно новый PM в 386 году. Модель плоской памяти обеспечивает доступ к памяти в куске объемом до 4 ГБ. CPU может входить и выходить из PM с помощью нескольких инструкций, поэтому не требуется никаких неуклюжих протоколов перезагрузки. VM86 означает, что большую часть времени, когда вам даже не нужно выходить из PM, вы можете запускать программы DOS в то время как в PM.

    Все эти улучшения означали, что 386 PM были не только более функциональными, но и значительно более совместимыми.

    Другими словами, единственное, что существует между защищенным режимом 286 и 386, – это имя. Вот почему операционные системы PM обычно 386 или новее. Добавление поддержки для 286 PM было бы полностью независимым, с небольшим или отсутствующим кодом, который мог бы использоваться совместно с совершенно разными 386 PM.

    В отличие от этого, 386 PM работает примерно так же вплоть до последнего из 32-разрядных процессоров и даже за его пределами, если вы запускаете 32-разрядное программное обеспечение на 64-битных процессорах.

    Недавно ядро ​​Linux отказалось от 386 в качестве поддерживаемой платформы, а ядро ​​Linux НЕ поддерживает процессоры Intel 286..80286 – это не 32-битный процессор, который требуется для загрузки.

    Linux x86 не может быть легко перенесен на 80286, поскольку это 16-разрядный процессор, а для Linux x86 требуется 32-разрядный процессор.

    Более конкретно, регистры на 286 были по-прежнему только в 16 бит. Ни один из регистров EX не был доступен. Кроме того, сегменты и смещения памяти по-прежнему были только 16-битными. Программам все еще приходилось иметь дело с кодами и данными ближнего / дальнего действия.

    Это означает, что Linux / 286 потребует радикально отличающегося ядра и пользовательского API, чем Linux / 386. Каждый исходный файл сборки и многие исходные файлы C должны быть переписаны. Это будет похоже на разницу между программированием для Win16 и Win32.

    Короче говоря, вы не можете просто указать GCC для компиляции для другого процессора. Каждый бит кода нужно будет переписать для 16-разрядной среды.

    Из того, что я читал, канонический способ заставить Linux работать на 80286 – это запустить его внутри виртуальной машины. Это то, что сделал здесь Фабрицио Беллард. Вам придется реализовать виртуальную машину самостоятельно или портировать.

    Linux и Unix - лучшая ОС в мире.