From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Pont Date: Tue, 17 Jun 2014 12:09:55 +0100 Subject: [U-Boot] Atmel SAMA5D31 NOR boot - sanity check required Message-ID: <008401cf8a1c$b08976f0$119c64d0$@pont@sdcsystems.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. 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? Do the settings above look correct, particularly the value for the initial stack pointer? How best do I debug SPL to determine where it is getting lost in the weeds? Many thanks, Andy.