2002-10-12 01:07:21

by James Simmons

[permalink] [raw]
Subject: [BK PATCH] console changes 1


This patch fixes some of the missed handle_sysrq functions not updated.
please apply.

You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.

===================================================================


[email protected], 2002-10-08 13:40:24-07:00, [email protected]
Already fixed.


arch/um/kernel/um_arch.c | 2 +-
drivers/tc/zs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)


diff -Nru a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
--- a/arch/um/kernel/um_arch.c Wed Oct 9 08:36:23 2002
+++ b/arch/um/kernel/um_arch.c Wed Oct 9 08:36:23 2002
@@ -337,7 +337,7 @@
void *unused2)
{
#ifdef CONFIG_SYSRQ
- handle_sysrq('p', &current->thread.regs, NULL, NULL);
+ handle_sysrq('p', &current->thread.regs, NULL);
#endif
machine_halt();
return(0);
diff -Nru a/drivers/tc/zs.c b/drivers/tc/zs.c
--- a/drivers/tc/zs.c Wed Oct 9 08:36:23 2002
+++ b/drivers/tc/zs.c Wed Oct 9 08:36:23 2002
@@ -443,7 +443,7 @@
if (break_pressed && info->line == sercons.index) {
if (ch != 0 &&
time_before(jiffies, break_pressed + HZ*5)) {
- handle_sysrq(ch, regs, NULL, NULL);
+ handle_sysrq(ch, regs, NULL);
break_pressed = 0;
goto ignore_char;
}

===================================================================


This BitKeeper patch contains the following changesets:
+
## Wrapped with gzip_uu ##


begin 664 bkpatch7145
M'XL(`/=,I#T``\U674_;,!1]QK_"$H]3DWMM)[$C=2J#:9-8-<3$\V0<0T.3
M!B4I'U-^_)RT?(HVI<"TME*MQ#X^]][C<[U+3RI;QCL759KGQ:PBN_1[4=7Q
M3JYOKFV6>5:7]21+9U-O9FOW]K@HW%M_7I5^51K?N#5%9@=5K4\S2]R$(UV;
M";VR917OH,?OG]2WES;>.?[Z[>3'WC$APR'=G^C9N?UE:SH<DKHHKW265"/M
MMBMF7EWJ697;6GNFR)O[J0T#8.X;8,0A"!L,042-P011"[0),"%#0>["&;T8
MQC,X!)`.D[.P"8142`XH>J%""LQ'\$%2Y+&`F(D!1#$`78]./W$Z`/*%OF](
M^\30O:RT.KFE9^F-33R2]C!YOH?"")6+%QN(%,@MUDL4G`>\X4Q*M=7ZD$F4
M#0\C9.20!C+D`1F_$>?H04ID\,H/(:"!?.XI5E*FK:+]VOA_*L\\*ID`1P,1
M1-`X5AH,!MR&8`+9IY,701=:="D6#:A02,?L(DFG=C35I;Y=D-&EF?CSW)_:
M<F8S-_K=/KECI9!AQ"(A&A8QAHVQG">G@$:*T$V(^EBM17]$3Z`+W=&[;$_W
M^JQ57(%O)KKT35UF[>!Q"J4#Q095%$;-62@2$W&TD53@2KMI"E?NL"#LF';Y
M5$%G/*M";'WHG;/=YT1]Z)W0(6B$0AYVQL2?V!(/8KZI+<&'V=*\+FANRW.;
MM)[097">9][F661MA3B"4U6D6F-8J&O\'F`_Z:"\[G[NM!^M+/X6SM%J:9T"
M6SU]Z/'H4U?_#@\*XUP%T"DL>-[X\!4*PW_3^"HSN4X3>U9-;T>)]=+3?+.4
MNF0*E"(`M@SXK5"!\_ZEM1S2[F_\?HC/I+L.8`OY'C!!\8F(EYVH_SZV53_<
M5*U/0!\$"LJ=YTZ@T?]N@7IZF8^2]-P6*[/5-B8'ZZK=N"%7G7I<OQ]OM7B%
?4)9KMK&VNVN[F5@SK>;YT-74W91`D+\2(U7K,PP`````
`
end



2002-10-12 01:25:43

by Martin J. Bligh

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1

> This patch fixes some of the missed handle_sysrq functions not updated.
> please apply.

Are you going to have early console support (ie printk from before
what is now console_init) done before the freeze, or should I just
submit our version?

Thanks,

Martin.

2002-10-12 01:40:48

by James Simmons

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1


> > This patch fixes some of the missed handle_sysrq functions not updated.
> > please apply.
>
> Are you going to have early console support (ie printk from before
> what is now console_init) done before the freeze, or should I just
> submit our version?

Depends on how fast Linus takes my patches. In the end vty_init will
initialize display drivers that need a other resource that are avaliable
latter (i.e pci handling, irqs) and the other drivers will be called by
vt_console_init. vt_console_init can be called much earlier than now. In
fact I will soon remove the need to call bootmem. I plan to removal all
the console related stuff from the arch directories!!! It can be done with
some work. I done it for the ix86 platform. The need for a dummy console
will also go away.

2002-10-12 01:41:16

by Anton Blanchard

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1


> Are you going to have early console support (ie printk from before
> what is now console_init) done before the freeze, or should I just
> submit our version?

On ppc64 Im currently setting a console up very early in arch init code
and using the CONFIG_EARLY_PRINTK hook to disable it at console_init
time. Works OK for me, do you guys need something on top of that?

Anton

2002-10-12 02:59:43

by Martin J. Bligh

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1

>> Are you going to have early console support (ie printk from before
>> what is now console_init) done before the freeze, or should I just
>> submit our version?
>
> On ppc64 Im currently setting a console up very early in arch init code
> and using the CONFIG_EARLY_PRINTK hook to disable it at console_init
> time. Works OK for me, do you guys need something on top of that?

Attatched is what I use when it all goes to hell in a handbasket.

Works for me ... I'd love to see it more generally available, so
we didn't get bug reports saying "it says 'booting linux', then
nothing". I'm not desperately attatched to any one implementation,
as long as it works from really, really early on. The fact that
everyone and his dog (including me once, badly) has reimplemented
this suggests it's very useful, and should go into mainline.

Patch by Bill Irwin and Keith Mannthey. Inlined so you can read it,
attached as well, cause my mail-reader on this PC seems to be eating
things at the moment for some reason. This version supports standard
PC VGA consoles, and serial consoles (essential for remote work),
but should be easy to hook in other interfaces.

Probably needs some cleanup. If people would take a cleaned up version,
I'll clean it up, or get someone to do it ;-)

M.

diff -urN linux-2.5.25/arch/i386/Config.help linux-2.5.25-early/arch/i386/Config.help
--- linux-2.5.25/arch/i386/Config.help 2002-07-05 16:42:04.000000000 -0700
+++ linux-2.5.25-early/arch/i386/Config.help 2002-07-16 13:11:21.000000000 -0700
@@ -941,6 +941,25 @@
Say Y here if you want to reduce the chances of the tree compiling,
and are prepared to dig into driver internals to fix compile errors.

+
+NO_CONFIG_EARLY_CONSOLE
+ If you are not doing early kernel devolopment NONE is what you want.
+ The other will add a early console for you (in i386)
+ This will allow you see printk output before console_init is called.
+ This is handy if you need to debug the kernel before this point.
+
+ VGA will give you a VGA console, your screen.
+
SERIAL will give you out put on your serial line.
+ Location of serial port
+ CONFIG_EARLY_CONSOLE_SERIAL_PORT
+ 0x3F8 == COMM 1
+ 0x3E8 == COMM 2
+
+CONFIG_EARLY_CONSOLE_SERIAL_BAUD
+ Set the the Baud of your serial console.
+
+
+
Software Suspend
CONFIG_SOFTWARE_SUSPEND
Enable the possibilty of suspendig machine. It doesn't need APM.
diff -urN linux-2.5.25/arch/i386/config.in linux-2.5.25-early/arch/i386/config.in
--- linux-2.5.25/arch/i386/config.in 2002-07-25 10:23:53.000000000 -0700
+++ linux-2.5.25-early/arch/i386/config.in 2002-07-16 13:11:21.000000000 -0700
@@ -424,6 +424,16 @@
bool ' Spinlock debugging' CONFIG_DEBUG_SPINLOCK
if [ "$CONFIG_HIGHMEM" = "y" ]; then
bool ' Highmem debugging' CONFIG_DEBUG_HIGHMEM
+
choice 'Early printk support' \
+ "NONE NO_CONFIG_EARLY_CONSOLE \
+ VGA CONFIG_EARLY_CONSOLE_VGA \
+ Serial_PORT CONFIG_EARLY_CONSOLE_SERIAL\
+ Bochs_0xE9_hack CONFIG_EARLY_CONSOLE_BOCHS_E9_HACK " NONE
+ if [ "$CONFIG_EARLY_CONSOLE_SERIAL" = "y" ]; then
+ hex "Location of serial port " CONFIG_EARLY_CONSOLE_SERIAL_PORT 0x3F8
+ int "Baud rate " CONFIG_EARLY_CONSOLE_SERIAL_BAUD 38400
+ fi
+
fi
fi

diff -urN linux-2.5.25/arch/i386/kernel/Makefile linux-2.5.25-early/arch/i386/kernel/Makefile
--- linux-2.5.25/arch/i386/kernel/Makefile 2002-07-05 16:42:14.000000000 -0700
+++ linux-2.5.25-early/arch/i386/kernel/Makefile 2002-07-16
13:11:21.000000000 -0700
@@ -11,7 +11,7 @@
obj-y := process.o semaphore.o signal.o entry.o traps.o irq.o vm86.o \
ptrace.o i8259.o ioport.o ldt.o setup.o time.o sys_i386.o \
pci-dma.o i386_ksyms.o i387.o bluesmoke.o dmi_scan.o \
- bootflag.o
+ bootflag.o early_consoles.o

obj-y += cpu/
obj-$(CONFIG_MCA) += mca.o
diff -urN linux-2.5.25/arch/i386/kernel/early_consoles.c linux-2.5.25-early/arch/i386/kernel/early_consoles.c
--- linux-2.5.25/arch/i386/kernel/early_consoles.c 1969-12-31 16:00:00.000000000 -0800
+++ linux-2.5.25-early/arch/i386/kernel/early_consoles.c 2002-07-16 13:19:34.000000000 -0700
@@ -0,0 +1,418 @@
+/*
+ * Early console drivers.
+ * (C) Nov 2001, William Irwin, IBM
+ *
+ * These are low-level pseudodrivers to enable
early console output
+ * to aid in debugging during early boot.
+ *
+ * They are crude, but hopefully effective. They rely on the fact
+ * that consoles are largely unused prior to the true console_init(),
+ * and that printk() uses the ->write callback and that callback
+ * only during its operation.
+ *
+ * Serial port routines are derived from Linux serial.c, and
+ * vga_putc() is derived from vsta, (C) Andrew Valencia.
+ */
+
+#include <linux/kernel.h>
+#include <linux/console.h>
+#include <linux/serial_reg.h>
+#include <asm/io.h>
+
+/*
+ * I/O ports are not linearly mapped on all architectures.
+ * On IA64 in particular, port I/O is just reading/writing from
+ * an uncached address, but ioremap there requires ia64_io_base
+ * to be initialized,
which does not happen until the middle of
+ * setup_arch(). So a port remapping macro is provided here.
+ *
+ * The IA64 case is not handled here, although the port remapping
+ * is demonstrated for the purposes of understanding its necessity.
+ * The IO_BASE is taken from Lion systems; in general, this varies.
+ * True handling for IA64 will be merged in given testing.
+ */
+
+#ifdef CONFIG_IA64
+
+#define IO_BASE 0xC0000FFFFC000000UL
+#define MK_PORT(port) ((char *)(IO_BASE|(((port)>>2)<<12)|((port) & 0xFFF)))
+
+#else
+
+/*
+ * This works for i386, but not everywhere.
+ * Other architectures with port I/O mapping needs will need to
+ * add to the preprocessor case analysis above.
+ */
+
+#define MK_PORT(port) (port)
+
+#endif
+
+#define
BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
+
+
+/*
+ * This serial output driver derived from the one appearing
+ * in serial.c
+ *
+ * It is a simple "bitbanging" style output routine, with
+ * initialization performed at every call.
+ */
+
+#ifdef CONFIG_EARLY_CONSOLE_SERIAL
+#define MAX_BAUD 115200
+#define BAUD_MSB (MAX_BAUD/CONFIG_EARLY_CONSOLE_SERIAL_BAUD)/0xFF
+#define BAUD_LSB (MAX_BAUD/CONFIG_EARLY_CONSOLE_SERIAL_BAUD)%0xFF
+
+
+static inline void wait_for_readiness(unsigned port)
+{
+ unsigned retries;
+ unsigned char status;
+
+ /*
+ * Wait for transmitter holding and shift registers to empty,
+ * which is required for output to succeed. If the retries are
+ * exceeded, this deliberately fails to ensure termination.
+ */
+ for(retries
= 0; retries < 65536; ++retries) {
+ status = inb(MK_PORT(port + 5));
+ if((status & BOTH_EMPTY) == BOTH_EMPTY)
+ break;
+ }
+}
+
+static int serial_init = 0;
+
+static void init_serial_io_port(unsigned port)
+{
+ serial_init = 1;
+
+ wait_for_readiness(port);
+
+ /*
+ * Disable interrupts.
+ */
+ outb(0x0, MK_PORT(port + 1));
+
+ /*
+ * Set the baud rate divisor's LSB.
+ */
+ outb(BAUD_MSB, MK_PORT(port + 3));
+
+ /*
+ * Set the baud rate divisor's MSB.
+ */
+ outb(BAUD_LSB, MK_PORT(port));
+
+ /*
+ * Set no parity, 8 bits, 1 stop bit, and select
+ * interrupt enable register.
+ */
+ outb(0x3, MK_PORT(port + 3));
+}
+

+
+static void write_serial_io_port(unsigned port,
+ const char *s,
+ unsigned n)
+{
+ unsigned k;
+
+ if (serial_init==0)
+ {
+ init_serial_io_port(port);
+ }
+
+ /*
+ * Set data terminal ready and request to send.
+ */
+
+ for(k = 0; k < n; ++k) {
+ wait_for_readiness(port);
+ outb(s[k], MK_PORT(port));
+ if(s[k] == '\n') {
+ wait_for_readiness(port);
+ outb('\r', MK_PORT(port));
+ }
+ }
+}
+
+
+
+/*
+ * On Intel-derived architectures it is customary for onboard serial
+ * ports to have I/O ports at these two port addresses.
+ */
+
+static void write_serial(struct console *c, const char *s, unsigned n)
+{
+ write_serial_io_port(CONFIG_EARLY_CONSOLE_SERIAL_PORT, s, n);
+}
+
+static struct console early_console_serial =
+{
+
write: write_serial
+};
+#endif
+
+
+#ifdef CONFIG_EARLY_CONSOLE_VGA
+
+/*
+ * This should work for a variety of Intel-derived architectures,
+ * as it is customary for VGA memory to reside in this address range.
+ * vga_putc() is derived from vsta sources, (C) Andrew Valencia.
+ *
+ * Several forms of functionality are intentionally omitted in the
+ * interest of robustness, in particular, cursor movement and cursor
+ * position determination.
+ */
+
+#define VGA_MAXCOL 80
+#define VGA_MAXROW 25
+#define VGA_SCRNSZ (VGA_MAXCOL * VGA_MAXROW)
+#define VGA_REG_PORT 0x3D4
+#define VGA_VAL_PORT 0x3D5
+#define VGA_TEXT_BUFFER 0xB8000
+
+#define VGA_CHAR(_row_, _col_) vga_mem[(_row_)*VGA_MAXCOL + (_col_)].c
+
+struct vga_char_desc
+{
+ unsigned char c;
+
unsigned char color;
+};
+
+static struct vga_char_desc * vga_mem =
+ (struct vga_char_desc *)(VGA_TEXT_BUFFER + PAGE_OFFSET);
+
+/*
+ ** The screen position can actually be determined by port I/O,
+ ** but in the interest of robustness, these are always initialized
+ ** to the (0, 0) position. These position indices must always be
+ ** strictly less than the bounds VGA_MAXROW and VGA_MAXCOL.
+ **/
+static unsigned short row;
+static unsigned short col;
+
+
+/*from martin bligh's early_printk */
+static inline void update_cursor(void)
+{
+ int pos = (col + VGA_MAXCOL*row) *2;
+
+ outb_p(14, VGA_REG_PORT);
+ outb_p(0xff & (pos >> 9), VGA_VAL_PORT);
+ outb_p(15, VGA_REG_PORT);
+ outb_p(0xff & (pos >> 1),
VGA_VAL_PORT);
+}
+
+
+void clear_vga_mem(void)
+{
+ int x, y;
+
+ for (x = 0; x < 80; x++) {
+ for (y = 0; y < 25; y++) {
+ VGA_CHAR(y,x) = ' ';
+ }
+ }
+ row =0;
+ col =0;
+ update_cursor();
+}
+
+
+
+
+/*
+ * The characters displayed at a screen position can be discerned by
+ * reading from the corresponding memory location. This can be used
+ * to simulate scrolling movement. Line blanking is simulated by
+ * overwriting the displayed characters with the space character.
+ *
+ * In the interest of robustness, cursor movement is also omitted.
+ */
+static inline void vga_scroll_up(void)
+{
+ unsigned k;
+
+ for(k = 0; k < (VGA_SCRNSZ - VGA_MAXCOL); ++k)
+ vga_mem[k].c =
vga_mem[k + VGA_MAXCOL].c;
+
+ for(k = VGA_SCRNSZ - VGA_MAXCOL; k < VGA_SCRNSZ; ++k)
+ vga_mem[k].c = ' ';
+}
+
+
+/*
+ * Line advancement must preserve the invariant that the row and
+ * column indices are in-bounds. The semantics of this mean that
+ * when line advancement "beyond" the last line results in scrolling.
+ */
+static inline void vga_line_advance(void)
+{
+ ++row;
+
+ if(row >= VGA_MAXROW) {
+ row = VGA_MAXROW - 1;
+ vga_scroll_up();
+ }
+}
+
+
+/*
+ * Character advancement must once again preserve the in-bounds
+ * invariants, and in so doing line wrapping and advancement may occur.
+ */
+static inline void vga_char_advance(void)
+{
+ ++col;
+
+ if(col >= VGA_MAXCOL) {
+ col = 0;
+ vga_line_advance();
+ }
+}
+
+
+/*
+ * Derived
from vsta sources (C) Andrew Valencia.
+ * Here the interpretation of several common special characters occurs,
+ * namely linefeeds, newlines, tabs, and backspaces. The position
+ * indices are updated using the vga_char_advance() and vga_line_advance()
+ * routines, and a vga_char_advance() is triggered on the printing of
+ * each ordinary character. The special characters have specialized
+ * position update semantics in order to be faithful to their customary
+ * cursor movement effects, although the cursor position is not updated.
+ */
+static void vga_putc(char c)
+{
+ unsigned k;
+ switch(c) {
+ case '\t':
+ for(k = 0; k < 8; ++k) {
+ VGA_CHAR(row, col) = ' ';
+ vga_char_advance();
+ }
+ break;
+
+ case '\r':
+ col = 0;
+
break;
+
+ case '\n':
+ col = 0;
+ vga_line_advance();
+ break;
+
+ case '\b':
+ if(col > 0) {
+ --col;
+ VGA_CHAR(row, col) = ' ';
+ }
+ break;
+
+ default:
+ VGA_CHAR(row, col) = c;
+ vga_char_advance();
+ break;
+ }
+}
+
+
+/*
+ * write_vga(), given a NUL-terminated character array, writes
+ * characters to VGA space in bulk, and is the callback used for the
+ * driver structure.
+ */
+static void write_vga(struct console *c, const char *s, unsigned n)
+{
+ unsigned k;
+
+ for(k = 0; k < n; ++k)
+ {
+ vga_putc(s[k]);
+ update_cursor();
+ }
+}
+
+static struct console early_console_vga =
+{
+ write: write_vga
+};
+
+#endif /*END CONFIG_EARLY_CONSOLE_VGA*/
+
+
+
+/*
+ * The bochs x86 simulator has an optional feature
for enabling
+ * debugging output through a normally unused ISA I/O port. The
+ * protocol for communicating with the simulated device is simply
+ * using port I/O writes to write a stream of characters to the
+ * device, and these are then relayed by the simulator to the
+ * controlling terminal of the simulator process.
+ */
+#ifdef CONFIG_EARLY_CONSOLE_BOCHS_E9_HACK
+static void write_bochs(struct console *c, const char *s, unsigned n)
+{
+ unsigned k;
+
+ for(k = 0; k < n; ++k)
+ outb(s[k], MK_PORT(0xE9));
+}
+
+static struct console early_console_bochs =
+{
+ write: write_bochs
+};
+#endif /* CONFIG_EARLY_CONSOLE_BOCHS_E9_HACK */
+
+
+/*
+ * In order to minimize the number of #ifdefs whch must
+ * appear in-line, this direct-mapped,
NULL-terminated table
+ * of console entries is used to provide a configuration-independent
+ * structure which may be traversed to discover all of the available
+ * early console devices for registration and unregistration.
+ *
+ * This is the ugliest part of the code, thanks to #ifdef
+ */
+static struct console * early_console_table[] =
+ {
+#ifdef CONFIG_EARLY_CONSOLE_SERIAL
+ &early_console_serial,
+#endif
+#ifdef CONFIG_EARLY_CONSOLE_VGA
+ &early_console_vga,
+#endif
+#ifdef CONFIG_EARLY_CONSOLE_BOCHS_E9_HACK
+ &early_console_bochs,
+#endif
+ NULL
+ };
+
+
+/*
+ * The above implementations are quite far from complete console
+ * devices, but printk() only requires the ->write callback, so this is
+ * somewhat deceptive, but still cleaner
than editing printk.c itself.
+ */
+void add_early_consoles(void)
+{
+
+ struct console **c = early_console_table;
+ while(*c)
+ {
+ register_early_console(*c++);
+ printk ("consoled added!\n\n");
+ }
+#ifdef CONFIG_EARLY_CONSOLE_VGA
+ clear_vga_mem();
+#endif
+
+}
+
diff -urN linux-2.5.25/arch/i386/kernel/setup.c linux-2.5.25-early/arch/i386/kernel/setup.c
--- linux-2.5.25/arch/i386/kernel/setup.c 2002-07-05 16:42:23.000000000 -0700
+++ linux-2.5.25-early/arch/i386/kernel/setup.c 2002-07-16 13:11:21.000000000 -0700
@@ -598,7 +598,9 @@
int i;

early_cpu_init();
-
+
+ add_early_consoles();
+
#ifdef CONFIG_VISWS
visws_get_board_type_and_rev();
#endif
diff -urN linux-2.5.25/include/linux/console.h
linux-2.5.25-early/include/linux/console.h
--- linux-2.5.25/include/linux/console.h 2002-07-05 16:42:22.000000000 -0700
+++ linux-2.5.25-early/include/linux/console.h 2002-07-16 13:11:21.000000000 -0700
@@ -90,7 +90,7 @@
#define CON_PRINTBUFFER (1)
#define CON_CONSDEV (2) /* Last on the command line */
#define CON_ENABLED (4)
-
+#define EARLY_CONSOLE (8) /* Early flag. Remove in con_init */
struct console
{
char name[8];
@@ -105,6 +105,7 @@
struct console *next;
};

+
extern void register_console(struct console *);
extern int unregister_console(struct console *);
extern struct console *console_drivers;
@@ -112,6 +113,9 @@
extern void release_console_sem(void);
extern void console_conditional_schedule(void);
extern void
console_unblank(void);
+extern int clear_early_consoles(void);
+extern void register_early_console(struct console *);
+

/* VESA Blanking Levels */
#define VESA_NO_BLANKING 0
diff -urN linux-2.5.25/kernel/printk.c linux-2.5.25-early/kernel/printk.c
--- linux-2.5.25/kernel/printk.c 2002-07-05 16:42:23.000000000 -0700
+++ linux-2.5.25-early/kernel/printk.c 2002-07-16 13:11:21.000000000 -0700
@@ -579,6 +579,10 @@
int i;
unsigned long flags;

+#ifndef NO_CONFIG_EARLY_CONSOLE
+ clear_early_consoles();
+#endif
+
/*
* See if we want to use this console driver. If we
* didn't select a console we take the first one
@@ -676,6 +680,50 @@
}
EXPORT_SYMBOL(unregister_console);

+/* This will clear any and all console_drivers that

+ use only in con_init to remove any consoles that setup_arch
+ may have added for early console support
+ */
+int clear_early_consoles(void)
+{
+ struct console *a, *b;
+ int removed = 0;
+
+ if(console_drivers)
+ {
+ acquire_console_sem();
+
+
+ for (a=console_drivers->next, b=console_drivers; a; b=a,a=b->next)
+ {
+ if (a->flags & EARLY_CONSOLE)
+ {
+ b->next = a->next;
+ removed++;
+ }
+ }
+
+ if (console_drivers->flags & EARLY_CONSOLE)
+ {
+ console_drivers=console_drivers->next;
+ removed++;
+
+ }
+
+ if (console_drivers == NULL)
+ preferred_console = -1;
+
+ release_console_sem();
+ }
+ return removed;
+}
+
+void register_early_console(struct console *early_con)
+{
+
early_con->flags |= EARLY_CONSOLE;
+ register_console(early_con);
+}
+
/**
* tty_write_message - write a message to a certain tty, not just the console.
*






Attachments:
(No filename) (16.89 kB)
early_console-2.5.25 (15.64 kB)
Download all attachments

2002-10-12 19:17:43

by Dave Hansen

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1

Martin J. Bligh wrote:
>>This patch fixes some of the missed handle_sysrq functions not updated.
>>please apply.
>
> Are you going to have early console support (ie printk from before
> what is now console_init) done before the freeze, or should I just
> submit our version?

That reminds me. Has anyone noticed that sysrq on the serial console
is broken?

--
Dave Hansen
[email protected]

2002-10-12 19:20:52

by William Lee Irwin III

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1

On Sat, Oct 12, 2002 at 12:22:29PM -0700, Dave Hansen wrote:
> That reminds me. Has anyone noticed that sysrq on the serial console
> is broken?

For so long I've not bothered trying.

2002-10-13 00:00:40

by Anton Blanchard

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1


> That reminds me. Has anyone noticed that sysrq on the serial console
> is broken?

Strange, its working fine on ppc64.

Anton

2002-10-13 20:42:38

by James Simmons

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1


On Sat, 12 Oct 2002, Anton Blanchard wrote:

>
> > Are you going to have early console support (ie printk from before
> > what is now console_init) done before the freeze, or should I just
> > submit our version?
>
> On ppc64 Im currently setting a console up very early in arch init code
> and using the CONFIG_EARLY_PRINTK hook to disable it at console_init
> time. Works OK for me, do you guys need something on top of that?

Ugh!!! The reason I reworked the console system is because over the years
hack after hack has been added. It now has lead to this twisted monster.
Take a look at the fbdev driver codes in 2.4.X. Instead of another hack
the console system should be cleaned up with a well thought out design to
make the code base smaller and more effiencent.

2002-10-13 20:49:33

by Martin J. Bligh

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1

>> > Are you going to have early console support (ie printk from before
>> > what is now console_init) done before the freeze, or should I just
>> > submit our version?
>>
>> On ppc64 Im currently setting a console up very early in arch init code
>> and using the CONFIG_EARLY_PRINTK hook to disable it at console_init
>> time. Works OK for me, do you guys need something on top of that?
>
> Ugh!!! The reason I reworked the console system is because over the years
> hack after hack has been added. It now has lead to this twisted monster.
> Take a look at the fbdev driver codes in 2.4.X. Instead of another hack
> the console system should be cleaned up with a well thought out design to
> make the code base smaller and more effiencent.

Cool, as long as it gets merged by the freeze. We've been waiting for you
to do this for a long time, but if it's not ready, then we need the hacky versions
in order to get the functionality.

M.

2002-10-13 20:55:01

by Russell King

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1

On Sun, Oct 13, 2002 at 01:40:50PM -0700, James Simmons wrote:
> Ugh!!! The reason I reworked the console system is because over the years
> hack after hack has been added. It now has lead to this twisted monster.
> Take a look at the fbdev driver codes in 2.4.X. Instead of another hack
> the console system should be cleaned up with a well thought out design to
> make the code base smaller and more effiencent.

There is a very good reason why stuff like this is needed. Its to get
the boot messages out of a non-booting box, when you know that its oopsed
before fbcon can be initialised.

fbcon can't be initialised before PCI setup on many systems because the
PCI bus may not be setup, and therefore the VGA card may very well not
be accessible.

I think you'll find that virtually every architecture has some method
to get real early boot time messages out of the box in some way (on ARM,
it involves enabling CONFIG_DEBUG_LL and adding a function call into
printk.c, and attaching a machine to a serial port - this works from
the moment that we start executing any kernel image.)

You're not going to be able to design something to cover all cases.
Especially the ones where the normal C environment isn't up and running
yet. 8)

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2002-10-13 21:17:25

by Andrew Morton

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1

Russell King wrote:
>
> On Sun, Oct 13, 2002 at 01:40:50PM -0700, James Simmons wrote:
> > Ugh!!! The reason I reworked the console system is because over the years
> > hack after hack has been added. It now has lead to this twisted monster.
> > Take a look at the fbdev driver codes in 2.4.X. Instead of another hack
> > the console system should be cleaned up with a well thought out design to
> > make the code base smaller and more effiencent.
>
> There is a very good reason why stuff like this is needed. Its to get
> the boot messages out of a non-booting box, when you know that its oopsed
> before fbcon can be initialised.
>
> fbcon can't be initialised before PCI setup on many systems because the
> PCI bus may not be setup, and therefore the VGA card may very well not
> be accessible.
>
> I think you'll find that virtually every architecture has some method
> to get real early boot time messages out of the box in some way (on ARM,
> it involves enabling CONFIG_DEBUG_LL and adding a function call into
> printk.c, and attaching a machine to a serial port - this works from
> the moment that we start executing any kernel image.)
>
> You're not going to be able to design something to cover all cases.
> Especially the ones where the normal C environment isn't up and running
> yet. 8)

Yes, there are a number of rude hacks down there to handle oopses
and early startup. It's just a messy problem, and no solution to
it will be a thing of beauty.

And early printk is obviously a useful thing to have when the
machine won't start.

I think what we need James is just the low-level hook in printk.c which
the various platforms and boards can plug into. The one in Martin's
patch (module some cleanups, docco, conversion to C, etc) looks
suitable to me. The actual early console drivers don't appear to have
much relationship at all to the console layer really. They're just
minimal-code busy-wait port banging.

The patch needs to be split.

- Generic part in printk.c. Make sure that it suits all users

- ia32 serial early console driver

- ia32 VGA early console driver.

What else?

And who's going to do it?

2002-10-13 22:28:06

by Anton Blanchard

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1


> Ugh!!! The reason I reworked the console system is because over the years
> hack after hack has been added. It now has lead to this twisted monster.
> Take a look at the fbdev driver codes in 2.4.X. Instead of another hack
> the console system should be cleaned up with a well thought out design to
> make the code base smaller and more effiencent.

Where is the hack? The ppc64 early console code uses a hypervisor call
or a serial port routine which have no business being in a generic
console infrastructure.

At the moment its two lines called before start_kernel to register the
console, and 4 lines of disable_early_printk. We use existing routines
to talk to the hypervisor or serial console.

How is the reworked console system going to reduce this? :)

Anton

2002-10-14 01:13:04

by Andi Kleen

[permalink] [raw]
Subject: Re: [BK PATCH] console changes 1

Andrew Morton <[email protected]> writes:

> I think what we need James is just the low-level hook in printk.c which
> the various platforms and boards can plug into. The one in Martin's
> patch (module some cleanups, docco, conversion to C, etc) looks
> suitable to me. The actual early console drivers don't appear to have
> much relationship at all to the console layer really. They're just
> minimal-code busy-wait port banging.

The hook already exists and it is called register_console. Has been there
for years. early_printk on x86-64 uses that. Originally I used the hackish
printk hook way, but Linus put me on the right track.

Your arch code just does a register_console very early which does the low level
output.

Actually you need one new hook for cosmetic reason: when the real console
starts you want to disable the early console, otherwise you get duplicated
output when they go to the same output device. This can be done with a
straight forward function call in console_init.

BTW the x86-64 early console should just work fine on i386 too, with minor
changes.

All you need to do is:

- cp arch/x86_64/kernel/early_printk.c arch/i386/kernel/early_printk.c
- edit arch/i386/kernel/early_printk.c and replace VGABASE with
__PAGE_OFFSET+0xb8000
- add it to arch/i386/kernel/Makefile
- (optional - if you don't do it will be only initialised after setup_arch when
__setup arguments are parsed)
add something like
if (c == ' ' && !memcmp(from,"earlyprintk=",12)) {
extern int setup_early_printk(char *opt)
setup_early_printk(from+12);
}
to the comand line parsing in arch/i386/kernel/setup.c
- Enable CONFIG_EARLY_PRINTK so that console_init disables it.
- Boot with earlyprintk=vga (for vga output)
or earlyprintk=serial,ttySx,baud for serial output.
Add ,keep when you want to keep it even after console_init


-Andi