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

Question

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

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

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

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

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

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

Answer 1

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

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

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

---

Итак, драйвер MTD может взять часть оперативной памяти (в драйвере MTD команды make menuconfig опция "Физическая системная память") и превратить ее в блочное устройство, если вам действительно нужно читаемое / записываемое блочное устройство. Например, его можно использовать для монтирования ОЗУ видеокарты в качестве небольшого раздела подкачки. Смотрите это.

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

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