We need a way to find out where our stack and our global variables are at any given moment. This is a first generic try, but doing this in a processor-specific way would be more appropriate.
Please note that this needs a new #define or Kconfig variable somewhere: CONFIG_RAM_STACK_LOCATION. As an alternative, we could declare the top of memory as optimal stack location.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: corebootv3-globalvariablelocation/arch/x86/stage1.c =================================================================== --- corebootv3-globalvariablelocation/arch/x86/stage1.c (Revision 925) +++ corebootv3-globalvariablelocation/arch/x86/stage1.c (Arbeitskopie) @@ -70,11 +70,22 @@ /* * The name is slightly misleading because this is the initial stack pointer, * not the address of the first element on the stack. + * NOTE: This function is very processor specific. */ void *bottom_of_stack(void) { - /* -4 because CONFIG_CARBASE + CONFIG_CARSIZE - 4 is initial %esp */ - return (void *)(CONFIG_CARBASE + CONFIG_CARSIZE - 4); + u32 onstack = (u32)&onstack; + + /* Check whether the variable onstack is inside the CAR area. + * If it is, assume we're still in CAR or the stack has not moved. + * Otherwise return initial %esp for the RAM-based stack location. + */ + if ((onstack >= CONFIG_CARBASE) && + (onstack < CONFIG_CARBASE + CONFIG_CARSIZE - 4)) + /* CONFIG_CARBASE + CONFIG_CARSIZE - 4 is initial %esp */ + return (void *)(CONFIG_CARBASE + CONFIG_CARSIZE - 4); + /* OK, so current %esp is not inside the CAR area. */ + return (void *) CONFIG_RAM_STACK_LOCATION; }
struct global_vars *global_vars(void)
return (void *) CONFIG_RAM_STACK_LOCATION;
not quite right? CONFIG_RAM_STACK_LOCATION; + CONFIG_RAM_STACK_SIZE -4?
ron
On 15.10.2008 04:54, ron minnich wrote:
return (void *) CONFIG_RAM_STACK_LOCATION;
not quite right? CONFIG_RAM_STACK_LOCATION; + CONFIG_RAM_STACK_SIZE -4?
Actually, that was intentional. You see, we haven't decided on the meaning of the RAM_STACK_LOCATION constant/variable yet. We could very well declare it to be the initial %esp for RAM stacks. Then again, we could also decide that the stack shall be at the top of available RAM, and that would require us to use a variable.
You supply the meaning of the variable, I'll make sure the code matches.
Regards, Carl-Daniel
On Wed, Oct 15, 2008 at 3:09 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 15.10.2008 04:54, ron minnich wrote:
return (void *) CONFIG_RAM_STACK_LOCATION;
not quite right? CONFIG_RAM_STACK_LOCATION; + CONFIG_RAM_STACK_SIZE -4?
Actually, that was intentional. You see, we haven't decided on the meaning of the RAM_STACK_LOCATION constant/variable yet. We could very well declare it to be the initial %esp for RAM stacks. Then again, we could also decide that the stack shall be at the top of available RAM, and that would require us to use a variable.
You supply the meaning of the variable, I'll make sure the code matches.
let's call it RAM_TOP_OF_STACK and put it at the standard 88ffc
ron
On Wed, Oct 15, 2008 at 8:34 AM, ron minnich rminnich@gmail.com wrote:
On Wed, Oct 15, 2008 at 3:09 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 15.10.2008 04:54, ron minnich wrote:
return (void *) CONFIG_RAM_STACK_LOCATION;
not quite right? CONFIG_RAM_STACK_LOCATION; + CONFIG_RAM_STACK_SIZE -4?
Actually, that was intentional. You see, we haven't decided on the meaning of the RAM_STACK_LOCATION constant/variable yet. We could very well declare it to be the initial %esp for RAM stacks. Then again, we could also decide that the stack shall be at the top of available RAM, and that would require us to use a variable.
You supply the meaning of the variable, I'll make sure the code matches.
let's call it RAM_TOP_OF_STACK and put it at the standard 88ffc
Sorry: RAM_STACK_BASE at 0x88ffc
ron
On 15.10.2008 17:34, ron minnich wrote:
On Wed, Oct 15, 2008 at 8:34 AM, ron minnich rminnich@gmail.com wrote:
On Wed, Oct 15, 2008 at 3:09 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 15.10.2008 04:54, ron minnich wrote:
return (void *) CONFIG_RAM_STACK_LOCATION;
not quite right? CONFIG_RAM_STACK_LOCATION; + CONFIG_RAM_STACK_SIZE -4?
Actually, that was intentional. You see, we haven't decided on the meaning of the RAM_STACK_LOCATION constant/variable yet. We could very well declare it to be the initial %esp for RAM stacks. Then again, we could also decide that the stack shall be at the top of available RAM, and that would require us to use a variable.
You supply the meaning of the variable, I'll make sure the code matches.
let's call it RAM_TOP_OF_STACK and put it at the standard 88ff
Sorry: RAM_STACK_BASE at 0x88ffc
While I do agree, it may be confusing for some people to have RAM_STACK_BASE denote the upper (as in memory location) end of the stack and CARBASE denote the lower end of the stack.
Suggested fix: Introduce the following #define:
#define CAR_STACK_BASE (CONFIG_CARBASE + CONFIG_CARSIZE - 4)
What do you think?
Regards, Carl-Daniel
On Wed, Oct 15, 2008 at 10:02 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
While I do agree, it may be confusing for some people to have RAM_STACK_BASE denote the upper (as in memory location) end of the stack and CARBASE denote the lower end of the stack.
Suggested fix: Introduce the following #define:
#define CAR_STACK_BASE (CONFIG_CARBASE + CONFIG_CARSIZE - 4)
What do you think?
it's fine!
ron
New version which takes into account everything mentioned in the discussion.
We need a way to find out where our stack and our global variables are at any given moment. The code is generic enough to handle this in a processor-specific way behind the scenes if needed.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: corebootv3-globalvariablelocation/include/arch/x86/cpu.h =================================================================== --- corebootv3-globalvariablelocation/include/arch/x86/cpu.h (Revision 931) +++ corebootv3-globalvariablelocation/include/arch/x86/cpu.h (Arbeitskopie) @@ -266,11 +266,17 @@ struct global_vars * global_vars(void); EXPORT_SYMBOL(global_vars);
+#define CAR_STACK_BASE (CONFIG_CARBASE + CONFIG_CARSIZE - 4) +#define RAM_STACK_BASE 0x88ffc + #ifdef CONFIG_CONSOLE_BUFFER #define PRINTK_BUF_SIZE_CAR (CONFIG_CARSIZE / 2) #define PRINTK_BUF_ADDR_CAR CONFIG_CARBASE #define PRINTK_BUF_SIZE_RAM 65536 #define PRINTK_BUF_ADDR_RAM 0x90000 +#define CAR_STACK_SIZE ((CONFIG_CARSIZE / 2) - 4) +#else +#define CAR_STACK_SIZE (CONFIG_CARSIZE - 4) #endif
/* resource maps. These started out as special for the K8 but now have more general usage */ Index: corebootv3-globalvariablelocation/arch/x86/stage1.c =================================================================== --- corebootv3-globalvariablelocation/arch/x86/stage1.c (Revision 931) +++ corebootv3-globalvariablelocation/arch/x86/stage1.c (Arbeitskopie) @@ -70,11 +70,21 @@ /* * The name is slightly misleading because this is the initial stack pointer, * not the address of the first element on the stack. + * NOTE: This function is very processor specific. */ void *bottom_of_stack(void) { - /* -4 because CONFIG_CARBASE + CONFIG_CARSIZE - 4 is initial %esp */ - return (void *)(CONFIG_CARBASE + CONFIG_CARSIZE - 4); + u32 onstack = (u32)&onstack; + + /* Check whether the variable onstack is inside the CAR stack area. + * If it is, assume we're still in CAR or the stack has not moved. + * Otherwise return initial %esp for the RAM-based stack location. + */ + if ((onstack >= CAR_STACK_BASE - CAR_STACK_SIZE) && + (onstack < CAR_STACK_BASE)) + return (void *)CAR_STACK_BASE; + /* OK, so current %esp is not inside the CAR stack area. */ + return (void *)RAM_STACK_BASE; }
struct global_vars *global_vars(void)
On 16.10.2008 03:37, Carl-Daniel Hailfinger wrote:
New version which takes into account everything mentioned in the discussion.
We need a way to find out where our stack and our global variables are at any given moment. The code is generic enough to handle this in a processor-specific way behind the scenes if needed.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Committed in r933.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
ron minnich