Il 31/05/2014 18:18, Kevin O'Connor ha scritto:
Change the multi-processor init code to trampoline into 32bit mode on
each of the additional processors. Implement an atomic lock so that
each processor performs its initialization serially.
Signed-off-by: Kevin O'Connor ke...@koconnor.net
---
On Mon, Jun 02, 2014 at 05:27:23PM -0500, Scott Duplichan wrote:
Kevin O'Connor [mailto:ke...@koconnor.net] wrote:
]Unfortunately, this would break builds where one specifies an OUT
]build directory that isn't a sub-directory of the source code. (That
]is, a build with make OUT=/a/b/c.)
]
This is a gratuitous GCC-ism. For C code actually compiled with GCC we
should be using -m16 where it's available (GCC 4.9+).
And where the only thing marked with .code16gcc is explicit assembler
code, we should just use .code16 and avoid letting the compiler make any
of the assumptions that the
GCC 4.9 and clang 3.5 support the -m16 option on the command line which
supersedes the hackish .code16gcc assembler directive. Use it where
possible.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
There's no need to use .code16gcc where we are writing assembler code
explicitly. It only affects word-size-ambiguous instructions, and we
should just be explicit. And we are.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/romlayout.S | 14 +++---
1 file changed, 7
There's no need to use .code16gcc where we are writing assembler code
explicitly. It only affects word-size-ambiguous instructions, and we
should just be explicit. And we are.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
vgasrc/vgaentry.S | 2 +-
1 file changed, 1 insertion(+),
There's no need to use .code16gcc where we are writing assembler code
explicitly. It only affects word-size-ambiguous instructions, and we
should just be explicit. And we are.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/fw/smm.c | 4 ++--
1 file changed, 2 insertions(+), 2
The build currently does a textual include of all files in order to
use the -fwhole-compile optimization. Update it to use relative file
paths instead of absolute file paths. This makes the section names in
the resulting binary more readable. It also makes the build easier on
some Windows
On Tue, Jun 03, 2014 at 05:25:57PM +0100, David Woodhouse wrote:
This is a gratuitous GCC-ism. For C code actually compiled with GCC we
should be using -m16 where it's available (GCC 4.9+).
And where the only thing marked with .code16gcc is explicit assembler
code, we should just use .code16
