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.

Some issues regarding IBL when using MAD utility, C6678

I am using mcsdk_2_00_08_20.

1. In my understanding, there are 2 components for IBL: 

      - IBL binary: i2crom_0x51_c6678_le.bin, building can follow build_instructions.txt in ibl\doc.

      - IBL Configuration: i2cparam_0x51_c6678_le_0x500.out + i2cConfig.gel

      Q1: how to build IBL Configuration? When is it needed to be re-built?

      Q2: there are 2 sub-projects in ibl\src\util: iblConfig and i2cConfig.
             What are they for? which one is for IBL Configuration? When are they needed to be re-built?

      Q3: ibl_single_binary.txt is instruting to generate iblConfig.out and ibl.bin in ibl/src/util/iblConfig.
             What are these? Where to use them?
             iblConfig.out == i2cparam_0x51_c6678_le_0x500.out ???
             ibl.bin == i2crom_0x51_c6678_le.bin ???

      Q4: in ibl_single_binary.txt:

                  == Create an IBL binary for a given EVM ==

                  - To create a IBL binary for a given use case, please copy the prebuilt IBL binary (what and where ???) for the
                    required EVM in the required endian from the releases folder and rename it to ibl.bin.....

                 - Then issue the command ./iblConfig.out (in dos command shell ???)

2. In STEP-4 of MAD Utils User Guide, startAddress and branchAddress are needed to modified.

      Q5: Should bootFormat be changed from ibl_BOOT_FORMAT_ELF to ibl_BOOT_FORMAT_BBLOB?

      Q6: Where should I modify them? i2cConfig.gel or ibl/src/util/iblConfig/src/device.c
             What is the difference for the 2 ways?

Thanks.

