OK things start to clear up.
The FAST_INIT register of the piix4e causes a cpu reset as a quick mean to get into real mode.
At this point the system hits onto LinuxBios which doesn't do callbacks, and it's game time-out. For a full reboot just add a board level reset when visiting LinuxBios a second time, cool.
Where does monte fit into the picture? It seems there is an issue with jumping to the 0xFFFFF0, as the board freezes...
Elias
-----Original Message-----
From: Elias Rajczyk
Sent: Monday, February 18, 2002 12:41 PM
To: '[EMAIL PROTECTED]'; Elias Rajczyk
Cc: [EMAIL PROTECTED]
Subject: RE: no reboot on linuxbios
Hi
We have a 440bx with piix4e. LinuxBios is being booted from flash.
After reading definitions of types of reboot and surfing the net and the kernel for additional information I got close to the top of confusion - maybe my doorbell will get the box rebooted(?)
We added "reboot=hard" to the command line. The following was observed :
1. On regular reboot the system freezes with no further notice.
2. The piix4e has a register that does a so-called FAST INIT when writing to it. It looks this is what you call software reboot. The register's definition says : "...provides a fast software executed processor reset function...".
Doing a FAST INIT kicks the system to a re-run of LinuxBios , this is the output of the re-run
"
Reached intel_main().
Updating microcode
microcode_info: sig = 0x00000686 pf=0x00000010 rev = 0x00000000
Finding PCI confiuration type...
PCI: Using configuration type 1
Scanning PCI bus...done
totalram: 2097152M
Enabling cache...
"
Here the system freezes, probably because the cache can't handle the INCORRECT amount of memory - the system has 256M .
What confuses me is that monte causes the same output, but only with reboot=hard . Shouldn't monte jump right away to the new kernel?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 18, 2002 1:06 AM
To: Elias Rajczyk
Cc: [EMAIL PROTECTED]
Subject: Re: no reboot on linuxbios
Elias Rajczyk <[EMAIL PROTECTED]> writes:
>
> We have problem rebooting our system with LinuxBios. After the command
> "reboot" the system freezes.
Knowing what hardware you are running LinuxBIOS on would help to debug this.
> There were plenty of mails on this subject saying this issue is caused by
> the pentium chip missing a reset instruction and others saying the cause is
> linux's way of rebooting is wrong. Well, apparently cause/cure are elsewhere
> : the system that freezes when rebooting with LinuxBios, restarts just fine
> in all modes (reset,hot reboot,soft reboot) with regular Bios.
> Apparently LinuxBios misses some system configuration...
Ron seems to be asking for my input so here goes.
1) There are three kinds of reboot.
a) software only (monte or kexec) or jump to 0xFFFFF0 in 16 bit mode.
b) cpu only (This will reliably get you back into the x86 firmware)
c) reset line on the entire motherboard.
2) When an x86 cpu tripple faults, or receives a reset signal it
hangs, until the it receives a signal that it is o.k. to continue.
It takes some close reading of the documentation to see this but is
is documented for both Athlons and Pentiums. Usually it is the
southbridge that controlls the reboot behaviour, on some
southbridges it defaults to setting this up correctly, and on
southbridges some registers need to be setup for this to work.
3) There are two options to reboot Linux under LinuxBIOS.
a) issue the corrent port I/O instruction to the hardware
to get a board level reboot. This is what Ron and Ollie
usually do. I support this but we need a way to specify
in the LinuxBIOS table where this is in case there are multiple
possibilities on the motherboard.
b) specify "reboot=hard" on the kernel command line and get a cpu
only reset either throught a triple fault or the keyboard
controller. This gets you back into LinuxBIOS and with the
a little additional code to skip the memory setup, you can issue
the board level reset from LinuxBIOS.
Things are a bit different here because LinuxBIOS by design does
not support any callbacks. Which does break the kernels default
reboot method of jumping to the BIOS (and we don't leave one
running).
I have been implementing option (b) at least initially because
it lets me avoid requiring a patched kernel. Which makes
maintenance much easier.
Eric
