headers
YhLu | 1 Jul 2004 06:05

答复: E7501 support in V2

Just check in E7501/ICH5R support into V2. the MB is tyan/s2735

Regards

YH

Intel E7501 P64H2 ICH5R support
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/cpu/p6/Config.lb src/cpu/p6/cpufixup.c
CVS:    src/include/device/pci_ids.h
CVS:    src/superio/winbond/w83627hf/superio.c
CVS: Added Files:
CVS:    src/cpu/p6/apic_timer.c src/cpu/p6/chip.h
CVS:    src/cpu/p6/disable_mmx_sse.inc src/cpu/p6/enable_mmx_sse.inc
CVS:    src/mainboard/tyan/s2735/Config.lb
CVS:    src/mainboard/tyan/s2735/auto.c
CVS:    src/mainboard/tyan/s2735/chip.h
CVS:    src/mainboard/tyan/s2735/cmos.layout
CVS:    src/mainboard/tyan/s2735/failover.c
CVS:    src/mainboard/tyan/s2735/irq_tables.c
CVS:    src/mainboard/tyan/s2735/mainboard.c
CVS:    src/mainboard/tyan/s2735/mptable.c
CVS:    src/northbridge/intel/e7501/Config.lb
CVS:    src/northbridge/intel/e7501/chip.h
CVS:    src/northbridge/intel/e7501/debug.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric W. Biederman | 1 Jul 2004 06:19

Re: qemu target

Stefan Reinauer <stepan <at> openbios.org> writes:

> * Eric W. Biederman <ebiederman <at> lnxi.com> [040630 19:10]:
> > Ok then most likely you have managed to get the debugging printk's
> > compiled out or something like that.  It should be possible to insert
> > a -g statement into the build and then to step through the code execution
> > with gdb.  qemu appears to have support for gdb stubs.
> > 
> > The real interesting part is what is the debug level set to.  And you can
> > get that with port 0x80.
> > 
> > Maybe we are attempting to use cmos options and that is not properly
> implemented?
> 
> 
> Actually that sounds very reasonable. all my builds where this happens
> are built without cmos support, and in this case the get_option()
> function always returns -2 iirc. 
> 
> I will give it a try enabling option tables 

Actually I was suggesting disabling option tables, to work around
this issue.

Anyway good luck.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric W. Biederman | 1 Jul 2004 06:50

Re: CPU refactoring status....


Ok before I head to bed and get some sleep here is a quick status
update of my refactoring the cpu initialization code.

The cpu tree for x86 cpu now looks like:

cpu/x86/mtrr
cpu/x86/lapic
cpu/x86/fpu
cpu/x86/mmx
cpu/x86/sse
... One directory for each generic feature we may want to reuse

cpu/intel/model_f0x/
cpu/intel/model_f1x/
cpu/intel/model_f2x/
cpu/intel/model_f3x/
... One directory for each core that is supported.
    The numbers are the significant bits from cpuid.
    Stepping differences are conglerated together.

cpu/intel/socket_mPGA603/
cpu/intel/socket_mPGA604_533Mhz/
cpu/intel/socket_mPGA604_800Mhz/
... One directory for each socket we support.
    These will use the dir directive to suck in the appropriate cores.

cpu/amd/model_fxx/ 
... So far for Opteron AMD really only has one core, with multiple steppings
(Continue reading)

Permalink | Reply | 19 comments |
headers
scheng | 6 Jul 2004 02:27

A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c

I am trying to use LinuxBIOS V2 + Filo to boot local Linux on hard disk
(EPIA 800 board).

I found that LinuxBIOS executes an infinite loop in dumpnorth() function
of freebios2/src/northbridge/via/vt8601/raminit.c .

The function is:
void
dumpnorth(device_t north)
{
	uint8_t r, c;
	for(r = 0; r < 256; r += 16) {
		print_debug_hex8(r);
		print_debug(":");
		for(c = 0; c < 16; c++) {
			print_debug_hex8(pci_read_config8(north, r+c));
			print_debug(" ");
		}
		print_debug("\r\n");
  }
}

Since r is an unsigned char, it will never reach 256. To fix the problem,
I simply added a line at the end of the loop: if( r >= 240 ) break;

*******************************************************************
By the way, I am still working on filo. In my machine, after elfboot
passing control to filo, LinuxBIOS  Fallback restarts again. Following is
a piece of screenshot:
......
(Continue reading)

Permalink | Reply | 11 comments |
headers
ron minnich | 6 Jul 2004 17:28

Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c

On Mon, 5 Jul 2004 scheng <at> msica.com wrote:

