LINUX.ORG.RU

Паника ядра при загрузке на исполнении сишного файла /linuxrc на процессоре AT91RM9200

 , ,


0

1

Всем привет! Я запускаю Линукс на отладочной плате «Embest ATEB9200» с процессором Atmel/Microchip AT91RM9200 семейства ARMV4T ARM920T. Ядро Линукса успешно грузится, но затем возникает исключение при запуске файла «/linuxrc» на корневом разделе, если его собрать с использованием сишной библиотеки «glibc». Если же при сборке этого файла я убираю библиотеку «glibc», то загрузочный файл «/linuxrc» успешно работает.

Вроде бы сразу ясно, что причина возникновения исключения заключена в неверной сборке библиотеки «glibc», но я не понимаю на каких командах процессора вылетает исключение, если само ядро Линукса и библиотека «glibc» собраны одним и тем же компилятором с одними и теми же ключами сборки и ядро Линукса работает успешно.

В процессоре отсутствует аппаратный блок обработки дробных чисел, но стандартный «гентушный» кросс-компилятор собран с программной поддержкой обработки дробных чисел и в ядре я включил эмуляцию дробной арифметики тоже.

Буду рад, если подкинете мыслей куда смотреть. Моя задача это запустить файл «/linuxrc» с использованием внутри него библиотеки «glibc», чтобы следом подставить вместо него собранный «Бизибокс».

  1. Лог загрузки с возникновением исключения.

  2. Сам загрузочный файл «/linuxrc» и последовательность его сборки без библиотеки «glibc».

  3. Кросс-компилятор и его ключи.

  4. Настройка ядра Линукса.

Я поставил галочку на добавление сообщений безымянными форумчанами, однако сверху вижу надпись, что отвечать смогут лишь учтённые форумчане. Наверное, новичкам на форуме не позволено приглашать всех к обсуждению.

В процессоре отсутствует аппаратный блок обработки дробных чисел, но стандартный «гентушный» кросс-компилятор собран с программной поддержкой обработки дробных чисел и в ядре я включил эмуляцию дробной арифметики тоже.

Ядро linux не использует дробную арифметику

anonymous
()
Ответ на: комментарий от mky

Так ты тренируйся, заменяй каждое второе слово на «жопа».

Binkledum
()
Ответ на: комментарий от mky

а может у вас как здесь: https://switch-case.ru/52446406

Похоже на то, что по-умолчанию кросс-компилятор в «Генте» сам собирается и собирает все остальные библиотеки под семейство «ARMv5», а у меня процессор на плате из семейства «ARMv4». Об этом же говорит вывод команды «readelf -A linuxrc». Благодарю за наводку.

Enthusiast ★★
() автор топика
Ответ на: комментарий от Enthusiast

«Бизибокс» загрузился успешно и осталось его только поднастроить после пересборки кросс-компилятора под семейство «ARMv4» командой:

crossdev --stable --env 'EXTRA_ECONF="--with-arch=armv4t"' --target arm-softfloat-linux-gnueabi

Теперь я могу с уверенностью сказать, что обновление и работа свежей версии ядра Линукса и кросс-компилятора на устаревшей электронной аппаратуре (одноядерный 32-хразрядный процессор с частотой 180 МГц, 2 МБ параллельной флэш-памяти, 8 МБ последовательной флэш-памяти, 32 МБ ОЗУ) это вполне решаемая задача. Однако для этого мне потребовалось избавиться от загрузчика «Ю-Бута», выданного производителем аппаратуры, и написать свой загрузчик. Зачем?

  1. Собранное, свежее ядро Линукса уже не помещалось в установленную на печатной плате параллельную флэш-память размером 2 МБ.
  2. Чтобы отладить загрузку ядра из последовательной флэш-памяти мне понадобился осциллограф и пошаговый отладчик. «Ю-Бут» написан таким образом, что его исходный код не собирается в составе программно-аппаратной отладочной среды с пошаговой отладкой (синтаксис ассемблеров разнится и запускательно-настроечный код вставляется в проект по-разному).
  3. Значения переменных ядра Линукса можно передавать в самом ядре и загрузчику этим заниматься необязательно. Даже передавать тип аппаратуры в регистрах необязательно - ядро Линукса узнает его из присоединённых к нему файлов описания аппаратуры (Device Tree - dtb).

В итоге вся работа загрузчика сводится к копированию ядра Линукса из флэш-памяти в ОЗУ и последующей передачи исполнения туда в режиме сверхнаблюдателя с отключенными кэшами данных и команд у процессора.

Для себя я сделал однозначный вывод, что гораздо лучше написать свой загрузчик, чем бороться с программистами «Ю-Бута», которые могут запросто исключить из своего загрузчика устаревшую электронную аппаратуру в любой день, как это произошло для моей отладочной платы (а современными компиляторами старые сборки «Ю-Бута» тоже не собираются :-). Девяносто процентов кода «Ю-Бута» можно смело выбросить и свой загрузчик будет небольшим. Зато этот самобытный, простой загрузчик позволит непрерывно обновлять ПО даже на устаревающей электронной аппаратуре.

Enthusiast ★★
() автор топика
Ответ на: комментарий от Enthusiast

Еще один все понял. Одобряю.

Нет, ну как можно выпускать новые версии без обратной совместимости и поддержки старого? Уроды.

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

Нет, ну как можно выпускать новые версии без обратной совместимости и поддержки старого?

Я пришёл к выводу, что первопричиной исключения устаревающей электронной аппаратуры из новых сборок «Ю-Бута» является ошибка проектирования самого «Ю-Бута». Сейчас в «Ю-Буте» всё множество различных электронных устройств приводится к единому способу обработки данных. То есть создаются структуры данных, различные для каждого электронного устройства, а затем эти разнородные данные обрабатываются единообразно одними и теми функциями. Естественно, что с годами разнородность данных добавляемой электронной аппаратуры разнится всё больше и больше и приводить эти данные к единому обработчику данных становится всё сложнее. Насколько я понимаю, «юбутовцы» зарабатывают не за счёт старого электронного барахла, которое даже его производителям уже не нужно, потому как устройства уже давно наштампованы и их продажи уже идут на спад, а за счёт поддержки «Ю-Бутом» новой электронной аппаратуры, в продажах которой заинтересованы сами производители электроники.

Как надо было делать? Я бы создавал весь запуск ядра Линукса для каждого из электронных устройств в отдельном файле от настройки умножителя частоты процессора до передачи исполнения ядерному коду. В этом случае видоизменять исходный код «Ю-Бута» каждому из сторонних разработчиков стало бы в разы легче, потому как не нужно было бы протаскивать новые данные через все слои ПО как сейчас.

Если сегодня не начать привлекать к разработке «Ю-Бута» сторонних разработчиков способом Линуса Торвальдса, то чтобы выжить под тяжестью поддержки разнородной электронной аппаратуры, «юбутовцам» придётся выбрасывать старьё раз за разом. А переписать весь загрузчик заново эти старые пердуны вряд ли решатся.

Enthusiast ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.