On Feb 1, 2013, at 7:44 AM, David Woodhouse wrote:
> On Fri, 2013-02-01 at 03:57 -0800, Andrew Fish wrote:
>>
>> Kevin,
>>
>> This was all a long time ago, and my memory is fuzzy on things
>> 16-bits
>>
>> It looks like generic CSM code locks the 0xC - 0xF region
>> prior to boot
On Fri, 2013-02-01 at 03:57 -0800, Andrew Fish wrote:
>
> Kevin,
>
> This was all a long time ago, and my memory is fuzzy on things
> 16-bits
>
> It looks like generic CSM code locks the 0xC - 0xF region
> prior to boot, and I seem to remember that this was the common
> practice at
On Jan 29, 2013, at 1:45 PM, Kevin OConnor wrote:
> I'm a bit surprised that OVMF would mark all of the 0xc-0xf
> area as read-only. There are lots of old programs that want to use
> parts of that area as memory.
Kevin,
This was all a long time ago, and my memory is fuzzy on things 16
On Sat, Jan 26, 2013 at 3:12 PM, Jordan Justen wrote:
> On Sun, Jan 20, 2013 at 3:42 PM, David Woodhouse
> wrote:
> > The main issue I have on the OVMF side is that it locks the entire
> > memory region from 0xC-0xF to be read-only, right before
> > invoking the Legacy16Boot method. This
On Tue, 2013-01-29 at 16:45 -0500, Kevin OConnor wrote:
>
> I'm a bit surprised that OVMF would mark all of the 0xc-0xf
> area as read-only. There are lots of old programs that want to use
> parts of that area as memory.
Well, there are EDK2-based machines out there in the field which ar
On Sat, 2013-01-26 at 12:12 -0800, Jordan Justen wrote:
>
> Is this still an issue? If so, why not use EBDA?
Kevin seemed very reluctant when this was suggested. We *have* RAM at
0xE-0xF that is perfectly usable if we handle things correctly.
> I think it is extremely unlikely that EFI_C
On Sun, Jan 20, 2013 at 3:42 PM, David Woodhouse wrote:
> The main issue I have on the OVMF side is that it locks the entire
> memory region from 0xC-0xF to be read-only, right before
> invoking the Legacy16Boot method. This upsets SeaBIOS, which puts a
> stack in the E segment for use
On Mon, 2013-01-21 at 17:53 +0100, Paolo Bonzini wrote:
> You are in control of the EFI_LEGACY_REGION_PROTOCOL implementation
> though. If SeaBIOS needs 0xE-0xF to be always writable, just
> make a Lock of that region a no-op...
We could do that, but it seems wrong to me. The LegacyRegion
Il 21/01/2013 00:42, David Woodhouse ha scritto:
> The main issue I have on the OVMF side is that it locks the entire
> memory region from 0xC-0xF to be read-only, right before
> invoking the Legacy16Boot method. This upsets SeaBIOS, which puts a
> stack in the E segment for use during
Hi,
> The implementation of this would be horrid, and it's made even more
> horrid by the fact that it would then have to do the platform-specific
> unlocking in its Legacy16Boot method, before re-enabling the normal
> stack-swapping code. And the CSM isn't really supposed to do that kind
> of p
On Sun, 2013-01-20 at 20:36 -0600, David Woodhouse wrote:
> Here's a slightly more concrete version of that proposal:
The implementation may look something like this:
diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBoot
On Sun, 2013-01-20 at 17:42 -0600, David Woodhouse wrote:
> It would be nice if there was a field in the EFI_COMPATIBILITY16_TABLE
> which let the CSM code indicate how much it wants locked. Then we could
> lock just the option roms and the bit that the CSM asks us to lock,
> while leaving RAM in b
I've made some progress on using SeaBIOS as a CSM, to the point where
I've got it successfully booting Linux and Windows. There's plenty more
to do to make it work *right*, and some of what I have done needs
cleaning up, but it's a good start.
The main issue I have on the OVMF side is that it lock
13 matches
Mail list logo