> I am trying to use LinuxBIOS V2 + Filo to boot local Linux on hard disk
> (EPIA 800 board).
> 
> I found that LinuxBIOS executes an infinite loop in dumpnorth() function
> of freebios2/src/northbridge/via/vt8601/raminit.c .
> 
> The function is:
> void
> dumpnorth(device_t north)
> {
> 	uint8_t r, c;
> 	for(r = 0; r < 256; r += 16) {
> 		print_debug_hex8(r);
> 		print_debug(":");
> 		for(c = 0; c < 16; c++) {
> 			print_debug_hex8(pci_read_config8(north, r+c));
> 			print_debug(" ");
> 		}
> 		print_debug("\r\n");
>   }
> }
> 
> Since r is an unsigned char, it will never reach 256. To fix the problem,
> I simply added a line at the end of the loop: if( r >= 240 ) break;

thanks for the fix, did you do something like this:

void
(Continue reading)

Permalink | Reply | 10 comments |
headers
Thomas Leidenfrost | 6 Jul 2004 18:01
Picon
Favicon

Wanted: Binary File for the Gene 4312 w/ NS Geode & Cx5530

Hello,

at the moment I'm using the Gene-4312-Board with the NS Geode CPU and 
the Cx5530. Reading the archive I found out, that some people were using 
a similar combination. So I wanted to ask, if somebody can send me a 
binary file that I simply can try to flash? (If it won't work, the 
original Bios is backupped in a seperate ROM).
And Is there any support for the onboard-flatpanel-connector?

Thanks in advance,

Tom.

--

-- 

Thomas Leidenfrost
Corscience GmbH & Co. KG
Henkestraße 91
91052 Erlangen

Tel: +49-9131-97798635
Fax: +49-9131-97798659
leidenfrost <at> corscience.de

_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
(Continue reading)

Permalink | Reply | 0 comments |
headers
scheng | 6 Jul 2004 18:26

Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c

> On Mon, 5 Jul 2004 scheng <at> msica.com wrote:
>
>> I am trying to use LinuxBIOS V2 + Filo to boot local Linux on hard disk
>> (EPIA 800 board).
>>
>> I found that LinuxBIOS executes an infinite loop in dumpnorth() function
>> of freebios2/src/northbridge/via/vt8601/raminit.c .
>>
>> The function is:
>> void
>> dumpnorth(device_t north)
>> {
>> 	uint8_t r, c;
>> 	for(r = 0; r < 256; r += 16) {
>> 		print_debug_hex8(r);
>> 		print_debug(":");
>> 		for(c = 0; c < 16; c++) {
>> 			print_debug_hex8(pci_read_config8(north, r+c));
>> 			print_debug(" ");
>> 		}
>> 		print_debug("\r\n");
>>   }
>> }
>>
>> Since r is an unsigned char, it will never reach 256. To fix the
>> problem,
>> I simply added a line at the end of the loop: if( r >= 240 ) break;
>
> thanks for the fix, did you do something like this:
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
ron minnich | 6 Jul 2004 18:36

Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c

On Tue, 6 Jul 2004 scheng <at> msica.com wrote:

> > Let me know if this works and I'll commit it.
> 
> Yes, it works.

I just committed the fix, thanks

what's you serial port baud rate? I can just send you one of our filo 
images to test.

Whats' your build machine again?

ron

_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Permalink | Reply | 3 comments |
headers
Eric W. Biederman | 6 Jul 2004 18:52

Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c

ron minnich <rminnich <at> lanl.gov> writes:

> On Mon, 5 Jul 2004 scheng <at> msica.com wrote:
> 
> > I am trying to use LinuxBIOS V2 + Filo to boot local Linux on hard disk
> > (EPIA 800 board).
> > 
> > I found that LinuxBIOS executes an infinite loop in dumpnorth() function
> > of freebios2/src/northbridge/via/vt8601/raminit.c .
> > 
> > The function is:
> > void
> > dumpnorth(device_t north)
> > {
> > 	uint8_t r, c;
> > 	for(r = 0; r < 256; r += 16) {
> > 		print_debug_hex8(r);
> > 		print_debug(":");
> > 		for(c = 0; c < 16; c++) {
> > 			print_debug_hex8(pci_read_config8(north, r+c));
> > 			print_debug(" ");
> > 		}
> > 		print_debug("\r\n");
> >   }
> > }
> > 
> > Since r is an unsigned char, it will never reach 256. To fix the problem,
> > I simply added a line at the end of the loop: if( r >= 240 ) break;
> 
> thanks for the fix, did you do something like this:
(Continue reading)

Permalink | Reply | 3 comments |
headers
ron minnich | 6 Jul 2004 18:58

Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c

On 6 Jul 2004, Eric W. Biederman wrote:

> Hmm..  Using bytes does not help the register pressure and in fact
> slightly increases code size.  If the byte register instructions
> on x86 were more symmetric this might be different, but...

sad that they don't work well. 
> 
> I cannot think of an architecture where using bytes would be better.
> The increase in code size is because of the need to clamp the values
> at their maximum so code like this fails properly.  

They exist :-)

thanks for the tip, this is very good to know.

thanks

ron

_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Permalink | Reply | 2 comments |

Gmane