More practically:
1st we have to check if the NAND is at all recognized by the RBL and if NAND boot starts at all.
- How do the NAND and GPMC timings look like compared to what is documented at page 4684 of the TRM SPRUH73?
- Can you hook a JTAG emulator to the board? In this case you could check the tracing vector (see board bring up wiki above and TRM). It would tell if the NAND boot has at least started.
- How much activity do you see on the GPMC interface during bootload? Depending on the activity of the control pins you could assess if the boot fails early or late in the NAND boot process.
- The RBL should copy the SPL to internal OCP RAM. Is there a way you can check the internal OCM RAM is written using CCS?
Could you modify the SPL to blink a LED or toggle a GPIO for example so that it can it tells it runs?
If the SPL runs it should setup the DDR. Do you see any activities on the DDR?
- As part of the starterware (non OS based C code) you can burn a simple C application to NAND via CCS. There AM335x side executable (see \tools\flash_writer\src\nand-flash-writer_AM335x\src) that you can adapt (layout, timing, ..etc) to your NAND device (as only the EVM and SK are supported out of the box).
As the first step you could replace the starterware bootloader by a simple while (1) loop. At boot the RBL will copy it to the OCM RAM. You can easily check with CCS if this step happens.
Then when it is working then you could use the starterware bootloader and a while (1) as application.
The starterware loader will be loaded in OCM RAM. It will run and should load the application to DDR.
Also the Startweware documentation does provides some high level information:
http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Booting_And_Flashing#Booting_Via_NAND
You could do something comparable with SPL and U-boot. The advantage of using the Starterware is that you would have a better visibility using CCS as CCS is part of the build and debug flow of the Starterware.
Anthony
