66AK2H14: Instructions for ARM Boot

Joe,

The instructions to boot from NAND on this devices are documented here:

http://www.ti.com/lit/an/spracn3/spracn3.pdf

We have the image formatting tools and single stage booting described in that document. The key gotcha in NAND boot is typically the format in which NAND ECC is programmed in the spare area. Please make sure that the ECC data is written in the correct format as done using the CCS based NAND writer we provide in SDK.

The ECC data needs to be generated using EMIF and stored in the same format as described here: (nandwriter supports two ECC layouts)

http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout 

It may good for you to confirm this setup on K2H EVM to confirm the image format before you move to the custom platform. Please let us know if you run into any issues and we can provide further guidance.

Regards,

Rahul

Hello, thank you for responding to my message. My co-worker took the program and tried using an EVM and he was successful. I will print out your reference docs and get with him.

Joe

Just wanted to give the part# 66AK2H14DAAWA24 of the device we are using. Thanks, Joe

Hello,

I am working with joe and i have come across some issues with booting from NAND using a custom board. I have tested my code on the DEV board and it successfully wrote my image to shared memory. I couldn't use your tools because the NAND we are using is different, although it is ONFI compatible and the geometry is the same.

I have successfully written the ECC values into the spare area and double checked the results against our custom platform and the EVM. the only difference between the two is the NAND chip we are using, and the PLL settings for the ARM and the System Clock at boot time. What else is required for the RBL (rom boot loader) to startup successfully. Is there any way to monitor this start up sequence? 

Again, my code/ GP Header Image works for the EVM Board but does not for the custom setup. I can read back the image from Nand along with the ECC Values and the format is exactly the same it just wont boot. 

Just as a side note:

Are there any registers/ memory addesses we can monitor to see if the RBL even starts up?

Rahul,

I don't see any of these symbols in the disassembly at startup, also I don't have my sections set up either as that is the next step. right now all I'm trying to do is load code onto shared memory onto out custom board, which the EVM does already. I am doing everything in bare metal in my own version as well, so i more than likely won't have all the information you are expecting back from your IP.

One of my main concerns is  how impactful the startup clocks are to the RBL.

does the RBL expect to be driven at the speed provided by the EVM?

Devstat register for our custom board is 0x02010867  

and the Devstat for the EVM is               0x02030CE7

Is this a possible issue? 

Rahul,

any updates on my last question?

UPDATE,

Joe and I scoped out the signals to see if the bootloader started at all, I don't think it did as the signals we captured only show the EMIF being powered on.

Here are the screen shots of the signals we scoped out. I noticed that the CLE signal stays low and i never see the processor attempt any transactions to

read the NAND.

Are there specific moments in time where the bootloader activates?

Rahul,

I forgot to include an other incident that kept reoccurring in my last reply. The WE pin sporadically toggled at around 1.6s into loading, is  this expected behavior of the RBL?

Alfredo,