Boll

  • Hi Boll,

    Q1: The configuration of IBL is done through i2cConfig.gel, so if there is any modification of the gel file, you should re-config the IBL. The steps to write IBL configuration is clearly described in the mcsdk_2_00_xx_xx\docs\BiosMulticoreSDK_2.0_UserGuide.pdf(search "Write IBL configuration" ). There indeed need some modification of original i2cConfig.gel file when you want to use IBL for MAD. This is also related to your Q5&Q6:

    We take Nand boot as example, you should modify  i2cConfig.gel as follows:

    ibl.bootModes[1].u.nandBoot.bootFormat = ibl_BOOT_FORMAT_BBLOB;
    ibl.bootModes[1].u.nandBoot.blob[0][0].startAddress = 0x9E000000;
    ibl.bootModes[1].u.nandBoot.blob[0][0].branchAddress = 0x9E001040;

    Q2: The actual config gel you will use is located in ibl\src\make\bin\i2cConfig.gel. You will be asked to locate it if you follow the steps of MCSDK UG.

    Q3&Q4:  In common case, I don't think it need the user to rebuild the ibl project since the i2cparam_0x51_c6678_le_0x500.out(which is the one mentioned in the steps of MCSDK user guide) is already exist in ibl\src\make\bin. What you should do is to follow these steps to finish the configuration of IBL.

    Hope it helps.

    Allen

  • Dear Allen,

    Thanks for the reply.

    So to understand the sequence for MAD application, let's take NAND boot as an example.

    1. Generate c6678-le.bin through MAP tool.

    2. As requested, modify bootFormat, startAddress and branch Address in i2cConfig.gel

            - No need to modify ibl/src/util/iblConfig/src/device.c.  There are also the 3 items in device.c, what is the difference with those in i2cConfig.gel?

            - No need to re-generate i2crom_0x51_c6678_le.bin, use the default one in ibl\src\make\bin.

            - No need to re-generate i2cparam_0x51_c6678_le_0x500.out, use the default one in ibl\src\make\bin.

    3. No need to re-program i2crom_0x51_c6678_le.bin into EEPROM since the file is not modified.

    4. In CCS, program IBL Configuration into EEPROM: i2cparam_0x51_c6678_le_0x500.out + i2cConfig.gel

    5. Write c6678-le.bin into NAND FLASH.

    BTW, 

    a. Usually user does NOT need to do the things stated in ibl_single_binary.txt.  But what ibl_single_binary.txt for ?

    b. Anything to do with ibl\src\util\i2cConfig ?

    Thanks.

    Boll

  • Hi Boll,

    In your step3, do you mean you have already programed the i2crom_0x51_c6678_le.bin into EEPROM? If so, there is no need to re-program, or you will need to program it at least one time.

    ibl_single_binary.txt states how to generate the binary of ibl for the dedicated platform, so if you are working on some other EVM, you need to follow the steps in the txt to generate the customized ibl for that platform. There is originaly only binary for EVM6670/6678 within mcsdk. The source files within ibl\src\util\i2cConfig is related to the steps of ibl_single_binary.txt. So if you are using EVM6678, no need to edit these files.

    Allen

  • Dear Allen,

    Yes, in step 3 I have already programmed IBL bin into EEPROM when I perform single core booting example.

    Actually, I am referring to http://processors.wiki.ti.com/index.php/MAD_Utils_User_Guide.  The only difference is that I am experimenting to boot from NOR FLASH.

    I encounter problem in the last step: Application deployment on device, which make me scratch my head.

    I can not figure out where I am wrong since I follow the instructions step by step.

    Could you please help to review my procedure?

    1. Build mad-utils\mad-loader\examples in MinGW

             - I build it in prelinker mode
                       build_examples_msys.sh C6678 little relocatable          => app_1.exe and app_2.exe generated.

             - Error will be encountered for prelinker by pass mode.  Maybe it is related with linker command file.

               "lnk_C6678.cmd", line 13: error: placement fails for object ".text", size 0x5e00 (page 0). 
                Available ranges:  PMEM size: 0x5000 unused 0x4ec0 max hole: 0x4ec0
                

    2. No modification in deployment_template_C6678_windows.json since it is same as instructed.

    3. Build ROMSFS:    maptool.py config-files\maptoolCfg_C6678_windows.json      c6678-le.bin and mad_load_symbols.gel generated in .\images folder

    4. Set boot mode to NO BOOT.

    5. Write c6678-le.bin to NOR FLASH
            - Copy c6678-le.bin to tools\writer\nor\evmc6678l\bin, and rename to app.bin
            - Load app.bin to memory 0x9E000000 of Core 0
            - Write to NOR FLASH.      => success displayed in CCS console

    6.  Program IBL configuration to EEPROM
            - Modify \ibl\src\make\bin\i2cConfig.gel
                     ibl.bootModes[0].u.norBoot.bootFormat = ibl_BOOT_FORMAT_BBLOB;
                     ibl.bootModes[0].u.norBoot.blob[0][0].startAddress  = 0x9e000000;
                     ibl.bootModes[0].u.norBoot.blob[0][0].branchAddress = 0x9e001040;
            - Write: i2cparam_0x51_c6678_le_0x500.out + i2cConfig.gel          => success displayed in CCS console

    7. Power off EVM; set boot mode to IBL NOR boot on image 0; power on.
        The following info is displayed in UART console.

                     IBL: PLL and DDR Initialization Complete
                     IBL Result code 00
                     IBL: Booting from NOR

    8. Launch CCS, connect Core 0

            In CCS console:
                     C66xx_0: GEL Output: No initialization performed since bootmode = 0x00000005 
                     C66xx_0: GEL Output: You can manually initialize with GlobalDefaultSetup

    9. Load mad_load_symbols.gel,  Run Scripts->refresh_symbols_app1:
                     C66xx_0: GEL Output: Symbols loaded for app1 C66xx_0: GEL Output: Symbols loaded for printf_dll

            However the variable "signature" is not displayed in "Variables" View, as is supposed in the MAD user guide, no matter I resume Core 0 or not.

            Q: do I need manually to perform "Run->Load->Load Symbols" ???  If needed, What to load since there is no .out file generated?

    Thank you very much.

    Boll

     

  • hello Boll,

    Okay, let's review the process step by step:
    1. Build mad-utils\mad-loader\examples in MinGW
    In prelinker bypass mode, the section allocation is managed by user linker script, and in prelinker mode, the role is played by MAPtools. So check your lnk_C6678.cmd, the error is raised because there is not enough space in PMEM segment to place .text section. You can place text into the other segment which has more available space than 0x5e00, or increase the size of PMEM.

    2. Normally, you will be needed to modify the json file according to your application. For example, if the secNamePat doesn't include all the sections produced in your application, you must add the missing section into that part, or the Maptools will report an error. It just require no any modification in the example. Please refer the MAD_utils User guide for more details about every options of deployment.json


    5. On my version of MCSDK, the write address of NAND/NOR flash is both 0x80000000, it seems you have load the binary to a wrong address. So the data actually wroten into NOR is the useless data located in 0x80000000, maybe a piece of ZEROS. That obviously leads to MAD fails. Please check again.

    The other steps seems no problem, so retry the address of step5 and review the result.

    Allen

  • Dear Allen,

    It seems OK after I correct the mistake in step 5.

    Variable "counter" can be updated when I perform continuous refresh although "signature" can not be read from memory, shown in the figure.

    BTW, there is bug in mad-utils in mcsdk_2_00_08_20.   The variable can not get updated when I perform all of the steps.

    Things are going to be OK when I write the c6678-le.bin generated in mcsdk_2_00_05_17\tools\boot_loader\mad-utils into NOR FLASH.




    Boll

  • Hi Boll,

    According to your figure, the signature is located in 0x00000004, which is an unavailable address in C6678EVM. It seems some sections are not allocated properly. I will try to repeat the situation on my EVM and let you know if I find the reason.

    Allen 

  • hello Boll,

    I can't reproduce the status on my side. Since the signature should be located in .far section, if you could confirm that .far is already included in secNamePat of deployment_template_C6678_windows.json, the allocation of signature should be okay.

    How did you generate the app_1.exe and app_2.exe, did you make some modification of build_examples_lnx.sh or the Makefile?

    Allen

  • Dear Allen,

    1. I generate app_1.exe and app_2.exe in MinGW shell: build_examples_msys.sh C6678 little relocatable

    2. I do not modify make file.

    3. The only modification made in build_examples_msys.sh is to set CGTools to 7.3.1 since I am using the 7.3.1.

    4. I do not touch deployment_template_C6678_windows.json, and I think the .far section is already included.

    {
        "name" : "ddr-data",
        "vaddr" : "0xD0000000",
        "paddr" : [ "0x800000000", "0x801000000", "0x802000000", "0x803000000", "0x804000000", "0x805000000", "0x806000000", "0x807000000" ],
        "size" : "0x1000000",
        "secNamePat" : ["stack", "^.far$", "args", "neardata", "fardata", "rodata"],
        "cores" : [0,1,2,3,4,5,6,7],
        "permissions" : ["UR", "UW", "SR", "SW"],
        "cacheEnable" : true,
        "prefetch" : true,
        "priority" : 0,
        "shared" : false
    }

    BTW, I am evaluating C6678EVM, and using mcsdk_2_00_05_17, CGTool_7.3.1, MinGW 3.1.17, Python 2.7.2

    Which versions are you using?


    Boll

  • Dear Allen,

    In app_1.c, signature is defined as a uninitialized array: char signature[128];

    When I change it to initialized, everything will be OK: char signature[128] = " ";

    However, in my memory both initialized and uninitialized array/structure/union are placed in .far segment.

    Is the behavior changed in the new compiler of C66x, such as CGT 7.3.1?

    In lkn_C6678.cmd:

         SECTIONS
         {
               .text > PMEM
               .const > PMEM
               .far > DMEM
               .fardata > DMEM
               .neardata > DMEM
               .stack > DMEM
         }

    And in deployment_template_C6678_windows.json:

               "secNamePat" : ["stack", "^.far$", "args", "neardata", "fardata", "rodata"]


    Boll

  • Hi Boll,

    I'm using the same environment with you.

    In the default environment(--abi=eabi, --mem_model:data = far_aggregrates) the uninitialized array is placed in .far, but the initialized global array is placed in .fardata. So when you change the signature to initialized, it should go into .fardata which is already explicitly placed in secNamePat. I'm not very familiar with the json script  grammar,so I can't be sure that whether the statement "^.far$" has the ability to allocate .far section correctly. You can have a try of the following statement:

     "secNamePat" : ["stack", "^.far$", "args", "neardata", ".far", "fardata", "rodata"]

    which also explicitly allocate .far section into ddr-data segment. But the situation is indeed odd, because I think ^.far$ should be the wildcards that covers all .far sections.

    Allen

  • Dear Allen,

    I have tried your suggestion, it does not help.

    BTW, when I build app_1 with "static" option, a map file can be referred to.

    • When signature is initialized, it will be placed in .neardata.
    • When signature is uninitialized, it will be placed in .bss.
      Then I add "bss" into "secNamePat", still no help.
    Anyway, now multi-core booting is getting smooth with your help; it is a great start for me.
    I will issue a new post to further discuss this problem.
    Thanks again for your patient help.
    Boll
  • Hi guys, I've some questions regarding these configurations on the .gel file:

    ibl.bootModes[1].u.nandBoot.blob[0][0].startAddress = 0x9E000000;
    ibl.bootModes[1].u.nandBoot.blob[0][0].branchAddress = 0x9E001040;


    I'm able to run other applications that i've made using these configurations of start adress em brach adress,not only the MAD example.


    So, my question is: what exactly those 2 adresses are needed for?Why they work with another programs, not only no MAD example?


    They're some kind of default adresses to boot multicore applications?


    Thanks