Re: [SeaBIOS] problem building from Windows using msys

2014-06-02 Thread Scott Duplichan
Kevin O'Connor [mailto:ke...@koconnor.net] wrote: ]On Sun, Jun 01, 2014 at 10:31:39PM -0500, Scott Duplichan wrote: ]> Building SeaBIOS from Windows using mingw has been broken for ]> a long time. The problem is that in this environment, line 100 ]> of the makefile: ]> ]>$(Q)printf '$(foreach

Re: [SeaBIOS] problem building from Windows using msys

2014-06-02 Thread Kevin O'Connor
On Sun, Jun 01, 2014 at 10:31:39PM -0500, Scott Duplichan wrote: > Building SeaBIOS from Windows using mingw has been broken for > a long time. The problem is that in this environment, line 100 > of the makefile: > >$(Q)printf '$(foreach i,$2,#include "$(CURDIR)/$i"\n)' > $3.tmp.c > > creates

Re: [SeaBIOS] [PATCH v4] Update EFI_COMPATIBILITY16_TABLE to match 0.98 spec update

2014-06-02 Thread Kevin O'Connor
On Mon, Jun 02, 2014 at 02:00:14PM +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 rea

Re: [SeaBIOS] [PATCH v3] Update EFI_COMPATIBILITY16_TABLE to match 0.98 spec update

2014-06-02 Thread David Woodhouse
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.UmaAdd

[SeaBIOS] [PATCH v4] Update EFI_COMPATIBILITY16_TABLE to match 0.98 spec update

2014-06-02 Thread David Woodhouse
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 read-only before invoking our Legacy16Boot method. Read-only stack considere