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

[OMAP3530] Booting Sequence

Chris Read
Genius 3345 points

I want to have a boot sequence on OMAP-3530 that includes UART3, MMC1, and NAND, with NAND the last of the three.  SYS.BOOT[5:0] = 0b101111 = 0x2f looks from table 25-4 in spruf98d (3530 Technical Reference Manual) like it would do just fine.  However, using my Rev.G OMAP-35x EVM it doesn't seem to work--at least the MMC1 boot doesn't happen.  It skips from UART3 to NAND.  Has anyone else seen this?

 

Notes:

1.  The EVM works quite well for this testing since you can easily set SYS.BOOT[0] through SYS.BOOT[5] with the DIP switches.

2.  Booting from MMC1 does work on my EVM using SYS.BOOT[5:0] = 0b111000 or 0b010010 or 0b011000, so my SD card is working properly--just not in the 0b101111 case.

3.  I have looked for Errata that refer to this in sprz278d, but haven't found any.

 

 

  • 0
    Genius 3345 points

    At least part of the problem is that the x-loader code in the AM35x-OMAP35x-PSP-SDK-03.00.01.06 release has the 0b101111 case (actually it ignores the MSB, so 0b01111, or 15) under GPMC_NAND instead of MMC_NAND at about line 139 in function get_mem_type() of file board/omap3evm/omap3evm.c

     

    This doesn't explain why it didn't seem to want to boot at all--not even start x-loader when, with other boot modes, it would boot just fine.

  • 0 in reply to Chris Read
    TI__Intellectual 1110 points

    Latest information on this is as follows:

    A couple of things, and it’s not perfect.  I can build it to boot over MMC or from NAND, but not use the same version for both.  The code implies that there is a boot mode that will try MMC first and then do NAND, but it doesn’t seem to work.

    What I had to change was in get_mem_type(), where the case that I wanted 0b01111 (15) was under GPMC_NAND, rather than MMC_NAND.  Thus it went straight to booting from NAND, rather than trying MMC first.  However, after I switched it to MMC_NAND, it wouldn’t boot from NAND.  I don’t currently require a single version that will boot from both NAND and MMC, so I just hacked around that in lib/board.c, but it would be nice if it really worked correctly.  Also, there was no indication that it would boot and fail—that was really frustrating.  It made it look like a hardware issue.

    This does not seem correct to me, can anyone shed light on why the settings with MMC first, NAND second does not work? The bootsys pin settings seem correct for the required sequence.