Ronald G Minnich wrote:
>
Hi
AFAIK the usual bios does the reset int the following
manner: (might only bee x86 mode)
-------------hard soft reset-------------
1) set up an error handler on bootup which tries to fix the error beeing occured
2) on error let the processor immediatly jump to the fatal error handler if software
doesn't have its own.
3) try to fix the error and get to a safe place
4) if the error also destroyed the safe place or the error wasn't cleared away
tidy up the processor set him to proper initial mode and let him jump to the
bootup address
-------------soft soft reset (only if bios is capable of-------
1a) bios resides unreloadable in memory or better most of its bootup findings
(bios and linux keep it their hardware and boot status settings in a place
near the initail boot address resitant against any clearance
2a) on error jump to handler and let him remember that the last sucessful reboot on
the last poweron had some hw settings (memory timestamp+monotonous growing reboot
counter(startup=0)+
crc on all valid harware configuration data+the bootstage the system brailed
out(or if hw error what was
the last working system status before error)
4a) on reboot first go back to initial address and check if the settings are still
valid
means the monotonous reboot counter now equals the saved one +1
if this is true check the crc and the last stage known as having functional
settings
if these are also valid than go ahead an sinply reload all you know
tell the kernel on bootup that it simply can reload the settings (or just set all
via append)
5) if checks in 4a fail (counter more than old counter +1 or counter at overflow)
go back to hard soft reset (hw settings stamp is set to 0)
6) give a detailed report on reset (done by a logger like the one for the kernel)
I know that this sounds much easier as it is
I know too that i' don't know much about Linux and that my last contact with
assembler was 8 jeras agon on a
286/386 so things have changed a bit.
But might be that on finalisation of linuxbios you get back to it (could be me my
selve)
cu
Christoph
> I'm going to do something much like what we do for other mainboard
> functions in linux (see irq setup).
>
> I'll have an struct like so:
>
> struct resethardware {
> unsigned short vendor, device;
> unsigned char registernumber;
> unsigned char bit;
> unsigned char val;
> };
>
> This will be populated with an array of things, viz:
> struct resethardware resets[] = {
> /* note: I know these are the wrong bits */
> {VENDOR_INTEL, PIIX4E, 0x3c, 0x5, 1},
> {VENDOR_SIS, SIS630, 0x47, 0x5, 0}
> };
>
> Then you call hardware reset.
>
> Hardware reset does this:
>
> 1) find the first pcidev in the resets array that matches the actual
> hardware
> 2) using the pcidv, set bit 'bit' to val 'val' in register
> 'registernumber'
>
> Comments?
>
> ron
--
THESIS: God is alive
PROOVE: Who else would have scheduled the mankind and world first
recommendation of resurch????
CONCLUSION: Scientist do what he wants, willing or not:)
