• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 10666 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.

Kernel boot error message - mtdoops: mtd device ...

Ron Olson
Intellectual 680 points
Other Parts Discussed in Thread: AM3517

On an AM3517EVM, I get the message "mtdoops: mtd device (mtddev=name/number) must be supplied" during kernel boot.  I also got many hits when I googled for this message.  But, I never saw a clear explanation of its cause, or its consequence.  Looking at the source code, apparently some required info wasn't set up properly before mtdoops_init() gets called.

What's interesting is that, almost without exception in postings containing this error message, whether on TI forums or elsewhere, the message is followed by the message "omap2-nand driver initializing".  That suggests the omap2 code is doing something wrong.  In other words, this error correlates with omap2 platforms, not with X86, PPC, etc.

Can anyone out there shed light on this?

Thanks,
Ron

  • 0
    Guru 26430 points

    No experience with that platform. Some comments from inspecting some kernel code. The driver that emits that error message is expecting a mtddev parameter to be passed in when it is loaded. If the mtdoops module is built it, then the bootargs will contain some line like "mtdoops.mtddev=2". If it is a loadable module, the modprobe or insmod command will have "mtddev=2" as a parameter. That's a direct interpretation. Whether or not the mtdoops modules should loaded. That will requre knowledge of the platform. Odds are that the mtddev=? parameter gto removed from the bootargs but the driver was not removed from the kernel.

  • 0 in reply to Norman Wong
    Intellectual 680 points

    Norman,

    Thanks for the explanation.  After checking out my configuration, that sounds right, and will save me some digging time.

    Ron

  • 0 in reply to Ron Olson
    Prodigy 230 points

    I am also puzzling over this error, mostly because it is a default linux setting set in am3517_evm_defconfig. It may (or not) be connected to the failure of "flash_unlock" to unlock mtd1 or mtd2 in preparation for updating u-boot or the linux kernel from a bash prompt. 

    When using "flash_unlock /dev/mtd1", there is an open error in "MTD_open" which appears to be the fact that the flash is not setup to be writable.

    So, I guess my followon question is "How can we make the various /dev/mtd0 defined in the am3517 TI reference software be configured so that a nand flash partition can be unlocked, erased ans re-written from Linux?"

    Charles

  • 0 in reply to Charles Krinke
    Guru 26430 points

    The MTD memory partitions are usually defined your board.c file.. eg. arch/arm/mach-omap2/board-am3517evm.c. The Arago repository has several different versions of this file. Some with code like this:

    static struct mtd_partition am3517evm_nand_partitions[] = {
    /* All the partition sizes are listed in terms of NAND block size */
      {
        .name           = "xloader-nand",
        .offset         = 0,
        .size           = 4*(SZ_128K),
        .mask_flags     = MTD_WRITEABLE
      },
    ...
    };

    I vaguely remember that the mask_flags are for NOT to allow. So using MTD_WRITEABLE means NOT writeable. Probably wrong on that.

  • 0 in reply to Norman Wong
    Prodigy 230 points

    Thank you, Norman, that is the data I was looking for. I also recall the flags may be backwards, but now that I know where the definition is, I can run some tests.

    Charles

  • 0 in reply to Norman Wong
    Intellectual 320 points

     "(..) If the mtdoops module is built it, then the bootargs will contain some line like "mtdoops.mtddev=2" (...)"

    I verified that by providing the name of the NAND flash device as a boot argument. For the AM3517evm board, I added  "mtdoops.mtddev=omap2.nand" to uBoot's bootarg environment variable. That pacified the mtdoops module and removed the error message from the system log when the kernel starts up.

    Thanks!