Sorry for the delay. I was a little tied up with other tasks so couldn`t get back on this topic.

Setup clocks are and power sequencing is critical for the ROM boot. Please ensure that your custom design follows the Power up sequence in section 11.2.1 in the data manual. Table 10-27 in the data manual describes the clock/PLL default programming in the device. The input clock setting from the boot mode switches and the device speed grade variant is used to setup the default clocks. As long as you have used one of the eight supported values of the clocks and setup the BOOTMODE[7:5] and BOOTMODE[11:9] as per your board design the clocks will be setup correctly by the ROM.

EVM DEVSTAT = 0x02030CE7

First Block = 000
Clear NAND = 0
ARM PLL = 110 (312.5)
Boot master = 0 (ARM)
SYS PLL = 111 (122.88)
Boot mode = 0011
Little Endian =1

Custom board DEVSTAT =0x02010867

First Block = 000
Clear NAND = 0
ARM PLL = 100 (156.25)
Boot master = 0 (ARM)
SYS PLL = 011 (100)
Boot mode = 0011
Little Endian = 1

Please ensure that the values of ARM and SYSPLL match your board design.

Regards,

Rahul

Hello, the SYSCLOCKOUT is 200Mhz (1/6* 1.2Ghz) and the RESETSTAT pin does go high.

I also noticed that the BOOTCOMPLETE never goes high, is that expected in this case?

Joe

Joe,

Yes, BOOTCOMPLETE will not go high in this case. you can check the BOOTCOMPLETE description in the E2E discussion here:

https://e2e.ti.com/support/processors/f/791/t/490604?Keystone-II-EMIF-NOR-Flash-Boot-vs-BOOTCOMPLETE-Assertion

The fact that RESETSTAT goes high and SYSCLOCKOUT is being set correctly makes me believe the ROM is getting started.

Regards,

Rahul

Rahul,

Hello, thank you for responding to my message. What can we do next? I am not the engineer doing the DSP/ARM programming, I'm only a the guy that did the schematics design. What can we try next to solve this problem? 

Thanks,

Joe

Raul,

I used the memory browser tool to export the contents of memory

BOOT_DATA.datBOOT_DATA_CORE0.dat7444.BOOT_Log.datBOOT_PARAM_TABLE.datBOOT_TRACE_CORE0.dat

Rahul,

Hello, here is a screen capture of the moment the RESETSTAT pin goes high:

I put o-scope probes on the NAND Boot memory. I don't see any transactions on the CE or CLE. I don't know what is going on with the WE for two events. 

If we connected to the target over JTAG and write to this NAND memory is working okay and we see good signal transactions. 

We must be missing something.

I also measured the SOC clocks:

SOC_ARM_CLK is 156.25Mhz

SOC_SYS_CLK is 100Mhz

SOC_PASS_CLK is 156.25Mhz

If you have any ideas, please send them.

Respectfully,

Joe

Rahul,

Hello, quick question for you when you say, "I still need you to connect to ARM Core 0 to be able provide insight from ROM boot loader perspective." what exactly do you want me to do? I must admit that I am a newbie at this stuff, usually I stop at the hardware schematics and let the software guru's take over. 

Thank you for all your help.

Respectfully,

Joe

Rahul,

Hi, I now understand what you meant about "connect to ARM Core 0 to be able provide insight from ROM boot loader perspective". I believe Alfredo is working on that. 

Joe

Joe,

Thanks for the memory dumps. I have not had a chance to look at this issue yet. To find out where the ARM cores is hung. Can you create a target configuration for 66AK2H1x and connect to ARM core 0 on your custom platform using steps provided here:

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#connect-to-evmk2h-using-ccs

Skip the step to populate the GEL file in the "Advanced Tab" as you want to analyze the ROM behavior. The GEL overrides the clock and PSC setup in ROM so we don`t want to use the GEL when analyzing the ROM behavior. After connecting to the ARM Core 0 at the end of the processor. Please go to View-Registers and under core registers look/report the Program counter value. You can also do a Run-> Reset->CPU reset to to put the core back into ROM and let the ROM bootloader restart. The other thing that you can do is from View->Disassembly, will open a Tab similar to memory view and then right click on the address and set HArdware break points at ROM symbol locations to trace if the ROM is getting to a specific stage where it is trying to read from the NAND.

Regards,

Rahul 

Rahul,

The PC is at address zero, This should be intentional. The image that I intended to write only contained a bit of data. This was used as an intermediary step to see if the data was being loaded from NAND into shared memory. The EVM loads this data in and populates the data staring at address 0x0c0c0c0c. as expected in the file below. While this may be true for the EVM our custom design does nothing.

Here is the test data that I have been using

7608.SImple_Load_NEW.dat

The PC being stuck at 0x0 means that the ROM boot loader is not executing or the core may be getting reset. Address 0x00  is the entry point of the ROM. I am a little confused with the finding as you indicated earlier that the SYSCLKOUT was 200 MHz. If the ROM is not starting then the PLL won`t be setup and that value of clock would be 100 Mhz (Input clock)/ 6 or 16.66 MHz.

Regards,

Rahul

Hello, I found that the EMIFWAIT0 was being pulled low somewhere else on the board. This is the first revision of the board and we found an error in the design. The EMIFWAIT0 was connected to an output of a buffer. Quickly found that error, lifted the pin so the EMIFWAIT0 trace was not being pulled low. We were then able to get a Ready on the NAND Flash and then program it, restart the board and then verify the data in memory. All looks good!

Thank you everyone for all your help and comments.

Respectfully,

Joe