when compiling my linux kernel i keep on recieving this message:
Warning: Clock Skew Detected Build May Be Incomplete
It seams to compile ok.
What does this error message mean?? and how can i fix it.
thanks
edwin
ps. I have only been getting this message since i upgraded to an AMD K6-2 500Mhz.
Hi, Guys does anyone know how I can test the USB controller on the
intel 82371FB (PIIX3) chipset or know of a web site that has source
code in assembly language that will acomplish this.
//Ross
I have begun to hack on OpenBIOS and am looking to add support for x86 and
the Aladdin V chipset (ie: Super Socket7, Asus P5A, etc...). If anyone
else has started work on this, or plans to, it would be nice to talk.
-- Burl.
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
Chong Chee Yong <catz(a)silvermoon.com.sg> wrote:
> > (this is all defined in the PCI spec) To scan the PCI bus, you
> > basically iterate through each slot, reading the device and vendor ids.
> > If the slot is empty you get a nonexistent value (either 0 or 0xffff I
> > think). There can also be bridges on the PCI bus, so you must
> > recursively descending into those, and scan their devices, as well.
>
> Haven't read the PCI bridges specs, but it seems that it is possible
> for two unconnected PCI bus since the algorithm suggested in revision 2.2
> Chapter 6.1 is to scan all possible slots.
I believe that this (or something similar) has been implemented on some
newer Compaq servers. There are a number of workarounds in the kernel PCI code.
If someone has access to one of these, an lspci -xxx output would make
interesting reading.
regards,
--
Dave.
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
any hints on what to do just to get timer interrupts going are most
welcome :-)
geez, this is getting close!
ron
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
I'm now in linux main. I was right at trap_init then the WinDB debugger
program exploded.
I love it.
ron
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
On Mon, 28 Feb 2000, Burl Nyswonger wrote:
> > when you say super socket 7 chipsets -- does this include AMD?
> > edwin
> I meant "Super Socket 7 boards" in general -- ie: the Asus P5 series, Acer
> boards (obviously), etc... When I say "Aladdin V Chipset", I am referring
OK, this brings up an interesting issue for the OpenBIOS community. At
least one Socket 7 motherboard will support either alpha or pentium in the
socket. So it's the same motherboard with a different processor. All
startup tasks for the motherboard are pretty much the same.
I had an interesting set of discussions with vendors at extreme linux last
week. There's a lot of interest in linuxbios -- from Alpha motherboards
too (the alpha bios'es all have sucked very badly -- dec never got it
right).
As things stand openbios is too pentium-specific. So I'd like to propose
an idea.
1) get into protected mode early
2) get rid of as much assembly as possible
there's a lot that can move to C
so we change the layout a bit. It's still early in the game, we can do
this.
A possible layout:
bios/arch/i386/{poweron.s,protected_mode.s,memory.s,motherboard.c,boot.c}
bios/arch/alpha/{poweron.s,protected_mode.s,memory.s,motherboard.c,boot.c}
bios/payload/{your c files here}
poweron.s is the very first set of things you do on poweron -- should be a
few instructions. protected_mode.s bumps you into protected mode. On the
pentium this is a few instructions. memory.s turns on memory -- this is
*much* easier on the pentium in protected mode. memory.s should set up a
stack and jump to C code. Motherboard.c does anything that has to be done
to further use the motherboard. Boot.c gunzips the payload (either a
bios-compatible code or Linux or FreeBSD or whatever) and jumps to it.
I'm talking to a commercial company that is going to do something like
this -- they don't want much assembly long-term, so they're recrafting
openbios. I don't think most people want to do assembly.
If we do this, we're not just for pentiums any more. That would be
wonderful! Any interest?
ron
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
Is anyone else out there working on adding PCI enumeration to OpenBIOS?
Any one have any pointers to code I can theft, er, reuse? I'm looking at
the function pci_scan_bus() in the linux source code (drivers/pci/pci.c),
but that looks like it just reads the results of an already-enummerated
PCI bus.
Help would be greatly appreciated.
Brian
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
Hi!
I just read about your project. Really cool! Ofcourse you wan't to boot linux
as fast as possible.
My friend David and I have spent a few hours surfing around for a BIOS able to
boot FAST. We'd like to use it for the fuel injection system we're building for
my car. The computer should not only control fuel delivery and ignition but
also play mp3. Preferably controlled using Sony's CD-changer protocol, but that
is far away.
Anyway, if you BIOS is able boot linux / rtlinux fast it would be great! That's
all we need. We don't want the slow code BIOS manifacturers put in for DOS and
other stuff.
I'll check your news page to see your progress.
Keep up the good work.
Daniel Haglund
dhaglund(a)mail.uccs.edu
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
I am now successfully gunzipping the kernel into ram. At some point this
will finish (yow it's slow under the debugger I'm using!) and I'll jump to
it, say in another 15 minutes :-)
we'll see.
The fixes I mentioned to inflate.c are essential.
ron
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
