Hi,
I have a really tough challenge for you: I need a global variable in v3.
Global means that it has to be accessible from all of stage1/stage2 code
(maybe except initram).
So far I only see one unacceptably hackish solution: Pass a pointer to
the global variable to every function in the
On Mon, Feb 04, 2008 at 02:52:05PM +0100, Carl-Daniel Hailfinger wrote:
I have a really tough challenge for you: I need a global variable
in v3.
Why?
//Peter
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
* Carl-Daniel Hailfinger [EMAIL PROTECTED] [080204 18:09]:
Hm yes. That still leaves us with the problem to locate the buffer. We
cannot rely on gcc to place it on stack in the location we want.
But we know which memory area is CARed. We can just use a piece of
that area. No need to involve
ron minnich wrote:
So, this is an example of the reason for the (void *) param I was
suggesting some time back. Such needs come up.
One option is to have a convention that globals are at the base of the
stack, rounded to 64k.
e.g. %esp 0x is where globals live.
Let's just put the
So, this is an example of the reason for the (void *) param I was
suggesting some time back. Such needs come up.
One option is to have a convention that globals are at the base of the
stack, rounded to 64k.
e.g. %esp 0x is where globals live.
ron
--
coreboot mailing list
On Mon, Feb 04, 2008 at 05:22:24PM +0100, Stefan Reinauer wrote:
e.g. %esp 0x is where globals live.
Let's just put the buffer to a well known address.
Yes, simple is good.
//Peter
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
* Carl-Daniel Hailfinger [EMAIL PROTECTED] [080204 17:42]:
It's not that easy. I need the location of the buffer and the current
offset inside the buffer. The one global variable would have pointed to
a struct containing all that info.
You want that pointer persistant anyways, because you
On 04.02.2008 17:12, ron minnich wrote:
So, this is an example of the reason for the (void *) param I was
suggesting some time back. Such needs come up.
One option is to have a convention that globals are at the base of the
stack, rounded to 64k.
e.g. %esp 0x is where globals live.
I think we're making this too hard.
Given a CAR address space, starting at CARBASE and ending at CAREND, we
partition it as follows:
bottom 1/2: stack
top 1/2: defined by the Linux log buffer struct.
All done.
ron
--
coreboot mailing list
coreboot@coreboot.org
On Feb 4, 2008 8:47 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
That could work, although in a slightly different way. I would store a
pointer at the base of the stack. That pointer would point to a struct
which has all global info.
sure. At that point it's actually a parameter by
On 04.02.2008 19:46, ron minnich wrote:
I think we're making this too hard.
Given a CAR address space, starting at CARBASE and ending at CAREND, we
partition it as follows:
bottom 1/2: stack
top 1/2: defined by the Linux log buffer struct.
Are you using top and bottom in the sense of
On Feb 4, 2008 11:40 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Are you using top and bottom in the sense of memory addresses or
their place on the stack?
memory addresses.So for example log buf could be 0x8c000 to 0x8 and
stack from 0x8 to 0x8bfff
ron
--
coreboot
12 matches
Mail list logo
