david/ipxe
david
/
ipxe
Archived
1
0
Fork 0
Commit Graph

8 Commits

Author SHA1 Message Date
Michael Brown 356f6c1b64 [acpi] Expose ACPI tables via settings mechanism
Allow values to be read from ACPI tables using the syntax

  ${acpi/<signature>.<index>.0.<offset>.<length>}

where <signature> is the ACPI table signature as a 32-bit hexadecimal
number (e.g. 0x41504093 for the 'APIC' signature on the MADT), <index>
is the index into the array of tables matching this signature,
<offset> is the byte offset within the table, and <length> is the
field length in bytes.

Numeric values are returned in reverse byte order, since ACPI numeric
values are usually little-endian.

For example:

  ${acpi/0x41504943.0.0.0.0}           - entire MADT table in raw hex
  ${acpi/0x41504943.0.0.0x0a.6:string} - MADT table OEM ID
  ${acpi/0x41504943.0.0.0x24.4:uint32} - local APIC address

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2017-05-23 18:48:06 +01:00
Michael Brown a25a16d4ad [vram] Add "vram" built-in setting to dump video RAM
The "vram" setting returns the (Base64-encoded) contents of video RAM,
and can be used to capture a screenshot.  For example: after running
memtest.0 and encountering an error, the output can be captured and
sent to a remote server for later diagnosis:

  #!ipxe
  chain -a http://server/memtest.0 && goto ok || goto bad
  :bad
  params
  param errno ${errno}
  param vram ${vram}
  chain -a http://server/report.php##params
  :ok

Inspired-by: Christian Nilsson <nikize@gmail.com>
Originally-implemented-by: Christian Nilsson <nikize@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-04-24 16:27:47 +01:00
Michael Brown b6ee89ffb5 [legal] Relicense files under GPL2_OR_LATER_OR_UBDL
Relicense files for which I am the sole author (as identified by
util/relicense.pl).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-03-02 14:17:31 +00:00
Michael Brown c801cb29d6 [build] Allow for named configurations at build time
Allow named configurations to be specified via the CONFIG=... build
parameter.  For headers in config/*.h which support named
configurations, the following files will be included when building
with CONFIG=<name>:

  - config/defaults/<platform>.h (e.g. config/defaults/pcbios.h)

  - config/<header>.h

  - config/<name>/<header>.h (only if the directory config/<name> exists)

  - config/local/<header>.h (autocreated if necessary)

  - config/local/<name>/<header>.h (autocreated if necessary)

This mechanism allows for predefined named configurations to be
checked in to the source tree, as a directory config/<name> containing
all of the required header files.

The mechanism also allows for users to define multiple local
configurations, by creating header files in the directory
config/local/<name>.

Note that the config/*.h files which are used only to configure
internal iPXE APIs (e.g. config/ioapi.h) cannot be modified via a
named configuration.  This avoids rebuilding the entire iPXE codebase
whenever switching to a different named configuration.

Inspired-by: Robin Smidsrød <robin@smidsrod.no>
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-20 12:36:44 +01:00
Michael Brown c692a690da [settings] Expose memory map via settings mechanism
Allow memory map entries to be read using the syntax

  ${memmap/<region>.<properties>.<scale>}

where <region> is the index of the memory region, <properties> is a
bitmask where bit 0 represents the start address and bit 1 represents
the length (allowing the end address to be encoded by having both bits
0 and 1 set), and <scale> is the number of bits by which to shift the
result.

This allows for several values of interest to be encoded.  For
example:

  ${memmap/<region>.1.0:hexraw}   # 64-bit start address of <region>
  ${memmap/<region>.2.0:hexraw}   # 64-bit length of <region>, in bytes
  ${memmap/<region>.3.0:hexraw}   # 64-bit end address of <region>
  ${memmap/<region>.2.10:int32}   # Length of <region>, in kB
  ${memmap/<region>.2.20:int32}   # Length of <region>, in MB

The numeric encoding is slightly more sophisticated than described
here, allowing a single encoding to cover multiple regions.  (See the
source code for details.)  The primary use case for this feature is to
provide the total system memory size (in MB) via the "memsize"
predefined setting.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-08-12 22:00:36 +01:00
Michael Brown 55201e2d0e [settings] Expose CPUID instruction via settings mechanism
Allow CPUID values to be read using the syntax

  ${cpuid/<register>.<function>}

For example, ${cpuid/2.0x80000001} will give the value of %ecx after
calling CPUID with %eax=0x80000001.  Values for <register> are encoded
as %eax=0, %ebx=1, %ecx=2, %edx=3.

The numeric encoding is more sophisticated than described above,
allowing for settings such as the CPU model (obtained by calling CPUID
with %eax=0x80000002-0x80000004 inclusive and concatenating the values
returned in %eax:%ebx:%ecx:%edx).  See the source code for details.

The "cpuvendor" and "cpumodel" settings provide easy access to these
more complex CPUID settings.

This functionality is intended to complement the "cpuid" command,
which allows for testing individual CPUID feature bits.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-08-07 12:06:28 +01:00
Michael Brown dbfa13ff2c [settings] Expose PCI configuration space via settings mechanism
Allow values to be read from PCI configuration space using the syntax

  ${pci/<busdevfn>.<offset>.<length>}

where <busdevfn> is the bus:dev.fn address of the PCI device
(expressed as a single integer, as returned by ${net0/busloc}),
<offset> is the offset within PCI configuration space, and <length> is
the length within PCI configuration space.

Values are returned in reverse byte order, since PCI configuration
space is little-endian by definition.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-07-13 12:46:18 +02:00
Michael Brown 258195242b [settings] Add config/settings.h
Move VMWARE_SETTINGS build configuration option from config/sideband.h
to a new config/settings.h.

Existing instances of config/local/sideband.h will not be affected,
since config.c still #includes config/sideband.h.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-07-13 12:44:48 +02:00