[U-Boot] Atmel SAMA5D31 NOR boot - sanity check required

[Bo Shen]

Hi Andy,

On 06/17/2014 07:09 PM, Andy Pont wrote:
> Hello!
>
> I am currently working on an implementation of NOR boot support for the
> Atmel SAMA5D31-EK reference platform as a precursor to a custom hardware
> platform.  When tested and working I will push the support back to the
> community but what I have at the moment doesn't appear to do anything so I
> would appreciate a sanity check on the work done so far.
>
> For reference the documentation for the Atmel SoC says:
>
> If BMS signal is tied to 0, BMS_BIT is read at 1.  The ROM code allows
> execution of the code contained in the memory connected to Chip Select 0 of
> the External Bus Interface (J828F128P33TF70A) and then goes on to detail the
> startup mode and changes that need to be made to the PLL and SMC.

I think you should check more detail in section 12 "Standard Boot 
Strategies". It needs more things to do. I will give a picture in 
following answer.

> For simplicity sake, I have taken the standard SAMA5D31-EK configuration of
> SPL+U-Boot and have added NOR boot support to SPL based on one of the other
> boards.  The board header file has the following configuration:
>
> #define CONFIG_SPL_NOR_SUPPORT
> #define CONFIG_SYS_FLASH_CFI            1
> #define CONFIG_FLASH_CFI_DRIVER         1
> #define CONFIG_SYS_FLASH_BASE           0x00000000
> #define CONFIG_SYS_MONITOR_BASE         CONFIG_SYS_FLASH_BASE
>
> As per the standard SPL build for this hardware platform the
> CONFIG_SYS_INIT_SP_ADDR value is set to 0x310000 but I haven't found a
> definitive statement that confirms that the internal SRAM is mapped to that
> location when in this boot mode.
>
> So my questions are...
>
> Is the SPL+U-Boot implementation the best way for NOR booting or should it
> all just be built as a single U-Boot image?

I think SPL + U-boot is a good choice.

> Do the settings above look correct, particularly the value for the initial
> stack pointer?

The stack pointer use the top address of internal SRAM.

> How best do I debug SPL to determine where it is getting lost in the weeds?

As the code execute on NOR flash, so, the SPL configure the CPU clock 
will cause SMC access abortion. So, a brief guide as following:

1. Write a ram function, which do as the datasheet says.
2. Add copy function (copy the ram function into sram) at the begin of 
the SPL code.
3. After the step 1, finished to execute, then, you can jump back to NOR 
to execute.

May you got what I mean, if any questions, please let me know.

> Many thanks,
>
> Andy.

Best Regards,
Bo Shen