diff options
author | Bernhard Walle <bwalle@suse.de> | 2008-06-27 07:12:54 -0400 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2008-07-08 11:55:41 -0400 |
commit | 69ac9cd629ca96e59f34eb4ccd12d00b2c8276a7 (patch) | |
tree | e9bb108c5ec36c666d64a52ca35ccf0197c84306 /Documentation/ABI/testing/sysfs-firmware-memmap | |
parent | 6247943d8ab699b57653afd453a4940cca70ef8a (diff) |
sysfs: add /sys/firmware/memmap
This patch adds /sys/firmware/memmap interface that represents the BIOS
(or Firmware) provided memory map. The tree looks like:
/sys/firmware/memmap/0/start (hex number)
end (hex number)
type (string)
... /1/start
end
type
With the following shell snippet one can print the memory map in the same form
the kernel prints itself when booting on x86 (the E820 map).
--------- 8< --------------------------
#!/bin/sh
cd /sys/firmware/memmap
for dir in * ; do
start=$(cat $dir/start)
end=$(cat $dir/end)
type=$(cat $dir/type)
printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
done
--------- >8 --------------------------
That patch only provides the needed interface:
1. The sysfs interface.
2. The structure and enumeration definition.
3. The function firmware_map_add() and firmware_map_add_early()
that should be called from architecture code (E820/EFI, for
example) to add the contents to the interface.
If the kernel is compiled without CONFIG_FIRMWARE_MEMMAP, the interface does
nothing without cluttering the architecture-specific code with #ifdef's.
The purpose of the new interface is kexec: While /proc/iomem represents
the *used* memory map (e.g. modified via kernel parameters like 'memmap'
and 'mem'), the /sys/firmware/memmap tree represents the unmodified memory
map provided via the firmware. So kexec can:
- use the original memory map for rebooting,
- use the /proc/iomem for setting up the ELF core headers for kdump
case that should only represent the memory of the system.
The patch has been tested on i386 and x86_64.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Acked-by: Greg KH <gregkh@suse.de>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Cc: kexec@lists.infradead.org
Cc: yhlu.kernel@gmail.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'Documentation/ABI/testing/sysfs-firmware-memmap')
-rw-r--r-- | Documentation/ABI/testing/sysfs-firmware-memmap | 71 |
1 files changed, 71 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/sysfs-firmware-memmap b/Documentation/ABI/testing/sysfs-firmware-memmap new file mode 100644 index 000000000000..0d99ee6ae02e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-memmap | |||
@@ -0,0 +1,71 @@ | |||
1 | What: /sys/firmware/memmap/ | ||
2 | Date: June 2008 | ||
3 | Contact: Bernhard Walle <bwalle@suse.de> | ||
4 | Description: | ||
5 | On all platforms, the firmware provides a memory map which the | ||
6 | kernel reads. The resources from that memory map are registered | ||
7 | in the kernel resource tree and exposed to userspace via | ||
8 | /proc/iomem (together with other resources). | ||
9 | |||
10 | However, on most architectures that firmware-provided memory | ||
11 | map is modified afterwards by the kernel itself, either because | ||
12 | the kernel merges that memory map with other information or | ||
13 | just because the user overwrites that memory map via command | ||
14 | line. | ||
15 | |||
16 | kexec needs the raw firmware-provided memory map to setup the | ||
17 | parameter segment of the kernel that should be booted with | ||
18 | kexec. Also, the raw memory map is useful for debugging. For | ||
19 | that reason, /sys/firmware/memmap is an interface that provides | ||
20 | the raw memory map to userspace. | ||
21 | |||
22 | The structure is as follows: Under /sys/firmware/memmap there | ||
23 | are subdirectories with the number of the entry as their name: | ||
24 | |||
25 | /sys/firmware/memmap/0 | ||
26 | /sys/firmware/memmap/1 | ||
27 | /sys/firmware/memmap/2 | ||
28 | /sys/firmware/memmap/3 | ||
29 | ... | ||
30 | |||
31 | The maximum depends on the number of memory map entries provided | ||
32 | by the firmware. The order is just the order that the firmware | ||
33 | provides. | ||
34 | |||
35 | Each directory contains three files: | ||
36 | |||
37 | start : The start address (as hexadecimal number with the | ||
38 | '0x' prefix). | ||
39 | end : The end address, inclusive (regardless whether the | ||
40 | firmware provides inclusive or exclusive ranges). | ||
41 | type : Type of the entry as string. See below for a list of | ||
42 | valid types. | ||
43 | |||
44 | So, for example: | ||
45 | |||
46 | /sys/firmware/memmap/0/start | ||
47 | /sys/firmware/memmap/0/end | ||
48 | /sys/firmware/memmap/0/type | ||
49 | /sys/firmware/memmap/1/start | ||
50 | ... | ||
51 | |||
52 | Currently following types exist: | ||
53 | |||
54 | - System RAM | ||
55 | - ACPI Tables | ||
56 | - ACPI Non-volatile Storage | ||
57 | - reserved | ||
58 | |||
59 | Following shell snippet can be used to display that memory | ||
60 | map in a human-readable format: | ||
61 | |||
62 | -------------------- 8< ---------------------------------------- | ||
63 | #!/bin/bash | ||
64 | cd /sys/firmware/memmap | ||
65 | for dir in * ; do | ||
66 | start=$(cat $dir/start) | ||
67 | end=$(cat $dir/end) | ||
68 | type=$(cat $dir/type) | ||
69 | printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type" | ||
70 | done | ||
71 | -------------------- >8 ---------------------------------------- | ||