Error using initramfs on DM365 - "Cannot open root device"

Bryan Evenson said:

I received the above error with these bootargs:

setenv bootargs console=ttyS0,115200n8 ip=171.0.0.130 mem=60M video=davincifb:vid0=OFF:vid1=OFF:osd0=720x480x16,4050K dm365_imp.oper_mode=0 vpfe_capture.interface=1 vpfe_capture.bufsize=691200 davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=ntsc

I have tried adding a root= variable to the bootargs for each of the blocks listed above (for example, root=/dev/mtdblock1 rw) but the kernel is still not able to mount the filesystem.  Is there a step I am missing so that the kernel can mount the filesystem?

You will need some sort of root= value in your bootargs to tell the kernel where to look for the filesystem, so your current error is related to missing that value so it tries to open NULL. Usually if you are setting something like 'root=/dev/mtdblock3 rw rootfstype=yaffs2' you would be using a flash based filesystem like yaffs or jffs.

For a RAM disk the setup is a bit different, you would have something like 'root=/dev/ram0 rw initrd=0x81600000,16M ramdisk_size=16384', where the ram disk image is loaded to 0x81600000. For a boot like this you would have U-Boot load the RAM disk image to the DDR location specified from NAND before going into the full boot. There are some procedures on the wiki that discuss this, in particular for RAM disks http://processors.wiki.ti.com/index.php/Creating_a_Root_File_System_for_Linux_on_OMAP35x#Creating_and_Booting_a_RAMDISK may be useful, though it is targeted at OMAP3, the premise is the same on a DM365.

I tried you suggestions, and it didn't work for my setup.  After some more searching I discovered that there was no init in the filesystem main directory.  I added an init softlink to /sbin/init (ln -s /sbin/init init), and now the kernel finds the filesystem and completes booting.

Now I'm having an issue in which my kernel modules are not loading properly.  When a kernel module loads, I get an error like the following: "cmem: disagrees about version of symbol module_layout".  And then when I go to run my application, I get the following error:  "insmod: error inserting 'cmem.ko': -1 Invalid module format".  I only get the insmod error if I'm running an initramfs; if I use an NFS insmod works just fine.

From my understanding these errors can occur when the module and the kernel are built with different configuration options.  However, I believe I'm rebuilding both the kernel and the modules whenever I have changed my kernel configuration.  Any tips on where to look to fix the error?

EDIT:  I saw some more detail on what the error is that is printing when I try to install modules.  The full error message I am getting is:

cmemk: relocation out of range, section 2 reloc 13 sym 'seq_open'
insmod: error inserting 'cmemk.ko': -1 Invalid module format

So there's something causing a relocation error when I try to load the module, although I don't know why this would only occur when I have a RAM filesystem and not when I'm using NFS.

Bryan Evenson said:

When a kernel module loads, I get an error like the following: "cmem: disagrees about version of symbol module_layout".  And then when I go to run my application, I get the following error:  "insmod: error inserting 'cmem.ko': -1 Invalid module format".  I only get the insmod error if I'm running an initramfs; if I use an NFS insmod works just fine.

These errors almost always mean that your kernel module version differs from your kernel version, in general if you rebuilt your kernel you need to rebuild your kernel modules as well so they match. If this works with NFS but not with initramfs than I would be suspect that your cmemk.ko files in each filesystem are not the same, or that the kernel uImage file you are booting in each instance is not the same.

Bryan Evenson said:

cmemk: relocation out of range, section 2 reloc 13 sym 'seq_open'
insmod: error inserting 'cmemk.ko': -1 Invalid module format

So there's something causing a relocation error when I try to load the module, although I don't know why this would only occur when I have a RAM filesystem and not when I'm using NFS.

This relocation out of range error is not something I have come across before, I would still double check the uImage and cmemk.ko files to ensure they are the same with each file system, as if you are still getting the 'disagrees about version of symbol module...' message there is a mismatch.

Aside from verifying the kernel and modules match in this case I would also check how you are inserting the cmemk.ko file, which is typically done with the loadmodules.sh script, it should have an address and a list of cmem buffer sizes on the command that inserts cmemk.ko. You would want to verify that the address and lengths used here make sense and still fit into your memory map with the RAM disk, if the cmem buffers conflict with another Linux construct you can get errors.

I had modified the main DVSDK makefile to include a few more things for my additions, and I found an error that I had introduced which was causing the "disagrees about version of symbol module_layout" error.  Now when I use NFS I don't see any errors associated with the kernel modules.  However, I am still seeing the "relocation out of range" error on any kernel module I try to install while using initramfs.  The kernel is configured to use 32 MB of space, which would be from 0x80008000 to 0x82008000.  The uncompressed initramfs image appears to be around 21.5 MB, which should leave about 10 MB of space to load kernel modules.  The cmemk.ko module is using the range 0x83C000000 to 0x88000000, so it shouldn't be interfering with the kernel.

When using initramfs, the filesystem is running /sbin/init for it's init with no changes from what is used when it is an NFS.  Is there something i need to do different to initialize the kernel modules (or to initialize the ability to use kernel modules) when using initramfs?

It looks like this is getting beyond something that is specific to TI, and more generic to Linux in general, so I did some searching on this and found a thread on another forum that discusses this issue in some detail (http://help.lockergnome.com/linux/ARM-relocation-range-loading-module--ftopict530945.html). It seems like the recommendation there was to use an initrd image instead of initramfs.