| Message ID | 1415746221-48062-6-git-send-email-john.tobias.ph@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
On Tue, Nov 11, 2014 at 8:50 PM, John Tobias <john.tobias.ph@gmail.com> wrote: > iMX6 SabreSD has a different stack address (0x0093FFB8) compare > to the default stack address defined in the file. Why you are using a different stack?
Hi Otavio, In iMX6DQ data sheet the stack address is 0x0093FFB8 (page 383). While, in iMX6SDL datasheet (page 393) is 0x0091FFB8. Regards, john On Tue, Nov 11, 2014 at 3:58 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > On Tue, Nov 11, 2014 at 8:50 PM, John Tobias <john.tobias.ph@gmail.com> wrote: >> iMX6 SabreSD has a different stack address (0x0093FFB8) compare >> to the default stack address defined in the file. > > Why you are using a different stack? > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.br http://code.ossystems.com.br > Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
On Tue, Nov 11, 2014 at 10:15 PM, John Tobias <john.tobias.ph@gmail.com> wrote: > In iMX6DQ data sheet the stack address is 0x0093FFB8 (page 383). > While, in iMX6SDL datasheet (page 393) is 0x0091FFB8. I am worrying how Compulab and Gateworks are using SPL if it is wrong.
I think Gateworks is based on iMX6SDL. On Tue, Nov 11, 2014 at 4:52 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > On Tue, Nov 11, 2014 at 10:15 PM, John Tobias <john.tobias.ph@gmail.com> wrote: >> In iMX6DQ data sheet the stack address is 0x0093FFB8 (page 383). >> While, in iMX6SDL datasheet (page 393) is 0x0091FFB8. > > I am worrying how Compulab and Gateworks are using SPL if it is wrong. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.br http://code.ossystems.com.br > Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
On 11/11/2014 5:52 PM, Otavio Salvador wrote: > On Tue, Nov 11, 2014 at 10:15 PM, John Tobias <john.tobias.ph@gmail.com> wrote: >> In iMX6DQ data sheet the stack address is 0x0093FFB8 (page 383). >> While, in iMX6SDL datasheet (page 393) is 0x0091FFB8. > > I am worrying how Compulab and Gateworks are using SPL if it is wrong. > 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. I don't know whether that is a goal here.
On Tue, Nov 11, 2014 at 10:59 PM, Troy Kisky <troy.kisky@boundarydevices.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. Agreed. John, Can't you just use the default 0x0091FFB8 value? Doesn't it work for you? Regards, Fabio Estevam
I'll go ahead and use the same address. Regards, john On Tue, Nov 11, 2014 at 5:02 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Tue, Nov 11, 2014 at 10:59 PM, Troy Kisky > <troy.kisky@boundarydevices.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. > > Agreed. > > John, > > Can't you just use the default 0x0091FFB8 value? Doesn't it work for you? > > Regards, > > Fabio Estevam
Hi John, On 12/11/2014 01:15, John Tobias wrote: > Hi Otavio, > > In iMX6DQ data sheet the stack address is 0x0093FFB8 (page 383). > While, in iMX6SDL datasheet (page 393) is 0x0091FFB8. > ???? 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. IMHO what you are saying is not correct. Maybe I see things different after a cup of coffee :-D. Best regards, Stefano Babic
> 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@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@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.
diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h index 5a5f940..4ff37b3 100644 --- a/include/configs/imx6_spl.h +++ b/include/configs/imx6_spl.h @@ -29,7 +29,9 @@ #define CONFIG_SPL_TEXT_BASE 0x00908000 #define CONFIG_SPL_MAX_SIZE 0x10000 #define CONFIG_SPL_START_S_PATH "arch/arm/cpu/armv7" +#ifndef CONFIG_SPL_STACK #define CONFIG_SPL_STACK 0x0091FFB8 +#endif #define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT #define CONFIG_SPL_SERIAL_SUPPORT @@ -66,7 +68,9 @@ #define CONFIG_SPL_BSS_MAX_SIZE 0x100000 /* 1 MB */ #define CONFIG_SYS_SPL_MALLOC_START 0x18300000 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x3200000 /* 50 MB */ +#ifndef CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_TEXT_BASE 0x17800000 #endif +#endif #endif
iMX6 SabreSD has a different stack address (0x0093FFB8) compare to the default stack address defined in the file. The CONFIG_SYS_TEXT_BASE is defined in mx6sabre_common.h. It is better to add the #ifndef to avoid compilation warnings. Signed-off-by: John Tobias <john.tobias.ph@gmail.com> --- include/configs/imx6_spl.h | 4 ++++ 1 file changed, 4 insertions(+)