On Wed, 2014-05-28 at 09:58 -0400, Kevin O'Connor wrote:
Is there an advantage to setting this at compile time vs only setting
these fields during runtime?
No.
Would this work instead?
u32 rommax = rom_get_max();
extern u8 final_readonly_start[];
csm_compat_table.UmaAddress =
On Wed, 2014-05-28 at 09:58 -0400, Kevin O'Connor wrote:
On Tue, May 20, 2014 at 02:22:16PM +0100, David Woodhouse wrote:
Unless CONFIG_MALLOC_UPPERMEMORY is turned off, we expect to use the
space between the top of option ROMs and the bottom of our own BIOS code
as a stack. OVMF was
On Tue, May 20, 2014 at 02:22:16PM +0100, David Woodhouse wrote:
Unless CONFIG_MALLOC_UPPERMEMORY is turned off, we expect to use the
space between the top of option ROMs and the bottom of our own BIOS code
as a stack. OVMF was previously marking the whole region from 0xC to
0xF
On Tue, 2014-05-20 at 14:22 +0100, David Woodhouse wrote:
However, this doesn't work if I have both CONFIG_MALLOC_UPPERMEMORY
*and* CONFIG_EXTRA_STACK enabled.
Hm, this appears to be because rom_get_max() is returning 0xef000,
causing us to ask UEFI to leave only the range 0xef000-0xf
On Wed, May 21, 2014 at 11:15:44AM +0100, David Woodhouse wrote:
On Tue, 2014-05-20 at 14:22 +0100, David Woodhouse wrote:
However, this doesn't work if I have both CONFIG_MALLOC_UPPERMEMORY
*and* CONFIG_EXTRA_STACK enabled.
Did you mean CONFIG_ENTRY_EXTRASTACK?
I don't see how
On Wed, 2014-05-21 at 09:52 -0400, Kevin O'Connor wrote:
Why is it wrong to declare memory at 0xef000-0xf and have a stack
at 0xef520-0xefd20?
Er, it's not. I'm stupid. But still it didn't work and it was almost
certainly because it's trying to write to read-only memory, given the
On Wed, 2014-05-21 at 09:52 -0400, Kevin O'Connor wrote:
Why is it wrong to declare memory at 0xef000-0xf and have a stack
at 0xef520-0xefd20?
I found the problem and it was on the UEFI side, not with the SeaBIOS
patch.
UEFI was only unlocking the requested 0xef000-0xf region when it
