Корневая файловая система Linux на пользовательском оборудовании

Корневая файловая система Linux на пользовательском оборудовании

У меня есть специально разработанная SoC, реализованная на FPGA, на основе клона ARM-процессора, на которой я пытаюсь загрузить Linux (ядро 3.10).

Мне удалось успешно добавить поддержку моих пользовательских периферийных устройств (USART, контроллер прерываний и таймер), что позволяет мне видеть сообщения printk, отображаемые ядром, вплоть до попытки монтирования корневой файловой системы.

У меня есть 2 ГБ пользовательской энергонезависимой памяти, с произвольным доступом, чтением и записью, отображенной с адреса 0 до 0x7FFFFFFF, с которого загрузчик выполняет, и которая содержит ядро ​​и раздел файловой системы. Загрузчик копирует ядро ​​в ОЗУ (256 Мб, с 0x80000000 до 0x8FFFFFFF), а затем передает управление Linux, который дает сбой в точке: "Паника ядра - не синхронизируется: VFS: Невозможно смонтировать корневую файловую систему на неизвестном-блоке(0,0)".

Судя по моим отладочным данным и поискам в Интернете, ядро ​​не может распознать мою энергонезависимую память, поэтому не может смонтировать файловую систему.

Как мне сказать ядру, что оно должно загрузиться с этой памяти, и какой код нужно добавить в ядро? Например, можно ли заставить ядро ​​думать, что моя память — это Nand, и изменить драйверы Nand, чтобы получить к ней правильный доступ?

Заранее благодарю за любую помощь и предложения.

решение1

Я не уверен, что вы сейчас делаете для своего «раздела файловой системы». Но вы можете поместить initrd в энергонезависимое хранилище, которое выглядит/работает как ОЗУ, а затем заставить загрузчик указать Linux использовать initrd.

Большинство initrd выполняют некоторую настройку, а затем пытаются перемонтировать корневую файловую систему на блочном устройстве. В вашем случае ваш initrd будет вашей настоящей корневой файловой системой, и вам нужно будет разместить утилиты, такие как оболочки и т. д. в initrd.

При загрузке на ARM с использованием U-Boot команды загрузки по сути загружают ядро ​​и initrd с запоминающего устройства в фиксированную область оперативной памяти, а затем адрес initrd передается ядру в качестве параметра командной строки, определяющего адрес.


Ну, драйвер MTD может взять раздел RAM (в драйвере MTD есть опция "Physical System RAM" на make menuconfig) и превратить его в блочное устройство, если вам действительно нужно блочное устройство с возможностью чтения/записи. Его можно использовать для монтирования RAM видеокарты в качестве небольшого раздела подкачки, например. Видеть это.

Я думаю, что команда для этого будет modprobe phram phram=0x00100000;256MiB, если у вас файловая система размером 256 МБ в ячейке памяти 0x00100000. Тогда modprobe mtdblockчто тогда делает /dev/mtdblock0. Затем вы можете делать такие вещи, как mount /dev/mtdblock0и тому подобное. Так что вам понадобится небольшой скрипт в initrd, который делает вышеописанное, затем fsck /dev/mtdblock0, а затем запускает ваш initили какой там у вас процесс 1.

Вы даже можете указать это все в командной строке ядра, но я не уверен, поддерживается ли это. Вы можете захотеть использовать небольшой initrd в любом случае, просто для гибкости.

Связанный контент