aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/ia64
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/ia64')
-rw-r--r--Documentation/ia64/IRQ-redir.txt69
-rw-r--r--Documentation/ia64/README43
-rw-r--r--Documentation/ia64/efirtc.txt128
-rw-r--r--Documentation/ia64/fsys.txt286
-rw-r--r--Documentation/ia64/serial.txt144
5 files changed, 670 insertions, 0 deletions
diff --git a/Documentation/ia64/IRQ-redir.txt b/Documentation/ia64/IRQ-redir.txt
new file mode 100644
index 000000000000..f7bd72261283
--- /dev/null
+++ b/Documentation/ia64/IRQ-redir.txt
@@ -0,0 +1,69 @@
1IRQ affinity on IA64 platforms
2------------------------------
3 07.01.2002, Erich Focht <efocht@ess.nec.de>
4
5
6By writing to /proc/irq/IRQ#/smp_affinity the interrupt routing can be
7controlled. The behavior on IA64 platforms is slightly different from
8that described in Documentation/IRQ-affinity.txt for i386 systems.
9
10Because of the usage of SAPIC mode and physical destination mode the
11IRQ target is one particular CPU and cannot be a mask of several
12CPUs. Only the first non-zero bit is taken into account.
13
14
15Usage examples:
16
17The target CPU has to be specified as a hexadecimal CPU mask. The
18first non-zero bit is the selected CPU. This format has been kept for
19compatibility reasons with i386.
20
21Set the delivery mode of interrupt 41 to fixed and route the
22interrupts to CPU #3 (logical CPU number) (2^3=0x08):
23 echo "8" >/proc/irq/41/smp_affinity
24
25Set the default route for IRQ number 41 to CPU 6 in lowest priority
26delivery mode (redirectable):
27 echo "r 40" >/proc/irq/41/smp_affinity
28
29The output of the command
30 cat /proc/irq/IRQ#/smp_affinity
31gives the target CPU mask for the specified interrupt vector. If the CPU
32mask is preceded by the character "r", the interrupt is redirectable
33(i.e. lowest priority mode routing is used), otherwise its route is
34fixed.
35
36
37
38Initialization and default behavior:
39
40If the platform features IRQ redirection (info provided by SAL) all
41IO-SAPIC interrupts are initialized with CPU#0 as their default target
42and the routing is the so called "lowest priority mode" (actually
43fixed SAPIC mode with hint). The XTP chipset registers are used as hints
44for the IRQ routing. Currently in Linux XTP registers can have three
45values:
46 - minimal for an idle task,
47 - normal if any other task runs,
48 - maximal if the CPU is going to be switched off.
49The IRQ is routed to the CPU with lowest XTP register value, the
50search begins at the default CPU. Therefore most of the interrupts
51will be handled by CPU #0.
52
53If the platform doesn't feature interrupt redirection IOSAPIC fixed
54routing is used. The target CPUs are distributed in a round robin
55manner. IRQs will be routed only to the selected target CPUs. Check
56with
57 cat /proc/interrupts
58
59
60
61Comments:
62
63On large (multi-node) systems it is recommended to route the IRQs to
64the node to which the corresponding device is connected.
65For systems like the NEC AzusA we get IRQ node-affinity for free. This
66is because usually the chipsets on each node redirect the interrupts
67only to their own CPUs (as they cannot see the XTP registers on the
68other nodes).
69
diff --git a/Documentation/ia64/README b/Documentation/ia64/README
new file mode 100644
index 000000000000..aa17f2154cba
--- /dev/null
+++ b/Documentation/ia64/README
@@ -0,0 +1,43 @@
1 Linux kernel release 2.4.xx for the IA-64 Platform
2
3 These are the release notes for Linux version 2.4 for IA-64
4 platform. This document provides information specific to IA-64
5 ONLY, to get additional information about the Linux kernel also
6 read the original Linux README provided with the kernel.
7
8INSTALLING the kernel:
9
10 - IA-64 kernel installation is the same as the other platforms, see
11 original README for details.
12
13
14SOFTWARE REQUIREMENTS
15
16 Compiling and running this kernel requires an IA-64 compliant GCC
17 compiler. And various software packages also compiled with an
18 IA-64 compliant GCC compiler.
19
20
21CONFIGURING the kernel:
22
23 Configuration is the same, see original README for details.
24
25
26COMPILING the kernel:
27
28 - Compiling this kernel doesn't differ from other platform so read
29 the original README for details BUT make sure you have an IA-64
30 compliant GCC compiler.
31
32IA-64 SPECIFICS
33
34 - General issues:
35
36 o Hardly any performance tuning has been done. Obvious targets
37 include the library routines (IP checksum, etc.). Less
38 obvious targets include making sure we don't flush the TLB
39 needlessly, etc.
40
41 o SMP locks cleanup/optimization
42
43 o IA32 support. Currently experimental. It mostly works.
diff --git a/Documentation/ia64/efirtc.txt b/Documentation/ia64/efirtc.txt
new file mode 100644
index 000000000000..ede2c1e51cd7
--- /dev/null
+++ b/Documentation/ia64/efirtc.txt
@@ -0,0 +1,128 @@
1EFI Real Time Clock driver
2-------------------------------
3S. Eranian <eranian@hpl.hp.com>
4March 2000
5
6I/ Introduction
7
8This document describes the efirtc.c driver has provided for
9the IA-64 platform.
10
11The purpose of this driver is to supply an API for kernel and user applications
12to get access to the Time Service offered by EFI version 0.92.
13
14EFI provides 4 calls one can make once the OS is booted: GetTime(),
15SetTime(), GetWakeupTime(), SetWakeupTime() which are all supported by this
16driver. We describe those calls as well the design of the driver in the
17following sections.
18
19II/ Design Decisions
20
21The original ideas was to provide a very simple driver to get access to,
22at first, the time of day service. This is required in order to access, in a
23portable way, the CMOS clock. A program like /sbin/hwclock uses such a clock
24to initialize the system view of the time during boot.
25
26Because we wanted to minimize the impact on existing user-level apps using
27the CMOS clock, we decided to expose an API that was very similar to the one
28used today with the legacy RTC driver (driver/char/rtc.c). However, because
29EFI provides a simpler services, not all all ioctl() are available. Also
30new ioctl()s have been introduced for things that EFI provides but not the
31legacy.
32
33EFI uses a slightly different way of representing the time, noticeably
34the reference date is different. Year is the using the full 4-digit format.
35The Epoch is January 1st 1998. For backward compatibility reasons we don't
36expose this new way of representing time. Instead we use something very
37similar to the struct tm, i.e. struct rtc_time, as used by hwclock.
38One of the reasons for doing it this way is to allow for EFI to still evolve
39without necessarily impacting any of the user applications. The decoupling
40enables flexibility and permits writing wrapper code is ncase things change.
41
42The driver exposes two interfaces, one via the device file and a set of
43ioctl()s. The other is read-only via the /proc filesystem.
44
45As of today we don't offer a /proc/sys interface.
46
47To allow for a uniform interface between the legacy RTC and EFI time service,
48we have created the include/linux/rtc.h header file to contain only the
49"public" API of the two drivers. The specifics of the legacy RTC are still
50in include/linux/mc146818rtc.h.
51
52
53III/ Time of day service
54
55The part of the driver gives access to the time of day service of EFI.
56Two ioctl()s, compatible with the legacy RTC calls:
57
58 Read the CMOS clock: ioctl(d, RTC_RD_TIME, &rtc);
59
60 Write the CMOS clock: ioctl(d, RTC_SET_TIME, &rtc);
61
62The rtc is a pointer to a data structure defined in rtc.h which is close
63to a struct tm:
64
65struct rtc_time {
66 int tm_sec;
67 int tm_min;
68 int tm_hour;
69 int tm_mday;
70 int tm_mon;
71 int tm_year;
72 int tm_wday;
73 int tm_yday;
74 int tm_isdst;
75};
76
77The driver takes care of converting back an forth between the EFI time and
78this format.
79
80Those two ioctl()s can be exercised with the hwclock command:
81
82For reading:
83# /sbin/hwclock --show
84Mon Mar 6 15:32:32 2000 -0.910248 seconds
85
86For setting:
87# /sbin/hwclock --systohc
88
89Root privileges are required to be able to set the time of day.
90
91IV/ Wakeup Alarm service
92
93EFI provides an API by which one can program when a machine should wakeup,
94i.e. reboot. This is very different from the alarm provided by the legacy
95RTC which is some kind of interval timer alarm. For this reason we don't use
96the same ioctl()s to get access to the service. Instead we have
97introduced 2 news ioctl()s to the interface of an RTC.
98
99We have added 2 new ioctl()s that are specific to the EFI driver:
100
101 Read the current state of the alarm
102 ioctl(d, RTC_WKLAM_RD, &wkt)
103
104 Set the alarm or change its status
105 ioctl(d, RTC_WKALM_SET, &wkt)
106
107The wkt structure encapsulates a struct rtc_time + 2 extra fields to get
108status information:
109
110struct rtc_wkalrm {
111
112 unsigned char enabled; /* =1 if alarm is enabled */
113 unsigned char pending; /* =1 if alarm is pending */
114
115 struct rtc_time time;
116}
117
118As of today, none of the existing user-level apps supports this feature.
119However writing such a program should be hard by simply using those two
120ioctl().
121
122Root privileges are required to be able to set the alarm.
123
124V/ References.
125
126Checkout the following Web site for more information on EFI:
127
128http://developer.intel.com/technology/efi/
diff --git a/Documentation/ia64/fsys.txt b/Documentation/ia64/fsys.txt
new file mode 100644
index 000000000000..28da181f9966
--- /dev/null
+++ b/Documentation/ia64/fsys.txt
@@ -0,0 +1,286 @@
1-*-Mode: outline-*-
2
3 Light-weight System Calls for IA-64
4 -----------------------------------
5
6 Started: 13-Jan-2003
7 Last update: 27-Sep-2003
8
9 David Mosberger-Tang
10 <davidm@hpl.hp.com>
11
12Using the "epc" instruction effectively introduces a new mode of
13execution to the ia64 linux kernel. We call this mode the
14"fsys-mode". To recap, the normal states of execution are:
15
16 - kernel mode:
17 Both the register stack and the memory stack have been
18 switched over to kernel memory. The user-level state is saved
19 in a pt-regs structure at the top of the kernel memory stack.
20
21 - user mode:
22 Both the register stack and the kernel stack are in
23 user memory. The user-level state is contained in the
24 CPU registers.
25
26 - bank 0 interruption-handling mode:
27 This is the non-interruptible state which all
28 interruption-handlers start execution in. The user-level
29 state remains in the CPU registers and some kernel state may
30 be stored in bank 0 of registers r16-r31.
31
32In contrast, fsys-mode has the following special properties:
33
34 - execution is at privilege level 0 (most-privileged)
35
36 - CPU registers may contain a mixture of user-level and kernel-level
37 state (it is the responsibility of the kernel to ensure that no
38 security-sensitive kernel-level state is leaked back to
39 user-level)
40
41 - execution is interruptible and preemptible (an fsys-mode handler
42 can disable interrupts and avoid all other interruption-sources
43 to avoid preemption)
44
45 - neither the memory-stack nor the register-stack can be trusted while
46 in fsys-mode (they point to the user-level stacks, which may
47 be invalid, or completely bogus addresses)
48
49In summary, fsys-mode is much more similar to running in user-mode
50than it is to running in kernel-mode. Of course, given that the
51privilege level is at level 0, this means that fsys-mode requires some
52care (see below).
53
54
55* How to tell fsys-mode
56
57Linux operates in fsys-mode when (a) the privilege level is 0 (most
58privileged) and (b) the stacks have NOT been switched to kernel memory
59yet. For convenience, the header file <asm-ia64/ptrace.h> provides
60three macros:
61
62 user_mode(regs)
63 user_stack(task,regs)
64 fsys_mode(task,regs)
65
66The "regs" argument is a pointer to a pt_regs structure. The "task"
67argument is a pointer to the task structure to which the "regs"
68pointer belongs to. user_mode() returns TRUE if the CPU state pointed
69to by "regs" was executing in user mode (privilege level 3).
70user_stack() returns TRUE if the state pointed to by "regs" was
71executing on the user-level stack(s). Finally, fsys_mode() returns
72TRUE if the CPU state pointed to by "regs" was executing in fsys-mode.
73The fsys_mode() macro is equivalent to the expression:
74
75 !user_mode(regs) && user_stack(task,regs)
76
77* How to write an fsyscall handler
78
79The file arch/ia64/kernel/fsys.S contains a table of fsyscall-handlers
80(fsyscall_table). This table contains one entry for each system call.
81By default, a system call is handled by fsys_fallback_syscall(). This
82routine takes care of entering (full) kernel mode and calling the
83normal Linux system call handler. For performance-critical system
84calls, it is possible to write a hand-tuned fsyscall_handler. For
85example, fsys.S contains fsys_getpid(), which is a hand-tuned version
86of the getpid() system call.
87
88The entry and exit-state of an fsyscall handler is as follows:
89
90** Machine state on entry to fsyscall handler:
91
92 - r10 = 0
93 - r11 = saved ar.pfs (a user-level value)
94 - r15 = system call number
95 - r16 = "current" task pointer (in normal kernel-mode, this is in r13)
96 - r32-r39 = system call arguments
97 - b6 = return address (a user-level value)
98 - ar.pfs = previous frame-state (a user-level value)
99 - PSR.be = cleared to zero (i.e., little-endian byte order is in effect)
100 - all other registers may contain values passed in from user-mode
101
102** Required machine state on exit to fsyscall handler:
103
104 - r11 = saved ar.pfs (as passed into the fsyscall handler)
105 - r15 = system call number (as passed into the fsyscall handler)
106 - r32-r39 = system call arguments (as passed into the fsyscall handler)
107 - b6 = return address (as passed into the fsyscall handler)
108 - ar.pfs = previous frame-state (as passed into the fsyscall handler)
109
110Fsyscall handlers can execute with very little overhead, but with that
111speed comes a set of restrictions:
112
113 o Fsyscall-handlers MUST check for any pending work in the flags
114 member of the thread-info structure and if any of the
115 TIF_ALLWORK_MASK flags are set, the handler needs to fall back on
116 doing a full system call (by calling fsys_fallback_syscall).
117
118 o Fsyscall-handlers MUST preserve incoming arguments (r32-r39, r11,
119 r15, b6, and ar.pfs) because they will be needed in case of a
120 system call restart. Of course, all "preserved" registers also
121 must be preserved, in accordance to the normal calling conventions.
122
123 o Fsyscall-handlers MUST check argument registers for containing a
124 NaT value before using them in any way that could trigger a
125 NaT-consumption fault. If a system call argument is found to
126 contain a NaT value, an fsyscall-handler may return immediately
127 with r8=EINVAL, r10=-1.
128
129 o Fsyscall-handlers MUST NOT use the "alloc" instruction or perform
130 any other operation that would trigger mandatory RSE
131 (register-stack engine) traffic.
132
133 o Fsyscall-handlers MUST NOT write to any stacked registers because
134 it is not safe to assume that user-level called a handler with the
135 proper number of arguments.
136
137 o Fsyscall-handlers need to be careful when accessing per-CPU variables:
138 unless proper safe-guards are taken (e.g., interruptions are avoided),
139 execution may be pre-empted and resumed on another CPU at any given
140 time.
141
142 o Fsyscall-handlers must be careful not to leak sensitive kernel'
143 information back to user-level. In particular, before returning to
144 user-level, care needs to be taken to clear any scratch registers
145 that could contain sensitive information (note that the current
146 task pointer is not considered sensitive: it's already exposed
147 through ar.k6).
148
149 o Fsyscall-handlers MUST NOT access user-memory without first
150 validating access-permission (this can be done typically via
151 probe.r.fault and/or probe.w.fault) and without guarding against
152 memory access exceptions (this can be done with the EX() macros
153 defined by asmmacro.h).
154
155The above restrictions may seem draconian, but remember that it's
156possible to trade off some of the restrictions by paying a slightly
157higher overhead. For example, if an fsyscall-handler could benefit
158from the shadow register bank, it could temporarily disable PSR.i and
159PSR.ic, switch to bank 0 (bsw.0) and then use the shadow registers as
160needed. In other words, following the above rules yields extremely
161fast system call execution (while fully preserving system call
162semantics), but there is also a lot of flexibility in handling more
163complicated cases.
164
165* Signal handling
166
167The delivery of (asynchronous) signals must be delayed until fsys-mode
168is exited. This is acomplished with the help of the lower-privilege
169transfer trap: arch/ia64/kernel/process.c:do_notify_resume_user()
170checks whether the interrupted task was in fsys-mode and, if so, sets
171PSR.lp and returns immediately. When fsys-mode is exited via the
172"br.ret" instruction that lowers the privilege level, a trap will
173occur. The trap handler clears PSR.lp again and returns immediately.
174The kernel exit path then checks for and delivers any pending signals.
175
176* PSR Handling
177
178The "epc" instruction doesn't change the contents of PSR at all. This
179is in contrast to a regular interruption, which clears almost all
180bits. Because of that, some care needs to be taken to ensure things
181work as expected. The following discussion describes how each PSR bit
182is handled.
183
184PSR.be Cleared when entering fsys-mode. A srlz.d instruction is used
185 to ensure the CPU is in little-endian mode before the first
186 load/store instruction is executed. PSR.be is normally NOT
187 restored upon return from an fsys-mode handler. In other
188 words, user-level code must not rely on PSR.be being preserved
189 across a system call.
190PSR.up Unchanged.
191PSR.ac Unchanged.
192PSR.mfl Unchanged. Note: fsys-mode handlers must not write-registers!
193PSR.mfh Unchanged. Note: fsys-mode handlers must not write-registers!
194PSR.ic Unchanged. Note: fsys-mode handlers can clear the bit, if needed.
195PSR.i Unchanged. Note: fsys-mode handlers can clear the bit, if needed.
196PSR.pk Unchanged.
197PSR.dt Unchanged.
198PSR.dfl Unchanged. Note: fsys-mode handlers must not write-registers!
199PSR.dfh Unchanged. Note: fsys-mode handlers must not write-registers!
200PSR.sp Unchanged.
201PSR.pp Unchanged.
202PSR.di Unchanged.
203PSR.si Unchanged.
204PSR.db Unchanged. The kernel prevents user-level from setting a hardware
205 breakpoint that triggers at any privilege level other than 3 (user-mode).
206PSR.lp Unchanged.
207PSR.tb Lazy redirect. If a taken-branch trap occurs while in
208 fsys-mode, the trap-handler modifies the saved machine state
209 such that execution resumes in the gate page at
210 syscall_via_break(), with privilege level 3. Note: the
211 taken branch would occur on the branch invoking the
212 fsyscall-handler, at which point, by definition, a syscall
213 restart is still safe. If the system call number is invalid,
214 the fsys-mode handler will return directly to user-level. This
215 return will trigger a taken-branch trap, but since the trap is
216 taken _after_ restoring the privilege level, the CPU has already
217 left fsys-mode, so no special treatment is needed.
218PSR.rt Unchanged.
219PSR.cpl Cleared to 0.
220PSR.is Unchanged (guaranteed to be 0 on entry to the gate page).
221PSR.mc Unchanged.
222PSR.it Unchanged (guaranteed to be 1).
223PSR.id Unchanged. Note: the ia64 linux kernel never sets this bit.
224PSR.da Unchanged. Note: the ia64 linux kernel never sets this bit.
225PSR.dd Unchanged. Note: the ia64 linux kernel never sets this bit.
226PSR.ss Lazy redirect. If set, "epc" will cause a Single Step Trap to
227 be taken. The trap handler then modifies the saved machine
228 state such that execution resumes in the gate page at
229 syscall_via_break(), with privilege level 3.
230PSR.ri Unchanged.
231PSR.ed Unchanged. Note: This bit could only have an effect if an fsys-mode
232 handler performed a speculative load that gets NaTted. If so, this
233 would be the normal & expected behavior, so no special treatment is
234 needed.
235PSR.bn Unchanged. Note: fsys-mode handlers may clear the bit, if needed.
236 Doing so requires clearing PSR.i and PSR.ic as well.
237PSR.ia Unchanged. Note: the ia64 linux kernel never sets this bit.
238
239* Using fast system calls
240
241To use fast system calls, userspace applications need simply call
242__kernel_syscall_via_epc(). For example
243
244-- example fgettimeofday() call --
245-- fgettimeofday.S --
246
247#include <asm/asmmacro.h>
248
249GLOBAL_ENTRY(fgettimeofday)
250.prologue
251.save ar.pfs, r11
252mov r11 = ar.pfs
253.body
254
255mov r2 = 0xa000000000020660;; // gate address
256 // found by inspection of System.map for the
257 // __kernel_syscall_via_epc() function. See
258 // below for how to do this for real.
259
260mov b7 = r2
261mov r15 = 1087 // gettimeofday syscall
262;;
263br.call.sptk.many b6 = b7
264;;
265
266.restore sp
267
268mov ar.pfs = r11
269br.ret.sptk.many rp;; // return to caller
270END(fgettimeofday)
271
272-- end fgettimeofday.S --
273
274In reality, getting the gate address is accomplished by two extra
275values passed via the ELF auxiliary vector (include/asm-ia64/elf.h)
276
277 o AT_SYSINFO : is the address of __kernel_syscall_via_epc()
278 o AT_SYSINFO_EHDR : is the address of the kernel gate ELF DSO
279
280The ELF DSO is a pre-linked library that is mapped in by the kernel at
281the gate page. It is a proper ELF shared object so, with a dynamic
282loader that recognises the library, you should be able to make calls to
283the exported functions within it as with any other shared library.
284AT_SYSINFO points into the kernel DSO at the
285__kernel_syscall_via_epc() function for historical reasons (it was
286used before the kernel DSO) and as a convenience.
diff --git a/Documentation/ia64/serial.txt b/Documentation/ia64/serial.txt
new file mode 100644
index 000000000000..f51eb4bc2ff1
--- /dev/null
+++ b/Documentation/ia64/serial.txt
@@ -0,0 +1,144 @@
1SERIAL DEVICE NAMING
2
3 As of 2.6.10, serial devices on ia64 are named based on the
4 order of ACPI and PCI enumeration. The first device in the
5 ACPI namespace (if any) becomes /dev/ttyS0, the second becomes
6 /dev/ttyS1, etc., and PCI devices are named sequentially
7 starting after the ACPI devices.
8
9 Prior to 2.6.10, there were confusing exceptions to this:
10
11 - Firmware on some machines (mostly from HP) provides an HCDP
12 table[1] that tells the kernel about devices that can be used
13 as a serial console. If the user specified "console=ttyS0"
14 or the EFI ConOut path contained only UART devices, the
15 kernel registered the device described by the HCDP as
16 /dev/ttyS0.
17
18 - If there was no HCDP, we assumed there were UARTs at the
19 legacy COM port addresses (I/O ports 0x3f8 and 0x2f8), so
20 the kernel registered those as /dev/ttyS0 and /dev/ttyS1.
21
22 Any additional ACPI or PCI devices were registered sequentially
23 after /dev/ttyS0 as they were discovered.
24
25 With an HCDP, device names changed depending on EFI configuration
26 and "console=" arguments. Without an HCDP, device names didn't
27 change, but we registered devices that might not really exist.
28
29 For example, an HP rx1600 with a single built-in serial port
30 (described in the ACPI namespace) plus an MP[2] (a PCI device) has
31 these ports:
32
33 pre-2.6.10 pre-2.6.10
34 MMIO (EFI console (EFI console
35 address on builtin) on MP port) 2.6.10
36 ========== ========== ========== ======
37 builtin 0xff5e0000 ttyS0 ttyS1 ttyS0
38 MP UPS 0xf8031000 ttyS1 ttyS2 ttyS1
39 MP Console 0xf8030000 ttyS2 ttyS0 ttyS2
40 MP 2 0xf8030010 ttyS3 ttyS3 ttyS3
41 MP 3 0xf8030038 ttyS4 ttyS4 ttyS4
42
43CONSOLE SELECTION
44
45 EFI knows what your console devices are, but it doesn't tell the
46 kernel quite enough to actually locate them. The DIG64 HCDP
47 table[1] does tell the kernel where potential serial console
48 devices are, but not all firmware supplies it. Also, EFI supports
49 multiple simultaneous consoles and doesn't tell the kernel which
50 should be the "primary" one.
51
52 So how do you tell Linux which console device to use?
53
54 - If your firmware supplies the HCDP, it is simplest to
55 configure EFI with a single device (either a UART or a VGA
56 card) as the console. Then you don't need to tell Linux
57 anything; the kernel will automatically use the EFI console.
58
59 (This works only in 2.6.6 or later; prior to that you had
60 to specify "console=ttyS0" to get a serial console.)
61
62 - Without an HCDP, Linux defaults to a VGA console unless you
63 specify a "console=" argument.
64
65 NOTE: Don't assume that a serial console device will be /dev/ttyS0.
66 It might be ttyS1, ttyS2, etc. Make sure you have the appropriate
67 entries in /etc/inittab (for getty) and /etc/securetty (to allow
68 root login).
69
70EARLY SERIAL CONSOLE
71
72 The kernel can't start using a serial console until it knows where
73 the device lives. Normally this happens when the driver enumerates
74 all the serial devices, which can happen a minute or more after the
75 kernel starts booting.
76
77 2.6.10 and later kernels have an "early uart" driver that works
78 very early in the boot process. The kernel will automatically use
79 this if the user supplies an argument like "console=uart,io,0x3f8",
80 or if the EFI console path contains only a UART device and the
81 firmware supplies an HCDP.
82
83TROUBLESHOOTING SERIAL CONSOLE PROBLEMS
84
85 No kernel output after elilo prints "Uncompressing Linux... done":
86
87 - You specified "console=ttyS0" but Linux changed the device
88 to which ttyS0 refers. Configure exactly one EFI console
89 device[3] and remove the "console=" option.
90
91 - The EFI console path contains both a VGA device and a UART.
92 EFI and elilo use both, but Linux defaults to VGA. Remove
93 the VGA device from the EFI console path[3].
94
95 - Multiple UARTs selected as EFI console devices. EFI and
96 elilo use all selected devices, but Linux uses only one.
97 Make sure only one UART is selected in the EFI console
98 path[3].
99
100 - You're connected to an HP MP port[2] but have a non-MP UART
101 selected as EFI console device. EFI uses the MP as a
102 console device even when it isn't explicitly selected.
103 Either move the console cable to the non-MP UART, or change
104 the EFI console path[3] to the MP UART.
105
106 Long pause (60+ seconds) between "Uncompressing Linux... done" and
107 start of kernel output:
108
109 - No early console because you used "console=ttyS<n>". Remove
110 the "console=" option if your firmware supplies an HCDP.
111
112 - If you don't have an HCDP, the kernel doesn't know where
113 your console lives until the driver discovers serial
114 devices. Use "console=uart, io,0x3f8" (or appropriate
115 address for your machine).
116
117 Kernel and init script output works fine, but no "login:" prompt:
118
119 - Add getty entry to /etc/inittab for console tty. Look for
120 the "Adding console on ttyS<n>" message that tells you which
121 device is the console.
122
123 "login:" prompt, but can't login as root:
124
125 - Add entry to /etc/securetty for console tty.
126
127
128
129[1] http://www.dig64.org/specifications/DIG64_PCDPv20.pdf
130 The table was originally defined as the "HCDP" for "Headless
131 Console/Debug Port." The current version is the "PCDP" for
132 "Primary Console and Debug Port Devices."
133
134[2] The HP MP (management processor) is a PCI device that provides
135 several UARTs. One of the UARTs is often used as a console; the
136 EFI Boot Manager identifies it as "Acpi(HWP0002,700)/Pci(...)/Uart".
137 The external connection is usually a 25-pin connector, and a
138 special dongle converts that to three 9-pin connectors, one of
139 which is labelled "Console."
140
141[3] EFI console devices are configured using the EFI Boot Manager
142 "Boot option maintenance" menu. You may have to interrupt the
143 boot sequence to use this menu, and you will have to reset the
144 box after changing console configuration.
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-26 16:29:51 -0500