• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 243 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.

3530 EVM: error during MLO execution

Nicolas Vassal
Prodigy 180 points

Hi,

I have a problem during the execution of MLO on my 3530 EVM board, but only for some sysboot configurations.

In my system the MLO, and all software, are located on an SD card inserted in MMC1 slot. All others memories/peripherals cannot be used.

If I use the 0b111000 conf (UART3 then MMC1) the software is correctly loaded and executed in a consistant way.

If I use these conf: 0b110000 or 0b100110 or 0b000110, the MLO is loaded and executed ... but it fails and hangs.... consistantly also ..

Are there some known limitations on some sysboot configurations on EVM board?

Thanks!

 

Regards,

Nicolas.

 

  • 0
    TI__Genius 15510 points

    I think I can explain what is happening.  Early EVMs had Infineon memory parts (DDR+OneNAND). Later EVMs had Micron memory parts (DDR+NAND). Looking at the MLO code, it looks like this code snippet determines whether you have NAND or OneNAND and if you are booting from MMC first or from the flash on our board:

    u32 get_mem_type(void)
    {
            u32   mem_type = get_sysboot_value();
            switch (mem_type){
                case 0:
                case 2:
                case 4:
                case 16:
                case 22:    return GPMC_ONENAND;

                case 1:
                case 12:
                case 15:
                case 21:
                case 27:    return GPMC_NAND;

                case 3:
                case 6:     return MMC_ONENAND;

                case 8:
                case 11:

                case 14:
                case 20:
                case 26:    return GPMC_MDOC;

                case 17:
                case 18:
                case 24:    return MMC_NAND;

    There are more case statements but I think this gives you an idea.  The routine get_sysboot_value strips off the upper bit so that you get the following:

    111000 -> 11000 ->case 24 -> MMC_NAND

    110000 -> 10000 -> case 16 -> GPMC_ONENAND

    Your other two map to MMC_ONENAND

    Later  the code MLO tries to determine how to configure the SDRC for the DDR that you have:

            if ((get_mem_type() == GPMC_ONENAND) || (get_mem_type() == MMC_ONENAND)){
                    __raw_writel(INFINEON_SDRC_ACTIM_CTRLA_0, SDRC_ACTIM_CTRLA_0);
                    __raw_writel(INFINEON_SDRC_ACTIM_CTRLB_0, SDRC_ACTIM_CTRLB_0);
            }
            if ((get_mem_type() == GPMC_NAND) ||(get_mem_type() == MMC_NAND)){
                    __raw_writel(MICRON_SDRC_ACTIM_CTRLA_0, SDRC_ACTIM_CTRLA_0);
                    __raw_writel(MICRON_SDRC_ACTIM_CTRLB_0, SDRC_ACTIM_CTRLB_0);
            }

    I think what is happening in the cases that don't work for you is that you are trying to configure MICRON DDR with Infineon DDR setting that cause the board to hang. Try setting sys_boot to any of the GPMC_NAND or MMC_NAND settings. All of the code I referenced is in the x-loader source directory in the board/omap3evm/omap3evm.c file.

    Steve K.

  • 0 in reply to Steve Kipisz
    Prodigy 180 points

    Hi Steve,

    thanks for your advice, I have modified a little bit the switch/case code, and now my software is correctly executed.

    I have modified the x-loader instead of simply changing SYSBOOT because I'm trying to reproduce an issue I have seen on a beagleboard, with the same sysboot config: 0b11'0000

    And I can see the same problem now on EVM!

    The goal of my software is to put the OMAP in OFF mode, wake it up on a IO daisy chain event and using the ROM code restoration mechanism to restore DDr settings and re-start code execution directly from DDr (skipping MLO execution).

    When using 0b11'1000 sysboot config, the whole sequence is fine, and the device can do hundreds of OFF/Active sequences. But when I'm using 0b11'0000 sysboot config, the device does not wakeup properly. Looks like I get some global warm reset when the device wakes-up.

    I have created another post for this issue: http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/58561/208804.aspx

    I you have an idea about it also ...

    Thanks for your help!

    Regards,

    Nicolas.