Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

rblode said:

IP-Config: No network devices available.
Looking up port of RPC 100003/2 on 192.168.1.66
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.1.66
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /home/me/workdir/filesys
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

This is a bit unusual, it sounds like your kernel is not configured to use the network interface on the EVM somehow, you mention that you are working with the IPNC software, my suspicion is that the kernel for the IPNC reference design uses a different Ethernet driver than the EVM, and that this is preventing you from booting the same kernel properly on the EVM. Note that I do not have the IPNC reference design so I am not all that familiar with how it differs from the EVM, but the errors you have indicate the network is not coming up for some reason, and I would blame the kernel specifically since the same hardware is working earlier from U-Boot.

To try to fix this you may want to try booting a pre built kernel that is included with the DVSDK, or try building the kernel again with the DVSDK getting started guide instructions.

EDIT: I think I misunderstood your question and got things reversed, reading your first few words I was under the impression you were working with the EVM trying to run IPNC software, but it seems you are doing the reverse by using the IPNC kit and running EVM software. It should be possible to use the same tools to build for the IPNC, however you probably need to change some kernel build options to include whatever hardware support is needed for the IPNC, in this case it looks like the network driver is broken/missing.

Just a precision:

The commands are to be typed on the server Linux PC, in a new terminal window (not the serial console). I was not clear.

And connect as root on this terminal.

Bernie Thompson said:

EDIT: I think I misunderstood your question and got things reversed, reading your first few words I was under the impression you were working with the EVM trying to run IPNC software, but it seems you are doing the reverse by using the IPNC kit and running EVM software. It should be possible to use the same tools to build for the IPNC, however you probably need to change some kernel build options to include whatever hardware support is needed for the IPNC, in this case it looks like the network driver is broken/missing.

Thank you for the reply

Yes i'm working with the EVM DM365 and now i try to use the same environement for the IPNCDM355-VCA1 , the question which build options i must change it ?.

Thank you for the reply

reda38 said:

Yes it looks strange that you have this at booting the kernel :

 

dm9000 Ethernet Driver
dm9000: read wrong id 0x2b2a2928
dm9000: read wrong id 0x2b2a2928
dm9000: wrong id: 0x2b2a2928
dm9000: not found (0).

Yes i see this but i select dm9000 Ethernet Driver when i builded the kernel , i followed the getting start with the default value of configuratio

reda38 said:

1-it looks like your ethernet link is down.

try to locate this message on a working configuration. If it is the same message the error is elsewhere (in such situation the drive loading messages would be weird).

but it is strange because your uboot used tftp through the DM9000 ethernet device. so my 2nd suggestion

 

I agree with you because on Uboot I can ping without problem which show that the driver works well and even ftp it works also

reda38 said:

2- my other suggestion is that if you read before your kernel panic, you notice that the transaction is closed because your platform ask your server to open the nfsd port and could not get the port (rpc).

First ensure that your server PC has the right IP address, sometimes it changes at reboot if you use dhcp.

Second, try to type the commands below when connecting in a console being "root" (as user you will not be able to type them)

/sbin/service iptables stop (it will stop the firewall)

Yes I thought about that but I have no problem with the DM365 EVM card, although I get to mount the filesys no problem with the same host platforme

reda38 said:

3- Of course the kernel that you have may be not configured for NFS, in this case you will have to recompile it with the right options and reflash it, and restart. but this is another story. Try the first 2 points before.

I used the default configuration following the getting start guide

rblode said:

Yes i'm working with the EVM DM365 and now i try to use the same environement for the IPNCDM355-VCA1 , the question which build options i must change it ?.

Unfortunately I do not have an IPNC kit so I have not really worked with it much and could not say what options would have to be changed. Though the build tools can probably be the same you may have to do some additional patch work to get the kernel that came with the EVM to run on the IPNC kit, I am not sure that it would include all the code needed for the IPNC in the kernel (primarily drivers for any hardware differences, in this case the Ethernet). In other words, I am not sure what Appro had to modify in the kernel to get the IPNC to work, whatever they had to do,  you would have to do as well.

What kernel version are you running on the IPNC? If it is a close enough version to the one you were running on the EVM than I would probably just try to stick with it and port the rest of your higher level software stack instead. If the kernel versions are different than porting around the driver code is a possibility to make the EVM kernel run on the IPNC kit however that could prove to be a lot of work.

Bernie Thompson said:

What kernel version are you running on the IPNC? If it is a close enough version to the one you were running on the EVM than I would probably just try to stick with it and port the rest of your higher level software stack instead. If the kernel versions are different than porting around the driver code is a possibility to make the EVM kernel run on the IPNC kit however that could prove to be a lot of work.

the default version of IPNC is Linux kernel version: 2.6.10_mvl401 , i tried to run my sample code directly in this version but i have  "segmentation falut" error

if it's not possible to use my environement of dm365  you know where i cn find the toolchaine for this version of kernel.

Thank you

thank you Juan for this informations , now i see the the difference

Hello

There is still a strange point in your question. Let me explain :

You said this :

"[...] EVM board dm365 with linux-2.6.18_pro500 and  arm_v5t_le- compiler  and now i have the DM355IPNC-VCA1 [...]"

I think the main source of your problem comes from the different target you have :

