I'm trying to get a box to boot and it appears to drop dead before
start_kernel(). Would anyone happen to have an early_printk() analogue
for 16-bit x86 code?
Thanks,
Bill
William Lee Irwin III wrote:
> I'm trying to get a box to boot and it appears to drop dead before
> start_kernel(). Would anyone happen to have an early_printk() analogue
> for 16-bit x86 code?
It could be failing in the decompression routine if it was compiled for
the wrong cpu (ie. using cmov instructions).
--
Brian Gerst
William Lee Irwin III wrote:
>> I'm trying to get a box to boot and it appears to drop dead before
>> start_kernel(). Would anyone happen to have an early_printk() analogue
>> for 16-bit x86 code?
On Tue, Jan 14, 2003 at 08:13:15AM -0500, Brian Gerst wrote:
> It could be failing in the decompression routine if it was compiled for
> the wrong cpu (ie. using cmov instructions).
The cpu has cmov. It's Pentium-III. It suceeds in one configuration of
the machine and fails in another.
Bill
I can share our serial tool for debugging early boot. It is actually written
for IA64 by Chuck Sluder at Unisys, and we used it even for EFI driver
debug. It saved us a lot of grief.
You can modify it for IA32. It just outputs debug messages to the serial
port directly, so you will need a serial console:
This insertion is into kernel/prink.c:
---------------------------------------------
extern void writebuf(int, const char *);
void
early_printk (const char *str)
{
char c;
int i, k, j;
#ifdef CONFIG_ITANIUM_ES7000
// this is out writing to serial port routine:
writebuf(0, str);
#endif
while ((c = *str++) != '\0') {
==cut here io.c =======================
#include <string.h>
extern unsigned long ia64_iobase;
extern void outb_asm();
extern unsigned char inb_asm();
unsigned short
serial_port_addr[4] = {
0x3f8,
0x2f8,
0x3e8,
0x2e8
};
void
outb(unsigned short port, unsigned char data)
{
unsigned char *addr;
addr = (unsigned char *)(ia64_iobase | ((port & 0xfffc) << 10) |
(port & 0x0fff));
outb_asm(addr, data);
return;
}
unsigned char
inb(unsigned short port)
{
unsigned char *addr, data;
addr = (unsigned char *)(ia64_iobase | ((port & 0xfffc) << 10) |
(port & 0x0fff));
data = inb_asm(addr);
return(data);
}
#define SERIAL_REGISTER_LSR 5 /* R/W Line Status Register */
void
mputc(unsigned char port, unsigned char data)
{
unsigned char status, i=0;
unsigned short portaddr;
portaddr = serial_port_addr[port];
do {
status = inb((serial_port_addr[port] +
SERIAL_REGISTER_LSR));
i++;
if (i == 10000){
return;
}
} while ((status & 0x20) == 0);
outb(portaddr, data);
return;
}
int
writebuf(unsigned char port, char *buf)
{
int i;
size_t cnt;
unsigned char data;
cnt = strlen(buf);
for (i=0; i<cnt; i++) {
data = buf[i];
if (data == '\n') {
mputc(port, 0x0d);
mputc(port, 0x0a);
} else {
mputc(port, data);
}
}
return((int)cnt);
}
====sample asm inb and outb for IA64========
.text
.global inb_asm
.global outb_asm
.global read_psr
.global read_iva
.global read_xapic
.global write_xapic
.align 32
.proc inb_asm
inb_asm:
mf // fence all loads/stores
ld1.acq r8 = [r32] // read a byte from the port
mf.a // make sure the platform accepts it
br.ret.sptk b0
.endp inb_asm
.proc outb_asm
outb_asm:
st1.rel [r32] = r33 // write one byte to a port
mf.a // make sure the platform accepts it
mf // fence all loads/stores
br.ret.sptk b0
.endp outb_asm
> I'm trying to get a box to boot and it appears to drop dead before
> start_kernel(). Would anyone happen to have an early_printk() analogue
> for 16-bit x86 code?
See arch/i386/boot/compressed/misc.c - there's a puts() routine in
there that should work for most things OK.
M.
William Lee Irwin III wrote:
> William Lee Irwin III wrote:
>
>>>I'm trying to get a box to boot and it appears to drop dead before
>>>start_kernel(). Would anyone happen to have an early_printk() analogue
>>>for 16-bit x86 code?
>>
>
> On Tue, Jan 14, 2003 at 08:13:15AM -0500, Brian Gerst wrote:
>
>>It could be failing in the decompression routine if it was compiled for
>>the wrong cpu (ie. using cmov instructions).
>
> The cpu has cmov. It's Pentium-III. It suceeds in one configuration of
> the machine and fails in another.
Does this mean succeeds with 32GB, but not with 48GB?
--
Dave Hansen
[email protected]
At some point in the past, I wrote:
>> I'm trying to get a box to boot and it appears to drop dead before
>> start_kernel(). Would anyone happen to have an early_printk() analogue
>> for 16-bit x86 code?
On Tue, Jan 14, 2003 at 08:07:53AM -0800, Martin J. Bligh wrote:
> See arch/i386/boot/compressed/misc.c - there's a puts() routine in
> there that should work for most things OK.
Hmm, I wonder why that was never mentioned by some others...
At any rate, it suffices for me.
Bill
On Tue, 2003-01-14 at 11:30, William Lee Irwin III wrote:
> I'm trying to get a box to boot and it appears to drop dead before
> start_kernel(). Would anyone happen to have an early_printk() analogue
> for 16-bit x86 code?
Linux 8086 has a complete mini-linux for it, let alone printk. A bcc
compileable printk is included
On Tue, 2003-01-14 at 11:30, William Lee Irwin III wrote:
>> I'm trying to get a box to boot and it appears to drop dead before
>> start_kernel(). Would anyone happen to have an early_printk() analogue
>> for 16-bit x86 code?
On Tue, Jan 21, 2003 at 02:32:07AM +0000, Alan wrote:
> Linux 8086 has a complete mini-linux for it, let alone printk. A bcc
> compileable printk is included
It actually turned out to be a bug in the early_printk I was using that
killed it on the first call to it, but the availability of this will
certainly broaden the scope of what I can feasibly debug.
Thanks,
Bill
William Lee Irwin III wrote:
> It actually turned out to be a bug in the early_printk I was using that
> killed it on the first call to it, but the availability of this will
> certainly broaden the scope of what I can feasibly debug.
Are you using the one that calls console_setup(), then initializes the
serial driver directly? I was seeing some strange behavior with that
yesterday, but I assumed that it was my patch crashing in early boot.
What was the bug?
--
Dave Hansen
[email protected]
William Lee Irwin III wrote:
>> It actually turned out to be a bug in the early_printk I was using that
>> killed it on the first call to it, but the availability of this will
>> certainly broaden the scope of what I can feasibly debug.
On Tue, Jan 21, 2003 at 09:31:04AM -0800, Dave Hansen wrote:
> Are you using the one that calls console_setup(), then initializes the
> serial driver directly? I was seeing some strange behavior with that
> yesterday, but I assumed that it was my patch crashing in early boot.
> What was the bug?
I don't think that was the one, no. I didn't bother debugging it and just
hand-coded the bitbanging directly in asm.
-- wli