Boot Stalls on readclock for Book 8088

[oblende]

The 64MB disk image of Minix 2 stalls at readclock. Message is:
`readclock: Machine ID unknown.
Machine ID byte = fe

Please enter date: MMDDYYhhmmss. Then hit the RETURN key.``

So I tried to enter the time and... It doesn't take any input from the keyboard. The only thing that works is CTRL+ALT+Delete.

BIOS is the revised BIOS by Skiselev. Processor is the stock V20 that comes with it.

[davidgiven]

Does the boot loader prompt work (hammer = at the boot menu?)

[oblende]

There is no boot menu. Which image do you suggest that has a boot menu? Is there suppose to be a boot menu in the 64 MB Minix image?

[davidgiven]

You're right, that doesn't give you the boot menu.

Can you boot from a floppy disk image? I've verified that the minix-2.0 1440kB image has the boot menu.

[davidgiven]

Addendum: to get that message, Minix must have booted all the way to running the startup scripts. So the OS is all actually functioning. I'm curious to know whether the simpler keyboard routines in the boot loader work or not to gauge compatibility of the Book8088's keyboard hardware.

The 0xfe machine ID byte is correct for an IBM XT. Those didn't have CMOS RAM, which is why readclock isn't working. I'm assuming the Book8088 does have CMOS RAM? In which case there should be a way to bypass that check.

minix2/minix-2.0/fs/usr/src/commands/ibm/readclock.c

Line 104 in 826a75d

if (mach_id != PS_386 && mach_id != PC_AT) {

[oblende]

Addendum: to get that message, Minix must have booted all the way to running the startup scripts. So the OS is all actually functioning. I'm curious to know whether the simpler keyboard routines in the boot loader work or not to gauge compatibility of the Book8088's keyboard hardware.

The 0xfe machine ID byte is correct for an IBM XT. Those didn't have CMOS RAM, which is why readclock isn't working. I'm assuming the Book8088 does have CMOS RAM? In which case there should be a way to bypass that check.

minix2/minix-2.0/fs/usr/src/commands/ibm/readclock.c

Line 104 in 826a75d

if (mach_id != PS_386 && mach_id != PC_AT) {

Well that may be the problem. This computer has no CMOS RAM. It's always 01-01-1980 when I boot it to FreeDOS.
So does that mean that booting Minix for this computer is a lost cause? or is there something else that I can do to get Minix to be usable?

I'll try the floppy image next chance I get. That might get me somewhere with this.

[davidgiven]

Nope, Minix works fine without CMOS RAM. The reason for doing the machine ID check is to make sure there is some. If it's not found it won't try to read the clock. I was just thinking that if it did have some, it'd be good to use it.

Also, a photo of the screen once it's hung might be useful.

[oblende]

Okay, here are a couple of screen shots. One from Minix 2.0.4 which doesn't seem to be too informative. It looks like a proper boot, I just can't enter anything. The other is from SysCheck with a screen shot of the BIOS information. I'll also attach a text file of all the test results from it.


BOOK8088.TXT

[davidgiven]

Nothing there looks strange --- honestly, I don't know what's going on, and I can't really debug it without the hardware!

If you can get a floppy image booting, there are lots of variables in the boot loader which can be modified to adjust the behaviour. My gut feeling is that there's some hardware that's more AT-ish than XT-ish and this is being misdetected. You might also want to add kernel tracing to https://github.com/davidgiven/minix2/blob/master/minix-2.0/fs/usr/src/kernel/keyboard.c to find out what's going on.

Also, if you boot the hd-64MB disk image in an emulator, you can do:

$ edparams /dev/c0d0p0
c0d0p0>main() menu
c0d0p0>save
c0d0p0>exit

...then that'll enable the boot loader. Then do set and it'll show you the detected configuration.

[andreasbaumann]

The monitor says bus=(xt). I happen to have a book8088 (with the VGA card, version 2) since 2 days or so.. hence.. :-)

So far I could bisect the issue to something most likely not keyboard related. The line readclock || intr date hangs in the
intr, which enables interrupts for the keyboard input in date. Commenting out that and booting with boot -s I got a # prompt, but no input.

Then my idea was to use a serial tty. I added tty00 vt100 getty "stty 960" to /etc/ttytab. I got to
a sleep 1 in /usr/etc/rc, again hanging. Commenting out that one I get a # prompt on the console (again no keyboard there)
and a Minix R (8 bytes, coinidence?) on the serial terminal (the V2 version of the book8088 has a serial connector, which
comes in handy here), which I could pin-point to getty.c: static char *def_banner[] = { "%s Release %r Version %v\n\n%n login: ", 0 };. The daemons start up just fine. Executing a ps -ax inside the init scripts shows, that things are up and alive.

As the image works perfectly in qemu I doubt something is wrong in the message passing inside the kernel. My interest
turned now to either interrupt handling or some timer chip not firing or something along those lines.

I'll keep you posted when I find out more.. :-)

[davidgiven]

Thanks --- let me know how you get on; it'd be nice to get this working...

[andreasbaumann]

Found it in src/kernel/i8259.c, some registration of the IRQ handler was missing in real
mode:

/*=========================================================================*
 *				put_irq_handler				   *
 *=========================================================================*/
PUBLIC void put_irq_handler(hook, irq, handler)
irq_hook_t *hook;
int irq;
irq_handler_t handler;
{
/* Register an interrupt handler. */
  int id;
  irq_hook_t **line;

  if ((unsigned) irq >= NR_IRQ_VECTORS)
	panic("invalid call to put_irq_handler", irq);

  line = &irq_hooks[irq];
  id = 1;
  while (*line != NULL) {
	if (hook == *line) return;	/* extra initialization */
	line = &(*line)->next;
	id <<= 1;
  }
  if (id == 0) panic("Too many handlers for irq", irq);

  hook->next = NULL;
  hook->handler = handler;
  hook->irq = irq;
  hook->id = id;
  *line = hook;

  if (!protected_mode) set_vec(BIOS_VECTOR(irq), irq_vec[irq]); // <-- missing line!

  irq_use |= 1 << irq;
}

This happens also when running runqemu, ESC and forcing real mode in the boot loeader with bus=xt, processor=86.

I should have tried that earlier instead of fiddling with XT-IDE over serial with the Book8088, because I was convinced, it happens only on real hardware. Turns out, nobody tested Minix 2.0.4 with hardware in real mode some years ago, because those machines were considered obsolete even back then. :-)

[davidgiven]

Very good! Does this mean that the fix is simply putting that line back?

Also, I have some XT grade machines, and I'm sure I've tried it on them, although I now cannot remember whether it worked or not. It's entirely possible it didn't and I just put it down to some other issue. I'll need to try it again.

[andreasbaumann]

Yes, this is just a line which is present in minix-1.7.5 but not in minix-2.0.4.

[andreasbaumann]

@KedalionDaimon: you might be interested to try this on your book8088. :-)