• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 722 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM355 Boot Problem - Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block

SteveG10854
Intellectual 510 points

I have a bootup problem which says:

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

I've attached and annotated the programming sequence and boot log (a couple of hundred lines).

I fitted and erased a new flash using the sfh_DM35x utility, then downloaded the U-Boot image that comes with the devkit (dvsdk_1_30_00_40/PSP_01_20_00_014/bin/dm355/u-boot-1.2.0-dm355_evm.bin). Then I've used the 'loadb' utility which is within U-Boot on the DVEVM to serially Kermit the kernel image to the DVEVM from the PC, using the image that comes with the devkit (dvsdk_1_30_00_40/PSP_01_20_00_014/bin/uImage-dm355). I used these original images so I could discount any build problems of my own images. Incidentally I also tried by own kernel build image but got the same error.

I'd be grateful of any help to get my bootup working. Many thanks.

  • 0
    TI__Mastermind 37340 points

    Steve,

    From the error above 'VFS: Unable to mount root fs on unknown-block(1,0)', this appears to be more of a file system issue than a kernel issue; where is your file system located and how are you referencing it in your bootargs?

    Also, are you doing this on your own hardware or our EVM?  If on your own hardware, can you try this on our EVM as well?

     

  • 0 in reply to Juan Gonzales
    Intellectual 510 points

    Juan, you were right, this is a file system issue. The filesys is expected by default to be in ramdisk which I think might be erased when the EVM reset button is pressed, so when I pressed it the image was gone.

    I can download the ramdisk OK and can boot up the whole system and log in. Now I need to program the file system into the flash, but the flash chip I have fitted (and which we'll use in production) is half the size of the navtive EVM chip, being only 1 gig.

    I have an SD card onto which I've put the dm355_flash_image_xxxxx.tar file, and can mount the SD using the procedure in section A.6.3 of the GSG. The GSG says to mount the nand at mtdblock3, but would this be where the upper half of the 2 gig flash would be (which I don't have)? This ties in with U-Boot's complaints about missing memory during bootup which I also have to mend.

    I guess what I need some help with is what I need to change in the U-Boot configuration and in the file system programming procedure (and anything else) in order that I can use a 1 gig flash part. Many thanks.

  • 0 in reply to SteveG10854
    TI__Mastermind 37340 points

    Steve,

    In your u-boot bootargs variabke, you define the amount of memory available to Linux OS via MEM argument (for exampel MEM=116M).  Depending on how much memory you have, this is the first thing you should change.

    Additionally, in your loadmodules.sh you define the memory range of CMEM (normally right after Linux OS defined by CMEM above); therefore, you need to alter this file and define a memory range consistent with the amount you have available.

    I believe these two steps should be all you need; there is no need to rebuild anything.

  • 0 in reply to Juan Gonzales
    Intellectual 510 points

    Juan,

    I thought MEM and CMEM set the RAM allocations, not NAND flash - or do I have the wrong end of the stick?

    I'd imaged the nand flash maps into the mtdblocks somehow, and that if I tried to untar the file system image into mtdblock3 as the GSG says, that the area of nand for mtdblock3 might not exist in the 1gig flash device. I thought I would need to adjust some other memory mappings and mtdblocks to use only flash within 1gig memory part space. If I do try untaring it into mtdblock3, I get a magic number corruption immediately next time I try to boot, which makes me think the file system wrote over the kernel because it kind of 'fell off' the end of the 1gig chip where it thought the second gig would be and began writing back to the start of the chip. So maybe there is something that maps the mtdblocks to physical nand that would need to change?

     

     

  • 0 in reply to SteveG10854
    TI__Mastermind 37340 points

    Apologies Steve, I must not have been fully awake (early morning over here) when I responded :).

    The NAND partitions are defined in the NAND Linux driver; therefore, if you are using a different size NAND part, you will need to redifine these NAND partitions by changing the Linux Driver.  This is what determines the size and memory range of the mtdblock partitions.  Once this is defined in the NAND Linux driver, you should be all set.

  • 0 in reply to Juan Gonzales
    Intellectual 510 points

    Hey no problem Juan, I was scratching my head for a second there in case I'd got some fundamentals confused.

    Redefining the partitions sounds right. I did a grep for 'nand' in the kernel source and came up with 99 files, could you let me know please which file(s) I should be changing and maybe what should be done to them? Many thanks.

  • 0 in reply to SteveG10854
    TI__Mastermind 37340 points

    Hi Steve,

    I believe this will depend on the version of the dvsdk software you are using; if I am not mistaken, this used to be defined under

       ../ti-davinci/drivers/mtd/nand/nand-davinci.c

    However, in the most recent dvsdk, I could not find it there anymore; after a little digging around, it appears that in order to support multiple TI platforms with a single driver, the NAND partitions are now defined under

       ../ti-davinci/arch/arm/mach-davinci/board-dm355-evm.c

    I hope this helps.