• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 101 subscribers
  • Views 1016 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.

AM1808 - Cannot set SFH flash block number

Filosofi
Intellectual 925 points
Other Parts Discussed in Thread: OMAP-L138, AM1808

Hi,

My issue is how to set the block number of the NAND flash where the SFH program (v2.40) should store u-boot.bin.

My NAND partitioning is

 #: name                      size                  offset               mask_flags

  •  0: u-boot_env             0x00020000    0x00000000    0
  •  1: ubl                          0x00020000    0x00020000    0
  •  2: spare                      0x00040000    0x00040000    0
  •  3: u-boot                     0x00080000    0x00080000    0
  •  4: kernel                     0x00700000    0x00100000    0
  •  5: rootfs                      0x0f800000     0x00800000    0
  •  6: archive                   0x10000000    0x10000000    0

Then I guess that 4 is the correct block number to use (offsets from 80000 to 100000) 

Running the SFH command

    sfh_OMAP-L138.exe -flash ubl_AM1808_NAND.bin u-boot.bin -targetType AM1808 -flashType NAND -p COM1 -baud 115200 -v -appFlashBlock 4

the u-boot.bin is actually stored at block 6 (look at the attachment)

Can anybody help ? Is it a bug of the SFH tool ?

Gabriele

  • 0
    TI__Guru** 116100 points
    Hi,

    Have you tried to flash from block no 2 "-appFlashBlock 2" ?

    And then do hex dump and see.

    sfh_OMAP-L138.exe -flash ubl_AM1808_NAND.bin u-boot.bin -targetType AM1808 -flashType NAND -p COM1 -baud 115200 -v -appFlashBlock 2


    sfh_OMAP-L138.exe -flash ubl_AM1808_NAND.bin u-boot.bin -targetType AM1808 -flashType NAND -p COM1 -baud 115200 -v -appFlashBlock 4

    the u-boot.bin is actually stored at block 6 (look at the attachment)


    I presume that flash block no is 2 for UBL, UBL takes 4th block,spare location takes 5th block, and uboot would be at 6th block

    We have to do some experiment, and need to confirm.

    BTW, I don't see any attachment.
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 925 points

    Hi Titus.

    The result is exactly the same using 2 as parameter.

    The UBL has been copied into block 1 (just matching my mtd1, "ubl") while the u-boot.bin has been copied into blocks 6,7,8,9. This partially corrupted my "kernel" partition mtd4 starting from block 8.

    I have looked at the SFH source code. The relevant function is LOCAL_NANDWriteHeaderAndData() defined in sfh/sft/src/uartboot.c.

    It is the DEVICE_NAND_UBL_SEARCH_START_BLOCK constant (6) which defines the minimum allowed block number.

    So, instead of re-compiling SFH, I have decided to redefine the u-boot and kernel partitions in order to match the SFH behavior.

    Now I need to figure out what kind of processing SFH performs over u-boot.bin input file. I need this in order to replicate it in our image file building chain.

    Do you think you can help me on this ?

    Gabriele

    ******

    >sfh_OMAP-L138.exe -flash ubl_AM1808_NAND.bin u-boot.bin -targetType AM1808 -flashType NAND -p COM1 -baud 115200 -v -appFlashBlock 2
    -----------------------------------------------------
    TI Serial Flasher Host Program for OMAP-L138
    (C) 2012, Texas Instruments, Inc.
    Ver. 1.67
    -----------------------------------------------------

    [TYPE] UBL and application image
    [UBL] ubl_AM1808_NAND.bin
    [APP IMAGE] u-boot.bin
    [TARGET] AM1808
    [DEVICE] NAND
    [NAND Block] 2

    Attempting to connect to device COM1...
    Press any key to end this program at any time.

    (AIS Parse): Read magic word 0x41504954.
    (AIS Parse): Waiting for BOOTME... (power on or reset target now)
    (AIS Parse): BOOTME received!
    (AIS Parse): Performing Start-Word Sync...
    (AIS Parse): Performing Ping Opcode Sync...
    (AIS Parse): Processing command 0: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 14376-Byte section to address 0x80000000.
    (AIS Parse): Processing command 1: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 1316-Byte section to address 0x80003828.
    (AIS Parse): Processing command 2: 0x58535906.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Performing jump and close...
    (AIS Parse): AIS complete. Jump to address 0x80000000.
    (AIS Parse): Waiting for DONE...
    (AIS Parse): Boot completed successfully.

    Waiting for SFT on the OMAP-L138...
    Target: BOOTUBL
    Target: DONE

    Flashing UBL ubl_AM1808_NAND.bin (12528 bytes) at 0x00000000

    Target: SENDIMG
    Target: BEGIN
    100% [ ████████████████████████████████████████████████████████████ ]
    Image data transmitted over UART.

    Target: DONE
    0% [ ------------------------------------------------------------ ]
    Programming UBL into flash...

    Target: CurrBlockNum =0x00000001
    Target: Writing image data to Block 0x00000001, Page 0x00000000
    Target: Writing image data to Block 0x00000001, Page 0x00000001
    Target: Writing image data to Block 0x00000001, Page 0x00000002
    Target: Writing image data to Block 0x00000001, Page 0x00000003
    Target: Writing image data to Block 0x00000001, Page 0x00000004
    Target: Writing image data to Block 0x00000001, Page 0x00000005
    0% Target: Writing image data to Block 0x00000001, Page 0x00000006
    100% ████████████████████████████████████████████████████████████007
    UBL programming complete
    Target: DONE

    Flashing application u-boot.bin (430852 bytes)

    Target: SENDIMG
    Target: BEGIN
    100% [ ████████████████████████████████████████████████████████████ ]
    Image data transmitted over UART.

    Target: DONE
    0% [ ------------------------------------------------------------ ]
    Programming application into flash...

    Target: Number of blocks needed for header and data: 0x0x00000004
    Target: Attempting to start in block number 0x0x00000006.
    Target: Magicnum: 0x0x55424CBB
    Target: Entrypoint: 0x0xC1080000
    100% ████████████████████████████████████████████████████████████
    Application programming complete e 0x00000000
    Target: DONE
    Target: DONE

    Operation completed successfully.

    ***

  • 0 in reply to Filosofi
    Intellectual 925 points

    Hi,

    I've solved also my last doubt.

    For SPI Flash as a boot memory device, SFH gets u-boot.bin and simply prepends the 20 bytes header

    typedef struct _SPIBOOT_HEADER_ 
    { 
     Uint32 magicNum;    // Expected magic number (0x0x55424CBB) 
     Uint32 entryPoint;  // Entry point of the user application (def: 0x0xC1080000) 
     Uint32 appSize;     // Number of bytes of the application image (example: 0x00069b20) 
     Uint32 memAddress;  // SPI memory offset where the application image is located (def: 0x00010014) 
     Uint32 ldAddress;   // Starting RAM address where image is to copied (def:0xC1080000) 
    } SPI_MEM_BOOT_HeaderObj, *SPI_MEM_BOOT_HeaderHandle; 

    Instead, for NAND Flash as a boot memory device, SFH gets u-boot.bin and prepends an entire page (2K) with just the 24 bytes header at offset 0 

    typedef struct _NANDBOOT_HEADER_ 
    { 
     Uint32 magicNum;    // Expected magic number (0x0x55424CBB) 
     Uint32 entryPoint;  // Entry point of the user application (def: 0x0xC1080000) 
     Uint32 numPage;     // Number of pages where boot loader is stored (example: 0x000000D4) 
     Uint32 block;       // Starting block number where User boot loader is stored (def: 0x00000006) 
     Uint32 page;        // Starting page number where boot-loader is stored (def: 0x00000001) 
     Uint32 ldAddress;   // Starting RAM address where image is to copied - XIP Mode (def: 0xC1080000) 
    } NANDBOOT_HeaderObj, *NANDBOOT_HeaderHandle;

    That's all.

    Bye.

  • 0 in reply to Filosofi
    TI__Guru** 116100 points
    Hi Filosofi,

    Thanks for your update.


    I have looked at the SFH source code. The relevant function is LOCAL_NANDWriteHeaderAndData() defined in sfh/sft/src/uartboot.c.
    It is the DEVICE_NAND_UBL_SEARCH_START_BLOCK constant (6) which defines the minimum allowed block number.
    So, instead of re-compiling SFH, I have decided to redefine the u-boot and kernel partitions in order to match the SFH behavior.

    FYI:
    It is for having multiple UBL copies to avoid boot failures, if first copy of UBL got corrupted then it would take second copy and it started to boot, so think of that.
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 925 points
    Hi,

    Quite clear.
    Unfortunately I'm struggling again on the meaning of the extra chunk of data that SFH appends to the input data (u-boot.bin) to fill the last page of the NAND. It makes the difference because any change it results in boot failure:

    AM1808 initialization passed!
    Booting TI User Boot Loader
    UBL Version: 1.65
    UBL Flashtype: NAND
    Starting NAND Copy...
    Valid magicnum, 0x55424CBB, found in block 0x00000006.
    No valid boot image found!
    NAND Boot failed.
    Aborting...

    Can you or anybody else help ?

    Gabriele