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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
