etherboot-developers

[Etherboot-developers] Serial Port Debugging

[Timothy L. <tl...@ro...>]

Hi

I am getting somewhat fustrated with trying to get the serial port debugging working.  Here what I have done:

1) Enabled the Serial Console in Config (I assume there is only one spot)
2) Run minicom, with the same speed and the /dev/ttyS0 or /dev/ttyS1 port, 8N1 and ANSI.  (The status bar for minicom says Offline, is this normal).

I had purchased a 9 to 25 pin null modem serial cable, nothing seemed to work.

Today, I purchased a 9 to 9 pin seial cable and a Null Modem adapter, nothing seems to work.

I have deleted /dev/modem and /dev/mouse, so they are not interfering.

Any ideas?

Tim

Re: [Etherboot-developers] Serial Port Debugging

[Vasil V. <vas...@sy...>]

On Fri, 17 Jan 2003, Timothy Legge wrote:

> Hi
>
> I am getting somewhat fustrated with trying to get the serial port debugging working.  Here what I have done:
>
> 1) Enabled the Serial Console in Config (I assume there is only one spot)

There is an option for CRT Console and Dual Console (CRT and Serial). I am not
sure what the exclusions are.

> 2) Run minicom, with the same speed and the /dev/ttyS0 or /dev/ttyS1 port,
> 8N1 and ANSI.  (The status bar for minicom says Offline, is this normal).

I've seen minicom which says Offline and sending and receiving OK. I think
Offline is to do with the flow control pins, so if they are not connected you
may get Offline in minicom, but otherwise all else is fine.

Check the serial port configuration for etherboot and the ports the BIOS uses
for the serial lines.

> I had purchased a 9 to 25 pin null modem serial cable, nothing seemed to work.

Where do you connect the 25 pin end?

> Today, I purchased a 9 to 9 pin seial cable and a Null Modem adapter, nothing seems to work.
>
> I have deleted /dev/modem and /dev/mouse, so they are not interfering.

Have you tried lilo or booting linux kernel with the console parameter set:

in lilo.conf

serial=s,xxxxxn8

image=.....
	append="console=ttySs,xxxxx"


where s is the number of the port, say 0 or 1. xxxxx is the speed, say 9600.

Or even simpler, trying typing into /dev/ttyS0 or /dev/ttyS1 on either machine
and listening on the other.
This would at least establish whether the lines and cables are working without
etherboot.

RE: [Etherboot-developers] Serial Port Debugging

[Timothy L. <tl...@ro...>]

> > I had purchased a 9 to 25 pin null modem serial cable, nothing
seemed to
> work.
> 
> Where do you connect the 25 pin end?

Particularly good question.  Here is what I have learned about serial
debugging:

1) If you have two 25 pin ports on the back of your computer, ensure
that you know which one is the printer port.  Yes, even if you think you
know, open the case and look to be sure.

2) If you are going to buy a num modem cable or adapter ensure that you
know how it should be wired.  Do not buy a cable or adapter that does
not have wiring information unless you verify it with a meter.  In fact,
insist on it even if it is labeled.

So after spending more money than I want to think about and making
beginner level mistakes I have finally gotten serial debugging working.
Now what was it I needed it for??

Tim

RE: [Etherboot-developers] Serial Port Debugging

[Vasil V. <va...@sy...>]

On Mon, 20 Jan 2003, Timothy Legge wrote:

> > > I had purchased a 9 to 25 pin null modem serial cable, nothing
> seemed to
> > work.
> >
> > Where do you connect the 25 pin end?
>
> Particularly good question.  Here is what I have learned about serial
> debugging:
>
> 1) If you have two 25 pin ports on the back of your computer, ensure
> that you know which one is the printer port.  Yes, even if you think you
> know, open the case and look to be sure.
>
> 2) If you are going to buy a num modem cable or adapter ensure that you
> know how it should be wired.  Do not buy a cable or adapter that does
> not have wiring information unless you verify it with a meter.  In fact,
> insist on it even if it is labeled.
>
> So after spending more money than I want to think about and making
> beginner level mistakes I have finally gotten serial debugging working.
> Now what was it I needed it for??

