Commit Graph

10 Commits

Author SHA1 Message Date
jhb
465469fc74 Consolidate duplicate definitions of V86_CY() and V86_ZR() which check for
the carry and zero flags being set, respectively, in <btxv86.h> and use
them throughout the x86 boot code.
2011-10-25 19:45:12 +00:00
jkim
e8cee11d8d A simple rewrite of biossmap.c:
- Do not iterate int 15h, function e820h twice.  Instead, we use STAILQ to
store each return buffer and copy all at once.
- Export optional extended attributes defined in ACPI 3.0 as separate
metadata.  Currently, there are only two bits defined in the specification.
For example, if the descriptor has extended attributes and it is not
enabled, it has to be ignored by OS.  We may implement it in the kernel
later if it is necessary and proven correct in reality.
- Check return buffer size strictly as suggested in ACPI 3.0.

Reviewed by:	jhb
2009-04-15 17:31:22 +00:00
jhb
0c94928735 Workaround a bug in the BIOS of Dell R900 machines. Specifically, each
entry in the SMAP is a 20 byte structure and they are queried from the
BIOS via sucessive BIOS calls.  Due to an apparent bug in the R900's
BIOS, for some SMAP requests the BIOS overflows the 20 byte buffer
trashing a few bytes of memory immediately after the SMAP structure.  As
a workaround, add 8 bytes of padding after the SMAP structure used in
the loader for SMAP queries.

PR:		i386/122668
Submitted by:	Mike Hibler  mike flux.utah.edu, silby
MFC after:	3 days
2008-06-07 03:07:32 +00:00
jhb
ae8e7ec2a3 - Add constants for the different memory types in the SMAP table.
- Use the SMAP types and constants from <machine/pc/bios.h> in the boot
  code rather than duplicating it.
2007-10-28 21:23:49 +00:00
jhb
4a28927c3c Oops, add return values for the smap command function. We must have the
warnings set weird or something because gcc didn't warn about this at all.

Submitted by:	ru
2006-09-29 20:07:16 +00:00
jhb
7a85c13bc9 Add an 'smap' command that dumps out the BIOS SMAP.
MFC after:	1 week
2006-09-28 19:07:13 +00:00
sobomax
85788ffcca Long-long time ago, when the trees were large and memory expensive amount of
memory directly available to loader(8) and friends was limited to 640K on i386.
Those times have passed long time ago and now loader(8) can directly access
up to 4GB of RAM at least theoretically. At the same time, there are several
places where it's assumed that malloc() will only allocate memory within
first megabyte.

Remove that assumption by allocating appropriate bounce buffers for BIOS
calls on stack where necessary.

This allows using memory above first megabyte for heap if necessary.
2005-12-19 09:00:11 +00:00
peter
19ec3de6fc Remove a pre-tier-1 kernel compatability helper. This means a 6.x loader
won't boot a pre-5.1 development amd64 kernel.  That's no big loss though.
2004-11-08 23:59:44 +00:00
obrien
2b8c9f2e64 Use __FBSDID().
Also some minor copyright style cleanups.
2003-08-25 23:28:32 +00:00
peter
fb5fbfc750 Enable the i386 loader to load and run an amd64 kernel. If this puts
things over floppy size limits, I can exclude it for release builds or
something like that.  Most of the changes are to get the load_elf.c file
into a seperate elf32_ or elf64_ namespace so that you can have two
ELF loaders present at once.  Note that for 64 bit kernels, it actually
starts up the kernel already in 64 bit mode with paging enabled.  This
is really easy because we have a known minimum feature set.

Of note is that for amd64, we have to pass in the bios int 15 0xe821
memory map because once in long mode, you absolutely cannot make VM86
calls.  amd64 does not use 'struct bootinfo' at all.  It is a pure loader
metadata startup, just like sparc64 and powerpc.  Much of the
infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00