Tengo un SoC de diseño personalizado implementado en FPGA, basado en un clon de procesador ARM, en el que estoy intentando iniciar Linux (kernel 3.10).
He agregado con éxito soporte a mis periféricos personalizados (un USART, controlador de interrupción y temporizador), permitiéndome ver los mensajes printk mostrados por el kernel hasta el punto de intentar montar el sistema de archivos raíz.
Tengo una memoria no volátil personalizada de 2 GB, acceso aleatorio, lectura y escritura, asignada desde la dirección 0 a 0x7FFFFFFF desde la cual se ejecuta el gestor de arranque y que contiene el kernel y la partición del sistema de archivos. El gestor de arranque copia el kernel en la RAM (256 Mb, de 0x80000000 a 0x8FFFFFFF) y luego pasa el control a Linux, lo que falla en el punto: "Pánico en el kernel - no se sincroniza: VFS: no se puede montar root fs en bloque desconocido (0,0) ".
Según mi depuración y búsquedas en Internet, parece que el kernel no puede reconocer mi memoria no volátil y, por lo tanto, no puede montar el sistema de archivos.
¿Cómo le digo al kernel que debe arrancar desde esa memoria y qué código se debe agregar al kernel? Por ejemplo, ¿sería posible hacer que el kernel piense que mi memoria es una Nand y modificar los controladores Nand para acceder a ella correctamente?
Gracias de antemano por toda la ayuda y sugerencias.
Respuesta1
No estoy seguro de qué está haciendo ahora con su "partición del sistema de archivos". Pero puede colocar un initrd en su almacenamiento no volátil que se ve/actúa como RAM, y luego hacer que su gestor de arranque le diga a Linux que use el initrd.
La mayoría de los initrds realizan alguna configuración y luego intentan volver a montar un sistema de archivos raíz en un dispositivo de bloque. En su caso, su initrd sería su sistema de archivos raíz real y necesitaría colocar utilidades como shells, etc. en el initrd.
Al arrancar en ARM usando U-Boot, básicamente los comandos de arranque cargan el kernel y el initrd desde un dispositivo de almacenamiento a una ubicación RAM fija, y luego la dirección del initrd se pasa al kernel como un parámetro de línea de comando, especificando la dirección.
Bueno, el controlador MTD puede tomar una sección de RAM (hay una opción de "RAM del sistema físico" en el controlador MTD make menuconfig) y convertirla en un dispositivo de bloque, si realmente necesita un dispositivo de bloque legible/escribible. Se puede utilizar para montar la RAM de la tarjeta gráfica como una pequeña partición de intercambio, por ejemplo. Mira esto.
Creo que el comando para hacerlo sería modprobe phram phram=0x00100000;256MiB, si tiene un sistema de archivos de 256 MBytes en la ubicación de memoria 0x00100000. Entonces modprobe mtdblocklo que luego hace /dev/mtdblock0. Luego puedes hacer cosas como mount /dev/mtdblock0esas. Por lo tanto, necesitaría un pequeño script en un initrd que haga lo anterior, luego fsck /dev/mtdblock0y luego inicie initsu proceso 1 o cualquiera que sea.
Es posible que incluso puedas especificar todo eso en la línea de comandos del kernel de alguna manera, pero no estoy seguro de si eso es compatible. Es posible que desee utilizar un initrd pequeño de todos modos sólo para ser flexible.