• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 2143 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

SPI + NAND + ubifs = Kernel panic

Arend Lapere
Intellectual 810 points

Hello everyone,

I bought a beaglebone to experiment with the AM335x platform. I've created a cape with NAND and SPI. Both are working, after i've edited the mux.c file in uboot directory.

I've written MLO+uboot to SPI : works perfectly

I've written my uImage to the nand ( partition 6 ) : loads the kernel, but panics! No sweat, I didn't write the rootfs yet.

So, i've created my UBIFS, and now i have a file called ubifs.img ( I didn't use ubinize, since that tool is only to write to the raw chip, right? ). I've downloaded that in memory ( through TFTP ), and wrote it to partition 7 on my nand. Afterwards, I've changed the bootargs to "console=ttyO0,115200n8 root=ubi0:rootfs rw ubi.mtd=7,2048 rootfstype=ubifs rootwait=1".

When I now reboot, I still get a panic. The following lines from the log are interesting:

[    1.265045] UBI error: ubi_init: UBI error: cannot initialize UBI, error -19

[ 1.830902] VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0)

[ 1.838348] Please append a correct "root=" boot option; here are the available partitions:

// nothing

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

My nand is at CS0. So again, from the top:

- MLO+Uboot in SPI : works

- uImage + FS in NAND : almost there

Is there a pinmux setting in the kernel that I must change? Where can I find this mux then?

Thanks in advance,