EVM365 is base on DM365, this chip includes an Ethernet MAC.

DM355IPNC-VCA1 is based on DM355, this chip does not include an Ethernet MAC but instead uses the Davicom DM9000 Ethernet MAC+PHY

The thing that happens is that if you put the kernel forecast for DM355 on a platform for DM365 you will get problems. There are probably other peripherals which will cause problems.

So when loading your DM355 kernel configured to use DM9000 on the EVM365, there will be the message you got.

What you need in my opinion is either you get EVM355, or you get DM365IPNC-VCA1 which i do not know if it exists.

Just my 2 cents contribution.

reda38 said:

"[...] EVM board dm365 with linux-2.6.18_pro500 and  arm_v5t_le- compiler  and now i have the DM355IPNC-VCA1 [...]"

I used EVM board dm365 in the first and now i try to use DM355IPNC-VCA1

reda38 said:

The thing that happens is that if you put the kernel forecast for DM355 on a platform for DM365 you will get problems. There are probably other peripherals which will cause problems.

i put the kernel forecast for EVM-DM355 on a platform DM355IPNC-VCA1

This is a great catch by reda38.  All DM365 DVSDKs have been based on MV Pro 5 thus far; whereas, DM355 DVSDKs have been based on MV Pro 4 (dvsdk 1.30) or MV Pro 5 (dvsdk 2.0).  Aside from this, there are fundametal differences in the parts, hence using a DM365 kernel on DM355 will likely reduce further any chance of your IPNC system working.

Did you know there is a DM365-based IPNC available

http://www.appropho.com/NewWeb/Product_DM365IMX035_Product.php

If you decide to stick with DM355 IPNC, then perhaps a closer match would be the DVSDK 1.3 for DM355 available at

http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/dvsdk/mv_dvsdk/index.html

The kernel included in this DVSDK is at least based on the same tool chain (MV Pro 4) and developed for the same platform (DM355); though this does not guarantee it will work, you would still need to accoung for any hardware differences between the DM355 EVM and the DM355 IPNC.  That said, is there a good reason you do not want to use the kernel provided with the DM355-IPNC?

Juan Gonzales said:

http://www.appropho.com/NewWeb/Product_DM365IMX035_Product.php

If you decide to stick with DM355 IPNC, then perhaps a closer match would be the DVSDK 1.3 for DM355 available at

http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/dvsdk/mv_dvsdk/index.html

Thank you Juan for the link

Juan Gonzales said:

The kernel included in this DVSDK is at least based on the same tool chain (MV Pro 4) and developed for the same platform (DM355); though this does not guarantee it will work, you would still need to accoung for any hardware differences between the DM355 EVM and the DM355 IPNC.  That said, is there a good reason you do not want to use the kernel provided with the DM355-IPNC?

I want to use the kernel Pro 5 because i  can use my program that i do with the evm-dm365

well, from you previous comments above, it appears DM355 IPNC software you are using is based on MV Pro 4.0; therefore, if you move to an MV Pro 5 kernel, you would need to update more than just the kernel, you would also need to upgarde the file system.  In this case, I would contact the third party that you bough DM355 IPNC from and see if they have a newer MV Pro 5 -based Linux stack.

Worst case, scenerio you can try porting DVSDK 2.0 to IPNC enviroment but this will likely result in challenges such as the one you are running into.  Hence it may be worth your time to figure out if Appro or whoever you bought the IPNC from has already done this.

hi bernie

well my kernel is working for bootm command but

whenever i m going for tftp boot the following things are coming

BOOTP broadcast 1                                                                                                                                                                                                                                           
DHCP client bound to address 192.168.72.135                                                                                                                                                                                                                 
TFTP from server 192.168.72.136; our IP address is 192.168.72.135                                                                                                                                                                                           
Filename 'uImage'.                                                                                                                                                                                                                                          
Load address: 0x80700000                                                                                                                                                                                                                                    
Loading: T T T T T T T T T T T T T T T T T T T T                                                                                                                                                                                                            
Retry count exceeded; starting again                                                                                                                                                                                                                        
BOOTP broadcast 1                                                                                                                                                                                                                                           
DHCP client bound to address 192.168.72.135                                                                                                                                                                                                                 
TFTP from server 192.168.72.136; our IP address is 192.168.72.135                                                                                                                                                                                           
Filename 'uImage'.                                                                                                                                                                                                                                          
Load address: 0x80700000                                                                                                                                                                                                                                    
Loading: T T...........
continue like that

well tftp is set same as given in GSG and it is set to

i m not able to short out the problem

thanks

vs

vigneshwaran sekar said:

TFTP from server 192.168.72.136; our IP address is 192.168.72.135                                                                                                                                                                                           
Filename 'uImage'.                                                                                                                                                                                                                                          
Load address: 0x80700000                                                                                                                                                                                                                                    
Loading: T T T T T T T T T T T T T T T T T T T T                                                                                                                                                                                                            
Retry count exceeded; starting again   

The Ts you see indicate timeout events, as in U-Boot sent a request to the TFTP server and did not hear back, this sort of issue is mentioned in many other threads on the forums as well. This could be caused by a few different things, such as the TFTP server not running, having the wrong server address, or having a firewall on the server preventing the TFTP server from operating. I would probably start by ensuring you can ping the server properly.