[U-Boot] [T1040] Boot location and NOR flash memory mapping

[york sun]

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.

> - 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.

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.

York