York,
Thanks a lot for your answer and precisions.
On 23/03/16 16:56, york sun wrote:
Valentin,
Your understand is correct. Please see my answers below to your questions.
On 03/23/2016 12:46 AM, Valentin Longchamp wrote:
Hello,
We are currently designing a board based on the T1040 CPU from Freescale/NXP. I am preparing its u-boot support and bring-up tools (JTAG) as well as contributing to the hardware design. We base our work (both HW and SW) on the 1040RDB dev board as our reference design. We want to use a parallel ("classical", not SPI) NOR Flash to boot from and to store our RCW/PBL and u-boot.
I have a question regarding the Boot location address when booting from the NOR flash. From the documentation, it is clear that the RCW and PBL instructions are read from the NOR (when cfg_rcw_src and RCW[PBI_SRC] are defined accordingly) through CS0 at from the address 0x0000_0000 (RM 27.5.1, PBL Starting addresses). I have not found a clear indication about this in the doc, but I guess that the PBL manages to minimally configure the IFC NOR controller to make sure the addresses it accesses trigger the CS0 and drives the address lines to access address 0 and counting up. My understanding is that we must thus make sure that the NOR Flash's CS is connected to the CS0.
For the actual boot location (i.e. when the cores start to execute code, after the RCW/PBL sequence), as stated in section 4.3.3 in the RM (Boot Space Translation), the cores execute the code that is located in the 4K page located at address 0x0_FFFF_F000, starting with the reset vector at address 0x0_FFFF_FFFC, which are located in the default boot location (0x0_FF80_0000 to 0x0_FFFF_FFFF). My conclusion is that somehow, the IFC NOR controller is again configured so that the accesses to this memory range will trigger the CS0 NOR access (in the T1040RDB RCW/PBL, I have seen no indication that another boot window than the default one is use, since the boot space translation capability is unused). But since the NOR boot section (24.6.1) does not give any details, I have no idea how this works.
Now u-boot, for its T1040RDB support, uses a memory mapping for the NOR Flash that is not aligned with the above boot location mapping. The 128 MB of the NOR flash are mapped from 0xE800_0000 to 0xEFFF_FFFF. My guess about this "change" it that it is to avoid the memory conflict with CCSR that is located at 0x0_FE00_0000 by default when the NOR is bigger than 16 MB. I think this mapping is only relevant later in the u-boot boot sequence, when the TLBs and LAWs are configured but not at boot time.
I have two questions about this NOR boot mechanism:
- how are the NOR accesses really happening (or how is the IFC NOR configured)
at boot time to read the RCW/PBL and the boot code at boot location ? I ask this in order to make sure that our HW design will allow us to boot from the NOR Flash (i.e. how we connect the NOR address bus to the IFC)
When IFC NOR flash is used for RCW_SRC (configured by hardware pins), the IFC defaults some registers to enable accessing to CS0. You can read the notes for CSPR0, CSOR0, AMASK0, etc. Basically they are set to default values based on the RCW_SRC and 4G space is mapped to CS0. So you can see any reading accessing is mapped to CS0. Because we don't have NOR flash with 4GB, and we don't have 32 address pins on NOR flash chip, you can expect to get RCW image from the beginning of NOR flash at multiple addresses, including zero. You can also expect to get reset vector at multiple addresses, including 0xfffffffc. So in short, these default settings guarantee the RCW and reset vectors are accessible, regardless the size of NOR flash chip.
OK, the precision about the 4G address space was the part I was missing. From then on it's clear that you can expect the reset vector at different addresses since not all the 32 pins are connected to the NOR chip indeed.
- what about CONFIG_SYS_TEXT_BASE ? I see that it defined according the later
"u-boot" memory mapping. Why this one and not the "boot time" one ?
Since we have 128MB NOR flash chip, and other devices on IFC, the default memory map is not enough. We need to remap them to avoid conflicts and make room. It is done by calling init_early_memctl_regs(). CONFIG_SYS_TEXT_BASE needs to match the actual address.
OK, good to know for our actual mapping (that most likely will be similar).
You worked on 85xx before (kmp204x). It is the same idea. Even T1040 had a "T" in the name, it is still in mpc85xx family.
Yup, a lot of similarities here, that helps a lot !
Thanks again for your support
Valentin