[EMAIL PROTECTED] writes:
> After successful testing linuxbios with my 440bx board, now I'm trying to
> port linuxbios to an 815ep board (Gigabyte GA-6OXE). Maybe I'm too brave, I
> have trouble just enabling serial. T_T
>
> I thought i can get serial working without any 815ep chipset initialiation
> (especially ICH2)because 440bx(maybe other chipset also) does. Am I right?
>
> Therfore, At first, I wrote little initialization code for ITE it8712f
> super I/O chip because it is not exist in current cvs tree. Then before
> doing raminit.inc I tested serial output with TTYS0_TX_STRING() and do
> 'hlt' intruction to stop. However, as you may think, I can't get the
> message from serial.
>
> I think there's 3 possiblity.
> 1) ITE it8712ef initialization code which i wrote is wrong.
> I wrote this code as described in the data sheet, so i think
> there's no problem. But, maybe it is possible i did some stupid
> typo
> or something so I attached this code. Data sheet can be found at
> http://www.ite.com.tw/productInfo/Download.html#IT8712F
The code looks o.k. I would explicitly set the serial port resources
io port 0x3f8 for serial 1 though.
>
> 2) DualBIOS is the problem.
> My board comes with physically two same bios installed. gigabyte
> says
> if one of them fail (both physically and logically mis programmed)
> another bios
> takes over. They called it as DualBIOS technology.
> What I don't know, so I suspect, is how they decide a bios is
> failed.
> Linuxbios is failed bios? hmm. I mailed to gigabyte about this, but
> no response
> until now.
Possibly. You should be able to have it up long enough to get output
out the serial port before it fails. Unless it does a checksum in hardware.
> 3) My theory is wrong. ICH2 must be initialized before accessing super i/o
> chip.
> For now, I don't know much about ICH2, MCH, ... I just printed
> their data sheet. :)
I do know for certain the ICH2 doesn't need to be initialized. I just
got my i860 board going.
> Any help, comment, will be very valuable to me.
However. It looks like the intels HUB chipset flags rom write failures. Which
happens when you access the ROM when switching to 32bit protected mode.
Our current gdt is wrong. Please try the following in entry16.inc.
The change is from 9a -> 9b and 92 -> 93. The low bit is the accessed bit
and when the accessed bit is set the processor doesn't attempt to access the
rom.
Acording to intels P6 documentation this can be a problem, and most likely
was not specific to the Pentium 4.
gdt:
.word 0x0000, 0x0000 /* dummy */
.byte 0x0, 0x0, 0x0, 0x0
.word 0x0000, 0x0000 /* dummy */
.byte 0x0, 0x0, 0x0, 0x0
.word 0xffff, 0x0000 /* flat code segment */
.byte 0x0, 0x9b, 0xcf, 0x0
.word 0xffff, 0x0000 /* flat data segment */
.byte 0x0, 0x93, 0xcf, 0x0
Eric