Good points. I have experienced similar problems about wiring but with RJ45
connectors:

3) There is no standard for converting RJ45 to DB9 or DB25 for serial lines.

-- 
Vasil
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The trouble with eating Italian food is that five or six days later
you're hungry again.
		-- George Miller

Re: [Etherboot-developers] Serial Port Debugging

[<ebi...@ln...>]

"Timothy Legge" <tl...@ro...> writes:

> So after spending more money than I want to think about and making
> beginner level mistakes I have finally gotten serial debugging working.
> Now what was it I needed it for??

There are 2 cases I remember.
1) confirming the double probe. (already confirmed...)
2) Seeing if just using the serial port would allow your 486 to work,
   you could at least see if it could get more than one character printed.

Eric

RE: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[Timothy L. <tim...@us...>]

> 2) Seeing if just using the serial port would allow your 486 to work,
>    you could at least see if it could get more than one character
printed.

Well, I have more information on the 486 issue.  I compiled a driver
(gcc 2.95.3) and booted the system.  It displayed:

.000041.0000 done
R

At this point, nothing was shown in minicom.  Then, I accidentally hit
some miscellaneous keys on the client keyboard.  The result was that it
started to display the rest of the information on the screen (and in
minicom) as follows:

.000041.0000 done
ROM segment 0x0800 length 0x8000 reloc 0x00020000

I was able to observe the following:

1) Even the non-serial debugging version displayed this behavior.
2) If I hit the (return) enter key it displayed the text 2 letters at a
time.
3) If I hit the number keypad enter key it displayed the text 4 letters
at a time.
4) It would start to beep after hitting the key a number of times.
5) It froze after it finished displaying that first line. (Or at least
did not display anything else in either minicom of on the screen.

I am not sure if any of this information is useful, but I guess it is
more than we knew earlier.

Tim

Re: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[<ebi...@ln...>]

"Timothy Legge" <tim...@us...> writes:

> > 2) Seeing if just using the serial port would allow your 486 to work,
> >    you could at least see if it could get more than one character
> printed.
> 
> Well, I have more information on the 486 issue.  I compiled a driver
> (gcc 2.95.3) and booted the system.  It displayed:
> 
> .000041.0000 done
> R
> 
> At this point, nothing was shown in minicom.  Then, I accidentally hit
> some miscellaneous keys on the client keyboard.  The result was that it
> started to display the rest of the information on the screen (and in
> minicom) as follows:
> 
> .000041.0000 done
> ROM segment 0x0800 length 0x8000 reloc 0x00020000
> 
> I was able to observe the following:
> 
> 1) Even the non-serial debugging version displayed this behavior.
> 2) If I hit the (return) enter key it displayed the text 2 letters at a
> time.
> 3) If I hit the number keypad enter key it displayed the text 4 letters
> at a time.
> 4) It would start to beep after hitting the key a number of times.
> 5) It froze after it finished displaying that first line. (Or at least
> did not display anything else in either minicom of on the screen.
> 
> I am not sure if any of this information is useful, but I guess it is
> more than we knew earlier.

Was this with both serial and video support compiled in or just serial.
If it is both serial and video support could you compile in just serial?

It looks like something is strange with the BIOS in the middle
of the printf.  As the serial debugging code bypasses the BIOS
entirely we should be able to trivially rule out the display
code.  But I suspect it is something about the code to display
a character on the serial port.

Is this a recent embedded 486 or is this a much older 486 PC.  I'm
just trying to get a feel for what kind of other hardware would be in
the box and where you are likely to have BIOS problems.

Eric

RE: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[Timothy L. <tim...@us...>]

> Was this with both serial and video support compiled in or just
serial.
> If it is both serial and video support could you compile in just
serial?

Yes, it was both the display and the serial console.  I will try just
the serial console.
 
> Is this a recent embedded 486 or is this a much older 486 PC.  I'm

It's a Compaq Prolinea 486/25 that has an upgraded processor (Evergreen
133).  It also has a 2 meg Mach 32 ISA vid card installed (motherboard
video is disabled).  So yes, it is a relatively old machine.

