• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 101 subscribers
  • Views 849 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.

Dilemma - X-loader not loading U-boot.

Gary Marsh
Prodigy 50 points
Other Parts Discussed in Thread: AM3517

I'm using an AM3517 Craneboard as a development platform for a future embedded design. I've successfully compiled X-loader and U-boot using the Craneboard git sources, which are based on TI PSP 03.00.01.06. From that compiled code, X-loader successfully runs U-boot, which in turn successfully boots a kernel.

I then decided to move up to the latest TI PSP (04.02.00.07) since it supports HW ECC of NAND, but it doesn't have support built in for the Craneboard so I added support back in. Changes for this were relatively minor; mainly done by cloning the AM3517EVM code and making small changes to account for differences between that board and the Craneboard - removing NOR support, adding the 3.3V Craneboard NAND chip ID to the NAND driver, etc. Seemed straightforward to do.

Well... "new" U-boot works fine, if I boot it from "old" X-loader. But "new" X-loader, for some reason, won't boot either "new" or "old" U-boot. X-loader reads U-boot into RAM, jumps to it... and the card immediately resets.

I've added memory test/checksum code to X-loader to try and figure out why, but can't find anything wrong. The modified X-loader is correctly setting up SDRAM, it's correctly reading U-boot from my SD card (right # of bytes, checksum out of SDRAM matches file checksum) and it's putting U-boot into the same memory location that "old" X-loader pokes it (0x80008000)... so I'm left scratching my head.

So I guess my questions are...

- Has anyone successfully run 04.02.00.07 on the AM3517EVM? (indicating that the problem I'm seeing is my fault)
- Has anyone ever encountered the "U-boot won't boot" situation that I have, and have any advice?

I can make a .diff of my X-loader changes available if anyone wants to have a look at it.

Thanks!

-GM

  • 0
    TI__Expert 6735 points

    GM:

    Yes, please post your x-loader diff.

    What are your NAND ECC requirements?

    Regards,

    Michael T

  • 0 in reply to Michael T
    Prodigy 50 points

    Here's the patch (17kbyte gzipped diff file) - http://www.sendspace.com/file/8xtmyg

    ECC requirements aren't yet finalized, we'll likely go with the default 1-bit hardware ECC. That's assuming we use onboard NAND; we're debating between putting bare NAND or putting a MicroSD socket in our embedded design.

    Thanks for the help!

    -GM

  • 0 in reply to Gary Marsh
    TI__Expert 6735 points

    GM:

    1) I looked thru the patch.  So you ar changing the NAND device ID so instead of looking for 0xBA it can be 0xBA (1.8V) or

    0xCA (3.3V).  The NAND on Crane is connected to a 3.3V supply and there should be no change to the x-loader

    other the NAND device ID received changes to 0xCA.  Both 0xBA and 0xCA are supported by RBL as 2Gb, x16, 2048-byte page.

    Could you have missed an occurrance of the "#ifdef (CONFIG_AM3517EVM)" somewhere?

    2) If x-loader is able to load and jump to u-boot, it's job is done.  Problem may be in u-boot.

         You mentioned a "new u-boot".  Do you mean the pre-built 4.2.0.7 u-boot?  Don't you also have to change the

         NAND driver in u-boot to use 0xCA?

    Regards,

    Michael T

    PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

  • 0 in reply to Michael T
    Prodigy 50 points

    (1) NAND setup is exactly as you've described. I've covered every #ifdef (CONFIG_AM3517EVM) case, with the exception of one spot where the boot mode mask was #defined, it was deliberately left alone there.

    (2) "New u-boot" refers to the compiled 04.02.00.07 PSP, with my Craneboard changes made to it in similar fashion to the x-loader changes - I can provide a diff of these also if you want. "Old u-boot" refers to the u-boot sources pulled from the Craneboard git hub, which is based on the 03.00.01.06 PSP. Both "new u-boot" and "old u-boot" work if they're loaded by the "old" x-loader, so I don't believe the issue lies with u-boot itself.

    Looking at the release notes for the 04.02.00.07 PSP, it's stated "Only Sanity testing has been carried out on OMAP35x EVMs (with both ES2.1 & ES3.1 Si), Beagle and BeagleXM" - implying that the code hasn't actually been tested on the AM3517EVM target.

    Would you folks be able to test the PSP on the actual AM3517EVM hardware? X-loader initially, but I'd be a lot more comfortable knowing that all three things - x-loader, u-boot and kernel - are tested, since I'm basing my eventual embedded system off the PSP.

    Thanks!

  • 0 in reply to Gary Marsh
    TI__Expert 6735 points

    Gary:

    The PSP 04.02.00.07 is targeted to and tested with  AM35x, AM37x and DM37x platforms.  The meaning of the comment is that only

    minimal  testing has been done on OMAP35xx, BeagleBoard and BeagleBoard XM.

    Regards,

    Michael T

  • 0 in reply to Gary Marsh
    TI__Expert 8180 points

    Gary,

    I did not understand why do you say that "the code hasn't actually been tested on the AM3517EVM target"? Please note that 04.02.00.07 release has been validated on AM3517EVM and AM37xEVM (System Test has been completed).

    Thanks,

    Vaibhav

  • 0 in reply to Vaibhav Hiremath
    Prodigy 50 points

    Thanks for the clarification. I misread the line in the PSP release notes.

    I made a far simpler change to X-loader, simply modifying the AM3517EVM board type in the stock PSP with a couple of changes:

    - board/am3517evm/am3517evm.c - in switch(mem_type), new cases 6, 8 and 24 return MMC_NAND. The Craneboard DIP switches are set to mem_type 24.
    - drivers/k9f1g08r0a.c - changed 0xBA memory type to 0xCA so the board recognizes the 3.3V NAND on my board.

    Doing this, same behavior - the Craneboard correctly pulls u-boot.bin from the SD card into memory, jumps to it and the board resets. Starting to think it's an obscure hardware difference now, time to stare at schematics for a while..

  • 0 in reply to Gary Marsh
    Intellectual 580 points

    hello, gary, can you share the file k9f1g0ir0a.c?