[U-Boot] [PATCH v4 5/7] imx6: add some flexibility for defining macros

[Bill Pringlemeir]

> On 12/11/2014 01:15, John Tobias wrote:

>> In iMX6DQ data sheet the stack address is 0x0093FFB8 (page 383).
>> While, in iMX6SDL datasheet (page 393) is 0x0091FFB8.

On 12 Nov 2014, sbabic at denx.de wrote:

> I admit that I should take a coffe, and after that maybe I can realize
> what you are saying. Anyway, it is normal for processors to set the
> stack pointer. If at a certain point the stack pointer is
> automatically set, well, this is another case. The internal ROM will
> set the stack pointer to a well defined address when it starts, but it
> does not mean that is fixed for other part of code. The problem arises
> if from our code (SPL) we call functions inside the ROM, and of course
> this can have conflicts if they share the same address range. This is
> also not your case - if that happens, two separate stack area must be
> taken.

> What you are referring is the stack pointer of the ROM. Well, the
> processors have different ROMs (only Freescale knows the differences)
> and of course they can use differently the IRAM. But when the ROM
> gives the control to the loaded image (SPL), this can use the whole
> IRAM (with the use case exception I mentioned before).

> That is the reason because ventana and Compulab have no problems at
> all.

Yes; this is my understanding as well.  I think there is some HABv4
document which says what IRAM offsets are used and should be reserved
fro all CPUs.  For the iMx25 at least, it seems you may set the stack
address to whatever you like when calling the ROM code.  It is the HAB
data that must not be touched.

So even if calls are made to the ROM code, I think you are free to set
the stack address to whatever you want.

On Tue, Nov 11, 2014 at 5:02 PM, Fabio Estevam <festevam at gmail.com> wrote:

>> iMX6SDL has 128KB OCRAM, 0x00900000 - 0x0091ffff
>> iMX6DQ  has 256KB OCRAM, 0x00900000 - 0x0093ffff
>>
>> So, if we want 1 image to support both, we should choose 0x0091FFB8.

This is true.  However, you will limit the size on the iMX6DQ platform.
Maybe that is fine for an SPL.  I think you can also use address
aliasing.  Does the iMX6SDL fully decode?  It maybe that 0x0093ffff on
the iMX6SDL will go to the 0x0091ffff address.  Did we try 0x0093FFB8 on
the iMX6SDL and it doesn't work?

I have used the aliasing to setup cache/non-cache ranges to the IRAM.
This is nice if you have L1 (primary 1M/4M MMU section entries) and need
to have non-cached entries for DMA (ethernet, usb, etc).  But that is
probably not relevant for the SPL?

Fwiw,
Bill Pringlemeir.