Re: [U-Boot] Atmel SAMA5D31 NOR boot - sanity check required
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
Hi Bo,
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.
<snip>
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:
The datasheet says the user software in external memory should:
a) Enable the 32768 Hz oscillator if best accuracy is needed. b) Reprogram the SMC setup, cycle, hold, mode timing registers for EBI CS0, to adapt them to the new clock. c) Program the PMC (Main Oscillator Enable or Bypass mode). d) Program and start the PLL. e) Switch the system clock to the new value.
So my current thinking is that:
- I am not so worried about (a), as I don't think accuracy is essential at this point in time. - (b) needs to be taken care of in the steps that you outline below. - (c) ??? - The function at91_pmc_init() in board\atmel\sama5d3xek\sama5d3xek.c takes care of items (d) and (e)
It has been a while since I have done this much low level code so I may be a little rusty :-)
- Write a ram function, which do as the datasheet says.
- 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.
I'm not sure I follow how to do this. Are there any similar implementations elsewhere in U-Boot that I could use as a reference. I should say that ARM assembler isn't my strongest skill as most of my previous experience has been gained with x86 and MIPS.
Thanks for all your help.
Andy.
participants (2)
-
Andy Pont -
Bo Shen