Arend

  • 0
    Intellectual 810 points

    [UPDATE]

    So I've fixed my assumption that I didn't need ubinize. I've created the ubinized image, but still the same error remains.

    It looks as if it doesn't recognize the NAND flash ( or the UBI device for name sake ).

  • 0 in reply to Arend Lapere
    TI__Mastermind 25235 points

    Hi,

    1. What is the size of your NAND flash chip?
    2. What is the size of the last partition (number 7) that is used for the file system?
    3. What is the command sequence you use to create the ubi.img file?
    4. Please post the whole kernel boot log (in an attachment). Is the following error message present?

    UBI error: vtbl_check: volume table check failed: record 0, error 9

    Here you can find exact steps to create an UBI file system depending on the size of the partition: http://processors.wiki.ti.com/index.php/UBIFS_Support

    Best regards,
    Miroslav

  • 0 in reply to Miroslav Kiradzhiyski XID
    Intellectual 810 points

    Thank you for your help!



    1. What is the size of your NAND flash chip?

        It's a 4Gb nand flash from samsung : K9F4G08U0D

    2. What is the size of the last partition (number 7) that is used for the file system?

       The actual size is: 39.5 MB ( this is the folder containing all the files in the rootfs, so not compiled )

       The UBIFS-file is: 26.0 MB ( 27299840 bytes )

       The ubinized files is: 27.1 MB (28442624 bytes)

    [code]U-Boot# mtdpart

    device nand0 <omap2-nand.0>, # parts = 8
    #: name size offset mask_flags
    0: SPL 0x00020000 0x00000000 0
    1: SPL.backup1 0x00020000 0x00020000 0
    2: SPL.backup2 0x00020000 0x00040000 0
    3: SPL.backup3 0x00020000 0x00060000 0
    4: u-boot 0x001e0000 0x00080000 0
    5: u-boot-env 0x00020000 0x00260000 0
    6: kernel 0x00500000 0x00280000 0
    7: rootfs 0x1f880000 0x00780000 0

    active partition: nand0,0 - (SPL) 0x00020000 @ 0x00000000

    defaults:
    mtdids : nand0=omap2-nand.0
    mtdparts: mtdparts=omap2-nand.0:128k(SPL),128k(SPL.backup1),128k(SPL.backup2),128k(SPL.backup3),1920k(u-boot),128k(u-boot-env),5m(kernel),-(rootfs)[/code]


    3. What is the command sequence you use to create the ubi.img file?

    sudo mkfs.ubifs -r beaglebone/ -F -o ubifs.img -m 2048 -e 126976 -c 1580

    where beaglebone is the folder containing the rootfs

    sudo ubinize -o ubi.img -m 2048 -p 128KiB -s 512 -O 2048 ubinize.cfg

    the ubinize.cfg

    [code]

    [RFS-volume]
    mode=ubi
    image=ubifs.img
    vol_id=0
    vol_size=192MiB
    vol_type=dynamic
    vol_name=rootfs
    vol_flags=autoresize[/code]

    Then I used the following commands from uBoot:

    U-Boot# tftp ubi.img

    U-boot# nand erase 0x00780000 0x1b20000

    U-boot# nand write 0x80200000 0x00780000 0x1b20000


    4. Please post the whole kernel boot log (in an attachment). Is the following error message present?

    5277.loguBOOT.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    CCCCCC
    U-Boot SPL 2013.01.01 (Jul 01 2013 - 11:41:46)
    No AC power, disabling frequency switch
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Peripheral mode controller at 47401000 using PIO, IRQ 0
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Host mode controller at 47401800 using PIO, IRQ 0
    SF: Detected M25P32 with page size 64 KiB, total 4 MiB
    U-Boot 2013.01.01 (Jul 01 2013 - 11:41:46)
    I2C: ready
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    UBI error: vtbl_check: volume table check failed: record 0, error 9

    no :-(

     

    Thank you!

  • 0 in reply to Arend Lapere
    Intellectual 810 points

    When I measure on the CS0 pin ( the one connected to the NAND ), I see that the pin is being pulled low ( at a high frequency ) while the kernel is being loaded.

    However, after the kernel is loaded, there is no interaction while booting... so the nand can never be detected this way.... right?

  • 0 in reply to Arend Lapere
    TI__Mastermind 25235 points

    Hi,

    [    1.265045] UBI error: ubi_init: UBI error: cannot initialize UBI, error -19

    error -19 means NO SUCH DEVICE.

    For some reason the ubi_init() function inside drivers/mtd/ubi/build.c file cannot find the device. I cannot see any of the other error messages, so you will need to put some debug prints inside this function in order to check where exactly is the initialization failing with error -ENODEV (-19).

    The other strange thing about your log is that there are no messages about the detection of the NAND device and the creation of the MTD partitions. Please check the function nand_get_flash_type() inside drivers/mtd/nand/nand_base.c and see if it actually detects the NAND device - there is a print statement at the end of the function: "NAND device: Manufacturer ID:................", which isn't printed out.

    There is also a static struct mtd_partition am335x_spi_partitions[] inside the board-am335xevm.c board config file. Have you done any modifications to this structure? I suppose not, but still, it is good to know as it is needed for the partitioning of the NAND device.

    Please try to provide answers to these questions in order to narrow down the possible reasons for the problem.

    Best regards,
    Miroslav

  • 0 in reply to Miroslav Kiradzhiyski XID
    Intellectual 810 points

    Hello again,

    Many thanks so far! I've added some debug output, and I can determine that the function 'nand_get_flash_type' never gets called at all!:s

    The function that makes UBI init fail is: 'open_mtd_device', but makes sense, since the NAND isn't even found ;-)

    But I think the nand isn't even found, because it is never selected? ( CSN0/GPIO1_29 - pin V6 )... so maybe I must provide pin mux info to the kernel as well? In the code i've found the following struct:

    static struct pinmux_config nand_pin_mux[] = {
    {"gpmc_ad0.gpmc_ad0", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_ad1.gpmc_ad1", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_ad2.gpmc_ad2", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_ad3.gpmc_ad3", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_ad4.gpmc_ad4", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_ad5.gpmc_ad5", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_ad6.gpmc_ad6", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_ad7.gpmc_ad7", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_wait0.gpmc_wait0", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_wpn.gpmc_wpn", OMAP_MUX_MODE7 | AM33XX_PIN_INPUT_PULLUP},
    {"gpmc_csn0.gpmc_csn0", OMAP_MUX_MODE0 | AM33XX_PULL_DISA},
    {"gpmc_advn_ale.gpmc_advn_ale", OMAP_MUX_MODE0 | AM33XX_PULL_DISA},
    {"gpmc_oen_ren.gpmc_oen_ren", OMAP_MUX_MODE0 | AM33XX_PULL_DISA},
    {"gpmc_wen.gpmc_wen", OMAP_MUX_MODE0 | AM33XX_PULL_DISA},
    {"gpmc_ben0_cle.gpmc_ben0_cle", OMAP_MUX_MODE0 | AM33XX_PULL_DISA},
    {NULL, 0},
    };

    I've also placed an debug-output in evm_nand_init, which is also not called... I think we're getting close here?

    I didn't change the struct you mentioned... actually I didn't change anything in the kernel code ( except for the extra logs ). I rechecked the configuration, and I didn't see anything suspicious.

    I don't know why u-boot can detect the size, but not the manufacturer...  i checked all the lines connected to the nand... But then again, if the NAND doens't work... I wouldn't be able to boot the uImage from it...right?

  • 0 in reply to Arend Lapere
    Intellectual 810 points

    Yeay, I found it!!

    I will paste the solution for others, it's quite easy once you know where to look!

    look up the beaglebone_dev_cfg ( for rev >=A3 ) or beaglebone_old_dev_cfg ( for rev < A3 ), there you muse add and entry:

    {evm_nand_init, DEV_ON_BASEBOARD, PROFILE_ALL},

    and that's all! Recompile the uImage and you're done!

    Thank you again for all your help