Skip to content

L
linux
Commit db9a0975 authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab
Browse files
Options

docs: ia64: convert to ReST 

Rename the ia64 documentation files to ReST, add an
index for them and adjust in order to produce a nice html
output via the Sphinx build system.

There are two upper case file names. Rename them to
lower case, as we're working to avoid upper case file
names at Documentation.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
parent c3123552
Expand all Show whitespace changes
Inline Side-by-side
Showing with 669 additions and 536 deletions
Documentation/ia64/aliasing.txt → Documentation/ia64/aliasing.rst
View file @ db9a0975
MEMORY ATTRIBUTE ALIASING ON IA-64 ==================================
Memory Attribute Aliasing on IA-64
==================================
Bjorn Helgaas Bjorn Helgaas <bjorn.helgaas@hp.com>
<bjorn.helgaas@hp.com>
May 4, 2006
May 4, 2006
MEMORY ATTRIBUTES
Memory Attributes
=================
Itanium supports several attributes for virtual memory references. Itanium supports several attributes for virtual memory references.
The attribute is part of the virtual translation, i.e., it is The attribute is part of the virtual translation, i.e., it is
contained in the TLB entry. The ones of most interest to the Linux contained in the TLB entry. The ones of most interest to the Linux
kernel are: kernel are:
== ======================
WB Write-back (cacheable) WB Write-back (cacheable)
UC Uncacheable UC Uncacheable
WC Write-coalescing WC Write-coalescing
== ======================
System memory typically uses the WB attribute. The UC attribute is System memory typically uses the WB attribute. The UC attribute is
used for memory-mapped I/O devices. The WC attribute is uncacheable used for memory-mapped I/O devices. The WC attribute is uncacheable
...@@ -29,7 +34,8 @@ MEMORY ATTRIBUTES ...@@ -29,7 +34,8 @@ MEMORY ATTRIBUTES
support either WB or UC access to main memory, while others support support either WB or UC access to main memory, while others support
only WB access. only WB access.
MEMORY MAP Memory Map
==========
Platform firmware describes the physical memory map and the Platform firmware describes the physical memory map and the
supported attributes for each region. At boot-time, the kernel uses supported attributes for each region. At boot-time, the kernel uses
...@@ -55,7 +61,8 @@ MEMORY MAP ...@@ -55,7 +61,8 @@ MEMORY MAP
The efi_memmap table is preserved unmodified because the original The efi_memmap table is preserved unmodified because the original
boot-time information is required for kexec. boot-time information is required for kexec.
KERNEL IDENTITY MAPPINGS Kernel Identify Mappings
========================
Linux/ia64 identity mappings are done with large pages, currently Linux/ia64 identity mappings are done with large pages, currently
either 16MB or 64MB, referred to as "granules." Cacheable mappings either 16MB or 64MB, referred to as "granules." Cacheable mappings
...@@ -74,17 +81,20 @@ KERNEL IDENTITY MAPPINGS ...@@ -74,17 +81,20 @@ KERNEL IDENTITY MAPPINGS
are only partially populated, or populated with a combination of UC are only partially populated, or populated with a combination of UC
and WB regions. and WB regions.
USER MAPPINGS User Mappings
=============
User mappings are typically done with 16K or 64K pages. The smaller User mappings are typically done with 16K or 64K pages. The smaller
page size allows more flexibility because only 16K or 64K has to be page size allows more flexibility because only 16K or 64K has to be
homogeneous with respect to memory attributes. homogeneous with respect to memory attributes.
POTENTIAL ATTRIBUTE ALIASING CASES Potential Attribute Aliasing Cases
==================================
There are several ways the kernel creates new mappings: There are several ways the kernel creates new mappings:
mmap of /dev/mem mmap of /dev/mem
----------------
This uses remap_pfn_range(), which creates user mappings. These This uses remap_pfn_range(), which creates user mappings. These
mappings may be either WB or UC. If the region being mapped mappings may be either WB or UC. If the region being mapped
...@@ -98,7 +108,8 @@ POTENTIAL ATTRIBUTE ALIASING CASES ...@@ -98,7 +108,8 @@ POTENTIAL ATTRIBUTE ALIASING CASES
Since the EFI memory map does not describe MMIO on some Since the EFI memory map does not describe MMIO on some
machines, this should use an uncacheable mapping as a fallback. machines, this should use an uncacheable mapping as a fallback.
mmap of /sys/class/pci_bus/.../legacy_mem mmap of /sys/class/pci_bus/.../legacy_mem
-----------------------------------------
This is very similar to mmap of /dev/mem, except that legacy_mem This is very similar to mmap of /dev/mem, except that legacy_mem
only allows mmap of the one megabyte "legacy MMIO" area for a only allows mmap of the one megabyte "legacy MMIO" area for a
...@@ -112,7 +123,8 @@ POTENTIAL ATTRIBUTE ALIASING CASES ...@@ -112,7 +123,8 @@ POTENTIAL ATTRIBUTE ALIASING CASES
The /dev/mem mmap constraints apply. The /dev/mem mmap constraints apply.
mmap of /proc/bus/pci/.../??.? mmap of /proc/bus/pci/.../??.?
------------------------------
This is an MMIO mmap of PCI functions, which additionally may or This is an MMIO mmap of PCI functions, which additionally may or
may not be requested as using the WC attribute. may not be requested as using the WC attribute.
...@@ -124,7 +136,8 @@ POTENTIAL ATTRIBUTE ALIASING CASES ...@@ -124,7 +136,8 @@ POTENTIAL ATTRIBUTE ALIASING CASES
Otherwise, the user mapping must use the same attribute as the Otherwise, the user mapping must use the same attribute as the
kernel mapping. kernel mapping.
read/write of /dev/mem read/write of /dev/mem
----------------------
This uses copy_from_user(), which implicitly uses a kernel This uses copy_from_user(), which implicitly uses a kernel
identity mapping. This is obviously safe for things in identity mapping. This is obviously safe for things in
...@@ -138,7 +151,8 @@ POTENTIAL ATTRIBUTE ALIASING CASES ...@@ -138,7 +151,8 @@ POTENTIAL ATTRIBUTE ALIASING CASES
eight-byte accesses, and the copy_from_user() path doesn't allow eight-byte accesses, and the copy_from_user() path doesn't allow
any control over the access size, so this would be dangerous. any control over the access size, so this would be dangerous.
ioremap() ioremap()
---------
This returns a mapping for use inside the kernel. This returns a mapping for use inside the kernel.
...@@ -155,9 +169,11 @@ POTENTIAL ATTRIBUTE ALIASING CASES ...@@ -155,9 +169,11 @@ POTENTIAL ATTRIBUTE ALIASING CASES
Failing all of the above, we have to fall back to a UC mapping. Failing all of the above, we have to fall back to a UC mapping.
PAST PROBLEM CASES Past Problem Cases
==================
mmap of various MMIO regions from /dev/mem by "X" on Intel platforms mmap of various MMIO regions from /dev/mem by "X" on Intel platforms
--------------------------------------------------------------------
The EFI memory map may not report these MMIO regions. The EFI memory map may not report these MMIO regions.
...@@ -166,12 +182,16 @@ PAST PROBLEM CASES ...@@ -166,12 +182,16 @@ PAST PROBLEM CASES
succeed. It may create either WB or UC user mappings, depending succeed. It may create either WB or UC user mappings, depending
on whether the region is in kern_memmap or the EFI memory map. on whether the region is in kern_memmap or the EFI memory map.
mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
----------------------------------------------------------------------
The EFI memory map reports the following attributes: The EFI memory map reports the following attributes:
=============== ======= ==================
0x00000-0x9FFFF WB only 0x00000-0x9FFFF WB only
0xA0000-0xBFFFF UC only (VGA frame buffer) 0xA0000-0xBFFFF UC only (VGA frame buffer)
0xC0000-0xFFFFF WB only 0xC0000-0xFFFFF WB only
=============== ======= ==================
This mmap is done with user pages, not kernel identity mappings, This mmap is done with user pages, not kernel identity mappings,
so it is safe to use WB mappings. so it is safe to use WB mappings.
...@@ -182,7 +202,8 @@ PAST PROBLEM CASES ...@@ -182,7 +202,8 @@ PAST PROBLEM CASES
never generate an uncacheable reference to the WB-only areas unless never generate an uncacheable reference to the WB-only areas unless
the driver explicitly touches them. the driver explicitly touches them.
mmap of 0x0-0xFFFFF legacy_mem by "X" mmap of 0x0-0xFFFFF legacy_mem by "X"
-------------------------------------
If the EFI memory map reports that the entire range supports the If the EFI memory map reports that the entire range supports the
same attributes, we can allow the mmap (and we will prefer WB if same attributes, we can allow the mmap (and we will prefer WB if
...@@ -197,15 +218,18 @@ PAST PROBLEM CASES ...@@ -197,15 +218,18 @@ PAST PROBLEM CASES
that doesn't report the VGA frame buffer at all), we should fail the that doesn't report the VGA frame buffer at all), we should fail the
mmap and force the user to map just the specific region of interest. mmap and force the user to map just the specific region of interest.
mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled
------------------------------------------------------------------------
The EFI memory map reports the following attributes::
The EFI memory map reports the following attributes:
0x00000-0xFFFFF WB only (no VGA MMIO hole) 0x00000-0xFFFFF WB only (no VGA MMIO hole)
This is a special case of the previous case, and the mmap should This is a special case of the previous case, and the mmap should
fail for the same reason as above. fail for the same reason as above.
read of /sys/devices/.../rom read of /sys/devices/.../rom
----------------------------
For VGA devices, this may cause an ioremap() of 0xC0000. This For VGA devices, this may cause an ioremap() of 0xC0000. This
used to be done with a UC mapping, because the VGA frame buffer used to be done with a UC mapping, because the VGA frame buffer
...@@ -215,7 +239,8 @@ PAST PROBLEM CASES ...@@ -215,7 +239,8 @@ PAST PROBLEM CASES
We should use WB page table mappings to avoid covering the VGA We should use WB page table mappings to avoid covering the VGA
frame buffer. frame buffer.
NOTES Notes
=====
[1] SDM rev 2.2, vol 2, sec 4.4.1. [1] SDM rev 2.2, vol 2, sec 4.4.1.
[2] SDM rev 2.2, vol 2, sec 4.4.6. [2] SDM rev 2.2, vol 2, sec 4.4.6.
Documentation/ia64/efirtc.txt → Documentation/ia64/efirtc.rst
View file @ db9a0975
==========================
EFI Real Time Clock driver EFI Real Time Clock driver
------------------------------- ==========================
S. Eranian <eranian@hpl.hp.com> S. Eranian <eranian@hpl.hp.com>
March 2000 March 2000
I/ Introduction 1. Introduction
===============
This document describes the efirtc.c driver has provided for This document describes the efirtc.c driver has provided for
the IA-64 platform. the IA-64 platform.
...@@ -16,7 +20,8 @@ SetTime(), GetWakeupTime(), SetWakeupTime() which are all supported by this ...@@ -16,7 +20,8 @@ SetTime(), GetWakeupTime(), SetWakeupTime() which are all supported by this
driver. We describe those calls as well the design of the driver in the driver. We describe those calls as well the design of the driver in the
following sections. following sections.
II/ Design Decisions 2. Design Decisions
===================
The original ideas was to provide a very simple driver to get access to, The original ideas was to provide a very simple driver to get access to,
at first, the time of day service. This is required in order to access, in a at first, the time of day service. This is required in order to access, in a
...@@ -50,19 +55,24 @@ we have created the include/linux/rtc.h header file to contain only the ...@@ -50,19 +55,24 @@ we have created the include/linux/rtc.h header file to contain only the
in include/linux/mc146818rtc.h. in include/linux/mc146818rtc.h.
III/ Time of day service 3. Time of day service
======================
The part of the driver gives access to the time of day service of EFI. The part of the driver gives access to the time of day service of EFI.
Two ioctl()s, compatible with the legacy RTC calls: Two ioctl()s, compatible with the legacy RTC calls:
Read the CMOS clock: ioctl(d, RTC_RD_TIME, &rtc); Read the CMOS clock::
ioctl(d, RTC_RD_TIME, &rtc);
Write the CMOS clock::
Write the CMOS clock: ioctl(d, RTC_SET_TIME, &rtc); ioctl(d, RTC_SET_TIME, &rtc);
The rtc is a pointer to a data structure defined in rtc.h which is close The rtc is a pointer to a data structure defined in rtc.h which is close
to a struct tm: to a struct tm::
struct rtc_time { struct rtc_time {
int tm_sec; int tm_sec;
int tm_min; int tm_min;
int tm_hour; int tm_hour;
...@@ -72,23 +82,26 @@ struct rtc_time { ...@@ -72,23 +82,26 @@ struct rtc_time {
int tm_wday; int tm_wday;
int tm_yday; int tm_yday;
int tm_isdst; int tm_isdst;
}; };
The driver takes care of converting back an forth between the EFI time and The driver takes care of converting back an forth between the EFI time and
this format. this format.
Those two ioctl()s can be exercised with the hwclock command: Those two ioctl()s can be exercised with the hwclock command:
For reading: For reading::
# /sbin/hwclock --show
Mon Mar 6 15:32:32 2000 -0.910248 seconds
For setting: # /sbin/hwclock --show
# /sbin/hwclock --systohc Mon Mar 6 15:32:32 2000 -0.910248 seconds
For setting::
# /sbin/hwclock --systohc
Root privileges are required to be able to set the time of day. Root privileges are required to be able to set the time of day.
IV/ Wakeup Alarm service 4. Wakeup Alarm service
=======================
EFI provides an API by which one can program when a machine should wakeup, EFI provides an API by which one can program when a machine should wakeup,
i.e. reboot. This is very different from the alarm provided by the legacy i.e. reboot. This is very different from the alarm provided by the legacy
...@@ -98,22 +111,24 @@ introduced 2 news ioctl()s to the interface of an RTC. ...@@ -98,22 +111,24 @@ introduced 2 news ioctl()s to the interface of an RTC.
We have added 2 new ioctl()s that are specific to the EFI driver: We have added 2 new ioctl()s that are specific to the EFI driver:
Read the current state of the alarm Read the current state of the alarm::
ioctl(d, RTC_WKLAM_RD, &wkt) ioctl(d, RTC_WKLAM_RD, &wkt)
Set the alarm or change its status Set the alarm or change its status::
ioctl(d, RTC_WKALM_SET, &wkt) ioctl(d, RTC_WKALM_SET, &wkt)
The wkt structure encapsulates a struct rtc_time + 2 extra fields to get The wkt structure encapsulates a struct rtc_time + 2 extra fields to get
status information: status information::
struct rtc_wkalrm { struct rtc_wkalrm {
unsigned char enabled; /* =1 if alarm is enabled */ unsigned char enabled; /* =1 if alarm is enabled */
unsigned char pending; /* =1 if alarm is pending */ unsigned char pending; /* =1 if alarm is pending */
struct rtc_time time; struct rtc_time time;
} }
As of today, none of the existing user-level apps supports this feature. As of today, none of the existing user-level apps supports this feature.
However writing such a program should be hard by simply using those two However writing such a program should be hard by simply using those two
...@@ -121,7 +136,8 @@ ioctl(). ...@@ -121,7 +136,8 @@ ioctl().
Root privileges are required to be able to set the alarm. Root privileges are required to be able to set the alarm.
V/ References. 5. References
=============
Checkout the following Web site for more information on EFI: Checkout the following Web site for more information on EFI:
......
Documentation/ia64/README → Documentation/ia64/ia64.rst
View file @ db9a0975
Linux kernel release 2.4.xx for the IA-64 Platform ===========================================
Linux kernel release for the IA-64 Platform
===========================================
These are the release notes for Linux version 2.4 for IA-64 These are the release notes for Linux since version 2.4 for IA-64
platform. This document provides information specific to IA-64 platform. This document provides information specific to IA-64
ONLY, to get additional information about the Linux kernel also ONLY, to get additional information about the Linux kernel also
read the original Linux README provided with the kernel. read the original Linux README provided with the kernel.
INSTALLING the kernel: Installing the Kernel
=====================
- IA-64 kernel installation is the same as the other platforms, see - IA-64 kernel installation is the same as the other platforms, see
original README for details. original README for details.
SOFTWARE REQUIREMENTS Software Requirements
=====================
Compiling and running this kernel requires an IA-64 compliant GCC Compiling and running this kernel requires an IA-64 compliant GCC
compiler. And various software packages also compiled with an compiler. And various software packages also compiled with an
IA-64 compliant GCC compiler. IA-64 compliant GCC compiler.
CONFIGURING the kernel: Configuring the Kernel
======================
Configuration is the same, see original README for details. Configuration is the same, see original README for details.
COMPILING the kernel: Compiling the Kernel:
- Compiling this kernel doesn't differ from other platform so read - Compiling this kernel doesn't differ from other platform so read
the original README for details BUT make sure you have an IA-64 the original README for details BUT make sure you have an IA-64
compliant GCC compiler. compliant GCC compiler.
IA-64 SPECIFICS IA-64 Specifics
===============
- General issues: - General issues:
o Hardly any performance tuning has been done. Obvious targets * Hardly any performance tuning has been done. Obvious targets
include the library routines (IP checksum, etc.). Less include the library routines (IP checksum, etc.). Less
obvious targets include making sure we don't flush the TLB obvious targets include making sure we don't flush the TLB
needlessly, etc. needlessly, etc.
o SMP locks cleanup/optimization * SMP locks cleanup/optimization
o IA32 support. Currently experimental. It mostly works. * IA32 support. Currently experimental. It mostly works.
Documentation/ia64/index.rst 0 → 100644
View file @ db9a0975
:orphan:
==================
IA-64 Architecture
==================
.. toctree::
:maxdepth: 1
ia64
aliasing
efirtc
err_inject
fsys
irq-redir
mca
serial
xen
Documentation/ia64/IRQ-redir.txt → Documentation/ia64/irq-redir.rst
View file @ db9a0975
==============================
IRQ affinity on IA64 platforms IRQ affinity on IA64 platforms
------------------------------ ==============================
07.01.2002, Erich Focht <efocht@ess.nec.de>
07.01.2002, Erich Focht <efocht@ess.nec.de>
By writing to /proc/irq/IRQ#/smp_affinity the interrupt routing can be By writing to /proc/irq/IRQ#/smp_affinity the interrupt routing can be
...@@ -12,22 +14,27 @@ IRQ target is one particular CPU and cannot be a mask of several ...@@ -12,22 +14,27 @@ IRQ target is one particular CPU and cannot be a mask of several
CPUs. Only the first non-zero bit is taken into account. CPUs. Only the first non-zero bit is taken into account.
Usage examples: Usage examples
==============
The target CPU has to be specified as a hexadecimal CPU mask. The The target CPU has to be specified as a hexadecimal CPU mask. The
first non-zero bit is the selected CPU. This format has been kept for first non-zero bit is the selected CPU. This format has been kept for
compatibility reasons with i386. compatibility reasons with i386.
Set the delivery mode of interrupt 41 to fixed and route the Set the delivery mode of interrupt 41 to fixed and route the
interrupts to CPU #3 (logical CPU number) (2^3=0x08): interrupts to CPU #3 (logical CPU number) (2^3=0x08)::
echo "8" >/proc/irq/41/smp_affinity echo "8" >/proc/irq/41/smp_affinity
Set the default route for IRQ number 41 to CPU 6 in lowest priority Set the default route for IRQ number 41 to CPU 6 in lowest priority
delivery mode (redirectable): delivery mode (redirectable)::
echo "r 40" >/proc/irq/41/smp_affinity echo "r 40" >/proc/irq/41/smp_affinity
The output of the command The output of the command::
cat /proc/irq/IRQ#/smp_affinity cat /proc/irq/IRQ#/smp_affinity
gives the target CPU mask for the specified interrupt vector. If the CPU gives the target CPU mask for the specified interrupt vector. If the CPU
mask is preceded by the character "r", the interrupt is redirectable mask is preceded by the character "r", the interrupt is redirectable
(i.e. lowest priority mode routing is used), otherwise its route is (i.e. lowest priority mode routing is used), otherwise its route is
...@@ -35,7 +42,8 @@ fixed. ...@@ -35,7 +42,8 @@ fixed.
Initialization and default behavior: Initialization and default behavior
===================================
If the platform features IRQ redirection (info provided by SAL) all If the platform features IRQ redirection (info provided by SAL) all
IO-SAPIC interrupts are initialized with CPU#0 as their default target IO-SAPIC interrupts are initialized with CPU#0 as their default target
...@@ -43,9 +51,11 @@ and the routing is the so called "lowest priority mode" (actually ...@@ -43,9 +51,11 @@ and the routing is the so called "lowest priority mode" (actually
fixed SAPIC mode with hint). The XTP chipset registers are used as hints fixed SAPIC mode with hint). The XTP chipset registers are used as hints
for the IRQ routing. Currently in Linux XTP registers can have three for the IRQ routing. Currently in Linux XTP registers can have three
values: values:
- minimal for an idle task, - minimal for an idle task,
- normal if any other task runs, - normal if any other task runs,
- maximal if the CPU is going to be switched off. - maximal if the CPU is going to be switched off.
The IRQ is routed to the CPU with lowest XTP register value, the The IRQ is routed to the CPU with lowest XTP register value, the
search begins at the default CPU. Therefore most of the interrupts search begins at the default CPU. Therefore most of the interrupts
will be handled by CPU #0. will be handled by CPU #0.
...@@ -53,12 +63,14 @@ will be handled by CPU #0. ...@@ -53,12 +63,14 @@ will be handled by CPU #0.
If the platform doesn't feature interrupt redirection IOSAPIC fixed If the platform doesn't feature interrupt redirection IOSAPIC fixed
routing is used. The target CPUs are distributed in a round robin routing is used. The target CPUs are distributed in a round robin
manner. IRQs will be routed only to the selected target CPUs. Check manner. IRQs will be routed only to the selected target CPUs. Check
with with::
cat /proc/interrupts cat /proc/interrupts
Comments: Comments
========
On large (multi-node) systems it is recommended to route the IRQs to On large (multi-node) systems it is recommended to route the IRQs to
the node to which the corresponding device is connected. the node to which the corresponding device is connected.
...@@ -66,4 +78,3 @@ For systems like the NEC AzusA we get IRQ node-affinity for free. This ...@@ -66,4 +78,3 @@ For systems like the NEC AzusA we get IRQ node-affinity for free. This
is because usually the chipsets on each node redirect the interrupts is because usually the chipsets on each node redirect the interrupts
only to their own CPUs (as they cannot see the XTP registers on the only to their own CPUs (as they cannot see the XTP registers on the
other nodes). other nodes).
Documentation/ia64/mca.txt → Documentation/ia64/mca.rst
View file @ db9a0975
An ad-hoc collection of notes on IA64 MCA and INIT processing. Feel =============================================================
free to update it with notes about any area that is not clear. An ad-hoc collection of notes on IA64 MCA and INIT processing
=============================================================
Feel free to update it with notes about any area that is not clear.
--- ---
...@@ -82,7 +85,8 @@ if we have a choice here. ...@@ -82,7 +85,8 @@ if we have a choice here.
own stack as running on that cpu. Then a recursive error gets a own stack as running on that cpu. Then a recursive error gets a
trace of the failing handler's "task". trace of the failing handler's "task".
[1] My (Keith Owens) original design called for ia64 to separate its [1]
My (Keith Owens) original design called for ia64 to separate its
struct task and the kernel stacks. Then the MCA/INIT data would be struct task and the kernel stacks. Then the MCA/INIT data would be
chained stacks like i386 interrupt stacks. But that required chained stacks like i386 interrupt stacks. But that required
radical surgery on the rest of ia64, plus extra hard wired TLB radical surgery on the rest of ia64, plus extra hard wired TLB
......
Documentation/ia64/serial.txt → Documentation/ia64/serial.rst
View file @ db9a0975
SERIAL DEVICE NAMING ==============
Serial Devices
==============
Serial Device Naming
====================
As of 2.6.10, serial devices on ia64 are named based on the As of 2.6.10, serial devices on ia64 are named based on the
order of ACPI and PCI enumeration. The first device in the order of ACPI and PCI enumeration. The first device in the
...@@ -30,17 +35,21 @@ SERIAL DEVICE NAMING ...@@ -30,17 +35,21 @@ SERIAL DEVICE NAMING
(described in the ACPI namespace) plus an MP[2] (a PCI device) has (described in the ACPI namespace) plus an MP[2] (a PCI device) has
these ports: these ports:
pre-2.6.10 pre-2.6.10 ========== ========== ============ ============ =======
MMIO (EFI console (EFI console Type MMIO pre-2.6.10 pre-2.6.10 2.6.10+
address on builtin) on MP port) 2.6.10 address
========== ========== ========== ====== (EFI console (EFI console
on builtin) on MP port)
========== ========== ============ ============ =======
builtin 0xff5e0000 ttyS0 ttyS1 ttyS0 builtin 0xff5e0000 ttyS0 ttyS1 ttyS0
MP UPS 0xf8031000 ttyS1 ttyS2 ttyS1 MP UPS 0xf8031000 ttyS1 ttyS2 ttyS1
MP Console 0xf8030000 ttyS2 ttyS0 ttyS2 MP Console 0xf8030000 ttyS2 ttyS0 ttyS2
MP 2 0xf8030010 ttyS3 ttyS3 ttyS3 MP 2 0xf8030010 ttyS3 ttyS3 ttyS3
MP 3 0xf8030038 ttyS4 ttyS4 ttyS4 MP 3 0xf8030038 ttyS4 ttyS4 ttyS4
========== ========== ============ ============ =======
CONSOLE SELECTION Console Selection
=================
EFI knows what your console devices are, but it doesn't tell the EFI knows what your console devices are, but it doesn't tell the
kernel quite enough to actually locate them. The DIG64 HCDP kernel quite enough to actually locate them. The DIG64 HCDP
...@@ -67,7 +76,8 @@ CONSOLE SELECTION ...@@ -67,7 +76,8 @@ CONSOLE SELECTION
entries in /etc/inittab (for getty) and /etc/securetty (to allow entries in /etc/inittab (for getty) and /etc/securetty (to allow
root login). root login).
EARLY SERIAL CONSOLE Early Serial Console
====================
The kernel can't start using a serial console until it knows where The kernel can't start using a serial console until it knows where
the device lives. Normally this happens when the driver enumerates the device lives. Normally this happens when the driver enumerates
...@@ -80,7 +90,8 @@ EARLY SERIAL CONSOLE ...@@ -80,7 +90,8 @@ EARLY SERIAL CONSOLE
or if the EFI console path contains only a UART device and the or if the EFI console path contains only a UART device and the
firmware supplies an HCDP. firmware supplies an HCDP.
TROUBLESHOOTING SERIAL CONSOLE PROBLEMS Troubleshooting Serial Console Problems
=======================================
No kernel output after elilo prints "Uncompressing Linux... done": No kernel output after elilo prints "Uncompressing Linux... done":
...@@ -133,19 +144,22 @@ TROUBLESHOOTING SERIAL CONSOLE PROBLEMS ...@@ -133,19 +144,22 @@ TROUBLESHOOTING SERIAL CONSOLE PROBLEMS
[1] http://www.dig64.org/specifications/agreement [1]
http://www.dig64.org/specifications/agreement
The table was originally defined as the "HCDP" for "Headless The table was originally defined as the "HCDP" for "Headless
Console/Debug Port." The current version is the "PCDP" for Console/Debug Port." The current version is the "PCDP" for
"Primary Console and Debug Port Devices." "Primary Console and Debug Port Devices."
[2] The HP MP (management processor) is a PCI device that provides [2]
The HP MP (management processor) is a PCI device that provides
several UARTs. One of the UARTs is often used as a console; the several UARTs. One of the UARTs is often used as a console; the
EFI Boot Manager identifies it as "Acpi(HWP0002,700)/Pci(...)/Uart". EFI Boot Manager identifies it as "Acpi(HWP0002,700)/Pci(...)/Uart".
The external connection is usually a 25-pin connector, and a The external connection is usually a 25-pin connector, and a
special dongle converts that to three 9-pin connectors, one of special dongle converts that to three 9-pin connectors, one of
which is labelled "Console." which is labelled "Console."
[3] EFI console devices are configured using the EFI Boot Manager [3]
EFI console devices are configured using the EFI Boot Manager
"Boot option maintenance" menu. You may have to interrupt the "Boot option maintenance" menu. You may have to interrupt the
boot sequence to use this menu, and you will have to reset the boot sequence to use this menu, and you will have to reset the
box after changing console configuration. box after changing console configuration.
Documentation/ia64/xen.rst 0 → 100644
View file @ db9a0975
********************************************************
Recipe for getting/building/running Xen/ia64 with pv_ops
********************************************************
This recipe describes how to get xen-ia64 source and build it,
and run domU with pv_ops.
Requirements
============
- python
- mercurial
it (aka "hg") is an open-source source code
management software. See the below.
http://www.selenic.com/mercurial/wiki/
- git
- bridge-utils
Getting and Building Xen and Dom0
=================================
My environment is:
- Machine : Tiger4
- Domain0 OS : RHEL5
- DomainU OS : RHEL5
1. Download source::
# hg clone http://xenbits.xensource.com/ext/ia64/xen-unstable.hg
# cd xen-unstable.hg
# hg clone http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg
2. # make world
3. # make install-tools
4. copy kernels and xen::
# cp xen/xen.gz /boot/efi/efi/redhat/
# cp build-linux-2.6.18-xen_ia64/vmlinux.gz \
/boot/efi/efi/redhat/vmlinuz-2.6.18.8-xen
5. make initrd for Dom0/DomU::
# make -C linux-2.6.18-xen.hg ARCH=ia64 modules_install \
O=$(pwd)/build-linux-2.6.18-xen_ia64
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.18.8-xen.img \
2.6.18.8-xen --builtin mptspi --builtin mptbase \
--builtin mptscsih --builtin uhci-hcd --builtin ohci-hcd \
--builtin ehci-hcd
Making a disk image for guest OS
================================
1. make file::
# dd if=/dev/zero of=/root/rhel5.img bs=1M seek=4096 count=0
# mke2fs -F -j /root/rhel5.img
# mount -o loop /root/rhel5.img /mnt
# cp -ax /{dev,var,etc,usr,bin,sbin,lib} /mnt
# mkdir /mnt/{root,proc,sys,home,tmp}
Note: You may miss some device files. If so, please create them
with mknod. Or you can use tar instead of cp.
2. modify DomU's fstab::
# vi /mnt/etc/fstab
/dev/xvda1 / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
3. modify inittab
set runlevel to 3 to avoid X trying to start::
# vi /mnt/etc/inittab
id:3:initdefault:
Start a getty on the hvc0 console::
X0:2345:respawn:/sbin/mingetty hvc0
tty1-6 mingetty can be commented out
4. add hvc0 into /etc/securetty::
# vi /mnt/etc/securetty (add hvc0)
5. umount::
# umount /mnt
FYI, virt-manager can also make a disk image for guest OS.
It's GUI tools and easy to make it.
Boot Xen & Domain0
==================
1. replace elilo
elilo of RHEL5 can boot Xen and Dom0.
If you use old elilo (e.g RHEL4), please download from the below
http://elilo.sourceforge.net/cgi-bin/blosxom
and copy into /boot/efi/efi/redhat/::
# cp elilo-3.6-ia64.efi /boot/efi/efi/redhat/elilo.efi
2. modify elilo.conf (like the below)::
# vi /boot/efi/efi/redhat/elilo.conf
prompt
timeout=20
default=xen
relocatable
image=vmlinuz-2.6.18.8-xen
label=xen
vmm=xen.gz
initrd=initrd-2.6.18.8-xen.img
read-only
append=" -- rhgb root=/dev/sda2"
The append options before "--" are for xen hypervisor,
the options after "--" are for dom0.
FYI, your machine may need console options like
"com1=19200,8n1 console=vga,com1". For example,
append="com1=19200,8n1 console=vga,com1 -- rhgb console=tty0 \
console=ttyS0 root=/dev/sda2"
Getting and Building domU with pv_ops
=====================================
1. get pv_ops tree::
# git clone http://people.valinux.co.jp/~yamahata/xen-ia64/linux-2.6-xen-ia64.git/
2. git branch (if necessary)::
# cd linux-2.6-xen-ia64/
# git checkout -b your_branch origin/xen-ia64-domu-minimal-2008may19
Note:
The current branch is xen-ia64-domu-minimal-2008may19.
But you would find the new branch. You can see with
"git branch -r" to get the branch lists.
http://people.valinux.co.jp/~yamahata/xen-ia64/for_eagl/linux-2.6-ia64-pv-ops.git/
is also available.
The tree is based on
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 test)
3. copy .config for pv_ops of domU::
# cp arch/ia64/configs/xen_domu_wip_defconfig .config
4. make kernel with pv_ops::
# make oldconfig
# make
5. install the kernel and initrd::
# cp vmlinux.gz /boot/efi/efi/redhat/vmlinuz-2.6-pv_ops-xenU
# make modules_install
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6-pv_ops-xenU.img \
2.6.26-rc3xen-ia64-08941-g1b12161 --builtin mptspi \
--builtin mptbase --builtin mptscsih --builtin uhci-hcd \
--builtin ohci-hcd --builtin ehci-hcd
Boot DomainU with pv_ops
========================
1. make config of DomU::
# vi /etc/xen/rhel5
kernel = "/boot/efi/efi/redhat/vmlinuz-2.6-pv_ops-xenU"
ramdisk = "/boot/efi/efi/redhat/initrd-2.6-pv_ops-xenU.img"
vcpus = 1
memory = 512
name = "rhel5"
disk = [ 'file:/root/rhel5.img,xvda1,w' ]
root = "/dev/xvda1 ro"
extra= "rhgb console=hvc0"
2. After boot xen and dom0, start xend::
# /etc/init.d/xend start
( In the debugging case, `# XEND_DEBUG=1 xend trace_start` )
3. start domU::
# xm create -c rhel5
Reference
=========
- Wiki of Xen/IA64 upstream merge
http://wiki.xensource.com/xenwiki/XenIA64/UpstreamMerge
Written by Akio Takebe <takebe_akio@jp.fujitsu.com> on 28 May 2008
Documentation/ia64/xen.txt deleted 100644 → 0
View file @ c3123552
Recipe for getting/building/running Xen/ia64 with pv_ops
--------------------------------------------------------
This recipe describes how to get xen-ia64 source and build it,
and run domU with pv_ops.
============
Requirements
============
- python
- mercurial
it (aka "hg") is an open-source source code
management software. See the below.
http://www.selenic.com/mercurial/wiki/
- git
- bridge-utils
=================================
Getting and Building Xen and Dom0
=================================
My environment is;
Machine : Tiger4
Domain0 OS : RHEL5
DomainU OS : RHEL5
1. Download source
# hg clone http://xenbits.xensource.com/ext/ia64/xen-unstable.hg
# cd xen-unstable.hg
# hg clone http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg
2. # make world
3. # make install-tools
4. copy kernels and xen
# cp xen/xen.gz /boot/efi/efi/redhat/
# cp build-linux-2.6.18-xen_ia64/vmlinux.gz \
/boot/efi/efi/redhat/vmlinuz-2.6.18.8-xen
5. make initrd for Dom0/DomU
# make -C linux-2.6.18-xen.hg ARCH=ia64 modules_install \
O=$(pwd)/build-linux-2.6.18-xen_ia64
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.18.8-xen.img \
2.6.18.8-xen --builtin mptspi --builtin mptbase \
--builtin mptscsih --builtin uhci-hcd --builtin ohci-hcd \
--builtin ehci-hcd
================================
Making a disk image for guest OS
================================
1. make file
# dd if=/dev/zero of=/root/rhel5.img bs=1M seek=4096 count=0
# mke2fs -F -j /root/rhel5.img
# mount -o loop /root/rhel5.img /mnt
# cp -ax /{dev,var,etc,usr,bin,sbin,lib} /mnt
# mkdir /mnt/{root,proc,sys,home,tmp}
Note: You may miss some device files. If so, please create them
with mknod. Or you can use tar instead of cp.
2. modify DomU's fstab
# vi /mnt/etc/fstab
/dev/xvda1 / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
3. modify inittab
set runlevel to 3 to avoid X trying to start
# vi /mnt/etc/inittab
id:3:initdefault:
Start a getty on the hvc0 console
X0:2345:respawn:/sbin/mingetty hvc0
tty1-6 mingetty can be commented out
4. add hvc0 into /etc/securetty
# vi /mnt/etc/securetty (add hvc0)
5. umount
# umount /mnt
FYI, virt-manager can also make a disk image for guest OS.
It's GUI tools and easy to make it.
==================
Boot Xen & Domain0
==================
1. replace elilo
elilo of RHEL5 can boot Xen and Dom0.
If you use old elilo (e.g RHEL4), please download from the below
http://elilo.sourceforge.net/cgi-bin/blosxom
and copy into /boot/efi/efi/redhat/
# cp elilo-3.6-ia64.efi /boot/efi/efi/redhat/elilo.efi
2. modify elilo.conf (like the below)
# vi /boot/efi/efi/redhat/elilo.conf
prompt
timeout=20
default=xen
relocatable
image=vmlinuz-2.6.18.8-xen
label=xen
vmm=xen.gz
initrd=initrd-2.6.18.8-xen.img
read-only
append=" -- rhgb root=/dev/sda2"
The append options before "--" are for xen hypervisor,
the options after "--" are for dom0.
FYI, your machine may need console options like
"com1=19200,8n1 console=vga,com1". For example,
append="com1=19200,8n1 console=vga,com1 -- rhgb console=tty0 \
console=ttyS0 root=/dev/sda2"
=====================================
Getting and Building domU with pv_ops
=====================================
1. get pv_ops tree
# git clone http://people.valinux.co.jp/~yamahata/xen-ia64/linux-2.6-xen-ia64.git/
2. git branch (if necessary)
# cd linux-2.6-xen-ia64/
# git checkout -b your_branch origin/xen-ia64-domu-minimal-2008may19
(Note: The current branch is xen-ia64-domu-minimal-2008may19.
But you would find the new branch. You can see with
"git branch -r" to get the branch lists.
http://people.valinux.co.jp/~yamahata/xen-ia64/for_eagl/linux-2.6-ia64-pv-ops.git/
is also available. The tree is based on
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 test)
3. copy .config for pv_ops of domU
# cp arch/ia64/configs/xen_domu_wip_defconfig .config
4. make kernel with pv_ops
# make oldconfig
# make
5. install the kernel and initrd
# cp vmlinux.gz /boot/efi/efi/redhat/vmlinuz-2.6-pv_ops-xenU
# make modules_install
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6-pv_ops-xenU.img \
2.6.26-rc3xen-ia64-08941-g1b12161 --builtin mptspi \
--builtin mptbase --builtin mptscsih --builtin uhci-hcd \
--builtin ohci-hcd --builtin ehci-hcd
========================
Boot DomainU with pv_ops
========================
1. make config of DomU
# vi /etc/xen/rhel5
kernel = "/boot/efi/efi/redhat/vmlinuz-2.6-pv_ops-xenU"
ramdisk = "/boot/efi/efi/redhat/initrd-2.6-pv_ops-xenU.img"
vcpus = 1
memory = 512
name = "rhel5"
disk = [ 'file:/root/rhel5.img,xvda1,w' ]
root = "/dev/xvda1 ro"
extra= "rhgb console=hvc0"
2. After boot xen and dom0, start xend
# /etc/init.d/xend start
( In the debugging case, # XEND_DEBUG=1 xend trace_start )
3. start domU
# xm create -c rhel5
=========
Reference
=========
- Wiki of Xen/IA64 upstream merge
http://wiki.xensource.com/xenwiki/XenIA64/UpstreamMerge
Written by Akio Takebe <takebe_akio@jp.fujitsu.com> on 28 May 2008
MAINTAINERS
View file @ db9a0975
...@@ -14389,7 +14389,7 @@ SGI SN-IA64 (Altix) SERIAL CONSOLE DRIVER ...@@ -14389,7 +14389,7 @@ SGI SN-IA64 (Altix) SERIAL CONSOLE DRIVER
M: Pat Gefre <pfg@sgi.com> M: Pat Gefre <pfg@sgi.com>
L: linux-ia64@vger.kernel.org L: linux-ia64@vger.kernel.org
S: Supported S: Supported
F: Documentation/ia64/serial.txt F: Documentation/ia64/serial.rst
F: drivers/tty/serial/ioc?_serial.c F: drivers/tty/serial/ioc?_serial.c
F: include/linux/ioc?.h F: include/linux/ioc?.h
......
arch/ia64/kernel/efi.c
View file @ db9a0975
...@@ -852,7 +852,7 @@ valid_phys_addr_range (phys_addr_t phys_addr, unsigned long size) ...@@ -852,7 +852,7 @@ valid_phys_addr_range (phys_addr_t phys_addr, unsigned long size)
* /dev/mem reads and writes use copy_to_user(), which implicitly * /dev/mem reads and writes use copy_to_user(), which implicitly
* uses a granule-sized kernel identity mapping. It's really * uses a granule-sized kernel identity mapping. It's really
* only safe to do this for regions in kern_memmap. For more * only safe to do this for regions in kern_memmap. For more
* details, see Documentation/ia64/aliasing.txt. * details, see Documentation/ia64/aliasing.rst.
*/ */
attr = kern_mem_attribute(phys_addr, size); attr = kern_mem_attribute(phys_addr, size);
if (attr & EFI_MEMORY_WB || attr & EFI_MEMORY_UC) if (attr & EFI_MEMORY_WB || attr & EFI_MEMORY_UC)
......
arch/ia64/kernel/fsys.S
View file @ db9a0975
...@@ -28,7 +28,7 @@ ...@@ -28,7 +28,7 @@
#include <asm/native/inst.h> #include <asm/native/inst.h>
/* /*
* See Documentation/ia64/fsys.txt for details on fsyscalls. * See Documentation/ia64/fsys.rst for details on fsyscalls.
* *
* On entry to an fsyscall handler: * On entry to an fsyscall handler:
* r10 = 0 (i.e., defaults to "successful syscall return") * r10 = 0 (i.e., defaults to "successful syscall return")
......
arch/ia64/mm/ioremap.c
View file @ db9a0975
...@@ -42,7 +42,7 @@ ioremap (unsigned long phys_addr, unsigned long size) ...@@ -42,7 +42,7 @@ ioremap (unsigned long phys_addr, unsigned long size)
/* /*
* For things in kern_memmap, we must use the same attribute * For things in kern_memmap, we must use the same attribute
* as the rest of the kernel. For more details, see * as the rest of the kernel. For more details, see
* Documentation/ia64/aliasing.txt. * Documentation/ia64/aliasing.rst.
*/ */
attr = kern_mem_attribute(phys_addr, size); attr = kern_mem_attribute(phys_addr, size);
if (attr & EFI_MEMORY_WB) if (attr & EFI_MEMORY_WB)
......
arch/ia64/pci/pci.c
View file @ db9a0975
...@@ -450,7 +450,7 @@ pci_mmap_legacy_page_range(struct pci_bus *bus, struct vm_area_struct *vma, ...@@ -450,7 +450,7 @@ pci_mmap_legacy_page_range(struct pci_bus *bus, struct vm_area_struct *vma,
return -ENOSYS; return -ENOSYS;
/* /*
* Avoid attribute aliasing. See Documentation/ia64/aliasing.txt * Avoid attribute aliasing. See Documentation/ia64/aliasing.rst
* for more details. * for more details.
*/ */
if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size)) if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size))
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7