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.

Linux/OMAP-L138: How to flash ais image with U-Boot to NAND from Linux

Part Number: OMAP-L138
Other Parts Discussed in Thread: OMAP-L132, FLASHTOOL

Tool/software: Linux

Currently I can flash the bootloader (an AIS image with U-Boot) to the NAND flash on my OMAP-L138 board using the utility "sfh_OMAP-L138.exe".

This works fine, but with disadvantages:

  1. I have to set a DIP switch for UART boot mode.
  2. This tool is a Windows prorgam.

Is there a method to update the bootloader in NAND flash (patition 1; device /dev/mtd1) directly from linux?

I've already tried with "mtd-utils"

flash_erase /dev/mtd1 0 0
nandwrite -p /dev/mtd1 <ais file>

but after that the board doesn't start after switching power off and on.

  • Can you check this:
    processors.wiki.ti.com/.../Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138

    There is a section to run the utility under linux using mono.

    Best Regards,
    Yordan
  • Hi Yordan!

    Thank you for your answer.

    I want to flash the bootloader AIS image from the linux running on the device.
    My device is a small embedded device; there is no enough space nor power to run "mono" on it!

    Currently it is posssible to erase and write the MTD partition holding the bootloader.
    But it seems that the AIS file should be prepared with an other format.
    Now I have to use "nandwrite" with the option "-p", otherwise I get an error message regarding not proper aligment.

    Best regards,
    Jan-Marc.
  • Hi Yordan!

    On my booard I'm using a the NAND flash type "MT29F4G16ABADAH4-IT:D" (data 16-bit).
    This NAND type requires a "4-bit ECC".
    This is no problem, because I can configure "U-Boot" and the Linux kernel (driver "davinci_nand") to "4-bit HW-ECC".

    My problem is:
    Writing the AIS image to the NAND with the "Serial FLASH Utility" ("sfh_OMAP-L138.exe") leads to a bootable board.
    Writing the same AIS image into the NAND with "nandwrite" from the running Linux leads to a non-bootable board.

    As far as I know the OMAP-L138 ROM bootloader (RBL) uses (only) "1-bit ECC".
    Is that correct?
    Is it possible that the problem is that "nandwrite" writes the AIS image into the NAND using "4-bit ECC", but the RBL only "understands" "1-bit ECC"?

    Is there a way to write the AIS image with "nandwrite" from the running Linux exceptionally with "1-bit ECC", although the Linux kernel is configured to "4-bit ECC"?

    Best regards,
    Jan-Marc.
  • Hi, Jan-Marc,

    Have you tried on TI EVM to see if it works with nandwrite? if it works, then it may be as you described the 1-bit/4-bit ECC difference. If not, it would be something else.

    Rex
  • Hi Rex!
    Hi Yordan!

    Unfortunately I do not have an TI OMAP-L138 LCDK board available anymore.
    But as far as I know the TI OMAP-L138 LCDK was delivered with an old Linux kernel (some V3.x) using an 1-bit ECC.
    During startup, there was always an message complaining about a too weak ECC calculation for the NAND flash.

    The topic "writing the bootloader from Linux with 'nandwrite'" is very important for us.
    For this we have to write the bootloader (AIS image) with a 4-bit ECC into the NAND flash.
    So I have to ask some questions again.

    We are using the NAND flash type "MT29F4G16ABADAH4-IT:D" with 16-bit data width.
    This type of NAND flash requires a 4-bit ECC calculation.

    What kind of ECC calculations supports the OMAP-L138 ROM Bootloader for NAND flash with 16-bit data width?
    We have studied the application report "Using the OMAP-L132/L138 Bootloader" (SPRAB41E from January 2014), but we can't find an answer for this.

    The latest release of the "Serial Boot and Flash Loading Utility" ("sfh_OMAP-L138.exe") is from the year 2012.
    What kind of ECC calculations supports the "Serial Boot and Flash Loading Utility"?

    Since 2012 there have been numerous developments for the Linux kernel NAND driver ("davinci_nand.c").
    With the Linux Kernel V4.4.x we can use a 4-bit ECC calculation successfully!

    The corresponding settings in our board file are:

    struct davinci_nand_pdata
        .options = NAND_BUSWIDTH_16,
        .ecc_mode = NAND_ECC_HW
        .ecc_bits = 4,
        .bbt_options = NAND_BBT_USE_FLASH,
       
    During probing the NAND driver ECC mode turns into "NAND_ECC_HW_OOB_FIRST".
    And during startup, there is no message about weak ECC calculation anymore!

    Is there any possibility that the "Serial Boot and Flash Loading Utility" writes the bootloader (AIS image) with 4-bit ECC?

    Thanks for your help in advance!
    Jan-Marc.

  • Jan-Marc,

    I've confirmed the Boot ROM supports 4-bit ECC.

    I believe this link, which is focused more on U-Boot will explain the problem you are running into and provide some insights for how to fix it for Linux:

    git.denx.de/

    Can you please take a look and let us know your thoughts/results?
  • Hi Ron,

    thank you for your answer and the hint!

    I followed the instructions from section "Flashing the images to NAND".
    However, the result is the same when I write the bootloader to the NAND flash from Linux; the board doesn't start up.

    I think it has to be something else.
    How does the ROM Bootloader "know" with ECC mode is being uesd for the AIS image?
    Could it be that an option for the ECC mode has to be set for the generation of the AIS image?

    And: my goal is to write the bootloader from Linux!

    Thanks for your help in advance!
    Jan-Marc.

  • Hi, Jan-Marc,

    There is a similar thread in e2e forum which is resolved. Could you see if it helps?
    e2e.ti.com/.../2482361

    Rex
  • Hi Rex!

    Thank you for your hint!

    In the thread recommended by you they are finally using "flashtool" for re-flashing the "U-Boot" partition.
    But "flashtool" is a program running under Windows!

    Our goal is still "re-flashing U-Boot partition from a Linux shell script"!
    But for this I think we had to write the U-Boot partition with 4-Bit ECC also with the "Serial Boot and Flash Loading Utility" ("sfh_OMAP-L138.exe") .

    Best regards
    Jan-Marc.

  • Hi, Jan-Marc,

    The flashtool mentioned in the thread is run from EVM. If I understand correctly, it originally was run using the following command:

    root@arago:~# ./flashtool --legacy /dev/mtd2 -w -s 0 --ubi mtd1.hex

    then modified to use the following:

    ./flashtool -w -s 0 --dm365-rbl --ubi /dev/mtd1 uboot_and_ubl.bin

    Is my understanding incorrect?

    Rex
  • Hi Rex!

    Thank you for your reply!

    It was a misunderstanding of mine.

    In the thread "re-flashing U-Boot partition from a Linux shell script" was a link to "flashtool" from TI
    (http://www.ti.com/tool/flashtool or also http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/amflashutil/latest/index_FDS.html).

    On this page you can read the following description:
    "Flash Tool is a Windows XP-based application that can be used to transfer binary images from a host PC to
    TI Sitara AM35x, AM37x, DM37x and OMAP35x target platforms.
    Transfer can be performed using USB or UART peripheral boot modes and can program internal target memories such as NAND and SDRAM."

    But there is also another web site for "flashtool": https://github.com/jonpovey/flashtool
    I think I can build the program for and run it under Linux.

    Best regards,
    Jan-Marc.

  • Hi, Jan-Marc,

    That is correct. Actually in the thread I provided, it says the flashtool was from https://github.com/jonpovey/flashtool.

    " I've been able to unlock the U-Boot partition, now when I use the tool https://github.com/jonpovey/flashtool  as suggested by mdeneen (thank you BTW!) I can write the UBL + U-Boot partition using the following command:

    root@arago:~# ./flashtool --legacy /dev/mtd2 -w -s 0 --ubi mtd1.hex "

    If you think this resolves your issue, please click "Resolved". If you have other issue, please submit a new thread. Thanks!

    Rex