RE: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[Timothy L. <tim...@us...>]

> If it is both serial and video support could you compile in just
serial?
> 
> It looks like something is strange with the BIOS in the middle
> of the printf.  As the serial debugging code bypasses the BIOS
> entirely we should be able to trivially rule out the display
> code.  But I suspect it is something about the code to display
> a character on the serial port.
> 
> Is this a recent embedded 486 or is this a much older 486 PC.  I'm
> just trying to get a feel for what kind of other hardware would be in
> the box and where you are likely to have BIOS problems.

The serial only console displayed the full text of:

ROM segment 0x0800 length 0x8000 reloc 0x00020000

in minicom, with out any problem, but it stopped there.

TIm

RE: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[Timothy L. <tim...@us...>]

> > Is this a recent embedded 486 or is this a much older 486 PC.  I'm
> > just trying to get a feel for what kind of other hardware would be
in
> > the box and where you are likely to have BIOS problems.
> 
> The serial only console displayed the full text of:
> 
> ROM segment 0x0800 length 0x8000 reloc 0x00020000
> 
> in minicom, with out any problem, but it stopped there.

I also modified core/main.c

	rom = *(struct rom_info *)phys_to_virt(ROM_INFO_LOCATION);
	printf("ROM segment %#hx length %#hx reloc %#x\n",
rom.rom_segment,
		rom.rom_length << 1, (unsigned long)_text);
+	printf("Got Here 0\n");
	gateA20_set();
+	printf("Got Here 1\n");
	print_config();
+	printf("Got Here 2\n");
	get_memsizes();
+	printf("Got Here 3\n");
	cleanup();
+	printf("Got Here 4\n");

Only the Got Here 0 was printed to the serial console.  So I assumed the
issue is in gateA20_set().  

I commented out gateA20_set() and then I got as far as Got Here 2, so it
is now stuck in the get_memsizes.

Of course, I could be out to lunch.  Could something that happened
earlier than gateA20_set() have caused the issue?

Tim

Re: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[<ebi...@ln...>]

"Timothy Legge" <tim...@us...> writes:

> > > Is this a recent embedded 486 or is this a much older 486 PC.  I'm
> > > just trying to get a feel for what kind of other hardware would be
> in
> > > the box and where you are likely to have BIOS problems.
> > 
> > The serial only console displayed the full text of:
> > 
> > ROM segment 0x0800 length 0x8000 reloc 0x00020000
> > 
> > in minicom, with out any problem, but it stopped there.
> 
> I also modified core/main.c
> 
> 	rom = *(struct rom_info *)phys_to_virt(ROM_INFO_LOCATION);
> 	printf("ROM segment %#hx length %#hx reloc %#x\n",
> rom.rom_segment,
> 		rom.rom_length << 1, (unsigned long)_text);
> +	printf("Got Here 0\n");
> 	gateA20_set();
> +	printf("Got Here 1\n");
> 	print_config();
> +	printf("Got Here 2\n");
> 	get_memsizes();
> +	printf("Got Here 3\n");
> 	cleanup();
> +	printf("Got Here 4\n");
> 
> Only the Got Here 0 was printed to the serial console.  So I assumed the
> issue is in gateA20_set().  
> 
> I commented out gateA20_set() and then I got as far as Got Here 2, so it
> is now stuck in the get_memsizes.
> 
> Of course, I could be out to lunch.  Could something that happened
> earlier than gateA20_set() have caused the issue?


It is clear that you are hanging in various BIOS calls.  gateA20_set,
will make them as well as getmemsize.  I am not certain you are hanging.

Does 5.0.x have this issue as well?

If it was a regression it might be easier to track.

When we make BIOS calls we switch from protcted to real mode, enable
interrupts.  Make the BIOS calls, and switch back to protected mode.

There is a lot that can potentially go wrong in that process.  But it
appears to work fairly universally.

Eric

RE: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[Timothy L. <tl...@ro...>]

> Does 5.0.x have this issue as well?
> 
> If it was a regression it might be easier to track.
> 

It does seem to be a regression.  I have had no issues with 5.0 even the
most recent cvs works fine.

Tim

RE: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[Timothy L. <tim...@us...>]

A little more information:

I tracked through misc.c and placed printfs:

#if defined(PCBIOS) && !defined(IBM_L40)
static void empty_8042(void)
{
	unsigned long time;
	char st;
	printf("empty_8042 0\n");
	time = currticks() + TICKS_PER_SEC;	/* max wait of 1 second
*/
	printf("empty_8042 1\n");
	while ((((st = inb(K_CMD)) & K_OBUF_FUL) ||
	       (st & K_IBUF_FUL)) &&
	       currticks() < time)
		inb(K_RDWR);
	printf("empty_8042 2\n");
}
#endif	/* IBM_L40 */

I only received the first printf: empty_8042 0.  I then moved into
arch/i386/core/i386_timer.c but non of the printfs I placed in currticks
displayed anything.

Thinking it might be dieing as a result of a previous operation, I
changed the first printf("empty_8042 0\n"); to:

int x;
for(x=0;x<1000;x++)
	printf("empty_8042 %d\n", x);

This properly displayed the correct number of llines, but again failed.
Is it possible that it cannot find currticks?

Tim

RE: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[Timothy L. <tim...@us...>]

OK, more information.  There does seem to be an issue with currticks.
In main (main.c) I placed:

unsigned long x = currticks(); 

as in: 
int main(struct Elf_Bhdr *ptr)
{
	char *p;
	int state;
++ 	unsigned long x = currticks();
	for (p = _bss; p < _ebss; p++)
		*p = 0;	/* Zero BSS */

	console_init(); 
	arch_main(ptr); 
#ifdef	DELIMITERLINES
	for (i=0; i<80; i++) putchar('=');
#endif
	rom = *(struct rom_info *)phys_to_virt(ROM_INFO_LOCATION);
	
	printf("ROM segment %#hx length %#hx reloc %#x\n",
rom.rom_segment,
		rom.rom_length << 1, (unsigned long)_text);
	printf("Got Here 0\n");
	gateA20_set(); 
	printf("Got Here 1\n");
	print_config();
	printf("Got Here 2\n");
	get_memsizes();
	printf("Got Here 3\n");

before any of my debugging printfs.  The execution did not get past that
line. (None of the other prints occurred.)

So, I modified empty_8042 in misc.c to remove the call to currticks
(repaced with a simple counting loop) as follows:

static void empty_8042(void)
{
	unsigned long time;
	char st;
	int x;

--	time = currticks() + TICKS_PER_SEC;	/* max wait of 1 second
*/ 
++	time = 1000;
++	x = 0;
	printf("empty_8042 1\n");
--	while ((((st = inb(K_CMD)) & K_OBUF_FUL) ||
	       (st & K_IBUF_FUL)) &&
	       curticks() < time)
++	while ((((st = inb(K_CMD)) & K_OBUF_FUL) ||
	       (st & K_IBUF_FUL)) &&
	       x++ < time)
			inb(K_RDWR);
}

This allowed me to return from gateA20_set() and the code executed as
far as the call to get_memsizes();

I will review get_memsizes (when I find it).

Tim
> -----Original Message-----
> From: eth...@li...
[mailto:etherboot-
> dev...@li...] On Behalf Of Timothy Legge
> Sent: Sunday, January 26, 2003 10:01 AM
> To: eth...@li...
> Cc: 'Eric W. Biederman'; 'Tom Trebisky'
> Subject: RE: [Etherboot-developers] 5.1 will not boot on 486 was
Serial
> Port Debugging
> 
> A little more information:
> 
> I tracked through misc.c and placed printfs:
> 
> #if defined(PCBIOS) && !defined(IBM_L40)
> static void empty_8042(void)
> {
> 	unsigned long time;
> 	char st;
> 	printf("empty_8042 0\n");
> 	time = currticks() + TICKS_PER_SEC;	/* max wait of 1 second
> */
> 	printf("empty_8042 1\n");
> 	while ((((st = inb(K_CMD)) & K_OBUF_FUL) ||
> 	       (st & K_IBUF_FUL)) &&
> 	       currticks() < time)
> 		inb(K_RDWR);
> 	printf("empty_8042 2\n");
> }
> #endif	/* IBM_L40 */
> 
> I only received the first printf: empty_8042 0.  I then moved into
> arch/i386/core/i386_timer.c but non of the printfs I placed in
currticks
> displayed anything.
> 
> Thinking it might be dieing as a result of a previous operation, I
> changed the first printf("empty_8042 0\n"); to:
> 
> int x;
> for(x=0;x<1000;x++)
> 	printf("empty_8042 %d\n", x);
> 
> This properly displayed the correct number of llines, but again
failed.
> Is it possible that it cannot find currticks?
> 
> Tim
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[<ebi...@ln...>]

"Timothy Legge" <tim...@us...> writes:

> OK, more information.  There does seem to be an issue with currticks.
> In main (main.c) I placed:
> 
> unsigned long x = currticks(); 

currticks() failing is a good test case, as it is about as simple as it
gets.

If you disable the call to _real_call it should work properly.  Though
it should stop counting.

5.0.8 uses _real_to_prot and _prot_to_real for the same functionality.
The next step is to walk through and see what the differences are between
those functions are.  

The implementation is radically different but in functionality I believe
the are very close to each other.

Eric

Re: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[<ebi...@ln...>]

ebi...@ln... (Eric W. Biederman) writes:

> "Timothy Legge" <tim...@us...> writes:
> 
> > OK, more information.  There does seem to be an issue with currticks.
> > In main (main.c) I placed:
> > 
> > unsigned long x = currticks(); 
> 
> currticks() failing is a good test case, as it is about as simple as it
> gets.
> 
> If you disable the call to _real_call it should work properly.  Though
> it should stop counting.

As an extension to this you should just be able to keep the interrupts
disabled in _real_call and the code should work as well.  But confirming
that would be interesting.

Eric

RE: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[Timothy L. <tim...@us...>]

> > If you disable the call to _real_call it should work properly.
Though
> > it should stop counting.
> 
> As an extension to this you should just be able to keep the interrupts
> disabled in _real_call and the code should work as well.  But
confirming
> that would be interesting.

If the only places to comment out are the two:

call _real_call

in start32.S, it did not work.  

Tim

Re: [Etherboot-developers] 5.1 will not boot on 486 was Serial Port Debugging

[<ebi...@ln...>]

"Timothy Legge" <tim...@us...> writes:

> > > If you disable the call to _real_call it should work properly.
> Though
> > > it should stop counting.
> > 
> > As an extension to this you should just be able to keep the interrupts
> > disabled in _real_call and the code should work as well.  But
> confirming
> > that would be interesting.
> 
> If the only places to comment out are the two:
> 
> call _real_call
> 
> in start32.S, it did not work.  

arch/i386/firmware/pcbios/pcbios.S is where currticks is located,
and that is what I was thinking of.

in start32.S you can comment out the enabling of the interrupts
in _real_call.

I am quite certain there should be some effect.

Eric

RE: [Etherboot-developers] Serial Port Debugging

[Timothy L. <tim...@us...>]

> > I had purchased a 9 to 25 pin null modem serial cable, nothing
seemed to
> work.
> 
> Where do you connect the 25 pin end?

Particularly good question.  Here is what I have learned about serial
debugging:

1) If you have two 25 pin ports on the back of your computer, ensure
that you know which one is the printer port.  Yes, even if you think you
know, open the case and look to be sure.

2) If you are going to buy a num modem cable or adapter ensure that you
know how it should be wired.  Do not buy a cable or adapter that does
not have wiring information unless you verify it with a meter.  In fact,
insist on it even if it is labeled.

So after spending more money than I want to think about and making
beginner level mistakes I have finally gotten serial debugging working.
Now what was it I needed it for??

Tim