From yinghai.lu at amd.com  Sat Apr  1 03:24:07 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 31 Mar 2006 17:24:07 -0800
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B5A@ssvlexmb2.amd.com>

Svn diff to current tree.

Please check it. I will commit it some time next week.

Guys have problem with s2891, s2881, s2892, please try it by 

patch -p0 to the latest tree.


Changes
1. new CAR with copy data from cache to ram
2. new coherent_ht_car.c
3. new reset code for amd8111
4. new amd8111_early_ctrl without sysinfo...

Thanks

Yinghai Lu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 03312006_new_cache_as_ram.diff.bz2
Type: application/octet-stream
Size: 20020 bytes
Desc: 03312006_new_cache_as_ram.diff.bz2
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060331/9bed2552/attachment.obj>

From smithbone at gmail.com  Sat Apr  1 06:20:55 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 31 Mar 2006 22:20:55 -0600
Subject: [LinuxBIOS] Advantech SOM GX5333 commited
Message-ID: <8a0c36780603312020s2c0386cap53cdee37be926b0e@mail.gmail.com>

I just committed the support for the the SOM-2354 CPU board running on
a SOM-DB2301 base board.

MSR 20000018 was from the rumba setup which didn't work on this board.
 Current value was ripped from how XpressROM set it.  Other than that
all I had to change was the superIO.

The unit boots jumps to linubios and looks for the vsabin which it
can't find since its not there.

What's next?

I have also made a little bit of progress on compiling the VSA. 
OpenWatcom has a 16-bit compiler and I've been hacking the makefile(s)
to get it to work.  OWC has a cl compability mode but IFAICT its 32bit
only.  I've attemped to translate the switches.

I'm currently at the point of trying to figure out how to feed the OWC
linker all the object files.

--
Richard A. Smith

From stepan at coresystems.de  Sat Apr  1 12:18:58 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 1 Apr 2006 12:18:58 +0200
Subject: [LinuxBIOS] Geode SC22000
In-Reply-To: <WorldClient-F200603311416.AA16200026@t2data.se>
References: <WorldClient-F200603311416.AA16200026@t2data.se>
Message-ID: <20060401101858.GA19266@openbios.org>

* Per Hallsmark <perh at t2data.se> [060331 14:16]:
> The LB base is svn ver 2171, I've got a 71K big patch for it.
> How do I contribute it to LB tree?
 
Just send an "svn diff" as an attachment to this list.

> Q1: The source code files often include source files again instead
> of like building object modules that are later linked together.
> Why something like this? It seems odd to me as an perhaps oldschool
> C programmer.
 
That's done in the romcc compiled code. The reason is that you can only
know how the code looks like as a whole, the single parts look pretty
different depending on the register pressure. Remember: This code is
compiled to assembler code that does not use _any_ memory but runs in
registers only.

> Q2: Why does the LB project need a special compiler?
> I've done numberous of firmware stuff and ordinary gnu tools have a
> good job so far.
> Must admit though that these hasn't been x86 which of course has it
> special boot mode, but there exist "standard" tools for that as well.
> (RPM package dev86 for example)
 
It does not _need_ one. The thing is, we don't want to write ram
initialization code for complex systems (such as the amd64) in assembler
but instead in more readable and understandable C code.
Since, consequentially, there is no RAM during RAM initialization, you
need to make sure the code fits into registers only.

No other C compiler except romcc does that.

Some platforms also allow you to do cache as ram, which uses the cpu
cache as a small amount of "fake ram". The advantage is: When this works
you can use gcc, which compiles faster and results in much smaller code.

We're trying to do this on all systems where it works reliably, but
LinuxBIOS is a burned child with respect to CAR (as we usually call
cache as ram) because the needed mechanisms changed per minor cpu
revision on intel systems a while ago which made the whole thing
reaaally fragile.

> Q3: Documentation...
> I was perhaps a bit optimistic when I thought the LB port should
> take one week, it was more like one month :-)
> But more documentation could help here a lot, or are there docs
> outside of linuxbios.org I've missed? Any work in progress here
> or can I contribute to it somehow?

There's Ron's great article on porting to the sc520 and I've written a
paper on AMD64 porting a whole while ago. Both should be linked in on
linuxbios.org though. 

More (formal) documentation is really needed though, indeed.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ollie at lanl.gov  Sat Apr  1 16:45:44 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sat, 1 Apr 2006 07:45:44 -0700 (MST)
Subject: [LinuxBIOS] Advantech SOM GX5333 commited
In-Reply-To: <8a0c36780603312020s2c0386cap53cdee37be926b0e@mail.gmail.com>
References: <8a0c36780603312020s2c0386cap53cdee37be926b0e@mail.gmail.com>
Message-ID: <26587.128.165.0.81.1143902744.squirrel@webmail.lanl.gov>

> I just committed the support for the the SOM-2354 CPU board running on
> a SOM-DB2301 base board.
>
> MSR 20000018 was from the rumba setup which didn't work on this board.
>  Current value was ripped from how XpressROM set it.  Other than that
> all I had to change was the superIO.
>

I have better version of programming MSR 20000018 around. I will try
to commit it next week. Does your board have SPD?

> The unit boots jumps to linubios and looks for the vsabin which it
> can't find since its not there.
>
> What's next?
>

Put your VSAINIT.BIN+SYSMGR.BIN at the bottom of your flash (like what
we did with VGA BIOS). Point the address where vsmsetup want to look
for VSM to the bottom of your flash. It sould be able to find the
vsa. BTW, the code on the current SVN has some serious bug (forget to
call setup_realmode_idt() before vsmsetup()) so it will crash soon
after jump into VSA. I will commit it fix next week.

I think there are still one or two MSR we have to program and probably
we need big real mode instead of the real mode for VSA to work. I will
dig into it more with the JTAG debugger later.

> I have also made a little bit of progress on compiling the VSA.
> OpenWatcom has a 16-bit compiler and I've been hacking the makefile(s)
> to get it to work.  OWC has a cl compability mode but IFAICT its 32bit
> only.  I've attemped to translate the switches.
>
> I'm currently at the point of trying to figure out how to feed the OWC
> linker all the object files.
>

Did you try to find on MSVC on ebay? BTW, by googleing the net
I found some VC/MASM are freely avaliable through MSDN. Do you
want to try it too?

Ollie





From ollie at lanl.gov  Sat Apr  1 16:50:52 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sat, 1 Apr 2006 07:50:52 -0700 (MST)
Subject: [LinuxBIOS] Geode SC22000
In-Reply-To: <WorldClient-F200603311416.AA16200026@t2data.se>
References: <WorldClient-F200603311416.AA16200026@t2data.se>
Message-ID: <26777.128.165.0.81.1143903052.squirrel@webmail.lanl.gov>

> Hello LB people,
>
> First, a great thank for the quick boost I had from your project
> in creating a special firmware for our project.
>
> I've ported LB to a SC2200 based platform, NCG266 (you can see some
> old photos at www.nano-system.com) The jump to the load just takes
> a couple of secs instead of like a minute with the Insyde BIOS...
>

Is there any reason you are working on an EOL product?

Ollie




From jardel at lesc.ufc.br  Sat Apr  1 18:24:14 2006
From: jardel at lesc.ufc.br (jardel at lesc.ufc.br)
Date: Sat, 1 Apr 2006 13:24:14 -0300 (BRT)
Subject: [LinuxBIOS] Advantech SOM GX5333 commited
In-Reply-To: <26587.128.165.0.81.1143902744.squirrel@webmail.lanl.gov>
References: <8a0c36780603312020s2c0386cap53cdee37be926b0e@mail.gmail.com>
	<26587.128.165.0.81.1143902744.squirrel@webmail.lanl.gov>
Message-ID: <2790.201.50.73.202.1143908654.squirrel@www.lesc.ufc.br>

Dear,


What about vsa legal questions ?
Are you using the source code available from insyde site ?
Has amd licensed VSA under GPL ?


Thanks.


Jardel.

>> I just committed the support for the the SOM-2354 CPU board running on
>> a SOM-DB2301 base board.
>>
>> MSR 20000018 was from the rumba setup which didn't work on this board.
>>  Current value was ripped from how XpressROM set it.  Other than that
>> all I had to change was the superIO.
>>
>
> I have better version of programming MSR 20000018 around. I will try
> to commit it next week. Does your board have SPD?
>
>> The unit boots jumps to linubios and looks for the vsabin which it
>> can't find since its not there.
>>
>> What's next?
>>
>
> Put your VSAINIT.BIN+SYSMGR.BIN at the bottom of your flash (like what
> we did with VGA BIOS). Point the address where vsmsetup want to look
> for VSM to the bottom of your flash. It sould be able to find the
> vsa. BTW, the code on the current SVN has some serious bug (forget to
> call setup_realmode_idt() before vsmsetup()) so it will crash soon
> after jump into VSA. I will commit it fix next week.
>
> I think there are still one or two MSR we have to program and probably
> we need big real mode instead of the real mode for VSA to work. I will
> dig into it more with the JTAG debugger later.
>
>> I have also made a little bit of progress on compiling the VSA.
>> OpenWatcom has a 16-bit compiler and I've been hacking the makefile(s)
>> to get it to work.  OWC has a cl compability mode but IFAICT its 32bit
>> only.  I've attemped to translate the switches.
>>
>> I'm currently at the point of trying to figure out how to feed the OWC
>> linker all the object files.
>>
>
> Did you try to find on MSVC on ebay? BTW, by googleing the net
> I found some VC/MASM are freely avaliable through MSDN. Do you
> want to try it too?
>
> Ollie
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>





From ollie at lanl.gov  Sun Apr  2 01:48:40 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sat, 1 Apr 2006 16:48:40 -0700 (MST)
Subject: [LinuxBIOS] Advantech SOM GX5333 commited
In-Reply-To: <2790.201.50.73.202.1143908654.squirrel@www.lesc.ufc.br>
References: <8a0c36780603312020s2c0386cap53cdee37be926b0e@mail.gmail.com><26587.128.165.0.81.1143902744.squirrel@webmail.lanl.gov>
	<2790.201.50.73.202.1143908654.squirrel@www.lesc.ufc.br>
Message-ID: <56529.128.165.0.81.1143935320.squirrel@webmail.lanl.gov>

> Dear,
>
>
> What about vsa legal questions ?
> Are you using the source code available from insyde site ?
> Has amd licensed VSA under GPL ?
>

We got source code from AMD. It is not GPL but more like MIT/X.
I think we should be able to redistribute the source code but
I have to make sure again.

Ollie




From perh at t2data.se  Mon Apr  3 10:19:06 2006
From: perh at t2data.se (Per Hallsmark)
Date: Mon, 03 Apr 2006 10:19:06 +0200
Subject: [LinuxBIOS] Geode SC22000
In-Reply-To: <20060401101858.GA19266@openbios.org>
References: <WorldClient-F200603311416.AA16200026@t2data.se>
	<20060401101858.GA19266@openbios.org>
Message-ID: <WorldClient-F200604031019.AA19060047@t2data.se>

Hi again,

Ok, here comes the svn diff (towards 2171) attached.
It's quite big, had to add superio and southbridge setups
(along with it's attached devices) which is embedded in
the SC2200. It was unfortunally not just a small port of
the current GX1...
There is some extra POST codes inserted to follow code flow,
perhaps this should be removed before adding patch into live tree.

I've also started a (yet another) porting guide, intent
is to make it more detailed and also describe "obvious"
steps that perhaps is not so obvious for a linuxbios beginner.
(at least it wasn't for me :-) )

Have a GX3 eval board (ITX form) somewhere on my desk, will
be a good testdrive porting according to document.

I've seen some logs here on mailing list that have nice
timestamps in first column. Is there some standard support
for this in LinuxBIOS? (have searched around in code but
couldn't find it)

Stefan, thanks for you answers. I'm still a bit puzzled though
why PPC, ARM, XScale, MIPS manages same thing without romcc or similar.
Is memory setup done so very much different and is so much more
complex in x86? For my port, SC2200, it looks about same to me.
(could be because of my embedded background, most targets have
 had defined memory size so mem sizing isn't a problem...)

-----Original Message-----
From: Stefan Reinauer <stepan at coresystems.de>
To: Per Hallsmark <perh at t2data.se>
Cc: linuxbios at linuxbios.org
Date: Sat, 1 Apr 2006 12:18:58 +0200
Subject: Re: [LinuxBIOS] Geode SC22000

> * Per Hallsmark <perh at t2data.se> [060331 14:16]:
> > The LB base is svn ver 2171, I've got a 71K big patch for it.
> > How do I contribute it to LB tree?
>  
> Just send an "svn diff" as an attachment to this list.
> 
> > Q1: The source code files often include source files again instead
> > of like building object modules that are later linked together.
> > Why something like this? It seems odd to me as an perhaps oldschool
> > C programmer.
>  
> That's done in the romcc compiled code. The reason is that you can only
> know how the code looks like as a whole, the single parts look pretty
> different depending on the register pressure. Remember: This code is
> compiled to assembler code that does not use _any_ memory but runs in
> registers only.
> 
> > Q2: Why does the LB project need a special compiler?
> > I've done numberous of firmware stuff and ordinary gnu tools have a
> > good job so far.
> > Must admit though that these hasn't been x86 which of course has it
> > special boot mode, but there exist "standard" tools for that as well.
> > (RPM package dev86 for example)
>  
> It does not _need_ one. The thing is, we don't want to write ram
> initialization code for complex systems (such as the amd64) in
> assembler
> but instead in more readable and understandable C code.
> Since, consequentially, there is no RAM during RAM initialization, you
> need to make sure the code fits into registers only.
> 
> No other C compiler except romcc does that.
> 
> Some platforms also allow you to do cache as ram, which uses the cpu
> cache as a small amount of "fake ram". The advantage is: When this
> works
> you can use gcc, which compiles faster and results in much smaller
> code.
> 
> We're trying to do this on all systems where it works reliably, but
> LinuxBIOS is a burned child with respect to CAR (as we usually call
> cache as ram) because the needed mechanisms changed per minor cpu
> revision on intel systems a while ago which made the whole thing
> reaaally fragile.
> 
> > Q3: Documentation...
> > I was perhaps a bit optimistic when I thought the LB port should
> > take one week, it was more like one month :-)
> > But more documentation could help here a lot, or are there docs
> > outside of linuxbios.org I've missed? Any work in progress here
> > or can I contribute to it somehow?
> 
> There's Ron's great article on porting to the sc520 and I've written a
> paper on AMD64 porting a whole while ago. Both should be linked in on
> linuxbios.org though. 
> 
> More (formal) documentation is really needed though, indeed.
> 
> Stefan
> 
> -- 
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>       Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LinuxBIOSv2-2171.patch
Type: application/octet-stream
Size: 71653 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060403/d935a99e/attachment.obj>

From stepan at coresystems.de  Mon Apr  3 13:37:23 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Apr 2006 13:37:23 +0200
Subject: [LinuxBIOS] help
In-Reply-To: <5c5dcf370604030427m7d9c5355ue70b892f821d13e5@mail.gmail.com>
References: <5c5dcf370604030427m7d9c5355ue70b892f821d13e5@mail.gmail.com>
Message-ID: <20060403113723.GA18996@openbios.org>

* Neil <myneil at gmail.com> [060403 13:27]:
> Hi,
> I am a freshman to linuxbios. And I am preparing porting linuxbios on my
> motherboard .
> My northbridge is Server works (SWC HT2000),and southbridge is Serverworks
> HT-1000, I don't know if it supports the chipset? could you please tell me ?
> and I cannot find relate source code in the source tree , should I create it
> myself ?

I think its the same as the Broadcom BCM5780/85. Yinghai Lu did the port
iirc.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ulrich.vanbrakel at pr0sys.com  Mon Apr  3 15:04:36 2006
From: ulrich.vanbrakel at pr0sys.com (ulrich.vanbrakel at pr0sys.com)
Date: Mon, 03 Apr 2006 15:04:36 +0200
Subject: [LinuxBIOS] linuxbios on nodes?
Message-ID: <20060403150436.3rdlb472i75wo888@webmail.pr0sys.com>

Hi everyone,

regarding linuxbios:
Do I have to load linuxbios on both "server PC" and nodes,
or can I get away with loading it on the nodes only?

ps. if this is any help, I am planning on using Clustermatic ..




From rminnich at lanl.gov  Mon Apr  3 18:17:08 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Apr 2006 10:17:08 -0600
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B57@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B57@ssvlexmb2.amd.com>
Message-ID: <44314A84.6030207@lanl.gov>

Lu, Yinghai wrote:
> I'm going to check in new cache_as_ram code. It is more solid and could
> copy data from cache to ram. So we can pass some info from CAR stage to
> RAM stage.
> 
> I want to change the default value for CONFIG_LB_MEM_TOPK from 1024 to
> 2048.
> So I don't need to change every Opteron MB Config.lb...

it's fine with me.

ron



From yinghai.lu at amd.com  Mon Apr  3 18:48:49 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 3 Apr 2006 09:48:49 -0700
Subject: [LinuxBIOS] linuxbios on nodes?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B5F@ssvlexmb2.amd.com>

Yes, you can use LinuxBIOS on nodes only.

But I can not find the reason not to use LinuxBIOS on node..., any
concern?

YH





From ulrich.vanbrakel at pr0sys.com  Mon Apr  3 19:15:26 2006
From: ulrich.vanbrakel at pr0sys.com (ulrich.vanbrakel at pr0sys.com)
Date: Mon, 03 Apr 2006 19:15:26 +0200
Subject: [LinuxBIOS] linuxbios on nodes?
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B5F@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B5F@ssvlexmb2.amd.com>
Message-ID: <20060403191526.k6le1opx2cw0os0o@webmail.pr0sys.com>

Quoting "Lu, Yinghai"
> Yes, you can use LinuxBIOS on nodes only.
>
> But I can not find the reason not to use LinuxBIOS on node..., any
> concern?
I have no concern flashing the node pc's.. as they are "Out of Warranty"
but the "Main Server" is still "Under Warranty" .. and I'm scared I that
if I mess up...







From rminnich at lanl.gov  Mon Apr  3 20:48:24 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Apr 2006 12:48:24 -0600
Subject: [LinuxBIOS] Geode SC22000
In-Reply-To: <WorldClient-F200603311416.AA16200026@t2data.se>
References: <WorldClient-F200603311416.AA16200026@t2data.se>
Message-ID: <44316DF8.7030802@lanl.gov>

Per Hallsmark wrote:

> Q1: The source code files often include source files again instead
> of like building object modules that are later linked together.
> Why something like this? It seems odd to me as an perhaps oldschool
> C programmer.

this is a romcc issue. It pretty much has to work this way. romcc has 
almost no function calls, as there is no stack, so all must be inlined.

> 
> Q2: Why does the LB project need a special compiler?
> I've done numberous of firmware stuff and ordinary gnu tools have a
> good job so far.

GNU can't be convinced to run without
1) memory
2) stack

> Q3: Documentation...
> I was perhaps a bit optimistic when I thought the LB port should
> take one week, it was more like one month :-)
> But more documentation could help here a lot, or are there docs
> outside of linuxbios.org I've missed? Any work in progress here
> or can I contribute to it somehow?

yes, please send a HOWTO of your experience and it goes on the web page.

docs are ALWAYS welcome.

thanks. please send me the patch.

ron




From rminnich at lanl.gov  Mon Apr  3 20:55:14 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 03 Apr 2006 12:55:14 -0600
Subject: [LinuxBIOS] linuxbios on nodes?
In-Reply-To: <20060403150436.3rdlb472i75wo888@webmail.pr0sys.com>
References: <20060403150436.3rdlb472i75wo888@webmail.pr0sys.com>
Message-ID: <44316F92.90908@lanl.gov>

ulrich.vanbrakel at pr0sys.com wrote:
> Hi everyone,
> 
> regarding linuxbios:
> Do I have to load linuxbios on both "server PC" and nodes,
> or can I get away with loading it on the nodes only?
> 
> ps. if this is any help, I am planning on using Clustermatic ..
> 
> 
you can load it on nodes only.

ron



From yinghai.lu at amd.com  Mon Apr  3 22:40:07 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 3 Apr 2006 13:40:07 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B63@ssvlexmb2.amd.com>

Committed.

Also enable HT 1GHz support for s2891 and s2892.

Thanks

Yinghai Lu

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Lu, Yinghai
Sent: Friday, March 31, 2006 5:24 PM
To: Ronald G Minnich; Stefan Reinauer; Jason Schildt
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK

Svn diff to current tree.

Please check it. I will commit it some time next week.

Guys have problem with s2891, s2881, s2892, please try it by 

patch -p0 to the latest tree.


Changes
1. new CAR with copy data from cache to ram
2. new coherent_ht_car.c
3. new reset code for amd8111
4. new amd8111_early_ctrl without sysinfo...

Thanks

Yinghai Lu





From stepan at coresystems.de  Mon Apr  3 22:48:59 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Apr 2006 22:48:59 +0200
Subject: [LinuxBIOS] [linuxbios-checkins] r2232 breaks all opteron
	boards.
In-Reply-To: <E1FQVoq-0004Jk-3g@khepri.openbios.org>
References: <E1FQVoq-0004Jk-3g@khepri.openbios.org>
Message-ID: <20060403204859.GA18403@openbios.org>

Yinghai,

your latest checkin breaks _all_ opteron boards.

in particular your "new reset functionality" - why exactly is that
needed?

Please go ahead and fix it. All opteron ports were compiling fine with
r2231.

compare 
  http://snapshots.linuxbios.org/stats/abuild-LinuxBIOSv2-2231.log
and
  http://snapshots.linuxbios.org/stats/abuild-LinuxBIOSv2-2232.log



Stefan

* svn at openbios.org <svn at openbios.org> [060403 22:38]:
> Author: yhlu
> Date: 2006-04-03 22:38:34 +0200 (Mon, 03 Apr 2006)
> New Revision: 2232
> 
> Added:
>    trunk/LinuxBIOSv2/src/cpu/amd/car/clear_init_ram.c
>    trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/coherent_ht_car.c
> Modified:
>    trunk/LinuxBIOSv2/src/arch/i386/include/arch/romcc_io.h
>    trunk/LinuxBIOSv2/src/config/Options.lb
>    trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc
>    trunk/LinuxBIOSv2/src/cpu/amd/car/copy_and_run.c
>    trunk/LinuxBIOSv2/src/cpu/amd/car/disable_cache_as_ram.c
>    trunk/LinuxBIOSv2/src/cpu/amd/car/post_cache_as_ram.c
>    trunk/LinuxBIOSv2/src/cpu/amd/model_fxx/init_cpus.c
>    trunk/LinuxBIOSv2/src/cpu/x86/lapic/lapic_cpu_init.c
>    trunk/LinuxBIOSv2/src/devices/hypertransport.c
>    trunk/LinuxBIOSv2/src/include/cpu/x86/mem.h
>    trunk/LinuxBIOSv2/src/mainboard/agami/aruma/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/get_bus_conf.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/resourcemap.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/get_bus_conf.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Config.lb
>    trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/cache_as_ram_auto.c
>    trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/coherent_ht.c
>    trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/incoherent_ht.c
>    trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/raminit.c
>    trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/reset_test.c
>    trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/Config.lb
>    trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111_early_ctrl.c
>    trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111_lpc.c
>    trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111_reset.c
>    trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804_early_setup.c
>    trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804_early_setup_car.c
>    trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804_enable_rom.c
>    trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804_smbus.h
>    trunk/LinuxBIOSv2/targets/tyan/s2892/Config.lb
>    trunk/LinuxBIOSv2/targets/tyan/s2895/Config.lb
> Log:
> new cache_as_ram support 

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From yinghai.lu at amd.com  Mon Apr  3 23:25:04 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 3 Apr 2006 14:25:04 -0700
Subject: [LinuxBIOS] [linuxbios-checkins] r2232 breaks all opteron
 boards.
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B64@ssvlexmb2.amd.com>

Fixed. Please check again.

YH





From stepan at coresystems.de  Tue Apr  4 00:55:13 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 4 Apr 2006 00:55:13 +0200
Subject: [LinuxBIOS] [linuxbios-checkins] r2232 breaks all opteron
	boards.
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B64@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B64@ssvlexmb2.amd.com>
Message-ID: <20060403225512.GA11477@openbios.org>

* Lu, Yinghai <yinghai.lu at amd.com> [060403 23:25]:
> Fixed. Please check again.

It builds fine again. thanks. Should we drop reset.c from all amd64
mainboards?

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at openbios.org  Tue Apr  4 01:06:19 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 4 Apr 2006 01:06:19 +0200
Subject: [LinuxBIOS] Geode SC22000
In-Reply-To: <WorldClient-F200604031019.AA19060047@t2data.se>
References: <WorldClient-F200603311416.AA16200026@t2data.se>
	<20060401101858.GA19266@openbios.org>
	<WorldClient-F200604031019.AA19060047@t2data.se>
Message-ID: <20060403230619.GA11567@openbios.org>

* Per Hallsmark <perh at t2data.se> [060403 10:19]:
> Stefan, thanks for you answers. I'm still a bit puzzled though
> why PPC, ARM, XScale, MIPS manages same thing without romcc or similar.

Cache-As-Ram works reliably on most platforms and it is definitely the
way to go. Romcc helps in cases where we don't have that, so we get
something up easily. On PPC it just works I think. Arm and Mips are not
supported in LinuxBIOS yet, but many of these systems (embedded and/or
with a fixed amount of memory soldered on) are a lot easier to set up
than the x86 (-64) boxes we support in LinuxBIOS.

> Is memory setup done so very much different and is so much more
> complex in x86? For my port, SC2200, it looks about same to me.

It is pretty complex on AMD64 which was the reason for romcc. And since
its there we use it to make readable C code rather than Assembler init
code. It's a matter of maintainability and ease of use. 100 lines of C
are easier to read than 100 lines of Assembler. Well, for most of us.

> (could be because of my embedded background, most targets have
>  had defined memory size so mem sizing isn't a problem...)
 
Yeah, with a fixed memory size the ram initialization is more or less
poking some values into some machine specific registers. There you dont
even gain a lot of readability with C. 
But imagine you read the SPD rom sitting on each DDR Ram module and you
have to find out how many rows and columns it is, find a timing
supported by all installed modules and generate values that the chipset
understands.
And then something doesnt work and you want to output some debugging
information but your functions are tight in registers (which is usually
the case on x86 machines) so you have to reorganize lots of your code.

romcc does that. It's a great tool. But in a "perfect world" we would
not need it ;-)

Stefan







From yinghai.lu at amd.com  Tue Apr  4 01:15:12 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 3 Apr 2006 16:15:12 -0700
Subject: [LinuxBIOS] [linuxbios-checkins] r2232 breaks all opteron
 boards.
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B65@ssvlexmb2.amd.com>

Yes.

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at coresystems.de] 
Sent: Monday, April 03, 2006 3:55 PM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] [linuxbios-checkins] r2232 breaks all opteron
boards.

* Lu, Yinghai <yinghai.lu at amd.com> [060403 23:25]:
> Fixed. Please check again.

It builds fine again. thanks. Should we drop reset.c from all amd64
mainboards?

Stefan

-- 
coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 * Fax: +49 761 7664613
Email: info at coresystems.de  * http://www.coresystems.de/





From myneil at gmail.com  Mon Apr  3 13:27:33 2006
From: myneil at gmail.com (Neil)
Date: Mon, 3 Apr 2006 19:27:33 +0800
Subject: [LinuxBIOS] help
Message-ID: <5c5dcf370604030427m7d9c5355ue70b892f821d13e5@mail.gmail.com>

Hi,
I am a freshman to linuxbios. And I am preparing porting linuxbios on my
motherboard .
My northbridge is Server works (SWC HT2000),and southbridge is Serverworks
HT-1000, I don't know if it supports the chipset? could you please tell me ?
and I cannot find relate source code in the source tree , should I create it
myself ?

Best regards.
Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060403/279136e6/attachment.html>

From bgr at linespeed.net  Tue Apr  4 10:45:45 2006
From: bgr at linespeed.net (Brian Rhodes)
Date: Tue, 04 Apr 2006 03:45:45 -0500
Subject: [LinuxBIOS] Geode Utilities and Tools
In-Reply-To: <1143563527.9996.0.camel@logarithm.lanl.gov>
References: <4428122C.2010704@onelabs.com>
	<1143563527.9996.0.camel@logarithm.lanl.gov>
Message-ID: <44323239.2060108@linespeed.net>

They have Cyreg and loadreg for 2.2, 2.4 and 2.6 kernels

For 2.4 and 2.6 they have flashrom.  The 2.4 version doesn't work very 
reliably on our reference design.  There are a few other tools including 
a register tool used by flashrom available.

I'm curious if anyone who has used the xpressrom BIOS for the 
sc1100/sc1200 has tried setting up > 4MB of video memory.  Or is there a 
pitch limitation?  I don't know how the memory for VGA is aligned.

Li-Ta Lo wrote:
> On Mon, 2006-03-27 at 10:26 -0600, Bari Ari wrote:
>   
>> Just FYI on the Geodes in case anyone missed them...
>>
>> The AMD Geode dev site has a few handy utilities and tools for debugging 
>> BIOS and driver settings.
>>
>> Cyreg -  Cyreg is a menu driven utility that displays memory, I/O and 
>> PCI configuration space data. The menus are defined in a text file that 
>> allows the user to easily modify each menu.
>>
>> Loadreg - Loadreg is a command line utility that allows the user to read 
>> or modify any I/O, memory, or PCI configuration space location. It is 
>> ideally suited to modifying system registers via a batch file.
>>
>> MCVAL - Mcval tests the state of the memory controller against known 
>> values, as well as lists all supported processor speeds and their 
>> associated memory controller register values.
>>
>>     
>
> Is there any Linux version?
>
>   
>> -Bari
>>
>>     



From stepan at openbios.org  Tue Apr  4 15:01:54 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 4 Apr 2006 15:01:54 +0200
Subject: [LinuxBIOS] bus 0 dev 0 and fidvid change
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094973@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094973@ssvlexmb2.amd.com>
Message-ID: <20060404130154.GA15613@openbios.org>

Ok, I found this one:

* Lu, Yinghai <yinghai.lu at amd.com> [051202 01:59]:
> Please check the issue 41, I make K8 MB can be compiled, and It include
> bus0/dev0 and fidvid change enhancement
> 
> HT_CHAIN_UNITID_BASE
> 	Default is 1, and if it is 6, then amd8131 will be from 6, also
> if it is 0, will assume ht chain only have one HT device...
 
so what exactly does this do? It sets the position of an 8131 on a given
bus? Does this work for all 8131 in a system? What about the 8111?

And that 0 value - is that a special case? What is the connection to the
other functionality? Does that mean there is only an 8111 and no 8131?

Possible values: 0, 1, 6 ? Others?


> HT_CHAIN_END_UNITID_BASE
> 	Default is 0x20 --- mean do not use that, if it is 0, the
> amd8111 will be dev0

do not use what? so i read:
- HT_CHAIN_END_UNITID_BASE == 0x20: 8111 on bus 1
- HT_CHAIN_END_UNITID_BASE == 0x00: 8111 on bus 0

why end unitid base? how is the correlation to HT_CHAIN_UNITID_BASE?

Possible values: 0, 32 ? Others?


> SB_HT_CHAIN_UNITID_OFFSET_ONLY
> 	Default is 1, so if HT_CHAIN_UNITID_BASE!=1, will only offset
> unitid of SB CHAIN.
 
Possible values: 0, 1? Others?

What does that mean? Why would I only want to offset the unitid of the
SB? SB Chain? Does it change the meaning of HT_CHAIN_UNITID_BASE?


> K8_SB_HT_CHAIN_ON_BUS0
> 	Deault is 0, if it is 1, will put sb chain on bus 0, even for
> S2885 sb ht is on link2, it will put on bus0.
 
does this require an 8111 southbrigde?

> K8_SET_FIDVID in cache_as_ram_auto.c or auto.c

> Fidvid change to sync the fid on 4 way or more system with different cpu
> installed....

I thought SMP systems need identical CPUs installed, according to AMD
BKDG? Is this option dangerous? Does it downclock faster CPUs to work
sanely in SMP context?

> Put following sequence in your cache_as_ram_auto.c after ht is set.
> enable_fid_change();
> enable_fid_change_on_sb();
> init_fidvid_bsp(bsp_apicid);

This is only needed if I want to use different CPUs?

> please check init_cpus.c and fidvid.c and amd8111_early_ctrl.c for
> detail....

Stefan




From yinghai.lu at amd.com  Tue Apr  4 18:17:12 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 4 Apr 2006 09:17:12 -0700
Subject: [LinuxBIOS] bus 0 dev 0 and fidvid change
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B69@ssvlexmb2.amd.com>


so what exactly does this do? It sets the position of an 8131 on a given
bus? Does this work for all 8131 in a system? What about the 8111?

And that 0 value - is that a special case? What is the connection to the
other functionality? Does that mean there is only an 8111 and no 8131?

Possible values: 0, 1, 6 ? Others?


> HT_CHAIN_END_UNITID_BASE
> 	Default is 0x20 --- mean do not use that, if it is 0, the
> amd8111 will be dev0

do not use what? so i read:
- HT_CHAIN_END_UNITID_BASE == 0x20: 8111 on bus 1
- HT_CHAIN_END_UNITID_BASE == 0x00: 8111 on bus 0

why end unitid base? how is the correlation to HT_CHAIN_UNITID_BASE?

Possible values: 0, 32 ? Others?

YH: A) 8131/8111
	HT_CHAIN_UNITID_BASE=0x10, HT_CHAIN_END_UNITID_BASE=0x06
	So 8131 will start from 0x10, and 8111 will start from 0x06
    B) ck804 only
	HT_CHAIN_UNITD_BASE=0, 
	So ck804 will start from 0x00.


> SB_HT_CHAIN_UNITID_OFFSET_ONLY
> 	Default is 1, so if HT_CHAIN_UNITID_BASE!=1, will only offset
> unitid of SB CHAIN.
 
Possible values: 0, 1? Others?

What does that mean? Why would I only want to offset the unitid of the
SB? SB Chain? Does it change the meaning of HT_CHAIN_UNITID_BASE?

YH: 0: mean using HT_CHAIN_UNITID_BASE and HT_CHAIN_END_UNITID_BASE.


> K8_SB_HT_CHAIN_ON_BUS0
> 	Deault is 0, if it is 1, will put sb chain on bus 0, even for
> S2885 sb ht is on link2, it will put on bus0.
 
does this require an 8111 southbrigde?

YH: any SB chain

> K8_SET_FIDVID in cache_as_ram_auto.c or auto.c

> Fidvid change to sync the fid on 4 way or more system with different
cpu
> installed....

I thought SMP systems need identical CPUs installed, according to AMD
BKDG? Is this option dangerous? Does it downclock faster CPUs to work
sanely in SMP context?

YH: A) using different CPU 
    B) some MB can not use at MAX fid....

> Put following sequence in your cache_as_ram_auto.c after ht is set.
> enable_fid_change();
> enable_fid_change_on_sb();
> init_fidvid_bsp(bsp_apicid);

This is only needed if I want to use different CPUs?

> please check init_cpus.c and fidvid.c and amd8111_early_ctrl.c for
> detail....

Stefan






From stepan at coresystems.de  Thu Apr  6 11:27:43 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 6 Apr 2006 11:27:43 +0200
Subject: [LinuxBIOS] Intel Southbridges
Message-ID: <20060406092743.GA3728@openbios.org>

Hi,

I just noticed, there are two identical intel southbridges in the 
v2 tree:

The southbridge/intel/i82801er part is exactly the southbridge/intel/ich5r
part. Seems like someone did not check what was there.

ICH5R:
  dell/s1850
  intel/jarrell
  momentum/apache
  supermicro/x6dhe_g2
  supermicro/x6dhr_ig2
  supermicro/x6dhr_ig

82801er 
  tyan/s2735


Also, the ich5r version uses nice PCI names like
PCI_DEVICE_ID_INTEL_82801ER_ISA whereas the i82802er code
uses PCI_DEVICE_ID_INTEL_82801ER_1F0 where the 1F0 says absolutely
nothing except maybe (guessing) the position of the device on the 
PCI bus in factory bios.

Since all mainboards except one are using the ich5r, I suggest 
deleting the 82801er directory and renaming the ich5r to 82801er to keep
consistence in the naming scheme

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Thu Apr  6 17:05:51 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 06 Apr 2006 09:05:51 -0600
Subject: [LinuxBIOS] Intel Southbridges
In-Reply-To: <20060406092743.GA3728@openbios.org>
References: <20060406092743.GA3728@openbios.org>
Message-ID: <44352E4F.3070107@lanl.gov>

Stefan Reinauer wrote:
> Hi,
> 
> I just noticed, there are two identical intel southbridges in the 
> v2 tree:
> 
>
> Since all mainboards except one are using the ich5r, I suggest 
> deleting the 82801er directory and renaming the ich5r to 82801er to keep
> consistence in the naming scheme
> 



I think this makes sense.

ron



From stepan at coresystems.de  Thu Apr  6 23:12:46 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 6 Apr 2006 23:12:46 +0200
Subject: [LinuxBIOS] Intel Southbridges
In-Reply-To: <44352E4F.3070107@lanl.gov>
References: <20060406092743.GA3728@openbios.org> <44352E4F.3070107@lanl.gov>
Message-ID: <20060406211246.GA15520@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [060406 17:05]:
> >Since all mainboards except one are using the ich5r, I suggest 
> >deleting the 82801er directory and renaming the ich5r to 82801er to keep
> >consistence in the naming scheme
> 
> I think this makes sense.

Ok, I'm preparing a patch.

    Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at openbios.org  Fri Apr  7 01:32:23 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 7 Apr 2006 01:32:23 +0200
Subject: [LinuxBIOS] xp booting
Message-ID: <20060406233223.GA20501@openbios.org>

Hi,

there's been quite some effort to get Windows XP running on Apple's new
Intel Macs. And not all of it was by Apple. 

Interesting is that one guy opened his source code of an EFI
compatibility handler. Maybe it is a good inspiration for LinuxBIOS?

http://daemons.net/~clay/index.php/2006/03/15/dual-booting-windows-xp-and-mac-os-x-on-intel-macs/
http://daemons.net/~clay/OSXP/

Stefan




From rminnich at gmail.com  Fri Apr  7 06:42:45 2006
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Apr 2006 22:42:45 -0600
Subject: [LinuxBIOS] xp booting
In-Reply-To: <20060406233223.GA20501@openbios.org>
References: <20060406233223.GA20501@openbios.org>
Message-ID: <13426df10604062142v693615bj36f28e72d6412956@mail.gmail.com>

On 4/6/06, Stefan Reinauer <stepan at openbios.org> wrote:
>
>
> Interesting is that one guy opened his source code of an EFI
> compatibility handler. Maybe it is a good inspiration for LinuxBIOS?



yes, I wonder if we could use that compatibility handler. It would be an
interesting experiment.



ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060406/cb173793/attachment.html>

From jdegood at atl.lmco.com  Fri Apr  7 15:59:49 2006
From: jdegood at atl.lmco.com (John DeGood)
Date: Fri, 07 Apr 2006 09:59:49 -0400
Subject: [LinuxBIOS] xp booting
In-Reply-To: <20060406233223.GA20501@openbios.org>
References: <20060406233223.GA20501@openbios.org>
Message-ID: <44367055.9020706@atl.lmco.com>

Apple Marketing on BIOS:

> "Macs use an ultra-modern industry standard technology called EFI to handle booting. Sadly, Windows XP, and even the upcoming Vista, are stuck in the 1980s with old-fashioned BIOS. But with Boot Camp, the Mac can operate smoothly in both centuries."




From rminnich at lanl.gov  Fri Apr  7 16:38:25 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 07 Apr 2006 08:38:25 -0600
Subject: [LinuxBIOS] xp booting
In-Reply-To: <44367055.9020706@atl.lmco.com>
References: <20060406233223.GA20501@openbios.org>
	<44367055.9020706@atl.lmco.com>
Message-ID: <44367961.5080704@lanl.gov>

John DeGood wrote:
> Apple Marketing on BIOS:
> 
> 
>>"Macs use an ultra-modern industry standard technology called EFI to handle booting. Sadly, Windows XP, and even the upcoming Vista, are stuck in the 1980s with old-fashioned BIOS. But with Boot Camp, the Mac can operate smoothly in both centuries."


I read that too. Pretty funny, once you start looking at EFI code ...

ron



From stepan at openbios.org  Fri Apr  7 18:32:28 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 7 Apr 2006 18:32:28 +0200
Subject: [LinuxBIOS] xp booting
In-Reply-To: <44367961.5080704@lanl.gov>
References: <20060406233223.GA20501@openbios.org>
	<44367055.9020706@atl.lmco.com> <44367961.5080704@lanl.gov>
Message-ID: <20060407163228.GB310@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [060407 16:38]:
> >>"Macs use an ultra-modern industry standard technology called EFI to
> >>handle booting. Sadly, Windows XP, and even the upcoming Vista, are
> >>stuck in the 1980s with old-fashioned BIOS. But with Boot Camp, the
> >>Mac can operate smoothly in both centuries."
> 
> I read that too. Pretty funny, once you start looking at EFI code ...

The really ultra-modern innovative part - and the only one that was not
coped by IEEE 1275-1994 (yeah last century) - was the intellectual
property closed source thingie.

The good thing is nobody except Intel and Apple are supporting EFI
actively yet.

Stefan




From ward at gnu.org  Fri Apr  7 19:27:44 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Apr 2006 13:27:44 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B63@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B63@ssvlexmb2.amd.com>
Message-ID: <20060407172744.GA15729@io.pong.be>

On Mon, Apr 03, 2006 at 01:40:07PM -0700, Lu, Yinghai wrote:
> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Lu, Yinghai
> Sent: Friday, March 31, 2006 5:24 PM
> To: Ronald G Minnich; Stefan Reinauer; Jason Schildt
> Cc: linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK
> 
> Svn diff to current tree.
> 
> Please check it. I will commit it some time next week.
> 
> Guys have problem with s2891, s2881, s2892, please try it by 

I still have the exact same problem with our s2881's. I've attached the
minicom boot log (gzipped). The kernel boots but at some point LinuxBIOS just
takes over again and the boot process halts. This is Etherboot 5.4.1 with
SATA support.

Is there anything I could be doing wrong that causes this? These machines
need to go into production soon, and I really want them to run LinuxBIOS.

I've also attached the Config.lb file.

Thanks,
Ward.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom_20060407.cap.gz
Type: application/octet-stream
Size: 9397 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060407/bd8d6cf2/attachment.obj>
-------------- next part --------------
# Sample config file for 
# the Tyan s2881 
# This will make a target directory of ./s2881

target s2881
mainboard tyan/s2881

# Tyan s2881
romimage "normal"
#       48K for SCSI FW or ATI ROM
##        option ROM_SIZE = 475136
#       48K for SCSI FW and 48K for ATI ROM
#       option ROM_SIZE = 425984 
#       64K for Etherboot
#        option ROM_SIZE = 458752 
	option USE_FALLBACK_IMAGE=0
#        option ROM_IMAGE_SIZE=0x11800
#	option ROM_IMAGE_SIZE=0x13000
#	option ROM_IMAGE_SIZE=0x16000
	option ROM_IMAGE_SIZE=0x20000
        option XIP_ROM_SIZE=0x20000
	option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal"
#       payload ../../../payloads/tg3--ide_disk.zelf
#        payload ../../../../../payloads/filo.elf
#        payload ../../../payloads/filo_mem.elf
#       payload ../../../payloads/filo.zelf
#        payload ../../../payloads/tg3--filo.zelf
        payload ../../../payloads/tg3--filo.zelf
#        payload ../../../payloads/memtest
##	payload ../../../../payloads/tg3--filo_hda2_vga.zelf
#	 payload ../../../payloads/tg3--filo_hda1_vga_md1.zelf
#	payload ../../../payloads/tg3--filo_btext_hda2.zelf
#       payload ../../../payloads/e1000--filo.zelf
#        payload ../../../payloads/tg3--e1000--filo.zelf
#        payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf
end

romimage "fallback" 
	option USE_FALLBACK_IMAGE=1
#        option ROM_IMAGE_SIZE=0x11800
#	option ROM_IMAGE_SIZE=0x13000
#	option ROM_IMAGE_SIZE=0x16000
	option ROM_IMAGE_SIZE=0x20000
        option XIP_ROM_SIZE=0x20000
	option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback"
#       payload ../../../payloads/tg3--ide_disk.zelf
#        payload ../../../payloads/filo.elf
#        payload ../../../../../payloads/filo.elf
#        payload ../../../payloads/tg3--filo.zelf
        payload ../../../payloads/tg3--filo.zelf
#        payload ../../../payloads/filo_mem.elf
#       payload ../../../payloads/filo.zelf
#        payload ../../../payloads/tg3--filo.zelf
##	payload ../../../../payloads/tg3--filo_hda2_vga.zelf
#	payload ../../../payloads/tg3--filo_hda1_vga_md1.zelf
#       payload ../../../payloads/e1000--filo.zelf
#	payload ../../../payloads/tg3--filo_btext_hda2.zelf
#        payload ../../../payloads/tg3--e1000--filo.zelf
#        payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf
end

buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"

From rminnich at lanl.gov  Fri Apr  7 20:10:14 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 07 Apr 2006 12:10:14 -0600
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <20060407172744.GA15729@io.pong.be>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B63@ssvlexmb2.amd.com>
	<20060407172744.GA15729@io.pong.be>
Message-ID: <4436AB06.3010207@lanl.gov>

interesting, your kernel is just exploding.

have you tried booting memtest?

can you tried booting single user and seeing how long it can do things 
for you?

thanks

ron



From ward at gnu.org  Fri Apr  7 20:22:25 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Apr 2006 14:22:25 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <4436AB06.3010207@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B63@ssvlexmb2.amd.com>
	<20060407172744.GA15729@io.pong.be> <4436AB06.3010207@lanl.gov>
Message-ID: <20060407182225.GA15981@io.pong.be>

On Fri, Apr 07, 2006 at 12:10:14PM -0600, Ronald G Minnich wrote:
> interesting, your kernel is just exploding.

Ah?! You mean it is panicking?

> have you tried booting memtest?

Yes. It ran for several days without problems; memory checked out fine too.

> can you tried booting single user and seeing how long it can do things 
> for you?

I'll try that now.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Fri Apr  7 20:32:30 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Apr 2006 11:32:30 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B7E@ssvlexmb2.amd.com>

Wait, you image has problem.

After print ht reset - 
The soft_reset() doesn't cause reset...

YH




From ward at gnu.org  Fri Apr  7 20:39:30 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Apr 2006 14:39:30 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <4436AB06.3010207@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B63@ssvlexmb2.amd.com>
	<20060407172744.GA15729@io.pong.be> <4436AB06.3010207@lanl.gov>
Message-ID: <20060407183930.GA17465@io.pong.be>

On Fri, Apr 07, 2006 at 12:10:14PM -0600, Ronald G Minnich wrote:
> can you try booting single user and seeing how long it can do things 
> for you?

Same problem - I don't even get there. Boot log attached...

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom_20060407_2.cap.gz
Type: application/octet-stream
Size: 10885 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060407/40f881e8/attachment.obj>

From ward at gnu.org  Fri Apr  7 20:46:09 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Apr 2006 14:46:09 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B7E@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B7E@ssvlexmb2.amd.com>
Message-ID: <20060407184609.GB17465@io.pong.be>

On Fri, Apr 07, 2006 at 11:32:30AM -0700, Lu, Yinghai wrote:
> Wait, you image has problem.
> 
> After print ht reset - 
> The soft_reset() doesn't cause reset...

I'm not sure I understand; could you elaborate a bit?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Fri Apr  7 21:40:50 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Apr 2006 12:40:50 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B7F@ssvlexmb2.amd.com>

The Image that you built has problem with HT reset.
It may still work at 200Mhz 8 bit HT speed. And some errata fix is not
effective too.

YH

-----Original Message-----
From: Ward Vandewege [mailto:ward at gnu.org] 
Sent: Friday, April 07, 2006 11:46 AM
To: Lu, Yinghai
Cc: Ronald G Minnich; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK

On Fri, Apr 07, 2006 at 11:32:30AM -0700, Lu, Yinghai wrote:
> Wait, you image has problem.
> 
> After print ht reset - 
> The soft_reset() doesn't cause reset...

I'm not sure I understand; could you elaborate a bit?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator





From rminnich at lanl.gov  Fri Apr  7 21:38:46 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 07 Apr 2006 13:38:46 -0600
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B7F@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B7F@ssvlexmb2.amd.com>
Message-ID: <4436BFC6.8000707@lanl.gov>

Lu, Yinghai wrote:
> The Image that you built has problem with HT reset.
> It may still work at 200Mhz 8 bit HT speed. And some errata fix is not
> effective too.

So, YH, what can he do about it?

thanks

ron



From yinghai.lu at amd.com  Fri Apr  7 21:49:10 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Apr 2006 12:49:10 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B80@ssvlexmb2.amd.com>

Ward, 

Can you send your cache_as_ram_auto.c and Config.lb in
src/mainboard/tyan/s2881?

YH

-----Original Message-----
From: Ronald G Minnich [mailto:rminnich at lanl.gov] 
Sent: Friday, April 07, 2006 12:39 PM
To: Lu, Yinghai
Cc: Ward Vandewege; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK

Lu, Yinghai wrote:
> The Image that you built has problem with HT reset.
> It may still work at 200Mhz 8 bit HT speed. And some errata fix is not
> effective too.

So, YH, what can he do about it?

thanks

ron





From arti_tevs at yahoo.de  Fri Apr  7 21:54:58 2006
From: arti_tevs at yahoo.de (Art Tevs)
Date: Fri, 7 Apr 2006 21:54:58 +0200
Subject: [LinuxBIOS] SockelA Mainboards supporting LinuxBIOS
Message-ID: <200604072154.58801.arti_tevs@yahoo.de>

Hi, folks!

I am new in the "Linux on BIOS" section. But I like it :-)

Does there exists SockelA (AMD Athlon XP) mainboards that are supported by the 
linuxbios project? On the homepage there is no such boards listed. 

I think each board that has removeable BIOS chip should be able to support 
linux. I mean it should be possible to write new version of LinuxBIOS for 
such a board. Or do I think wrong?

Thanks!

	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de




From ward at gnu.org  Fri Apr  7 22:07:00 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Apr 2006 16:07:00 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B80@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B80@ssvlexmb2.amd.com>
Message-ID: <20060407200700.GA18795@io.pong.be>

On Fri, Apr 07, 2006 at 12:49:10PM -0700, Lu, Yinghai wrote:
> Can you send your cache_as_ram_auto.c and Config.lb in
> src/mainboard/tyan/s2881?

Sure, they are attached.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cache_as_ram_auto.c
Type: text/x-csrc
Size: 5319 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060407/c981755f/attachment.c>
-------------- next part --------------
##
## Compute the location and size of where this firmware image
## (linuxBIOS plus bootloader) will live in the boot rom chip.
##
if USE_FALLBACK_IMAGE
	default ROM_SECTION_SIZE   = FALLBACK_SIZE
	default ROM_SECTION_OFFSET = ( ROM_SIZE - FALLBACK_SIZE )
else
	default ROM_SECTION_SIZE   = ( ROM_SIZE - FALLBACK_SIZE )
	default ROM_SECTION_OFFSET = 0
end

##
## Compute the start location and size size of
## The linuxBIOS bootloader.
##
default PAYLOAD_SIZE            = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1)

##
## Compute where this copy of linuxBIOS will start in the boot rom
##
default _ROMBASE      = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE )

##
## Compute a range of ROM that can cached to speed up linuxBIOS,
## execution speed.
##
## XIP_ROM_SIZE must be a power of 2.
## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE
##
default XIP_ROM_SIZE=65536
default XIP_ROM_BASE = ( _ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE )

arch i386 end 

##
## Build the objects we have code for in this directory.
##

driver mainboard.o

#dir /drivers/si/3114
object get_bus_conf.o
if HAVE_MP_TABLE object mptable.o end
if HAVE_PIRQ_TABLE object irq_tables.o end
if USE_DCACHE_RAM

if CONFIG_USE_INIT

makerule ./auto.o
        depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h"
        action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -o auto.o" 
end

else    
                
makerule ./auto.inc
        depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h"
        action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -S -o $@"         
        action "perl -e 's/.rodata/.rom.data/g' -pi $@"
        action "perl -e 's/.text/.section .rom.text/g' -pi $@"
end

end
else


##
## Romcc output
##
makerule ./failover.E
        depends "$(MAINBOARD)/failover.c ./romcc"
        action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
end

makerule ./failover.inc
        depends "$(MAINBOARD)/failover.c ./romcc"
        action "./romcc    -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
end

makerule ./auto.E
        depends "$(MAINBOARD)/auto.c option_table.h ./romcc"
        action  "./romcc -E -mcpu=k8 -O2 -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
end
makerule ./auto.inc
        depends "$(MAINBOARD)/auto.c option_table.h ./romcc"
        action  "./romcc    -mcpu=k8 -O2 -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
end

end
##
## Build our 16 bit and 32 bit linuxBIOS entry code
##
if USE_FALLBACK_IMAGE
        mainboardinit cpu/x86/16bit/entry16.inc
        ldscript /cpu/x86/16bit/entry16.lds
end

mainboardinit cpu/x86/32bit/entry32.inc

if USE_DCACHE_RAM
        if CONFIG_USE_INIT
                ldscript /cpu/x86/32bit/entry32.lds
        end

        if CONFIG_USE_INIT
                ldscript      /cpu/amd/car/cache_as_ram.lds
        end
end

##
## Build our reset vector (This is where linuxBIOS is entered)
##
if USE_FALLBACK_IMAGE 
	mainboardinit cpu/x86/16bit/reset16.inc 
	ldscript /cpu/x86/16bit/reset16.lds 
else
	mainboardinit cpu/x86/32bit/reset32.inc 
	ldscript /cpu/x86/32bit/reset32.lds 
end

if USE_DCACHE_RAM
else
### Should this be in the northbridge code?
mainboardinit arch/i386/lib/cpu_reset.inc
end

##
## Include an id string (For safe flashing)
##
mainboardinit arch/i386/lib/id.inc
ldscript /arch/i386/lib/id.lds

if USE_DCACHE_RAM
##
## Setup Cache-As-Ram
##
mainboardinit cpu/amd/car/cache_as_ram.inc
end

###
### This is the early phase of linuxBIOS startup 
### Things are delicate and we test to see if we should
### failover to another image.
###
if USE_FALLBACK_IMAGE
if USE_DCACHE_RAM
       ldscript /arch/i386/lib/failover.lds
else
       ldscript /arch/i386/lib/failover.lds
        mainboardinit ./failover.inc
end
end

###
### O.k. We aren't just an intermediary anymore!
###

##
## Setup RAM
##
if USE_DCACHE_RAM

if CONFIG_USE_INIT
initobject auto.o
else
mainboardinit ./auto.inc
end

else

##
## Setup RAM
##
mainboardinit cpu/x86/fpu/enable_fpu.inc
mainboardinit cpu/x86/mmx/enable_mmx.inc
mainboardinit cpu/x86/sse/enable_sse.inc
mainboardinit ./auto.inc
mainboardinit cpu/x86/sse/disable_sse.inc
mainboardinit cpu/x86/mmx/disable_mmx.inc

end

##
## Include the secondary Configuration files 
##
if CONFIG_CHIP_NAME
	config chip.h
end

# sample config for tyan/s2881
chip northbridge/amd/amdk8/root_complex
        device apic_cluster 0 on
                chip cpu/amd/socket_940
                        device apic 0 on end
                end
        end
	device pci_domain 0 on
		chip northbridge/amd/amdk8
			device pci 18.0 on end # LDT0
			device pci 18.0 on end # LDT1
			device pci 18.0 on #  northbridge 
				#  devices on link 2, link 2 == LDT 2
				chip southbridge/amd/amd8131
					# the on/off keyword is mandatory
					device pci 0.0 on 
                                                chip drivers/pci/onboard
                                                        device pci 9.0 on end # Broadcom 5704
                                                        device pci 9.1 on end
                                                end
                                                chip drivers/pci/onboard
                                                        device pci a.0 on end # Adaptic
                                                        device pci a.1 on end
                                                end
					end
					device pci 0.1 on end
					device pci 1.0 on end
					device pci 1.1 on end
				end
				chip southbridge/amd/amd8111
					# this "device pci 0.0" is the parent the next one
					# PCI bridge
					device pci 0.0 on
						device pci 0.0 on end
						device pci 0.1 on end
						device pci 0.2 off end
						device pci 1.0 off end
                                                chip drivers/pci/onboard
                                                        device pci 5.0 on end # SiI
                                                end
                                                chip drivers/pci/onboard
                                                        device pci 6.0 on end
							register "rom_address" = "0xfff80000"
                                                end
					end
					device pci 1.0 on
						chip superio/winbond/w83627hf
							device pnp 2e.0 on #  Floppy
                	                 			io 0x60 = 0x3f0
                	                			irq 0x70 = 6
                	                			drq 0x74 = 2
							end
                	        			device pnp 2e.1 off #  Parallel Port
                	                 			io 0x60 = 0x378
                	                			irq 0x70 = 7
							end
                	        			device pnp 2e.2 on #  Com1
                	                 			io 0x60 = 0x3f8
                	                			irq 0x70 = 4
							end
                	        			device pnp 2e.3 off #  Com2
                	                 			io 0x60 = 0x2f8
                	                			irq 0x70 = 3
							end
                	        			device pnp 2e.5 on #  Keyboard
                	                 			io 0x60 = 0x60
                	                 			io 0x62 = 0x64
                	                			irq 0x70 = 1
								irq 0x72 = 12
							end
                	                                device pnp 2e.6 off #  CIR
                	                                        io 0x60 = 0x100
                	                                end
                	                                device pnp 2e.7 off #  GAME_MIDI_GIPO1
                	                                        io 0x60 = 0x220
                	                                        io 0x62 = 0x300
                	                                        irq 0x70 = 9
                	                                end  
                	                                device pnp 2e.8 off end #  GPIO2
                	                                device pnp 2e.9 off end #  GPIO3
                	                                device pnp 2e.a off end #  ACPI
                	                                device pnp 2e.b on #  HW Monitor
                	                                        io 0x60 = 0x290
                	                                        irq 0x70 = 5
                	                                end
						end
					end
					device pci 1.1 on end
					device pci 1.2 on end
                                        device pci 1.3 on 
                                                chip drivers/generic/generic #dimm 0-0-0
                                                        device i2c 50 on end
                                                end
                                                chip drivers/generic/generic #dimm 0-0-1
                                                        device i2c 51 on end
                                                end     
                                                chip drivers/generic/generic #dimm 0-1-0
                                                        device i2c 52 on end
                                                end
                                                chip drivers/generic/generic #dimm 0-1-1
                                                        device i2c 53 on end
                                                end
                                                chip drivers/generic/generic #dimm 1-0-0
                                                        device i2c 54 on end
                                                end
                                                chip drivers/generic/generic #dimm 1-0-1
                                                        device i2c 55 on end
                                                end
                                                chip drivers/generic/generic #dimm 1-1-0
                                                        device i2c 56 on end
                                                end
                                                chip drivers/generic/generic #dimm 1-1-1
                                                        device i2c 57 on end
                                                end
                                                chip drivers/i2c/adm1027 # ADT7463A CPU0/1 temp, CPU1 vid, SYS FAN 1/2/3
                                                        device i2c 2d on end
                                                end
                                                chip drivers/generic/generic # Winbond HWM 0x54 CPU0/1 VRM temp, SYSFAN 4,CPU0 vid, CPU0/1 FAN
                                                        device i2c 2a on end
                                                end
                                                chip drivers/generic/generic # Winbond HWM 0x92
                                                        device i2c 49 on end
                                                end
                                                chip drivers/generic/generic # Winbond HWM 0x94
                                                        device i2c 4a on end
                                                end
                                        end # acpi
					device pci 1.5 off end
					device pci 1.6 off end
                                        register "ide0_enable" = "1"
                                        register "ide1_enable" = "1"
				end
			end #  device pci 18.0 
			
			device pci 18.1 on end
			device pci 18.2 on end
			device pci 18.3 on end
		end
	end 
end


From yinghai.lu at amd.com  Fri Apr  7 22:37:06 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Apr 2006 13:37:06 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B81@ssvlexmb2.amd.com>

I fixed one merge typo in
src/southbride/amd/amd8111/amd8111_early_ctrl.c

Please change 15 to 11 at line 13.

YH

-----Original Message-----
From: Ward Vandewege [mailto:ward at gnu.org] 
Sent: Friday, April 07, 2006 1:07 PM
To: Lu, Yinghai
Cc: Ronald G Minnich; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK

On Fri, Apr 07, 2006 at 12:49:10PM -0700, Lu, Yinghai wrote:
> Can you send your cache_as_ram_auto.c and Config.lb in
> src/mainboard/tyan/s2881?

Sure, they are attached.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator




From ward at gnu.org  Fri Apr  7 22:54:31 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Apr 2006 16:54:31 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B81@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B81@ssvlexmb2.amd.com>
Message-ID: <20060407205431.GA21387@io.pong.be>

On Fri, Apr 07, 2006 at 01:37:06PM -0700, Lu, Yinghai wrote:
> I fixed one merge typo in
> src/southbride/amd/amd8111/amd8111_early_ctrl.c
> 
> Please change 15 to 11 at line 13.

OK; did that, but it did not help. Same problem still.

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Fri Apr  7 23:02:47 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Apr 2006 14:02:47 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>

1. Can you make one elf image with mkelfImage ( combine the kernel and
initrd)?

2. use latest kernel + suse rescue disk to make on elf to check your
/dev/md3...

YH


-----Original Message-----
From: Ward Vandewege [mailto:ward at gnu.org] 
Sent: Friday, April 07, 2006 1:55 PM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK

On Fri, Apr 07, 2006 at 01:37:06PM -0700, Lu, Yinghai wrote:
> I fixed one merge typo in
> src/southbride/amd/amd8111/amd8111_early_ctrl.c
> 
> Please change 15 to 11 at line 13.

OK; did that, but it did not help. Same problem still.

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator





From ward at gnu.org  Sat Apr  8 00:15:28 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Apr 2006 18:15:28 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
Message-ID: <20060407221528.GA23521@io.pong.be>

On Fri, Apr 07, 2006 at 02:02:47PM -0700, Lu, Yinghai wrote:
> 1. Can you make one elf image with mkelfImage ( combine the kernel and
> initrd)?

OK; this is what I've done:

1. Retrieved the mkelfImage program (v2.7) from

 ftp://ftp.lnxi.com

2. 

 mkelfImage --command-line="ro root=/dev/md3 quiet splash console=tty0
console=ttyS0,115200n8" \
            --kernel="/boot/vmlinuz-2.6.12-9-amd64-generic" \
            --initrd="/boot/initrd.img-2.6.12-9-amd64-generic" \
            --output="/boot/linuxbios_2.6.12-9-amd64-generic.elf"

3. Adjusted etherboot-5.4.1/file/Config

 AUTOBOOT_FILE = "hde1:/linuxbios_2.6.12-9-amd64-generic.elf"

4.

 cd etherboot-5.4.1/src
 make bin/tg3--filo.elf

5. Adjusted targets/tyan/s2881/Config.lb to point to the new payload
(tg3--filo.elf)
 
6. Tried booting - it actually got to a login prompt this time, but as I hit
enter on the kbd, it crashed again. Log is attached.

So that did not help. I'm going to try your next suggestion now.

Thanks,
Ward.

> 2. use latest kernel + suse rescue disk to make on elf to check your
> /dev/md3...
> 
> YH
> 
> 
> -----Original Message-----
> From: Ward Vandewege [mailto:ward at gnu.org] 
> Sent: Friday, April 07, 2006 1:55 PM
> To: Lu, Yinghai
> Cc: linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK
> 
> On Fri, Apr 07, 2006 at 01:37:06PM -0700, Lu, Yinghai wrote:
> > I fixed one merge typo in
> > src/southbride/amd/amd8111/amd8111_early_ctrl.c
> > 
> > Please change 15 to 11 at line 13.
> 
> OK; did that, but it did not help. Same problem still.
> 
> Ward.
> 
> -- 
> Ward Vandewege <ward at fsf.org>
> Free Software Foundation - Senior System Administrator
> 
> 
> 
> -- 
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
> 
> !DSPAM:4436d470278011542430122!
> 
-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom_20060407_3.cap.gz
Type: application/octet-stream
Size: 4318 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060407/40379497/attachment.obj>

From yinghai.lu at amd.com  Sat Apr  8 00:38:05 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Apr 2006 15:38:05 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B84@ssvlexmb2.amd.com>

What is the T0 in your /etc/inittab?

Also com2 is disabled in LB, and Linux bring it out ?

So can you enable the com2 in your MB Config.lb, 2e.3 off==> 2e.3 on...

YH




From ward at gnu.org  Sat Apr  8 00:46:00 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Apr 2006 18:46:00 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B84@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B84@ssvlexmb2.amd.com>
Message-ID: <20060407224600.GA24710@io.pong.be>

On Fri, Apr 07, 2006 at 03:38:05PM -0700, Lu, Yinghai wrote:
> What is the T0 in your /etc/inittab?

It puts the console on com2, which is probably why it is failing.

> Also com2 is disabled in LB, and Linux bring it out ?
> 
> So can you enable the com2 in your MB Config.lb, 2e.3 off==> 2e.3 on...

Can you give me an example of the exact line to add to Config.lb? It doesn't
have any serial configuration in it right now.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Sat Apr  8 00:49:55 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Apr 2006 15:49:55 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B85@ssvlexmb2.amd.com>

device pnp 2e.3 off #  Com2

===>

device pnp 2e.3 on #  Com2

-----Original Message-----
From: Ward Vandewege [mailto:ward at gnu.org] 
Sent: Friday, April 07, 2006 3:46 PM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org; Ronald G Minnich
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK

On Fri, Apr 07, 2006 at 03:38:05PM -0700, Lu, Yinghai wrote:
> What is the T0 in your /etc/inittab?

It puts the console on com2, which is probably why it is failing.

> Also com2 is disabled in LB, and Linux bring it out ?
> 
> So can you enable the com2 in your MB Config.lb, 2e.3 off==> 2e.3
on...

Can you give me an example of the exact line to add to Config.lb? It
doesn't
have any serial configuration in it right now.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator





From ward at gnu.org  Sat Apr  8 00:52:47 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Apr 2006 18:52:47 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
Message-ID: <20060407225247.GA24812@io.pong.be>

On Fri, Apr 07, 2006 at 02:02:47PM -0700, Lu, Yinghai wrote:
> 1. Can you make one elf image with mkelfImage ( combine the kernel and
> initrd)?
> 
> 2. use latest kernel + suse rescue disk to make on elf to check your
> /dev/md3...

OK; tried stock 2.6.16.2 kernel + mkelfImage. Same problem; output attached.
I have disabled the T0 in /etc/inittab for now, until I can configure my
Config.lb properly.

Any other ideas?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom_20060407_4.cap.gz
Type: application/octet-stream
Size: 3400 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060407/8f88359d/attachment.obj>

From a.mimms at f5.com  Sat Apr  8 01:00:28 2006
From: a.mimms at f5.com (Alan Mimms)
Date: Fri, 7 Apr 2006 16:00:28 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
Message-ID: <4E497EE4DD5F9347B242A83387F27DC821A921@exchsix.olympus.f5net.com>

One side comment from a lurker on this list.  Your experience with the
error hang after your login prompt (prints message like the one below)

  LinuxBIOS-1.1.8_s2881_Fallback Fri Apr  7 18:06:33 EDT 2006
starting...
  (0,1) link=00
  (1,0) link=00
  02 nodes initialized.
  SBLink=02
  NC node|link=02

reminded me of something I found and fixed a couple of weeks ago.

The board hangs when it does a warm reset on a bus error condition.
This is due to a typo in the code in
src/northbridge/amdk8/incoherent_ht.c in the function ht_setup_chainx
(base indentation removed for clarity):

if (ctrl & ((1 << 4) | (1 << 8))) {
                   /*
    * Either the link has failed, or we have
    * a CRC error.
    * Sometimes this can happen due to link
    * retrain, so lets knock it down and see
    * if its transient
    */
-->  ctrl |= ((1 << 6) | (1 <<8)); // Link fail + Crc
	pci_write_config16(udev, upos + LINK_CTRL(uoffs), ctrl);
	ctrl = pci_read_config16(udev, upos + LINK_CTRL(uoffs));
	if (ctrl & ((1 << 4) | (1 << 8))) {
		print_err("Detected error on Hypertransport Link\n");
		break;
	}
}

The line (marked with "-->" above) where the error bits to be cleared
are set to '1'
    ctrl |= ((1 << 6) | (1 <<8)); // Link fail + Crc
SHOULD be
    ctrl |= ((1 << 4) | (1 <<8)); // Link fail + Crc

The code should be setting the 1<<4 bit (so as to clear one of the error
bits) instead of 1<<6 (the read only bit that signals end of HT bus
chain).

After making this change, your board won't hang when the BIOS or Linux
detects a need to reboot due to some fatal error.

This is a pretty trivial change to an error case that hardly ever occurs
but was crucial for us.  I claim this change is safe and correct and
should be merged into the main line code.

Cheers, and thanks to all you who work so hard for all of the good and
useful LinuxBIOS code.  We have been very successful with it thus far in
our project.

Alan Mimms, Senior Architect
F5 Networks, Inc.  Spokane Development Center
1322 North Whitman Lane
Liberty Lake, Washington   99019
v: 509-343-3524   f: 509-343-3501
 

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
Sent: Friday, April 07, 2006 3:15 PM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK

On Fri, Apr 07, 2006 at 02:02:47PM -0700, Lu, Yinghai wrote:
> 1. Can you make one elf image with mkelfImage ( combine the kernel and
> initrd)?

OK; this is what I've done:

1. Retrieved the mkelfImage program (v2.7) from

 ftp://ftp.lnxi.com

2. 

 mkelfImage --command-line="ro root=/dev/md3 quiet splash console=tty0
console=ttyS0,115200n8" \
            --kernel="/boot/vmlinuz-2.6.12-9-amd64-generic" \
            --initrd="/boot/initrd.img-2.6.12-9-amd64-generic" \
            --output="/boot/linuxbios_2.6.12-9-amd64-generic.elf"

3. Adjusted etherboot-5.4.1/file/Config

 AUTOBOOT_FILE = "hde1:/linuxbios_2.6.12-9-amd64-generic.elf"

4.

 cd etherboot-5.4.1/src
 make bin/tg3--filo.elf

5. Adjusted targets/tyan/s2881/Config.lb to point to the new payload
(tg3--filo.elf)
 
6. Tried booting - it actually got to a login prompt this time, but as I
hit
enter on the kbd, it crashed again. Log is attached.

So that did not help. I'm going to try your next suggestion now.

Thanks,
Ward.

> 2. use latest kernel + suse rescue disk to make on elf to check your
> /dev/md3...
> 
> YH
> 
> 
> -----Original Message-----
> From: Ward Vandewege [mailto:ward at gnu.org] 
> Sent: Friday, April 07, 2006 1:55 PM
> To: Lu, Yinghai
> Cc: linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK
> 
> On Fri, Apr 07, 2006 at 01:37:06PM -0700, Lu, Yinghai wrote:
> > I fixed one merge typo in
> > src/southbride/amd/amd8111/amd8111_early_ctrl.c
> > 
> > Please change 15 to 11 at line 13.
> 
> OK; did that, but it did not help. Same problem still.
> 
> Ward.
> 
> -- 
> Ward Vandewege <ward at fsf.org>
> Free Software Foundation - Senior System Administrator
> 
> 
> 
> -- 
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
> 
> !DSPAM:4436d470278011542430122!
> 
-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Sat Apr  8 01:12:47 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 7 Apr 2006 16:12:47 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B86@ssvlexmb2.amd.com>

You are right. It should be 4 instead of 6....

YH

-----Original Message-----
From: Alan Mimms [mailto:a.mimms at f5.com] 
Sent: Friday, April 07, 2006 4:00 PM
To: Ward Vandewege; Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: RE: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)

One side comment from a lurker on this list.  Your experience with the
error hang after your login prompt (prints message like the one below)

  LinuxBIOS-1.1.8_s2881_Fallback Fri Apr  7 18:06:33 EDT 2006
starting...
  (0,1) link=00
  (1,0) link=00
  02 nodes initialized.
  SBLink=02
  NC node|link=02

reminded me of something I found and fixed a couple of weeks ago.

The board hangs when it does a warm reset on a bus error condition.
This is due to a typo in the code in
src/northbridge/amdk8/incoherent_ht.c in the function ht_setup_chainx
(base indentation removed for clarity):

if (ctrl & ((1 << 4) | (1 << 8))) {
                   /*
    * Either the link has failed, or we have
    * a CRC error.
    * Sometimes this can happen due to link
    * retrain, so lets knock it down and see
    * if its transient
    */
-->  ctrl |= ((1 << 6) | (1 <<8)); // Link fail + Crc
	pci_write_config16(udev, upos + LINK_CTRL(uoffs), ctrl);
	ctrl = pci_read_config16(udev, upos + LINK_CTRL(uoffs));
	if (ctrl & ((1 << 4) | (1 << 8))) {
		print_err("Detected error on Hypertransport Link\n");
		break;
	}
}

The line (marked with "-->" above) where the error bits to be cleared
are set to '1'
    ctrl |= ((1 << 6) | (1 <<8)); // Link fail + Crc
SHOULD be
    ctrl |= ((1 << 4) | (1 <<8)); // Link fail + Crc

The code should be setting the 1<<4 bit (so as to clear one of the error
bits) instead of 1<<6 (the read only bit that signals end of HT bus
chain).

After making this change, your board won't hang when the BIOS or Linux
detects a need to reboot due to some fatal error.

This is a pretty trivial change to an error case that hardly ever occurs
but was crucial for us.  I claim this change is safe and correct and
should be merged into the main line code.

Cheers, and thanks to all you who work so hard for all of the good and
useful LinuxBIOS code.  We have been very successful with it thus far in
our project.

Alan Mimms, Senior Architect
F5 Networks, Inc.  Spokane Development Center
1322 North Whitman Lane
Liberty Lake, Washington   99019
v: 509-343-3524   f: 509-343-3501
 

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
Sent: Friday, April 07, 2006 3:15 PM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK

On Fri, Apr 07, 2006 at 02:02:47PM -0700, Lu, Yinghai wrote:
> 1. Can you make one elf image with mkelfImage ( combine the kernel and
> initrd)?

OK; this is what I've done:

1. Retrieved the mkelfImage program (v2.7) from

 ftp://ftp.lnxi.com

2. 

 mkelfImage --command-line="ro root=/dev/md3 quiet splash console=tty0
console=ttyS0,115200n8" \
            --kernel="/boot/vmlinuz-2.6.12-9-amd64-generic" \
            --initrd="/boot/initrd.img-2.6.12-9-amd64-generic" \
            --output="/boot/linuxbios_2.6.12-9-amd64-generic.elf"

3. Adjusted etherboot-5.4.1/file/Config

 AUTOBOOT_FILE = "hde1:/linuxbios_2.6.12-9-amd64-generic.elf"

4.

 cd etherboot-5.4.1/src
 make bin/tg3--filo.elf

5. Adjusted targets/tyan/s2881/Config.lb to point to the new payload
(tg3--filo.elf)
 
6. Tried booting - it actually got to a login prompt this time, but as I
hit
enter on the kbd, it crashed again. Log is attached.

So that did not help. I'm going to try your next suggestion now.

Thanks,
Ward.

> 2. use latest kernel + suse rescue disk to make on elf to check your
> /dev/md3...
> 
> YH
> 
> 
> -----Original Message-----
> From: Ward Vandewege [mailto:ward at gnu.org] 
> Sent: Friday, April 07, 2006 1:55 PM
> To: Lu, Yinghai
> Cc: linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK
> 
> On Fri, Apr 07, 2006 at 01:37:06PM -0700, Lu, Yinghai wrote:
> > I fixed one merge typo in
> > src/southbride/amd/amd8111/amd8111_early_ctrl.c
> > 
> > Please change 15 to 11 at line 13.
> 
> OK; did that, but it did not help. Same problem still.
> 
> Ward.
> 
> -- 
> Ward Vandewege <ward at fsf.org>
> Free Software Foundation - Senior System Administrator
> 
> 
> 
> -- 
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
> 
> !DSPAM:4436d470278011542430122!
> 
-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator





From rminnich at lanl.gov  Sat Apr  8 01:56:07 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 07 Apr 2006 17:56:07 -0600
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <20060407221528.GA23521@io.pong.be>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
	<20060407221528.GA23521@io.pong.be>
Message-ID: <4436FC17.6080602@lanl.gov>

Ward Vandewege wrote:

> So that did not help. I'm going to try your next suggestion now.

This still sounds like memory to me. OH, wait ....

can you time the time until it crashes. I had a problem once with a 
watchdog timer. Can you see if it's always the same amount of time.

I doubt this is it, but you never know.

ron



From ward at gnu.org  Sat Apr  8 15:54:52 2006
From: ward at gnu.org (Ward Vandewege)
Date: Sat, 8 Apr 2006 09:54:52 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <4436FC17.6080602@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
	<20060407221528.GA23521@io.pong.be> <4436FC17.6080602@lanl.gov>
Message-ID: <20060408135452.GA32144@io.pong.be>

On Fri, Apr 07, 2006 at 05:56:07PM -0600, Ronald G Minnich wrote:
> Ward Vandewege wrote:
> 
> > So that did not help. I'm going to try your next suggestion now.
> 
> This still sounds like memory to me. OH, wait ....
> 
> can you time the time until it crashes. I had a problem once with a 
> watchdog timer. Can you see if it's always the same amount of time.
> 
> I doubt this is it, but you never know.

OK; thanks for all the extra suggestions guys, I will try them all on Monday.
Look forward to having this one solved :)


Thanks!
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From stuge-linuxbios at cdy.org  Sat Apr  8 20:48:30 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Sat, 8 Apr 2006 20:48:30 +0200
Subject: [LinuxBIOS] SockelA Mainboards supporting LinuxBIOS
In-Reply-To: <200604072154.58801.arti_tevs@yahoo.de>
References: <200604072154.58801.arti_tevs@yahoo.de>
Message-ID: <20060408184831.10675.qmail@cdy.org>

On Fri, Apr 07, 2006 at 09:54:58PM +0200, Art Tevs wrote:
> Does there exists SockelA (AMD Athlon XP) mainboards that are
> supported by the linuxbios project? On the homepage there is no
> such boards listed.

Please check the source tree for the most (only) up-to-date list of
supported hardware.


> I think each board that has removeable BIOS chip should be able to
> support linux. I mean it should be possible to write new version of
> LinuxBIOS for such a board. Or do I think wrong?

Socketed or not, all boards are potential LinuxBIOS machines.

In practice, more often than not it's hard (impossible) to access
satisfactory documentation for the hardware that needs to be
initialized by LinuxBIOS. Clean reverse engineering is an alternative
of course, but that means a lot more work. Leading developers have
chosen hardware with more accessible documentation instead, one
example is AMD over Intel.


//Peter



From frust at iti.cs.tu-bs.de  Mon Apr 10 09:42:05 2006
From: frust at iti.cs.tu-bs.de (Frank Rust)
Date: Mon, 10 Apr 2006 09:42:05 +0200
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
Message-ID: <443A0C4D.1000802@iti.cs.tu-bs.de>

Is this one supported, or might become supported soon?
System SUN FIRE X4100

Mainboard manufacturer: (SUN?)
Processor: one or two Opteron or Opteron Dual Core
Chipset: AMD 8131, AMD 8111
IO: quad channel SAS raid (LSI SAS 1064)
Net: 2 dual 10/100/1000 Ethernet Controllers (Intel FW82546 GB NIC)
Video: ATI Rage XL
Floppy Disc, legacy Serial: SMSC LPC47B272 Super IO Controller
(additional: Management: Motorola MPC8248PowerPC Processor)

Supported OS: Solaris 10 x64, RedHat Enterprise Linux 3.0-4.0, SUSE 
Linux Enterprise Server 9, MS Windows Server 2003

(Documentation: white paper: 
http://www.sun.com/servers/entry/x4100/arch-wp.pdf)

Best regards,
Frank.

-- 
________________________________________________________________________
Frank Rust, Technische Universit?t, Institut f?r Theoretische Informatik
Tel.: +49 531 391 9525               Postfach 3329, D-38023 Braunschweig
Fax.: +49 531 391 9529      M?hlenpfordtstr. 22-23, D-38106 Braunschweig




From stepan at openbios.org  Mon Apr 10 11:13:05 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon, 10 Apr 2006 11:13:05 +0200
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
In-Reply-To: <443A0C4D.1000802@iti.cs.tu-bs.de>
References: <443A0C4D.1000802@iti.cs.tu-bs.de>
Message-ID: <20060410091305.GB16606@openbios.org>

* Frank Rust <frust at iti.cs.tu-bs.de> [060410 09:42]:
> Is this one supported, or might become supported soon?
> System SUN FIRE X4100
> 
> IO: quad channel SAS raid (LSI SAS 1064)
unsupported

> SMSC LPC47B272 Super IO Controller
unsupported

The rest should be rather easy to get up and running. 
the Super IO is needed for serial output and is therefore fundamental.

Stefan





From ward at gnu.org  Mon Apr 10 16:14:51 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 10 Apr 2006 10:14:51 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
In-Reply-To: <4E497EE4DD5F9347B242A83387F27DC821A921@exchsix.olympus.f5net.com>
References: <4E497EE4DD5F9347B242A83387F27DC821A921@exchsix.olympus.f5net.com>
Message-ID: <20060410141451.GA14509@io.pong.be>

On Fri, Apr 07, 2006 at 04:00:28PM -0700, Alan Mimms wrote:
> The code should be setting the 1<<4 bit (so as to clear one of the error
> bits) instead of 1<<6 (the read only bit that signals end of HT bus
> chain).
> 
> After making this change, your board won't hang when the BIOS or Linux
> detects a need to reboot due to some fatal error.
> 
> This is a pretty trivial change to an error case that hardly ever occurs
> but was crucial for us.  I claim this change is safe and correct and
> should be merged into the main line code.

Yes, please merge that change!

Our box now keeps rebooting itself instead of crashing - have a look at the
attached boot log. Maybe this will be more of a clue as to what exactly is
happening? Anyone got anymore ideas?

Thanks, Alan!!
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom_20060410.cap.gz
Type: application/octet-stream
Size: 4048 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060410/40ac7cf0/attachment.obj>

From rminnich at lanl.gov  Mon Apr 10 16:10:08 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 10 Apr 2006 08:10:08 -0600
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
In-Reply-To: <443A0C4D.1000802@iti.cs.tu-bs.de>
References: <443A0C4D.1000802@iti.cs.tu-bs.de>
Message-ID: <443A6740.5070300@lanl.gov>

I think it would "Just work". We've been trying to interest sun for some 
time in a port, but no calls back yet.

ron



From ward at gnu.org  Mon Apr 10 16:33:30 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 10 Apr 2006 10:33:30 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <4436FC17.6080602@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
	<20060407221528.GA23521@io.pong.be> <4436FC17.6080602@lanl.gov>
Message-ID: <20060410143330.GA15384@io.pong.be>

On Fri, Apr 07, 2006 at 05:56:07PM -0600, Ronald G Minnich wrote:
> Ward Vandewege wrote:
> 
> > So that did not help. I'm going to try your next suggestion now.
> 
> This still sounds like memory to me. OH, wait ....
> 
> can you time the time until it crashes. I had a problem once with a 
> watchdog timer. Can you see if it's always the same amount of time.

Assuming you mean from poweron to crash, right?

I've done some tests. I can let it sit for minutes on the etherboot 'Boot
from (N)etwork (D)isk or (Q)uit?' prompt. From the moment it starts FILO's
default kernel, it doesn't last much longer than 11 to 14 seconds. I have 2
datapoints with almost 14 seconds, one with just over 13 seconds and 2 with
just over 11 seconds. Of course these measurements are not very precise since
I had to push the timer buttons manually.

T 000:00:13.248
T 000:00:11.328
T 000:00:11.532
T 000:00:13.864
T 000:00:13.715

The biggest part of that time is spent right after it prints 

  ACPI: Unable to locate RSDP

There is no output for easily 5-6 seconds after printing this.

> I doubt this is it, but you never know.

What do you think, watchdog timer or not? I've attached another (longer)
bootlog with many boot attempts.

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom2_20060410.cap.gz
Type: application/octet-stream
Size: 5802 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060410/05e4a99d/attachment.obj>

From rminnich at lanl.gov  Mon Apr 10 16:40:17 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 10 Apr 2006 08:40:17 -0600
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <20060410143330.GA15384@io.pong.be>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
	<20060407221528.GA23521@io.pong.be> <4436FC17.6080602@lanl.gov>
	<20060410143330.GA15384@io.pong.be>
Message-ID: <443A6E51.7030201@lanl.gov>

not sure if it's watchdog.

Here's the easiest way to tell. boot with
init=/bin/sh

and, once you get the shell prompt, just let it sit there.

At that point, ints are enabled, and if there's something bad going on 
you need to control, you'll know it in about 15 seconds.

I had a vendor do this to me once: they changed the board and connected 
(on the board) and  started enabling a watchdog and did not tell me -- 
one week before an exhibit. I had a sleepless weekend.

Of course, the part # did not change -- they never do ...

ron



From ward at gnu.org  Mon Apr 10 17:18:43 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 10 Apr 2006 11:18:43 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <443A6E51.7030201@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
	<20060407221528.GA23521@io.pong.be> <4436FC17.6080602@lanl.gov>
	<20060410143330.GA15384@io.pong.be> <443A6E51.7030201@lanl.gov>
Message-ID: <20060410151843.GA15774@io.pong.be>

On Mon, Apr 10, 2006 at 08:40:17AM -0600, Ronald G Minnich wrote:
> not sure if it's watchdog.
> 
> Here's the easiest way to tell. boot with
> init=/bin/sh
> and, once you get the shell prompt, just let it sit there.
> 
> At that point, ints are enabled, and if there's something bad going on 
> you need to control, you'll know it in about 15 seconds.

I let it boot 5 times. Used the stopwatch on the last 2 boots:

T 000:00:16.143
T 000:01:20.498

So if it's a watchdog timer, it's a pretty variable one (?). The third boot
also felt like at least a minute. I've attached the boot log.

> I had a vendor do this to me once: they changed the board and connected 
> (on the board) and  started enabling a watchdog and did not tell me -- 
> one week before an exhibit. I had a sleepless weekend.
> 
> Of course, the part # did not change -- they never do ...

Ugh. I don't understand why they never do that. Must make their own support
people's life hell.

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom3_20060410.cap.gz
Type: application/octet-stream
Size: 3919 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060410/29cba86a/attachment.obj>

From rminnich at lanl.gov  Mon Apr 10 17:44:35 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 10 Apr 2006 09:44:35 -0600
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <20060410151843.GA15774@io.pong.be>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B83@ssvlexmb2.amd.com>
	<20060407221528.GA23521@io.pong.be> <4436FC17.6080602@lanl.gov>
	<20060410143330.GA15384@io.pong.be> <443A6E51.7030201@lanl.gov>
	<20060410151843.GA15774@io.pong.be>
Message-ID: <443A7D63.9010104@lanl.gov>

I don't think it's a watchdog.

Next thing you can do for isolation: boot into init=/bin/bash and then 
start up rc one thing at a time.

If we get a chance, we will try out 2881s here.

ron



From yinghai.lu at amd.com  Mon Apr 10 18:01:03 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 10 Apr 2006 09:01:03 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B87@ssvlexmb2.amd.com>

Please try another switch

In southbridge/amd/amd8111/amd8111_pci.c

Line dword |= (1<<27) /* discard Timer */
===> dword &= ~(1<<27);

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
Sent: Monday, April 10, 2006 7:15 AM
To: Alan Mimms
Cc: linuxbios at linuxbios.org; Lu, Yinghai
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)

On Fri, Apr 07, 2006 at 04:00:28PM -0700, Alan Mimms wrote:
> The code should be setting the 1<<4 bit (so as to clear one of the
error
> bits) instead of 1<<6 (the read only bit that signals end of HT bus
> chain).
> 
> After making this change, your board won't hang when the BIOS or Linux
> detects a need to reboot due to some fatal error.
> 
> This is a pretty trivial change to an error case that hardly ever
occurs
> but was crucial for us.  I claim this change is safe and correct and
> should be merged into the main line code.

Yes, please merge that change!

Our box now keeps rebooting itself instead of crashing - have a look at
the
attached boot log. Maybe this will be more of a clue as to what exactly
is
happening? Anyone got anymore ideas?

Thanks, Alan!!
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator




From yinghai.lu at amd.com  Mon Apr 10 18:34:46 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 10 Apr 2006 09:34:46 -0700
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B88@ssvlexmb2.amd.com>

What OS are you going to use?

Things to be checked
1. settings for to make management card working
2. Is the LSI FW on BIOS flash or another separate flash?
3. Boot from SAS raid directly? We may need to use big IDE flash for using tiny kernel and kexec...

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Frank Rust
Sent: Monday, April 10, 2006 12:42 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100

Is this one supported, or might become supported soon?
System SUN FIRE X4100

Mainboard manufacturer: (SUN?)
Processor: one or two Opteron or Opteron Dual Core
Chipset: AMD 8131, AMD 8111
IO: quad channel SAS raid (LSI SAS 1064)
Net: 2 dual 10/100/1000 Ethernet Controllers (Intel FW82546 GB NIC)
Video: ATI Rage XL
Floppy Disc, legacy Serial: SMSC LPC47B272 Super IO Controller
(additional: Management: Motorola MPC8248PowerPC Processor)

Supported OS: Solaris 10 x64, RedHat Enterprise Linux 3.0-4.0, SUSE 
Linux Enterprise Server 9, MS Windows Server 2003

(Documentation: white paper: 
http://www.sun.com/servers/entry/x4100/arch-wp.pdf)

Best regards,
Frank.

-- 
________________________________________________________________________
Frank Rust, Technische Universit?t, Institut f?r Theoretische Informatik
Tel.: +49 531 391 9525               Postfach 3329, D-38023 Braunschweig
Fax.: +49 531 391 9529      M?hlenpfordtstr. 22-23, D-38106 Braunschweig


-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From dlaurie at google.com  Mon Apr 10 20:13:17 2006
From: dlaurie at google.com (Duncan Laurie)
Date: Mon, 10 Apr 2006 11:13:17 -0700
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B88@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B88@ssvlexmb2.amd.com>
Message-ID: <20060410181317.GB2743@google.com>

On Mon, 10 Apr 2006, Lu, Yinghai wrote:
> What OS are you going to use?
> 
> Things to be checked
> 1. settings for to make management card working

Nothing required IIRC, but optional features such as the boot
mailbox are available.  The service processor does not have
an RTC so it relies on the BIOS to set its time with Set SEL
Time command but this could be easily done after boot with
the OpenIPMI driver and ipmitool script.

Flash of system BIOS can be done through the service processor
as it has hooks into the LPC bus (system must be in reset for
this to work).  This means a LinuxBIOS port would not be overly
dangerous since you can always flash a working BIOS by reloading
SP firmware (which includes a system BIOS).

> 2. Is the LSI FW on BIOS flash or another separate flash?
> 3. Boot from SAS raid directly? We may need to use big IDE flash for using tiny kernel and kexec...
> 

LSI firmware is on a separate flash.  Disk boot will be tricky
but getting network boot working should be easier.  Boot over
redirected USB via service processor might also work...

-duncan

> 
> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Frank Rust
> Sent: Monday, April 10, 2006 12:42 AM
> To: linuxbios at linuxbios.org
> Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
> 
> Is this one supported, or might become supported soon?
> System SUN FIRE X4100
> 
> Mainboard manufacturer: (SUN?)
> Processor: one or two Opteron or Opteron Dual Core
> Chipset: AMD 8131, AMD 8111
> IO: quad channel SAS raid (LSI SAS 1064)
> Net: 2 dual 10/100/1000 Ethernet Controllers (Intel FW82546 GB NIC)
> Video: ATI Rage XL
> Floppy Disc, legacy Serial: SMSC LPC47B272 Super IO Controller
> (additional: Management: Motorola MPC8248PowerPC Processor)
> 
> Supported OS: Solaris 10 x64, RedHat Enterprise Linux 3.0-4.0, SUSE 
> Linux Enterprise Server 9, MS Windows Server 2003
> 
> (Documentation: white paper: 
> http://www.sun.com/servers/entry/x4100/arch-wp.pdf)
> 
> Best regards,
> Frank.
> 
> -- 
> ________________________________________________________________________
> Frank Rust, Technische Universit?t, Institut f?r Theoretische Informatik
> Tel.: +49 531 391 9525               Postfach 3329, D-38023 Braunschweig
> Fax.: +49 531 391 9529      M?hlenpfordtstr. 22-23, D-38106 Braunschweig
> 



From ward at gnu.org  Mon Apr 10 20:23:49 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 10 Apr 2006 14:23:49 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B87@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B87@ssvlexmb2.amd.com>
Message-ID: <20060410182349.GA16773@io.pong.be>

On Mon, Apr 10, 2006 at 09:01:03AM -0700, Lu, Yinghai wrote:
> Please try another switch
> 
> In southbridge/amd/amd8111/amd8111_pci.c
> 
> Line dword |= (1<<27) /* discard Timer */
> ===> dword &= ~(1<<27);

Yinghai, you're a hero! The box has been up for 1 hour and 45 minutes. I
think the problem is solved. I'll do more stress testing, but it really looks
like this patch should go into the mainline linuxbios tree.

Thanks!
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Mon Apr 10 20:23:35 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 10 Apr 2006 11:23:35 -0700
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B89@ssvlexmb2.amd.com>

1. Is there anything special in BIOS to be done for making serial over
LAN or IPMI over LAN working with your BMC daughter card...? I mean
connection to NIC shared or I2C.
2. Good to hear that separated FLASH for LSI...
3. Can you check the protocol for USB that BMC simulated? OHCI or UHCI
or EHCI only?

YH

-----Original Message-----
From: Duncan Laurie [mailto:dlaurie at google.com] 
Sent: Monday, April 10, 2006 11:13 AM
To: Lu, Yinghai
Cc: Frank Rust; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] Is this system supported? SUN FIRE X4100

On Mon, 10 Apr 2006, Lu, Yinghai wrote:
> What OS are you going to use?
> 
> Things to be checked
> 1. settings for to make management card working

Nothing required IIRC, but optional features such as the boot
mailbox are available.  The service processor does not have
an RTC so it relies on the BIOS to set its time with Set SEL
Time command but this could be easily done after boot with
the OpenIPMI driver and ipmitool script.

Flash of system BIOS can be done through the service processor
as it has hooks into the LPC bus (system must be in reset for
this to work).  This means a LinuxBIOS port would not be overly
dangerous since you can always flash a working BIOS by reloading
SP firmware (which includes a system BIOS).

> 2. Is the LSI FW on BIOS flash or another separate flash?
> 3. Boot from SAS raid directly? We may need to use big IDE flash for
using tiny kernel and kexec...
> 

LSI firmware is on a separate flash.  Disk boot will be tricky
but getting network boot working should be easier.  Boot over
redirected USB via service processor might also work...

-duncan





From dlaurie at google.com  Mon Apr 10 20:44:05 2006
From: dlaurie at google.com (Duncan Laurie)
Date: Mon, 10 Apr 2006 11:44:05 -0700
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B89@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B89@ssvlexmb2.amd.com>
Message-ID: <20060410184404.GC2743@google.com>

On Mon, 10 Apr 2006, Lu, Yinghai wrote:
> 1. Is there anything special in BIOS to be done for making serial over
> LAN or IPMI over LAN working with your BMC daughter card...? I mean
> connection to NIC shared or I2C.

I don't recall the details; its possible there is some BIOS
interaction involved in setting up the SuperIO for serial mux.

> 2. Good to hear that separated FLASH for LSI...
> 3. Can you check the protocol for USB that BMC simulated? OHCI or UHCI
> or EHCI only?

It should be OHCI.  I remember booting over virtual USB was
rather slow at USB1.1 but infinitely useful.

-duncan


> 
> -----Original Message-----
> From: Duncan Laurie [mailto:dlaurie at google.com] 
> Sent: Monday, April 10, 2006 11:13 AM
> To: Lu, Yinghai
> Cc: Frank Rust; linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] Is this system supported? SUN FIRE X4100
> 
> On Mon, 10 Apr 2006, Lu, Yinghai wrote:
> > What OS are you going to use?
> > 
> > Things to be checked
> > 1. settings for to make management card working
> 
> Nothing required IIRC, but optional features such as the boot
> mailbox are available.  The service processor does not have
> an RTC so it relies on the BIOS to set its time with Set SEL
> Time command but this could be easily done after boot with
> the OpenIPMI driver and ipmitool script.
> 
> Flash of system BIOS can be done through the service processor
> as it has hooks into the LPC bus (system must be in reset for
> this to work).  This means a LinuxBIOS port would not be overly
> dangerous since you can always flash a working BIOS by reloading
> SP firmware (which includes a system BIOS).
> 
> > 2. Is the LSI FW on BIOS flash or another separate flash?
> > 3. Boot from SAS raid directly? We may need to use big IDE flash for
> using tiny kernel and kexec...
> > 
> 
> LSI firmware is on a separate flash.  Disk boot will be tricky
> but getting network boot working should be easier.  Boot over
> redirected USB via service processor might also work...
> 
> -duncan
> 
> 



From ward at gnu.org  Tue Apr 11 00:42:38 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 10 Apr 2006 18:42:38 -0400
Subject: [LinuxBIOS] some more tyan/s2881 questions
Message-ID: <20060410224238.GA20526@io.pong.be>

So the board is stable now. That's great.

Some observations:

1. 'halt' no longer powers the machine off, which it does with the
proprietary bios. 'halt -p' does the job though. LinuxBIOS oddity?

2. reboots seem to cause problems sometimes. I'm not sure yet what causes
this, but I've had problems with the machine hanging after

  ACPI: Unable to locate RSDP

It normally sits there for a few seconds, but I had the machine in such a
state that it simply hung at that point.

This may have had something to do with the IPMI card, which I'm experimenting
with. I had to unplug the power before this problem went away, a cold restart
didn't help. I will do more testing to see if I can pinpoint this.

Thanks for all your help so far!
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Tue Apr 11 01:00:27 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 10 Apr 2006 16:00:27 -0700
Subject: [LinuxBIOS] some more tyan/s2881 questions
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>

1. need to add acpi support in s2881 LinuxBIOS support to get it.
Anyway 8111 acpi support is already there in Serengeti_leopard, so it
will be easy to get that.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
Sent: Monday, April 10, 2006 3:43 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] some more tyan/s2881 questions

So the board is stable now. That's great.

Some observations:

1. 'halt' no longer powers the machine off, which it does with the
proprietary bios. 'halt -p' does the job though. LinuxBIOS oddity?

2. reboots seem to cause problems sometimes. I'm not sure yet what
causes
this, but I've had problems with the machine hanging after

  ACPI: Unable to locate RSDP

It normally sits there for a few seconds, but I had the machine in such
a
state that it simply hung at that point.

This may have had something to do with the IPMI card, which I'm
experimenting
with. I had to unplug the power before this problem went away, a cold
restart
didn't help. I will do more testing to see if I can pinpoint this.

Thanks for all your help so far!
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From stepan at openbios.org  Tue Apr 11 09:58:42 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 11 Apr 2006 09:58:42 +0200
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
In-Reply-To: <20060410181317.GB2743@google.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B88@ssvlexmb2.amd.com>
	<20060410181317.GB2743@google.com>
Message-ID: <20060411075842.GA14594@openbios.org>

* Duncan Laurie <dlaurie at google.com> [060410 20:13]:
> Flash of system BIOS can be done through the service processor
> as it has hooks into the LPC bus (system must be in reset for
> this to work).  This means a LinuxBIOS port would not be overly
> dangerous since you can always flash a working BIOS by reloading
> SP firmware (which includes a system BIOS).

If it works similar to the Sun Fire v20z (newisys 2100e) the flash
upgrade mechanism in the SP is pretty useless as it only works when you
did not mess up the bios of the machine. What this does is tell the
bios: "Please update yourself, here's the data"

Doing the port does not sound too hard though, given you have a 
local machine.

Stefan




From stepan at openbios.org  Tue Apr 11 10:28:06 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 11 Apr 2006 10:28:06 +0200
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
In-Reply-To: <20060410182349.GA16773@io.pong.be>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B87@ssvlexmb2.amd.com>
	<20060410182349.GA16773@io.pong.be>
Message-ID: <20060411082806.GA16099@openbios.org>

* Ward Vandewege <ward at gnu.org> [060410 20:23]:
> On Mon, Apr 10, 2006 at 09:01:03AM -0700, Lu, Yinghai wrote:
> > Please try another switch
> > 
> > In southbridge/amd/amd8111/amd8111_pci.c
> > 
> > Line dword |= (1<<27) /* discard Timer */
> > ===> dword &= ~(1<<27);
> 
> Yinghai, you're a hero! The box has been up for 1 hour and 45 minutes. I
> think the problem is solved. I'll do more stress testing, but it really looks
> like this patch should go into the mainline linuxbios tree.

Is this with both changes from this thread applied?

Stefan



From yinghailu at gmail.com  Tue Apr 11 12:16:08 2006
From: yinghailu at gmail.com (yhlu)
Date: Tue, 11 Apr 2006 03:16:08 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
In-Reply-To: <20060411082806.GA16099@openbios.org>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B87@ssvlexmb2.amd.com>
	<20060410182349.GA16773@io.pong.be>
	<20060411082806.GA16099@openbios.org>
Message-ID: <2ea3fae10604110316m28f2f2b3m252a9005088c901a@mail.gmail.com>

Not yet.

On 4/11/06, Stefan Reinauer <stepan at openbios.org> wrote:
> * Ward Vandewege <ward at gnu.org> [060410 20:23]:
> > On Mon, Apr 10, 2006 at 09:01:03AM -0700, Lu, Yinghai wrote:
> > > Please try another switch
> > >
> > > In southbridge/amd/amd8111/amd8111_pci.c
> > >
> > > Line dword |= (1<<27) /* discard Timer */
> > > ===> dword &= ~(1<<27);
> >
> > Yinghai, you're a hero! The box has been up for 1 hour and 45 minutes. I
> > think the problem is solved. I'll do more stress testing, but it really looks
> > like this patch should go into the mainline linuxbios tree.
>
> Is this with both changes from this thread applied?
>
> Stefan
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From ward at gnu.org  Tue Apr 11 13:37:48 2006
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 11 Apr 2006 07:37:48 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
In-Reply-To: <20060411082806.GA16099@openbios.org>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B87@ssvlexmb2.amd.com>
	<20060410182349.GA16773@io.pong.be>
	<20060411082806.GA16099@openbios.org>
Message-ID: <20060411113748.GA22800@io.pong.be>

On Tue, Apr 11, 2006 at 10:28:06AM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060410 20:23]:
> > On Mon, Apr 10, 2006 at 09:01:03AM -0700, Lu, Yinghai wrote:
> > > Please try another switch
> > > 
> > > In southbridge/amd/amd8111/amd8111_pci.c
> > > 
> > > Line dword |= (1<<27) /* discard Timer */
> > > ===> dword &= ~(1<<27);
> > 
> > Yinghai, you're a hero! The box has been up for 1 hour and 45 minutes. I
> > think the problem is solved. I'll do more stress testing, but it really looks
> > like this patch should go into the mainline linuxbios tree.
> 
> Is this with both changes from this thread applied?

All three in fact - to my local tree. But the first one (small fix from YH on
Friday) has already been applied in the svn tree I see.

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From dlaurie at google.com  Tue Apr 11 18:31:58 2006
From: dlaurie at google.com (Duncan Laurie)
Date: Tue, 11 Apr 2006 09:31:58 -0700
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
In-Reply-To: <20060411075842.GA14594@openbios.org>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B88@ssvlexmb2.amd.com>
	<20060410181317.GB2743@google.com>
	<20060411075842.GA14594@openbios.org>
Message-ID: <20060411163158.GA31774@google.com>

On Tue, 11 Apr 2006, Stefan Reinauer wrote:
> * Duncan Laurie <dlaurie at google.com> [060410 20:13]:
> > Flash of system BIOS can be done through the service processor
> > as it has hooks into the LPC bus (system must be in reset for
> > this to work).  This means a LinuxBIOS port would not be overly
> > dangerous since you can always flash a working BIOS by reloading
> > SP firmware (which includes a system BIOS).
> 
> If it works similar to the Sun Fire v20z (newisys 2100e) the flash
> upgrade mechanism in the SP is pretty useless as it only works when you
> did not mess up the bios of the machine. What this does is tell the
> bios: "Please update yourself, here's the data"
> 

This one is different; considerably more invasive but useful.
It does not care what (if anything) is currently loaded in the
system bios flash and will read and write directly via the LPC
bus.  Since LPC is no good at sharing this requires the system
to be held in reset to guarantee it is idle or all sorts of
strange things will happen.

The downside is you cannot do a BIOS upgrade via the SP through
an in-band method since you would lose communiation. (tricks could
be done to load the image first and flash later but then you lose
notification of failures, etc etc)  It is still possible to do
a direct BIOS flash on the system with the right (DOS) tool.

-duncan




From stepan at coresystems.de  Tue Apr 11 19:27:27 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 11 Apr 2006 19:27:27 +0200
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
In-Reply-To: <20060411163158.GA31774@google.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B88@ssvlexmb2.amd.com>
	<20060410181317.GB2743@google.com>
	<20060411075842.GA14594@openbios.org>
	<20060411163158.GA31774@google.com>
Message-ID: <20060411172727.GA5408@openbios.org>

* Duncan Laurie <dlaurie at google.com> [060411 18:31]:
> This one is different; considerably more invasive but useful.
> It does not care what (if anything) is currently loaded in the
> system bios flash and will read and write directly via the LPC
> bus.  Since LPC is no good at sharing this requires the system
> to be held in reset to guarantee it is idle or all sorts of
> strange things will happen.
 
Nice! Keeping the system in reset is nothing evil, as a system with a
corrupted bios won't do much anyways :)

> The downside is you cannot do a BIOS upgrade via the SP through
> an in-band method since you would lose communiation. (tricks could
> be done to load the image first and flash later but then you lose
> notification of failures, etc etc)  It is still possible to do
> a direct BIOS flash on the system with the right (DOS) tool.

or probably with the LinuxBIOS flashrom utility. 

  Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From a.mimms at f5.com  Tue Apr 11 19:39:18 2006
From: a.mimms at f5.com (Alan Mimms)
Date: Tue, 11 Apr 2006 10:39:18 -0700
Subject: [LinuxBIOS] Is this system supported? SUN FIRE X4100
Message-ID: <4E497EE4DD5F9347B242A83387F27DC821AB62@exchsix.olympus.f5net.com>

Danger Will Robinson!  We found certain (won't name them) PCI-X cards
that consume HUGE amounts of power when held in RESET.  Of course YMMV,
but keeping the motherboard in reset for long periods of time CAN be
detrimental...

Alan Mimms, Senior Architect
F5 Networks, Inc.  Spokane Development Center
1322 North Whitman Lane
Liberty Lake, Washington   99019
v: 509-343-3524   f: 509-343-3501
 

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Stefan Reinauer
Sent: Tuesday, April 11, 2006 10:27 AM
To: Duncan Laurie
Cc: Frank Rust; linuxbios at linuxbios.org; Lu,Yinghai
Subject: Re: [LinuxBIOS] Is this system supported? SUN FIRE X4100

* Duncan Laurie <dlaurie at google.com> [060411 18:31]:
> This one is different; considerably more invasive but useful.
> It does not care what (if anything) is currently loaded in the
> system bios flash and will read and write directly via the LPC
> bus.  Since LPC is no good at sharing this requires the system
> to be held in reset to guarantee it is idle or all sorts of
> strange things will happen.
 
Nice! Keeping the system in reset is nothing evil, as a system with a
corrupted bios won't do much anyways :)

> The downside is you cannot do a BIOS upgrade via the SP through
> an in-band method since you would lose communiation. (tricks could
> be done to load the image first and flash later but then you lose
> notification of failures, etc etc)  It is still possible to do
> a direct BIOS flash on the system with the right (DOS) tool.

or probably with the LinuxBIOS flashrom utility. 

  Stefan

-- 
coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 * Fax: +49 761 7664613
Email: info at coresystems.de  * http://www.coresystems.de/

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios



From stepan at coresystems.de  Tue Apr 11 20:38:06 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 11 Apr 2006 20:38:06 +0200
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
In-Reply-To: <20060411113748.GA22800@io.pong.be>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B87@ssvlexmb2.amd.com>
	<20060410182349.GA16773@io.pong.be>
	<20060411082806.GA16099@openbios.org>
	<20060411113748.GA22800@io.pong.be>
Message-ID: <20060411183806.GB8338@openbios.org>

* Ward Vandewege <ward at gnu.org> [060411 13:37]:
> All three in fact - to my local tree. But the first one (small fix from YH on
> Friday) has already been applied in the svn tree I see.
> 
> Ward.
 
Ok, committed in revision 2251. Could you please update to this version
and verify it's working correctly?

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From yinghai.lu at amd.com  Tue Apr 11 20:45:57 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 11 Apr 2006 11:45:57 -0700
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B98@ssvlexmb2.amd.com>

Please add comment before discard timer on amd 8111....

I didn't figure the reason for that yet.

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at coresystems.de] 
Sent: Tuesday, April 11, 2006 11:38 AM
To: Ward Vandewege
Cc: linuxbios at linuxbios.org; Lu, Yinghai
Subject: Re: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)

* Ward Vandewege <ward at gnu.org> [060411 13:37]:
> All three in fact - to my local tree. But the first one (small fix
from YH on
> Friday) has already been applied in the svn tree I see.
> 
> Ward.
 
Ok, committed in revision 2251. Could you please update to this version
and verify it's working correctly?

Stefan

-- 
coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 * Fax: +49 761 7664613
Email: info at coresystems.de  * http://www.coresystems.de/





From stepan at coresystems.de  Tue Apr 11 20:50:21 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 11 Apr 2006 20:50:21 +0200
Subject: [LinuxBIOS] Intel Southbridges
In-Reply-To: <20060406211246.GA15520@openbios.org>
References: <20060406092743.GA3728@openbios.org> <44352E4F.3070107@lanl.gov>
	<20060406211246.GA15520@openbios.org>
Message-ID: <20060411185021.GD8338@openbios.org>

* Stefan Reinauer <stepan at coresystems.de> [060406 23:12]:
> * Ronald G Minnich <rminnich at lanl.gov> [060406 17:05]:
> > >Since all mainboards except one are using the ich5r, I suggest 
> > >deleting the 82801er directory and renaming the ich5r to 82801er to keep
> > >consistence in the naming scheme
> > 
> > I think this makes sense.
> 
> Ok, I'm preparing a patch.

Can anyone try the latest release with the changes I made? Especially
the Tyan s2735 board.

Stefan




From c-d.hailfinger.devel.2006 at gmx.net  Tue Apr 11 21:55:26 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 11 Apr 2006 21:55:26 +0200
Subject: [LinuxBIOS] flash_rom on Nvidia CK804
Message-ID: <443C09AE.6040501@gmx.net>

Hi,

I want to flash a legacy BIOS on my ASUS A8N-SLI Deluxe,
but to make sure I don't screw up, I tried to backup the
existing BIOS first. However, running a binary diff between
the image extracted from the chip via flash_rom and the
vendor-supplied image of the same BIOS version, it seems
that a few sections differ.
The image is 512 kb big.


From yinghai.lu at amd.com  Tue Apr 11 22:10:16 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 11 Apr 2006 13:10:16 -0700
Subject: [LinuxBIOS] flash_rom on Nvidia CK804
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B9B@ssvlexmb2.amd.com>

These should be DMI info ....,

You can backup it and restore it late.

YH




From roger at eskimo.com  Tue Apr 11 21:28:24 2006
From: roger at eskimo.com (roger at eskimo.com)
Date: Tue, 11 Apr 2006 12:28:24 -0700
Subject: [LinuxBIOS] Emulator for linuxbios
Message-ID: <1144783704.5455.1.camel@localhost2.localdomain>

Any possible solutions for using an emulator to test linuxbios payloads?

ie. Bochs?





From stepan at coresystems.de  Tue Apr 11 22:31:53 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 11 Apr 2006 22:31:53 +0200
Subject: [LinuxBIOS] Emulator for linuxbios
In-Reply-To: <1144783704.5455.1.camel@localhost2.localdomain>
References: <1144783704.5455.1.camel@localhost2.localdomain>
Message-ID: <20060411203153.GA31453@openbios.org>

* roger at eskimo.com <roger at eskimo.com> [060411 21:28]:
> Any possible solutions for using an emulator to test linuxbios payloads?
> 
> ie. Bochs?

Try qemu - I ported LinuxBIOS to it (on x86) a while ago

 Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From roger at eskimo.com  Tue Apr 11 21:47:56 2006
From: roger at eskimo.com (roger at eskimo.com)
Date: Tue, 11 Apr 2006 12:47:56 -0700
Subject: [LinuxBIOS] Emulator for linuxbios
In-Reply-To: <20060411203153.GA31453@openbios.org>
References: <1144783704.5455.1.camel@localhost2.localdomain>
	<20060411203153.GA31453@openbios.org>
Message-ID: <1144784876.5455.4.camel@localhost2.localdomain>

Ah! Many thanks!

Gentoo:
app-emulation/qemu

I should now have lots of fun - even if I don't have a supported
motherboard!


On Tue, 2006-04-11 at 22:31 +0200, Stefan Reinauer wrote:
> * roger at eskimo.com <roger at eskimo.com> [060411 21:28]:
> > Any possible solutions for using an emulator to test linuxbios payloads?
> > 
> > ie. Bochs?
> 
> Try qemu - I ported LinuxBIOS to it (on x86) a while ago
> 
>  Stefan
> 




From c-d.hailfinger.devel.2006 at gmx.net  Wed Apr 12 06:17:51 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 12 Apr 2006 06:17:51 +0200
Subject: [LinuxBIOS] flash_rom on Nvidia CK804
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B9B@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B9B@ssvlexmb2.amd.com>
Message-ID: <443C7F6F.90803@gmx.net>

Lu, Yinghai schrieb:
> These should be DMI info ....,

The later section (2.2 kb) really are DMI info.

But I strongly doubt that the missing 128 kb in the middle are
all DMI info. Especially the fact that here flash_rom reads
a consecutive block of 0xff while the vendor BIOS image has
real contents seems the wrong way. If it were DMI info, the
vendor BIOS image should have the 0xff and not flash_rom.

> You can backup it and restore it late.

Thanks for the hint.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From roger at eskimo.com  Wed Apr 12 06:18:11 2006
From: roger at eskimo.com (roger)
Date: Tue, 11 Apr 2006 21:18:11 -0700
Subject: [LinuxBIOS] qemu missing openbios.elf within Config.lb?
Message-ID: <1144815491.14193.6.camel@localhost3.localdomain>

Trying to build an image for qemu and am stumped as to how to get the
openbios.elf file?  Or should I use filo with using Qemu?

~/src/linuxbios/LinuxBIOSv2-2247/targets/emulation/qemu-i386/Config.lb


mainboard emulation/qemu-i386

option ROM_SIZE=0x40000

option CC="gcc -m32"

romimage "image"
        option USE_FALLBACK_IMAGE=1
        option ROM_IMAGE_SIZE=0x10000
        option LINUXBIOS_EXTRA_VERSION="-OpenBIOS"
        payload /home/stepan/openbios.elf

end

buildrom ./qemu-bios.rom ROM_SIZE "image"

--
Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61

Tue Apr 11 21:18:10 PDT 2006




From stepan at coresystems.de  Wed Apr 12 10:07:21 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 12 Apr 2006 10:07:21 +0200
Subject: [LinuxBIOS] flash_rom on Nvidia CK804
In-Reply-To: <443C7F6F.90803@gmx.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B9B@ssvlexmb2.amd.com>
	<443C7F6F.90803@gmx.net>
Message-ID: <20060412080721.GB10331@openbios.org>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060412 06:17]:
> Lu, Yinghai schrieb:
> > These should be DMI info ....,
> 
> The later section (2.2 kb) really are DMI info.
> 
> But I strongly doubt that the missing 128 kb in the middle are
> all DMI info. Especially the fact that here flash_rom reads
> a consecutive block of 0xff while the vendor BIOS image has
> real contents seems the wrong way. If it were DMI info, the
> vendor BIOS image should have the 0xff and not flash_rom.

What does that content look like?

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Wed Apr 12 10:08:41 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 12 Apr 2006 10:08:41 +0200
Subject: [LinuxBIOS] qemu missing openbios.elf within Config.lb?
In-Reply-To: <1144815491.14193.6.camel@localhost3.localdomain>
References: <1144815491.14193.6.camel@localhost3.localdomain>
Message-ID: <20060412080841.GC10331@openbios.org>

* roger <roger at eskimo.com> [060412 06:18]:
> Trying to build an image for qemu and am stumped as to how to get the
> openbios.elf file?  Or should I use filo with using Qemu?

It's the payload file. you can use whatever you want to. :-)

for OpenBIOS as payload, go check www.openbios.org for now.

  Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From c-d.hailfinger.devel.2006 at gmx.net  Wed Apr 12 16:12:12 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 12 Apr 2006 16:12:12 +0200
Subject: [LinuxBIOS] flash_rom on Nvidia CK804
In-Reply-To: <20060412080721.GB10331@openbios.org>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B9B@ssvlexmb2.amd.com>	<443C7F6F.90803@gmx.net>
	<20060412080721.GB10331@openbios.org>
Message-ID: <443D0ABC.8050806@gmx.net>

Stefan Reinauer schrieb:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060412 06:17]:
> 
>>Lu, Yinghai schrieb:
>>
>>>These should be DMI info ....,
>>
>>The later section (2.2 kb) really are DMI info.
>>
>>But I strongly doubt that the missing 128 kb in the middle are
>>all DMI info. Especially the fact that here flash_rom reads
>>a consecutive block of 0xff while the vendor BIOS image has
>>real contents seems the wrong way. If it were DMI info, the
>>vendor BIOS image should have the 0xff and not flash_rom.
> 
> 
> What does that content look like?

Looks like valid x86 instructions.

The following archive has both BIOS images (the extracted one and
the vendor-suplied one) inside.
http://www-ti.informatik.uni-tuebingen.de/~hailfing/biosimages.tar.bz2

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From sleff1970 at yahoo.com  Wed Apr 12 18:20:42 2006
From: sleff1970 at yahoo.com (Scott Leffel)
Date: Wed, 12 Apr 2006 09:20:42 -0700 (PDT)
Subject: [LinuxBIOS]  flash_rom on Nvidia CK804
Message-ID: <20060412162042.2705.qmail@web37005.mail.mud.yahoo.com>

When this thread began the other day, I know mention was made of the Asus A8N-SLI Deluxe board.  Since (I think) the focus of this discussion has been on making sure it's safe to flash an Asus image back onto the board, I wanted to make sure the inference I'm drawing is correct, namely that this board in fact supports a working build of LinuxBIOS v2.0?  One of my main systems is based on that board, and since I've been wanting to dabble in LinuxBIOS for a long time (but, alas, haven't had any supported hardware) I thought this sounded like a good opening.  Is CK804 some barely published term for the nForce4 'southbridge'?  When I've searched nVidia's own site for the keyword CK804 it's always come up with nothing, so I had no idea that might have been referring to my own chip(set) all along.

If this does successfully build, and safely burn to flash, does anybody know if the 4Mib is sufficient for a useful kernel, or would I need to use an EtherBoot payload?

Hopefully this isn't too risky; my only other faintly promising prospect - in terms of a board that was ever on the supported hardware list - is with an OLD Tyan "Tsunami" S1846 board!  That was merged into FreeBIOS v1.0, oh, it looks like sometime several years ago, and has since been seemingly dumped.  Doh!


		
---------------------------------
Love cheap thrills? Enjoy PC-to-Phone  calls to 30+ countries for just 2?/min with Yahoo! Messenger with Voice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060412/c24758d7/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Wed Apr 12 18:39:23 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 12 Apr 2006 18:39:23 +0200
Subject: [LinuxBIOS] flash_rom on Nvidia CK804
In-Reply-To: <20060412162042.2705.qmail@web37005.mail.mud.yahoo.com>
References: <20060412162042.2705.qmail@web37005.mail.mud.yahoo.com>
Message-ID: <443D2D3B.1080005@gmx.net>

Scott Leffel schrieb:
> When this thread began the other day, I know mention was made of the
> Asus A8N-SLI Deluxe board.  Since (I think) the focus of this
> discussion has been on making sure it's safe to flash an Asus image

Yes.

> back onto the board, I wanted to make sure the inference I'm drawing
> is correct, namely that this board in fact supports a working build
> of LinuxBIOS v2.0?

Sorry, no. I wanted to port LinuxBIOS to this board, but I didn't have
time yet (and I hoped somebody else would do it). The data sheets for
the ITE 8712F-A SuperIO should have been uploaded to the LinuxBIOS site
a while ago.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From c-d.hailfinger.devel.2006 at gmx.net  Thu Apr 13 00:40:57 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 13 Apr 2006 00:40:57 +0200
Subject: [LinuxBIOS] flash_rom on Nvidia CK804
In-Reply-To: <20060412213542.18128.qmail@web37009.mail.mud.yahoo.com>
References: <20060412213542.18128.qmail@web37009.mail.mud.yahoo.com>
Message-ID: <443D81F9.2010701@gmx.net>

Hi Scott,

Scott Leffel schrieb:
> 
> or another of the embedded systems developers I know would have
> a little spare time though, so I'll have to see if I can get them
> interested in LinuxBIOS. As for

That would be cool.

> the chipset hurdle, is the CK804 = nForce4? Just trying to gauge
> roughly how far along this might already be in terms of progress.

Yes. AFAICS you would just need to find someone writing the driver
for the SuperIO and a little bit of glue code and you'd be done.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From c-d.hailfinger.devel.2006 at gmx.net  Thu Apr 13 00:50:21 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 13 Apr 2006 00:50:21 +0200
Subject: [LinuxBIOS] Chipset docs for ITE 8712F missing
Message-ID: <443D842D.8070000@gmx.net>

Hi Ron,

iirc you wanted to post the docs for the ITE 8712F SuperIO to
the LinuxBIOS website. However, I can't find them with the
wiki search. Did I make a mistake?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From stepan at coresystems.de  Thu Apr 13 01:28:34 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 13 Apr 2006 01:28:34 +0200
Subject: [LinuxBIOS] Chipset docs for ITE 8712F missing
In-Reply-To: <443D842D.8070000@gmx.net>
References: <443D842D.8070000@gmx.net>
Message-ID: <20060412232834.GA22473@coresystems.de>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060413 00:50]:
> Hi Ron,
> 
> iirc you wanted to post the docs for the ITE 8712F SuperIO to
> the LinuxBIOS website. However, I can't find them with the
> wiki search. Did I make a mistake?

Dont think they ever went there, as noone volunteered for a port
anyways.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From c-d.hailfinger.devel.2006 at gmx.net  Thu Apr 13 02:35:58 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 13 Apr 2006 02:35:58 +0200
Subject: [LinuxBIOS] Chipset docs for ITE 8712F missing
In-Reply-To: <20060412232834.GA22473@coresystems.de>
References: <443D842D.8070000@gmx.net> <20060412232834.GA22473@coresystems.de>
Message-ID: <443D9CEE.8010500@gmx.net>

Stefan Reinauer schrieb:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060413 00:50]:
> 
>>Hi Ron,
>>
>>iirc you wanted to post the docs for the ITE 8712F SuperIO to
>>the LinuxBIOS website. However, I can't find them with the
>>wiki search. Did I make a mistake?
> 
> 
> Dont think they ever went there, as noone volunteered for a port
> anyways.

I wanted to do it back then. And I'll probably do it in a few weeks
if nobody beats me to it. This will make it easy to support a lot of
Asus boards.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From c-d.hailfinger.devel.2006 at gmx.net  Thu Apr 13 04:26:10 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 13 Apr 2006 04:26:10 +0200
Subject: [LinuxBIOS] Chipset docs for ITE 8712F missing
In-Reply-To: <443D9CEE.8010500@gmx.net>
References: <443D842D.8070000@gmx.net> <20060412232834.GA22473@coresystems.de>
	<443D9CEE.8010500@gmx.net>
Message-ID: <443DB6C2.4090206@gmx.net>

Carl-Daniel Hailfinger schrieb:
> Stefan Reinauer schrieb:
> 
>>* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060413 00:50]:
>>
>>
>>>Hi Ron,
>>>
>>>iirc you wanted to post the docs for the ITE 8712F SuperIO to
>>>the LinuxBIOS website. However, I can't find them with the
>>>wiki search. Did I make a mistake?
>>
>>
>>Dont think they ever went there, as noone volunteered for a port
>>anyways.
> 
> 
> I wanted to do it back then. And I'll probably do it in a few weeks
> if nobody beats me to it. This will make it easy to support a lot of
> Asus boards.

Heh. ITE even allows anybody to download "BIOS sample code" for their
SuperIO chips. What can I ask more?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From c-d.hailfinger.devel.2006 at gmx.net  Thu Apr 13 18:03:50 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 13 Apr 2006 18:03:50 +0200
Subject: [LinuxBIOS] flash_rom on Nvidia CK804
In-Reply-To: <443D0ABC.8050806@gmx.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B9B@ssvlexmb2.amd.com>	<443C7F6F.90803@gmx.net>	<20060412080721.GB10331@openbios.org>
	<443D0ABC.8050806@gmx.net>
Message-ID: <443E7666.6050902@gmx.net>

Carl-Daniel Hailfinger wrote:
> Stefan Reinauer wrote:
> 
>>* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060412 06:17]:
>>
>>>Lu, Yinghai wrote:
>>>
>>>
>>>>These should be DMI info ....,
>>>
>>>The later section (2.2 kb) really are DMI info.
>>>
>>>But I strongly doubt that the missing 128 kb in the middle are
>>>all DMI info. Especially the fact that here flash_rom reads
>>>a consecutive block of 0xff while the vendor BIOS image has
>>>real contents seems the wrong way. If it were DMI info, the
>>>vendor BIOS image should have the 0xff and not flash_rom.
>>
>>What does that content look like?
> 
> Looks like valid x86 instructions.

I tested with awdflash and the readout of awdflash does not exhibit
this bug. Any idea how to fix it in flash_rom?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From ward at gnu.org  Fri Apr 14 23:47:06 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 14 Apr 2006 17:47:06 -0400
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK (and a patch)
In-Reply-To: <20060411183806.GB8338@openbios.org>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B87@ssvlexmb2.amd.com>
	<20060410182349.GA16773@io.pong.be>
	<20060411082806.GA16099@openbios.org>
	<20060411113748.GA22800@io.pong.be>
	<20060411183806.GB8338@openbios.org>
Message-ID: <20060414214706.GA26346@io.pong.be>

On Tue, Apr 11, 2006 at 08:38:06PM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060411 13:37]:
> > All three in fact - to my local tree. But the first one (small fix from YH on
> > Friday) has already been applied in the svn tree I see.
> > 
> > Ward.
>  
> Ok, committed in revision 2251. Could you please update to this version
> and verify it's working correctly?

I've checked out a clean 2254 tree. Compiled & installed, works great still.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From ward at gnu.org  Fri Apr 14 23:57:56 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 14 Apr 2006 17:57:56 -0400
Subject: [LinuxBIOS] compile problems s2881
Message-ID: <20060414215756.GB26346@io.pong.be>

Hi all,

I just checked out a clean s2881 tree (2254), and built it.

Along the way, I had to make a few changes to make it compile.

1. in targets/tyan/s2881/s2881/config.py, my machine required:
- a '#!/usr/bin/env python' line at the start of the file
- the file to be executable

2. compilation then failed as follows:
# make
...
Traceback (most recent call last):
  File "tyan/s2881/s2881/config.py", line 1541, in ?
    from yappsrt import *
ImportError: No module named yappsrt
make: *** [Makefile.settings] Error 1

I had to copy the yappsrt.py file from util/newconfig to the tyan/s2881/s2881
directory, and then everything worked fine.

Note that I only saw those problems with a freshly checked out tree. Once
I compiled successfully just once, I could erase tyan/s2881/s2881, redo the
buildtarget step, and make would work just fine in tyan/2881/s2881 without
these modifications.

Not sure what's causing this - my solution is clearly just a workaround. Any
ideas for a fix? I've observed these issues on a Debian testing/unstable
system, as well as an Ubuntu Breezy one.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From ward at gnu.org  Sat Apr 15 00:28:46 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 14 Apr 2006 18:28:46 -0400
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
Message-ID: <20060414222846.GA28759@io.pong.be>

On Mon, Apr 10, 2006 at 04:00:27PM -0700, Lu, Yinghai wrote:
> 1. need to add acpi support in s2881 LinuxBIOS support to get it.
> Anyway 8111 acpi support is already there in Serengeti_leopard, so it
> will be easy to get that.

Thanks, I see that halt now powers off the machine properly (svn 2254)!

Still has the delays after

  ACPI: Unable to locate RSDP

on boot.

Thanks,
Ward.

> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
> Sent: Monday, April 10, 2006 3:43 PM
> To: linuxbios at linuxbios.org
> Subject: [LinuxBIOS] some more tyan/s2881 questions
> 
> So the board is stable now. That's great.
> 
> Some observations:
> 
> 1. 'halt' no longer powers the machine off, which it does with the
> proprietary bios. 'halt -p' does the job though. LinuxBIOS oddity?
> 
> 2. reboots seem to cause problems sometimes. I'm not sure yet what
> causes
> this, but I've had problems with the machine hanging after
> 
>   ACPI: Unable to locate RSDP
> 
> It normally sits there for a few seconds, but I had the machine in such
> a
> state that it simply hung at that point.
> 
> This may have had something to do with the IPMI card, which I'm
> experimenting
> with. I had to unplug the power before this problem went away, a cold
> restart
> didn't help. I will do more testing to see if I can pinpoint this.
> 
> Thanks for all your help so far!
> Ward.
> 
> -- 
> Ward Vandewege <ward at fsf.org>
> Free Software Foundation - Senior System Administrator
> 
> -- 
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
> 
> 
> -- 
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
> 
> !DSPAM:443ae48e228441410093335!
> 
-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Sat Apr 15 01:11:46 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 14 Apr 2006 16:11:46 -0700
Subject: [LinuxBIOS] some more tyan/s2881 questions
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BBC@ssvlexmb2.amd.com>

Without enabling the ACPI, the power off works? 

YH




From stepan at coresystems.de  Sat Apr 15 01:39:30 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 15 Apr 2006 01:39:30 +0200
Subject: [LinuxBIOS] compile problems s2881
In-Reply-To: <20060414215756.GB26346@io.pong.be>
References: <20060414215756.GB26346@io.pong.be>
Message-ID: <20060414233930.GA4418@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060414 23:57]:
> I just checked out a clean s2881 tree (2254), and built it.
> 
> Along the way, I had to make a few changes to make it compile.
> 
> 1. in targets/tyan/s2881/s2881/config.py, my machine required:
> - a '#!/usr/bin/env python' line at the start of the file
> - the file to be executable
> 
> 2. compilation then failed as follows:
> # make
> ...
> Traceback (most recent call last):
>   File "tyan/s2881/s2881/config.py", line 1541, in ?
>     from yappsrt import *
> ImportError: No module named yappsrt
> make: *** [Makefile.settings] Error 1
> 
> I had to copy the yappsrt.py file from util/newconfig to the tyan/s2881/s2881
> directory, and then everything worked fine.

Sounds like either you have a broken or a brand new or a really old 
python version.  What python version are you using?

This kind of stuff happens all the time with python based software. 

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Sat Apr 15 02:00:57 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 14 Apr 2006 19:00:57 -0500
Subject: [LinuxBIOS] compile problems s2881
In-Reply-To: <20060414233930.GA4418@coresystems.de>
References: <20060414215756.GB26346@io.pong.be>
	<20060414233930.GA4418@coresystems.de>
Message-ID: <8a0c36780604141700l230ccafk5b3fd829265c7dd9@mail.gmail.com>

> >
> > I had to copy the yappsrt.py file from util/newconfig to the tyan/s2881/s2881
> > directory, and then everything worked fine.
>
> Sounds like either you have a broken or a brand new or a really old
> python version.  What python version are you using?
>

Sounds more to me like the PYTHONPATH is not setup correctly.  The
reason it works the 2nd time is that python has compiled the module
into a .pyc in the current directory and now doesn't have to go look
though PYTHONPATH to find the module.

Modules either need to be in the current directory, have the proper
path to them specified, be in PYTHONPATH or be placed in the default
locations under the python tree.

> This kind of stuff happens all the time with python based software.

I don't see any difference between this and having your include or
library paths set properly in "C".  I don't know of any language that
will go searching your entire hard drive looking for files when it
can't find them where it expects them.

--
Richard A. Smith

From micael.beronius at telia.com  Sat Apr 15 16:00:11 2006
From: micael.beronius at telia.com (Micael Beronius)
Date: Sat, 15 Apr 2006 16:00:11 +0200
Subject: [LinuxBIOS] Intel D865GLC motherboard support?
Message-ID: <200604151600.11771.micael.beronius@telia.com>


Hi all,

I have been reading up on Linuxbios, and with 2 motherboards from Intel that 
I'd like to use for this project, I feel it is time to start up.

How complicated is it to adapt Linuxbios to these two boards? Has it been done 
(did not find any indicatons for this searching the list and reading the 
doc), and if not, what's missing.

These boards uses the 865G chipset with gigabit ethernet through CSA and Intel 
specifies:
82801EB I/O Controller HUB (ICH5)
82802AB 4Mbit Firmware Hub
82865G Graphics and Memory Controller Hub
Analog devices AD1985 Audio codec
LPC Bus I/O Controller (both SMSC LPC47M172 and National Semiconductor PC87372 
are listen)
Gigabit ethernet using Intel 82547EI PLC (over CSA)

All according to the documentation 
ftp://download.intel.com/design/motherbd/lc/C3263401.pdf

lspci gives;
helium micke # lspci
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub 
Interface (rev 02)
00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev 
02)
00:03.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to CSA Bridge (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI 
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI 
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI 
Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI 
Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI 
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface 
Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE 
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 
02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 
02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) 
AC'97 Audio Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 6200 (rev a1)
02:01.0 Ethernet controller: Intel Corporation 82547EI Gigabit Ethernet 
Controller (LOM)


Thanks,

 - Micael



From rminnich at lanl.gov  Sun Apr 16 22:18:18 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 16 Apr 2006 14:18:18 -0600
Subject: [LinuxBIOS] compile problems s2881
In-Reply-To: <20060414215756.GB26346@io.pong.be>
References: <20060414215756.GB26346@io.pong.be>
Message-ID: <4442A68A.7000200@lanl.gov>

Ward Vandewege wrote:

> I had to copy the yappsrt.py file from util/newconfig to the tyan/s2881/s2881
> directory, and then everything worked fine.

we definitely don't want this? This has not been needed for anything 
else. Wonder what's wrong?

Not sure what is going on here, have not seen this on FCx

ron



From JJia at Fortinet.com  Mon Apr 17 20:22:40 2006
From: JJia at Fortinet.com (Jia Jianwei)
Date: Mon, 17 Apr 2006 11:22:40 -0700
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B59@ssvlexmb2.amd.com>
Message-ID: <00c401c6624b$e9641f40$3a4610ac@fortinet.com>


Sata should be working with the following initializing code. (verified on
two boards). Thanks!

Jianwei


void HT1000_SATA_init( void )
{
        volatile unsigned int *mmio_reg;
        unsigned int mmio_base,val32;
        int i;

        pcibios_write_config_byte( 1, HT1000_SATA, 0x70, 0x18);
        pcibios_write_config_byte( 1, HT1000_SATA, 0x78, 0x04);

        pcibios_read_config_dword (1, HT1000_SATA, 0x24, &mmio_base);

        mmio_base &= 0xfffffffc;

        mmio_reg = (unsigned int *)( mmio_base + 0x10f0 );

        * mmio_reg = 0x40000001;

        mmio_reg = ( unsigned int *)( mmio_base + 0x8c );
        * mmio_reg = 0x00ff2007;
        mdelay( 10 );
        * mmio_reg = 0x78592009;
        mdelay( 10 );
        * mmio_reg = 0x00082004;
        mdelay( 10 );
        * mmio_reg = 0x00002004;
        mdelay( 10 );

        for( i = 0; i < 4; i ++ )
        {
                mmio_reg = ( unsigned int *)( mmio_base + 0x40 + i * 256 );
                val32 = *mmio_reg ;
                if( val32 & 0x4 )
                {
                        mmio_reg = ( unsigned int *)( mmio_base + 0x48 + i *
256);
                        val32 = *mmio_reg;
                        val32 |= 1;
                        *mmio_reg = val32;
                        mdelay( 10 );
                        val32 &= ( ~1 );
                        *mmio_reg = val32;
                        mdelay( 10 );
                }
        }

}




----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "Jia Jianwei" <JJia at Fortinet.com>; <linuxbios at linuxbios.org>
Sent: Friday, March 31, 2006 11:40 AM
Subject: RE: [LinuxBIOS] broadcom HT1000 SATA PHY initializing


> You should be right.
>
> When I was testing that on Broadcom BLAST ref board: STAT and IDE
> doesn't work.
>
> But on another MB (serverworks HT1000 based), IDE is working.
>
> Maybe some magic bit in pci conf space need to set by option rom...
>
> You could compare the pci conf dump between system bios and LinuxBIOS...
>
> BTW, Can drop your funny signature in LinuxBIOS?
>
> YH
>
>
>




From yinghai.lu at amd.com  Mon Apr 17 20:30:38 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 17 Apr 2006 11:30:38 -0700
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BC1@ssvlexmb2.amd.com>

Good.

Where to call it? Auto stage or called by hardwaremain driver?

Need to be effective after soft_reset?

YH

-----Original Message-----
From: Jia Jianwei [mailto:JJia at Fortinet.com] 
Sent: Monday, April 17, 2006 11:23 AM
To: Lu, Yinghai; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] broadcom HT1000 SATA PHY initializing


Sata should be working with the following initializing code. (verified
on
two boards). Thanks!

Jianwei


void HT1000_SATA_init( void )
{
        volatile unsigned int *mmio_reg;
        unsigned int mmio_base,val32;
        int i;

        pcibios_write_config_byte( 1, HT1000_SATA, 0x70, 0x18);
        pcibios_write_config_byte( 1, HT1000_SATA, 0x78, 0x04);

        pcibios_read_config_dword (1, HT1000_SATA, 0x24, &mmio_base);

        mmio_base &= 0xfffffffc;

        mmio_reg = (unsigned int *)( mmio_base + 0x10f0 );

        * mmio_reg = 0x40000001;

        mmio_reg = ( unsigned int *)( mmio_base + 0x8c );
        * mmio_reg = 0x00ff2007;
        mdelay( 10 );
        * mmio_reg = 0x78592009;
        mdelay( 10 );
        * mmio_reg = 0x00082004;
        mdelay( 10 );
        * mmio_reg = 0x00002004;
        mdelay( 10 );

        for( i = 0; i < 4; i ++ )
        {
                mmio_reg = ( unsigned int *)( mmio_base + 0x40 + i * 256
);
                val32 = *mmio_reg ;
                if( val32 & 0x4 )
                {
                        mmio_reg = ( unsigned int *)( mmio_base + 0x48 +
i *
256);
                        val32 = *mmio_reg;
                        val32 |= 1;
                        *mmio_reg = val32;
                        mdelay( 10 );
                        val32 &= ( ~1 );
                        *mmio_reg = val32;
                        mdelay( 10 );
                }
        }

}




----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "Jia Jianwei" <JJia at Fortinet.com>; <linuxbios at linuxbios.org>
Sent: Friday, March 31, 2006 11:40 AM
Subject: RE: [LinuxBIOS] broadcom HT1000 SATA PHY initializing


> You should be right.
>
> When I was testing that on Broadcom BLAST ref board: STAT and IDE
> doesn't work.
>
> But on another MB (serverworks HT1000 based), IDE is working.
>
> Maybe some magic bit in pci conf space need to set by option rom...
>
> You could compare the pci conf dump between system bios and
LinuxBIOS...
>
> BTW, Can drop your funny signature in LinuxBIOS?
>
> YH
>
>
>






From JJia at Fortinet.com  Mon Apr 17 20:49:19 2006
From: JJia at Fortinet.com (Jia Jianwei)
Date: Mon, 17 Apr 2006 11:49:19 -0700
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BC1@ssvlexmb2.amd.com>
Message-ID: <00d601c6624f$a2b50ab0$3a4610ac@fortinet.com>


Because my BIOS source is different with LinuxBIOS, so I think just replace
sata_init() in bcm_5785_sata.c should be working. Do not need a
soft_reset.In my BIOS source, I just do it after PCI device enumerate and
resource allocation.

Regards,
Jianwei

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "Jia Jianwei" <JJia at Fortinet.com>; <linuxbios at linuxbios.org>
Sent: Monday, April 17, 2006 11:30 AM
Subject: RE: [LinuxBIOS] broadcom HT1000 SATA PHY initializing


> Good.
>
> Where to call it? Auto stage or called by hardwaremain driver?
>
> Need to be effective after soft_reset?
>
> YH
>
> -----Original Message-----
> From: Jia Jianwei [mailto:JJia at Fortinet.com]
> Sent: Monday, April 17, 2006 11:23 AM
> To: Lu, Yinghai; linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
>
>
> Sata should be working with the following initializing code. (verified
> on
> two boards). Thanks!
>
> Jianwei
>
>
> void HT1000_SATA_init( void )
> {
>         volatile unsigned int *mmio_reg;
>         unsigned int mmio_base,val32;
>         int i;
>
>         pcibios_write_config_byte( 1, HT1000_SATA, 0x70, 0x18);
>         pcibios_write_config_byte( 1, HT1000_SATA, 0x78, 0x04);
>
>         pcibios_read_config_dword (1, HT1000_SATA, 0x24, &mmio_base);
>
>         mmio_base &= 0xfffffffc;
>
>         mmio_reg = (unsigned int *)( mmio_base + 0x10f0 );
>
>         * mmio_reg = 0x40000001;
>
>         mmio_reg = ( unsigned int *)( mmio_base + 0x8c );
>         * mmio_reg = 0x00ff2007;
>         mdelay( 10 );
>         * mmio_reg = 0x78592009;
>         mdelay( 10 );
>         * mmio_reg = 0x00082004;
>         mdelay( 10 );
>         * mmio_reg = 0x00002004;
>         mdelay( 10 );
>
>         for( i = 0; i < 4; i ++ )
>         {
>                 mmio_reg = ( unsigned int *)( mmio_base + 0x40 + i * 256
> );
>                 val32 = *mmio_reg ;
>                 if( val32 & 0x4 )
>                 {
>                         mmio_reg = ( unsigned int *)( mmio_base + 0x48 +
> i *
> 256);
>                         val32 = *mmio_reg;
>                         val32 |= 1;
>                         *mmio_reg = val32;
>                         mdelay( 10 );
>                         val32 &= ( ~1 );
>                         *mmio_reg = val32;
>                         mdelay( 10 );
>                 }
>         }
>
> }
>
>
>
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at amd.com>
> To: "Jia Jianwei" <JJia at Fortinet.com>; <linuxbios at linuxbios.org>
> Sent: Friday, March 31, 2006 11:40 AM
> Subject: RE: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
>
>
> > You should be right.
> >
> > When I was testing that on Broadcom BLAST ref board: STAT and IDE
> > doesn't work.
> >
> > But on another MB (serverworks HT1000 based), IDE is working.
> >
> > Maybe some magic bit in pci conf space need to set by option rom...
> >
> > You could compare the pci conf dump between system bios and
> LinuxBIOS...
> >
> > BTW, Can drop your funny signature in LinuxBIOS?
> >
> > YH
> >
> >
> >
>
>
>
>
>




From yinghai.lu at amd.com  Mon Apr 17 20:59:28 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 17 Apr 2006 11:59:28 -0700
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BC3@ssvlexmb2.amd.com>

I will test that.

Thanks

YH

-----Original Message-----
From: Jia Jianwei [mailto:JJia at Fortinet.com] 
Sent: Monday, April 17, 2006 11:49 AM
To: Lu, Yinghai; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] broadcom HT1000 SATA PHY initializing


Because my BIOS source is different with LinuxBIOS, so I think just
replace
sata_init() in bcm_5785_sata.c should be working. Do not need a
soft_reset.In my BIOS source, I just do it after PCI device enumerate
and
resource allocation.

Regards,
Jianwei

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "Jia Jianwei" <JJia at Fortinet.com>; <linuxbios at linuxbios.org>
Sent: Monday, April 17, 2006 11:30 AM
Subject: RE: [LinuxBIOS] broadcom HT1000 SATA PHY initializing


> Good.
>
> Where to call it? Auto stage or called by hardwaremain driver?
>
> Need to be effective after soft_reset?
>
> YH
>
> -----Original Message-----
> From: Jia Jianwei [mailto:JJia at Fortinet.com]
> Sent: Monday, April 17, 2006 11:23 AM
> To: Lu, Yinghai; linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
>
>
> Sata should be working with the following initializing code. (verified
> on
> two boards). Thanks!
>
> Jianwei
>
>
> void HT1000_SATA_init( void )
> {
>         volatile unsigned int *mmio_reg;
>         unsigned int mmio_base,val32;
>         int i;
>
>         pcibios_write_config_byte( 1, HT1000_SATA, 0x70, 0x18);
>         pcibios_write_config_byte( 1, HT1000_SATA, 0x78, 0x04);
>
>         pcibios_read_config_dword (1, HT1000_SATA, 0x24, &mmio_base);
>
>         mmio_base &= 0xfffffffc;
>
>         mmio_reg = (unsigned int *)( mmio_base + 0x10f0 );
>
>         * mmio_reg = 0x40000001;
>
>         mmio_reg = ( unsigned int *)( mmio_base + 0x8c );
>         * mmio_reg = 0x00ff2007;
>         mdelay( 10 );
>         * mmio_reg = 0x78592009;
>         mdelay( 10 );
>         * mmio_reg = 0x00082004;
>         mdelay( 10 );
>         * mmio_reg = 0x00002004;
>         mdelay( 10 );
>
>         for( i = 0; i < 4; i ++ )
>         {
>                 mmio_reg = ( unsigned int *)( mmio_base + 0x40 + i *
256
> );
>                 val32 = *mmio_reg ;
>                 if( val32 & 0x4 )
>                 {
>                         mmio_reg = ( unsigned int *)( mmio_base + 0x48
+
> i *
> 256);
>                         val32 = *mmio_reg;
>                         val32 |= 1;
>                         *mmio_reg = val32;
>                         mdelay( 10 );
>                         val32 &= ( ~1 );
>                         *mmio_reg = val32;
>                         mdelay( 10 );
>                 }
>         }
>
> }
>
>
>
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at amd.com>
> To: "Jia Jianwei" <JJia at Fortinet.com>; <linuxbios at linuxbios.org>
> Sent: Friday, March 31, 2006 11:40 AM
> Subject: RE: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
>
>
> > You should be right.
> >
> > When I was testing that on Broadcom BLAST ref board: STAT and IDE
> > doesn't work.
> >
> > But on another MB (serverworks HT1000 based), IDE is working.
> >
> > Maybe some magic bit in pci conf space need to set by option rom...
> >
> > You could compare the pci conf dump between system bios and
> LinuxBIOS...
> >
> > BTW, Can drop your funny signature in LinuxBIOS?
> >
> > YH
> >
> >
> >
>
>
>
>
>






From eric at zyxod.com  Tue Apr 18 07:37:26 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Mon, 17 Apr 2006 22:37:26 -0700
Subject: [LinuxBIOS] Via Epia ML5000, LinuxBios, Filo -- 99 % there,
 need help with last 1%!
Message-ID: <44447B16.5010304@zyxod.com>

Hi all,



I've gotten LinuxBIOS working without much of a hitch, but I'm trying to 
get the VGA console working.  I've been looking through the email 
archives without much success, then I found this page:

http://linuxbios.org/index.php/VGA_support

I have a Via Epia ML5000 board.  My question is specific to this part, 
found at the above URL:

/If you want to use the onboard VGA chip, you have to do the following 
in additional to the CONFIG options described above. /

/1. in MB Config.lb You need to specify for your onboard VGA /

/device pci 9.0 on # PCI
/

/        chip drivers/pci/onboard
                device pci 9.0 on end
                register "rom_address" = "0xfff80000" #512k image
                #register "rom_address" = "0xfff00000" #1M image
        end
end/


Is PCI 9.0 the correct value for the Via Epia-M onboard CLE266 video?  
Is there a way to find out, such as lspci?

What about the "rom_address" field -- Can someone explain what this is, 
and how to set it properly?

Thanks

-- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060417/645ac03b/attachment.html>

From pada at chemonline.de  Tue Apr 18 13:20:04 2006
From: pada at chemonline.de (Daniel Parthey)
Date: Tue, 18 Apr 2006 13:20:04 +0200
Subject: [LinuxBIOS] Via Epia ML5000, LinuxBios, Filo -- 99 there,
	need help with last 1 !
In-Reply-To: <44447B16.5010304@zyxod.com>
References: <44447B16.5010304@zyxod.com>
Message-ID: <20060418112003.GA7551@daniel.localdomain>

Eric Poulsen schrieb:
> I'm trying to get the VGA console working.
> I've been looking through the email archives without much success,
> then I found this page:
> 
> http://linuxbios.org/index.php/VGA_support
> 
> I have a Via Epia ML5000 board.

Note that the ML Board is slightly different from the M board and target,
e.g. firewire, cardbus and second raiser card support is missing.

You should prepend an original VGA BIOS from and old VIA M 1.13 BIOS:
http://www.via.com.tw/download/mainboards/1/0/i0100113.bin
You can extract the VGA image from the BIOS image with Award BIOS Editor:
http://awdbedit.sf.net

You might have a look into my pdf document where the setup is described:
http://archiv.tu-chemnitz.de/pub/2006/0066/data/studienarbeit.pdf
Please read section 4.2.1

Also have a look into my patches under ./bios/linuxbios/install/patches/ of
http://archiv.tu-chemnitz.de/pub/2006/0066/data/dateien.tar.gz
Some of the changes you might consider useful for the ML board.

> /1. in MB Config.lb You need to specify for your onboard VGA /
> /device pci 9.0 on # PCI
> /        chip drivers/pci/onboard
>                device pci 9.0 on end
>                register "rom_address" = "0xfff80000" #512k image
>                #register "rom_address" = "0xfff00000" #1M image
>        end
> end/
I did not change anything of this section.

I can confirm that factory VGA is working with LinuxBIOSv2 r2169 on an
EPIA ML-6000EA board. The only remaining problem is that after any
kernel soft "reboot", the screen content is crippled and the machine hangs.
After each hard reset or power cycle the machine starts fine.

HTH,
Daniel.
-- 
Jabber: pada at jabber.ccc.de



From ward at gnu.org  Tue Apr 18 17:19:01 2006
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 18 Apr 2006 11:19:01 -0400
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BBC@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BBC@ssvlexmb2.amd.com>
Message-ID: <20060418151901.GA4517@io.pong.be>

On Fri, Apr 14, 2006 at 04:11:46PM -0700, Lu, Yinghai wrote:
> Without enabling the ACPI, the power off works? 

No; ACPI was enabled in the kernel all along. The ACPI options from the
.config file are below (this is stock 2.6.16.2).

It's just that early last week halt did not actually poweroff the machine
(but halt -p did).

Since last Friday, with the linuxbios checkout from that day, halt does
poweroff the machine. So something must have changed, thanks!

Ward.

-----------------

CONFIG_X86_64_ACPI_NUMA=y

CONFIG_ACPI=y
CONFIG_ACPI_AC=y
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set

CONFIG_PNPACPI=y

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From ward at gnu.org  Tue Apr 18 17:21:43 2006
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 18 Apr 2006 11:21:43 -0400
Subject: [LinuxBIOS] compile problems s2881
In-Reply-To: <20060414233930.GA4418@coresystems.de>
References: <20060414215756.GB26346@io.pong.be>
	<20060414233930.GA4418@coresystems.de>
Message-ID: <20060418152143.GB4517@io.pong.be>

On Sat, Apr 15, 2006 at 01:39:30AM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060414 23:57]:
> > I just checked out a clean s2881 tree (2254), and built it.
> > 
> > Along the way, I had to make a few changes to make it compile.
> > 
> > 1. in targets/tyan/s2881/s2881/config.py, my machine required:
> > - a '#!/usr/bin/env python' line at the start of the file
> > - the file to be executable
> > 
> > 2. compilation then failed as follows:
> > # make
> > ...
> > Traceback (most recent call last):
> >   File "tyan/s2881/s2881/config.py", line 1541, in ?
> >     from yappsrt import *
> > ImportError: No module named yappsrt
> > make: *** [Makefile.settings] Error 1
> > 
> > I had to copy the yappsrt.py file from util/newconfig to the tyan/s2881/s2881
> > directory, and then everything worked fine.
> 
> Sounds like either you have a broken or a brand new or a really old 
> python version.  What python version are you using?

I've tried with Python 2.3.5 on Debian testing/unstable, and Python 2.4.2 on
Ubuntu Breezy. Both exhibit the same problem.

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From stepan at coresystems.de  Wed Apr 19 01:10:07 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 19 Apr 2006 01:10:07 +0200
Subject: [LinuxBIOS] Via Epia ML5000, LinuxBios, Filo -- 99 % there,
	need help with last 1%!
In-Reply-To: <44447B16.5010304@zyxod.com>
References: <44447B16.5010304@zyxod.com>
Message-ID: <20060418231007.GA6825@coresystems.de>

Hi Eric,

> I've gotten LinuxBIOS working without much of a hitch, but I'm trying to get
> the VGA console working.  I've been looking through the email archives without
> much success, then I found this page:

[..] 

> device pci 9.0 on # PCI
 
[..] 
 
> Is PCI 9.0 the correct value for the Via Epia-M onboard CLE266 video?  Is there
> a way to find out, such as lspci?
 
Can you send a LinuxBIOS boot log to the list? So someone with a working Epia
can compare this.

> What about the "rom_address" field -- Can someone explain what this is, and how
> to set it properly?

It's the physical address to the gfx bios image. If you want LinuxBIOS
to initialize VGA, you need to grad this rom image from a legacy bios
and pack it in front of the LinuxBIOS image.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From gjohnson at lanl.gov  Wed Apr 19 19:01:32 2006
From: gjohnson at lanl.gov (Greg Johnson)
Date: Wed, 19 Apr 2006 11:01:32 -0600
Subject: [LinuxBIOS] Tyan s2891 working now
Message-ID: <20060419170132.GE19253@durango.c3.lanl.gov>

The current (r2256) svn seems to be woriking fine for us with the Tyan
s2891 boards.  I think the recent changes to get the s2881 working fixed
it.

Thanks,

Greg



From c-d.hailfinger.devel.2006 at gmx.net  Thu Apr 20 01:34:37 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 20 Apr 2006 01:34:37 +0200
Subject: [LinuxBIOS] Support for AM2 processors?
Message-ID: <4446C90D.6060304@gmx.net>

Hi,

since the upcoming AM2 processors will have a new (DDR2)
memory controller, does that mean the RAM initialization
has to be rewritten completely? If so, is there any expected
time when LinuxBIOS support for these processors will be
available?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From c-d.hailfinger.devel.2006 at gmx.net  Thu Apr 20 01:40:51 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 20 Apr 2006 01:40:51 +0200
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
In-Reply-To: <43CC2992.3090006@coplanar.net>
References: <43CAFDD6.5070904@gmx.net>
	<2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>
	<43CB87E9.7060502@gmx.net> <43CC2992.3090006@coplanar.net>
Message-ID: <4446CA83.6030200@gmx.net>

Jeremy Jackson wrote on 2006-01-17:
> Carl-Daniel Hailfinger wrote:
> 
>> On 2005-08-17, yhlu wrote:
>>  
>>
>>> You need to talk to Tyan to see if they want to release the source
>>> code for s2865 support.
>>>   
>>
>>
>> Did there anything come out of these efforts?
>>  
>>
> There was some activity, but I didn't get an answer.  Perhaps I should
> send another email.

Did Tyan respond to that other mail? I have the impression that half
of the Tyan mainboards available today are unsupported in LinuxBIOS.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From bari at onelabs.com  Thu Apr 20 02:25:48 2006
From: bari at onelabs.com (Bari Ari)
Date: Wed, 19 Apr 2006 19:25:48 -0500
Subject: [LinuxBIOS] Support for AM2 processors?
In-Reply-To: <4446C90D.6060304@gmx.net>
References: <4446C90D.6060304@gmx.net>
Message-ID: <4446D50C.7000708@onelabs.com>

Carl-Daniel Hailfinger wrote:
> since the upcoming AM2 processors will have a new (DDR2)
> memory controller, does that mean the RAM initialization
> has to be rewritten completely? If so, is there any expected
> time when LinuxBIOS support for these processors will be
> available?

Support should be up shortly after AMD releases the processors and the 
docs. Maybe after this : http://theinquirer.net/?article=29682

-Bari



From yinghai.lu at amd.com  Thu Apr 20 02:27:35 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 19 Apr 2006 17:27:35 -0700
Subject: [LinuxBIOS] Support for AM2 processors?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BCD@ssvlexmb2.amd.com>

The support code is done, and will be released to public tree after the
CPU is released to public.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Carl-Daniel
Hailfinger
Sent: Wednesday, April 19, 2006 4:35 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Support for AM2 processors?

Hi,

since the upcoming AM2 processors will have a new (DDR2)
memory controller, does that mean the RAM initialization
has to be rewritten completely? If so, is there any expected
time when LinuxBIOS support for these processors will be
available?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From hawkeyeaz1 at gmail.com  Wed Apr 19 20:16:51 2006
From: hawkeyeaz1 at gmail.com (Justin Hawkeye)
Date: Wed, 19 Apr 2006 15:16:51 -0300
Subject: [LinuxBIOS] Development Utility idea
Message-ID: <f52b80050604191116t1717ebf9m8e5b57649603331a@mail.gmail.com>

Client boots, loads consisting of a tiny Linux Kernel and network driver,
and a script or program [Non-NVRAM setup]
Client listens for predefined broadcast from Emu(server)
When found, Kernel contacts Emu and establishes connection
Emu starts logging all activity
Kernel reads local bios to Emu [Non-NVRAM setup]
Emu executes received bios (emulated), directing all output to Kernel
Kernel directs/passes received output to hardware, directs/passes hardware
results to Emu
Assuming the Kernel does not get overwritten or lose control of system
(crash), we now have a log of all neccesary and expected results of that
bios on boot on that hardware. This would allow reverse engineering bioses
and developing bioses for hardware legally?

                               BIOS
                                   |
                                   v
A) Emu<->network<->Kernel       OR     B) ROM Image->Emu<->network<->Kernel
Bios<->system/devices
                                    ^
                                    |
                                    v
                          system/devices

If the above ascii depiction is off, bios is above kernel is above
system/devices

Also, as in B) Client can be burned to Flash NVRAM, and ROM images can be
fed through Emu to Kernel (Bios)
One possibility for A) is loading Client via PXE/bootp/Network boot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060419/a64f373f/attachment.html>

From stepan at coresystems.de  Thu Apr 20 12:11:31 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 20 Apr 2006 12:11:31 +0200
Subject: [LinuxBIOS] Development Utility idea
In-Reply-To: <f52b80050604191116t1717ebf9m8e5b57649603331a@mail.gmail.com>
References: <f52b80050604191116t1717ebf9m8e5b57649603331a@mail.gmail.com>
Message-ID: <20060420101131.GA4358@coresystems.de>

* Justin Hawkeye <hawkeyeaz1 at gmail.com> [060419 20:16]:
[..]
> Assuming the Kernel does not get overwritten or lose control of system
> (crash), we now have a log of all neccesary and expected results of
> that bios on boot on that hardware. This would allow reverse
> engineering bioses and developing bioses for hardware legally?
 
Problems with this approach:

- compare it to driving a car. at one intersection the car just drives
  on. At another one it stops.
  This way you run into another car in the first intersection and most
  probably (murphy's law) halt without a reason on the second.

- you can never do better than factory bios

- the emulator would have to pass calls to the hardware. qemu, bochs and
  co emulate their own hardware.


Stefan


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Thu Apr 20 15:17:11 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 20 Apr 2006 15:17:11 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
Message-ID: <444789D7.1040403@suehsi.de>

I'm back :D

Ok, I will start to create a new target for LB.

Board with following features.

Cyrix Media GXM CPU up to 300MHz.

NSC CS5530 or Cyrix CX5530 Southbridge
NSC SuperIO PC97137
Cyberpro 500x Video Chipset

Lan (sometimes on board) realtek 8139
DOC Support
PC104 Connector
Sound on board
and so on ...

what do you think is the best target to start?

AMD has sometimes the same features and the same chipsets.

Thanks chris





From rminnich at lanl.gov  Thu Apr 20 16:44:51 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 20 Apr 2006 08:44:51 -0600
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444789D7.1040403@suehsi.de>
References: <444789D7.1040403@suehsi.de>
Message-ID: <44479E63.7040003@lanl.gov>

Christian S?hs wrote:
> I'm back :D
> 
> Ok, I will start to create a new target for LB.
> 
> Board with following features.
> 
> Cyrix Media GXM CPU up to 300MHz.
> 
> NSC CS5530 or Cyrix CX5530 Southbridge
> NSC SuperIO PC97137
> Cyberpro 500x Video Chipset
> 
> Lan (sometimes on board) realtek 8139
> DOC Support
> PC104 Connector
> Sound on board
> and so on ...
> 
> what do you think is the best target to start?
> 
> AMD has sometimes the same features and the same chipsets.
> 
> Thanks chris
> 
> 
> 

I'm not sure what board to use, but this would be nice to have

thanks

ron



From survey at chase.org  Thu Apr 20 17:01:23 2006
From: survey at chase.org (Chase)
Date: Thu, 20 Apr 2006 11:01:23 -0400
Subject: [LinuxBIOS] Get $20 Reward
Message-ID: <CAKIBLSFZRCOBNQYZTVZWL@yahoo.com>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060420/c5073880/attachment.html>

From chris at suehsi.de  Thu Apr 20 19:02:59 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 20 Apr 2006 19:02:59 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <44479E63.7040003@lanl.gov>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>
Message-ID: <4447BEC3.3090003@suehsi.de>


>>Cyrix Media GXM CPU up to 300MHz.
>>
>>NSC CS5530 or Cyrix CX5530 Southbridge
>>NSC SuperIO PC97137
>>Cyberpro 500x Video Chipset
>>
>>Lan (sometimes on board) realtek 8139
>>DOC Support
>>PC104 Connector
>>Sound on board
>>and so on ...
>>
>>what do you think is the best target to start?
>>
>>AMD has sometimes the same features and the same chipsets.
>>
>>Thanks chris
>>
>>
>>
> 
> 
> I'm not sure what board to use, but this would be nice to have
>
Well, I have looked on the source, and it seems that the eaglelion/5bcm 
use the same hardware. Now I will have a try with that settings and see 
what happens :D

More later,

regards chris

> thanks
> 
> ron
> 




From ward at gnu.org  Fri Apr 21 01:11:27 2006
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 20 Apr 2006 19:11:27 -0400
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
Message-ID: <20060420231127.GA27488@io.pong.be>

On Mon, Apr 10, 2006 at 04:00:27PM -0700, Lu, Yinghai wrote:
> 1. need to add acpi support in s2881 LinuxBIOS support to get it.
> Anyway 8111 acpi support is already there in Serengeti_leopard, so it
> will be easy to get that.

So.... if there is no ACPI support yet for this board in LinuxBIOS, does that
mean that there is no automatic fan control in hardware? In other words, that
the CPUs will cook if they get too hot, because the fans won't start blowing
harder automatically?

As a point of interest, somewhere in the process of upgrading this box to
LinuxBIOS, the fans got stuck at maximum speed (which is pretty loud). I'm
not sure where it happened, but in any case booting with the proprietary bios
didn't change a thing - they were still stuck at 17K RPM. 

I've now figured out how to monitor and set fan speed through lm_sensors, but
I want to know if I need to run fancontrold (daemon that keeps an eye on cpu
temperature and adjusts fan speed as necessary) to prevent hardware
overheating?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From smithbone at gmail.com  Fri Apr 21 01:25:29 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 20 Apr 2006 18:25:29 -0500
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <20060420231127.GA27488@io.pong.be>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
	<20060420231127.GA27488@io.pong.be>
Message-ID: <8a0c36780604201625m4424248fn3ce45d8dca138fb4@mail.gmail.com>

On 4/20/06, Ward Vandewege <ward at gnu.org> wrote:
> On Mon, Apr 10, 2006 at 04:00:27PM -0700, Lu, Yinghai wrote:
> > 1. need to add acpi support in s2881 LinuxBIOS support to get it.
> > Anyway 8111 acpi support is already there in Serengeti_leopard, so it
> > will be easy to get that.
>
> So.... if there is no ACPI support yet for this board in LinuxBIOS, does that
> mean that there is no automatic fan control in hardware? In other words, that
> the CPUs will cook if they get too hot, because the fans won't start blowing
> harder automatically?

If they do then the hardware designers failed miserably.  Generally
what I find is that when you first power on the machine the fans come
on full.  Then the bios takes over.
What happens in the case when the power supply is going flaky and
machine glitches on startup and doesn't fully boot?

If you pull the bios chip and then power up the board and the fans
don't come on full then I would find a different manufacturer since
that one is just waiting to cook itself in a crash.

--
Richard A. Smith



From yinghai.lu at amd.com  Fri Apr 21 01:59:52 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 20 Apr 2006 16:59:52 -0700
Subject: [LinuxBIOS] some more tyan/s2881 questions
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>

I have inited the hw sensors in LinuxBIOS for s2881. So you could use
lmsensor to check the FAN speed. The config file is on Tyan web.

For the Fan control, there should more some reg setting...to reduce the
FAN speed winbond and adm1027...

YH





From ward at gnu.org  Fri Apr 21 04:41:58 2006
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 20 Apr 2006 22:41:58 -0400
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
Message-ID: <20060421024158.GA28494@io.pong.be>

On Thu, Apr 20, 2006 at 04:59:52PM -0700, Lu, Yinghai wrote:
> I have inited the hw sensors in LinuxBIOS for s2881. So you could use
> lmsensor to check the FAN speed. The config file is on Tyan web.

Yes; that's what I did today, it works well. I can even set the FAN speed.
Thanks for doing that!

> For the Fan control, there should more some reg setting...to reduce the
> FAN speed winbond and adm1027...

Any idea how hard that will be/how long it will take? So you're saying that
would activate the automatic fan speed control?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From ward at gnu.org  Fri Apr 21 04:56:00 2006
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 20 Apr 2006 22:56:00 -0400
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <8a0c36780604201625m4424248fn3ce45d8dca138fb4@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
	<20060420231127.GA27488@io.pong.be>
	<8a0c36780604201625m4424248fn3ce45d8dca138fb4@mail.gmail.com>
Message-ID: <20060421025600.GA28523@io.pong.be>

On Thu, Apr 20, 2006 at 06:25:29PM -0500, Richard Smith wrote:
> On 4/20/06, Ward Vandewege <ward at gnu.org> wrote:
> > On Mon, Apr 10, 2006 at 04:00:27PM -0700, Lu, Yinghai wrote:
> > > 1. need to add acpi support in s2881 LinuxBIOS support to get it.
> > > Anyway 8111 acpi support is already there in Serengeti_leopard, so it
> > > will be easy to get that.
> >
> > So.... if there is no ACPI support yet for this board in LinuxBIOS, does that
> > mean that there is no automatic fan control in hardware? In other words, that
> > the CPUs will cook if they get too hot, because the fans won't start blowing
> > harder automatically?
> 
> If they do then the hardware designers failed miserably.  Generally
> what I find is that when you first power on the machine the fans come
> on full.  Then the bios takes over.
> What happens in the case when the power supply is going flaky and
> machine glitches on startup and doesn't fully boot?
> 
> If you pull the bios chip and then power up the board and the fans
> don't come on full then I would find a different manufacturer since
> that one is just waiting to cook itself in a crash.

So far I'm really happy with Tyan and this board in particular. I'll see if I
can try that tomorrow. I'd be surprised if the fans don't do the right thing.

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From smithbone at gmail.com  Fri Apr 21 05:06:00 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 20 Apr 2006 22:06:00 -0500
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <20060421025600.GA28523@io.pong.be>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
	<20060420231127.GA27488@io.pong.be>
	<8a0c36780604201625m4424248fn3ce45d8dca138fb4@mail.gmail.com>
	<20060421025600.GA28523@io.pong.be>
Message-ID: <8a0c36780604202006q5013ab6ct35dfe0c8ccd68bbc@mail.gmail.com>

>
> So far I'm really happy with Tyan and this board in particular. I'll see if I
> can try that tomorrow. I'd be surprised if the fans don't do the right thing.

I'm sure they will.  Tyan is good stuff.

One thing many years of embedded developement has taught me is that if
all your safeguards are software then its not a matter of "if" but
"when" for system failure in a some catastrophic method.

If it were not for watchdog timers I'm sure 990% of the embedded
systems we rely on would stop on a regular basis.

--
Richard A. Smith



From smithbone at gmail.com  Fri Apr 21 05:11:22 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 20 Apr 2006 22:11:22 -0500
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <8a0c36780604202006q5013ab6ct35dfe0c8ccd68bbc@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
	<20060420231127.GA27488@io.pong.be>
	<8a0c36780604201625m4424248fn3ce45d8dca138fb4@mail.gmail.com>
	<20060421025600.GA28523@io.pong.be>
	<8a0c36780604202006q5013ab6ct35dfe0c8ccd68bbc@mail.gmail.com>
Message-ID: <8a0c36780604202011j5a5fa70fh1b24f8ec8b388756@mail.gmail.com>

> If it were not for watchdog timers I'm sure 990% of the embedded

r/990/90

--
Richard A. Smith



From eric at zyxod.com  Fri Apr 21 05:57:06 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 20 Apr 2006 20:57:06 -0700
Subject: [LinuxBIOS] Epia ML 5000 progress (sort of)
Message-ID: <44485812.8070409@zyxod.com>

I finally got myself a serial cable, but there's a BIG gotcha.  My whole 
plan was to have a data logging device that boots very quickly.  Hence, 
my use of LinuxBIOS.  Here's the gotcha: There's an EIGHT SECOND delay 
from power on (or reset switch) until the time LinuxBIOS sends anything 
to the serial port.  Anyone have any ideas about this one? FWIW, the 
stock BIOS shows a logo within 3 seconds of power on.

Here's the relevant section of the LinuxBIOS output regarding VGA, which 
is what I wanted to get working.  I'm thinking "Oops, Exception 6" might 
be a problem, as well as the "Bailing out" message.

I'm pretty sure my VGA Bios is okay: 1) The image file begins with AA55 
(or 55AA, whatever it is) 2) X.org starts okay, which uses the BIOS, 
AFAIK; when I had a BAD Bios, X wouldn't start.  3) LinuxBIOS actually 
finds the AA55 sig, or else it wouldn't print what you see below.

Anyone have any thoughts on the VGA?

Thanks

--Eric

------------------------------------------------------
found VGA: vid=1106, did=3122
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0x100
biosint: INT# 0x6
biosint: eax 0x5f00 ebx 0x18538 ecx 0x17fa0 edx 0xa
biosint: ebp 0x17f70 esp 0xfec edi 0xecf0 esi 0x18538
biosint:  ip 0xf85e   cs 0xf000  flags 0x86
biosint: Oops, exception 6
Stack contents: 0xf85e 0xf000 0x0086 0x6a1f 0xc000 0x0046 0x7fa0 0x89b5 
0xb155 0x0000
biosint: Bailing out
biosint: INT# 0x10
biosint: eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0
biosint: ebp 0x17fa0 esp 0xffa edi 0x0 esi 0x18538
biosint:  ip 0xafd9   cs 0x0  flags 0x46
BIOSINT: Unsupport int #0x10
------------------------------------------------------

Full output of LinuxBIOS:

0

LinuxBIOS-1.1.8.0Fallback Thu Apr 20 17:57:10 PDT 2006 starting...
 Enabling mainboard devices
 Enabling shadow ram
vt8623 init starting
Detecting Memory
Number of Banks 04
Number of Rows 0d
Priamry DRAM width08
No Columns 0a
MA type e0
Bank 0 (*16 Mb) 10
No Physical Banks 01
Total Memory (*16 Mb) 10
CAS Supported 2 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)75
Starting at CAS 3
We can do CAS 2.5
We can do CAS 2
tRP 48
tRCD 48
tRAS 28
Low Bond 00  High Bondbc  Setting DQS delay7dvt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00
50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00
60:02 ff 00 30 d6 32 01 2a 42 2d 43 58 00 44 00 00
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 02
80:0f 65 00 00 80 00 00 00 02 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00
b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00
AGP
 Doing MTRR init.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Thu Apr 20 17:58:10 PDT 2006 booting...
clocks_per_usec: 838
Enumerating buses...
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123] enabled
PCI: 00:01.0 [1106/b091] enabled
Disabling static device: PCI: 00:0a.0
Disabling static device: PCI: 00:0a.1
In vt8235_enable 1106 3038.
PCI: 00:10.0 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 3104.
PCI: 00:10.3 [1106/3104] enabled
In vt8235_enable 1106 3177.
Initialising Devices
PCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106 0571.
PCI: 00:11.1 [1106/0571] enabled
In vt8235_enable 1106 3059.
PCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122] enabled
PCI: pci_scan_bus returning with max=01
vt1211 enabling PNP devices.
PNP: 002e.0 enabled
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
vt1211 enabling PNP devices.
PNP: 002e.b enabled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resources...
I would set ram size to 0x40000 Kbytes
PCI: 00:10.0 20 <- [0x0000001800 - 0x000000181f] io
PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f] io
PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io
PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff] mem
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 140
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <- 141
PCI: 00:10.1 subsystem <- 00/00
PCI: 00:10.1 cmd <- 141
PCI: 00:10.2 subsystem <- 00/00
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.0 - enabling
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PCI: 00:11.1 cmd <- 147
PCI: 00:11.5 subsystem <- 00/00
PCI: 00:11.5 cmd <- 141
PCI: 00:12.0 cmd <- 1c3
done.
Initializing devices...
Root Device init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
Invalid CMOS LB checksum
pci_routing_fixup: dev is 00010fa0
setting firewire
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.2
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
setting cardbus slot
setting riser slot
PNP: 002e.0 init
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 init
PCI: 00:12.0 init
Configuring VIA Rhine LAN
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Centaur device 673
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000
PCI: 00:01.0 init
VT8623 AGP random fixup ...
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0x100
biosint: INT# 0x6
biosint: eax 0x5f00 ebx 0x18538 ecx 0x17fa0 edx 0xa
biosint: ebp 0x17f70 esp 0xfec edi 0xecf0 esi 0x18538
biosint:  ip 0xf85e   cs 0xf000  flags 0x86
biosint: Oops, exception 6
Stack contents: 0xf85e 0xf000 0x0086 0x6a1f 0xc000 0x0046 0x7fa0 0x89b5 
0xb155 0x0000
biosint: Bailing out
biosint: INT# 0x10
biosint: eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0
biosint: ebp 0x17fa0 esp 0xffa edi 0x0 esi 0x18538
biosint:  ip 0xafd9   cs 0x0  flags 0x46
BIOSINT: Unsupport int #0x10
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
done.
ACPI: Writing ACPI tables at f0400...
ACPI:     * FACS
ACPI:     * DSDT @ 000f049e Length 3f0
ACPI:     * FADT
ACPI: added table 1/5 Length now 40
ACPI: done.
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000b80  checksum d885

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x23760 offset 0xc0 filesize 0x96e8
(cleaned up) New segment addr 0x100000 size 0x23760 offset 0xc0 filesize 
0x96e8
New segment addr 0x123760 size 0x48 offset 0x97c0 filesize 0x48
(cleaned up) New segment addr 0x123760 size 0x48 offset 0x97c0 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000023760 
filesz: 0x00000000000096e8
Clearing Segment: addr: 0x00000000001096e8 memsz: 0x000000000001a078
Loading Segment: addr: 0x0000000000123760 memsz: 0x0000000000000048 
filesz: 0x0000000000000048
Jumping to boot code at 0x107860
FILO version 0.4.2 (root at embedded) Thu Apr 20 16:57:23 PDT 2006
boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200
hda: LBA 80GB: WDC WD800JB-00FMA0                     
Mounted ext2fs
Found Linux version 2.6.12-10-386 (buildd at rothera) #1 Mon Jan 16 
17:18:08 UTC 2006 bzImage.
Loading kernel... ok
Jumping to entry point...
[4294667.296000] Linux version 2.6.12-10-386 (buildd at rothera) (gcc 
version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 Mon Jan 
16 17:18:08 UTC 2006
[4294667.296000] BIOS-provided physical RAM map:
[4294667.296000]  BIOS-e820: 0000000000000be0 - 00000000000a0000 (usable)
[4294667.296000]  BIOS-e820: 0000000000100000 - 000000000e000000 (usable)
[4294667.296000] 0MB HIGHMEM available.
[4294667.296000] 224MB LOWMEM available.
[4294667.296000] DMI not present.
[4294667.296000] ACPI: PM-Timer IO Port: 0x408
[4294667.296000] Allocating PCI resources starting at 0e000000 (gap: 
0e000000:f2000000)
[4294667.296000] Built 1 zonelists
[4294667.296000] Kernel command line: root=/dev/hda1 console=tty0 
console=ttyS0,115200
[4294667.296000] No local APIC present or hardware disabled
[4294667.296000] Initializing CPU#0
[4294667.296000] PID hash table entries: 1024 (order: 10, 16384 bytes)
[4294667.296000] Detected 533.331 MHz processor.
[4294667.296000] Using pmtmr for high-res timesource
[4294667.296000] Console: colour dummy device 80x25
[4294667.508000] Dentry cache hash table entries: 32768 (order: 5, 
131072 bytes)
[4294667.518000] Inode-cache hash table entries: 16384 (order: 4, 65536 
bytes)
[4294667.579000] Memory: 224044k/229376k available (1416k kernel code, 
4888k reserved, 762k data, 224k init, 0k highmem)
[4294667.590000] Checking if this processor honours the WP bit even in 
supervisor mode... Ok.
[4294667.625000] Security Framework v1.0.0 initialized
[4294667.630000] SELinux:  Disabled at boot.
[4294667.635000] Mount-cache hash table entries: 512
[4294667.640000] CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 
bytes/line)
[4294667.649000] CPU: L2 Cache: 64K (32 bytes/line)
[4294667.654000] CPU: Centaur VIA Samuel 2 stepping 03
[4294667.660000] Checking 'hlt' instruction... OK.
[4294667.669000] Checking for popad bug... OK.
[4294667.730000]  not found!
[4294667.735000] ACPI: setting ELCR to 0020 (from 0220)
[4294667.742000] NET: Registered protocol family 16
[4294667.748000] EISA bus registered
[4294667.752000] ACPI: bus type pci registered
[4294667.810000] PCI: Using configuration type 1
[4294667.815000] mtrr: v2.0 (20020519)
[4294667.821000] ACPI: Subsystem revision 20050729
[4294667.885000] ACPI: Interpreter enabled
[4294667.890000] ACPI: Using PIC for interrupt routing
[4294667.897000] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 9 10)
[4294667.904000] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *9 10)
[4294667.911000] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *9 10)
[4294667.918000] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 9 10)
[4294667.925000] ACPI: PCI Root Bridge [PCI0] (0000:00)
[4294667.931000] PCI: Probing PCI hardware (bus 00)
[4294667.937000] ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
[4294667.948000] Linux Plug and Play Support v0.97 (c) Adam Belay
[4294667.955000] pnp: PnP ACPI init
[4294667.959000] pnp: PnP ACPI: found 0 devices
[4294667.964000] PnPBIOS: Disabled by ACPI PNP
[4294667.969000] PCI: Using ACPI for IRQ routing
[4294667.974000] PCI: If a device doesn't work, try "pci=routeirq".  If 
it helps, post a report
[4294667.986000] audit: initializing netlink socket (disabled)
[4294667.993000] audit: initialized
[4294667.997000] VFS: Disk quotas dquot_6.5.1
[4294668.002000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[4294668.010000] devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au)
[4294668.018000] devfs: boot_options: 0x0
[4294668.022000] Initializing Cryptographic API
[4294668.028000] isapnp: Scanning for PnP cards...
[4294668.387000] isapnp: No Plug & Play device found
[4294668.483000] PNP: No PS/2 controller found. Probing ports directly.
[4294668.490000] serio: i8042 AUX port at 0x60,0x64 irq 12
[4294668.497000] serio: i8042 KBD port at 0x60,0x64 irq 1
[4294668.503000] Serial: 8250/16550 driver $Revision: 1.90 $ 54 ports, 
IRQ sharing enabled
[4294668.513000] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[4294668.519000] ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[4294668.533000] io scheduler noop registered
[4294668.538000] io scheduler anticipatory registered
[4294668.544000] io scheduler deadline registered
[4294668.549000] io scheduler cfq registered
[4294668.556000] RAMDISK driver initialized: 16 RAM disks of 65536K size 
1024 blocksize
[4294668.565000] EISA: Probing bus 0 at eisa.0
[4294668.570000] Cannot allocate resource for EISA slot 1
[4294668.577000] EISA: Detected 0 cards.
[4294668.581000] NET: Registered protocol family 2
[4294668.596000] IP: routing cache hash table of 2048 buckets, 16Kbytes
[4294668.604000] TCP established hash table entries: 8192 (order: 4, 
65536 bytes)
[4294668.613000] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[4294668.621000] TCP: Hash tables configured (established 8192 bind 8192)
[4294668.629000] NET: Registered protocol family 8
[4294668.635000] NET: Registered protocol family 20
[4294668.640000] ACPI wakeup devices:
[4294668.645000]
[4294668.646000] ACPI: (supports S0 S5)
[4294668.655000] VFS: Cannot open root device "hda1" or unknown-block(0,0)
[4294668.663000] Please append a correct "root=" boot option

Don't worry about this part ... Kernel issues I can fix =)

[4294668.669000] Kernel panic - not syncing: VFS: Unable to mount root 
fs on unknown-block(0,0)
[4294668.679000] 




From rminnich at lanl.gov  Fri Apr 21 05:59:44 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 20 Apr 2006 21:59:44 -0600
Subject: [LinuxBIOS] Epia ML 5000 progress (sort of)
In-Reply-To: <44485812.8070409@zyxod.com>
References: <44485812.8070409@zyxod.com>
Message-ID: <444858B0.5090309@lanl.gov>

Eric Poulsen wrote:

> 
> Here's the relevant section of the LinuxBIOS output regarding VGA, which 
> is what I wanted to get working.  I'm thinking "Oops, Exception 6" might 
> be a problem, as well as the "Bailing out" message.
> 

well, that's bad.

Can you try booting without vga to start, and run vga under the testbios 
emulator (see util/testbios) and let us know if that works?

thanks

ron



From smithbone at gmail.com  Fri Apr 21 06:16:16 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 20 Apr 2006 23:16:16 -0500
Subject: [LinuxBIOS] Epia ML 5000 progress (sort of)
In-Reply-To: <44485812.8070409@zyxod.com>
References: <44485812.8070409@zyxod.com>
Message-ID: <8a0c36780604202116h47313291o7f31c532d26355ff@mail.gmail.com>

> my use of LinuxBIOS.  Here's the gotcha: There's an EIGHT SECOND delay
> from power on (or reset switch) until the time LinuxBIOS sends anything
> to the serial port.  Anyone have any ideas about this one?

Yep.  I do. I'm pretty sure its the scan for the firewire device. 
Heres the  snip from a past thread on this.

=====================
Ok, first I have commented out enable_smbus(), for that there are
unreadable characters at the console and it takes the same time --> the
false way

Then I recognized the lines above in auto.c, which disable the Firewire
stuff, but The Epia-ML does not have Firewire, ok it is the same chipset
and the firewire is integrated in the chip, but voila it works.

I have commented out line 119-123 and all works fine on high speed :D
Is there a better way?
======================

Whats happening is that the PCI code does a complete PCI space lookup
looking for the firewire bridge which is not there.  Apparently thats
about 8 seconds.
So comment out the search for the firewire bridge in auto.c and retry.

I'm going to go a head and setup a new directory for the EPIA ML so we
can fix this properly.

Dunno about your VGA issues.  I seem to remember that there was only 1
version of the vbios that actually worked.  Check the archives.

--
Richard A. Smith



From smithbone at gmail.com  Fri Apr 21 06:20:48 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 20 Apr 2006 23:20:48 -0500
Subject: [LinuxBIOS] Epia ML 5000 progress (sort of)
In-Reply-To: <444858B0.5090309@lanl.gov>
References: <44485812.8070409@zyxod.com> <444858B0.5090309@lanl.gov>
Message-ID: <8a0c36780604202120l61c31206je3d573ddaa78f41d@mail.gmail.com>

>
> well, that's bad.
>
> Can you try booting without vga to start, and run vga under the testbios
> emulator (see util/testbios) and let us know if that works?
>

I don't think that will help much.  The via video bios is known not to
work under the emulator. [Issue54] That's why the via code does the
drop back to 16-bit trick and runs the vbios natively.


--
Richard A. Smith



From chris at suehsi.de  Fri Apr 21 11:26:32 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 21 Apr 2006 11:26:32 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <4447BEC3.3090003@suehsi.de>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>
	<4447BEC3.3090003@suehsi.de>
Message-ID: <4448A548.30106@suehsi.de>


> 
> Well, I have looked on the source, and it seems that the eaglelion/5bcm 
> use the same hardware. Now I will have a try with that settings and see 
> what happens :D
> 

First test with same settings as for eaglelion/5bcm

It seems that LB boots nearly correct, but after the bootloader calls 
filo the Board stops any output.
Filo produce no output, too.
I'm not sure, but filo tries to bring up the vga console and fails.
Or is there any other reason why filo could fail?

What does filo first?

Also the serial output says, that LB fails to copy the IRQ Table. I 
think that is not good :D and could be the main reason. Because of the 
IRQs for IDE.

Any Hints?

Here are the results ;) (attachment)


thanks chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stb3036-1.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060421/7f4f0fa4/attachment.ksh>

From chris at suehsi.de  Fri Apr 21 15:27:14 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 21 Apr 2006 15:27:14 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <4448A548.30106@suehsi.de>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>
	<4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
Message-ID: <4448DDB2.7060801@suehsi.de>


> PCI: 00:13.0 init
> Devices initialized
> Copying IRQ routing tables to 0xf0000...done.
> Verifing copy of IRQ routing tables at 0xf0000...failed

What could be a reason for that?

> Moving GDT to 0x500...ok
> Wrote linuxbios table at: 00000530 - 000006c4  checksum a262
> 
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.

...

> Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000023d00 filesz: 0x0000000000009c68
> Clearing Segment: addr: 0x0000000000109c68 memsz: 0x000000000001a098
> Loading Segment: addr: 0x0000000000123d00 memsz: 0x0000000000000048 filesz: 0x0000000000000048
> Jumping to boot code at 0x1078c4

Filo tries first to init vga and serial, disabling vga makes no 
different, it fails too.

Serial needs an IRQ, right?

Is there any callback from filo to LB?
Needs filo the LB Irq Table on 0xf0000 to initialise?

chris



From stepan at coresystems.de  Fri Apr 21 14:38:11 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 21 Apr 2006 14:38:11 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <4448DDB2.7060801@suehsi.de>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>
	<4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de>
Message-ID: <20060421123811.GA27096@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060421 15:27]:
> 
> > PCI: 00:13.0 init
> > Devices initialized
> > Copying IRQ routing tables to 0xf0000...done.
> > Verifing copy of IRQ routing tables at 0xf0000...failed
> 
> What could be a reason for that?

CONFIG_COMPRESS is enabled. PIRQ tables are obsolete when you use ACPI,
so if possible, go ACPI.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From sleff1970 at yahoo.com  Fri Apr 21 16:12:07 2006
From: sleff1970 at yahoo.com (Scott Leffel)
Date: Fri, 21 Apr 2006 07:12:07 -0700 (PDT)
Subject: [LinuxBIOS] Old Tyan "Tsunami" S1846 board?
Message-ID: <20060421141207.1523.qmail@web37006.mail.mud.yahoo.com>

I realize that the S1846 is quite an "antique" and it would seem support for it was dropped during the LinuxBIOS 2.0 development phase.  Code support seems to be in "FreeBIOS Devel. v1.0 Base0.tar.bz2" which I have archived; I can see from old lanl.gov mailing list archives I googled where Ron Minnich merged hcyun's changes into the source tree on 28 Sept. 2001 (yes, that how ancient this is!).

What's unclear to me is what version of the kernel source code might have ever worked with FreeBIOS when it supported the S1846 there for awhile under v1.0.  I know the 2Mbit flash is too small for a kernel (that same message thread was in relation to an Etherboot payload originally), but I know a matching kernel source will be important nonetheless.  Could I probably get away with trying 2.2.19 or 2.4.10, since they are dated closest to the time S1846 was merged into FreeBIOS v1.0 back in Sept. 2001?  Or does anyone here (perhaps Yinghai Lu, who seems to have an excellent memory for all the Tyan board matters!) remember what kernel source version would have worked?

I've scoured all our spare & decomissioned systems here, trying to find something more modern that's been on the supported list at some point, but unfortunately this board seems to be all we've got.  I'd like to be able to lab this out, which might convince folks to buy some newer Tyan's for this purpose, but for now I'd greatly appreciate anything the community can render in terms of advice.


		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1&cent;/min.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060421/f146b643/attachment.html>

From stuge-linuxbios at cdy.org  Fri Apr 21 17:01:23 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 21 Apr 2006 17:01:23 +0200
Subject: [LinuxBIOS] Epia ML 5000 progress (sort of)
In-Reply-To: <44485812.8070409@zyxod.com>
References: <44485812.8070409@zyxod.com>
Message-ID: <20060421150124.15196.qmail@cdy.org>

On Thu, Apr 20, 2006 at 08:57:06PM -0700, Eric Poulsen wrote:
> bus/devfn = 0x100
> biosint: INT# 0x6
> biosint: eax 0x5f00 ebx 0x18538 ecx 0x17fa0 edx 0xa
> biosint: ebp 0x17f70 esp 0xfec edi 0xecf0 esi 0x18538
> biosint:  ip 0xf85e   cs 0xf000  flags 0x86
> biosint: Oops, exception 6
> Stack contents: 0xf85e 0xf000 0x0086 0x6a1f 0xc000 0x0046 0x7fa0 0x89b5 
> 0xb155 0x0000
> biosint: Bailing out

Unsupported instruction.. What 16 bytes are at f000:f85e?


> biosint: INT# 0x10
> biosint: eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0
> biosint: ebp 0x17fa0 esp 0xffa edi 0x0 esi 0x18538
> biosint:  ip 0xafd9   cs 0x0  flags 0x46
> BIOSINT: Unsupport int #0x10

VBE OEM interface, bl=function. Side-effect of the above?


//Peter



From chris at suehsi.de  Fri Apr 21 18:47:41 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 21 Apr 2006 18:47:41 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <20060421123811.GA27096@coresystems.de>
References: <444789D7.1040403@suehsi.de>
	<44479E63.7040003@lanl.gov>	<4447BEC3.3090003@suehsi.de>
	<4448A548.30106@suehsi.de>	<4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>
Message-ID: <44490CAD.5020009@suehsi.de>

Stefan Reinauer schrieb:
> * Christian S?hs <chris at suehsi.de> [060421 15:27]:
> 
>>>PCI: 00:13.0 init
>>>Devices initialized
>>>Copying IRQ routing tables to 0xf0000...done.
>>>Verifing copy of IRQ routing tables at 0xf0000...failed
>>
>>What could be a reason for that?
> 
> 
> CONFIG_COMPRESS is enabled. PIRQ tables are obsolete when you use ACPI,
> so if possible, go ACPI.
> 
Jup ;)

but now it works :D
I don't know, what I have made wrong or what I have changed. It seems 
that false filo settings have made the trouble.

However, the board starts with eaglelion/5bcm target.

Ok, now I need the best way to get vga working. Any ideas?
There is a Cyberpro 5000 on the board, normaly the vgabios is included 
in the factory bios. I think the chip is on the pci bus.
Could I try the emulator to load the vgabios?

chris






From smithbone at gmail.com  Fri Apr 21 17:38:50 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 10:38:50 -0500
Subject: [LinuxBIOS] Epia ML 5000 progress (sort of)
In-Reply-To: <4448FA8D.2070303@zyxod.com>
References: <44485812.8070409@zyxod.com>
	<8a0c36780604202116h47313291o7f31c532d26355ff@mail.gmail.com>
	<4448FA8D.2070303@zyxod.com>
Message-ID: <8a0c36780604210838n28f302der53a1772ae88a6a59@mail.gmail.com>

> >
> No problem.  One question: All of this occurs BEFORE LinuxBIOS prints
> anything?
>

Thats correct.   According the the comments in auto.c if the firewire
device is enabled it stomps on legacy IO.  So you have to disable it
prior to serial port activity.

--
Richard A. Smith



From smithbone at gmail.com  Fri Apr 21 17:45:20 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 10:45:20 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <44490CAD.5020009@suehsi.de>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>
	<4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de> <20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
Message-ID: <8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>

>
> Ok, now I need the best way to get vga working. Any ideas?
> There is a Cyberpro 5000 on the board, normaly the vgabios is included
> in the factory bios. I think the chip is on the pci bus.
> Could I try the emulator to load the vgabios?

Get linux up and get a serial console going.  Then lspci (or do this
from fuctory bios) to see what vga chip you have and where it is.  If
you don't have a copy of the vga binary then you will either need to
rip it out of the fuctory bios image or boot under fuctory and then
copy it from memory.   The wiki has info on doing this.

Then you can test the bios on the target under the emulator.  If it
works then you can add the bios into your Linuxbios image and set the
rom address accordingly so the emulator will run it on boot.

If it dosen't work.... Well then you get to debug it...*grin*

--
Richard A. Smith



From smithbone at gmail.com  Fri Apr 21 18:05:48 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 11:05:48 -0500
Subject: [LinuxBIOS] Adding a config option
Message-ID: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>

I'ts been awhile since I've messed with the config system and having
some difficulity adding a new config option.

I have modified the epia-m auto.c to have a ifdef wrapper around the
section that disables the firewire bridge.   I called it
DISABLE_FIREWIRE.  I added uses DISABLE_FIREWIRE to the Options.lb and
setup a defaut.

I then created a new target called epia-ml that just uses the epia-m
mainboard but would disable the firewire disable section.

But when I run buildtarget I still get:

build_dir=via/epia-ml/epia-ml
Configuring TARGET epia-ml
Will place Makefile, crt0.S, etc. in via/epia-ml/epia-ml
===> ERROR: Can't use undefined option DISABLE_FIREWIRE
via/epia-ml/Config.lb:0
src/mainboard/via/epia-m/Options.lb:0

Where else do I  have to add my new config option so the buld system
knwos about it?

--
Richard A. Smith



From rminnich at lanl.gov  Fri Apr 21 18:05:55 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 21 Apr 2006 10:05:55 -0600
Subject: [LinuxBIOS] Epia ML 5000 progress (sort of)
In-Reply-To: <8a0c36780604202120l61c31206je3d573ddaa78f41d@mail.gmail.com>
References: <44485812.8070409@zyxod.com> <444858B0.5090309@lanl.gov>
	<8a0c36780604202120l61c31206je3d573ddaa78f41d@mail.gmail.com>
Message-ID: <444902E3.1080009@lanl.gov>

Richard Smith wrote:
>>well, that's bad.
>>
>>Can you try booting without vga to start, and run vga under the testbios
>>emulator (see util/testbios) and let us know if that works?
>>
> 
> 
> I don't think that will help much.  The via video bios is known not to
> work under the emulator. [Issue54] That's why the via code does the
> drop back to 16-bit trick and runs the vbios natively.

Sorry,  I forgot about that.

Ollie and I are off to taiwan to work on OLPC. I'll try to look at this 
when we get back.

thanks

ron



From stepan at coresystems.de  Fri Apr 21 18:26:23 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 21 Apr 2006 18:26:23 +0200
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
Message-ID: <20060421162623.GB10690@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060421 18:05]:
> I have modified the epia-m auto.c to have a ifdef wrapper around the
> section that disables the firewire bridge.   I called it
> DISABLE_FIREWIRE.  I added uses DISABLE_FIREWIRE to the Options.lb and
> setup a defaut.

you need to add the option in src/config/Options.lb as well.

> I then created a new target called epia-ml that just uses the epia-m
> mainboard but would disable the firewire disable section.

Another idea:
        /*
         * Disable the firewire stuff, which apparently steps on IO 0+
         * on
         * reset. Doh!
         */
        dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
                                PCI_DEVICE_ID_VIA_6305), 0);
        if (dev != PCI_DEV_INVALID) {
                pci_write_config8(dev, 0x15, 0x1c);
        }

This is the problematic code, especially pci_locate_device.

I would guess this is messing up boot times on all systems that it 
is running on without finding a device.

Idea: We should add a maximum bus number to it, so we can look for the
device on bus0 only for example, or on the first 10 busses, if we know
its an epia that will never have an onboard device with a bus number
higher than that. Searching 256 busses takes a while, no doubt. And its
not a smart thing to do at this place either.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Fri Apr 21 18:34:05 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 11:34:05 -0500
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <20060421162623.GB10690@coresystems.de>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<20060421162623.GB10690@coresystems.de>
Message-ID: <8a0c36780604210934t52b22ebas4d1409d6d5ecc8e9@mail.gmail.com>

>
> you need to add the option in src/config/Options.lb as well.
>

Ah thats it. I knew there was another place.

> Idea: We should add a maximum bus number to it, so we can look for the
> device on bus0 only for example, or on the first 10 busses, if we know
> its an epia that will never have an onboard device with a bus number
> higher than that. Searching 256 busses takes a while, no doubt. And its
> not a smart thing to do at this place either.

Excellent Idea.  Much better than more #if's.  So OPTION_PCI_MAX_BUS?
and then fixup the search routine to never look beyond that.  The
default could be 5 or so which is sane for 99% of the setups.

--
Richard A. Smith



From chris at suehsi.de  Fri Apr 21 20:01:03 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 21 Apr 2006 20:01:03 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
References: <444789D7.1040403@suehsi.de>
	<44479E63.7040003@lanl.gov>	<4447BEC3.3090003@suehsi.de>
	<4448A548.30106@suehsi.de>	<4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
Message-ID: <44491DDF.4080703@suehsi.de>


> Get linux up and get a serial console going.  Then lspci (or do this
> from fuctory bios) to see what vga chip you have and where it is.  If

Ok cat /proc/pci

gives an Intergraphics Cyberpro 5000 rev.2 on BUS 0, Device 9
That should be PCI.

> you don't have a copy of the vga binary then you will either need to
> rip it out of the fuctory bios image or boot under fuctory and then
> copy it from memory.   The wiki has info on doing this.

Of course, I have ripped the fuctory bios, yesterday :D

> 
> Then you can test the bios on the target under the emulator.  If it

Mmmmmh, the test program under utils/x86emu?
I can't compile this :(

to few arguments in pci_write() bla, blub

or an other program?


> works then you can add the bios into your Linuxbios image and set the
> rom address accordingly so the emulator will run it on boot.
> 
> If it dosen't work.... Well then you get to debug it...*grin*

It will work :D

chris
> 
> --
> Richard A. Smith
> 




From smithbone at gmail.com  Fri Apr 21 18:50:26 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 11:50:26 -0500
Subject: [LinuxBIOS] Old Tyan "Tsunami" S1846 board?
In-Reply-To: <20060421141207.1523.qmail@web37006.mail.mud.yahoo.com>
References: <20060421141207.1523.qmail@web37006.mail.mud.yahoo.com>
Message-ID: <8a0c36780604210950n2b713d22ge98d23511a113718@mail.gmail.com>

On 4/21/06, Scott Leffel <sleff1970 at yahoo.com> wrote:

> What's unclear to me is what version of the kernel source code might have
> ever worked with FreeBIOS when it supported the S1846 there for awhile under
> v1.0.

Thats a 440bx based board.  So the V1 Bitworks/IMS mainboard code
should work if you fixup the superIO.

I've booted lots of different kernels starting from 2.4.3 or so up to
2.6.10 on the IMS board so I think if you just pick the latest and try
you should not have any problems.

> I've scoured all our spare & decomissioned systems here, trying to find
> something more modern that's been on the supported list at some point, but
> unfortunately this board seems to be all we've got.  I'd like to be able to
> lab this out, which might convince folks to buy some newer Tyan's for this
> purpose, but for now I'd greatly appreciate anything the community can
> render in terms of advice.

Good timing.  Just last night I pulled in my V2 440bx framework
patches into the latest SVN  and began work on trying to make an Asus
P2B work (Another 440bx board)

Currently I have the Asus up and spitting data out the serial port.

The V2 440bx stuff has a problem that I'm doing something wrong in the
SPD read from the memory.  It always returns 0xff.

The Asus is further complicated in that it has a something different
with the spd bus that has to be enabled.   The V1 440bx code does not
work with the Asus P2B.

If you are interested in helping me work out the problems with the V2
440bx SPD read then let me know and I'll commit my 440bx V2 framework.

--
Richard A. Smith



From smithbone at gmail.com  Fri Apr 21 18:52:54 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 11:52:54 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <44491DDF.4080703@suehsi.de>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>
	<4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de> <20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de>
Message-ID: <8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>

> > Then you can test the bios on the target under the emulator.  If it
>
> Mmmmmh, the test program under utils/x86emu?
> I can't compile this :(
>
> to few arguments in pci_write() bla, blub
> or an other program?

Do you have the pci-utils dev sutff installed?

I just pulled a fresh copy last night.  I'll see if I can build it.

--
Richard A. Smith



From smithbone at gmail.com  Fri Apr 21 18:56:23 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 11:56:23 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>
	<4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de> <20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de>
	<8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>
Message-ID: <8a0c36780604210956t53b70d51j43afd7fca78d0895@mail.gmail.com>

>
> Do you have the pci-utils dev sutff installed?
>
> I just pulled a fresh copy last night.  I'll see if I can build it.
>

Builds Ok for me.  Post up your build output.

--
Richard A. Smith



From rminnich at lanl.gov  Fri Apr 21 18:52:42 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 21 Apr 2006 10:52:42 -0600
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <4448DDB2.7060801@suehsi.de>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>
	<4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de>
Message-ID: <44490DDA.3000904@lanl.gov>

Christian S?hs wrote:
> 
>> PCI: 00:13.0 init
>> Devices initialized
>> Copying IRQ routing tables to 0xf0000...done.
>> Verifing copy of IRQ routing tables at 0xf0000...failed

you need to make sure shadow bios is enabled, OR just build it with 
CONFIG_COMPRESS=0. IF  you build with CONFIG_COMPRESS=0, you will still 
get this message, but it does not matter.
=
> Filo tries first to init vga and serial, disabling vga makes no 
> different, it fails too.
> 
> Serial needs an IRQ, right?

not for filo.

be sure to rebuild filo completely if you turn off vga in config. OR I 
can send you a known-good serial-only filo



> 
> Is there any callback from filo to LB?

no. LB does not have callbacks.

> Needs filo the LB Irq Table on 0xf0000 to initialise?

no.

thanks

ron



From chris at suehsi.de  Fri Apr 21 20:27:36 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 21 Apr 2006 20:27:36 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604210956t53b70d51j43afd7fca78d0895@mail.gmail.com>
References: <444789D7.1040403@suehsi.de>
	<44479E63.7040003@lanl.gov>	<4447BEC3.3090003@suehsi.de>
	<4448A548.30106@suehsi.de>	<4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>	<44490CAD.5020009@suehsi.de>	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>	<44491DDF.4080703@suehsi.de>	<8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>
	<8a0c36780604210956t53b70d51j43afd7fca78d0895@mail.gmail.com>
Message-ID: <44492418.7070208@suehsi.de>

Richard Smith schrieb:
>>Do you have the pci-utils dev sutff installed?
>>
>>I just pulled a fresh copy last night.  I'll see if I can build it.
>>
> 
> 
> Builds Ok for me.  Post up your build output.

Well, pci_userspace.c makes trouble.

All calls to pci_get_dev fails with to few arguments, because of the IF 
Versions check to libpci

but I should have the right version, because pci/pci.h declared the 
function with 5 arguments, but the check fails and try to compile with 4 
arguments.

However, I have commented the IF stuff and it compiles fine. Now I will 
have a test and hope it works :D

chris

> 
> --
> Richard A. Smith
> 




From rminnich at lanl.gov  Fri Apr 21 19:32:13 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 21 Apr 2006 11:32:13 -0600
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
Message-ID: <4449171D.7020603@lanl.gov>

actually, what would be nice is, instead of a config option, set up the 
struct in chip.h to have a member called firewire, and then in the 
Config.lb, enable it on or off.

thanks

ron



From chris at suehsi.de  Fri Apr 21 20:57:58 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 21 Apr 2006 20:57:58 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <44492418.7070208@suehsi.de>
References: <444789D7.1040403@suehsi.de>	<44479E63.7040003@lanl.gov>	<4447BEC3.3090003@suehsi.de>	<4448A548.30106@suehsi.de>	<4448DDB2.7060801@suehsi.de>	<20060421123811.GA27096@coresystems.de>	<44490CAD.5020009@suehsi.de>	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>	<44491DDF.4080703@suehsi.de>	<8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>	<8a0c36780604210956t53b70d51j43afd7fca78d0895@mail.gmail.com>
	<44492418.7070208@suehsi.de>
Message-ID: <44492B36.3010505@suehsi.de>


> 
> However, I have commented the IF stuff and it compiles fine. Now I will 
> have a test and hope it works :D
> 
---------------------------

Ok, ./testbios -s 20k aw512n.bin
running file aw512n.bin
No base specified. defaulting to 0xc0000
No initial code segment specified. defaulting to 0xc000
No initial instruction pointer specified. defaulting to 0x0003
inb(0x0080) = 0x92
updating int vector 0x0

----------------------

no more :D --> is that right?

while the program runs, I have switched around the consoles, but all 
seems normal. Restarting X, normal too.

<STRG>C

program stops, all is normal ;)

What do this piece of code?

changing the running code in rom to the files code?

chris



From smithbone at gmail.com  Fri Apr 21 20:16:13 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 13:16:13 -0500
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <4449171D.7020603@lanl.gov>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<4449171D.7020603@lanl.gov>
Message-ID: <8a0c36780604211116l2db0ddc6l9b893dacfc407782@mail.gmail.com>

On 4/21/06, Ronald G Minnich <rminnich at lanl.gov> wrote:

> actually, what would be nice is, instead of a config option, set up the
> struct in chip.h to have a member called firewire, and then in the
> Config.lb, enable it on or off.

That was actually what I was thinking about first but then we would
need to create a new mainboard directory right?  Seemed a lot of
duplication just to skip over a couple of lines of code or Can the
target build file override the device stuff in the MB config?

--
Richard A. Smith



From chris at suehsi.de  Fri Apr 21 23:35:30 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 21 Apr 2006 23:35:30 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <44491DDF.4080703@suehsi.de>
References: <444789D7.1040403@suehsi.de>	<44479E63.7040003@lanl.gov>	<4447BEC3.3090003@suehsi.de>	<4448A548.30106@suehsi.de>	<4448DDB2.7060801@suehsi.de>	<20060421123811.GA27096@coresystems.de>	<44490CAD.5020009@suehsi.de>	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de>
Message-ID: <44495022.2060505@suehsi.de>


> 
>>you don't have a copy of the vga binary then you will either need to
>>rip it out of the fuctory bios image or boot under fuctory and then
>>copy it from memory.   The wiki has info on doing this.

>>Then you can test the bios on the target under the emulator.  If it
> 
> 

How? The whole bios?
or the vgabios.bin only.

I get this rare output (describe before), if I try to start testbios 
with the vgabios only. Means, the extracted vgabios only :D

chris





From stepan at coresystems.de  Sat Apr 22 00:06:25 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Apr 2006 00:06:25 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>
	<4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de>
	<8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>
Message-ID: <20060421220625.GB3970@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060421 18:52]:
> > > Then you can test the bios on the target under the emulator.  If it
> >
> > Mmmmmh, the test program under utils/x86emu?
> > I can't compile this :(
> >
> > to few arguments in pci_write() bla, blub
> > or an other program?
> 
> Do you have the pci-utils dev sutff installed?
> 
> I just pulled a fresh copy last night.  I'll see if I can build it.

newer versions of pciutils want the pci domain in addition to bus:dev:fn

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Sat Apr 22 00:11:43 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Apr 2006 00:11:43 +0200
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <4449171D.7020603@lanl.gov>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<4449171D.7020603@lanl.gov>
Message-ID: <20060421221143.GC3970@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060421 19:32]:
> actually, what would be nice is, instead of a config option, set up the 
> struct in chip.h to have a member called firewire, and then in the 
> Config.lb, enable it on or off.

chip.h is post-auto.c stuff, so this won't affect it. nor?

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Sat Apr 22 00:20:42 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 17:20:42 -0500
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <20060421221143.GC3970@coresystems.de>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<4449171D.7020603@lanl.gov> <20060421221143.GC3970@coresystems.de>
Message-ID: <8a0c36780604211520i6ede31d5r56a11a427e2760ce@mail.gmail.com>

> > struct in chip.h to have a member called firewire, and then in the
> > Config.lb, enable it on or off.
>
> chip.h is post-auto.c stuff, so this won't affect it. nor?
>

If its post auto.c then no it won't work.  According to the comments
you have to disable the firewire to make legacy IO work.  So even
prior to early_serial.

Sombody with an Epia-M (not ML) may want to verfiy all this.

--
Richard A. Smith



From smithbone at gmail.com  Sat Apr 22 00:26:44 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 17:26:44 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <20060421220625.GB3970@coresystems.de>
References: <444789D7.1040403@suehsi.de> <4447BEC3.3090003@suehsi.de>
	<4448A548.30106@suehsi.de> <4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de> <44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de>
	<8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>
	<20060421220625.GB3970@coresystems.de>
Message-ID: <8a0c36780604211526u9f7df16uc434023fafe3fbf3@mail.gmail.com>

>
> newer versions of pciutils want the pci domain in addition to bus:dev:fn
>

Oh yeah I remember that now.  His pciutils library is too old and
there isn't an easy way to detect which one is in use.  64-bit systems
require the newer pciutils IIRC.

Wasn't their some option in the makefile to choose what lib to use?

--
Richard A. Smith



From noodles at earth.li  Sat Apr 22 00:47:11 2006
From: noodles at earth.li (Jonathan McDowell)
Date: Fri, 21 Apr 2006 23:47:11 +0100
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <8a0c36780604211520i6ede31d5r56a11a427e2760ce@mail.gmail.com>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<4449171D.7020603@lanl.gov> <20060421221143.GC3970@coresystems.de>
	<8a0c36780604211520i6ede31d5r56a11a427e2760ce@mail.gmail.com>
Message-ID: <20060421224711.GL7570@earth.li>

On Fri, Apr 21, 2006 at 05:20:42PM -0500, Richard Smith wrote:
> > > struct in chip.h to have a member called firewire, and then in the
> > > Config.lb, enable it on or off.
> > chip.h is post-auto.c stuff, so this won't affect it. nor?
> If its post auto.c then no it won't work.  According to the comments
> you have to disable the firewire to make legacy IO work.  So even
> prior to early_serial.
> 
> Sombody with an Epia-M (not ML) may want to verfiy all this.

You want confirmation that that Firewire disabling is necessary for the
Epia-M? I should be able to check this out in the next few days if
someone else doesn't get there first; I've finally got to the point
where my M10000 based project is ready to go ahead and have started
testing again. Recent

J.

-- 
                          noodles is now open
      Ask me about server co-location - info at blackcatnetworks.co.uk



From smithbone at gmail.com  Sat Apr 22 00:53:08 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 17:53:08 -0500
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <20060421224711.GL7570@earth.li>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<4449171D.7020603@lanl.gov> <20060421221143.GC3970@coresystems.de>
	<8a0c36780604211520i6ede31d5r56a11a427e2760ce@mail.gmail.com>
	<20060421224711.GL7570@earth.li>
Message-ID: <8a0c36780604211553p6dbec782l6c7cf4f5e1f9527@mail.gmail.com>

> > you have to disable the firewire to make legacy IO work.  So even
> > prior to early_serial.
> >
> > Sombody with an Epia-M (not ML) may want to verfiy all this.
>
> You want confirmation that that Firewire disabling is necessary for the
> Epia-M? I should be able to check this out in the next few days if
> someone else doesn't get there first; I've finally got to the point
> where my M10000 based project is ready to go ahead and have started
> testing again. Recent

Yeah.  just as a sanity check that that code is there for a reason. 
Board bring up is Voodo sometimes.

--
Richard A. Smith



From stepan at coresystems.de  Sat Apr 22 01:06:40 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Apr 2006 01:06:40 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604211526u9f7df16uc434023fafe3fbf3@mail.gmail.com>
References: <4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de>
	<8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>
	<20060421220625.GB3970@coresystems.de>
	<8a0c36780604211526u9f7df16uc434023fafe3fbf3@mail.gmail.com>
Message-ID: <20060421230640.GA11535@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060422 00:26]:
> >
> > newer versions of pciutils want the pci domain in addition to bus:dev:fn
> >
> 
> Oh yeah I remember that now.  His pciutils library is too old and
> there isn't an easy way to detect which one is in use.  64-bit systems
> require the newer pciutils IIRC.
> 
> Wasn't their some option in the makefile to choose what lib to use?

There's this macro in pci-userspace.c:
#define LIBPCI_CHECK_VERSION(major,minor,micro) \
 ( (LIBPCI_MAJOR_VERSION > (major)) || \
   (LIBPCI_MAJOR_VERSION == (major) && LIBPCI_MINOR_VERSION > (minor)) || \
 (LIBPCI_MAJOR_VERSION == (major) && LIBPCI_MINOR_VERSION == (minor)) && \
 LIBPCI_MICRO_VERSION >= (micro) )

but for some reason it doesn't seem to work.. I guess
LIBPCI_MAJOR_VERSION et al are not set correctly anymore or something
in most recent pciutil version

Christian, what pciutils/libpci version are you using?

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Sat Apr 22 02:49:52 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 21 Apr 2006 18:49:52 -0600
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <20060421221143.GC3970@coresystems.de>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<4449171D.7020603@lanl.gov> <20060421221143.GC3970@coresystems.de>
Message-ID: <44497DB0.5030907@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060421 19:32]:
> 
>>actually, what would be nice is, instead of a config option, set up the 
>>struct in chip.h to have a member called firewire, and then in the 
>>Config.lb, enable it on or off.
> 
> 
> chip.h is post-auto.c stuff, so this won't affect it. nor?
> 


Oops. My bad. That's what comes of not reading a thread in enough 
detail. Sorry.

Go with config option, I guess.

ron



From smithbone at gmail.com  Sat Apr 22 05:21:09 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 21 Apr 2006 22:21:09 -0500
Subject: [LinuxBIOS] PCI max buses patch
Message-ID: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>

The following patch adds a CONFIG_MAX_PCI_BUSES to pci_locate_device()

It defaults to 5 buses which should be plenty for 99% of us.

I only added the actual option to the epia-m config but the global
defaut should pickup for all the other boards.

Please someone apply and auto-build to see if I broke anything.  If
not then I'll commit.

--
Richard A. Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pci_max_buses.patch
Type: application/octet-stream
Size: 2199 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060421/eb7bd380/attachment.obj>

From yinghailu at gmail.com  Sat Apr 22 06:37:11 2006
From: yinghailu at gmail.com (yhlu)
Date: Fri, 21 Apr 2006 21:37:11 -0700
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
Message-ID: <2ea3fae10604212137l2d9aa8a6oee05112bda5aceea@mail.gmail.com>

why?

we already have
pci_locate_device().
pci_locate_device_on_bus(...unsigned bus).

you may add
pci_locate_device_before_bus(...unsigned bus).

YH



On 4/21/06, Richard Smith <smithbone at gmail.com> wrote:
> The following patch adds a CONFIG_MAX_PCI_BUSES to pci_locate_device()
>
> It defaults to 5 buses which should be plenty for 99% of us.
>
> I only added the actual option to the epia-m config but the global
> defaut should pickup for all the other boards.
>
> Please someone apply and auto-build to see if I broke anything.  If
> not then I'll commit.
>
> --
> Richard A. Smith
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>



From chris at suehsi.de  Sat Apr 22 11:09:30 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 11:09:30 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <20060421230640.GA11535@coresystems.de>
References: <4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de>
	<8a0c36780604210952w3352579aqa5086c85e3705eae@mail.gmail.com>
	<20060421220625.GB3970@coresystems.de>
	<8a0c36780604211526u9f7df16uc434023fafe3fbf3@mail.gmail.com>
	<20060421230640.GA11535@coresystems.de>
Message-ID: <4449F2CA.5080004@suehsi.de>

Stefan Reinauer schrieb:
> * Richard Smith <smithbone at gmail.com> [060422 00:26]:
> 
>>>newer versions of pciutils want the pci domain in addition to bus:dev:fn
>>>
>>
>>Oh yeah I remember that now.  His pciutils library is too old and
>>there isn't an easy way to detect which one is in use.  64-bit systems
>>require the newer pciutils IIRC.
>>
>>Wasn't their some option in the makefile to choose what lib to use?
> 
> 
> There's this macro in pci-userspace.c:
> #define LIBPCI_CHECK_VERSION(major,minor,micro) \
>  ( (LIBPCI_MAJOR_VERSION > (major)) || \
>    (LIBPCI_MAJOR_VERSION == (major) && LIBPCI_MINOR_VERSION > (minor)) || \
>  (LIBPCI_MAJOR_VERSION == (major) && LIBPCI_MINOR_VERSION == (minor)) && \
>  LIBPCI_MICRO_VERSION >= (micro) )
> 
> but for some reason it doesn't seem to work.. I guess
> LIBPCI_MAJOR_VERSION et al are not set correctly anymore or something
> in most recent pciutil version
> 
> Christian, what pciutils/libpci version are you using?
> 

I have pciutils-2.2.1 installed. I should have > 2.1.99 ;) to compile 
testbios. I will have a look to a newer version and try it again also I 
will check the settings to LIBPCI_MAJOR_VERSION

chris



From chris at suehsi.de  Sat Apr 22 12:42:55 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 12:42:55 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
References: <444789D7.1040403@suehsi.de> <44479E63.7040003@lanl.gov>	
	<4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>	
	<4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>	
	<44490CAD.5020009@suehsi.de>	
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>	
	<44491DDF.4080703@suehsi.de> <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
Message-ID: <444A08AF.2090706@suehsi.de>


> 
> 
> Running the bios under the emu is tricky.  It may be bailling out
> early although normally it prints a messge.  Search the archives for
> info.  You will probally have to add debug printf's to see whats going
> on.
>

Ok, yesterday evening I have found the testbios faq on the linuxbios page.

I have tried it twice.

1. extracted vgabios from fuctory bios.
2. bios get with dd command from /dev/mem

The result of first try I have described before, it happens nothing.

The second try seems to be more successfully :D
The screen goes to black :D after a second. No more. The connected TFT 
holds the signal. There is a short flickering after 30 seconds I think.
(The reason for no output on the console is the FB Mode. I have 
sometimes problems, if I start a normal program, than there is no output 
too and I need to press <return> for a while to get a prompt)
The system is still running but the only way to get a new try is 
<ctrl><alt><del> to shutdown and reboot the system.

Than I have made tests with my host system, to see what happens.
I get a vga.bin with dd and try it. (PCI Nvidia Graphic Card)

I get a lot of numbers on the console for about 5 seconds, than the 
screen switched to black and the monitor lost the signal and goes to 
stand by. The system is still running but only
<strg><alt><del> helps.

Mmmh, both systems runs in FB Mode, could that be the reason for no more 
output? Should I try the bios on a real console?

What does USER Space mean in the wiki?

chris


> --
> Richard A. Smith
> 




From chris at suehsi.de  Sat Apr 22 12:51:41 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 12:51:41 +0200
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <8a0c36780604211116l2db0ddc6l9b893dacfc407782@mail.gmail.com>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>	<4449171D.7020603@lanl.gov>
	<8a0c36780604211116l2db0ddc6l9b893dacfc407782@mail.gmail.com>
Message-ID: <444A0ABD.8000405@suehsi.de>


> 
> That was actually what I was thinking about first but then we would
> need to create a new mainboard directory right?  Seemed a lot of
> duplication just to skip over a couple of lines of code or Can the
> target build file override the device stuff in the MB config?

There is also an enable setting for the MII in the config.lb under 
src/motherboard/via/epia-m for the ricoh chip

I'm not sure, what happens on this, but most epia-m revisions like the 
ME and others don't have a cf card slot.

chris



From hugo.mercier at laposte.net  Sat Apr 22 12:24:25 2006
From: hugo.mercier at laposte.net (Hugo MERCIER)
Date: Sat, 22 Apr 2006 12:24:25 +0200
Subject: [LinuxBIOS] Bios memory init
Message-ID: <1145701465.4912.25.camel@localhost>

Hi,

I'm investigating the Linuxbios port to the ASUS A7V600 motherboard.

I'm currently at an early phase of the development. I'm just trying to
get the bios executing code ... and I noticed some strange behavior ... 

I wrote a little piece of asm to make the speaker beep.

I created an "empty" bios image (full of 0xFF) except a jmp at FFFFFFF0
to a beep routine and flashed it. Result : nothing happens.

I then copied and overwrite the original bios in order to make it beep
only (modification of the jmp and insertion of the beep function). I
flashed it and it beeps ...

So, it seems the flash memory has to contain some correct bytes before
the processor is "launched". Right ?

Consequently, I took this modified beeping image, and iteratively filled
it with 0xFF and tested if it beeps, in a dichotomic manner, in order to
find what part of the memory is needed.

Result: Two blocks in the memory have to be present before execution of
any instruction: a 1024bytes block at FFFF7C00 and a 16bytes block at
FFFFFFD0. The second block begins with "0x00 0x7C 0xFF 0xFF", so it
seems to be a pointer to the first block.

I can't figure out what these blocks mean. It is divided into 4
subblocks. It's not x86 code. Some sort of init table ... processor
microcode ? other chipsets init ?

The dump of the two blocks are in attachment.

Any ideas ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: block1.bin
Type: application/octet-stream
Size: 1024 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060422/94c709f0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: block2.bin
Type: application/octet-stream
Size: 16 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060422/94c709f0/attachment-0001.bin>

From stepan at coresystems.de  Sat Apr 22 12:22:20 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Apr 2006 12:22:20 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A08AF.2090706@suehsi.de>
References: <4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de> <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de>
Message-ID: <20060422102220.GA18296@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060422 12:42]:
> I get a lot of numbers on the console for about 5 seconds, than the 
> screen switched to black and the monitor lost the signal and goes to 
> stand by. The system is still running but only
> <strg><alt><del> helps.
 
good sign, it actually starts working (or doing something) 

Can you catch those "numbers" to a file?

> Mmmh, both systems runs in FB Mode, could that be the reason for no more 
> output? Should I try the bios on a real console?
 
Yes, definitely. The graphics card bios will reinitialize the 
card in VGA mode, so Linux will be definitely confused if it suddenly
has no pixel based graphics mode anymore.

> What does USER Space mean in the wiki?

it means "running after login as a user" as opposed to "running in the
bios" or "running as a part of the (linux) kernel"

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Sat Apr 22 12:29:56 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Apr 2006 12:29:56 +0200
Subject: [LinuxBIOS] PCI max buses - Simple solution
In-Reply-To: <2ea3fae10604212137l2d9aa8a6oee05112bda5aceea@mail.gmail.com>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<2ea3fae10604212137l2d9aa8a6oee05112bda5aceea@mail.gmail.com>
Message-ID: <20060422102956.GB18296@coresystems.de>

* yhlu <yinghailu at gmail.com> [060422 06:37]:
> we already have
> pci_locate_device().
> pci_locate_device_on_bus(...unsigned bus).
 
Cool! I guess most of us just did not know about that.

static device_t pci_locate_device_on_bus(unsigned pci_id, unsigned bus)

is defined in romcc_io.h and does exactly what is needed in this case.
Firewire on the Epia is always on bus 0.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Sat Apr 22 14:26:53 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 14:26:53 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <20060422102220.GA18296@coresystems.de>
References: <4447BEC3.3090003@suehsi.de> <4448A548.30106@suehsi.de>
	<4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de> <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de>
	<20060422102220.GA18296@coresystems.de>
Message-ID: <444A210D.3030701@suehsi.de>


>  
> Yes, definitely. The graphics card bios will reinitialize the 
> card in VGA mode, so Linux will be definitely confused if it suddenly
> has no pixel based graphics mode anymore.
> 
> 

Yip, I have start the system with vga=normal and taken a fresh vga.bios 
extracted with awardeco from the original factory bios. (The old one was 
definitivly corrupt)

btw. flashbios seems unable to handle WINBOND W29C020

./testbios --abseg /dev/mem -s 32768 aw512n.bin

I get 3 columns of output, which stops after 1-2 seconds
The screen seems froozen, but at the bottom I have 3 blinking "cursors"
I can do what I want, only a Hardreset takes effect ;)

I will try to pipe the output, but this is hard on a readonly filesystem :D

chris



From stepan at coresystems.de  Sat Apr 22 13:50:31 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Apr 2006 13:50:31 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A210D.3030701@suehsi.de>
References: <4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de> <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de>
	<20060422102220.GA18296@coresystems.de>
	<444A210D.3030701@suehsi.de>
Message-ID: <20060422115031.GA28391@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060422 14:26]:
> Yip, I have start the system with vga=normal and taken a fresh vga.bios 
> extracted with awardeco from the original factory bios. (The old one was 
> definitivly corrupt)

yes, vga bios is often self modifying code. I fell like back on the
Amiga or C64 seeing that stuff.

> btw. flashbios seems unable to handle WINBOND W29C020
 
What's the ID? Can you run flashrom -V and mail the output to this list
or to me directly.

> ./testbios --abseg /dev/mem -s 32768 aw512n.bin
> 
> I get 3 columns of output, which stops after 1-2 seconds
> The screen seems froozen, but at the bottom I have 3 blinking "cursors"
> I can do what I want, only a Hardreset takes effect ;)
 
What output? Are you sure aw512n is the vga bios image?

> I will try to pipe the output, but this is hard on a readonly filesystem :D
 
uh, why is it readonly?  you could log in via serial port from another
machine and log the output in your terminal program... That always
works.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Sat Apr 22 15:48:17 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 15:48:17 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <20060422115031.GA28391@coresystems.de>
References: <4448DDB2.7060801@suehsi.de>
	<20060421123811.GA27096@coresystems.de>
	<44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de> <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de>
	<20060422102220.GA18296@coresystems.de>
	<444A210D.3030701@suehsi.de>
	<20060422115031.GA28391@coresystems.de>
Message-ID: <444A3421.3080403@suehsi.de>


> 
>>btw. flashbios seems unable to handle WINBOND W29C020
> 
>  
> What's the ID? Can you run flashrom -V and mail the output to this list
> or to me directly.
> 
> 
It is an older Version
-V seems to have no effect

chipset cs5530
flash part is W29C020C

Verify fails, write seems done right read also. But I have get corrupted 
files

"uniflash" works fine for me, but I will test the latest flashrom from 
svn and see what happens.
>  
> What output? Are you sure aw512n is the vga bios image?

Yes it starts with 55aa and there is a text like:

IBM Compatiple PCI VGA/SVGA Vesa Bios V1.0

> 
> 
>>I will try to pipe the output, but this is hard on a readonly filesystem :D
> 
>  
> uh, why is it readonly?  you could log in via serial port from another
> machine and log the output in your terminal program... That always
> works.

Well, ok not really hard. Not all is readonly, but the main system runs 
out of the RAM and at the moment I use a kernel where is serial output 
disabled ;)

I have piped the output to a file, which is very large and I think it is 
not useful to attach the whole file. Also this try seems successfuller, 
because of the screen goes black and sometimes it flickers.
<ctrl>c stops testbios normaly.

I only post the interesting parts.

What config Options should I use, if I want LB starts with this Bios.

CONFIG_CONSOLE_VGA
CONFIG_PCI_ROM_RUN
CONFIG_LEGACY_BIOS
....

  chris



> 
> Stefan
> 




From chris at suehsi.de  Sat Apr 22 16:12:07 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 16:12:07 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A3421.3080403@suehsi.de>
References: <4448DDB2.7060801@suehsi.de>	<20060421123811.GA27096@coresystems.de>	<44490CAD.5020009@suehsi.de>	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>	<44491DDF.4080703@suehsi.de>
	<44495022.2060505@suehsi.de>	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>	<444A08AF.2090706@suehsi.de>	<20060422102220.GA18296@coresystems.de>	<444A210D.3030701@suehsi.de>	<20060422115031.GA28391@coresystems.de>
	<444A3421.3080403@suehsi.de>
Message-ID: <444A39B7.30201@suehsi.de>


> 
> I only post the interesting parts.
> 

Here are the results ;)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testbios.log
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060422/fccf82de/attachment.ksh>

From stepan at coresystems.de  Sat Apr 22 15:07:04 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Apr 2006 15:07:04 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A3421.3080403@suehsi.de>
References: <44490CAD.5020009@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de> <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de>
	<20060422102220.GA18296@coresystems.de>
	<444A210D.3030701@suehsi.de>
	<20060422115031.GA28391@coresystems.de>
	<444A3421.3080403@suehsi.de>
Message-ID: <20060422130704.GA896@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060422 15:48]:
> chipset cs5530
> flash part is W29C020C
> 
> Verify fails, write seems done right read also. But I have get corrupted 
> files
 
Sounds like a timing issue in the driver..

How early does it fail? (address)

You get corrupted _files_?

> Well, ok not really hard. Not all is readonly, but the main system runs 
> out of the RAM and at the moment I use a kernel where is serial output 
> disabled ;)
 
You will need serial output to get LinuxBIOS up and running at the
current stage anyways..

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Sat Apr 22 15:08:06 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Apr 2006 15:08:06 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A39B7.30201@suehsi.de>
References: <8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de> <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de>
	<20060422102220.GA18296@coresystems.de>
	<444A210D.3030701@suehsi.de>
	<20060422115031.GA28391@coresystems.de>
	<444A3421.3080403@suehsi.de> <444A39B7.30201@suehsi.de>
Message-ID: <20060422130806.GB896@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060422 16:12]:
> 
> >
> >I only post the interesting parts.
> >
> 
> Here are the results ;)

it'd be more interesting to see the bios calls its making than 
some random hw io.

> running file aw512n.bin
> No base specified. defaulting to 0xc0000
> No initial code segment specified. defaulting to 0xc000
> No initial instruction pointer specified. defaulting to 0x0003
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x42
> updating int vector 0x42
> updating int vector 0x43
> updating int vector 0x43
> updating int vector 0x1f
> updating int vector 0x1f
> outb(0x18, 0x46e8)
> outb(0x01, 0x0102)
> outb(0x08, 0x46e8)
> outw(0x04f8, 0x03ce)
> outw(0x00fb, 0x03ce)
> outw(0x80bb, 0x03ce)
> outw(0x80ba, 0x03ce)
> outw(0x52b2, 0x03ce)
> outw(0x50b3, 0x03ce)
> outb(0xb9, 0x03ce)
> inb(0x03cf) = 0x00
> outw(0x80b9, 0x03ce)
> outw(0x00b9, 0x03ce)
> outb(0x70, 0x03ce)
> inb(0x03cf) = 0x0b
> outw(0x0b70, 0x03ce)
> outw(0xa871, 0x03ce)
> outw(0x80b5, 0x03ce)
> outb(0xbe, 0x03ce)
> inb(0x03cf) = 0x0a
> outw(0x0abe, 0x03ce)
> outw(0x8097, 0x03ce)
> outw(0x031f, 0x03d4)
> outw(0x0157, 0x03ce)
> inw(0x03ce) = 0x0157
> outw(0x0057, 0x03ce)
> outw(0x0100, 0x03c4)
> outw(0x0001, 0x03c4)
> outw(0x0302, 0x03c4)
> outw(0x0003, 0x03c4)
> outw(0x0204, 0x03c4)
> outb(0x01, 0x03c4)
> inw(0x03c4) = 0x0001
> outw(0x2001, 0x03c4)
> outb(0x67, 0x03c2)
> outw(0x0300, 0x03c4)
> outb(0x11, 0x03d4)
> inb(0x03d5) = 0x8e
> outw(0x0e11, 0x03d4)
> outw(0x5f00, 0x03d4)
> outw(0x4f01, 0x03d4)
> 
> -------------------------------
> 
> outw(0x0058, 0x03ce)
> outw(0x0059, 0x03ce)
> outw(0x005a, 0x03ce)
> outw(0x0057, 0x03ce)
> outw(0x0077, 0x03ce)
> outw(0x003c, 0x03ce)
> outw(0x205c, 0x03ce)
> outb(0x90, 0x03ce)
> inb(0x03cf) = 0x10
> outw(0x1090, 0x03ce)
> outb(0x72, 0x03ce)
> inw(0x03ce) = 0x0672
> outw(0x0672, 0x03ce)
> outb(0x56, 0x03ce)
> inw(0x03ce) = 0x0056
> outw(0x0456, 0x03ce)
> inb(0x03c6) = 0x04
> outb(0x04, 0x03c6)
> outw(0x0056, 0x03ce)
> outb(0x73, 0x03ce)
> inb(0x0080) = 0x93
> inb(0x03cf) = 0x11
> inb(0x0080) = 0x93
> inb(0x03cf) = 0x10
> inb(0x0080) = 0x93
> inb(0x03cf) = 0x10
> inb(0x0080) = 0x93
> inb(0x03cf) = 0x10
> inb(0x0080) = 0x93
> inb(0x03cf) = 0x10
> inb(0x0080) = 0x93
> inb(0x03cf) = 0x10
> inb(0x0080) = 0x93
> inb(0x03cf) = 0x10
> inb(0x0080) = 0x90
> inb(0x03cf) = 0x10
> inb(0x0080) = 0x90
> inb(0x03cf) = 0x10
> 
> ------------------------
> 
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x09
> outw(0x0036, 0x03ce)
> outw(0x0072, 0x03ce)
> outw(0x0379, 0x03ce)
> outw(0xa071, 0x03ce)
> outw(0x1073, 0x03ce)
> outw(0x0ff9, 0x03ce)
> outw(0x3034, 0x03c4)
> outw(0x0035, 0x03c4)
> outw(0x8530, 0x03c4)
> outw(0x013c, 0x03c4)
> outw(0x003b, 0x03c4)
> outw(0x0c33, 0x03c4)
> outw(0x003e, 0x03c4)
> outw(0x553f, 0x03c4)
> outw(0x083a, 0x03c4)
> outw(0x0231, 0x03c4)
> outw(0x0b70, 0x03ce)
> outw(0x00f4, 0x03ce)
> outw(0x3d36, 0x03c4)
> outw(0x01bf, 0x03ce)
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> inb(0x03da) = 0x01
> 
> ---------------------------
> 
> inb(0x03ba) = 0x01
> inb(0x03ba) = 0x01
> inb(0x03ba) = 0x01
> inb(0x03ba) = 0x01
> inb(0x03ba) = 0x01
> inb(0x03ba) = 0x00
> outb(0xbe, 0x03ce)
> inb(0x03cf) = 0x6a
> outw(0x00bf, 0x03ce)
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> int10 vector at c41b4
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> run_bios_int: INT 10 CS:IP = c000:41b4
> outb(0x56, 0x03ce)
> inb(0x03cf) = 0x00
> outw(0x0456, 0x03ce)
> inb(0x03c6) = 0x04
> outb(0x44, 0x03c6)
> outb(0x33, 0x03ce)
> inb(0x03cf) = 0x00
> outb(0x06, 0x03ce)
> inb(0x03cf) = 0x0e
> outw(0x0833, 0x03ce)
> outw(0x803c, 0x03ce)
> inb(0x03cc) = 0x00
> outb(0x00, 0x03c2)
> inb(0x03cc) = 0x00
> outb(0x02, 0x03c2)
> outw(0x003c, 0x03ce)
> outb(0x33, 0x03ce)
> inb(0x03cf) = 0x08
> outw(0x0033, 0x03ce)
> outb(0x95, 0x03ce)
> inb(0x03cf) = 0x00
> outw(0x0095, 0x03ce)
> updating int vector 0x43
> updating int vector 0x43
> outw(0xa871, 0x03ce)
> outb(0x70, 0x03ce)
> inb(0x03cf) = 0x0b
> outw(0xcb70, 0x03ce)
> outw(0x05fa, 0x03ce)
> outb(0x4e, 0x03ce)
> inb(0x03cf) = 0x00
> outw(0x004e, 0x03ce)
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff 

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Sat Apr 22 16:45:49 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 16:45:49 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <20060422130806.GB896@coresystems.de>
References: <8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>	<44491DDF.4080703@suehsi.de>
	<44495022.2060505@suehsi.de>	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>	<444A08AF.2090706@suehsi.de>	<20060422102220.GA18296@coresystems.de>	<444A210D.3030701@suehsi.de>	<20060422115031.GA28391@coresystems.de>	<444A3421.3080403@suehsi.de>
	<444A39B7.30201@suehsi.de> <20060422130806.GB896@coresystems.de>
Message-ID: <444A419D.5050401@suehsi.de>


> 
> it'd be more interesting to see the bios calls its making than 
> some random hw io.
> 

what is that ??
but it is the only one.

>>updating int vector 0x10
>>updating int vector 0x10
>>updating int vector 0x10
>>updating int vector 0x10
>>updating int vector 0x10
>>run_bios_int: INT 10 CS:IP = c000:41b4
>>outb(0x56, 0x03ce)
>>inb(0x03cf) = 0x00





From smithbone at gmail.com  Sat Apr 22 16:38:37 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Apr 2006 09:38:37 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A3421.3080403@suehsi.de>
References: <4448DDB2.7060801@suehsi.de>
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>
	<44491DDF.4080703@suehsi.de> <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de> <20060422102220.GA18296@coresystems.de>
	<444A210D.3030701@suehsi.de> <20060422115031.GA28391@coresystems.de>
	<444A3421.3080403@suehsi.de>
Message-ID: <8a0c36780604220738v664bcba1q615049be26961a4d@mail.gmail.com>

> > works.
>
> Well, ok not really hard. Not all is readonly, but the main system runs
> out of the RAM and at the moment I use a kernel where is serial output
> disabled ;)

That's why the first step in my instructions said to "get a serial
console up."  Its pretty much required for VGA debugging.

> I have piped the output to a file, which is very large and I think it is
> not useful to attach the whole file. Also this try seems successfuller,
> because of the screen goes black and sometimes it flickers.
> <ctrl>c stops testbios normaly.

You need to comment out the in/out printfs.  in vgabios edit the file
helper_exec.c starting at line 131 comment out all the printf's for
the in and out statements.   That will quiet down the noise level
quite a bit.  When you run it on the target system you may need to
always re-direct the output to a file.  I've found that the slowdown
associated with the printf to the console (which has to go out the
serial port) may cause some trouble with timing.

Route it to a file to look at but also try routeing the output to
>/dev/null to see if it makes any difference.

Those printfs really need to be off by default.

If vgabios succeeds then you should see some sort of bios sign on
message on your screen.  Since there was no vga available when Linux
booted there won't be a console.  You might be able to load a
framebuffer _module_ at that time.  But the best dianostic is to try
and load the X server.  The X log file has lots of good info in it for
debugging.  Note that you don't need the whole X setup just the server
for your chip.

--
Richard A. Smith



From chris at suehsi.de  Sat Apr 22 18:10:47 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 18:10:47 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604220738v664bcba1q615049be26961a4d@mail.gmail.com>
References: <4448DDB2.7060801@suehsi.de>	
	<8a0c36780604210845u633749e7m9a879bc050f9bad4@mail.gmail.com>	
	<44491DDF.4080703@suehsi.de> <44495022.2060505@suehsi.de>	
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>	
	<444A08AF.2090706@suehsi.de>
	<20060422102220.GA18296@coresystems.de>	
	<444A210D.3030701@suehsi.de>
	<20060422115031.GA28391@coresystems.de>	
	<444A3421.3080403@suehsi.de>
	<8a0c36780604220738v664bcba1q615049be26961a4d@mail.gmail.com>
Message-ID: <444A5587.8030107@suehsi.de>


> 
> You need to comment out the in/out printfs.  in vgabios edit the file
> helper_exec.c starting at line 131 comment out all the printf's for
> the in and out statements.   That will quiet down the noise level
> quite a bit.  When you run it on the target system you may need to
> always re-direct the output to a file.  I've found that the slowdown
> associated with the printf to the console (which has to go out the
> serial port) may cause some trouble with timing.
> 

Well, but there is a big problem for me.
The VFS mounted the filesystem readonly.
I'm not sure why, but the system is not initialize properly.

I will try to fix that.

> 
> If vgabios succeeds then you should see some sort of bios sign on
> message on your screen.  Since there was no vga available when Linux
> booted there won't be a console.  You might be able to load a
> framebuffer _module_ at that time.  But the best dianostic is to try
> and load the X server.  The X log file has lots of good info in it for
> debugging.  Note that you don't need the whole X setup just the server
> for your chip.

Ok later more ;)
> 
> --
> Richard A. Smith
> 




From smithbone at gmail.com  Sat Apr 22 17:01:26 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Apr 2006 10:01:26 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A5587.8030107@suehsi.de>
References: <4448DDB2.7060801@suehsi.de> <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de> <20060422102220.GA18296@coresystems.de>
	<444A210D.3030701@suehsi.de> <20060422115031.GA28391@coresystems.de>
	<444A3421.3080403@suehsi.de>
	<8a0c36780604220738v664bcba1q615049be26961a4d@mail.gmail.com>
	<444A5587.8030107@suehsi.de>
Message-ID: <8a0c36780604220801m73228df8h28f023f8662e5d0c@mail.gmail.com>

> > always re-direct the output to a file.  I've found that the slowdown
> > associated with the printf to the console (which has to go out the
> > serial port) may cause some trouble with timing.
> >
>
> Well, but there is a big problem for me.
> The VFS mounted the filesystem readonly.
> I'm not sure why, but the system is not initialize properly.
>
> I will try to fix that.

Can you just remout it?  'mount -o remount, rw /'

Or perhaps enable ramfs in your kernel and just make a ram disk to
hold the info.  Of course when testdisk crashes the system you will
lose the log but its a start.

--
Richard A. Smith



From stepan at coresystems.de  Sat Apr 22 17:44:07 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 22 Apr 2006 17:44:07 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A419D.5050401@suehsi.de>
References: <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de>
	<20060422102220.GA18296@coresystems.de>
	<444A210D.3030701@suehsi.de>
	<20060422115031.GA28391@coresystems.de>
	<444A3421.3080403@suehsi.de> <444A39B7.30201@suehsi.de>
	<20060422130806.GB896@coresystems.de> <444A419D.5050401@suehsi.de>
Message-ID: <20060422154407.GA27007@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060422 16:45]:
> 
> >
> >it'd be more interesting to see the bios calls its making than 
> >some random hw io.
> >
> 
> what is that ??
> but it is the only one.

Did you get no other output than that? Its incomplete.

Try running it verbose then. There's something missing.

> >>updating int vector 0x10
> >>updating int vector 0x10
> >>updating int vector 0x10
> >>updating int vector 0x10
> >>updating int vector 0x10
> >>run_bios_int: INT 10 CS:IP = c000:41b4
> >>outb(0x56, 0x03ce)
> >>inb(0x03cf) = 0x00
> 
> 
> 
-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Sat Apr 22 19:50:47 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 19:50:47 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <20060422154407.GA27007@coresystems.de>
References: <44495022.2060505@suehsi.de>
	<8a0c36780604211325n27bf3837q94f67e6fce697780@mail.gmail.com>
	<444A08AF.2090706@suehsi.de>
	<20060422102220.GA18296@coresystems.de>
	<444A210D.3030701@suehsi.de>
	<20060422115031.GA28391@coresystems.de>
	<444A3421.3080403@suehsi.de> <444A39B7.30201@suehsi.de>
	<20060422130806.GB896@coresystems.de> <444A419D.5050401@suehsi.de>
	<20060422154407.GA27007@coresystems.de>
Message-ID: <444A6CF7.6040507@suehsi.de>

New start:

I have compiled testbios without the printfs for outs and ins.

Than I have made to runs:

First, boot with factory bios, after that a boot with LB
have a look at the attachments, that is the whole output.

in both cases the file was catched with minicom.
Also I was able to start/stop testbios normal.

With the factory bios I get a sometimes flickering screen. Testbios 
stops automaticaly after a while.

With LB it happens nothing on the screen :(

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testvgafactory.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060422/c8012cae/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testvgaLB.cap
Type: application/octet-stream
Size: 541 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060422/c8012cae/attachment.obj>

From smithbone at gmail.com  Sat Apr 22 18:40:33 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Apr 2006 11:40:33 -0500
Subject: [LinuxBIOS] PCI max buses - Simple solution
In-Reply-To: <20060422102956.GB18296@coresystems.de>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<2ea3fae10604212137l2d9aa8a6oee05112bda5aceea@mail.gmail.com>
	<20060422102956.GB18296@coresystems.de>
Message-ID: <8a0c36780604220940y681897fao1bb55dad6f6caf99@mail.gmail.com>

On 4/22/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * yhlu <yinghailu at gmail.com> [060422 06:37]:
> > we already have
> > pci_locate_device().
> > pci_locate_device_on_bus(...unsigned bus).
>
> Cool! I guess most of us just did not know about that.
>
> static device_t pci_locate_device_on_bus(unsigned pci_id, unsigned bus)
>
> is defined in romcc_io.h and does exactly what is needed in this case.
> Firewire on the Epia is always on bus 0.

Ok so the "right" solution for the epia-m is to change
pci_locate_device() to pci_locate_device_on_bus(0);

Eric:  Please confirm that it fixes your problem.

That still leaves the outstanding issue that pci_locate_device() will
pause for long periods if it can't find a device.  And probing the
entire pci space may not be a good thing anyway.

I would propose that pci_locate_device still needs a hard cap.

Whats the maximum number of PCI buses that any one has ever seen on one board?

--
Richard A. Smith



From smithbone at gmail.com  Sat Apr 22 19:29:48 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Apr 2006 12:29:48 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A6CF7.6040507@suehsi.de>
References: <44495022.2060505@suehsi.de>
	<20060422102220.GA18296@coresystems.de> <444A210D.3030701@suehsi.de>
	<20060422115031.GA28391@coresystems.de> <444A3421.3080403@suehsi.de>
	<444A39B7.30201@suehsi.de> <20060422130806.GB896@coresystems.de>
	<444A419D.5050401@suehsi.de> <20060422154407.GA27007@coresystems.de>
	<444A6CF7.6040507@suehsi.de>
Message-ID: <8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>

> First, boot with factory bios, after that a boot with LB
> have a look at the attachments, that is the whole output.

Running testbios after the factory bios has already posted the chip
dosen't really tell us much.  Its good to know that it at least runs
in some setup though.

Try this.  Find a PCI video card and plug it in your system.  Then
tell your factory bios to either init a PCI card first (If your chip
is AGP) or it should find the PCI card  before the onboard video and
init that chip.  Leaving your on board device un-posted.

Then you need to use 'setpci' to disable the IO range for the PCI
card.  You have to do this from a serial console because your VGA will
stop.

Then use the -d option to specify your onboard device to testbios. 
You have to convert Bus:dev:func to the packed notation.  See the wiki
faq on testbios for details.

Hey... I just realized that none of your command lines have the -d
option specified.  That won't work, its not optional.  You _have_ to
specifiy a device.  Without it you are sending all your PCI requests
to 0:0:0 which is probally not your video device.

The reason it does something after factory and not LB is because
factory has allready talked to the device and enabled the legacy IO. 
With LB most of stuff on the card is disabled and the bios is just
looping forever looking for an IO bit to go active.

I just looked at the Wiki and it is incorrect.  -d is not 'diag' mode.
 I'll go fix it.

Set your device and try again.  If it still dosen't work then try my
alternate card method and run testbios on a non-posted card under
factory.

--
Richard A. Smith



From smithbone at gmail.com  Sat Apr 22 20:10:23 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Apr 2006 13:10:23 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A8075.1030100@suehsi.de>
References: <44495022.2060505@suehsi.de>
	<20060422115031.GA28391@coresystems.de> <444A3421.3080403@suehsi.de>
	<444A39B7.30201@suehsi.de> <20060422130806.GB896@coresystems.de>
	<444A419D.5050401@suehsi.de> <20060422154407.GA27007@coresystems.de>
	<444A6CF7.6040507@suehsi.de>
	<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>
	<444A8075.1030100@suehsi.de>
Message-ID: <8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>

On 4/22/06, Christian S?hs <chris at suehsi.de> wrote:

>
> >
> > Set your device and try again.  If it still dosen't work then try my
> > alternate card method and run testbios on a non-posted card under
> > factory.
> >
>
> I have tried -d 0:9.0
>
> -d 0:9:0
>
> how is the right syntax for -d

Its in the wiki testbios FAQ.

    *  How to get pci busdevfn
    * lspci
    * look for your video card
          o Example:
            2:00:00
            2 (00 << 3) | 00 = 0x200
          o Example:
            00:12.0:
            0 (12 << 3) | 0 = 0x90

So for you its

0 (9 << 3) | 0 = 0x048

so '-d 0x48'

--
Richard A. Smith



From chris at suehsi.de  Sat Apr 22 21:46:40 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 22 Apr 2006 21:46:40 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>
References: <44495022.2060505@suehsi.de>	<20060422115031.GA28391@coresystems.de>
	<444A3421.3080403@suehsi.de>	<444A39B7.30201@suehsi.de>
	<20060422130806.GB896@coresystems.de>	<444A419D.5050401@suehsi.de>
	<20060422154407.GA27007@coresystems.de>	<444A6CF7.6040507@suehsi.de>	<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>	<444A8075.1030100@suehsi.de>
	<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>
Message-ID: <444A8820.6080606@suehsi.de>


> 
> 0 (9 << 3) | 0 = 0x048
> 
> so '-d 0x48'
>

8-)

sorry I need to learn more about this.

Ok, it doesn't work. I will try the second method with another card.

chris

> --
> Richard A. Smith
> 




From smithbone at gmail.com  Sat Apr 22 20:54:40 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Apr 2006 13:54:40 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>
References: <44495022.2060505@suehsi.de> <20060422130806.GB896@coresystems.de>
	<444A419D.5050401@suehsi.de>
	<20060422154407.GA27007@coresystems.de>
	<444A6CF7.6040507@suehsi.de>
	<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>
	<444A8075.1030100@suehsi.de>
	<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>
	<444A8820.6080606@suehsi.de>
	<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>
Message-ID: <8a0c36780604221154q71712241s1b83082856e99ce0@mail.gmail.com>

Oops forgot to Reply to all:

> 8-)
>
> sorry I need to learn more about this.
>
> Ok, it doesn't work. I will try the second method with another card.

doesn't work how?  More details please or we can't help much.  What
output did you get?

If it does not work under factory with previously non-posted chip then
you are going to have to re-enable the IO printfs and see whats up.

Note.  Comparing the IO logs between the posted and non-posted runs
won't do you much good.  One of the first things video bios does is
check to see if the card has already been posted and if it has then it
will take a different path and skip a lot of the init stuff.

Welcome to the single hardest thing in Linuxbios.   *grin*

Well perhaps second to trying to enable RAM without a proper datasheet.

Definitely the hardest from a user standpoint.

--
Richard A. Smith



From yinghailu at gmail.com  Sat Apr 22 22:09:06 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 22 Apr 2006 13:09:06 -0700
Subject: [LinuxBIOS] PCI max buses - Simple solution
In-Reply-To: <8a0c36780604220940y681897fao1bb55dad6f6caf99@mail.gmail.com>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<2ea3fae10604212137l2d9aa8a6oee05112bda5aceea@mail.gmail.com>
	<20060422102956.GB18296@coresystems.de>
	<8a0c36780604220940y681897fao1bb55dad6f6caf99@mail.gmail.com>
Message-ID: <2ea3fae10604221309y6772a239t2120e6ba7ad3f3a1@mail.gmail.com>

For K8, I put second chain on 0x40, third chain on 0x80, and fourth
chain on 0xc0.

YH

On 4/22/06, Richard Smith <smithbone at gmail.com> wrote:
> On 4/22/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> > * yhlu <yinghailu at gmail.com> [060422 06:37]:
> > > we already have
> > > pci_locate_device().
> > > pci_locate_device_on_bus(...unsigned bus).
> >
> > Cool! I guess most of us just did not know about that.
> >
> > static device_t pci_locate_device_on_bus(unsigned pci_id, unsigned bus)
> >
> > is defined in romcc_io.h and does exactly what is needed in this case.
> > Firewire on the Epia is always on bus 0.
>
> Ok so the "right" solution for the epia-m is to change
> pci_locate_device() to pci_locate_device_on_bus(0);
>
> Eric:  Please confirm that it fixes your problem.
>
> That still leaves the outstanding issue that pci_locate_device() will
> pause for long periods if it can't find a device.  And probing the
> entire pci space may not be a good thing anyway.
>
> I would propose that pci_locate_device still needs a hard cap.
>
> Whats the maximum number of PCI buses that any one has ever seen on one board?
>
> --
> Richard A. Smith
>



From smithbone at gmail.com  Sat Apr 22 22:57:44 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Apr 2006 15:57:44 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444A9D58.7050205@suehsi.de>
References: <44495022.2060505@suehsi.de> <444A419D.5050401@suehsi.de>
	<20060422154407.GA27007@coresystems.de> <444A6CF7.6040507@suehsi.de>
	<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>
	<444A8075.1030100@suehsi.de>
	<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>
	<444A8820.6080606@suehsi.de>
	<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>
	<444A9D58.7050205@suehsi.de>
Message-ID: <8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>

> > If it does not work under factory with previously non-posted chip then
> > you are going to have to re-enable the IO printfs and see whats up.
> >
>
> What exact is the meaning of posted and non-posted.

Sorry. My bad.  I forget about the lingo sometimes.

post or rather POST.  Power On Self Test.  The video bios people call
a card that has been initialized by the BIOS 'posted.'   Probally
because it happens during the BIOS which used to be much more of a
POST.  Nowdays BIOS is a whole different beast but the 'posting' term
remained.

posted = initialized.

--
Richard A. Smith



From smithbone at gmail.com  Sat Apr 22 23:02:14 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Apr 2006 16:02:14 -0500
Subject: [LinuxBIOS] PCI max buses - Simple solution
In-Reply-To: <2ea3fae10604221309y6772a239t2120e6ba7ad3f3a1@mail.gmail.com>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<2ea3fae10604212137l2d9aa8a6oee05112bda5aceea@mail.gmail.com>
	<20060422102956.GB18296@coresystems.de>
	<8a0c36780604220940y681897fao1bb55dad6f6caf99@mail.gmail.com>
	<2ea3fae10604221309y6772a239t2120e6ba7ad3f3a1@mail.gmail.com>
Message-ID: <8a0c36780604221402k17888118xc7f6f9b21f45d74c@mail.gmail.com>

On 4/22/06, yhlu <yinghailu at gmail.com> wrote:

> For K8, I put second chain on 0x40, third chain on 0x80, and fourth
> chain on 0xc0.
>

Ok so even though there are only 4 buses they are not numbered
consecutively.  Ah..well that changes things a bit then dosen't it?

So then we just need to leave it alone?   So far its only been the
epia-ml that has a problem.

--
Richard A. Smith



From cej at os.dk  Sun Apr 23 01:26:50 2006
From: cej at os.dk (Christian =?iso-8859-1?Q?E=2E_J=F8rgensen?=)
Date: Sun, 23 Apr 2006 01:26:50 +0200
Subject: [LinuxBIOS] Tyan Tomcat K8E (S2865)
Message-ID: <20060422232650.GA2747@balthazar>

Hi!

I'm on the lookout for a socket 939 board that supports LinuxBIOS. Will
this one do? If not, are there others? 

Best regards, 
Christian E. J?rgensen



From smithbone at gmail.com  Sun Apr 23 02:36:16 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 22 Apr 2006 19:36:16 -0500
Subject: [LinuxBIOS] Make testbios understand PCI bus:dev.func
Message-ID: <8a0c36780604221736j5ca3de2bk5c739b4c30fc6c3@mail.gmail.com>

The following patch makes testbios understand what to do with a device
that is specified as bus:dev.func or dev.func.  If you just give it
one number then its works like the original.

so '-d 0:9.0' or '-d 9.0' will translate to devfn of 0x48

It also add a sanity check for the device if you appear to be running
an option ROM.  So if you fail to specify a device or your -d
parameter works out to 0 it prints a warning message.

--
Richard A. Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testbios_grok_busdevfn.patch
Type: application/octet-stream
Size: 2530 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060422/ade566ed/attachment.obj>

From eric at zyxod.com  Sun Apr 23 06:52:02 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Sat, 22 Apr 2006 21:52:02 -0700
Subject: [LinuxBIOS] Epia ML 5000 progress (sort of)
In-Reply-To: <44485812.8070409@zyxod.com>
References: <44485812.8070409@zyxod.com>
Message-ID: <444B07F2.3080605@zyxod.com>

[NB: I wrote this originally as a reply to my original post to 
LinuxBIOS. I didn't realize that the LB mailing list did not set the 
'reply-to' field.  In conjunction with how my email filters work, I 
thought this email went to the list, but it only came to me!  In any 
case, I'll send it for posterity, but I'll add additional remarks in 
square brackets WRT what I have discovered]

I've created an Epia-ML target, and I'm making changes that I hope will
work.  Presently, I'm trying to change the VGA settings, but I'm a bit
confused on the PCI device IDs

I know that the ML Shows up as a 3122 instead of the 3123 as found on
the M series. AFAIK, 3122 == ML and 3123 == M.  The
write_protect_vgabios function in src/mainboard/via/epia-ml/mainboard.c
looks like this:

void write_protect_vgabios(void)
{
        device_t dev;

        printk_info("write_protect_vgabios\n");
        /* there are two possible devices. Just do both. */
        dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0);
        if(dev)
                pci_write_config8(dev, 0x61, 0xaa);

        dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0);
        if(dev)
                pci_write_config8(dev, 0x61, 0xaa);
}

Since this is an ML specific target, can I remove the 3123 attempt?

Also:

[The supposition I make below is wrong.  The VT 8623 and CLE266_VGA are 
different.  When I changed the PCI_DEVICE_ID_VIA_8623 to 
PCI_DEVICE_ID_VIA_CLE266_VGA in the struct, LB did not work.]

src/include/device/pci_ids.h has these declarations:

#define PCI_DEVICE_ID_VIA_CLE266_VGA    0x3122
#define PCI_DEVICE_ID_VIA_8623          0x3123

The file src/northbridge/via/vt8623/northbridge.c has this struct defined:

static struct pci_driver northbridge_driver __pci_driver = {
        .ops = &northbridge_operations,
        .vendor = PCI_VENDOR_ID_VIA,
        .device = PCI_DEVICE_ID_VIA_8623,
};

I know pretty much zero about how PCI and the chipset works.  Both the M
and ML datasheets say they have the CLE266 northbridge.  Web searches
seem to imply that "vt8623" and "cle266" are interchangeable terms.  I'm
wondering if the ML target should have a struct that refers to
PCI_DEVICE_ID_VIA_CLE266_VGA (3122) instead of PCI_DEVICE_ID_VIA_8623
(3123).  If so, since this file is in
src/src/northbridge/via/vt8623/northbridge.c, is there a way of
separating it to have two versions (or #defines) for the M and ML targets?










From chris at suehsi.de  Sun Apr 23 10:57:14 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 23 Apr 2006 10:57:14 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>
References: <44495022.2060505@suehsi.de>
	<444A419D.5050401@suehsi.de>	<20060422154407.GA27007@coresystems.de>
	<444A6CF7.6040507@suehsi.de>	<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>	<444A8075.1030100@suehsi.de>	<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>	<444A8820.6080606@suehsi.de>	<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>	<444A9D58.7050205@suehsi.de>
	<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>
Message-ID: <444B416A.8070903@suehsi.de>

> 
> Sorry. My bad.  I forget about the lingo sometimes.
> 
> post or rather POST.  Power On Self Test.  The video bios people call
> a card that has been initialized by the BIOS 'posted.'   Probally
> because it happens during the BIOS which used to be much more of a
> POST.  Nowdays BIOS is a whole different beast but the 'posting' term
> remained.
> 
> posted = initialized.

Ok,

now I have done a few tests with a extra vga card.
There a no settings in the factory bios for that case. If I remember 
right, than they are hidden. I have had a look long time ago with 
awardbin on the orginal bios.bin.

However, the system detects the card first and posted them ;)
What should I do? How can I disable the posted card correctly.

Look at the attachment. With command=0 it is possible to unset the IO 
and Mem from + to - but I think that is not enough. VGA is still running.

If I try to run testbios after set IO/MEM to -  the result is nearly the 
same as I boot with LB.

If I run testbios without unsetting the IO Range, the output is very 
different from all others. There are a few more calls. I will attach 
this output later, because after those experiments I have to do my best 
to restart the system :D

Unfortanetly I know nothing about PCI Registers and commands

Thanks

chris
> --
> Richard A. Smith
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setpci.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060423/f67949df/attachment.ksh>

From chris at suehsi.de  Sun Apr 23 11:24:51 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 23 Apr 2006 11:24:51 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444B416A.8070903@suehsi.de>
References: <44495022.2060505@suehsi.de>	<444A419D.5050401@suehsi.de>	<20060422154407.GA27007@coresystems.de>	<444A6CF7.6040507@suehsi.de>	<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>	<444A8075.1030100@suehsi.de>	<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>	<444A8820.6080606@suehsi.de>	<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>	<444A9D58.7050205@suehsi.de>	<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>
	<444B416A.8070903@suehsi.de>
Message-ID: <444B47E3.7060403@suehsi.de>


> 
> If I try to run testbios after set IO/MEM to -  the result is nearly the 
> same as I boot with LB.
> 

Well, if I set the onboard chip IO to +
following happens at running testbios

(attachment)

After the run, the screen connected to the onboard vga is black & white 
with rectangles an flickers. (2 times / second)

I have seen that there is no latency on 0:9.0
also it seems the onboard vga memory is false detected [16MB]
it should be 4MB

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setpci2.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060423/a0c0efab/attachment.ksh>

From smithbone at gmail.com  Sun Apr 23 10:26:42 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 03:26:42 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036
In-Reply-To: <444B416A.8070903@suehsi.de>
References: <44495022.2060505@suehsi.de> <444A6CF7.6040507@suehsi.de>
	<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>
	<444A8075.1030100@suehsi.de>
	<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>
	<444A8820.6080606@suehsi.de>
	<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>
	<444A9D58.7050205@suehsi.de>
	<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>
	<444B416A.8070903@suehsi.de>
Message-ID: <8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>

> However, the system detects the card first and posted them ;)
> What should I do? How can I disable the posted card correctly.
>
> Look at the attachment. With command=0 it is possible to unset the IO
> and Mem from + to - but I think that is not enough. VGA is still running.

Thats it. Bits 0 and 1 in the command register control access to the
IO space and memory space.  Setting them to 0 should disable the card.
 So you say when clear them that you can still get video updates on
the console?

Rather than use lspci -w you may want also check with -x.  I've had -w
and other stuff report back old settings.  Like it was cached and not
updated when I tweaked the registers.  -x will re-read them.  The
command register is offset 4.

> If I try to run testbios after set IO/MEM to -  the result is nearly the
> same as I boot with LB.

Well I'm out of things to try.   Now it gets ugly.

Perhaps Ollie has some other suggestions.  He has debugged a lot of cards.

I think you are going to have to enable the printf's in the IO for the
emulator and match them up with the datasheet to see what's happening.

--
Richard A. Smith



From chris at suehsi.de  Sun Apr 23 12:03:12 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 23 Apr 2006 12:03:12 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>
References: <44495022.2060505@suehsi.de> <444A6CF7.6040507@suehsi.de>	
	<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>	
	<444A8075.1030100@suehsi.de>	
	<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>	
	<444A8820.6080606@suehsi.de>	
	<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>	
	<444A9D58.7050205@suehsi.de>	
	<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>	
	<444B416A.8070903@suehsi.de>
	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>
Message-ID: <444B50E0.4080700@suehsi.de>


Waaaaaaah,

I can't believe that :D

What happens?

Ok,
I had have a look to /usr/include/linux/pci.h

The registers are described in that file.

setpci -d VENDOR_ID:DEVICE_ID command=0 (0000)
in that case disable the pci vga cards IO / MEM.

setpci -d VENDOR_ID:DEVICE_ID command=3

where 0x1 is IO and 0x2 is MEM
in that case enables the IO and MEM to + from onboard vga

after that a new try with testbios.

flicker, flicker
black screen with blinking cursor :D

Send an echo "hello" > /dev/tty0 about serial

voila ;)

what now, I think it will run under Linuxbios, but how can I set control 
registers on boot time or is that done by LB or the vga bios

chris



From chris at suehsi.de  Sun Apr 23 12:24:22 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 23 Apr 2006 12:24:22 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444B50E0.4080700@suehsi.de>
References: <44495022.2060505@suehsi.de>
	<444A6CF7.6040507@suehsi.de>		<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>		<444A8075.1030100@suehsi.de>		<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>		<444A8820.6080606@suehsi.de>		<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>		<444A9D58.7050205@suehsi.de>		<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>		<444B416A.8070903@suehsi.de>	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>
	<444B50E0.4080700@suehsi.de>
Message-ID: <444B55D6.8080001@suehsi.de>

Christian S?hs schrieb:
> Waaaaaaah,
> 
same test under LB

setting IO/MEM with setpci to +

run testbios

same result

the screen comes up after a few seconds with a blinking cursor

I think now its time to include the vga.bios into the LB image
But I ask before.

How should I setup LB to use the vga.bios with the emulator.
Which CONFIG Options do I need for that.

There are a few more questions for me.

After filo loads the kernel and initrd.gz there is a jump to the entry 
point.
It tooks a lot of time to do that jump (5 seconds!?)

Under factory bios the boot stuff is done by syslinux.
After initrd.gz is load, there is the same jump, but this is done very 
quickly.

What could be the reason.

On my Epia ME this jump is done by filo very quick, too.

chris




From chris at suehsi.de  Sun Apr 23 13:43:01 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 23 Apr 2006 13:43:01 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444B55D6.8080001@suehsi.de>
References: <44495022.2060505@suehsi.de>
	<444A6CF7.6040507@suehsi.de>		<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>		<444A8075.1030100@suehsi.de>		<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>		<444A8820.6080606@suehsi.de>		<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>		<444A9D58.7050205@suehsi.de>		<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>		<444B416A.8070903@suehsi.de>	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>
	<444B50E0.4080700@suehsi.de> <444B55D6.8080001@suehsi.de>
Message-ID: <444B6845.5020607@suehsi.de>


> 
> How should I setup LB to use the vga.bios with the emulator.
> Which CONFIG Options do I need for that.
> 

Oops, now I have found it on the wiki.

chris



From chris at suehsi.de  Sun Apr 23 17:57:36 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 23 Apr 2006 17:57:36 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444B6845.5020607@suehsi.de>
References: <44495022.2060505@suehsi.de>
	<444A6CF7.6040507@suehsi.de>		<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>		<444A8075.1030100@suehsi.de>		<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>		<444A8820.6080606@suehsi.de>		<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>		<444A9D58.7050205@suehsi.de>		<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>		<444B416A.8070903@suehsi.de>	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>
	<444B50E0.4080700@suehsi.de> <444B55D6.8080001@suehsi.de>
	<444B6845.5020607@suehsi.de>
Message-ID: <444BA3F0.7000105@suehsi.de>

Christian S?hs schrieb:
> 
>>
>> How should I setup LB to use the vga.bios with the emulator.
>> Which CONFIG Options do I need for that.
>>
> 
> Oops, now I have found it on the wiki.
> 
> chris
> 

Well, currently I'm not able to bring up the VGA console.
I'm not sure, if I done all right.

in Option.lb I have inserted the two CONFIGs

uses CONFIG_CONSOLE_VGA
uses CONFIG_PCI_ROM_RUN

default CONFIG_CONSOLE_VGA=1
default CONFIG_PCI_ROM_RUN=1


where the second option seems to bring up the cs5530 internal graphic 
engine (attachment)

Furthermore, the emulator fails on a false expansion ROM signatur 0202
it should be 55aa, right?

Is there any option, that I have forgotten?

In Config.lb should I insert a rom_adress and a few lines. What does 
image in that case mean. The whole Bios image (256k) or the vga segment 
only (32k).
I have inserted this lines at the bottom end of the file as described in 
the wiki. My Device is also located as in the description (9.0 PCI)
rom_adress = 0xfff40000 for 256K image ?!

thanks for any hints

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vga_try_1.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060423/83588d4e/attachment.ksh>

From rminnich at lanl.gov  Sun Apr 23 16:50:38 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 08:50:38 -0600
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444BA3F0.7000105@suehsi.de>
References: <44495022.2060505@suehsi.de>	<444A6CF7.6040507@suehsi.de>		<8a0c36780604221029u2799b453tb5a55a7cb0861d69@mail.gmail.com>		<444A8075.1030100@suehsi.de>		<8a0c36780604221110l11d4efe7h344f36a30f6c6e2d@mail.gmail.com>		<444A8820.6080606@suehsi.de>		<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>		<444A9D58.7050205@suehsi.de>		<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>		<444B416A.8070903@suehsi.de>	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>	<444B50E0.4080700@suehsi.de>
	<444B55D6.8080001@suehsi.de>	<444B6845.5020607@suehsi.de>
	<444BA3F0.7000105@suehsi.de>
Message-ID: <444B943E.1000300@lanl.gov>

Christian S?hs wrote:

> In Config.lb should I insert a rom_adress and a few lines. What does 
> image in that case mean. The whole Bios image (256k) or the vga segment 
> only (32k).
> I have inserted this lines at the bottom end of the file as described in 
> the wiki. My Device is also located as in the description (9.0 PCI)
> rom_adress = 0xfff40000 for 256K image ?!

for a 256kB flash part you should 0xffffc000. You can look at the 4882 
mainboard for an example.


thanks

ron



From rminnich at lanl.gov  Sun Apr 23 16:53:19 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 08:53:19 -0600
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
Message-ID: <444B94DF.709@lanl.gov>

Richard Smith wrote:
> The following patch adds a CONFIG_MAX_PCI_BUSES to pci_locate_device()
>

sorry I have not been following this discussion more closely. So, the 
basic idea here is that for the romcc part, we rarely need to look on 
high busses for devices? Is that really true?

ron



From stepan at coresystems.de  Sun Apr 23 17:01:23 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 23 Apr 2006 17:01:23 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444BA3F0.7000105@suehsi.de>
References: <444A8820.6080606@suehsi.de>
	<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>
	<444A9D58.7050205@suehsi.de>
	<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>
	<444B416A.8070903@suehsi.de>
	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>
	<444B50E0.4080700@suehsi.de> <444B55D6.8080001@suehsi.de>
	<444B6845.5020607@suehsi.de> <444BA3F0.7000105@suehsi.de>
Message-ID: <20060423150123.GA10314@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060423 17:57]:
> in Option.lb I have inserted the two CONFIGs
> 
> uses CONFIG_CONSOLE_VGA
> uses CONFIG_PCI_ROM_RUN
> 
> default CONFIG_CONSOLE_VGA=1
> default CONFIG_PCI_ROM_RUN=1
> 
> where the second option seems to bring up the cs5530 internal graphic 
> engine (attachment)
 
So the onboard VGA works? Confusing..

> Furthermore, the emulator fails on a false expansion ROM signatur 0202
> it should be 55aa, right?

yes, it is looking at address 0xfe000000, not at your bios image. Are you 
talking about onboard graphics or a pci expansion card now?

> In Config.lb should I insert a rom_adress and a few lines. What does 
> image in that case mean. The whole Bios image (256k) or the vga segment 
> only (32k).

In which case? 

> I have inserted this lines at the bottom end of the file as described in 
> the wiki. My Device is also located as in the description (9.0 PCI)
> rom_adress = 0xfff40000 for 256K image ?!
 
what lines?

If your linuxbios image is 256kbyte and your graphics bios image is at the very
beginning of the linuxbios image, the address is 0xfffc0000. If your
LinuxBIOS image is 512k the address would be 0xfff80000. And so on.


Stefan





From smithbone at gmail.com  Sun Apr 23 17:13:11 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 10:13:11 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444BA3F0.7000105@suehsi.de>
References: <44495022.2060505@suehsi.de>
	<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>
	<444A9D58.7050205@suehsi.de>
	<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>
	<444B416A.8070903@suehsi.de>
	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>
	<444B50E0.4080700@suehsi.de> <444B55D6.8080001@suehsi.de>
	<444B6845.5020607@suehsi.de> <444BA3F0.7000105@suehsi.de>
Message-ID: <8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>

> Allocating resources...
> Reading resources...
> Done reading resources.
> Allocating VGA resource PCI: 00:12.4 // here is the internal graphic which should be disabled

Do you still have the PCI video card in the system?  You can remove
it.  All the extra card was for was so that you could have a factory
BIOS enviromnet where the on board video was not posted.

For LinuxBIOS you don't need that.  Remove it and see if Linux bios
sets up the card correctly.

Then you can enable the VGA emulator options.

--
Richard A. Smith



From chris at suehsi.de  Sun Apr 23 18:47:09 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 23 Apr 2006 18:47:09 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <20060423150123.GA10314@coresystems.de>
References: <444A8820.6080606@suehsi.de>	<8a0c36780604221151n4f4e36b9lef40e2c6f4be7c3f@mail.gmail.com>	<444A9D58.7050205@suehsi.de>	<8a0c36780604221357u49e5be33k74be98ff195f7323@mail.gmail.com>	<444B416A.8070903@suehsi.de>	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>	<444B50E0.4080700@suehsi.de>
	<444B55D6.8080001@suehsi.de>	<444B6845.5020607@suehsi.de>
	<444BA3F0.7000105@suehsi.de>
	<20060423150123.GA10314@coresystems.de>
Message-ID: <444BAF8D.5030608@suehsi.de>


> 
> yes, it is looking at address 0xfe000000, not at your bios image. Are you 
> talking about onboard graphics or a pci expansion card now?
>

This board has a cs5530 southbridge, this bridge has an internal graphic 
engine, but this item is not used.

Also the board has a cyberpro 5000 graphic (onboard) chip located on the 
PCI BUS
There a two onboard graphic engines, one is used the other isn't

It is possible, that the kalhua cs5530 graphic chip is normally used for 
a LVDS connector, but this board revision doesn't have this connector 
and also a few other items like resistors and so on. I will try that 
later :D



> In which case? 

In the wiki text.


> what lines?
>

device pci 9.0 on
	driver .....

end



> If your linuxbios image is 256kbyte and your graphics bios image is at the very
> beginning of the linuxbios image, the address is 0xfffc0000. If your
> LinuxBIOS image is 512k the address would be 0xfff80000. And so on.
> 

shit I have had a few tests, always with the wrong addresses
I will try this.

chris

> Stefan
> 
> 
> 




From stepan at coresystems.de  Sun Apr 23 17:49:48 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 23 Apr 2006 17:49:48 +0200
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <444B94DF.709@lanl.gov>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<444B94DF.709@lanl.gov>
Message-ID: <20060423154947.GA17084@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060423 16:53]:
> sorry I have not been following this discussion more closely. So, the 
> basic idea here is that for the romcc part, we rarely need to look on 
> high busses for devices? Is that really true?

The romcc part is not supposed to "talk" to any non-onboard devices.

The scanning process takes forever in the romcc part. So as long as we
want to claim fast boot we simply _have_ to believe that we dont have to
look at high busses there.

S.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Sun Apr 23 17:50:40 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 10:50:40 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>
References: <44495022.2060505@suehsi.de> <444B416A.8070903@suehsi.de>
	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>
	<444B50E0.4080700@suehsi.de> <444B55D6.8080001@suehsi.de>
	<444B6845.5020607@suehsi.de> <444BA3F0.7000105@suehsi.de>
	<8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>
	<444BACBF.5090005@suehsi.de>
	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>
Message-ID: <8a0c36780604230850g4eff712buea927b9c3ad2d7c8@mail.gmail.com>

Crap.. Forgot to reply to all....

> This allocated vga resource is part of the cs5530. This chip has an
> included vga engine, which is not used for the board. Normally disabled
> by Config.lb, but the PCI_RUN bring up that item.

Ah well thats a problem.  So the on board CS5530 VGA is device 12 and
the Cyberpro 5000 is device 9?

I don't have my PCI book handy but IIRC you have to use the highest
number for guessing which is the primary display to enable the legacy
IO ranges.  Which is not the the chip you want.

You said you were using the the eaglelion/5bcm config.lb config file
right?  I looked at it and I see:

       device pci 12.1 off end         # SMI
       device pci 12.2 on  end         # IDE
       device pci 12.3 off end         # Audio
       device pci 12.4 off end         # VGA

Group question:

If so then why does is the vga IO enabled?  Is  the PCI resource
allocator for VGA supposed to use this config?

--
--
Richard A. Smith



From rminnich at lanl.gov  Sun Apr 23 17:46:06 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 09:46:06 -0600
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <20060423154947.GA17084@coresystems.de>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<444B94DF.709@lanl.gov> <20060423154947.GA17084@coresystems.de>
Message-ID: <444BA13E.7090006@lanl.gov>

Stefan Reinauer wrote:

> The scanning process takes forever in the romcc part. So as long as we
> want to claim fast boot we simply _have_ to believe that we dont have to
> look at high busses there.


ok, that makes sense to me. I just wanted to make sure I understood it. 
I'm fine with that patch.

ron



From chris at suehsi.de  Sun Apr 23 20:14:39 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 23 Apr 2006 20:14:39 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>
References: <44495022.2060505@suehsi.de>	
	<8a0c36780604230126j1d876a05o5f1810b39dec39db@mail.gmail.com>	
	<444B50E0.4080700@suehsi.de> <444B55D6.8080001@suehsi.de>	
	<444B6845.5020607@suehsi.de> <444BA3F0.7000105@suehsi.de>	
	<8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>	
	<444BACBF.5090005@suehsi.de>	
	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>	
	<444BB7FB.8040806@suehsi.de>
	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>
Message-ID: <444BC40F.9010904@suehsi.de>


> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
> Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
> 
> This means that the primary VGA device was set to 12.4.  Which means
> that 12.4 gets the legacy IO range.
>

Well, but why.
I have told about the config script, that 9.0 is the one to use :(


> Go into src/devices/device.c and change line 416 from a 1 to a 0. 
> Accrding to the comments that should use the last vga device as
> primary rather than the first one.

I will try this.

But few things more.
How does I handle the config.lb

(attachment)

first the old section:
This produced LB, if I insert the wiki lines at least.
After the other initializing stuff.

If I insert
device pci 9.0 on
... bla bla

after device pci 0.0 on

the second section is produced.

ok, both don't bring up the console, but there are lot of differents

In the second one 9.0 is allocated as VGA first
but not as subsystem!
Also there is no init which fails later??

chris




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vga_try_3.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060423/3d16e47f/attachment.ksh>

From smithbone at gmail.com  Sun Apr 23 21:04:06 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 14:04:06 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444BC40F.9010904@suehsi.de>
References: <44495022.2060505@suehsi.de> <444B55D6.8080001@suehsi.de>
	<444B6845.5020607@suehsi.de> <444BA3F0.7000105@suehsi.de>
	<8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>
	<444BACBF.5090005@suehsi.de>
	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>
	<444BB7FB.8040806@suehsi.de>
	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>
	<444BC40F.9010904@suehsi.de>
Message-ID: <8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>

On 4/23/06, Christian S?hs <chris at suehsi.de> wrote:

> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
> > Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
> >
> > This means that the primary VGA device was set to 12.4.  Which means
> > that 12.4 gets the legacy IO range.
> >
>
> Well, but why.
> I have told about the config script, that 9.0 is the one to use :(
>

I've added some debug output to the VGA area that determines which
device to use as primary.  Apply the attached patch and post the
output.

The output is BIOS_SPEW level output so you will have to bump your
maximum loglevel up to 10 and your default loglevel to 9

--
Richard A. Smith



From smithbone at gmail.com  Sun Apr 23 21:22:20 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 14:22:20 -0500
Subject: [LinuxBIOS] [Commit] Make testbios understand PCI bus:dev.func
In-Reply-To: <8a0c36780604221736j5ca3de2bk5c739b4c30fc6c3@mail.gmail.com>
References: <8a0c36780604221736j5ca3de2bk5c739b4c30fc6c3@mail.gmail.com>
Message-ID: <8a0c36780604231222q34622fc5v741a41abc100e335@mail.gmail.com>

Yeesh.  Hit the wrong button. Lets try this again.

On 4/22/06, Richard Smith <smithbone at gmail.com> wrote:
> The following patch makes testbios understand what to do with a device
> that is specified as bus:dev.func or dev.func.  If you just give it
> one number then its works like the original.
>
> so '-d 0:9.0' or '-d 9.0' will translate to devfn of 0x48
>
> It also add a sanity check for the device if you appear to be running
> an option ROM.  So if you fail to specify a device or your -d
> parameter works out to 0 it prints a warning message.

Signed off by Ron and Committed.

Chris: please update  and give it some testing time.

--
Richard A. Smith



From smithbone at gmail.com  Sun Apr 23 21:32:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 14:32:43 -0500
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <444BA13E.7090006@lanl.gov>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<444B94DF.709@lanl.gov> <20060423154947.GA17084@coresystems.de>
	<444BA13E.7090006@lanl.gov>
Message-ID: <8a0c36780604231232x2a23d11ld57758279e09b5cb@mail.gmail.com>

On 4/23/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> Stefan Reinauer wrote:
>
> > The scanning process takes forever in the romcc part. So as long as we
> > want to claim fast boot we simply _have_ to believe that we dont have to
> > look at high busses there.
>
>
> ok, that makes sense to me. I just wanted to make sure I understood it.
> I'm fine with that patch.

Its going to break any board that depends on pci_locate_device() to
find things on a high bus.  Is that going to be ok?

A grep for pci_locate_device() shows that its used in a lot of places.


--
Richard A. Smith



From rminnich at lanl.gov  Sun Apr 23 21:26:29 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 13:26:29 -0600
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <8a0c36780604231232x2a23d11ld57758279e09b5cb@mail.gmail.com>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>	
	<444B94DF.709@lanl.gov> <20060423154947.GA17084@coresystems.de>	
	<444BA13E.7090006@lanl.gov>
	<8a0c36780604231232x2a23d11ld57758279e09b5cb@mail.gmail.com>
Message-ID: <444BD4E5.6060606@lanl.gov>

Richard Smith wrote:
> On 4/23/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> 
>>Stefan Reinauer wrote:
>>
>>
>>>The scanning process takes forever in the romcc part. So as long as we
>>>want to claim fast boot we simply _have_ to believe that we dont have to
>>>look at high busses there.
>>
>>
>>ok, that makes sense to me. I just wanted to make sure I understood it.
>>I'm fine with that patch.
> 
> 
> Its going to break any board that depends on pci_locate_device() to
> find things on a high bus.  Is that going to be ok?
> 
> A grep for pci_locate_device() shows that its used in a lot of places.

right, but unless I missed the point, that is configurable?

thanks

ron



From smithbone at gmail.com  Sun Apr 23 21:48:32 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 14:48:32 -0500
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <444BD4E5.6060606@lanl.gov>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<444B94DF.709@lanl.gov> <20060423154947.GA17084@coresystems.de>
	<444BA13E.7090006@lanl.gov>
	<8a0c36780604231232x2a23d11ld57758279e09b5cb@mail.gmail.com>
	<444BD4E5.6060606@lanl.gov>
Message-ID: <8a0c36780604231248j1a207865tcbde8a714a8b0360@mail.gmail.com>

>
> right, but unless I missed the point, that is configurable?

Yes.  I've got the default set to 5.  I just wanted to make sure
before I go breaking boards in slient ways.

yulu are you ok with this?

--
Richard A. Smith



From smithbone at gmail.com  Sun Apr 23 22:00:53 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 15:00:53 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444BEC7D.3010806@suehsi.de>
References: <44495022.2060505@suehsi.de> <444BA3F0.7000105@suehsi.de>
	<8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>
	<444BACBF.5090005@suehsi.de>
	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>
	<444BB7FB.8040806@suehsi.de>
	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>
	<444BC40F.9010904@suehsi.de>
	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>
	<444BEC7D.3010806@suehsi.de>
Message-ID: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>

On 4/23/06, Christian S?hs <chris at suehsi.de> wrote:
>
> >
> > I've added some debug output to the VGA area that determines which
> > device to use as primary.  Apply the attached patch and post the
> > output.
> >
>
> Thanks, but there is no attachement :(
> I will have a look to the svn

Sorry.  Forgot to attach.

Try this.

--
Richard A. Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vga_IO_debug.patch
Type: application/octet-stream
Size: 1896 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060423/6b7108f8/attachment.obj>

From rminnich at lanl.gov  Sun Apr 23 22:19:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 14:19:36 -0600
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <8a0c36780604231248j1a207865tcbde8a714a8b0360@mail.gmail.com>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>	
	<444B94DF.709@lanl.gov> <20060423154947.GA17084@coresystems.de>	
	<444BA13E.7090006@lanl.gov>	
	<8a0c36780604231232x2a23d11ld57758279e09b5cb@mail.gmail.com>	
	<444BD4E5.6060606@lanl.gov>
	<8a0c36780604231248j1a207865tcbde8a714a8b0360@mail.gmail.com>
Message-ID: <444BE158.5060102@lanl.gov>

Richard Smith wrote:
>>right, but unless I missed the point, that is configurable?
> 
> 
> Yes.  I've got the default set to 5.  I just wanted to make sure
> before I go breaking boards in slient ways.
> 
> yulu are you ok with this?

I see the right way to do this is to make the default behaviour the 
'guaranteed no break boards' behaviour. That means default value is to 
scan all busses. For those who need/want it set lower, they can know 
where the config option is.

But we sure oculd use an addiiton to the wiki that explains stuff like this.

make sense?

ron



From stepan at coresystems.de  Sun Apr 23 22:32:47 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 23 Apr 2006 22:32:47 +0200
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <444BE158.5060102@lanl.gov>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<444B94DF.709@lanl.gov> <20060423154947.GA17084@coresystems.de>
	<444BA13E.7090006@lanl.gov>
	<8a0c36780604231232x2a23d11ld57758279e09b5cb@mail.gmail.com>
	<444BD4E5.6060606@lanl.gov>
	<8a0c36780604231248j1a207865tcbde8a714a8b0360@mail.gmail.com>
	<444BE158.5060102@lanl.gov>
Message-ID: <20060423203247.GA11917@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060423 22:19]:
> I see the right way to do this is to make the default behaviour the 
> 'guaranteed no break boards' behaviour. That means default value is to 
> scan all busses. For those who need/want it set lower, they can know 
> where the config option is.
> 
> But we sure oculd use an addiiton to the wiki that explains stuff like this.
> 
> make sense?
 
perfect sense.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Sun Apr 23 22:48:39 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 15:48:39 -0500
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <444BE158.5060102@lanl.gov>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<444B94DF.709@lanl.gov> <20060423154947.GA17084@coresystems.de>
	<444BA13E.7090006@lanl.gov>
	<8a0c36780604231232x2a23d11ld57758279e09b5cb@mail.gmail.com>
	<444BD4E5.6060606@lanl.gov>
	<8a0c36780604231248j1a207865tcbde8a714a8b0360@mail.gmail.com>
	<444BE158.5060102@lanl.gov>
Message-ID: <8a0c36780604231348h51898a8escc0b873d0a17d2e5@mail.gmail.com>

> I see the right way to do this is to make the default behaviour the
> 'guaranteed no break boards' behaviour. That means default value is to
> scan all busses. For those who need/want it set lower, they can know
> where the config option is.

Ok. I'll change the default to be 255 and commit.

> But we sure oculd use an addiiton to the wiki that explains stuff like this.

Any ideas on a section title and how we would lay it out?  There is
already the linuxBIOS options but its largly incomprehensible to a
newbe.

There is a disconnect between the lasting info that gets on the wiki
and all the discussion on the mailing list.  We need some method to
catagorize all the discussions on the list into something searchable
by mailboard or perhaps chipset.

--
Richard A. Smith



From chris at suehsi.de  Mon Apr 24 00:05:26 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 00:05:26 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
References: <44495022.2060505@suehsi.de>
	<444BA3F0.7000105@suehsi.de>	<8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>	<444BACBF.5090005@suehsi.de>	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>	<444BB7FB.8040806@suehsi.de>	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>	<444BC40F.9010904@suehsi.de>	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>
	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
Message-ID: <444BFA26.1000405@suehsi.de>


> 
> Sorry.  Forgot to attach.
>

Allright, here is the more verbose output.

It seems that 12.4 is assign as first pci vga Device anymore.
Tomorrow I will try to set

if 1 to if 0 in device.c

I hope than is taken the right one.

What about the rom_adress

stefan means 0xfffc0000
ron means    0xffffc000

:D

what should I try?
The vga segment is located first in the image.

chris

> Richard A. Smith
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vga_try_4.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/98bfe6de/attachment.ksh>

From chris at suehsi.de  Mon Apr 24 00:06:18 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 00:06:18 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
References: <44495022.2060505@suehsi.de>
	<444BA3F0.7000105@suehsi.de>	<8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>	<444BACBF.5090005@suehsi.de>	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>	<444BB7FB.8040806@suehsi.de>	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>	<444BC40F.9010904@suehsi.de>	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>
	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
Message-ID: <444BFA5A.3020106@suehsi.de>


> 
> Sorry.  Forgot to attach.
>

Allright, here is the more verbose output.

It seems that 12.4 is assign as first pci vga Device anymore.
Tomorrow I will try to set

if 1 to if 0 in device.c

I hope than is taken the right one.

What about the rom_adress

stefan means 0xfffc0000
ron means    0xffffc000

:D

what should I try?
The vga segment is located first in the image.

chris

> Richard A. Smith
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vga_try_4.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/6da7ccef/attachment.ksh>

From rminnich at lanl.gov  Sun Apr 23 22:43:23 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 14:43:23 -0600
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <8a0c36780604231348h51898a8escc0b873d0a17d2e5@mail.gmail.com>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>	
	<444B94DF.709@lanl.gov> <20060423154947.GA17084@coresystems.de>	
	<444BA13E.7090006@lanl.gov>	
	<8a0c36780604231232x2a23d11ld57758279e09b5cb@mail.gmail.com>	
	<444BD4E5.6060606@lanl.gov>	
	<8a0c36780604231248j1a207865tcbde8a714a8b0360@mail.gmail.com>	
	<444BE158.5060102@lanl.gov>
	<8a0c36780604231348h51898a8escc0b873d0a17d2e5@mail.gmail.com>
Message-ID: <444BE6EB.3060805@lanl.gov>

Richard Smith wrote:
>>I see the right way to do this is to make the default behaviour the
>>'guaranteed no break boards' behaviour. That means default value is to
>>scan all busses. For those who need/want it set lower, they can know
>>where the config option is.
> 
> 
> Ok. I'll change the default to be 255 and commit.
> 
> 
>>But we sure oculd use an addiiton to the wiki that explains stuff like this.
> 
> 
> Any ideas on a section title and how we would lay it out?  There is
> already the linuxBIOS options but its largly incomprehensible to a
> newbe.
> 
> There is a disconnect between the lasting info that gets on the wiki
> and all the discussion on the mailing list.  We need some method to
> catagorize all the discussions on the list into something searchable
> by mailboard or perhaps chipset.
> 
> --
> Richard A. Smith

I'd say a preprocessor of some sort that can take the Options.lb and 
produce latex. Furthermore, we can add "hints" to Options.lb such as 
"you can set the MAX PCI to 5 if you are sure there are no higher 
devices" or some such.

But documents derived from source is probably all we can expect, given 
our time limits.

ron



From rminnich at lanl.gov  Sun Apr 23 22:52:28 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 14:52:28 -0600
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444BFA5A.3020106@suehsi.de>
References: <44495022.2060505@suehsi.de>	<444BA3F0.7000105@suehsi.de>	<8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>	<444BACBF.5090005@suehsi.de>	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>	<444BB7FB.8040806@suehsi.de>	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>	<444BC40F.9010904@suehsi.de>	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444BFA5A.3020106@suehsi.de>
Message-ID: <444BE90C.20505@lanl.gov>

Christian S?hs wrote:
> 
>>
>> Sorry.  Forgot to attach.
>>
> 
> Allright, here is the more verbose output.
> 
> It seems that 12.4 is assign as first pci vga Device anymore.
> Tomorrow I will try to set
> 
> if 1 to if 0 in device.c
> 
> I hope than is taken the right one.
> 
> What about the rom_adress
> 
> stefan means 0xfffc0000
> ron means    0xffffc000


well, stefan is right. I hit one too many 'f'. sorry.

ron



From yinghailu at gmail.com  Sun Apr 23 23:17:50 2006
From: yinghailu at gmail.com (yhlu)
Date: Sun, 23 Apr 2006 14:17:50 -0700
Subject: [LinuxBIOS] PCI max buses patch
In-Reply-To: <8a0c36780604231348h51898a8escc0b873d0a17d2e5@mail.gmail.com>
References: <8a0c36780604212021p6bce0ff4wc84572c04e3a2159@mail.gmail.com>
	<444B94DF.709@lanl.gov> <20060423154947.GA17084@coresystems.de>
	<444BA13E.7090006@lanl.gov>
	<8a0c36780604231232x2a23d11ld57758279e09b5cb@mail.gmail.com>
	<444BD4E5.6060606@lanl.gov>
	<8a0c36780604231248j1a207865tcbde8a714a8b0360@mail.gmail.com>
	<444BE158.5060102@lanl.gov>
	<8a0c36780604231348h51898a8escc0b873d0a17d2e5@mail.gmail.com>
Message-ID: <2ea3fae10604231417u3771bb97h7dc30920a7ea9086@mail.gmail.com>

That function is only called in auto stage or cache_as_ram_stage....

To support more chains (4 chains ) and make it more dynamical (
installed or not), I need default to be set 255 at this time.

and some time later it will be 0xfff for segment num support and 24
chains or more.

YH

On 4/23/06, Richard Smith <smithbone at gmail.com> wrote:
> > I see the right way to do this is to make the default behaviour the
> > 'guaranteed no break boards' behaviour. That means default value is to
> > scan all busses. For those who need/want it set lower, they can know
> > where the config option is.
>
> Ok. I'll change the default to be 255 and commit.
>
> > But we sure oculd use an addiiton to the wiki that explains stuff like this.
>
> Any ideas on a section title and how we would lay it out?  There is
> already the linuxBIOS options but its largly incomprehensible to a
> newbe.
>
> There is a disconnect between the lasting info that gets on the wiki
> and all the discussion on the mailing list.  We need some method to
> catagorize all the discussions on the list into something searchable
> by mailboard or perhaps chipset.
>
> --
> Richard A. Smith
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From stepan at coresystems.de  Sun Apr 23 23:29:57 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 23 Apr 2006 23:29:57 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444BFA26.1000405@suehsi.de>
References: <8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>
	<444BACBF.5090005@suehsi.de>
	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>
	<444BB7FB.8040806@suehsi.de>
	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>
	<444BC40F.9010904@suehsi.de>
	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>
	<444BEC7D.3010806@suehsi.de>
	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444BFA26.1000405@suehsi.de>
Message-ID: <20060423212957.GB19684@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060424 00:05]:
> What about the rom_adress
> 
> stefan means 0xfffc0000
> ron means    0xffffc000
> 
> :D
> 
> what should I try?
> The vga segment is located first in the image.

Flash chips are located directly below 4G (0xffffffff)

So you need to calculate the address by subtracting the
flash chip size (and adding the offset within the image)

in your case the offset within the image is 0, because its the first
thing.

then you type (in bash for example)

biossize=256
printf "0x%x\n" $(( 0x100000000 - ($biossize*1024) ))

Stefan





From rminnich at lanl.gov  Mon Apr 24 01:56:23 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 17:56:23 -0600
Subject: [LinuxBIOS] GX2 status
Message-ID: <444C1427.4020508@lanl.gov>

as of today I am booting linux on my AMD rumba! i am using busybox and 
getting to a /bin/ash prompt. Things all seem to work.

I can insmod the rtl8139 driver, but I'm not sure yet how INTA hooks up 
to the SB. That's for today.

Thanks to Steve Goodrich, who came down and got us off the ground, and 
all the great folks at AMD who have given us so much help. This week's 
work will be ethernet and graphics.

We're getting there. Anyone else out there doing GX2 at this point?

ron



From smithbone at gmail.com  Mon Apr 24 02:06:00 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 19:06:00 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <20060423212957.GB19684@coresystems.de>
References: <8a0c36780604230813h662660e5pa63fbc2acad0011c@mail.gmail.com>
	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>
	<444BB7FB.8040806@suehsi.de>
	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>
	<444BC40F.9010904@suehsi.de>
	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>
	<444BEC7D.3010806@suehsi.de>
	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444BFA26.1000405@suehsi.de> <20060423212957.GB19684@coresystems.de>
Message-ID: <8a0c36780604231706x6fe39a5er6e904170da514ec0@mail.gmail.com>

> So you need to calculate the address by subtracting the
> flash chip size (and adding the offset within the image)
>

I updated the wiki with this info.

--
Richard A. Smith



From smithbone at gmail.com  Mon Apr 24 02:16:31 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 19:16:31 -0500
Subject: [LinuxBIOS] GX2 status
In-Reply-To: <444C1427.4020508@lanl.gov>
References: <444C1427.4020508@lanl.gov>
Message-ID: <8a0c36780604231716x4832dcb7p72325189d23e832f@mail.gmail.com>

On 4/23/06, Ronald G Minnich <rminnich at lanl.gov> wrote:

> We're getting there. Anyone else out there doing GX2 at this point?

I've got my eval board.  But I was waiting for the VSA stuff to get
worked out.  Can you send me a VSA bin that works and quick
instructions for putting it into my build.  I'll pull out my eval
board and give it a test.

--
Richard A. Smith



From rminnich at lanl.gov  Mon Apr 24 02:36:08 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 18:36:08 -0600
Subject: [LinuxBIOS] GX2 status
In-Reply-To: <8a0c36780604231716x4832dcb7p72325189d23e832f@mail.gmail.com>
References: <444C1427.4020508@lanl.gov>
	<8a0c36780604231716x4832dcb7p72325189d23e832f@mail.gmail.com>
Message-ID: <444C1D78.4000901@lanl.gov>

Richard Smith wrote:
> On 4/23/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> 
> 
>>We're getting there. Anyone else out there doing GX2 at this point?
> 
> 
> I've got my eval board.  But I was waiting for the VSA stuff to get
> worked out.  Can you send me a VSA bin that works and quick
> instructions for putting it into my build.  I'll pull out my eval
> board and give it a test.

good point. Vesa is working, but Ollie has the modules. We'll try to get 
those to you tomorrow.

We're doing very minimal usage of VSA, with luck tending to 0 over time. 
We mainly use the vas init stuff and SYSMGR, and we only use SYSMGR so 
we can get pci config cycles.

thanks

ron



From smithbone at gmail.com  Mon Apr 24 03:11:49 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 20:11:49 -0500
Subject: [LinuxBIOS] GX2 status
In-Reply-To: <444C1D78.4000901@lanl.gov>
References: <444C1427.4020508@lanl.gov>
	<8a0c36780604231716x4832dcb7p72325189d23e832f@mail.gmail.com>
	<444C1D78.4000901@lanl.gov>
Message-ID: <8a0c36780604231811p5684a84bkcdf413196c45ee88@mail.gmail.com>

> We're doing very minimal usage of VSA, with luck tending to 0 over time.
> We mainly use the vas init stuff and SYSMGR, and we only use SYSMGR so
> we can get pci config cycles.

Good plan.  The inclusion of yet another hunk of 16-bit binary code in
to the mix doesn't seem like a good long-term plan.  We have enough
trouble with the VGA binaries.

--
Richard A. Smith



From rminnich at lanl.gov  Mon Apr 24 03:09:10 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 23 Apr 2006 19:09:10 -0600
Subject: [LinuxBIOS] GX2 status
In-Reply-To: <8a0c36780604231811p5684a84bkcdf413196c45ee88@mail.gmail.com>
References: <444C1427.4020508@lanl.gov>	
	<8a0c36780604231716x4832dcb7p72325189d23e832f@mail.gmail.com>	
	<444C1D78.4000901@lanl.gov>
	<8a0c36780604231811p5684a84bkcdf413196c45ee88@mail.gmail.com>
Message-ID: <444C2536.9060004@lanl.gov>

Richard Smith wrote:

> Good plan.  The inclusion of yet another hunk of 16-bit binary code in
> to the mix doesn't seem like a good long-term plan.  We have enough
> trouble with the VGA binaries.

we did confirm during our discussions last week that there is nothing in 
principle that disallows SMI in 32-bit mode. So we could do the same 
trick we do for vgabios, where we pop into 32 bit from 16 bit mode (yes, 
I wrote that correctly!) and back to 16-bit mode for returning from SMI.

The better option is to write adapters for linuxbios and linux that use 
the GX2 MSRs directly and don't try to use 0xcfc/0xcf8 for PCI 
enumeration etc. But we'd have to convince linux, plan 9, bsd, etc. to 
pick this up ... that's definitely a longer-term issue. But I do think 
that, in the long run, we don't absolutely have to have vsa and SMI Int 
at all.

ron



From smithbone at gmail.com  Mon Apr 24 03:21:33 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 23 Apr 2006 20:21:33 -0500
Subject: [LinuxBIOS] Epia ML 5000 progress (sort of)
In-Reply-To: <444B07F2.3080605@zyxod.com>
References: <44485812.8070409@zyxod.com> <444B07F2.3080605@zyxod.com>
Message-ID: <8a0c36780604231821n6e7ee6f5x52627c90884bdaab@mail.gmail.com>

> Also:
>
> [The supposition I make below is wrong.  The VT 8623 and CLE266_VGA are
> different.  When I changed the PCI_DEVICE_ID_VIA_8623 to
> PCI_DEVICE_ID_VIA_CLE266_VGA in the struct, LB did not work.]

Search the archives.  People have booted the ML with existing setups. 
That's probally  why no ML directory was ever created.  They just
tweaked the M setup.  You will have to go back and find what those
tweaks were.

--
Richard A. Smith



From smithbone at gmail.com  Mon Apr 24 08:12:11 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 24 Apr 2006 01:12:11 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444BFA5A.3020106@suehsi.de>
References: <44495022.2060505@suehsi.de> <444BACBF.5090005@suehsi.de>
	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>
	<444BB7FB.8040806@suehsi.de>
	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>
	<444BC40F.9010904@suehsi.de>
	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>
	<444BEC7D.3010806@suehsi.de>
	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444BFA5A.3020106@suehsi.de>
Message-ID: <8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>

> Done reading resources.
>  first onboard = PCI: 00:09.0
>  Skipping disabled device PNP: 002e.3
>  Skipping disabled device PCI: 00:12.1
>  Skipping disabled device PCI: 00:12.3
>  Skipping disabled device PCI: 00:12.4
>  vga_first = PCI: 00:12.4
>  vga = PCI: 00:12.4
>  Looking at vga_onboard
>  Reassigning vga to PCI: 00:12.4
> Allocating VGA resource PCI: 00:09.0

I dont understand yet whats happening.. dev 12.4 should never get
consider since  its disabled.  It ended up doing the right thing and
enabling 9.0 but I don't know how 12.4 made it in there.

Will you please add the following at line 387 in device.c  Just before
the disable check.

printk_spew(" Looking at device %s\n",dev_path(dev));

--
Richard A. Smith



From chris at suehsi.de  Mon Apr 24 10:34:21 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 10:34:21 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
References: <44495022.2060505@suehsi.de>
	<444BACBF.5090005@suehsi.de>	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>	<444BB7FB.8040806@suehsi.de>	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>	<444BC40F.9010904@suehsi.de>	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>
	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
Message-ID: <444C8D8D.4040409@suehsi.de>


> 
> I dont understand yet whats happening.. dev 12.4 should never get
> consider since  its disabled.  It ended up doing the right thing and
> enabling 9.0 but I don't know how 12.4 made it in there.
>

I'm not sure, but I think it is the stepping in Config.lb


> Will you please add the following at line 387 in device.c  Just before
> the disable check.
>

Ok, I will also post my current Config.lb and my first one.

> printk_spew(" Looking at device %s\n",dev_path(dev));
> 
> --
> Richard A. Smith
> 




From chris at suehsi.de  Mon Apr 24 11:30:48 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 11:30:48 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
References: <44495022.2060505@suehsi.de>
	<444BACBF.5090005@suehsi.de>	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>	<444BB7FB.8040806@suehsi.de>	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>	<444BC40F.9010904@suehsi.de>	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>
	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
Message-ID: <444C9AC8.6050605@suehsi.de>

Next day, next runs ;)

Here are the results.
I've also attached two lspci outputs
Current LB and boot with factory bios

As I say before, PCI 12.4 comes never up before the VGA Tries starts.

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vga_try_5.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/27cd18d9/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Config-snippet.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/27cd18d9/attachment.txt>

From chris at suehsi.de  Mon Apr 24 11:47:13 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 11:47:13 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444C9AC8.6050605@suehsi.de>
References: <44495022.2060505@suehsi.de>	<444BACBF.5090005@suehsi.de>	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>	<444BB7FB.8040806@suehsi.de>	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>	<444BC40F.9010904@suehsi.de>	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
	<444C9AC8.6050605@suehsi.de>
Message-ID: <444C9EA1.8090604@suehsi.de>

Christian S?hs schrieb:
> Next day, next runs ;)
> 
> Here are the results.

What's that.
Why are the disabled devices first skipped and then look again?




> Looking at device PNP: 002e.7
>  Looking at device PNP: 002e.8
>  Looking at device PCI: 00:12.1
>  Skipping disabled device PCI: 00:12.1
>  Looking at device PCI: 00:12.2
>  Looking at device PCI: 00:12.3
>  Skipping disabled device PCI: 00:12.3
>  Looking at device PCI: 00:12.4
>  Skipping disabled device PCI: 00:12.4
>  Looking at device PCI: 00:12.1
>  Looking at device PCI: 00:12.2
>  Looking at device PCI: 00:12.3
>  Looking at device PCI: 00:12.4
>  vga_first = PCI: 00:12.4
>  Looking at device PCI: 00:13.0
>  vga = PCI: 00:12.4








From chris at suehsi.de  Mon Apr 24 12:32:10 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 12:32:10 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444C9AC8.6050605@suehsi.de>
References: <44495022.2060505@suehsi.de>
	<444BACBF.5090005@suehsi.de>	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>	<444BB7FB.8040806@suehsi.de>	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>	<444BC40F.9010904@suehsi.de>	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>
	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
	<444C9AC8.6050605@suehsi.de>
Message-ID: <444CA92A.7070505@suehsi.de>


>  Looking at vga_onboard
>  Reassigning vga to PCI: 00:12.4

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think this line is wrong,
the debug should be output the vga_onboard Variable,
but the output is vga.


----------------
#if 1
    	printk_spew(" Looking at vga_onboard\n");
	if (vga_onboard) // will use on board vga as pri
#else
	if (!vga) // will use last add on adapter as pri
#endif
	{
	  printk_spew(" Reassigning vga to %s\n",dev_path(vga)); // <--
	  vga = vga_onboard;
	}
-----------------

Therefor it seems, that in my case the right PCI Device is allocated.
the debug should printed out "Reassigning vga to PCI: 00:9.0

lspci is also this meaning :D
but what about the false memory region

chris



From chris at suehsi.de  Mon Apr 24 13:57:23 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 13:57:23 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444C9AC8.6050605@suehsi.de>
References: <44495022.2060505@suehsi.de>
	<444BACBF.5090005@suehsi.de>	<8a0c36780604230849w48fc1d6fr6f6fb95b1b4374df@mail.gmail.com>	<444BB7FB.8040806@suehsi.de>	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>	<444BC40F.9010904@suehsi.de>	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>
	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
	<444C9AC8.6050605@suehsi.de>
Message-ID: <444CBD23.6020405@suehsi.de>

Ok, I think the problem is here,

> 
> 00:12.4 0300: 1078:0104
> 	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Region 0: Memory at fe000000 (32-bit, non-prefetchable) [size=4K]
> 

For any reason the internal kalhua graphic is initialize
and get the RAM range with is needed for 00:9.0

The emulatur looks if I remember right on fe000000 for a rom signatur.
But there should be nothing or it fails, while IO is disabled for that 
device.

If I start testbios on 00:9.0 the console is coming up.

What now. How can I solve this.

chris



From stepan at coresystems.de  Mon Apr 24 12:49:50 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Apr 2006 12:49:50 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444CA92A.7070505@suehsi.de>
References: <444BB7FB.8040806@suehsi.de>
	<8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>
	<444BC40F.9010904@suehsi.de>
	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>
	<444BEC7D.3010806@suehsi.de>
	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444BFA5A.3020106@suehsi.de>
	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
	<444C9AC8.6050605@suehsi.de> <444CA92A.7070505@suehsi.de>
Message-ID: <20060424104950.GA24874@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060424 12:32]:
> 
> > Looking at vga_onboard
> > Reassigning vga to PCI: 00:12.4
> 
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I think this line is wrong,
> the debug should be output the vga_onboard Variable,
> but the output is vga.

good spot. 
LinuxBIOS does not detect the vga device as an onboard vga device. 

Lemme see..

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Mon Apr 24 13:11:10 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Apr 2006 13:11:10 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <20060424104950.GA24874@coresystems.de>
References: <8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>
	<444BC40F.9010904@suehsi.de>
	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>
	<444BEC7D.3010806@suehsi.de>
	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444BFA5A.3020106@suehsi.de>
	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
	<444C9AC8.6050605@suehsi.de> <444CA92A.7070505@suehsi.de>
	<20060424104950.GA24874@coresystems.de>
Message-ID: <20060424111110.GA28044@coresystems.de>

* Stefan Reinauer <stepan at coresystems.de> [060424 12:49]:
> > the debug should be output the vga_onboard Variable,
> > but the output is vga.
> 
> good spot. 
> LinuxBIOS does not detect the vga device as an onboard vga device. 

Can you apply the attached patch and try again?

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
-------------- next part --------------
Index: src/northbridge/amd/gx1/northbridge.c
===================================================================
--- src/northbridge/amd/gx1/northbridge.c	(revision 2273)
+++ src/northbridge/amd/gx1/northbridge.c	(working copy)
@@ -211,3 +211,32 @@
 	CHIP_NAME("AMD GX1 Northbridge")
 	.enable_dev = enable_dev, 
 };
+
+// This is currently only activated for the 
+// Cyrix Corporation 5530 Video [Kahlua]
+// Question: Are other GX1 systems equipped 
+// with other VGA chips (or do they have other
+// PCI IDs?)
+
+static void vga_read_resources(device_t dev)
+{
+	// dev->rom_address = (void *)0xfffc0000;
+	dev->on_mainboard=1;
+	pci_dev_read_resources(dev);
+}
+
+static struct device_operations vga_operations = {
+	.read_resources   = vga_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = pci_dev_init,
+	.ops_pci          = 0,
+};
+
+static struct pci_driver vga_driver __pci_driver = {
+	.ops = &vga_operations,
+	.vendor = 0x1078,
+	.device = 0x0104,
+};
+
+

From chris at suehsi.de  Mon Apr 24 15:33:03 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 15:33:03 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <20060424111110.GA28044@coresystems.de>
References: <8a0c36780604230936v72ca965ar9024eb31a8e40561@mail.gmail.com>	<444BC40F.9010904@suehsi.de>	<8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>	<444C9AC8.6050605@suehsi.de>
	<444CA92A.7070505@suehsi.de>	<20060424104950.GA24874@coresystems.de>
	<20060424111110.GA28044@coresystems.de>
Message-ID: <444CD38F.5090502@suehsi.de>


> 
> Can you apply the attached patch and try again?
> 
> Stefan

Well, here is the debug.

Now, the Kalhua is detect as onboard vga and assigned.
( That is not what I want :) )
lspci output is a little bit different.
Both vga devices have no enabled IO Range.

chris

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vga_try_7.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/94ee4fb8/attachment.ksh>

From stepan at coresystems.de  Mon Apr 24 14:28:26 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Apr 2006 14:28:26 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444CD38F.5090502@suehsi.de>
References: <8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>
	<444BEC7D.3010806@suehsi.de>
	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444BFA5A.3020106@suehsi.de>
	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
	<444C9AC8.6050605@suehsi.de> <444CA92A.7070505@suehsi.de>
	<20060424104950.GA24874@coresystems.de>
	<20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de>
Message-ID: <20060424122826.GA4308@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060424 15:33]:
> Now, the Kalhua is detect as onboard vga and assigned.
> ( That is not what I want :) )

So what is it you want, then? ;)





From chris at suehsi.de  Mon Apr 24 15:56:34 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 15:56:34 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <20060424122826.GA4308@coresystems.de>
References: <8a0c36780604231204t2c57cc0dt1d2f7f4d2841bfd9@mail.gmail.com>	<444BEC7D.3010806@suehsi.de>	<8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>	<444C9AC8.6050605@suehsi.de>
	<444CA92A.7070505@suehsi.de>	<20060424104950.GA24874@coresystems.de>	<20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de>
Message-ID: <444CD912.20607@suehsi.de>

Stefan Reinauer schrieb:
> * Christian S?hs <chris at suehsi.de> [060424 15:33]:
> 
>>Now, the Kalhua is detect as onboard vga and assigned.
>>( That is not what I want :) )
> 
> 
> So what is it you want, then? ;)
> 
> 
> 


I want, that the Kalhua is totally ignored.
Because I don't need that item.
I will now try my first Config.lb
Then PCI 0:9.0 should be detect after the 0:12.4 and set as onboard vga.
( I hope so )

I think the problem is the meaning of "onboard"

Ok, both chips are onboard, but the cyperpro I think is more like a 
addon pci card integrated onboard ;)
Also this chip has its own memory onboard and shares not the RAM

chris





From stepan at coresystems.de  Mon Apr 24 14:42:36 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Apr 2006 14:42:36 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444CD912.20607@suehsi.de>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444BFA5A.3020106@suehsi.de>
	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>
	<444C9AC8.6050605@suehsi.de> <444CA92A.7070505@suehsi.de>
	<20060424104950.GA24874@coresystems.de>
	<20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de> <20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de>
Message-ID: <20060424124236.GA9541@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060424 15:56]:
> I want, that the Kalhua is totally ignored.
> Because I don't need that item.
> I will now try my first Config.lb
> Then PCI 0:9.0 should be detect after the 0:12.4 and set as onboard vga.
> ( I hope so )
> 
> I think the problem is the meaning of "onboard"
> 
> Ok, both chips are onboard, but the cyperpro I think is more like a 
> addon pci card integrated onboard ;)
> Also this chip has its own memory onboard and shares not the RAM

Aaah :-)) I see.

Well, try changing the PCI ID in the last patch to that of the
cyberpro..

Stefan


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Mon Apr 24 16:57:44 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 16:57:44 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <20060424124236.GA9541@coresystems.de>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>	<444C9AC8.6050605@suehsi.de>
	<444CA92A.7070505@suehsi.de>	<20060424104950.GA24874@coresystems.de>	<20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de>
Message-ID: <444CE768.1010606@suehsi.de>


> 
> Aaah :-)) I see.
> 
> Well, try changing the PCI ID in the last patch to that of the
> cyberpro..
>

Yep, but it is alwalys the same.
Wether the right device is allocated, but has the wrong or not enabled IO

or the false device is alocated.
both have the same result --> no vga output.

I need a proper posted vga with romem on fe000000
the best I get is a not-posted 09.0 with romem on fe000000

but this is not enough :D , because the init fails later with a bad 
signatur on fe000000

The Problem is the kalhua, which comes up and is initialized.
Is there any way to stop this.

chris
> Stefan
> 
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vga_try_8.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/e1a721ea/attachment.ksh>

From chris at suehsi.de  Mon Apr 24 17:12:22 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 17:12:22 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444CE768.1010606@suehsi.de>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>	<444C9AC8.6050605@suehsi.de>	<444CA92A.7070505@suehsi.de>	<20060424104950.GA24874@coresystems.de>	<20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>	<20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de>
Message-ID: <444CEAD6.3070901@suehsi.de>

However,

look here:

>  vga_first = PCI: 00:09.0

Thats good!

>  Looking at device PCI: 00:12.1
>  Looking at device PCI: 00:12.2
>  Looking at device PCI: 00:12.3
>  Looking at device PCI: 00:12.4

Why on hell does this happens?

>  last onboard = PCI: 00:12.4
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This comes with the not changed patch
It Should be vga_first = PCI 12.4
last onboard = PCI 9.0

or only one onboard device


>  Looking at device PCI: 00:13.0
>  vga = PCI: 00:09.0
>  Looking at vga_onboard
>  Yes: PCI: 00:12.4
>  Reassigning vga to PCI: 00:12.4

Waaaaaaaaah!? Ok, the old patch.

> Root Device read_resources bus 0 link: 0 done
> PCI: 00:09.0 10 *  [0xfd000000 - 0xfdffffff] mem
> PCI: 00:09.0 30 *  [0xfe000000 - 0xfe00ffff] mem

Yeahhhhh, thats good

> PCI: 00:12.4 10 *  [0xfe010000 - 0xfe010fff] mem

> PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
> PCI: 00:09.0 10 <- [0x00fd000000 - 0x00fdffffff] mem
> PCI: 00:09.0 30 <- [0x00fe000000 - 0x00fe00ffff] romem
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here is the needed IO Range

> PCI: 00:12.1 10 <- [0x00fe012000 - 0x00fe0120ff] mem
> PCI: 00:12.2 20 <- [0x0000001000 - 0x000000107f] io
> PCI: 00:12.3 10 <- [0x00fe013000 - 0x00fe01307f] mem
> PCI: 00:12.4 10 <- [0x00fe010000 - 0x00fe010fff] mem
> PCI: 00:13.0 10 <- [0x00fe011000 - 0x00fe011fff] mem

> PCI: 00:09.0 init
> rom address for PCI: 00:09.0 = fe000000
> PCI Expansion ROM, signature 0x0202, INIT size 0x0400, data ptr 0x0202
> Incorrect Expansion ROM Header Signature 0202
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well, the false vga device was allocated

> 00:09.0 0300: 10ea:5000 (rev 02)
> 	Subsystem: 0202:0202
         ^^^^^^^^^^^^^^^^^^^^^
         Is 0280:7000 with factory bios

> 	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
                  ^^^^
                   Why not?
> 	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Interrupt: pin A routed to IRQ 0
> 	Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
> 	Expansion ROM at fe000000 [disabled] [size=64K]
> 
> 
> 
> 00:12.4 0300: 1078:0104
  ^^^^^^^^^^^^^^^^^^^^^^^^^
  Damn, I can't see this longer :D

> 	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Region 0: Memory at fe010000 (32-bit, non-prefetchable) [size=4K]
> 




From chris at suehsi.de  Mon Apr 24 17:20:05 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 17:20:05 +0200
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444CEAD6.3070901@suehsi.de>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>	<444C9AC8.6050605@suehsi.de>	<444CA92A.7070505@suehsi.de>	<20060424104950.GA24874@coresystems.de>	<20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>	<20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
Message-ID: <444CECA5.7030909@suehsi.de>

Here is the output with changed patch. vendor/device ID to cyberpro.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vga_try_10.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/398a5959/attachment.ksh>

From eric at zyxod.com  Mon Apr 24 17:48:50 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Mon, 24 Apr 2006 08:48:50 -0700
Subject: [LinuxBIOS] Extraction of vga bios from .BIN file?
Message-ID: <444CF362.5040505@zyxod.com>

I've downloaded the 1.13 version of the Epia Via BIOS, which should 
solve my VGA issues.  Thing is, I can't seem to find a valid VGA BIOS 
within this file -- Is there a magic trick to extracting this?

Bios file:
http://www.via.com.tw/download/mainboards/1/0/i0100113.bin



From chris at suehsi.de  Mon Apr 24 19:15:27 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 19:15:27 +0200
Subject: [LinuxBIOS] Extraction of vga bios from .BIN file?
In-Reply-To: <444CF362.5040505@zyxod.com>
References: <444CF362.5040505@zyxod.com>
Message-ID: <444D07AF.3040809@suehsi.de>

Eric Poulsen schrieb:
> I've downloaded the 1.13 version of the Epia Via BIOS, which should 
> solve my VGA issues.  Thing is, I can't seem to find a valid VGA BIOS 
> within this file -- Is there a magic trick to extracting this?
> 
> Bios file:
> http://www.via.com.tw/download/mainboards/1/0/i0100113.bin
> 
There are a lot of tools to do this.
search for "awardeco" for linux
or awardedit, cbrom, ie for DOS, Windoof



From smithbone at gmail.com  Mon Apr 24 18:04:02 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 24 Apr 2006 11:04:02 -0500
Subject: [LinuxBIOS] Extraction of vga bios from .BIN file?
In-Reply-To: <444CF362.5040505@zyxod.com>
References: <444CF362.5040505@zyxod.com>
Message-ID: <8a0c36780604240904v17fd4da1rc57c75f798403537@mail.gmail.com>

On 4/24/06, Eric Poulsen <eric at zyxod.com> wrote:
> I've downloaded the 1.13 version of the Epia Via BIOS, which should
> solve my VGA issues.  Thing is, I can't seem to find a valid VGA BIOS
> within this file -- Is there a magic trick to extracting this?
>
> Bios file:
> http://www.via.com.tw/download/mainboards/1/0/i0100113.bin

A lot of times the factory bios stuff is compressed.

You will probally have to boot under factory and use dd to extract. 
Somewhere there were some tools for various mfgs that would extract
the image.  Check the archives.  If you find one for via then we
should list them on the wiki.

--
Richard A. Smith



From chris at suehsi.de  Mon Apr 24 19:48:52 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 19:48:52 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444CEAD6.3070901@suehsi.de>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<444BFA5A.3020106@suehsi.de>	<8a0c36780604232312j14489f5fj57ca0322f83d4d16@mail.gmail.com>	<444C9AC8.6050605@suehsi.de>	<444CA92A.7070505@suehsi.de>	<20060424104950.GA24874@coresystems.de>	<20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>	<20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
Message-ID: <444D0F84.3060004@suehsi.de>


Look to the attachment,
but Lb stops on emulate vga :(

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vga_try_13.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/5d797fc6/attachment.ksh>

From smithbone at gmail.com  Mon Apr 24 18:42:52 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 24 Apr 2006 11:42:52 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <444CECA5.7030909@suehsi.de>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<20060424104950.GA24874@coresystems.de>
	<20060424111110.GA28044@coresystems.de> <444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de> <444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de> <444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de> <444CECA5.7030909@suehsi.de>
Message-ID: <8a0c36780604240942m132ce454pbd73a50ef6f09f1f@mail.gmail.com>

On 4/24/06, Christian S?hs <chris at suehsi.de> wrote:
> Here is the output with changed patch. vendor/device ID to cyberpro.
>

I think I am beginning to see what's happening here device 12.4 seems
to have mutiple entries in the device tree.

I've not looked at the pci enum stuff so I don't quite understand what
is going on but looking at the log I see.. (I've sniped it down a bit)

> PCI_DOMAIN: 0000 enabled
> PCI_DOMAIN: 0000 scanning...
> PCI: pci_scan_bus for bus 0
> PCI: 00:00.0 [1078/0001] ops
> PCI: 00:00.0 [1078/0001] enabled
> PCI: 00:09.0 [10ea/5000] ops
> PCI: 00:09.0 [10ea/5000] enabled
> PCI: 00:12.0 [1078/0100] bus ops

Notice that it detected the southbrige with 'bus' ops

> southbridge_enable: dev is 00018900
> PCI: 00:12.0 [1078/0100] enabled
> malloc Enter, size 668, free_mem_ptr 00022000
> malloc 0x00022000
> PCI: 00:12.1 [1078/0101] enabled
> malloc Enter, size 668, free_mem_ptr 0002229c
> malloc 0x0002229c
> PCI: 00:12.2 [1078/0102] ops
> cs5530_ide: ide_enable
> PCI: 00:12.2 [1078/0102] enabled
> malloc Enter, size 668, free_mem_ptr 00022538
> malloc 0x00022538
> PCI: 00:12.3 [1078/0103] enabled
> malloc Enter, size 668, free_mem_ptr 000227d4
> malloc 0x000227d4
> PCI: 00:12.4 [1078/0104] enabled

So here is entry #1 and it has the device enabled.

> malloc Enter, size 668, free_mem_ptr 00022a70
> malloc 0x00022a70
> PCI: 00:13.0 [0e11/a0f8] enabled

Now we move into another scan of just the 12.x devices

> scan_static_bus for PCI: 00:12.0
> PNP: 002e.0 enabled
> PNP: 002e.1 enabled
> PNP: 002e.2 enabled
> PNP: 002e.3 disabled
> PNP: 002e.4 enabled
> PNP: 002e.5 enabled
> PNP: 002e.6 enabled
> PNP: 002e.7 enabled
> PNP: 002e.8 enabled
> PCI: 00:12.1 disabled
> PCI: 00:12.2 enabled
> PCI: 00:12.3 disabled
> PCI: 00:12.4 disabled
> scan_static_bus for PCI: 00:12.0 done
> PCI: pci_scan_bus returning with max=00
> scan_static_bus for Root Device done

So according to all this 12.4 is in the tree twice once as enabled and
once as disabled.  Which is what we see later on when doing then VGA
resource allocation.

Most of this code was doen by Eric B.  I've added him to the To: list
since I don't think he follows the LB list very closely anymore.

Eric:

I know you are a busy man and coming in on this cold but perhaps you
can shed some light on this?  Chris is trying to set up another board
based on the eaglelion/5bcm board but his board has an additional VGA
device at 9.0 and he wants that device to show up as the primary
device.  We have 12.4 marked as "off" in the Options.lb but its still
getting picked and assiged to the VGA resource.

The gory details should be on the list under this thread.

--
Richard A. Smith



From smithbone at gmail.com  Mon Apr 24 18:47:38 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 24 Apr 2006 11:47:38 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444D0F84.3060004@suehsi.de>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<20060424104950.GA24874@coresystems.de>
	<20060424111110.GA28044@coresystems.de> <444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de> <444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de> <444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de> <444D0F84.3060004@suehsi.de>
Message-ID: <8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>

> PCI: 00:09.0 init
> rom address for PCI: 00:09.0 = fffc0000
> PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x0031
> PCI ROM Image, Vendor 10ea, Device 5000,
> PCI ROM Image,  Class Code 030000, Code Type 00
> copying VGA ROM Image from fffc0000 to c0000, 8000 bytes
> entering emulator

So what did you do?

--
Richard A. Smith



From borg_no.one at gmx.net  Mon Apr 24 19:00:29 2006
From: borg_no.one at gmx.net (Borg No. One)
Date: Mon, 24 Apr 2006 19:00:29 +0200 (MEST)
Subject: [LinuxBIOS] Extraction of vga bios from .BIN file?
References: <mailman.1646.1145894652.9611.linuxbios@linuxbios.org>
Message-ID: <4848.1145898029@www047.gmx.net>

Hi.


The VIA EPIA BIOS is an Award/Phoenix Award BIOS, so it contains lh5/lha
compressed modules.
With a hex editor and/or lha/lh5 unpacker you can extract the VGABIOS from
the VIA EPIA BIOS file.

Using "CBROM"/"CBROM32"/"Award BIOS Editor"/..., you can see that the BIOS
file contains following BIOS modules:


CBROM32 V1.45 [08/03/04 Release] (C)Phoenix Technologies 2001-2004

              ******** i0100113.bin BIOS component ********

 No. Item-Name         Original-Size   Compressed-Size Original-File-Name
=========================================================================
  0. System BIOS       20000h(128.00K)  12B3Fh(74.81K)  i0100113.BIN
  1. XGROUP CODE       0ACE0h(43.22K)   079D2h(30.46K)  awardext.rom
  2. ACPI table        030B9h(12.18K)   01408h(5.01K)   ACPITBL.BIN
  3. EPA LOGO          0168Ch(5.64K)    002AAh(0.67K)   AwardBmp.bmp
  4. GROUP ROM[ 0]     054D0h(21.20K)   025DEh(9.47K)   _EN_CODE.BIN
  5. YGROUP ROM        04AA0h(18.66K)   031DFh(12.47K)  awardeyt.rom
  6. LOGO BitMap       4B30Ch(300.76K)  02ECBh(11.70K)  vpsd.bmp
  7. VGA ROM[1]        0FA00h(62.50K)   0947Ah(37.12K)  MVPSD_15.rom
  8. PCI ROM[A]        0A000h(40.00K)   05FF2h(23.99K)  pxe.lom

  Total compress code space  = 35000h(212.00K)
  Total compressed code size = 336B7h(205.68K)
  Remain compress code space = 01949h(6.32K)

                          ** Micro Code Information **
Update ID  CPUID|  Update ID  CPUID|  Update ID  CPUID|  Update ID  CPUID
----------------+------------------+------------------+------------------
SLOT1  13   0630|


If you should use "CBROM", then just use following command to extract the
VGA BIOS:

"CBROM i0100113.bin /VGA extract"



PS:
... the VIA EPIA has a nice BIOS logo. ;)

http://bnobtc.pix-art.com/images/bioslogo
-->
via_vpsd.png

> I've downloaded the 1.13 version of the Epia Via BIOS, which should 
> solve my VGA issues.  Thing is, I can't seem to find a valid VGA BIOS 
> within this file -- Is there a magic trick to extracting this?
> 
> Bios file:
> http://www.via.com.tw/download/mainboards/1/0/i0100113.bin

-- 
Echte DSL-Flatrate dauerhaft f?r 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl



From chris at suehsi.de  Mon Apr 24 20:49:18 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 20:49:18 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com> 
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	
	<20060424104950.GA24874@coresystems.de>	
	<20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de>	
	<20060424122826.GA4308@coresystems.de> <444CD912.20607@suehsi.de>	
	<20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de>	 <444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com> 
Message-ID: <444D1DAE.8080100@suehsi.de>

Christian S?hs schrieb:
>

>> So what did you do?

good question ;)

I have removed stefan's patch.

but I think, later it is important to have this stuff.
However,
than I have played around with the config.lb
It seems to be very Important where the entry is located in that file.

Currently I have had a lot of tries with different locations.
for the device entries.




I get the same, If I insert the vga entry after the chip soutbridge line
If I insert the entry after the device 12.0
LB boots as before with false rom signatur.

Next I will try a vga.bios get with dd
Currently I use an extracted one.

Both vga.bios starts with testbios but
It is a try :D

This is the version, were the emulatur tries to bring up vga.
  ------------------------------------------------------------------------


  ##
  ## Include the secondary Configuration files
  ##
  dir /pc80
  config chip.h

  chip northbridge/amd/gx1
    device pci_domain 0 on
      device pci 0.0 on end
#       device pci 9.0 on			// Is this on the right place ??
  	chip drivers/pci/onboard	// first it was at the end of the file
  	    device pci 9.0 on end
  	    register "rom_address" = "0xfffc0000"
  	end
#     end
        chip southbridge/amd/cs5530
          device pci 12.0 on
----------------------------------------------------------------------




From eric at zyxod.com  Mon Apr 24 19:35:55 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Mon, 24 Apr 2006 10:35:55 -0700
Subject: [LinuxBIOS] Extraction of vga bios from .BIN file?
In-Reply-To: <4848.1145898029@www047.gmx.net>
References: <mailman.1646.1145894652.9611.linuxbios@linuxbios.org>
	<4848.1145898029@www047.gmx.net>
Message-ID: <444D0C7B.20902@zyxod.com>

Okay,

I tried awardeco, and it DOES NOT list the VGA ROM, but CBROM (under the 
"dosbox" emulator) worked well.

Only one thing -- the extracted VGA ROM is _exactly_ 64000 bytes 
(instead of 65536) -- do I need to pad it out (with zeros?) before 
concatenating it with LinuxBIOS to achieve the final burnable image?



Borg No. One wrote:
> Hi.
>
>
> The VIA EPIA BIOS is an Award/Phoenix Award BIOS, so it contains lh5/lha
> compressed modules.
> With a hex editor and/or lha/lh5 unpacker you can extract the VGABIOS from
> the VIA EPIA BIOS file.
>
> Using "CBROM"/"CBROM32"/"Award BIOS Editor"/..., you can see that the BIOS
> file contains following BIOS modules:
>
>
> CBROM32 V1.45 [08/03/04 Release] (C)Phoenix Technologies 2001-2004
>
>               ******** i0100113.bin BIOS component ********
>
>  No. Item-Name         Original-Size   Compressed-Size Original-File-Name
> =========================================================================
>   0. System BIOS       20000h(128.00K)  12B3Fh(74.81K)  i0100113.BIN
>   1. XGROUP CODE       0ACE0h(43.22K)   079D2h(30.46K)  awardext.rom
>   2. ACPI table        030B9h(12.18K)   01408h(5.01K)   ACPITBL.BIN
>   3. EPA LOGO          0168Ch(5.64K)    002AAh(0.67K)   AwardBmp.bmp
>   4. GROUP ROM[ 0]     054D0h(21.20K)   025DEh(9.47K)   _EN_CODE.BIN
>   5. YGROUP ROM        04AA0h(18.66K)   031DFh(12.47K)  awardeyt.rom
>   6. LOGO BitMap       4B30Ch(300.76K)  02ECBh(11.70K)  vpsd.bmp
>   7. VGA ROM[1]        0FA00h(62.50K)   0947Ah(37.12K)  MVPSD_15.rom
>   8. PCI ROM[A]        0A000h(40.00K)   05FF2h(23.99K)  pxe.lom
>
>   Total compress code space  = 35000h(212.00K)
>   Total compressed code size = 336B7h(205.68K)
>   Remain compress code space = 01949h(6.32K)
>
>                           ** Micro Code Information **
> Update ID  CPUID|  Update ID  CPUID|  Update ID  CPUID|  Update ID  CPUID
> ----------------+------------------+------------------+------------------
> SLOT1  13   0630|
>
>
> If you should use "CBROM", then just use following command to extract the
> VGA BIOS:
>
> "CBROM i0100113.bin /VGA extract"
>
>
>
> PS:
> ... the VIA EPIA has a nice BIOS logo. ;)
>
> http://bnobtc.pix-art.com/images/bioslogo
> -->
> via_vpsd.png
>
>   
>> I've downloaded the 1.13 version of the Epia Via BIOS, which should 
>> solve my VGA issues.  Thing is, I can't seem to find a valid VGA BIOS 
>> within this file -- Is there a magic trick to extracting this?
>>
>> Bios file:
>> http://www.via.com.tw/download/mainboards/1/0/i0100113.bin
>>     
>
>   




From stepan at coresystems.de  Mon Apr 24 20:33:03 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Apr 2006 20:33:03 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444D1DAE.8080100@suehsi.de>
References: <20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de> <20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de> <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D1DAE.8080100@suehsi.de>
Message-ID: <20060424183303.GA18751@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060424 20:49]:
> Currently I have had a lot of tries with different locations.
> for the device entries.
 
> This is the version, were the emulatur tries to bring up vga.

can you post all of the Config.lb file please?

S.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Mon Apr 24 22:03:03 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 22:03:03 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060424183303.GA18751@coresystems.de>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D1DAE.8080100@suehsi.de>
	<20060424183303.GA18751@coresystems.de>
Message-ID: <444D2EF7.1030906@suehsi.de>


> 
> 
> can you post all of the Config.lb file please?
> 
> S.
> 

Sure
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Config.lb
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/2849461f/attachment.ksh>

From rminnich at lanl.gov  Mon Apr 24 20:41:20 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 24 Apr 2006 12:41:20 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060424183303.GA18751@coresystems.de>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D1DAE.8080100@suehsi.de>
	<20060424183303.GA18751@coresystems.de>
Message-ID: <444D1BD0.5030604@lanl.gov>

Stefan Reinauer wrote:
> * Christian S?hs <chris at suehsi.de> [060424 20:49]:
> 
>>Currently I have had a lot of tries with different locations.
>>for the device entries.
> 
>  
> 
>>This is the version, were the emulatur tries to bring up vga.
> 
> 
> can you post all of the Config.lb file please?
> 


I think we also need the static.c that is output.

ron



From chris at suehsi.de  Mon Apr 24 22:18:22 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 22:18:22 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444D1BD0.5030604@lanl.gov>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D1DAE.8080100@suehsi.de>	<20060424183303.GA18751@coresystems.de>
	<444D1BD0.5030604@lanl.gov>
Message-ID: <444D328E.2060309@suehsi.de>


> I think we also need the static.c that is output.
> 
> ron
> 

Ok,
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: static.c
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/104e011d/attachment.c>

From smithbone at gmail.com  Mon Apr 24 21:31:59 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 24 Apr 2006 14:31:59 -0500
Subject: [LinuxBIOS] Extraction of vga bios from .BIN file?
In-Reply-To: <444D0C7B.20902@zyxod.com>
References: <mailman.1646.1145894652.9611.linuxbios@linuxbios.org>
	<4848.1145898029@www047.gmx.net> <444D0C7B.20902@zyxod.com>
Message-ID: <8a0c36780604241231n2ff93e9al970651128ff4c1b9@mail.gmail.com>

On 4/24/06, Eric Poulsen <eric at zyxod.com> wrote:

> Okay,
>
> I tried awardeco, and it DOES NOT list the VGA ROM, but CBROM (under the
> "dosbox" emulator) worked well.

Please keep track of your procedure,  what tools worked and didn't
work, where you got them from, etc so we can put it on the wiki.

> Only one thing -- the extracted VGA ROM is _exactly_ 64000 bytes
> (instead of 65536) -- do I need to pad it out (with zeros?) before
> concatenating it with LinuxBIOS to achieve the final burnable image?

Yes. dd can snap it to the right size for you.  You could also tweak
your ROM_SIZE to make it match.

--
Richard A. Smith



From chris at suehsi.de  Mon Apr 24 23:07:19 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 24 Apr 2006 23:07:19 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<20060424104950.GA24874@coresystems.de>	<20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de>	<20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de>	<20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
Message-ID: <444D3E07.6010209@suehsi.de>

Richard Smith schrieb:
>>PCI: 00:09.0 init
>>rom address for PCI: 00:09.0 = fffc0000
>>PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x0031
>>PCI ROM Image, Vendor 10ea, Device 5000,
>>PCI ROM Image,  Class Code 030000, Code Type 00
>>copying VGA ROM Image from fffc0000 to c0000, 8000 bytes
>>entering emulator


Other question:
All seems to look fine!?

What could be the reason for fail.

The call comes very first at initializing ( I think before the 
northbridge is init)

I have tried to init it later but thats results in a not proper posted 
vga device.

chris



From eric at zyxod.com  Mon Apr 24 21:59:41 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Mon, 24 Apr 2006 12:59:41 -0700
Subject: [LinuxBIOS] Extraction of vga bios from .BIN file?
In-Reply-To: <8a0c36780604241231n2ff93e9al970651128ff4c1b9@mail.gmail.com>
References: <mailman.1646.1145894652.9611.linuxbios@linuxbios.org>	
	<4848.1145898029@www047.gmx.net> <444D0C7B.20902@zyxod.com>
	<8a0c36780604241231n2ff93e9al970651128ff4c1b9@mail.gmail.com>
Message-ID: <444D2E2D.3020403@zyxod.com>

Richard Smith wrote:
> On 4/24/06, Eric Poulsen <eric at zyxod.com> wrote:
>
>   
>> Okay,
>>
>> I tried awardeco, and it DOES NOT list the VGA ROM, but CBROM (under the
>> "dosbox" emulator) worked well.
>>     
>
> Please keep track of your procedure,  what tools worked and didn't
> work, where you got them from, etc so we can put it on the wiki.
>   
I've done a LOT of things, but they mostly didn't work =)

When this is all over, I'll write up a set of instructions, and follow 
them from a clean install to see if I've got it all down.

>   
>> Only one thing -- the extracted VGA ROM is _exactly_ 64000 bytes
>> (instead of 65536) -- do I need to pad it out (with zeros?) before
>> concatenating it with LinuxBIOS to achieve the final burnable image?
>>     
>
> Yes. dd can snap it to the right size for you.  You could also tweak
> your ROM_SIZE to make it match.
>   
I've got the VGA extracted -- I'll burn it tonight and see what happens.

Assumedly:

dd if=vga.bios.bin of=vga.bios.bin.padded bs=65536 count=1 conv=sync

> --
> Richard A. Smith
>
>   




From stepan at coresystems.de  Mon Apr 24 22:10:07 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Apr 2006 22:10:07 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444D3E07.6010209@suehsi.de>
References: <20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de> <20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de> <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D3E07.6010209@suehsi.de>
Message-ID: <20060424201007.GA32112@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060424 23:07]:
> Other question:
> All seems to look fine!?
> 
> What could be the reason for fail.

check LinuxBIOSv2/src/devices/emulator/biosemu.c:

Enable this line (116) by removing the // 
// printk_debug("int%x vector at %x\n", num, getIntVect(num));
 

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Mon Apr 24 22:27:20 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 24 Apr 2006 15:27:20 -0500
Subject: [LinuxBIOS] Extraction of vga bios from .BIN file?
In-Reply-To: <444D2E2D.3020403@zyxod.com>
References: <mailman.1646.1145894652.9611.linuxbios@linuxbios.org>
	<4848.1145898029@www047.gmx.net> <444D0C7B.20902@zyxod.com>
	<8a0c36780604241231n2ff93e9al970651128ff4c1b9@mail.gmail.com>
	<444D2E2D.3020403@zyxod.com>
Message-ID: <8a0c36780604241327t3437a015la274899d350e9e78@mail.gmail.com>

> > Please keep track of your procedure,  what tools worked and didn't
> > work, where you got them from, etc so we can put it on the wiki.
> >
> I've done a LOT of things, but they mostly didn't work =)

:)

> When this is all over, I'll write up a set of instructions, and follow
> them from a clean install to see if I've got it all down.

Thanks.

> Assumedly:
>
> dd if=vga.bios.bin of=vga.bios.bin.padded bs=65536 count=1 conv=sync
>

yep. Thats it.

--
Richard A. Smith



From eric at zyxod.com  Mon Apr 24 22:37:28 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Mon, 24 Apr 2006 13:37:28 -0700
Subject: [LinuxBIOS] Strange code in src/northbridge/via/vt8623/raminit.c ?
Message-ID: <444D3708.1020907@zyxod.com>

While poking around trying to get VGA working, I did a grep for '3123', 
and I found this.  Notice how the variable 'north' is assigned to the 
result of the 'pci_locate_device' call, then immediately re-assigned to 
zero ... and then used.  Is this correct?


static void ddr_ram_setup(const struct mem_controller *ctrl)
{
  device_t north = (device_t) 0;
  uint8_t b, c, bank;
  uint16_t i,j;
  unsigned long bank_address;

  print_debug("vt8623 init starting\r\n");
  north = pci_locate_device(PCI_ID(0x1106, 0x3123), 0);
  north = 0;

  pci_write_config8(north,0x75,0x08);

...

}




From stepan at coresystems.de  Mon Apr 24 22:41:27 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 24 Apr 2006 22:41:27 +0200
Subject: [LinuxBIOS] Strange code in
	src/northbridge/via/vt8623/raminit.c ?
In-Reply-To: <444D3708.1020907@zyxod.com>
References: <444D3708.1020907@zyxod.com>
Message-ID: <20060424204127.GA3438@coresystems.de>

* Eric Poulsen <eric at zyxod.com> [060424 22:37]:
> While poking around trying to get VGA working, I did a grep for '3123', 
> and I found this.  Notice how the variable 'north' is assigned to the 
> result of the 'pci_locate_device' call, then immediately re-assigned to 
> zero ... and then used.  Is this correct?
 
It will probably work because the northbridge usually sits on 0:0.0

>   print_debug("vt8623 init starting\r\n");
>   north = pci_locate_device(PCI_ID(0x1106, 0x3123), 0);
>   north = 0;

In the best case this wasts time and space.

Stefan.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Mon Apr 24 22:45:31 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 24 Apr 2006 14:45:31 -0600
Subject: [LinuxBIOS] Strange code in
 src/northbridge/via/vt8623/raminit.c ?
In-Reply-To: <444D3708.1020907@zyxod.com>
References: <444D3708.1020907@zyxod.com>
Message-ID: <444D38EB.4080504@lanl.gov>

Eric Poulsen wrote:
> While poking around trying to get VGA working, I did a grep for '3123', 
> and I found this.  Notice how the variable 'north' is assigned to the 
> result of the 'pci_locate_device' call, then immediately re-assigned to 
> zero ... and then used.  Is this correct?
> 
> 
> static void ddr_ram_setup(const struct mem_controller *ctrl)
> {
>   device_t north = (device_t) 0;
>   uint8_t b, c, bank;
>   uint16_t i,j;
>   unsigned long bank_address;
> 
>   print_debug("vt8623 init starting\r\n");
>   north = pci_locate_device(PCI_ID(0x1106, 0x3123), 0);
>   north = 0;
> 
>   pci_write_config8(north,0x75,0x08);
> 
> ...
> 
> }
> 
> 

yeah, it works but is gross. This is part of the overloading that goes 
on in the romcc side of the build step that makes me green.

Basically, in the romcc step, a device_t is a u32. So you're allowed to 
do something that in the gcc step is totally illegal, because device_t 
is this in gcc world:
typedef struct device * device_t;

so in romcc, device_t is a scalar, in gcc, a pointer, and via the magic 
of #ifdef and #define the
pci_x_y
stuff all returns the correct type.

The upside is you can compile most romcc code in gcc and it will work. 
The downside is that it gets confusing.

I'm guessing that hack was put in there because the same, or compatible, 
device has slightly different devids. It would be interesting to look at 
history and see when it happened. Basically romcc is so smart that it 
will optimize out the pci_locate_device anyway.

ron



From chris at suehsi.de  Tue Apr 25 00:17:30 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 00:17:30 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060424201007.GA32112@coresystems.de>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>
	<20060424201007.GA32112@coresystems.de>
Message-ID: <444D4E7A.6040408@suehsi.de>

v2/src/devices/emulator/biosemu.c:
> 
> Enable this line (116) by removing the // 
> // printk_debug("int%x vector at %x\n", num, getIntVect(num));
>

Mmmmmmh,

sorry, there is absolute nothing, no output.
Now I will enable other lines.

chris

> 
> Stefan
> 




From smithbone at gmail.com  Mon Apr 24 23:06:24 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 24 Apr 2006 16:06:24 -0500
Subject: [LinuxBIOS] Strange code in
	src/northbridge/via/vt8623/raminit.c ?
In-Reply-To: <444D38EB.4080504@lanl.gov>
References: <444D3708.1020907@zyxod.com> <444D38EB.4080504@lanl.gov>
Message-ID: <8a0c36780604241406y2f3c3c1dn9c199e0270ffbd2a@mail.gmail.com>

> I'm guessing that hack was put in there because the same, or compatible,
> device has slightly different devids. It would be interesting to look at
> history and see when it happened. Basically romcc is so smart that it
> will optimize out the pci_locate_device anyway.

Why would you try and search for a northbridge anyway?  I though by
definition there is one located at 0:0.0.  Does the HT world and dual
channel stuff break that?

--
Richard A. Smith



From chris at suehsi.de  Tue Apr 25 00:37:12 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 00:37:12 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444D4E7A.6040408@suehsi.de>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>
	<444D4E7A.6040408@suehsi.de>
Message-ID: <444D5318.3000707@suehsi.de>


> Mmmmmmh,
> 
> sorry, there is absolute nothing, no output.
> Now I will enable other lines.
> 

nothing :(






From rminnich at lanl.gov  Mon Apr 24 23:24:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 24 Apr 2006 15:24:36 -0600
Subject: [LinuxBIOS] Strange code in
 src/northbridge/via/vt8623/raminit.c ?
In-Reply-To: <8a0c36780604241406y2f3c3c1dn9c199e0270ffbd2a@mail.gmail.com>
References: <444D3708.1020907@zyxod.com> <444D38EB.4080504@lanl.gov>
	<8a0c36780604241406y2f3c3c1dn9c199e0270ffbd2a@mail.gmail.com>
Message-ID: <444D4214.8090001@lanl.gov>

Richard Smith wrote:
>>I'm guessing that hack was put in there because the same, or compatible,
>>device has slightly different devids. It would be interesting to look at
>>history and see when it happened. Basically romcc is so smart that it
>>will optimize out the pci_locate_device anyway.
> 
> 
> Why would you try and search for a northbridge anyway?  I though by
> definition there is one located at 0:0.0.  Does the HT world and dual
> channel stuff break that?

there are cases where it is not, even going far back, to the Micron 
nortbridge that RLX used. It's good hygiene to look for it.

ron



From chris at suehsi.de  Tue Apr 25 00:49:52 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 00:49:52 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444D5318.3000707@suehsi.de>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>
	<444D5318.3000707@suehsi.de>
Message-ID: <444D5610.7050207@suehsi.de>

Christian S?hs schrieb:
>>Mmmmmmh,
>>
>>sorry, there is absolute nothing, no output.
>>Now I will enable other lines.
>>
> 
> 
> nothing :(
> 

Ok, now I have enabled all debug lines, but there is no output.

chris




From ward at gnu.org  Tue Apr 25 00:01:47 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 24 Apr 2006 18:01:47 -0400
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
Message-ID: <20060424220147.GA26709@io.pong.be>

Hi YH and list,

I've been playing with the boot prompt timeouts for Etherboot/filo on my
setup.

I've noticed that if I set the combined timeout (the etherboot ASK_BOOT and
filo AUTOBOOT_DELAY) to less than about 3 seconds, the system won't boot
because filo doesn't see the SATA drives. This example has ASK_BOOT set to -1
(i.e. disabled), and AUTOBOOT_DELAY set to 2 seconds.

---------------------------
Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffc0000 - 0xfffdffff
Found ELF candiate at offset 0
Loading Etherboot version: 5.4.1
Dropping non PT_LOAD segment
New segment addr 0x10000 size 0x49090 offset 0x0 filesize 0xf7f0
(cleaned up) New segment addr 0x10000 size 0x49090 offset 0x0 filesize 0xf7f0
Loading Segment: addr: 0x00000000bff90000 memsz: 0x0000000000032000 filesz:
0x000000000000f7f0
Clearing Segment: addr: 0x00000000bff9f7f0 memsz: 0x0000000000022810
Loading Segment: addr: 0x0000000000042000 memsz: 0x0000000000017090 filesz:
0x0000000000000000
Clearing Segment: addr: 0x0000000000042000 memsz: 0x0000000000017090
Jumping to boot code at 0x100b0
CPU 2064 Mhz
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: TG3 FILO   Images: NBI ELF
Protocols: DHCP TFTP
Relocating _text from: [000100e0,00059090) to [bfeb7050,bff00000)
Probing pci disk...
[FILO]FILO version 0.4.1 (root at countzero.vandewege.net) Fri Apr 21 18:47:00 EDT 2006
Press <Enter> for default boot, or <Esc> for boot prompt... 2^H ^H1^H ^Htimed out
boot: hde1:/linuxbios.elf
No drive detected on IDE channel 2
boot: hde1:/linuxbios.elf^H ^H^H ^Hlf
Drive 4 does not exist
boot: hde1:/linuxbios.elf
---------------------------

This is only a problem for a cold boot, i.e. from power off. If I do a warm
reboot, the system boots fine.

Is there something that can be done about this? It seems silly to have to
introduce delays in the bootup sequence to make booting from SATA possible,
particularly since fast bootup is one of LinuxBIOS's strengths.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From stepan at coresystems.de  Tue Apr 25 00:07:35 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 25 Apr 2006 00:07:35 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444D5610.7050207@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D3E07.6010209@suehsi.de>
	<20060424201007.GA32112@coresystems.de>
	<444D4E7A.6040408@suehsi.de> <444D5318.3000707@suehsi.de>
	<444D5610.7050207@suehsi.de>
Message-ID: <20060424220735.GA15237@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060425 00:49]:
> 
> Ok, now I have enabled all debug lines, but there is no output.
 
including X86EMU_trace_on()?
 
-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Tue Apr 25 00:02:21 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 24 Apr 2006 16:02:21 -0600
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060424220147.GA26709@io.pong.be>
References: <20060424220147.GA26709@io.pong.be>
Message-ID: <444D4AED.3020805@lanl.gov>

Ward Vandewege wrote:

> This is only a problem for a cold boot, i.e. from power off. If I do a warm
> reboot, the system boots fine.
> 
> Is there something that can be done about this? It seems silly to have to
> introduce delays in the bootup sequence to make booting from SATA possible,
> particularly since fast bootup is one of LinuxBIOS's strengths.

this problem goes back to our very first boot some six years ago. Amazing.

ATA has outrageous boot delays. I'm sorry to see that SATA has them too. 
I have no good idea how to fix this, unless we can train FILO to know 
that we're coming into boot from power on reset.

ron



From yinghai.lu at amd.com  Tue Apr 25 00:14:56 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 24 Apr 2006 15:14:56 -0700
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BDE@ssvlexmb2.amd.com>

I don't know if it is Silicon Image 3114 bug or sth..., or if there is
any bit to check if the HDD scan is busy...for us to check...

YH




From stepan at coresystems.de  Tue Apr 25 00:21:44 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 25 Apr 2006 00:21:44 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <444D4AED.3020805@lanl.gov>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
Message-ID: <20060424222144.GA17934@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060425 00:02]:
> this problem goes back to our very first boot some six years ago. Amazing.
> 
> ATA has outrageous boot delays. I'm sorry to see that SATA has them too. 
> I have no good idea how to fix this, unless we can train FILO to know 
> that we're coming into boot from power on reset.

What's needed here? Just keep on polling until either a couple more
seconds are gone or we finally start seeing the drive?

What features does the etherboot filo have that the official one does
not? I'd like to merge those, as file-pre-0.5 has a lot of interesting 
stuff that never went into etherboot (and etherboot is a pita to build 
compared to filo at least)

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ward at gnu.org  Tue Apr 25 00:25:01 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 24 Apr 2006 18:25:01 -0400
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060424222144.GA17934@coresystems.de>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
	<20060424222144.GA17934@coresystems.de>
Message-ID: <20060424222501.GC27028@io.pong.be>

On Tue, Apr 25, 2006 at 12:21:44AM +0200, Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060425 00:02]:
> > this problem goes back to our very first boot some six years ago. Amazing.
> > 
> > ATA has outrageous boot delays. I'm sorry to see that SATA has them too. 
> > I have no good idea how to fix this, unless we can train FILO to know 
> > that we're coming into boot from power on reset.
> 
> What's needed here? Just keep on polling until either a couple more
> seconds are gone or we finally start seeing the drive?
> 
> What features does the etherboot filo have that the official one does
> not? I'd like to merge those, as file-pre-0.5 has a lot of interesting 
> stuff that never went into etherboot (and etherboot is a pita to build 
> compared to filo at least)

Can we have SATA support directly in filo? That would simplify things
greatly!

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Tue Apr 25 00:26:59 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 24 Apr 2006 15:26:59 -0700
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BE1@ssvlexmb2.amd.com>

1. compatiable sata support
2. usb OHCI/EHI storage support
3. zelf format support

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at coresystems.de] 
Sent: Monday, April 24, 2006 3:22 PM
To: Ronald G Minnich
Cc: Ward Vandewege; linuxbios at linuxbios.org; Lu, Yinghai
Subject: Re: [LinuxBIOS] etherboot/filo + sata startup timing

* Ronald G Minnich <rminnich at lanl.gov> [060425 00:02]:
> this problem goes back to our very first boot some six years ago.
Amazing.
> 
> ATA has outrageous boot delays. I'm sorry to see that SATA has them
too. 
> I have no good idea how to fix this, unless we can train FILO to know 
> that we're coming into boot from power on reset.

What's needed here? Just keep on polling until either a couple more
seconds are gone or we finally start seeing the drive?

What features does the etherboot filo have that the official one does
not? I'd like to merge those, as file-pre-0.5 has a lot of interesting 
stuff that never went into etherboot (and etherboot is a pita to build 
compared to filo at least)

Stefan

-- 
coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 * Fax: +49 761 7664613
Email: info at coresystems.de  * http://www.coresystems.de/





From yinghai.lu at amd.com  Tue Apr 25 00:28:28 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 24 Apr 2006 15:28:28 -0700
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BE2@ssvlexmb2.amd.com>

That should be most easy part, about one or two lines...

YH

-----Original Message-----
From: Ward Vandewege [mailto:ward at gnu.org] 
Sent: Monday, April 24, 2006 3:25 PM
To: Stefan Reinauer
Cc: Ronald G Minnich; linuxbios at linuxbios.org; Lu, Yinghai
Subject: Re: [LinuxBIOS] etherboot/filo + sata startup timing

On Tue, Apr 25, 2006 at 12:21:44AM +0200, Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060425 00:02]:
> > this problem goes back to our very first boot some six years ago.
Amazing.
> > 
> > ATA has outrageous boot delays. I'm sorry to see that SATA has them
too. 
> > I have no good idea how to fix this, unless we can train FILO to
know 
> > that we're coming into boot from power on reset.
> 
> What's needed here? Just keep on polling until either a couple more
> seconds are gone or we finally start seeing the drive?
> 
> What features does the etherboot filo have that the official one does
> not? I'd like to merge those, as file-pre-0.5 has a lot of interesting

> stuff that never went into etherboot (and etherboot is a pita to build

> compared to filo at least)

Can we have SATA support directly in filo? That would simplify things
greatly!

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator





From stepan at coresystems.de  Tue Apr 25 00:29:51 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 25 Apr 2006 00:29:51 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BE1@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BE1@ssvlexmb2.amd.com>
Message-ID: <20060424222951.GA19642@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060425 00:26]:
> 1. compatiable sata support
> 2. usb OHCI/EHI storage support
> 3. zelf format support
 
is vga init support still in there as well? From the list above
zelf seems the hardest to implement in Filo, as the etherboot
implementation is kind of nasty...

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Tue Apr 25 00:46:03 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 24 Apr 2006 17:46:03 -0500
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <444D4AED.3020805@lanl.gov>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
Message-ID: <8a0c36780604241546l6ecc8eaey91a3c07e8706a0f9@mail.gmail.com>

> this problem goes back to our very first boot some six years ago. Amazing.
>
> ATA has outrageous boot delays. I'm sorry to see that SATA has them too.
> I have no good idea how to fix this, unless we can train FILO to know
> that we're coming into boot from power on reset.

I don't know that they are *that* outrageous when you consider what's
happening.  The problem is mostly physics and economics.  Consider
what it takes to spin a platter from a dead stop up to 7200 rpm and
position a read head on the platter with nanometer accuracy across a
fairly wide temp range.  Now try to do it with hardware that costs
less than $10.

If you want really fast boot times you need to boot off of non-mechancial media.

--
Richard A. Smith



From yinghai.lu at amd.com  Tue Apr 25 00:59:11 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 24 Apr 2006 15:59:11 -0700
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BE4@ssvlexmb2.amd.com>

VGA init? Etherboot could use DIRECT_VGA...

That's one of the reasons for merging filo into etherboot....

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at coresystems.de] 
Sent: Monday, April 24, 2006 3:30 PM
To: Lu, Yinghai
Cc: Ronald G Minnich; Ward Vandewege; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] etherboot/filo + sata startup timing

* Lu, Yinghai <yinghai.lu at amd.com> [060425 00:26]:
> 1. compatiable sata support
> 2. usb OHCI/EHI storage support
> 3. zelf format support
 
is vga init support still in there as well? From the list above
zelf seems the hardest to implement in Filo, as the etherboot
implementation is kind of nasty...

Stefan

-- 
coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 * Fax: +49 761 7664613
Email: info at coresystems.de  * http://www.coresystems.de/





From stepan at coresystems.de  Tue Apr 25 01:02:11 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 25 Apr 2006 01:02:11 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BE4@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BE4@ssvlexmb2.amd.com>
Message-ID: <20060424230211.GA25587@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060425 00:59]:
> VGA init? Etherboot could use DIRECT_VGA...
 
> That's one of the reasons for merging filo into etherboot....

direct vga? whats that? normal text mode output? that works fine in the
normal filo as well.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at lanl.gov  Tue Apr 25 06:05:53 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 24 Apr 2006 22:05:53 -0600
Subject: [LinuxBIOS] gx2 status
Message-ID: <444DA021.5070004@lanl.gov>

as of today, we have got ethernet and external uart up on rumba, so we 
now have a networked node. OLPC patches are next, then graphics, then ...

I'm also planning to put Plan 9 in FLASH on the lippert frontrunner, but 
that's next week ...

ron



From ebiederman at lnxi.com  Tue Apr 25 08:26:09 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue, 25 Apr 2006 00:26:09 -0600
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <8a0c36780604240942m132ce454pbd73a50ef6f09f1f@mail.gmail.com>
	(Richard Smith's message of "Mon, 24 Apr 2006 11:42:52 -0500")
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<20060424104950.GA24874@coresystems.de>
	<20060424111110.GA28044@coresystems.de> <444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de> <444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de> <444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de> <444CECA5.7030909@suehsi.de>
	<8a0c36780604240942m132ce454pbd73a50ef6f09f1f@mail.gmail.com>
Message-ID: <m3r73m8932.fsf@maxwell.lnxi.com>

"Richard Smith" <smithbone at gmail.com> writes:

> On 4/24/06, Christian S?hs <chris at suehsi.de> wrote:
>> Here is the output with changed patch. vendor/device ID to cyberpro.
>>
>
> I think I am beginning to see what's happening here device 12.4 seems
> to have mutiple entries in the device tree.
>
> I've not looked at the pci enum stuff so I don't quite understand what
> is going on but looking at the log I see.. (I've sniped it down a bit)
>
>> PCI_DOMAIN: 0000 enabled
>> PCI_DOMAIN: 0000 scanning...
>> PCI: pci_scan_bus for bus 0
>> PCI: 00:00.0 [1078/0001] ops
>> PCI: 00:00.0 [1078/0001] enabled
>> PCI: 00:09.0 [10ea/5000] ops
>> PCI: 00:09.0 [10ea/5000] enabled
>> PCI: 00:12.0 [1078/0100] bus ops
>
> Notice that it detected the southbrige with 'bus' ops
>
>> southbridge_enable: dev is 00018900
>> PCI: 00:12.0 [1078/0100] enabled
>> malloc Enter, size 668, free_mem_ptr 00022000
>> malloc 0x00022000
>> PCI: 00:12.1 [1078/0101] enabled
>> malloc Enter, size 668, free_mem_ptr 0002229c
>> malloc 0x0002229c
>> PCI: 00:12.2 [1078/0102] ops
>> cs5530_ide: ide_enable
>> PCI: 00:12.2 [1078/0102] enabled
>> malloc Enter, size 668, free_mem_ptr 00022538
>> malloc 0x00022538
>> PCI: 00:12.3 [1078/0103] enabled
>> malloc Enter, size 668, free_mem_ptr 000227d4
>> malloc 0x000227d4
>> PCI: 00:12.4 [1078/0104] enabled
>
> So here is entry #1 and it has the device enabled.

>> malloc Enter, size 668, free_mem_ptr 00022a70
>> malloc 0x00022a70
>> PCI: 00:13.0 [0e11/a0f8] enabled
>
> Now we move into another scan of just the 12.x devices
>
>> scan_static_bus for PCI: 00:12.0
>> PNP: 002e.0 enabled
>> PNP: 002e.1 enabled
>> PNP: 002e.2 enabled
>> PNP: 002e.3 disabled
>> PNP: 002e.4 enabled
>> PNP: 002e.5 enabled
>> PNP: 002e.6 enabled
>> PNP: 002e.7 enabled
>> PNP: 002e.8 enabled
>> PCI: 00:12.1 disabled
>> PCI: 00:12.2 enabled
>> PCI: 00:12.3 disabled
>> PCI: 00:12.4 disabled
>> scan_static_bus for PCI: 00:12.0 done
>> PCI: pci_scan_bus returning with max=00
>> scan_static_bus for Root Device done
>
> So according to all this 12.4 is in the tree twice once as enabled and
> once as disabled.  Which is what we see later on when doing then VGA
> resource allocation.

I'm not quite certain that is right, although it may be.
There is a part where we unify the static and the dynamic
device tress.

It does not look correct for 12.1,12.2,12.3,12.4 to be static
devices of device 12.0 though.   I suspect there is an unnecessary
level of nesting in Config.lb that is causing this.

>
> Most of this code was doen by Eric B.  I've added him to the To: list
> since I don't think he follows the LB list very closely anymore.

No but I am happy to help when I have a minute.  Somedays I
feel like I am wearing as many hats as the mad hatter in
Alice in Wonderland....

> Eric:
>
> I know you are a busy man and coming in on this cold but perhaps you
> can shed some light on this?  Chris is trying to set up another board
> based on the eaglelion/5bcm board but his board has an additional VGA
> device at 9.0 and he wants that device to show up as the primary
> device.  We have 12.4 marked as "off" in the Options.lb but its still
> getting picked and assiged to the VGA resource.

So I would first check to see if the VGA adapter identification code
checks the enable bit.  It is quite possible that just because
a device is disable that I we don't ignore it.  Looking at
an old version of the code, we do clearly do not check the enable
bit, and just finds the first vga device on the list of all devices.

> The gory details should be on the list under this thread.

I'm trying to answer without looking :)

Eric



From smithbone at gmail.com  Tue Apr 25 08:43:35 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 25 Apr 2006 01:43:35 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <m3r73m8932.fsf@maxwell.lnxi.com>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444CD38F.5090502@suehsi.de> <20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de> <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444CECA5.7030909@suehsi.de>
	<8a0c36780604240942m132ce454pbd73a50ef6f09f1f@mail.gmail.com>
	<m3r73m8932.fsf@maxwell.lnxi.com>
Message-ID: <8a0c36780604242343w15d887a9h57662eb147cab630@mail.gmail.com>

> So I would first check to see if the VGA adapter identification code
> checks the enable bit.

I added debug code that does just that.

>  It is quite possible that just because
> a device is disable that I we don't ignore it.  Looking at
> an old version of the code, we do clearly do not check the enable
> bit, and just finds the first vga device on the list of all devices.

That version must be pretty old then.  The current code will
'continue' the loop if the enable is not set.  Here's what my VGA
debug code spewed.. Notice that 12.4 is in the tree twice once
disabled (where it is skipped) and then a second time where it gets
picked up.

Perhaps the merge of the static and dynamic trees gets tripped up by
whats in the Config.lb?

Done reading resources.
 Looking at device Root Device
 Looking at device PCI_DOMAIN: 0000
 Looking at device PCI: 00:00.0
 Looking at device PCI: 00:09.0
 first onboard = PCI: 00:09.0
 Looking at device PCI: 00:09.0
 Looking at device PCI: 00:12.0
 Looking at device PNP: 002e.0
 Looking at device PNP: 002e.1
 Looking at device PNP: 002e.2
 Looking at device PNP: 002e.3
 Skipping disabled device PNP: 002e.3
 Looking at device PNP: 002e.4
 Looking at device PNP: 002e.5
 Looking at device PNP: 002e.6
 Looking at device PNP: 002e.7
 Looking at device PNP: 002e.8
 Looking at device PCI: 00:12.1
 Skipping disabled device PCI: 00:12.1
 Looking at device PCI: 00:12.2
 Looking at device PCI: 00:12.3
 Skipping disabled device PCI: 00:12.3
 Looking at device PCI: 00:12.4
 Skipping disabled device PCI: 00:12.4
 Looking at device PCI: 00:12.1
 Looking at device PCI: 00:12.2
 Looking at device PCI: 00:12.3
 Looking at device PCI: 00:12.4
 first onboard = PCI: 00:12.4
 Looking at device PCI: 00:13.0
 Looking at vga_onboard
 Yes: PCI: 00:12.4
 Reassigning vga to PCI: 00:12.4
Allocating VGA resource PCI: 00:12.4
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device

--
Richard A. Smith



From ebiederman at lnxi.com  Tue Apr 25 08:44:54 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue, 25 Apr 2006 00:44:54 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444D2EF7.1030906@suehsi.de> (
	=?iso-8859-1?q?Christian_S=FChs's_message_of?= "Mon,
	24 Apr 2006 22:03:03 +0200")
References: <20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de> <20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de> <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D1DAE.8080100@suehsi.de> <20060424183303.GA18751@coresystems.de>
	<444D2EF7.1030906@suehsi.de>
Message-ID: <m3odyq2ly1.fsf@maxwell.lnxi.com>

Christian S?hs <chris at suehsi.de> writes:

>> can you post all of the Config.lb file please?
>> S.
>

Hmm. I deleted the commented out lines and cleaned up the indentation
and this is what I see.

It appears we have several nesting problems.
Nothing should be inside drivce/pci/onboard except pci 9.0.

Having pci 12.1,12.2,12.3 inside of pci 12.0 looks distinctly suspicious.

The version in static.c appears to confirm this.

It actually looks to me like we are short an end.  is that really
accepted?

chip northbridge/amd/gx1
	device pci_domain 0 on 
		device pci 0.0 on end
		chip drivers/pci/onboard
			device pci 9.0 on end
			    register "rom_address" = "0xfffc0000"
			end
			chip southbridge/amd/cs5530
				device pci 12.0 on
					chip superio/NSC/pc97317
						device pnp 2e.0 on		# Keyboard
							 io 0x60 = 0x60
							 io 0x62 = 0x64
							irq 0x70 = 1
						end
						device pnp 2e.1 on		# Mouse
							irq 0x70 = 12
						end
						device pnp 2e.2 on		# RTC
							 io 0x60 = 0x70
							irq 0x70 = 8
						end
						device pnp 2e.3 off		# FDC
						end
						device pnp 2e.4 on		# Parallel Port
							 io 0x60 = 0x378
							irq 0x70 = 7
						end
						device pnp 2e.5 on		# COM2
							 io 0x60 = 0x2f8
							irq 0x70 = 3
						end
						device pnp 2e.6 on		# COM1
							 io 0x60 = 0x3f8
							irq 0x70 = 4
						end
						device pnp 2e.7 on		# GPIO
							 io 0x60 = 0xe0
						end
						device pnp 2e.8 on		# Power Management
							io 0x60 = 0xe800
						end
						register "com1" = "{115200}"
						register "com2" = "{38400}"
					end
					device pci 12.1 off end		# SMI
					device pci 12.2 on  end		# IDE
					device pci 12.3 off end 	# Audio
					device pci 12.4 off end		# VGA
				end
			end
		end
	
		chip cpu/amd/model_gx1
		end
	end

Eric



From ebiederman at lnxi.com  Tue Apr 25 08:59:20 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue, 25 Apr 2006 00:59:20 -0600
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <8a0c36780604242343w15d887a9h57662eb147cab630@mail.gmail.com>
	(Richard Smith's message of "Tue, 25 Apr 2006 01:43:35 -0500")
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444CD38F.5090502@suehsi.de> <20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de> <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444CECA5.7030909@suehsi.de>
	<8a0c36780604240942m132ce454pbd73a50ef6f09f1f@mail.gmail.com>
	<m3r73m8932.fsf@maxwell.lnxi.com>
	<8a0c36780604242343w15d887a9h57662eb147cab630@mail.gmail.com>
Message-ID: <m3lkturvhz.fsf@maxwell.lnxi.com>

"Richard Smith" <smithbone at gmail.com> writes:

>> So I would first check to see if the VGA adapter identification code
>> checks the enable bit.
>
> I added debug code that does just that.
>
>>  It is quite possible that just because
>> a device is disable that I we don't ignore it.  Looking at
>> an old version of the code, we do clearly do not check the enable
>> bit, and just finds the first vga device on the list of all devices.
>
> That version must be pretty old then.  
Yep. :)  Just something laying around on my hard drive.
One of these days I will figure out how to get the SVN tree.

> The current code will
> 'continue' the loop if the enable is not set.  Here's what my VGA
> debug code spewed.. Notice that 12.4 is in the tree twice once
> disabled (where it is skipped) and then a second time where it gets
> picked up.
>
> Perhaps the merge of the static and dynamic trees gets tripped up by
> whats in the Config.lb?

That is what it looks like. The static 12.[123] appears to be
on a child bus of 12.0 which is nonsense in this case.

See my other message on the properly indented version of Config.lb
It appears we have structures that just aren't closed properly.

There has got to be a good way to prevent that but...

Eric



From smithbone at gmail.com  Tue Apr 25 09:01:32 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 25 Apr 2006 02:01:32 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <m3odyq2ly1.fsf@maxwell.lnxi.com>
References: <20060424111110.GA28044@coresystems.de>
	<20060424124236.GA9541@coresystems.de> <444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de> <444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D1DAE.8080100@suehsi.de> <20060424183303.GA18751@coresystems.de>
	<444D2EF7.1030906@suehsi.de> <m3odyq2ly1.fsf@maxwell.lnxi.com>
Message-ID: <8a0c36780604250001v343caf03y7c4b00aa24ef51bd@mail.gmail.com>

> Hmm. I deleted the commented out lines and cleaned up the indentation
> and this is what I see.
>
> It appears we have several nesting problems.
> Nothing should be inside drivce/pci/onboard except pci 9.0.
>
> Having pci 12.1,12.2,12.3 inside of pci 12.0 looks distinctly suspicious.
>
> The version in static.c appears to confirm this.
>
> It actually looks to me like we are short an end.  is that really
> accepted?
>

Yep.. I just took what you posted pasted it over the existing, ran
buildtarget and then make and it made fine.
--
Richard A. Smith



From smithbone at gmail.com  Tue Apr 25 09:10:51 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 25 Apr 2006 02:10:51 -0500
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <m3lkturvhz.fsf@maxwell.lnxi.com>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>
	<444CD912.20607@suehsi.de> <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444CECA5.7030909@suehsi.de>
	<8a0c36780604240942m132ce454pbd73a50ef6f09f1f@mail.gmail.com>
	<m3r73m8932.fsf@maxwell.lnxi.com>
	<8a0c36780604242343w15d887a9h57662eb147cab630@mail.gmail.com>
	<m3lkturvhz.fsf@maxwell.lnxi.com>
Message-ID: <8a0c36780604250010r56e6f71ambd85c321aa6d6072@mail.gmail.com>

> > Perhaps the merge of the static and dynamic trees gets tripped up by
> > whats in the Config.lb?
>
> That is what it looks like. The static 12.[123] appears to be
> on a child bus of 12.0 which is nonsense in this case.

Thats what I was thinking but I wasn't quite sure enough what the
"right" way should look like.

> See my other message on the properly indented version of Config.lb
> It appears we have structures that just aren't closed properly.

Did you miss the end after pci 9.0 here?

                chip drivers/pci/onboard
                       device pci 9.0 on end
                           register "rom_address" = "0xfffc0000"
                       end



--
Richard A. Smith



From chris at suehsi.de  Tue Apr 25 10:43:56 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 10:43:56 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060424220735.GA15237@coresystems.de>
References: <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D3E07.6010209@suehsi.de>
	<20060424201007.GA32112@coresystems.de>
	<444D4E7A.6040408@suehsi.de> <444D5318.3000707@suehsi.de>
	<444D5610.7050207@suehsi.de>
	<20060424220735.GA15237@coresystems.de>
Message-ID: <444DE14C.8050402@suehsi.de>

Stefan Reinauer schrieb:
> * Christian S?hs <chris at suehsi.de> [060425 00:49]:
> 
>>Ok, now I have enabled all debug lines, but there is no output.
> 
>  
> including X86EMU_trace_on()?
>  
I wondered about that and no,
I have not enabled this line. Unfortanetly I can't test this now.
Sometimes I have to work :D

Is this line needed for the output ?!

More in the evening






From ebiederman at lnxi.com  Tue Apr 25 09:27:45 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue, 25 Apr 2006 01:27:45 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <m3odyq2ly1.fsf@maxwell.lnxi.com> (Eric W. Biederman's message
	of "Tue, 25 Apr 2006 00:44:54 -0600")
References: <20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de> <20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de> <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D1DAE.8080100@suehsi.de> <20060424183303.GA18751@coresystems.de>
	<444D2EF7.1030906@suehsi.de> <m3odyq2ly1.fsf@maxwell.lnxi.com>
Message-ID: <m3fyk2i07i.fsf@maxwell.lnxi.com>


To be clear I think the Config.lb should read:


chip northbridge/amd/gx1
	device pci_domain 0 on 
		device pci 0.0 on end
		chip drivers/pci/onboard
			device pci 9.0 on end
			    register "rom_address" = "0xfffc0000"
			end
		end
		chip southbridge/amd/cs5530
			device pci 12.0 on
				chip superio/NSC/pc97317
					device pnp 2e.0 on # Keyboard
						 io 0x60 = 0x60
						 io 0x62 = 0x64
						irq 0x70 = 1
					end
					device pnp 2e.1 on # Mouse
						irq 0x70 = 12
					end
					device pnp 2e.2 on # RTC
						 io 0x60 = 0x70
						irq 0x70 = 8
					end
					device pnp 2e.3 off # FDC
					end
					device pnp 2e.4 on # Parallel Port
						 io 0x60 = 0x378
						irq 0x70 = 7
					end
					device pnp 2e.5 on # COM2
						 io 0x60 = 0x2f8
						irq 0x70 = 3
					end
					device pnp 2e.6 on # COM1
						 io 0x60 = 0x3f8
						irq 0x70 = 4
					end
					device pnp 2e.7 on # GPIO
						 io 0x60 = 0xe0
					end
					device pnp 2e.8 on # Power Management
						io 0x60 = 0xe800
					end
					register "com1" = "{115200}"
					register "com2" = "{38400}"
				end
			end
			device pci 12.1 off end		# SMI
			device pci 12.2 on  end		# IDE
			device pci 12.3 off end 	# Audio
			device pci 12.4 off end		# VGA
		end
	
		chip cpu/amd/model_gx1
		end
	end
end

Eric



From clsl at df.ufpe.br  Mon Apr 24 20:47:14 2006
From: clsl at df.ufpe.br (Clessio Leao)
Date: Mon, 24 Apr 2006 15:47:14 -0300
Subject: [LinuxBIOS] clusters
Message-ID: <000c01c667cf$90d5a6d0$7709a196@guaiamum>

Hi anyone, 
In this first moment I would like to say thanks for your attention. Mi name is Clessio and I'm a physics student at UFPE, Brazil.  Today I have a serious doubt. I can't imagine how can I construct a cluster wuith differents kinds of PC?s (6 AMD Athlon 64 bits, motherboard - K8TNeo-V) and 2 Pentium IV 3.2Ghz. If anyone know something about it, please tell me as soon as possible.
Thanks for everything,
Clessio Le?o
UFPE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060424/d6a7d0ff/attachment.html>

From m at de-minimis.co.uk  Tue Apr 25 14:11:55 2006
From: m at de-minimis.co.uk (m at de-minimis.co.uk)
Date: Tue, 25 Apr 2006 13:11:55 +0100 (BST)
Subject: [LinuxBIOS] Overview
Message-ID: <Pine.LNX.4.63.0604251243250.5146@thermalone.footholds.net>


Dear All,

I'm completely new to LinuxBios, and I'm trying to understand exactly what 
it does, and what it offers.  Trying to decide exactly how interested I 
am.  Could you please forgive my ignorance and clarify the following for 
me please:

Does LinuxBios run on the main processor or on some auxiliary processor?

What is the typical power consumption of a LinuxBios moboard running the 
minimum number of devices to do basic communication over ethernet - 
hopefully only the moboard and the network card if it isn't already on the 
moboard will require power, then I need to know processor consumption - 
here the earlier question about what does the processing becomes relevant.

Can LinuxBios be used to do complicated wake-on lan?  Here minimal power 
consumption in the idle state becomes important to me.  (question of 
fairly high interest to me)

Does LinuxBios help with running multiple operating systems 
simultaneously? (high interest)

Does it accelerate booting, because where previously first the bios 
loaded, then grub, then the OS proper, now perhaps booting can go straight 
from LinuxBios to OS?

How often can one typically write to the bios before it won't take any 
more changes?  I understand it's flash, so I expect few thousand times, 
more if one rotates which memory blocks one uses, but on the other hand 
this isn't exactly flash that is designed to be rewritten very often, as 
far as I understand anyway!  Can one fairly easily and at a competitive 
price buy replacement chips?

I very much appreciate any help you can give, because you've already done 
this kind of stuff.

A short introduction is probably in order:  I'm a mathematician, so a bit 
of an amateur where computer science is concerned.  I'm getting into 
writing linux device drivers at the moment.

Best Wishes, Max



From chris at suehsi.de  Tue Apr 25 16:56:02 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 16:56:02 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <m3fyk2i07i.fsf@maxwell.lnxi.com>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D1DAE.8080100@suehsi.de>
	<20060424183303.GA18751@coresystems.de>	<444D2EF7.1030906@suehsi.de>
	<m3odyq2ly1.fsf@maxwell.lnxi.com> <m3fyk2i07i.fsf@maxwell.lnxi.com>
Message-ID: <444E3882.70102@suehsi.de>

Thanks for this.

Eric W. Biederman schrieb:
> To be clear I think the Config.lb should read:
> 
> 
> chip northbridge/amd/gx1
> 	device pci_domain 0 on 
> 		device pci 0.0 on end
> 		chip drivers/pci/onboard
> 			device pci 9.0 on end
> 			    register "rom_address" = "0xfffc0000"
> 			end

I had to disable this "end tag" for a successful build.

# 		end
> 		chip southbridge/amd/cs5530
> 			device pci 12.0 on
> 				chip superio/NSC/pc97317
> 					device pnp 2e.0 on # Keyboard
> 						 io 0x60 = 0x60
> 						 io 0x62 = 0x64
> 						irq 0x70 = 1

Have a look to the attachment, the disabled PCI 12.4 device comes no 
longer up :D

I think this Config.lb version is better than the old one ;)


chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: erics_config.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060425/cdcc967b/attachment.ksh>

From smithbone at gmail.com  Tue Apr 25 15:55:05 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 25 Apr 2006 08:55:05 -0500
Subject: [LinuxBIOS] Overview
In-Reply-To: <Pine.LNX.4.63.0604251243250.5146@thermalone.footholds.net>
References: <Pine.LNX.4.63.0604251243250.5146@thermalone.footholds.net>
Message-ID: <8a0c36780604250655n1ed0204fs1f1ef94e52ed7c2a@mail.gmail.com>

On 4/25/06, m at de-minimis.co.uk <m at de-minimis.co.uk> wrote:

> I'm completely new to LinuxBios, and I'm trying to understand exactly what
> it does, and what it offers.  Trying to decide exactly how interested I
> am.  Could you please forgive my ignorance and clarify the following for
> me please:

Have you read all the info at linuxbios.org?  That should help.

> Does LinuxBios run on the main processor or on some auxiliary processor?

LinuxBIOS replaces the system BIOS so it rus on the "main" processor.

> What is the typical power consumption of a LinuxBios moboard running the
> minimum number of devices to do basic communication over ethernet -
> hopefully only the moboard and the network card if it isn't already on the
> moboard will require power, then I need to know processor consumption -
> here the earlier question about what does the processing becomes relevant.

The power consumption of most onboard devices will be swamped by the
power consumption of the CPU.  Next in line (or even greater) would be
a high powerd graphics card.  Since the power consumption of a
mainboard depneds on the type of the mainboard, the design of the
mainboard, and load of the CPU there is no easy answer to your
question.  Some one would actually have to measure it for a specific
mainboard setup.

For example a Dual opteron setup is going to pull way more juice than a Geode.

> Can LinuxBios be used to do complicated wake-on lan?

LinuxBIOS is GPL so it can do _whatever_ you code it to do. *grin*
Currently I don't know of any wake-on-lan implementations for the
supported mainboards.  But perhapas someone else does.

> Does LinuxBios help with running multiple operating systems
> simultaneously? (high interest)

No.

> Does it accelerate booting,

Yes.

> because where previously first the bios
> loaded, then grub, then the OS proper, now perhaps booting can go straight
> from LinuxBios to OS?

Even better than that.  LinuxBIOS can be customized to take out most
of the fat in a normal bios.  A linux prompt in 3 seconds is not
unheard of.  A lot depends on the type of media you boot from.

> How often can one typically write to the bios before it won't take any
> more changes?

I do embedded systems where we use flash parts a lot and I've never
run into a case where I've reached the write limit of a flash during
developement.  Its largely a non-issue.

> I understand it's flash, so I expect few thousand times,

The minimum I've ever seen was 10,000 cycles.  Most are 100,000
cycles. Some nowdays are 1M cycles.  This is also a worst case rating.
 ie running at the temp extreme and the lowest supply voltage.

> more if one rotates which memory blocks one uses, but on the other hand
> this isn't exactly flash that is designed to be rewritten very often, as
> far as I understand anyway!  Can one fairly easily and at a competitive
> price buy replacement chips?

Yes.  Digikey and Mouser have most of the popular parts.  And you
don't need the exact same part just one that is the same size and the
same speed and same package/pinout.

--
Richard A. Smith



From stuge-linuxbios at cdy.org  Tue Apr 25 16:35:36 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 25 Apr 2006 16:35:36 +0200
Subject: [LinuxBIOS] Overview
In-Reply-To: <Pine.LNX.4.63.0604251243250.5146@thermalone.footholds.net>
References: <Pine.LNX.4.63.0604251243250.5146@thermalone.footholds.net>
Message-ID: <20060425143536.30894.qmail@cdy.org>

On Tue, Apr 25, 2006 at 01:11:55PM +0100, m at de-minimis.co.uk wrote:
> 
> Dear All,
> 
> I'm completely new to LinuxBios, and I'm trying to understand
> exactly what it does, and what it offers.  Trying to decide exactly
> how interested I am.  Could you please forgive my ignorance and
> clarify the following for me please:

Perhaps you've already checked out the wiki on
http://wiki.linuxbios.org/ ? It has useful information both on macro
and micro levels.


> Does LinuxBios run on the main processor or on some auxiliary processor?

On the main processor.


> What is the typical power consumption of a LinuxBios moboard
> running the minimum number of devices to do basic communication
> over ethernet - hopefully only the moboard and the network card if
> it isn't already on the moboard will require power, then I need to
> know processor consumption - here the earlier question about what
> does the processing becomes relevant.

This depends completely on the hardware. LinuxBIOS can be configured
to disable or just disregard any hardware in the system that can be
disabled (usually this means leaving PCI devices untouched) but
whether the hardware does powersaving or not is outside LinuxBIOS'
control.


> Can LinuxBios be used to do complicated wake-on lan?  Here minimal
> power consumption in the idle state becomes important to me. 
> (question of fairly high interest to me)

LinuxBIOS doesn't generally stay resident in any way after starting
the OS either, the exception may be the recent VSA support that is
specific to the Geode family of System-on-Chip products from AMD.

Since LinuxBIOS is no longer running, this depends on the OS.


> Does LinuxBios help with running multiple operating systems
> simultaneously? (high interest)

No.


> Does it accelerate booting, because where previously first the bios
> loaded, then grub, then the OS proper, now perhaps booting can go
> straight from LinuxBios to OS?

Yes. I believe the boot time record is around three (3) seconds
although this will require ideal circumstances. Expect LinuxBIOS to
always be faster than a factory-supplied closed-source BIOS though.
Boot time varies heavily with specific mainboards and their quirks,
which affect LinuxBIOS as well as the OS. Solid-state storage (flash)
is a must for the optimal times.


> How often can one typically write to the bios before it won't take
> any more changes?  I understand it's flash, so I expect few
> thousand times, more if one rotates which memory blocks one uses,
> but on the other hand this isn't exactly flash that is designed to
> be rewritten very often, as far as I understand anyway!

I'd expect at the very least tens of thousands write cycles, but more
commonly hundreds of thousands. Anyway it's more than enough for
development, but probably not something you would want to depend on
in the field. (self-flashing systems etc.)


> Can one fairly easily and at a competitive price buy replacement
> chips?

Lots of flash parts are interchangeable. Check the specs for the
factory-installed part and find a replacement from your favorite
flash manufacturer. Add support to the LinuxBIOS auxiliary utility
flashrom if the particular chip isn't supported yet.

Most if not all flash manufacturers have distributors that will
gladly sell large quantities (1k+) of chips. Those willing to deal in
smaller quantities are fewer, but still exist. You'll usually have to
buy at least one full package. (typically PLCC or DIP plastic tubes
with 20-40 chips) Prices depend on flash size, but stay around a few
dollars per part.


> A short introduction is probably in order:  I'm a mathematician, so
> a bit of an amateur where computer science is concerned.  I'm
> getting into writing linux device drivers at the moment.

Cool. Out of curiosity, what is your interest in LinuxBIOS?


//Peter



From chris at suehsi.de  Tue Apr 25 18:39:00 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 18:39:00 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444DE14C.8050402@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>
	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>
	<444DE14C.8050402@suehsi.de>
Message-ID: <444E50A4.9080208@suehsi.de>


>>
>>>Ok, now I have enabled all debug lines, but there is no output.
>>
>> 
>>including X86EMU_trace_on()?
>> 
> 
> I wondered about that and no,
> I have not enabled this line. Unfortanetly I can't test this now.
> Sometimes I have to work :D
> 
> Is this line needed for the output ?!
> 

Well, what should I do next.

I've enabled all debug lines in biosemu.c --> no debug output
I've tried to enable X86EMU_trace_on() and setup_int_vect()
--> compile LB fails with undefiened references to this functions.
but void setup_int_vect(void) is in the same file ?!

It seems, that there is doing nothing by LB in this state.

chris



From rminnich at lanl.gov  Tue Apr 25 17:15:34 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 09:15:34 -0600
Subject: [LinuxBIOS] New Target for LinuxBios MB1030 / 3036 Success!!!???
In-Reply-To: <m3r73m8932.fsf@maxwell.lnxi.com>
References: <8a0c36780604231300y753c1cbapffd2a2498272ae08@mail.gmail.com>	<20060424104950.GA24874@coresystems.de>	<20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de>	<20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de>	<20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>
	<444CECA5.7030909@suehsi.de>	<8a0c36780604240942m132ce454pbd73a50ef6f09f1f@mail.gmail.com>
	<m3r73m8932.fsf@maxwell.lnxi.com>
Message-ID: <444E3D16.4070108@lanl.gov>

Eric W. Biederman wrote:

> So I would first check to see if the VGA adapter identification code
> checks the enable bit.  It is quite possible that just because
> a device is disable that I we don't ignore it.  Looking at
> an old version of the code, we do clearly do not check the enable
> bit, and just finds the first vga device on the list of all devices.

yes, my memory of that code was that it was pretty simple minded.

Find first vga device. Start it up.

I think, however, that Ollie fixed it up quite a bit, so i am no longer 
sure that is the case. We will be working with that code in a day or 
two, so I'll know better then.
ron



From rminnich at lanl.gov  Tue Apr 25 17:19:13 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 09:19:13 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <8a0c36780604250001v343caf03y7c4b00aa24ef51bd@mail.gmail.com>
References: <20060424111110.GA28044@coresystems.de>	<20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D1DAE.8080100@suehsi.de>
	<20060424183303.GA18751@coresystems.de>	<444D2EF7.1030906@suehsi.de>
	<m3odyq2ly1.fsf@maxwell.lnxi.com>
	<8a0c36780604250001v343caf03y7c4b00aa24ef51bd@mail.gmail.com>
Message-ID: <444E3DF1.8040607@lanl.gov>

Richard Smith wrote:
>>Hmm. I deleted the commented out lines and cleaned up the indentation
>>and this is what I see.
>>
>>It appears we have several nesting problems.
>>Nothing should be inside drivce/pci/onboard except pci 9.0.
>>
>>Having pci 12.1,12.2,12.3 inside of pci 12.0 looks distinctly suspicious.
>>
>>The version in static.c appears to confirm this.
>>
>>It actually looks to me like we are short an end.  is that really
>>accepted?
>>
> 
> 
> Yep.. I just took what you posted pasted it over the existing, ran
> buildtarget and then make and it made fine.
> --
> Richard A. Smith

great. Thinking about it, I don't think the parser is smart enough to 
catch that. Goodness, that's Parsing 101 and I missed it!

We had a project here to replace the config tool with Kconfig, but it 
did not work out -- our needs are more complex that Kconfig could 
accomodate. But fixing up the config parser is on the list.

At a minimum, however, if somebody had a .emacs for the config language 
even that would help ...

For now, however ,I think the Config issue with this mobo is drawing 
into focus.

ron



From ollie at lanl.gov  Tue Apr 25 17:38:56 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 25 Apr 2006 09:38:56 -0600
Subject: [LinuxBIOS] gx2 status
In-Reply-To: <444DA021.5070004@lanl.gov>
References: <444DA021.5070004@lanl.gov>
Message-ID: <1145979536.7827.0.camel@logarithm.lanl.gov>

On Mon, 2006-04-24 at 22:05 -0600, Ronald G Minnich wrote:
> as of today, we have got ethernet and external uart up on rumba, so we 
> now have a networked node. OLPC patches are next, then graphics, then ...
> 

Could you commit your current code ?

> I'm also planning to put Plan 9 in FLASH on the lippert frontrunner, but 
> that's next week ...
> 
> ron
> 
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From smithbone at gmail.com  Tue Apr 25 17:44:40 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 25 Apr 2006 10:44:40 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E3DF1.8040607@lanl.gov>
References: <20060424111110.GA28044@coresystems.de>
	<444CEAD6.3070901@suehsi.de> <444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D1DAE.8080100@suehsi.de> <20060424183303.GA18751@coresystems.de>
	<444D2EF7.1030906@suehsi.de> <m3odyq2ly1.fsf@maxwell.lnxi.com>
	<8a0c36780604250001v343caf03y7c4b00aa24ef51bd@mail.gmail.com>
	<444E3DF1.8040607@lanl.gov>
Message-ID: <8a0c36780604250844r2ac2645av293b6d5ae15e8a9e@mail.gmail.com>

On 4/25/06, Ronald G Minnich <rminnich at lanl.gov> wrote:

> great. Thinking about it, I don't think the parser is smart enough to
> catch that. Goodness, that's Parsing 101 and I missed it!
>
> We had a project here to replace the config tool with Kconfig, but it
> did not work out -- our needs are more complex that Kconfig could
> accomodate. But fixing up the config parser is on the list.
>
> At a minimum, however, if somebody had a .emacs for the config language
> even that would help ...

.emacs.. yuck. I might try something that works in vi though.  Is
there any really up to date documentation on the keyworks and
structure of the PCI list other than the code?  Its not obvious
sometimes what keywords need an end statement and which don't.

And there are obviously several wrong examples.

--
Richard A. Smith



From eric at zyxod.com  Tue Apr 25 17:57:12 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Tue, 25 Apr 2006 08:57:12 -0700
Subject: [LinuxBIOS] Epia ML 5000 success
Message-ID: <444E46D8.3050501@zyxod.com>

Last night, I got LinuxBios + VGA working on an Epia ML 5000.  If I'm 
feeling ambitious, I'll figure out how to get a splash logo. I'll write 
up my efforts as a HOWTO in the near future.

I'd like to thank everyone here for their help -- This is one of the 
most helpful technical mailing lists that I've been on.

-- Eric



From rminnich at lanl.gov  Tue Apr 25 17:49:13 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 09:49:13 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E50A4.9080208@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>
	<444E50A4.9080208@suehsi.de>
Message-ID: <444E44F9.3080107@lanl.gov>

I hate to say this, but it is time to reset. I think we actually may 
understand part of the problem -- the Config.lb is wrong for the mobo.

But you're in a maze of twisty little passages.

Honestly, it's hard to do this, but do a clean checkout, fix up your 
Config.lb, and let's try to get a clean serial console trace, and see if 
things make more sense.

Sorry this has been so painful. This is really my fault, I bet, since 
the config parser is so stupid.

ron



From rminnich at lanl.gov  Tue Apr 25 17:50:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 09:50:36 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <8a0c36780604250844r2ac2645av293b6d5ae15e8a9e@mail.gmail.com>
References: <20060424111110.GA28044@coresystems.de>	
	<444CEAD6.3070901@suehsi.de> <444D0F84.3060004@suehsi.de>	
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	
	<444D1DAE.8080100@suehsi.de>
	<20060424183303.GA18751@coresystems.de>	
	<444D2EF7.1030906@suehsi.de> <m3odyq2ly1.fsf@maxwell.lnxi.com>	
	<8a0c36780604250001v343caf03y7c4b00aa24ef51bd@mail.gmail.com>	
	<444E3DF1.8040607@lanl.gov>
	<8a0c36780604250844r2ac2645av293b6d5ae15e8a9e@mail.gmail.com>
Message-ID: <444E454C.2060402@lanl.gov>

Richard Smith wrote:

> .emacs.. yuck. I might try something that works in vi though.  Is
> there any really up to date documentation on the keyworks and
> structure of the PCI list other than the code?  Its not obvious
> sometimes what keywords need an end statement and which don't.

no, and if we could get someone and get some time, we'd redo the whole 
language with someone in the loop who knows how to do languages.


> 
> And there are obviously several wrong examples.

yes.

ron



From rminnich at lanl.gov  Tue Apr 25 17:56:18 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 09:56:18 -0600
Subject: [LinuxBIOS] Epia ML 5000 success
In-Reply-To: <444E46D8.3050501@zyxod.com>
References: <444E46D8.3050501@zyxod.com>
Message-ID: <444E46A2.4050208@lanl.gov>

Eric Poulsen wrote:
> Last night, I got LinuxBios + VGA working on an Epia ML 5000.  If I'm 
> feeling ambitious, I'll figure out how to get a splash logo. I'll write 
> up my efforts as a HOWTO in the near future.

can you use the linuxbios splash logo from the old V1 tree (did anyone 
bring it forward?) it has a nice logo and URL!

Do that writeup as soon as you can. Believe me, the bits will start 
leaking from your memory faster than you might like. We can sure use the 
HOWTOs!

> 
> I'd like to thank everyone here for their help -- This is one of the 
> most helpful technical mailing lists that I've been on.

Great to hear!

thanks

ron



From smithbone at gmail.com  Tue Apr 25 18:14:37 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 25 Apr 2006 11:14:37 -0500
Subject: [LinuxBIOS] Epia ML 5000 success
In-Reply-To: <444E46D8.3050501@zyxod.com>
References: <444E46D8.3050501@zyxod.com>
Message-ID: <8a0c36780604250914n68abd307tf084f1570ab7a078@mail.gmail.com>

On 4/25/06, Eric Poulsen <eric at zyxod.com> wrote:

> Last night, I got LinuxBios + VGA working on an Epia ML 5000.

Woohoo.

> If I'm
> feeling ambitious, I'll figure out how to get a splash logo.

IIRC someone did some support for this.  It was an 800x600 vesa thing
I think.  It was quite a while ago though.

> I'll write up my efforts as a HOWTO in the near future.

Please, please, please make sure you follow through on this and pester
us to get the info up on the wiki and in the HOWTO section of the
tree.

Its the only way we can keep track of the myrid of issues and
configurations that occur and continue to help.   I refer to that info
a _lot_ when I'm trying to help someone.

--
Richard A. Smith



From chris at suehsi.de  Tue Apr 25 20:04:42 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 20:04:42 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E44F9.3080107@lanl.gov>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>
	<444E44F9.3080107@lanl.gov>
Message-ID: <444E64BA.40306@suehsi.de>

Ronald G Minnich schrieb:
> I hate to say this, but it is time to reset. I think we actually may 
> understand part of the problem -- the Config.lb is wrong for the mobo.
> 
> But you're in a maze of twisty little passages.
> 
> Honestly, it's hard to do this, but do a clean checkout, fix up your 
> Config.lb, and let's try to get a clean serial console trace, and see if 
> things make more sense.
> 
> Sorry this has been so painful. This is really my fault, I bet, since 
> the config parser is so stupid.
> 
> ron
> 

Mmmh, but I get the same as before. ;)
Why should I do this? Ok, I have it done.

Fresh Checkout:
Now I use again the eaglelion/5bcm as target and have taken my old 
"fixed" Config.lb. Furthermore I have enabled the CONFIGURE_CONSOLE_VGA 
& CONFIGURE_PCI_ROM_RUN in Options.lb

and as I say, I get the same as before ;)

Should I do a run without VGA stuff.

At the moment, I have one problem.
Why fails the emulator? It seems the rest is OK for me.

chris

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fresh_1.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060425/5f89b39c/attachment.ksh>

From rminnich at lanl.gov  Tue Apr 25 18:46:21 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 10:46:21 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E64BA.40306@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>
	<444E44F9.3080107@lanl.gov> <444E64BA.40306@suehsi.de>
Message-ID: <444E525D.9030408@lanl.gov>

Christian S?hs wrote:

> Now I use again the eaglelion/5bcm as target and have taken my old 
> "fixed" Config.lb. Furthermore I have enabled the CONFIGURE_CONSOLE_VGA 
> & CONFIGURE_PCI_ROM_RUN in Options.lb

And you repaired the Config.lb as per Eric B.'s suggestions, right?

> 
> and as I say, I get the same as before ;)
> 
> Should I do a run without VGA stuff.

yes.

Sorry, I haven not had time to follow this as I should have. Try booting 
w/o emulator in linuxbios.

ron



From chris at suehsi.de  Tue Apr 25 20:25:56 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 20:25:56 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E525D.9030408@lanl.gov>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>
	<444E44F9.3080107@lanl.gov> <444E64BA.40306@suehsi.de>
	<444E525D.9030408@lanl.gov>
Message-ID: <444E69B4.6000808@suehsi.de>

Ronald G Minnich schrieb:
> Christian S?hs wrote:
> 
>> Now I use again the eaglelion/5bcm as target and have taken my old 
>> "fixed" Config.lb. Furthermore I have enabled the 
>> CONFIGURE_CONSOLE_VGA & CONFIGURE_PCI_ROM_RUN in Options.lb
> 
> 
> And you repaired the Config.lb as per Eric B.'s suggestions, right?

Well, I have to comment one "end" tag, because the buildtarget script 
fails with Erics original.

> 
>>
>> and as I say, I get the same as before ;)
>>
>> Should I do a run without VGA stuff.
> 
> 
> yes.

Ok, I will do so.
> 
> Sorry, I haven not had time to follow this as I should have. Try booting 
> w/o emulator in linuxbios.

Doesn't matter :D
> 
> ron
> 





From eric at zyxod.com  Tue Apr 25 19:26:47 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Tue, 25 Apr 2006 10:26:47 -0700
Subject: [LinuxBIOS] What's stored in the CMOS by LB?
Message-ID: <444E5BD7.2080007@zyxod.com>

The LinuxBIOS boot doesn't always work for me 100%.  Sometimes I get 
Exception 6 in LB itself (causing a halt), other times, the Kernel has 
an Exception 6, or it can't find the hard drive.

Here's the weird part: I flip back to the factory BIOS, it says "CMOS 
checksum invalid, using defaults". I hit DEL, save the settings to CMOS, 
and power down.  I flip back to LB, and all of a sudden, it's working 
fine for a while.  The kernel is a stock Ubuntu kernel with initrd that 
always works with the stock BIOS + grub loading.

1) Does LB store anything in the CMOS?
2) If yes, is there anything in there that could become corrupted and 
cause "weird issues" as described above?
3) If no, any other guesses?

-- Eric

P.S>> I haven't had any issues since I got VGA working, but I've only 
powered up the machine twice since that flashing.



From chris at suehsi.de  Tue Apr 25 20:48:00 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 20:48:00 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E69B4.6000808@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>
	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>
	<444E69B4.6000808@suehsi.de>
Message-ID: <444E6EE0.5000806@suehsi.de>

Ok,

attachment: 1 File

first --> Lb boot log
second -> lspci -vv
third --> relevant segment of current Config.lb

lspci shows the 12.4 device ???!!!! Why

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fresh_3.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060425/7640c28e/attachment.ksh>

From chris at suehsi.de  Tue Apr 25 20:57:05 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 20:57:05 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E6EE0.5000806@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>
	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>
	<444E69B4.6000808@suehsi.de> <444E6EE0.5000806@suehsi.de>
Message-ID: <444E7101.80600@suehsi.de>


> Initializing devices...
> Root Device init
> PCI: 00:00.0 init
> northbridge: northbridge_init()
> PCI: 00:09.0 init

Is it possible to initialize this device later.
I think after the southbridge is a good place.

How is this done on other boards?

> PCI: 00:12.0 init
> cs5530: southbridge_init
> PNP: 002e.0 init
> PNP: 002e.1 init
> PNP: 002e.2 init
> PNP: 002e.4 init
> PNP: 002e.5 init
> PNP: 002e.6 init
> PNP: 002e.7 init
> PNP: 002e.8 init
> PCI: 00:12.2 init
> cs5530_ide: ide_init
> PCI: 00:13.0 init
> Devices initialized



From rminnich at lanl.gov  Tue Apr 25 19:45:44 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 11:45:44 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E7101.80600@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>
	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>
	<444E69B4.6000808@suehsi.de> <444E6EE0.5000806@suehsi.de>
	<444E7101.80600@suehsi.de>
Message-ID: <444E6048.4050302@lanl.gov>

Christian S?hs wrote:
> 
>> Initializing devices...
>> Root Device init
>> PCI: 00:00.0 init
>> northbridge: northbridge_init()
>> PCI: 00:09.0 init

problem is it is a "child" of the NB.

So doing it later makes it tough. You could set up your own control and 
make the init function a no-op, and do all your init later in enable?

ron



From chris at suehsi.de  Tue Apr 25 21:30:13 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 21:30:13 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E6048.4050302@lanl.gov>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>
	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>
	<444E69B4.6000808@suehsi.de> <444E6EE0.5000806@suehsi.de>
	<444E7101.80600@suehsi.de> <444E6048.4050302@lanl.gov>
Message-ID: <444E78C5.5030300@suehsi.de>


> problem is it is a "child" of the NB.
> 
> So doing it later makes it tough. You could set up your own control and 
> make the init function a no-op, and do all your init later in enable?
> 
> ron
>

However, I think the main problem is the again listed 12.4 device
under factory bios it is "not listed"

Could that be the reason for the emulator fail. Also under factory the 
needed vga device 00:9.0 is listed as BusMaster.

Or is that normaly done later with the irq_table.

Remember, I get two different Linux-Kernel startups.
With factory bios. My ramdisks and all other stuff is booted fine.
With LB i get a VFS: Filesystem readonly

But that is another question and can resolve later :D

chris





From rminnich at lanl.gov  Tue Apr 25 20:19:51 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 12:19:51 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E78C5.5030300@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>
	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>
	<444E69B4.6000808@suehsi.de> <444E6EE0.5000806@suehsi.de>
	<444E7101.80600@suehsi.de> <444E6048.4050302@lanl.gov>
	<444E78C5.5030300@suehsi.de>
Message-ID: <444E6847.4080103@lanl.gov>

Christian S?hs wrote:

> However, I think the main problem is the again listed 12.4 device
> under factory bios it is "not listed"

ah. ah. ah.

ok. I'm sorry to be so slow here. I have only been skimming this mail, 
have not had time to read it in depth.

I would guess that somewhere in the 12.0 part there is a "magic bit" you 
can set that makes 12.4 not even visible to a config cycle -- i.e. a 
bios or os won't ever see that 12.4 as existing. This is really common 
in these types of parts. Do you know if this is the case?

ron



From eric at zyxod.com  Tue Apr 25 20:33:20 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Tue, 25 Apr 2006 11:33:20 -0700
Subject: [LinuxBIOS] Q's regarding pci_routing_fixup() in
	src/southbridge/via/vt8235/vt8235_lpc.c
Message-ID: <444E6B70.204@zyxod.com>



If the southbridge init code assigns irqs to nonexistent devices.

1) Is this slow?
2) Does it matter if it assigns an irq to a nonexistent device?

static void pci_routing_fixup(struct device *dev)
{
  printk_info("%s: dev is %p\n", __FUNCTION__, dev);

  /* set up PCI IRQ routing */
  pci_write_config8(dev, 0x55, pciIrqs[0] << 4);
  pci_write_config8(dev, 0x56, pciIrqs[1] | (pciIrqs[2] << 4) );
  pci_write_config8(dev, 0x57, pciIrqs[3] << 4);

  // firewire built into southbridge
  printk_info("setting firewire\n");
  pci_assign_irqs(0, 0x0d, pin_to_irq(firewirePins));

 [... usb, sound, ethernet, vga, pci slots ...]

  // Cardbus slot
  printk_info("setting cardbus slot\n");
  pci_assign_irqs(0, 0x0a, pin_to_irq(cbPins));

  printk_spew("%s: DONE\n", __FUNCTION__);
}



From rminnich at lanl.gov  Tue Apr 25 20:44:15 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 12:44:15 -0600
Subject: [LinuxBIOS] What's stored in the CMOS by LB?
In-Reply-To: <444E5BD7.2080007@zyxod.com>
References: <444E5BD7.2080007@zyxod.com>
Message-ID: <444E6DFF.4090208@lanl.gov>

Eric Poulsen wrote:

> 
> 1) Does LB store anything in the CMOS?

it can. It does store a few abouts about the type of boot that occurred 
(fallback or normal).


> 2) If yes, is there anything in there that could become corrupted and 
> cause "weird issues" as described above?

What's exception 6? I don't recall.

sometimes clocking info is stored in CMOS. There could be a collision here.

If you can tell more it would be good to know.

ron



From steven.goodrich at amd.com  Tue Apr 25 21:31:49 2006
From: steven.goodrich at amd.com (Goodrich,Steven)
Date: Tue, 25 Apr 2006 14:31:49 -0500
Subject: [LinuxBIOS] What's stored in the CMOS by LB?
Message-ID: <0E81348C5627674A9C0061413EBFF5F74F3E9E@SAUSEXMB2.amd.com>

Exception 6 is Invalid Opcode.  This usually means that ES:EIP is
pointing to data or to garbage (stack error?).  It could mean that
you're not at the right privilege level for the specific instruction at
CS:EIP.

      -- Steve G. 


-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ronald G Minnich
Sent: Tuesday, April 25, 2006 12:44 PM
To: Eric Poulsen
Cc: LinuxBIOS
Subject: Re: [LinuxBIOS] What's stored in the CMOS by LB?

Eric Poulsen wrote:

> 
> 1) Does LB store anything in the CMOS?

it can. It does store a few abouts about the type of boot that occurred
(fallback or normal).


> 2) If yes, is there anything in there that could become corrupted and 
> cause "weird issues" as described above?

What's exception 6? I don't recall.

sometimes clocking info is stored in CMOS. There could be a collision
here.

If you can tell more it would be good to know.

ron

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From chris at suehsi.de  Tue Apr 25 23:35:19 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 23:35:19 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E6847.4080103@lanl.gov>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>	<444E69B4.6000808@suehsi.de>
	<444E6EE0.5000806@suehsi.de>	<444E7101.80600@suehsi.de>
	<444E6048.4050302@lanl.gov>	<444E78C5.5030300@suehsi.de>
	<444E6847.4080103@lanl.gov>
Message-ID: <444E9617.7080508@suehsi.de>


> 
> I would guess that somewhere in the 12.0 part there is a "magic bit" you 
> can set that makes 12.4 not even visible to a config cycle -- i.e. a 
> bios or os won't ever see that 12.4 as existing. This is really common 
> in these types of parts. Do you know if this is the case?
>

Well, I described that somewhere.

The datasheet for cs5530 says, that the integrated graphic unit which 
seems located at 12.4 provides a ramdac and other stuff for vga output, 
like a rgb signal and digital Pixelbus, but the main graphic computing 
is done by the GXM Cyrix in this case.

This board was manufactured in many ways, like the epia itx serie.
The core is always the same, but the peripherie differs.

In my case there are pads for a LVDS connector, which seems to wired to 
the cs5530, but the connector is not "on board". You know what I mean :D

In Factory Bios you can enable/disable this feature. Called TFT/Display 
or so. I will make a lspci after enable. If I remember right, enabling 
this feature disables the onboard cyberpro graphic chip (9.0)

It could be, that both devices can not run at the same time.
More we should find this bit ;)
> ron
> 




From chris at suehsi.de  Tue Apr 25 23:46:56 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 25 Apr 2006 23:46:56 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E9617.7080508@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>	<444E69B4.6000808@suehsi.de>	<444E6EE0.5000806@suehsi.de>	<444E7101.80600@suehsi.de>	<444E6048.4050302@lanl.gov>	<444E78C5.5030300@suehsi.de>	<444E6847.4080103@lanl.gov>
	<444E9617.7080508@suehsi.de>
Message-ID: <444E98D0.3070401@suehsi.de>


> In Factory Bios you can enable/disable this feature. Called TFT/Display 
> or so. I will make a lspci after enable. If I remember right, enabling 
> this feature disables the onboard cyberpro graphic chip (9.0)

Sorry, there are no differents for enable or disable in lspci output.
I have a look to the datasheet.

chris



From rminnich at lanl.gov  Tue Apr 25 22:23:56 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 25 Apr 2006 14:23:56 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E98D0.3070401@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>	<444E69B4.6000808@suehsi.de>	<444E6EE0.5000806@suehsi.de>	<444E7101.80600@suehsi.de>	<444E6048.4050302@lanl.gov>	<444E78C5.5030300@suehsi.de>	<444E6847.4080103@lanl.gov>
	<444E9617.7080508@suehsi.de> <444E98D0.3070401@suehsi.de>
Message-ID: <444E855C.60705@lanl.gov>

Christian S?hs wrote:
> 
>> In Factory Bios you can enable/disable this feature. Called 
>> TFT/Display or so. I will make a lspci after enable. If I remember 
>> right, enabling this feature disables the onboard cyberpro graphic 
>> chip (9.0)
> 
> 
> Sorry, there are no differents for enable or disable in lspci output.
> I have a look to the datasheet.


There has to be some other control bit we're missing here.

ron



From stepan at coresystems.de  Wed Apr 26 00:35:22 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 26 Apr 2006 00:35:22 +0200
Subject: [LinuxBIOS] What's stored in the CMOS by LB?
In-Reply-To: <444E6DFF.4090208@lanl.gov>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
Message-ID: <20060425223522.GC13619@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060425 20:44]:
> > 2) If yes, is there anything in there that could become corrupted and 
> > cause "weird issues" as described above?
> 
> What's exception 6? I don't recall.
 
illegal opcode. 

I think I saw this on opteron before as well, but I don't remember the
issue. i seem to remember that writing all 0 to cmos and populating it
from scratch made it work reliably.

> sometimes clocking info is stored in CMOS. There could be a collision here.




-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From c-d.hailfinger.devel.2006 at gmx.net  Wed Apr 26 00:44:27 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 26 Apr 2006 00:44:27 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E98D0.3070401@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>	<444E69B4.6000808@suehsi.de>	<444E6EE0.5000806@suehsi.de>	<444E7101.80600@suehsi.de>	<444E6048.4050302@lanl.gov>	<444E78C5.5030300@suehsi.de>	<444E6847.4080103@lanl.gov>	<444E9617.7080508@suehsi.de>
	<444E98D0.3070401@suehsi.de>
Message-ID: <444EA64B.7050700@gmx.net>

Christian S?hs schrieb:
>>In Factory Bios you can enable/disable this feature. Called TFT/Display 
>>or so. I will make a lspci after enable. If I remember right, enabling 
>>this feature disables the onboard cyberpro graphic chip (9.0)
> 
> Sorry, there are no differents for enable or disable in lspci output.
> I have a look to the datasheet.

You wrote earlier that 12.4 is invisible under factory. If you enable
the bios option mentioned above, is it still invisible? Do you see any
difference if you use lspci -vvvxxx ?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From stepan at coresystems.de  Wed Apr 26 01:55:35 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 26 Apr 2006 01:55:35 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E98D0.3070401@suehsi.de>
References: <444E64BA.40306@suehsi.de> <444E525D.9030408@lanl.gov>
	<444E69B4.6000808@suehsi.de> <444E6EE0.5000806@suehsi.de>
	<444E7101.80600@suehsi.de> <444E6048.4050302@lanl.gov>
	<444E78C5.5030300@suehsi.de> <444E6847.4080103@lanl.gov>
	<444E9617.7080508@suehsi.de> <444E98D0.3070401@suehsi.de>
Message-ID: <20060425235535.GB19153@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060425 23:46]:
> >In Factory Bios you can enable/disable this feature. Called TFT/Display 
> >or so. I will make a lspci after enable. If I remember right, enabling 
> >this feature disables the onboard cyberpro graphic chip (9.0)
> 
> Sorry, there are no differents for enable or disable in lspci output.
> I have a look to the datasheet.
 
have you been checking with lspci -xxx ?

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From m at de-minimis.co.uk  Wed Apr 26 04:44:18 2006
From: m at de-minimis.co.uk (m at de-minimis.co.uk)
Date: Wed, 26 Apr 2006 03:44:18 +0100 (BST)
Subject: [LinuxBIOS] Overview
In-Reply-To: <20060425143536.30894.qmail@cdy.org>
References: <Pine.LNX.4.63.0604251243250.5146@thermalone.footholds.net>
	<20060425143536.30894.qmail@cdy.org>
Message-ID: <Pine.LNX.4.63.0604260316000.1855@thermalone.footholds.net>


Thanks, Richard and Peter, that helped a lot.

I'd read the intro and the FAQ but not the wiki.  I shall probe the last 
but not until (apply industrial strength matchsticks) the morning in the 
old fashioned and comfortably un-pedantic sense of the sun coming up.

My primary interest just at the moment is having a low power device server 
that I can program to take various USB devices and also do provide some 
very basic network services that need to be on all the time if they're 
going to be any use at all.  However naturally if the technology has wider 
implications I'd be interested to know where it's going, just out of 
curiosity.  The fast booting sounds attractive.

The use of the main processor kills the thought of motherboards gaining a 
second, low power purpose in their powered down mode.  I suppose one could 
use wake on lan, use the processor for a short time and then shut down 
again however that isn't ideal.  I've looked at some purpose built 
embedded devices that run on linux and I'll probably use one of those. 
There are quite a lot to choose from!

Once again, thanks for your help.

Best Wishes, Max



From ebiederman at lnxi.com  Wed Apr 26 05:58:11 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue, 25 Apr 2006 21:58:11 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444E3882.70102@suehsi.de> (
	=?iso-8859-1?q?Christian_S=FChs's_message_of?= "Tue,
	25 Apr 2006 16:56:02 +0200")
References: <20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de> <20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de> <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D1DAE.8080100@suehsi.de> <20060424183303.GA18751@coresystems.de>
	<444D2EF7.1030906@suehsi.de> <m3odyq2ly1.fsf@maxwell.lnxi.com>
	<m3fyk2i07i.fsf@maxwell.lnxi.com> <444E3882.70102@suehsi.de>
Message-ID: <m3slo16l9o.fsf@maxwell.lnxi.com>

Christian S?hs <chris at suehsi.de> writes:

> Thanks for this.

Hmm. Looking closer I do see why there is a problem.

Please disable the indicated end tag and not the one
you picked.  I think that will make the configuration 
say what you intended.

> Eric W. Biederman schrieb:
>> To be clear I think the Config.lb should read:
>> chip northbridge/amd/gx1
>> 	device pci_domain 0 on 		device pci 0.0 on end
>> 		chip drivers/pci/onboard
>> 			device pci 9.0 on end
                                          ^^^^
>> 			    register "rom_address" = "0xfffc0000"
>> 			end
>
> I had to disable this "end tag" for a successful build.

>
> # 		end


>> 		chip southbridge/amd/cs5530
>> 			device pci 12.0 on
>> 				chip superio/NSC/pc97317
>> 					device pnp 2e.0 on # Keyboard
>> 						 io 0x60 = 0x60
>> 						 io 0x62 = 0x64
>> 						irq 0x70 = 1
>
> Have a look to the attachment, the disabled PCI 12.4 device comes no longer up
> :D
>
> I think this Config.lb version is better than the old one ;)

Cool so progress is being made :)


Eric



From chris at suehsi.de  Wed Apr 26 10:52:16 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 10:52:16 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <m3slo16l9o.fsf@maxwell.lnxi.com>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D1DAE.8080100@suehsi.de>
	<20060424183303.GA18751@coresystems.de>	<444D2EF7.1030906@suehsi.de>
	<m3odyq2ly1.fsf@maxwell.lnxi.com>	<m3fyk2i07i.fsf@maxwell.lnxi.com>
	<444E3882.70102@suehsi.de> <m3slo16l9o.fsf@maxwell.lnxi.com>
Message-ID: <444F34C0.5080303@suehsi.de>

Eric W. Biederman schrieb:
> Christian S?hs <chris at suehsi.de> writes:
> 
> 
>>Thanks for this.
> 
> 
> Hmm. Looking closer I do see why there is a problem.
> 
> Please disable the indicated end tag and not the one
> you picked.  I think that will make the configuration 
> say what you intended.
> 

Ok, I will try this.

chip northbridge/amd/gx1
	device pci_domain 0 on
		device pci 0.0 on end
		chip drivers/pci/onboard
			device pci 9.0 on
			register "rom_address" = "0xfffc0000"
			end
		end
		chip southbridge/amd/cs5530
		.
		.
		.


> 
>>Eric W. Biederman schrieb:
>>
>>>To be clear I think the Config.lb should read:
>>>chip northbridge/amd/gx1
>>>	device pci_domain 0 on 		device pci 0.0 on end
>>>		chip drivers/pci/onboard
>>>			device pci 9.0 on end
> 
>                                           ^^^^
> 
>>>			    register "rom_address" = "0xfffc0000"
>>>			end
>>

But, why there are so many Configs with the same way as above?

>>I had to disable this "end tag" for a successful build.
> 
> 
>># 		end






From johnson.xu at gmail.com  Wed Apr 26 09:46:52 2006
From: johnson.xu at gmail.com (Zhen Xu)
Date: Wed, 26 Apr 2006 15:46:52 +0800
Subject: [LinuxBIOS] Want to know whether linuxbios works on my PC
Message-ID: <2ea7d6950604260046rce499cyafe0b6024c4cdbdb@mail.gmail.com>

Hi, all,

I'm interested in linuxbios and planning to do some experiments with it.
However, I don't know whether linuxbios works on my PC. It's a IBM
thinkcentre 8114, chip set is Intel 945G and the result of 'listpci -vvv' is
as below:

00:00.0 Host bridge: Intel Corp.: Unknown device 2770 (rev 02)
    Subsystem: IBM: Unknown device 02f6
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-
    Latency: 0
    Capabilities: [e0] #09 [5109]

00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2772 (rev 02)
(prog-if 00 [VGA])
    Subsystem: IBM: Unknown device 02f6
    Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
    Interrupt: pin A routed to IRQ 5
    Region 0: Memory at d0100000 (32-bit, non-prefetchable) [size=512K]
    Region 1: I/O ports at 30c0 [size=8]
    Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
    Region 3: Memory at d0180000 (32-bit, non-prefetchable) [size=256K]
    Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0
Enable-
        Address: 00000000  Data: 0000
    Capabilities: [d0] Power Management version 2
        Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:02.1 Display controller: Intel Corp.: Unknown device 2776 (rev 02)
    Subsystem: IBM: Unknown device 02f6
    Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
    Region 0: Memory at 20000000 (32-bit, non-prefetchable) [disabled]
[size=512K]
    Capabilities: [d0] Power Management version 2
        Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1b.0 Class 0403: Intel Corp.: Unknown device 27d8 (rev 01)
    Subsystem: IBM: Unknown device 02f6
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
    Latency: 0, cache line size 08
    Interrupt: pin A routed to IRQ 9
    Region 0: Memory at d01c0000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [50] Power Management version 2
        Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-
    Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable-
        Address: 0000000000000000  Data: 0000
    Capabilities: [70] #10 [0091]

00:1c.0 PCI bridge: Intel Corp.: Unknown device 27d0 (rev 01) (prog-if 00
[Normal decode])
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
    Latency: 0, cache line size 08
    Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
    I/O behind bridge: 00004000-00004fff
    Memory behind bridge: d0000000-d00fffff
    Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
    BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
    Capabilities: [40] #10 [0141]
    Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0
Enable-
        Address: 00000000  Data: 0000
    Capabilities: [90] #0d [0000]
    Capabilities: [a0] Power Management version 2
        Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
        Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

00:1c.1 PCI bridge: Intel Corp.: Unknown device 27d2 (rev 01) (prog-if 00
[Normal decode])
    Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
    Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
    I/O behind bridge: 00000000-00000fff
    Memory behind bridge: 00000000-000fffff
    Prefetchable memory behind bridge: 0000000000000000-0000000000000000
    BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
    Capabilities: [40] #10 [0141]
    Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0
Enable-
        Address: 00000000  Data: 0000
    Capabilities: [90] #0d [0000]
    Capabilities: [a0] Power Management version 2
        Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
        Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

00:1d.0 USB Controller: Intel Corp.: Unknown device 27c8 (rev 01) (prog-if
00 [UHCI])
    Subsystem: IBM: Unknown device 02f6
    Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Interrupt: pin A routed to IRQ 11
    Region 4: I/O ports at 3000 [size=32]

00:1d.1 USB Controller: Intel Corp.: Unknown device 27c9 (rev 01) (prog-if
00 [UHCI])
    Subsystem: IBM: Unknown device 02f6
    Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Interrupt: pin B routed to IRQ 9
    Region 4: I/O ports at 3020 [size=32]

00:1d.2 USB Controller: Intel Corp.: Unknown device 27ca (rev 01) (prog-if
00 [UHCI])
    Subsystem: IBM: Unknown device 02f6
    Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Interrupt: pin C routed to IRQ 11
    Region 4: I/O ports at 3040 [size=32]

00:1d.3 USB Controller: Intel Corp.: Unknown device 27cb (rev 01) (prog-if
00 [UHCI])
    Subsystem: IBM: Unknown device 02f6
    Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Interrupt: pin D routed to IRQ 5
    Region 4: I/O ports at 3060 [size=32]

00:1d.7 USB Controller: Intel Corp.: Unknown device 27cc (rev 01) (prog-if
20 [EHCI])
    Subsystem: IBM: Unknown device 02f6
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Interrupt: pin A routed to IRQ 11
    Region 0: Memory at d03c4000 (32-bit, non-prefetchable) [size=1K]
    Capabilities: [50] Power Management version 2
        Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-
    Capabilities: [58] #0a [20a0]

00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev e1) (prog-if
01 [Subtractive decode])
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
    Latency: 0
    Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=32
    I/O behind bridge: 0000f000-00000fff
    Memory behind bridge: fff00000-000fffff
    Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
    BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
    Capabilities: [50] #0d [0000]

00:1f.0 ISA bridge: Intel Corp.: Unknown device 27b8 (rev 01)
    Subsystem: IBM: Unknown device 02f6
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Capabilities: [e0] #09 [100c]

00:1f.2 IDE interface: Intel Corp.: Unknown device 27c0 (rev 01) (prog-if 80
[Master])
    Subsystem: IBM: Unknown device 02f6
    Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Interrupt: pin B routed to IRQ 0
    Region 0: I/O ports at <unassigned>
    Region 1: I/O ports at <unassigned>
    Region 2: I/O ports at <unassigned>
    Region 3: I/O ports at <unassigned>
    Region 4: I/O ports at 30b0 [size=16]
    Capabilities: [70] Power Management version 2
        Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold-)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1f.3 SMBus: Intel Corp.: Unknown device 27da (rev 01)
    Subsystem: IBM: Unknown device 02f6
    Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Interrupt: pin B routed to IRQ 9
    Region 4: I/O ports at 3080 [size=32]

02:00.0 Ethernet controller: Intel Corp.: Unknown device 108c (rev 03)
    Subsystem: IBM: Unknown device 02f6
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
    Latency: 0, cache line size 08
    Interrupt: pin A routed to IRQ 16
    Region 0: Memory at d0080000 (32-bit, non-prefetchable) [size=128K]
    Region 1: Memory at d0000000 (32-bit, non-prefetchable) [size=512K]
    Region 2: I/O ports at 4000 [size=32]
    Capabilities: [c8] Power Management version 2
        Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
        Status: D0 PME-Enable+ DSel=0 DScale=1 PME-
    Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable-
        Address: 0000000000000000  Data: 0000
    Capabilities: [e0] #10 [0001]

Best Regards.

Xu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060426/700d9ea2/attachment.html>

From chris at suehsi.de  Wed Apr 26 11:34:26 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 11:34:26 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444F34C0.5080303@suehsi.de>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D1DAE.8080100@suehsi.de>	<20060424183303.GA18751@coresystems.de>	<444D2EF7.1030906@suehsi.de>	<m3odyq2ly1.fsf@maxwell.lnxi.com>	<m3fyk2i07i.fsf@maxwell.lnxi.com>	<444E3882.70102@suehsi.de>
	<m3slo16l9o.fsf@maxwell.lnxi.com> <444F34C0.5080303@suehsi.de>
Message-ID: <444F3EA2.1000509@suehsi.de>


> 
> Ok, I will try this.
> 
> chip northbridge/amd/gx1
> 	device pci_domain 0 on
> 		device pci 0.0 on end
> 		chip drivers/pci/onboard
> 			device pci 9.0 on
> 			register "rom_address" = "0xfffc0000"
> 			end
> 		end
> 		chip southbridge/amd/cs5530
> 		.
> 		.
> 		.
> 

This fails, the buildsript stops with a warning like.
Only chips can have a register.

than I have tried this:

  chip northbridge/amd/gx1
  	device pci_domain 0 on
  		device pci 0.0 on end
		device pci 9.0 on
  		chip drivers/pci/onboard
  			register "rom_address" = "0xfffc0000"
  			end
  		end
  		chip southbridge/amd/cs5530

the right device is allocated, the emulator is not entered

I also tried this:

chip northbridge/amd/gx1
  	device pci_domain 0 on
  		device pci 0.0 on end
		device pci 9.0 on
  		chip drivers/pci/onboard
			device pci 9.0 on end
  			register "rom_address" = "0xfffc0000"
  			end
  		end
  		chip southbridge/amd/cs5530

This results in the same as before.

chris



From chris at suehsi.de  Wed Apr 26 11:59:25 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 11:59:25 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444EA64B.7050700@gmx.net>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>	<444E69B4.6000808@suehsi.de>	<444E6EE0.5000806@suehsi.de>	<444E7101.80600@suehsi.de>	<444E6048.4050302@lanl.gov>	<444E78C5.5030300@suehsi.de>	<444E6847.4080103@lanl.gov>	<444E9617.7080508@suehsi.de>	<444E98D0.3070401@suehsi.de>
	<444EA64B.7050700@gmx.net>
Message-ID: <444F447D.1040108@suehsi.de>


> 
> 
> You wrote earlier that 12.4 is invisible under factory. If you enable
> the bios option mentioned above, is it still invisible? Do you see any
> difference if you use lspci -vvvxxx ?

Yes, device 00:12.4 is not shown in both cases, it is totally ignored.
There is nothing about that. Same with cat /proc/pci no 12.4 (or 18.4) 
under factory bios.

I had a look with "modbin" to the factory bios. There is a hidden field 
called "multiple monitor support". I know that option from other boards. 
You can choosen "no Onboard" "PCI first" and "Both" if I remember right. 
As I say this is disabled and therefor not shown in Bios setup.
Both "Bios defaults" and "setup defaults" are set to "no Onboard"

I think this disables normaly the "real onboard" vga.
As I say, the 00:9.0 device is more like a integrated pci card on board.

I should also say, that this mobo has no real pci slots, there is an 
expansion slot where you can put in a riser card (ISA/PCI Riser card). 
But it should be the same as a pci bus.

I'm not sure, but why are there differences between lspci and
cat /proc/pci . I get other device numbers with cat

device 12 is 18
device 13 is 19

is that normal? the functions are the same

chris

> 
> 
> Regards,
> Carl-Daniel




From chris at suehsi.de  Wed Apr 26 12:22:47 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 12:22:47 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444F447D.1040108@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>	<444E69B4.6000808@suehsi.de>	<444E6EE0.5000806@suehsi.de>	<444E7101.80600@suehsi.de>	<444E6048.4050302@lanl.gov>	<444E78C5.5030300@suehsi.de>	<444E6847.4080103@lanl.gov>	<444E9617.7080508@suehsi.de>	<444E98D0.3070401@suehsi.de>	<444EA64B.7050700@gmx.net>
	<444F447D.1040108@suehsi.de>
Message-ID: <444F49F7.8080302@suehsi.de>


> I had a look with "modbin" to the factory bios. There is a hidden field 
> called "multiple monitor support". I know that option from other boards. 
> You can choosen "no Onboard" "PCI first" and "Both" if I remember right. 

sorry not "Both", the third option is called "M/B First"

chris



From ebiederman at lnxi.com  Wed Apr 26 11:15:09 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed, 26 Apr 2006 03:15:09 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444F3EA2.1000509@suehsi.de> (
	=?iso-8859-1?q?Christian_S=FChs's_message_of?= "Wed,
	26 Apr 2006 11:34:26 +0200")
References: <20060424111110.GA28044@coresystems.de>
	<444CD38F.5090502@suehsi.de> <20060424122826.GA4308@coresystems.de>
	<444CD912.20607@suehsi.de> <20060424124236.GA9541@coresystems.de>
	<444CE768.1010606@suehsi.de> <444CEAD6.3070901@suehsi.de>
	<444D0F84.3060004@suehsi.de>
	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>
	<444D1DAE.8080100@suehsi.de> <20060424183303.GA18751@coresystems.de>
	<444D2EF7.1030906@suehsi.de> <m3odyq2ly1.fsf@maxwell.lnxi.com>
	<m3fyk2i07i.fsf@maxwell.lnxi.com> <444E3882.70102@suehsi.de>
	<m3slo16l9o.fsf@maxwell.lnxi.com> <444F34C0.5080303@suehsi.de>
	<444F3EA2.1000509@suehsi.de>
Message-ID: <m3lktswvdu.fsf@maxwell.lnxi.com>

Christian S?hs <chris at suehsi.de> writes:

>> Ok, I will try this.
>> chip northbridge/amd/gx1
>> 	device pci_domain 0 on
>> 		device pci 0.0 on end
>> 		chip drivers/pci/onboard
>> 			device pci 9.0 on
>> 			register "rom_address" = "0xfffc0000"
>> 			end
>> 		end
>> 		chip southbridge/amd/cs5530
>> 		.
>> 		.
>> 		.
>>
>
> This fails, the buildsript stops with a warning like.
> Only chips can have a register.

Ok. Sorry, the I had forgotten that twist.
I'm just trying to sort out the indentation so that part is
readable.


So what I should have suggested was simply:
> chip northbridge/amd/gx1
>  	device pci_domain 0 on
>  		device pci 0.0 on end
>  		chip drivers/pci/onboard
>  			device pci 9.0 on end
>  			register "rom_address" = "0xfffc0000"
>  		end
>  		chip southbridge/amd/cs5530
>  		.
>  		.
>  		.

So the chip which has the name 9.0 has a register rom_address.

And with that I think I have reached my limit of usefulness.

Eric



From chris at suehsi.de  Wed Apr 26 13:17:16 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 13:17:16 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <m3lktswvdu.fsf@maxwell.lnxi.com>
References: <20060424111110.GA28044@coresystems.de>	<444CD38F.5090502@suehsi.de>
	<20060424122826.GA4308@coresystems.de>	<444CD912.20607@suehsi.de>
	<20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>
	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D1DAE.8080100@suehsi.de>
	<20060424183303.GA18751@coresystems.de>	<444D2EF7.1030906@suehsi.de>
	<m3odyq2ly1.fsf@maxwell.lnxi.com>	<m3fyk2i07i.fsf@maxwell.lnxi.com>
	<444E3882.70102@suehsi.de>	<m3slo16l9o.fsf@maxwell.lnxi.com>
	<444F34C0.5080303@suehsi.de>	<444F3EA2.1000509@suehsi.de>
	<m3lktswvdu.fsf@maxwell.lnxi.com>
Message-ID: <444F56BC.8050906@suehsi.de>


> 
> So the chip which has the name 9.0 has a register rom_address.
>

Well, it is a onboard graphic chip "cyberpro 5000"

> And with that I think I have reached my limit of usefulness.
> 
> Eric
> 

Mmmh, I think LB does all in the right way.

The right device is allocated, the image is copy and the emulator is 
entered, now the question is.
Why fails the emulator. It seems, that there happens nothing.
Remember that. There is no debug output, but it should.

So, what is wrong.

Is it the 12.4, which eventually block something. Or is any other stuff 
not right.

I think the 12.4 is the problem, because if I try the image with 
testbios all seems to work fine. But I have to disable the 12.4 totally 
before. That means command=0 with setpci send to 12.4
After that, there is no I/O or MEM anywhere allocated.

If I do a boot know with the current config and disable the VGA stuff, 
all is done well, but the 12.4 device has a MEM+ shown with lspci.

So I think, that causes the problems with enabled emulator, because if I 
done a testbios run in that state, it fails too ;) with rare debug 
output (ca. 10 lines)

Question is now, in which state of LB is for 12.4 MEM allocated, while 
it is disabled?

i.e there are two other devices on 12.0 (12.1/12.3) and these ones are 
disabled, too. and this works fine.

chris



From stepan at coresystems.de  Wed Apr 26 12:32:09 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 26 Apr 2006 12:32:09 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444F56BC.8050906@suehsi.de>
References: <20060424183303.GA18751@coresystems.de>
	<444D2EF7.1030906@suehsi.de> <m3odyq2ly1.fsf@maxwell.lnxi.com>
	<m3fyk2i07i.fsf@maxwell.lnxi.com> <444E3882.70102@suehsi.de>
	<m3slo16l9o.fsf@maxwell.lnxi.com> <444F34C0.5080303@suehsi.de>
	<444F3EA2.1000509@suehsi.de> <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de>
Message-ID: <20060426103209.GA14218@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060426 13:17]:
> The right device is allocated, the image is copy and the emulator is 
> entered, now the question is.
> Why fails the emulator. It seems, that there happens nothing.
> Remember that. There is no debug output, but it should.
 
LinuxBIOSv2/src/devices/emulator/x86emu/debug.h

there's:

//#define DEBUG 0
#undef DEBUG


change that to 

#define DEBUG 1
and enable the ...trace_on() in biosemu.c again

S.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Wed Apr 26 16:12:29 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 16:12:29 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060426103209.GA14218@coresystems.de>
References: <20060424183303.GA18751@coresystems.de>	<444D2EF7.1030906@suehsi.de>
	<m3odyq2ly1.fsf@maxwell.lnxi.com>	<m3fyk2i07i.fsf@maxwell.lnxi.com>
	<444E3882.70102@suehsi.de>	<m3slo16l9o.fsf@maxwell.lnxi.com>
	<444F34C0.5080303@suehsi.de>	<444F3EA2.1000509@suehsi.de>
	<m3lktswvdu.fsf@maxwell.lnxi.com>	<444F56BC.8050906@suehsi.de>
	<20060426103209.GA14218@coresystems.de>
Message-ID: <444F7FCD.3070406@suehsi.de>


> LinuxBIOSv2/src/devices/emulator/x86emu/debug.h
> 
> there's:
> 
> //#define DEBUG 0
> #undef DEBUG
> 
> 
> change that to 
> 
> #define DEBUG 1
> and enable the ...trace_on() in biosemu.c again
> 
> S.
> 

Ok, here is the output.

I hope you understand this. :D

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug_2.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060426/b2ad9ba2/attachment.ksh>

From chris at suehsi.de  Wed Apr 26 16:56:15 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 16:56:15 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444F7FCD.3070406@suehsi.de>
References: <20060424183303.GA18751@coresystems.de>	<444D2EF7.1030906@suehsi.de>	<m3odyq2ly1.fsf@maxwell.lnxi.com>	<m3fyk2i07i.fsf@maxwell.lnxi.com>	<444E3882.70102@suehsi.de>	<m3slo16l9o.fsf@maxwell.lnxi.com>	<444F34C0.5080303@suehsi.de>	<444F3EA2.1000509@suehsi.de>	<m3lktswvdu.fsf@maxwell.lnxi.com>	<444F56BC.8050906@suehsi.de>	<20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de>
Message-ID: <444F8A0F.1050607@suehsi.de>


> PCI: 00:09.0 init
> rom address for PCI: 00:09.0 = fffc0000
> copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes
			     ^^^^^^	   ^^^^^    ^^^^^^
remember my Image is located at first of my 256K flash part
and is 32K big, are these values correct.

0xfffc0000 i don't know
0xc0000 should be correct
0x8000 yes

Mmmh, the pci_rom_run detected the right signatur on 0xfffc0000
also this should be correct to.

> entering emulator
> halt_sys: file /root/src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4956
> halted
> 	AX=0048  BX=0000  CX=0000  DX=0080  SP=fff8  BP=0000  SI=0000  DI=0000
> 	DS=0040  ES=0000  SS=c000  CS=c000  IP=0005   NV UP DI PL NZ NA PO NC 
> c000:0005 ff                  ILLEGAL DECODING OF OPCODE FF	PCI: 00:12.0 init
> PNP: 002e.0 init
> PNP: 002e.1 init
> PNP: 002e.2 init


Waaah. Ok, how can I verify, that the vga.bios image is proper copied to 
0xc0000. I think the emulator reads from this adress, right?

Now, where the emu is stopping with halt_sys. I'm able to read out 
0xc0000 with dd and voila, there is definitivly not the vga.bios.

$ dd if=/dev/mem of=vga.bios bs=1 count=32768 skip=786432

I get garbage :D

chris








From stepan at coresystems.de  Wed Apr 26 16:05:26 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 26 Apr 2006 16:05:26 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444F8A0F.1050607@suehsi.de>
References: <m3fyk2i07i.fsf@maxwell.lnxi.com> <444E3882.70102@suehsi.de>
	<m3slo16l9o.fsf@maxwell.lnxi.com> <444F34C0.5080303@suehsi.de>
	<444F3EA2.1000509@suehsi.de> <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de>
	<20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
Message-ID: <20060426140526.GA3910@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060426 16:56]:
> Waaah. Ok, how can I verify, that the vga.bios image is proper copied to 
> 0xc0000. I think the emulator reads from this adress, right?
> 
> Now, where the emu is stopping with halt_sys. I'm able to read out 
> 0xc0000 with dd and voila, there is definitivly not the vga.bios.

test with applied patch.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
-------------- next part --------------
Index: src/devices/emulator/biosemu.c
===================================================================
--- src/devices/emulator/biosemu.c	(revision 2273)
+++ src/devices/emulator/biosemu.c	(working copy)
@@ -328,6 +328,11 @@
 
 	printk_info("entering emulator\n");
 
+	for (i=0xc0000; i< 0xc8000; i++) {
+		printk_debug("%02x ", rdb(i));
+		if((i&16)==15) printk_debug("\n");
+	}
+	
 	X86EMU_exec();
 #endif
 }

From chris at suehsi.de  Wed Apr 26 18:35:42 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 18:35:42 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060426140526.GA3910@coresystems.de>
References: <m3fyk2i07i.fsf@maxwell.lnxi.com>
	<444E3882.70102@suehsi.de>	<m3slo16l9o.fsf@maxwell.lnxi.com>
	<444F34C0.5080303@suehsi.de>	<444F3EA2.1000509@suehsi.de>
	<m3lktswvdu.fsf@maxwell.lnxi.com>	<444F56BC.8050906@suehsi.de>	<20060426103209.GA14218@coresystems.de>	<444F7FCD.3070406@suehsi.de>
	<444F8A0F.1050607@suehsi.de> <20060426140526.GA3910@coresystems.de>
Message-ID: <444FA15E.8050408@suehsi.de>


>>Now, where the emu is stopping with halt_sys. I'm able to read out 
>>0xc0000 with dd and voila, there is definitivly not the vga.bios.
> 
> 
> test with applied patch.
> 
> 

Thanks, the output is as expected. There are only FF

What about the irq_table, which is later copied. The verify fails to.
For the same reason ?? CONFIG_COMPRESSED is default 1 or 0 ???

I don't have those line. Ok, I will look to the Config Options page for 
default,
but vga.bios is merged after the compile stuff and not compressed.

Furthermore,
my readonly filesystem later. That should have a reason. Is there 
something with the RAM.

chris


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug_3.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060426/eb806972/attachment.ksh>

From stepan at coresystems.de  Wed Apr 26 17:22:11 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 26 Apr 2006 17:22:11 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444FA15E.8050408@suehsi.de>
References: <m3slo16l9o.fsf@maxwell.lnxi.com> <444F34C0.5080303@suehsi.de>
	<444F3EA2.1000509@suehsi.de> <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de>
	<20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
Message-ID: <20060426152211.GA13826@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060426 18:35]:
> Thanks, the output is as expected. There are only FF
> 
> What about the irq_table, which is later copied. The verify fails to.
> For the same reason ?? CONFIG_COMPRESSED is default 1 or 0 ???
 
No, different reason. I guess the ram at 0xc0000 is not visible or
writable. The datasheet usually knows how to make that area writable.



Stefan.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Wed Apr 26 18:44:07 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 18:44:07 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060426152211.GA13826@coresystems.de>
References: <m3slo16l9o.fsf@maxwell.lnxi.com> <444F34C0.5080303@suehsi.de>
	<444F3EA2.1000509@suehsi.de> <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de>
	<20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de>
Message-ID: <444FA357.7000907@suehsi.de>


>>What about the irq_table, which is later copied. The verify fails to.
>>For the same reason ?? CONFIG_COMPRESSED is default 1 or 0 ???
> 
>  
> No, different reason. I guess the ram at 0xc0000 is not visible or
> writable. The datasheet usually knows how to make that area writable.
>

Datasheet of which part ??
I have them all :D

chris

> 
> 
> Stefan.
> 




From smithbone at gmail.com  Wed Apr 26 17:53:25 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 10:53:25 -0500
Subject: [LinuxBIOS] Want to know whether linuxbios works on my PC
In-Reply-To: <2ea7d6950604260046rce499cyafe0b6024c4cdbdb@mail.gmail.com>
References: <2ea7d6950604260046rce499cyafe0b6024c4cdbdb@mail.gmail.com>
Message-ID: <8a0c36780604260853h67e2d9d6ufd7457cafe0d3ace@mail.gmail.com>

On 4/26/06, Zhen Xu <johnson.xu at gmail.com> wrote:

> Hi, all,
>
>  I'm interested in linuxbios and planning to do some experiments with it.
> However, I don't know whether linuxbios works on my PC. It's a IBM
> thinkcentre 8114, chip set is Intel 945G and the result of 'listpci -vvv' is
> as below:

I seem to remember that we haven't been able to get any good Docs on
this chipset.  Its not in the tree.

--
Richard A. Smith



From eric at zyxod.com  Wed Apr 26 18:02:12 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 09:02:12 -0700
Subject: [LinuxBIOS] Kernel crash output (was: What's stored in the CMOS by
	LB?)
In-Reply-To: <444E6DFF.4090208@lanl.gov>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
Message-ID: <444F9984.6040207@zyxod.com>

My kernel crash issue is attached below.  This one isn't an Exception 6
(that I can tell), but it's one I've seen before.  This happened twice
in a row, after the machine had been off for a while.  As usual,
flipping to the factory BIOS, seeing the "corrupt CMOS" message, and
re-writing the CMOS fixed the issue.  I immediately flipped back to LB,
and it worked as expected.

I looked at the CMOS code in src/pc80/mc146818rtc.c.  The code that
prints "Invalid CMOS LB checksum" is found immediately after a call to
CMOS_WRITE, then it sets the checksum.  If you remove the comments in
the source, the following two code snippets are contiguous, but I've
inserted comments.


The following works ok:
===
  checksum_invalid =
!rtc_checksum_valid(PC_CKS_RANGE_START,PC_CKS_RANGE_END,PC_CKS_LOC);

  if (invalid || cmos_invalid || checksum_invalid) {
    printk_warning("RTC:%s%s%s zeroing cmos\n",
      invalid?" Clear requested":"",
      cmos_invalid?" Power Problem":"",
      checksum_invalid?" Checksum invalid":"");
===

The following fails.  You can see at the end of this block, there is a
routine to set the checksum.  Here's my guess: the CMOS_WRITE commands
below do not work correctly, causing the checksum error.  A valid
checksum is computed and written, which prevents the error from
occurring above on the next reboot. OR, 'Invalid CMOS LB checksum' is
perfectly normal because the checksum should be invalid after a write.
In the case of the latter, the checksumming that occurs below is
pointless, since it's about to be written anyway.
===

  /* Setup the real time clock */
  CMOS_WRITE(RTC_CONTROL_DEFAULT, RTC_CONTROL);
  /* Setup the frequency it operates at */
  CMOS_WRITE(RTC_FREQ_SELECT_DEFAULT, RTC_FREQ_SELECT);

  /* See if there is a LB CMOS checksum error */
  checksum_invalid =
!rtc_checksum_valid(LB_CKS_RANGE_START,LB_CKS_RANGE_END,LB_CKS_LOC);
  if(checksum_invalid)
    printk_debug("Invalid CMOS LB checksum\n");

  /* Make certain we have a valid checksum */
  rtc_set_checksum(PC_CKS_RANGE_START,PC_CKS_RANGE_END,PC_CKS_LOC);

===

-- Eric

Ronald G Minnich wrote:
> Eric Poulsen wrote:
>
>>
>> 1) Does LB store anything in the CMOS?
>
> it can. It does store a few abouts about the type of boot that 
> occurred (fallback or normal).
>
>
>> 2) If yes, is there anything in there that could become corrupted and 
>> cause "weird issues" as described above?
>
> What's exception 6? I don't recall.
>
> sometimes clocking info is stored in CMOS. There could be a collision 
> here.
>
> If you can tell more it would be good to know.
>
> ron
>



0

LinuxBIOS-1.1.8.0Fallback Tue Apr 25 20:17:47 PDT 2006 starting...
Enabling mainboard devices
Enabling shadow ram
vt8623 init starting
Detecting Memory
Number of Banks 04
Number of Rows 0d
Priamry DRAM width08
No Columns 0a
MA type e0
Bank 0 (*16 Mb) 10
No Physical Banks 01
Total Memory (*16 Mb) 10
CAS Supported 2 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)75
Starting at CAS 3
We can do CAS 2.5
We can do CAS 2
tRP 48
tRCD 48
tRAS 28
Low Bond 00  High Bondc7  Setting DQS delay84vt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00
50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00
60:02 ff 00 30 d6 32 01 20 42 2d 43 58 00 44 00 00
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 02
80:0f 65 00 00 80 00 00 00 02 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00
b0:00 00 00 00 40 00 00 00 a8 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00
AGP
Doing MTRR init.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Tue Apr 25 20:17:47 PDT 2006 booting...
clocks_per_usec: 838
Enumerating buses...
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123] enabled
PCI: 00:01.0 [1106/b091] enabled
Disabling static device: PCI: 00:0a.0
Disabling static device: PCI: 00:0a.1
In vt8235_enable 1106 3038.
PCI: 00:10.0 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 3104.
PCI: 00:10.3 [1106/3104] enabled
In vt8235_enable 1106 3177.
Initialising Devices
PCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106 0571.
PCI: 00:11.1 [1106/0571] enabled
In vt8235_enable 1106 3059.
PCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122] enabled
PCI: pci_scan_bus returning with max=01
vt1211 enabling PNP devices.
PNP: 002e.0 enabled
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
vt1211 enabling PNP devices.
PNP: 002e.b enabled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resources...
I would set ram size to 0x40000 Kbytes
PCI: 00:10.0 20 <- [0x0000001800 - 0x000000181f] io
PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f] io
PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io
PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff] mem
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 140
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <- 141
PCI: 00:10.1 subsystem <- 00/00
PCI: 00:10.1 cmd <- 141
PCI: 00:10.2 subsystem <- 00/00
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.0 - enabling
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PCI: 00:11.1 cmd <- 147
PCI: 00:11.5 subsystem <- 00/00
PCI: 00:11.5 cmd <- 141
PCI: 00:12.0 cmd <- 1c3
done.
Initializing devices...
Root Device init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
Invalid CMOS LB checksum
pci_routing_fixup: dev is 00010fa0
setting firewire
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.2
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
setting cardbus slot
setting riser slot
PNP: 002e.0 init
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 init
PCI: 00:12.0 init
Configuring VIA Rhine LAN
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Centaur device 673
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000
PCI: 00:01.0 init
VT8623 AGP random fixup ...
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0x100
biosint: INT# 0x15
biosint: eax 0x5f00 ebx 0x18538 ecx 0x17fa0 edx 0xa
biosint: ebp 0x17f70 esp 0xff2 edi 0xecf0 esi 0x18538
biosint:  ip 0x637f   cs 0xc000  flags 0x46
biosint: INT# 0x1a
biosint: eax 0xb108 ebx 0x10000 ecx 0x10000 edx 0x3d5
biosint: ebp 0x17f70 esp 0xfcc edi 0xf6 esi 0x155eb
biosint:  ip 0x40da   cs 0xc000  flags 0x46
0xb108: bus 0 devfn 0x0 reg 0xf6 val 0x12
biosint: INT# 0x15
biosint: eax 0x5f0f ebx 0x18538 ecx 0x7fa0 edx 0x3d5
biosint: ebp 0x17f70 esp 0xfee edi 0x44 esi 0x18538
biosint:  ip 0x647e   cs 0xc000  flags 0x7
biosint: INT# 0x15
biosint: eax 0x5f02 ebx 0x18538 ecx 0x7f01 edx 0x3d5
biosint: ebp 0x17f70 esp 0xfdc edi 0x44 esi 0x18538
biosint:  ip 0x63cb   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f18 ebx 0x18501 ecx 0x7fa0 edx 0x3d5
biosint: ebp 0x17f70 esp 0xfde edi 0x44 esi 0x18538
biosint:  ip 0x6496   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f06 ebx 0x18001 ecx 0x1 edx 0x0
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0x14672
biosint:  ip 0x63dc   cs 0xc000  flags 0x246
biosint: INT# 0x15
biosint: eax 0x5f08 ebx 0x10d01 ecx 0x8301 edx 0xd4
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0x10d0e
biosint:  ip 0x63e8   cs 0xc000  flags 0x246
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
done.
ACPI: Writing ACPI tables at f0400...
ACPI:     * FACS
ACPI:     * DSDT @ 000f049e Length 3f0
ACPI:     * FADT
ACPI: added table 1/5 Length now 40
ACPI: done.
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000b80  checksum 68b7

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x23760 offset 0xc0 filesize 0x96e8
(cleaned up) New segment addr 0x100000 size 0x23760 offset 0xc0 filesize
0x96e8
New segment addr 0x123760 size 0x48 offset 0x97c0 filesize 0x48
(cleaned up) New segment addr 0x123760 size 0x48 offset 0x97c0 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000023760
filesz: 0x00000000000096e8
Clearing Segment: addr: 0x00000000001096e8 memsz: 0x000000000001a078
Loading Segment: addr: 0x0000000000123760 memsz: 0x0000000000000048
filesz: 0x0000000000000048
Jumping to boot code at 0x107860
FILO version 0.4.2 (root at embedded) Tue Apr 25 20:15:07 PDT 2006
boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200
hda: LBA 80GB: WDC WD800JB-00FMA0
Mounted ext2fs
Found Linux version 2.6.16.5 (root at Proteus) #3 Sun Apr 16 21:06:34 PDT
2006 bzImage.
Loading kernel... ok
Jumping to entry point...
[17179569.184000] Linux version 2.6.16.5 (root at Proteus) (gcc version
4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)) #3 Sun Apr 16
21:06:34 PDT 2006
[17179569.184000] BIOS-provided physical RAM map:
[17179569.184000]  BIOS-e820: 0000000000000be0 - 00000000000a0000 (usable)
[17179569.184000]  BIOS-e820: 0000000000100000 - 000000000e000000 (usable)
[17179569.184000] 0MB HIGHMEM available.
[17179569.184000] 224MB LOWMEM available.
[17179569.184000] DMI not present or invalid.
[17179569.184000] ACPI: PM-Timer IO Port: 0x408
[17179569.184000] Allocating PCI resources starting at 10000000 (gap:
0e000000:f2000000)
[17179569.184000] Built 1 zonelists
[17179569.184000] Kernel command line: root=/dev/hda1 console=tty0
console=ttyS0,115200
[17179569.184000] No local APIC present or hardware disabled
[17179569.184000] Initializing CPU#0
[17179569.184000] PID hash table entries: 1024 (order: 10, 16384 bytes)
[17179569.184000] Detected 533.193 MHz processor.
[17179569.184000] Using pmtmr for high-res timesource
[17179569.184000] Console: colour VGA+ 80x25
[17179571.984000] Dentry cache hash table entries: 32768 (order: 5,
131072 bytes)
[17179571.992000] Inode-cache hash table entries: 16384 (order: 4, 65536
bytes)
[17179572.052000] Memory: 223968k/229376k available (1628k kernel code,
4992k reserved, 604k data, 232k init, 0k highmem)
[17179572.064000] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[17179572.152000] Calibrating delay using timer specific routine..
1068.40 BogoMIPS (lpj=2136811)
[17179572.160000] Security Framework v1.0.0 initialized
[17179572.164000] SELinux:  Disabled at boot.
[17179572.168000] Mount-cache hash table entries: 512
[17179572.172000] CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32
bytes/line)
[17179572.180000] CPU: L2 Cache: 64K (32 bytes/line)
[17179572.184000] CPU: Centaur VIA Samuel 2 stepping 03
[17179572.192000] Checking 'hlt' instruction... OK.
[17179572.268000] ACPI: setting ELCR to 0020 (from 0220)
[17179572.276000] NET: Registered protocol family 16
[17179572.280000] EISA bus registered
[17179572.284000] ACPI: bus type pci registered
[17179572.340000] Unable to handle kernel paging request at virtual
address 6de8d753
[17179572.340000]  printing eip:
[17179572.340000] c00fab46
[17179572.340000] *pde = 00000000
[17179572.340000] Oops: 0002 [#1]
[17179572.340000] Modules linked in:
[17179572.340000] CPU:    0
[17179572.340000] EIP:    0060:[<c00fab46>]    Not tainted VLI
[17179572.340000] EFLAGS: 00010087   (2.6.16.5 #3)
[17179572.340000] EIP is at 0xc00fab46
[17179572.340000] eax: 00008701   ebx: 000f0000   ecx: 0000d5b4   edx:
00000000
[17179572.340000] esi: 00000206   edi: c02f9874   ebp: 000fa960   esp:
c121ffb6
[17179572.340000] ds: 007b   es: 0000   ss: 0068
[17179572.340000] Process swapper (pid: 1, threadinfo=c121e000
task=c1217a70)
[17179572.340000] Stack: <0>c00fa99d 00000000 a2350006 0060c034 20440000
83c8c02b 0000c036 00000000
[17179572.340000]        00000000 03070000 0290c010 0000c010 10050000
0000c010 00000000 00000000
[17179572.340000]        00000000 00000000
[17179572.340000] Call Trace:
[17179572.340000] Code: 00 f8 c3 87 db 52 50 e8 95 01 00 00 72 12 66 51
66 8b df 8a eb e8 23 02 00 00 66 59 8a c8 b4 00 8a d4 58 8a e2 5a 0a e4
74 01 f5 <d3> 90 52 50 e8 6d 01 10 00 72 1a 66 f7 c7 01 00 74 04 b4 87 eb
[17179572.340000]  <0>Kernel panic - not syncing: Attempted to kill init!
[17179572.340000]  0





From noodles at earth.li  Wed Apr 26 18:14:52 2006
From: noodles at earth.li (Jonathan McDowell)
Date: Wed, 26 Apr 2006 17:14:52 +0100
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <8a0c36780604211553p6dbec782l6c7cf4f5e1f9527@mail.gmail.com>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<4449171D.7020603@lanl.gov> <20060421221143.GC3970@coresystems.de>
	<8a0c36780604211520i6ede31d5r56a11a427e2760ce@mail.gmail.com>
	<20060421224711.GL7570@earth.li>
	<8a0c36780604211553p6dbec782l6c7cf4f5e1f9527@mail.gmail.com>
Message-ID: <20060426161452.GA7570@earth.li>

On Fri, Apr 21, 2006 at 05:53:08PM -0500, Richard Smith wrote:
> > > you have to disable the firewire to make legacy IO work.  So even
> > > prior to early_serial.
> > >
> > > Sombody with an Epia-M (not ML) may want to verfiy all this.
> >
> > You want confirmation that that Firewire disabling is necessary for
> > the Epia-M? I should be able to check this out in the next few days
> > if someone else doesn't get there first; I've finally got to the
> > point where my M10000 based project is ready to go ahead and have
> > started testing again. Recent
> 
> Yeah.  just as a sanity check that that code is there for a reason.
> Board bring up is Voodo sometimes.

Yes, it's necessary (which is good, because I was certainly the last
person to touch it though I can't remember if I put it there in the
first place; I certainly remember seeing it in v1). Without it my boot
hangs, though I do still see the LinuxBIOS banner output before this
happens.

J.

-- 
No thanks, I'm already having one.
This .sig brought to you by the letter A and the number  4
Product of the Republic of HuggieTag



From chris at suehsi.de  Wed Apr 26 19:47:10 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 19:47:10 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060426152211.GA13826@coresystems.de>
References: <m3slo16l9o.fsf@maxwell.lnxi.com> <444F34C0.5080303@suehsi.de>
	<444F3EA2.1000509@suehsi.de> <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de>
	<20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de>
Message-ID: <444FB21E.8000500@suehsi.de>

Stefan Reinauer schrieb:
> * Christian S?hs <chris at suehsi.de> [060426 18:35]:
> 
>>Thanks, the output is as expected. There are only FF
>>
>>What about the irq_table, which is later copied. The verify fails to.
>>For the same reason ?? CONFIG_COMPRESSED is default 1 or 0 ???
> 
>  
> No, different reason. I guess the ram at 0xc0000 is not visible or
> writable. The datasheet usually knows how to make that area writable.
> 
> 
> 
> Stefan.
> 

Ok, what is this?

In src/northbridge/amd/gx1/northbridge.c

There is a part, where a Framebuffer Size is compute.
This Framebuffer is only used, if the internal virtual graphic 
accelaration is needed.
Means, if the graphic work is done by the GXM Geode and the cs5530 
southbridge.
In that case the RAM holds also the graphic memory and is used.

I hope I explain that right ;)

However, in my case it is set to 60MB ?!?!
(see older attached *.cap files)

The RAM Modul, which I use is a 64MB SDRAM.

64MB - 60MB = 4 MB :D

I think that is not enough ;)

However, could that be a reason for my problem.

chris








From smithbone at gmail.com  Wed Apr 26 18:42:20 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 11:42:20 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444FA357.7000907@suehsi.de>
References: <m3slo16l9o.fsf@maxwell.lnxi.com> <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de> <20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de> <444FA357.7000907@suehsi.de>
Message-ID: <8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>

On 4/26/06, Christian S?hs <chris at suehsi.de> wrote:
>
> >
> >
> > No, different reason. I guess the ram at 0xc0000 is not visible or
> > writable. The datasheet usually knows how to make that area writable.
> >
>
> Datasheet of which part ??
> I have them all :D

I bet access to your video bios cache area is still write protected. 
Look for something in the CPU or northbridge datasheets (usually
northbrdge but the Geode is a bit wierd) that talks about controlling
reads and writes to this range.  A lot of times its called the c000
segment.

Ah... Nevermind... I just pulled the datasheet.  According to what I
read I dont think you have a vbios cache.  Page 94 Section 3.5.3 ROM
Interface.

The CS5530A positively decodes memory addresses
000F0000h-000FFFFFh (64 KB) and FFFC0000h-
FFFFFFFFh (256 KB) at reset. These memory cycles
cause the CS5530A to claim the cycle, and generate an
ISA bus memory cycle with KBROMCS# asserted.

I don't see anywhere that you can enable this section as read from
ROM/ write to RAM like you would do for a normal vbios shadow.   You
can disable the area completely but not on a  partial read/write
basis.

If this is true then if you can't see your vbios show up at 0xfffc0000
then its not in your ROM image correctly.

This would explain why the user space emulator works but the in-tree dosent.

--
Richard A. Smith



From smithbone at gmail.com  Wed Apr 26 18:44:12 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 11:44:12 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444FA15E.8050408@suehsi.de>
References: <m3fyk2i07i.fsf@maxwell.lnxi.com> <444F34C0.5080303@suehsi.de>
	<444F3EA2.1000509@suehsi.de> <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de> <20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
Message-ID: <8a0c36780604260944k781cdeecgc7e3d16ccaa6f3b9@mail.gmail.com>

On 4/26/06, Christian S?hs <chris at suehsi.de> wrote:

> rom address for PCI: 00:09.0 = fffc0000
> copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes
> entering emulator
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> .

Does the emulator not check for a valid ROM signature after it
completes the copy?
That needs to be fixed.

--
Richard A. Smith



From smithbone at gmail.com  Wed Apr 26 18:46:07 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 11:46:07 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <m3lktswvdu.fsf@maxwell.lnxi.com>
References: <20060424111110.GA28044@coresystems.de>
	<20060424183303.GA18751@coresystems.de> <444D2EF7.1030906@suehsi.de>
	<m3odyq2ly1.fsf@maxwell.lnxi.com> <m3fyk2i07i.fsf@maxwell.lnxi.com>
	<444E3882.70102@suehsi.de> <m3slo16l9o.fsf@maxwell.lnxi.com>
	<444F34C0.5080303@suehsi.de> <444F3EA2.1000509@suehsi.de>
	<m3lktswvdu.fsf@maxwell.lnxi.com>
Message-ID: <8a0c36780604260946u1fd6415drbc5a575e25123939@mail.gmail.com>

>
> So the chip which has the name 9.0 has a register rom_address.
>
> And with that I think I have reached my limit of usefulness.
>

Eric, thank you for your help.  I was overlooking that the Config.lb
may not have been correct.

--
Richard A. Smith



From smithbone at gmail.com  Wed Apr 26 18:49:02 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 11:49:02 -0500
Subject: [LinuxBIOS] Kernel crash output (was: What's stored in the CMOS
	by LB?)
In-Reply-To: <444F9984.6040207@zyxod.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
Message-ID: <8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>

On 4/26/06, Eric Poulsen <eric at zyxod.com> wrote:
> My kernel crash issue is attached below.  This one isn't an Exception 6
> (that I can tell), but it's one I've seen before.  This happened twice


Have you used memtest86 as a payload and verified that your RAM is solid?

--
Richard A. Smith



From smithbone at gmail.com  Wed Apr 26 18:51:34 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 11:51:34 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444FB21E.8000500@suehsi.de>
References: <m3slo16l9o.fsf@maxwell.lnxi.com> <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de> <20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de> <444FB21E.8000500@suehsi.de>
Message-ID: <8a0c36780604260951v16be320fgadaddbc85b74e947@mail.gmail.com>

>
> I think that is not enough ;)
>
> However, could that be a reason for my problem.

You aren't ever getting that far.  Verify that your vbios is located correctly.

--
Richard A. Smith



From stepan at coresystems.de  Wed Apr 26 18:52:44 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 26 Apr 2006 18:52:44 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
References: <m3lktswvdu.fsf@maxwell.lnxi.com> <444F56BC.8050906@suehsi.de>
	<20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de>
	<444FA357.7000907@suehsi.de>
	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
Message-ID: <20060426165244.GA26131@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060426 18:42]:
> If this is true then if you can't see your vbios show up at 0xfffc0000
> then its not in your ROM image correctly.

It's at 0xfffc0000, just copying it to 0xc0000 does not seem to work...

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Wed Apr 26 18:55:51 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 11:55:51 -0500
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <20060426161452.GA7570@earth.li>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<4449171D.7020603@lanl.gov> <20060421221143.GC3970@coresystems.de>
	<8a0c36780604211520i6ede31d5r56a11a427e2760ce@mail.gmail.com>
	<20060421224711.GL7570@earth.li>
	<8a0c36780604211553p6dbec782l6c7cf4f5e1f9527@mail.gmail.com>
	<20060426161452.GA7570@earth.li>
Message-ID: <8a0c36780604260955s5b0a336ev728bbac6c3122cfa@mail.gmail.com>

> Yes, it's necessary (which is good, because I was certainly the last
> person to touch it though I can't remember if I put it there in the
> first place; I certainly remember seeing it in v1). Without it my boot
> hangs, though I do still see the LinuxBIOS banner output before this
> happens.

Ok.. But you do get serial output prior to that then?  So it must not
totally stop on all legacy IO.

Can you test the changing pci_locate_device() to
pci_locate_device_on_bus(0) (or what ever bus that need to be) and see
if it still works?

--
Richard A. Smith



From chris at suehsi.de  Wed Apr 26 20:25:47 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 20:25:47 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060426165244.GA26131@coresystems.de>
References: <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de>	<20060426103209.GA14218@coresystems.de>	<444F7FCD.3070406@suehsi.de>
	<444F8A0F.1050607@suehsi.de>	<20060426140526.GA3910@coresystems.de>
	<444FA15E.8050408@suehsi.de>	<20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
	<20060426165244.GA26131@coresystems.de>
Message-ID: <444FBB2B.6030701@suehsi.de>

Stefan Reinauer schrieb:
> * Richard Smith <smithbone at gmail.com> [060426 18:42]:
> 
>>If this is true then if you can't see your vbios show up at 0xfffc0000
>>then its not in your ROM image correctly.
> 
> 
> It's at 0xfffc0000, just copying it to 0xc0000 does not seem to work...
> 

yep.

Ok,

http://www.routerboard.com/PDF/gx1.pdf

section 4.

I read, read, read

well, there is spoken about a vga emulation mode, you can enable/disable 
this feature. The GXM Geode has therefor 4 special instructions. I think.

See the special note on page 102.

If this feature enabled, the geode registers ranges for special use in 
the upper memory, where? I don't know ;)

If disabled, the complete graphic instruction stuff is disabled.

I will read more and try to understand

chris



From stuge-linuxbios at cdy.org  Wed Apr 26 19:42:23 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 26 Apr 2006 19:42:23 +0200
Subject: [LinuxBIOS] Kernel crash output (was: What's stored in the CMOS
	by LB?)
In-Reply-To: <8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<444F9984.6040207@zyxod.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
Message-ID: <20060426174223.30888.qmail@cdy.org>

On Wed, Apr 26, 2006 at 09:02:12AM -0700, Eric Poulsen wrote:
> As usual, flipping to the factory BIOS, seeing the "corrupt CMOS"
> message, and re-writing the CMOS fixed the issue.

Are you sure this is actually the case, as opposed to "after
rebooting with the factory BIOS the system does not crash immediately
on the next boot with LinuxBIOS" - they are quite different.

> I immediately flipped back to LB, and it worked as expected.

Worked reliably or did not crash while you were looking?

Can you reliably reproduce the crash? If not there's no way to tell
if the problem has been fixed or merely isn't manifesting itself at
that particular point in time.

Does just rebooting with LinuxBIOS produce different results than
factory(resetCMOS)->LinuxBIOS?

I second Richard on running memtest86, RAM problems can cause all
sorts of funny things.


> I looked at the CMOS code in src/pc80/mc146818rtc.c.

Any system that requires special data to be in CMOS or anywhere else
and does not validate this data before using it is broken.

If one of the OS/mainboard combinations LinuxBIOS works with requires
data in CMOS I guess it could just as well be the OS' responsibility
to validate/create it, but such a dependency would be kind of stupid
IMHO..


//Peter



From chris at suehsi.de  Wed Apr 26 20:54:27 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 20:54:27 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444FBB2B.6030701@suehsi.de>
References: <m3lktswvdu.fsf@maxwell.lnxi.com>	<444F56BC.8050906@suehsi.de>	<20060426103209.GA14218@coresystems.de>	<444F7FCD.3070406@suehsi.de>	<444F8A0F.1050607@suehsi.de>	<20060426140526.GA3910@coresystems.de>	<444FA15E.8050408@suehsi.de>	<20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>
	<444FBB2B.6030701@suehsi.de>
Message-ID: <444FC1E3.50802@suehsi.de>

Christian S?hs schrieb:
> Stefan Reinauer schrieb:
> 
>>* Richard Smith <smithbone at gmail.com> [060426 18:42]:
>>
>>
>>>If this is true then if you can't see your vbios show up at 0xfffc0000
>>>then its not in your ROM image correctly.
>>
>>
>>It's at 0xfffc0000, just copying it to 0xc0000 does not seem to work...
>>
> 

Section 4.2.4 described the read/write access to regions between 640k - 
1MB There is a table on page 106. I think that is what you need.




From eric at zyxod.com  Wed Apr 26 19:41:27 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 10:41:27 -0700
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>	
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
Message-ID: <444FB0C7.8070907@zyxod.com>

Richard Smith wrote:
> On 4/26/06, Eric Poulsen <eric at zyxod.com> wrote:
>   
>> My kernel crash issue is attached below.  This one isn't an Exception 6
>> (that I can tell), but it's one I've seen before.  This happened twice
>>     
>
>
> Have you used memtest86 as a payload and verified that your RAM is solid?
>
> --
> Richard A. Smith
>
>   
No, I haven't.  I have memtest86 as a boot option from factory BIOS / 
Grub -- I'll fire it up at lunch and let it go for a while.



From stuge-linuxbios at cdy.org  Wed Apr 26 19:55:58 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 26 Apr 2006 19:55:58 +0200
Subject: [LinuxBIOS] Overview
In-Reply-To: <444FB08C.20809@zyxod.com>
References: <Pine.LNX.4.63.0604251243250.5146@thermalone.footholds.net>
	<20060425143536.30894.qmail@cdy.org> <444F9938.2000600@zyxod.com>
	<20060426172048.28300.qmail@cdy.org> <444FB08C.20809@zyxod.com>
Message-ID: <20060426175559.32644.qmail@cdy.org>

On Wed, Apr 26, 2006 at 10:40:28AM -0700, Eric Poulsen wrote:
> Cool, I'll check out the DOM stuff -- I was wondering how I was
> going to mount my CF/IDE unit inside my tiny case.  The CF/IDE
> adapter does have the advantage that I could simply pull it out,
> put a new kernel on it (using another cpu) and plug it back in.
> I wonder if you can hot-swap CF/IDE, provided you unmount it?

That depends on the adapter. I just added a few adapters, one with
hotswap support, to:
http://wiki.linuxbios.org/index.php/FAQ#What_kind_of_hardware_tools_do_I_need.3F


//Peter



From stuge-linuxbios at cdy.org  Wed Apr 26 20:01:27 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 26 Apr 2006 20:01:27 +0200
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <444FB0C7.8070907@zyxod.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<444FB0C7.8070907@zyxod.com>
Message-ID: <20060426180128.937.qmail@cdy.org>

On Wed, Apr 26, 2006 at 10:41:27AM -0700, Eric Poulsen wrote:
> No, I haven't.  I have memtest86 as a boot option from factory
> BIOS / Grub -- I'll fire it up at lunch and let it go for a while.

If it works there then please also set it up to run with LinuxBIOS to
see if anything is different with the RAM setup.


//Peter



From chris at suehsi.de  Wed Apr 26 21:14:47 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 26 Apr 2006 21:14:47 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444FC1E3.50802@suehsi.de>
References: <m3lktswvdu.fsf@maxwell.lnxi.com>	<444F56BC.8050906@suehsi.de>	<20060426103209.GA14218@coresystems.de>	<444F7FCD.3070406@suehsi.de>	<444F8A0F.1050607@suehsi.de>	<20060426140526.GA3910@coresystems.de>	<444FA15E.8050408@suehsi.de>	<20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>
	<444FBB2B.6030701@suehsi.de> <444FC1E3.50802@suehsi.de>
Message-ID: <444FC6A7.4080002@suehsi.de>


> 
> Section 4.2.4 described the read/write access to regions between 640k - 
> 1MB There is a table on page 106. I think that is what you need.
> 
> 

Have a look to the src/cpu/amd/model_gx1 section

I'm not sure, but I think the BC_XMAP_2 and BC_XMAP_3 are untouched.
Means all is set to zero.

In that case the region c0000 - fffff is disabled.

BC_XMAP_1 has a 0x60 entry in the cpu_setup table.
How can I enable the other Memory regions.

as the same way, I'm not sure what will happen ;)

chris




From smithbone at gmail.com  Wed Apr 26 20:01:09 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 13:01:09 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444FBB2B.6030701@suehsi.de>
References: <m3lktswvdu.fsf@maxwell.lnxi.com> <444F7FCD.3070406@suehsi.de>
	<444F8A0F.1050607@suehsi.de> <20060426140526.GA3910@coresystems.de>
	<444FA15E.8050408@suehsi.de> <20060426152211.GA13826@coresystems.de>
	<444FA357.7000907@suehsi.de>
	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
	<20060426165244.GA26131@coresystems.de> <444FBB2B.6030701@suehsi.de>
Message-ID: <8a0c36780604261101y2d124cb6pe739c9ffe112759f@mail.gmail.com>

> >
> > It's at 0xfffc0000, just copying it to 0xc0000 does not seem to work...
> >
>
> yep.
>
> Ok,
>
> http://www.routerboard.com/PDF/gx1.pdf
>

Ahh.. Thats it.  So its in the gx datasheet and not the northbridge.

BC_XMAP_3 bits 31:28.

That controls the read/write access to the Fc000 to FFFFF .  It
defaults on reset to 0 which is read but no write.  So verify that you
have write enabled prior to when the emulator is called.

--
Richard A. Smith



From stuge-linuxbios at cdy.org  Wed Apr 26 20:26:14 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 26 Apr 2006 20:26:14 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444FC1E3.50802@suehsi.de>
References: <444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de>
	<444FA357.7000907@suehsi.de>
	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
	<20060426165244.GA26131@coresystems.de>
	<444FBB2B.6030701@suehsi.de> <444FC1E3.50802@suehsi.de>
Message-ID: <20060426182615.3954.qmail@cdy.org>

On Wed, Apr 26, 2006 at 08:54:27PM +0200, Christian S?hs wrote:
> Section 4.2.4 described the read/write access to regions between
> 640k -> 1MB There is a table on page 106. I think that is what you
> need.

Yeah. Memory access is "directed to the PCI master"..

Try setting bits 5:4 and 1:0 (0x33) at GX_BASE+8008h before the BIOS
is copied. Set 6:4 and 2:0 (0x77) if you want to enable caching too.


//Peter



From stuge-linuxbios at cdy.org  Wed Apr 26 20:28:29 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 26 Apr 2006 20:28:29 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <8a0c36780604261101y2d124cb6pe739c9ffe112759f@mail.gmail.com>
References: <444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de>
	<444FA357.7000907@suehsi.de>
	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
	<20060426165244.GA26131@coresystems.de>
	<444FBB2B.6030701@suehsi.de>
	<8a0c36780604261101y2d124cb6pe739c9ffe112759f@mail.gmail.com>
Message-ID: <20060426182829.4278.qmail@cdy.org>

On Wed, Apr 26, 2006 at 01:01:09PM -0500, Richard Smith wrote:
> BC_XMAP_3 bits 31:28.
> 
> That controls the read/write access to the Fc000 to FFFFF .  It
> defaults on reset to 0 which is read but no write.  So verify that
> you have write enabled prior to when the emulator is called.

Argh, I wanted a 0 too many and got the wrong register and bits. Of
course you are right.


//Peter



From eric at zyxod.com  Wed Apr 26 20:39:07 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 11:39:07 -0700
Subject: [LinuxBIOS] Is there sched_clock equivalent in LB?
Message-ID: <444FBE4B.4040006@zyxod.com>

I was going to hack LB a bit, and add a timestamp, just like you see in 
the newer Linux kernels, to look for potential bottlenecks specific to 
my MLB. The kernel printk uses sched_clock() to get the current time.  
Is there an equivalent call in LB?  I've looked through the code base 
for files / code that has *clock* or *time* or something similar, but 
without much luck.



From stuge-linuxbios at cdy.org  Wed Apr 26 20:48:37 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 26 Apr 2006 20:48:37 +0200
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <444FBA0B.8040004@zyxod.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com> <20060426174223.30888.qmail@cdy.org>
	<444FBA0B.8040004@zyxod.com>
Message-ID: <20060426184838.6632.qmail@cdy.org>

You're sending replies only to me - let's keep it on the list for
the benefit of others as well. Thanks! :)


On Wed, Apr 26, 2006 at 11:20:59AM -0700, Eric Poulsen wrote:
> 1) Use factory BIOS, re-save CMOS, Boot OS, Reboot later using LB
> 2) Use factory BIOS, NOT re-save CMOS, Boot OS, Reboot later using LB
> 3) Use factory BIOS, re-save CMOS, powerdown, boot use LB
> 4) Use factory BIOS, NOT re-save CMOS, powerdown, boot use LB
> 5) Other ?
> 
> "re-save CMOS" means entering BIOS menu and choosing "save changes
> and exit"
> 
> When I have the crash problem, I have been using option #3.  I'm
> not sure if that answers your question =)

Sorry, no. But the question was badly stated as well. :) More below.


> >>I immediately flipped back to LB, and it worked as expected.
> >
> >Worked reliably or did not crash while you were looking?
> 
> The crash _always_ occurs during initial kernel execution, before
> 'init' starts.

Depending on what the problem is, the system could crash later on as
well, just that it hasn't been left running long enough or with such
loads that the problem appears.


> >Can you reliably reproduce the crash? If not there's no way to
> >tell if the problem has been fixed or merely isn't manifesting
> >itself at that particular point in time.
> >
> >Does just rebooting with LinuxBIOS produce different results than
> >factory(resetCMOS)->LinuxBIOS?
> 
> Rebooting with LB crashes every time, until I reset the CMOS with
> the Factory BIOS.  This is why I think it might be a CMOS issue --
> the crashing seems stateful.

Ok! So the only successful way to boot LinuxBIOS under any
circumstances is to first boot factory BIOS, have it do something
(possibly rewrite CMOS, possibly something else) and then reboot into
LinuxBIOS without powering off the system?

If it works also when powering off between factory BIOS and
LinuxBIOS, please leave the system powered off several hours up to a
day and see it that works too.


> >I second Richard on running memtest86, RAM problems can cause all
> >sorts of funny things.
> 
> I'll hit the ram test ASAP.  I've had other weird issues, such as
> the kernel taking a REALLY LONG time to initialize stuff.  This is
> new RAM, so hopefully still under warranty.

Since this is code setting up the DRAM controller the RAM test also
serves as a code test.


> >Any system that requires special data to be in CMOS or anywhere else
> >and does not validate this data before using it is broken.
> 
> If by "system" you mean the BIOS, then I agree.

Any system. Development 101 has to be "validate the input!"


//Peter



From eric at zyxod.com  Wed Apr 26 20:44:09 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 11:44:09 -0700
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <20060426174223.30888.qmail@cdy.org>
References: <444E5BD7.2080007@zyxod.com>
	<444E6DFF.4090208@lanl.gov>	<444F9984.6040207@zyxod.com>	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>	<444E5BD7.2080007@zyxod.com>
	<444E6DFF.4090208@lanl.gov>	<444F9984.6040207@zyxod.com>
	<20060426174223.30888.qmail@cdy.org>
Message-ID: <444FBF79.7010800@zyxod.com>

Peter Stuge wrote:
> On Wed, Apr 26, 2006 at 09:02:12AM -0700, Eric Poulsen wrote:
>   
>> As usual, flipping to the factory BIOS, seeing the "corrupt CMOS"
>> message, and re-writing the CMOS fixed the issue.
>>     
>
> Are you sure this is actually the case, as opposed to "after
> rebooting with the factory BIOS the system does not crash immediately
> on the next boot with LinuxBIOS" - they are quite different.
>   
I'm not sure I fully understand your definition / distinction.  Here are
some options:

1) Use factory BIOS, re-save CMOS, Boot OS, Reboot later using LB
2) Use factory BIOS, NOT re-save CMOS, Boot OS, Reboot later using LB
3) Use factory BIOS, re-save CMOS, powerdown, boot use LB
4) Use factory BIOS, NOT re-save CMOS, powerdown, boot use LB
5) Other ?

"re-save CMOS" means entering BIOS menu and choosing "save changes and exit"

When I have the crash problem, I have been using option #3.  I'm not
sure if that answers your question =)

If the "using defaults" message from the Factory BIOS does NOT re-write
the CMOS, I suspect that #2 and #4 WON'T fix the problem.  I'm fairly
certain that #1 fixes the issue.

Actually booting the OS after the CMOS reset doesn't seem to be necessary.

>   
>> I immediately flipped back to LB, and it worked as expected.
>>     
>
> Worked reliably or did not crash while you were looking?
>   
The crash _always_ occurs during initial kernel execution, before 'init'
starts.  It never crashes once it fully boots.  I'm not sure what
"reliably" vs "while looking" means.  Once it goes into 'crash mode', it
never fully boots.
> Can you reliably reproduce the crash? If not there's no way to tell
> if the problem has been fixed or merely isn't manifesting itself at
> that particular point in time.
>
> Does just rebooting with LinuxBIOS produce different results than
> factory(resetCMOS)->LinuxBIOS?
>   
Rebooting with LB crashes every time, until I reset the CMOS with the
Factory BIOS.  This is why I think it might be a CMOS issue -- the
crashing seems stateful.
> I second Richard on running memtest86, RAM problems can cause all
> sorts of funny things.
>   
I'll hit the ram test ASAP.  I've had other weird issues, such as the
kernel taking a REALLY LONG time to initialize stuff.  This is new RAM,
so hopefully still under warranty.
>
>   
>> I looked at the CMOS code in src/pc80/mc146818rtc.c.
>>     
>
> Any system that requires special data to be in CMOS or anywhere else
> and does not validate this data before using it is broken.
>   
If by "system" you mean the BIOS, then I agree.  AFAIK, the only setting
that Linux (or any OS) uses from the CMOS is the RTC.
> If one of the OS/mainboard combinations LinuxBIOS works with requires
> data in CMOS I guess it could just as well be the OS' responsibility
> to validate/create it, but such a dependency would be kind of stupid
> IMHO..
>
>
> //Peter
>
>   





From eric at zyxod.com  Wed Apr 26 20:50:24 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 11:50:24 -0700
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <20060426184838.6632.qmail@cdy.org>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com> <20060426174223.30888.qmail@cdy.org>
	<444FBA0B.8040004@zyxod.com> <20060426184838.6632.qmail@cdy.org>
Message-ID: <444FC0F0.5070809@zyxod.com>



Peter Stuge wrote:
> You're sending replies only to me - let's keep it on the list for
> the benefit of others as well. Thanks! :)
>   

I'm trying -- the lack of a "reply-to" header for the list is really weird.

>
> On Wed, Apr 26, 2006 at 11:20:59AM -0700, Eric Poulsen wrote:
>   
>> 1) Use factory BIOS, re-save CMOS, Boot OS, Reboot later using LB
>> 2) Use factory BIOS, NOT re-save CMOS, Boot OS, Reboot later using LB
>> 3) Use factory BIOS, re-save CMOS, powerdown, boot use LB
>> 4) Use factory BIOS, NOT re-save CMOS, powerdown, boot use LB
>> 5) Other ?
>>
>> "re-save CMOS" means entering BIOS menu and choosing "save changes
>> and exit"
>>
>> When I have the crash problem, I have been using option #3.  I'm
>> not sure if that answers your question =)
>>     
>
> Sorry, no. But the question was badly stated as well. :) More below.
>
>
>   
>>>> I immediately flipped back to LB, and it worked as expected.
>>>>         
>>> Worked reliably or did not crash while you were looking?
>>>       
>> The crash _always_ occurs during initial kernel execution, before
>> 'init' starts.
>>     
>
> Depending on what the problem is, the system could crash later on as
> well, just that it hasn't been left running long enough or with such
> loads that the problem appears.
>
>
>   
>>> Can you reliably reproduce the crash? If not there's no way to
>>> tell if the problem has been fixed or merely isn't manifesting
>>> itself at that particular point in time.
>>>
>>> Does just rebooting with LinuxBIOS produce different results than
>>> factory(resetCMOS)->LinuxBIOS?
>>>       
>> Rebooting with LB crashes every time, until I reset the CMOS with
>> the Factory BIOS.  This is why I think it might be a CMOS issue --
>> the crashing seems stateful.
>>     
>
> Ok! So the only successful way to boot LinuxBIOS under any
> circumstances is to first boot factory BIOS, have it do something
> (possibly rewrite CMOS, possibly something else) and then reboot into
> LinuxBIOS without powering off the system?
>   
Not at all.  After the "reset," I can power down and restart (this is 
typical because I just hit the power switch, and linux shuts down).  
Often, I can come back later and it boots fine.  Then, it suddenly 
starts having issues, and this is persistent until the "reset."  It 
_seems_ (but I haven't verified) to be exacerbated by having the machine 
off for a few hours/days.
> If it works also when powering off between factory BIOS and
> LinuxBIOS, please leave the system powered off several hours up to a
> day and see it that works too.
>   
Haha I hadn't read this paragraph when I wrote the above.  It seems that 
long off times screws up LB.
>
>   
>>> I second Richard on running memtest86, RAM problems can cause all
>>> sorts of funny things.
>>>       
>> I'll hit the ram test ASAP.  I've had other weird issues, such as
>> the kernel taking a REALLY LONG time to initialize stuff.  This is
>> new RAM, so hopefully still under warranty.
>>     
>
> Since this is code setting up the DRAM controller the RAM test also
> serves as a code test.
>   
>
>   
>>> Any system that requires special data to be in CMOS or anywhere else
>>> and does not validate this data before using it is broken.
>>>       
>> If by "system" you mean the BIOS, then I agree.
>>     
>
> Any system. Development 101 has to be "validate the input!"
>   
True.
>
> //Peter
>
>   




From noodles at earth.li  Wed Apr 26 20:51:53 2006
From: noodles at earth.li (Jonathan McDowell)
Date: Wed, 26 Apr 2006 19:51:53 +0100
Subject: [LinuxBIOS] Adding a config option
In-Reply-To: <8a0c36780604260955s5b0a336ev728bbac6c3122cfa@mail.gmail.com>
References: <8a0c36780604210905x462c3ff0v6cfd4f382f7c6b78@mail.gmail.com>
	<4449171D.7020603@lanl.gov> <20060421221143.GC3970@coresystems.de>
	<8a0c36780604211520i6ede31d5r56a11a427e2760ce@mail.gmail.com>
	<20060421224711.GL7570@earth.li>
	<8a0c36780604211553p6dbec782l6c7cf4f5e1f9527@mail.gmail.com>
	<20060426161452.GA7570@earth.li>
	<8a0c36780604260955s5b0a336ev728bbac6c3122cfa@mail.gmail.com>
Message-ID: <20060426185153.GB7570@earth.li>

On Wed, Apr 26, 2006 at 11:55:51AM -0500, Richard Smith wrote:
> > Yes, it's necessary (which is good, because I was certainly the last
> > person to touch it though I can't remember if I put it there in the
> > first place; I certainly remember seeing it in v1). Without it my boot
> > hangs, though I do still see the LinuxBIOS banner output before this
> > happens.
> Ok.. But you do get serial output prior to that then?  So it must not
> totally stop on all legacy IO.

Yes, I get the "LinuxBIOS-1.1.8.0Fallback Wed...booting..." header fine.
My guess it it stomps over something else or quite possible does so
randomly; ISTR getting random lockups when first getting the EPIA-M up
and running again.

> Can you test the changing pci_locate_device() to
> pci_locate_device_on_bus(0) (or what ever bus that need to be) and see
> if it still works?

That works; s/pci_locate_device/pci_locate_device_on_bus/ for the
firewire bits.

On a separate note, but still related to the EPIA-M, I'm sure I'd found
the appropriate bit to twiddle to make sure the machine auto powers on
always. However I can't find my tree where I did that and I'm failing to
find the details in the datasheet again. Has anyone else done this?

J.

-- 
                 /------------------------------------\
                 |             Purrrrrrr.             |
                 \------------------------------------/



From stepan at coresystems.de  Wed Apr 26 21:10:42 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 26 Apr 2006 21:10:42 +0200
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <444FC0F0.5070809@zyxod.com>
References: <444E6DFF.4090208@lanl.gov> <444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com> <20060426174223.30888.qmail@cdy.org>
	<444FBA0B.8040004@zyxod.com> <20060426184838.6632.qmail@cdy.org>
	<444FC0F0.5070809@zyxod.com>
Message-ID: <20060426191042.GA16333@coresystems.de>

* Eric Poulsen <eric at zyxod.com> [060426 20:50]:
> 
> 
> Peter Stuge wrote:
> > You're sending replies only to me - let's keep it on the list for
> > the benefit of others as well. Thanks! :)
> >   
> 
> I'm trying -- the lack of a "reply-to" header for the list is really weird.

Most mailers have a "reply to group" or "reply to all" function that
would do the right thing.

There are many reasons not to introduce or override the Reply-To:
header. One is that some posters depend on their own Reply-To: settings
to convey their valid return address. Another is that modifying
Reply-To: makes it much more difficult to send private replies. See
`Reply-To' Munging Considered Harmful
[http://www.unicom.com/pw/reply-to-harmful.html] for a general discussion of this
issue.

Stefan




From smithbone at gmail.com  Wed Apr 26 21:35:24 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 14:35:24 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444FC6A7.4080002@suehsi.de>
References: <m3lktswvdu.fsf@maxwell.lnxi.com>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de> <444FA357.7000907@suehsi.de>
	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
	<20060426165244.GA26131@coresystems.de> <444FBB2B.6030701@suehsi.de>
	<444FC1E3.50802@suehsi.de> <444FC6A7.4080002@suehsi.de>
Message-ID: <8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>

On 4/26/06, Christian S?hs <chris at suehsi.de> wrote:

> > Section 4.2.4 described the read/write access to regions between 640k -
> > 1MB There is a table on page 106. I think that is what you need.
> >
> Have a look to the src/cpu/amd/model_gx1 section
>
> I'm not sure, but I think the BC_XMAP_2 and BC_XMAP_3 are untouched.
> Means all is set to zero.

Yeah.  All the operations on these registers are commented out.

Heres the rub though.  Although this is a CPU thing in this case. 
This type of setting is _mainboard_ specific.  What works for you may
not be good for others.  So we can't just go setting this stuff in
here by default.  Of course there don't appeat to be too many users
and VGA is a common item so perhpas its ok.

The right way do do this seems to be to add a field into the chip
operations struct that allows the read/write of registers  either
indivdually or via a table and then the mainboard code could call that
with what it wanted to do.

But that may be a lot of extra overhead I know some of the romcc
setups are alreday tight on rom space.

To test you can just change line 36 in GX setup to be:
        .long   BC_XMAP_2, 0xb0000000

Seems to me we've had this discussion before but I never remember the result. :(

--
Richard A. Smith



From stuge-linuxbios at cdy.org  Wed Apr 26 21:46:47 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 26 Apr 2006 21:46:47 +0200
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <444FC0F0.5070809@zyxod.com>
References: <444E6DFF.4090208@lanl.gov> <444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com> <20060426174223.30888.qmail@cdy.org>
	<444FBA0B.8040004@zyxod.com> <20060426184838.6632.qmail@cdy.org>
	<444FC0F0.5070809@zyxod.com>
Message-ID: <20060426194647.13924.qmail@cdy.org>

On Wed, Apr 26, 2006 at 11:50:24AM -0700, Eric Poulsen wrote:
> > Ok! So the only successful way to boot LinuxBIOS under any
> > circumstances is to first boot factory BIOS, have it do something
> > (possibly rewrite CMOS, possibly something else) and then reboot
> > into LinuxBIOS without powering off the system?
> 
> Not at all.  After the "reset," I can power down and restart (this
> is typical because I just hit the power switch, and linux shuts
> down).
> Often, I can come back later and it boots fine.  Then, it suddenly
> starts having issues, and this is persistent until the "reset."

Ok, thanks for making that clear. Can you provide some timeframes?
Ie. how much later "later" means, and how much time passes between
"later" and "suddenly" ? :)


> It _seems_ (but I haven't verified) to be exacerbated by having the
> machine off for a few hours/days.
>
> > If it works also when powering off between factory BIOS and
> > LinuxBIOS, please leave the system powered off several hours up
> > to a day and see it that works too.
> 
> Haha I hadn't read this paragraph when I wrote the above.  It seems
> that long off times screws up LB.

The reason this may matter is that special configuration of chips
performed by the factory BIOS may well stay around in chip registers
even if power is cut for some time, while if the special config is in
CMOS it will of course survive without power a lot longer.


//Peter



From smithbone at gmail.com  Wed Apr 26 21:46:23 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 14:46:23 -0500
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <444FC0F0.5070809@zyxod.com>
References: <8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com> <20060426174223.30888.qmail@cdy.org>
	<444FBA0B.8040004@zyxod.com> <20060426184838.6632.qmail@cdy.org>
	<444FC0F0.5070809@zyxod.com>
Message-ID: <8a0c36780604261246r7245c655m1dcd02433d331283@mail.gmail.com>

> >
> Haha I hadn't read this paragraph when I wrote the above.  It seems that
> long off times screws up LB.
> >

What happens if you use the clear CMOS jumper bettween boots so you
always start with a zeroed CMOS?

--
Richard A. Smith



From eric at zyxod.com  Wed Apr 26 22:45:55 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 13:45:55 -0700
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <8a0c36780604261246r7245c655m1dcd02433d331283@mail.gmail.com>
References: <8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>	<444E5BD7.2080007@zyxod.com>
	<444E6DFF.4090208@lanl.gov>	<444F9984.6040207@zyxod.com>
	<20060426174223.30888.qmail@cdy.org>	<444FBA0B.8040004@zyxod.com>
	<20060426184838.6632.qmail@cdy.org>	<444FC0F0.5070809@zyxod.com>
	<8a0c36780604261246r7245c655m1dcd02433d331283@mail.gmail.com>
Message-ID: <444FDC03.3090309@zyxod.com>

Richard Smith wrote:
>> Haha I hadn't read this paragraph when I wrote the above.  It seems that
>> long off times screws up LB.
>>     
>
> What happens if you use the clear CMOS jumper bettween boots so you
> always start with a zeroed CMOS?
>
> --
> Richard A. Smith
>
>   
I'll give it a shot.



From ollie at lanl.gov  Thu Apr 27 00:05:00 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed, 26 Apr 2006 16:05:00 -0600
Subject: [LinuxBIOS] Is there sched_clock equivalent in LB?
In-Reply-To: <444FBE4B.4040006@zyxod.com>
References: <444FBE4B.4040006@zyxod.com>
Message-ID: <1146089100.6595.11.camel@logarithm.lanl.gov>

On Wed, 2006-04-26 at 11:39 -0700, Eric Poulsen wrote:
> I was going to hack LB a bit, and add a timestamp, just like you see in 
> the newer Linux kernels, to look for potential bottlenecks specific to 
> my MLB. The kernel printk uses sched_clock() to get the current time.  
> Is there an equivalent call in LB?  I've looked through the code base 
> for files / code that has *clock* or *time* or something similar, but 
> without much luck.
> 

There used to be something like POST_TSC which prints the CPU TSC 
register value in every printk. I don't know if it is still there.
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From ward at gnu.org  Thu Apr 27 00:08:30 2006
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 26 Apr 2006 18:08:30 -0400
Subject: [LinuxBIOS] Tyan S2881 build tutorial online
Message-ID: <20060426220830.GA12620@io.pong.be>

Hi all,

As promised, I've just uploaded a Tyan S2881 build tutorial to the wiki:

  http://wiki.linuxbios.org/index.php/Tyan_S2881_Build_Tutorial

We (the FSF) hope this will help others to get LinuxBIOS going.

A _very big_ thank you to all of you, and in particular Yinghai, Ron, Stefan,
Richard and Alan for all your help to get me to the point where we have a
working LinuxBIOS machine.

We will be deploying 2 or 3 of these GX28 boxes shortly. Soon, all
@(lists.)gnu.org and @fsf.org e-mail will be processed by machines running
LinuxBIOS!

As you will see in the wiki page, there is still one thing that I have not
gotten to work - VGA output. It's not a big issue for us, but I'd like to get
it working nevertheless, if only to complete the build tutorial. I'll be
posting about that shortly, I'm sure :)

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From smithbone at gmail.com  Thu Apr 27 00:21:51 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 17:21:51 -0500
Subject: [LinuxBIOS] Tyan S2881 build tutorial online
In-Reply-To: <20060426220830.GA12620@io.pong.be>
References: <20060426220830.GA12620@io.pong.be>
Message-ID: <8a0c36780604261521h5056c1edj89b1facb3d7afc8b@mail.gmail.com>

>
> As you will see in the wiki page, there is still one thing that I have not
> gotten to work - VGA output. It's not a big issue for us, but I'd like to get
> it working nevertheless, if only to complete the build tutorial. I'll be
> posting about that shortly, I'm sure :)

Well being that we are smak dab in the middle of a big VGA thread nows
probally as good a time as any.

Give us the details.

--
Richard A. Smith



From russ at ashlandhome.net  Thu Apr 27 01:07:31 2006
From: russ at ashlandhome.net (Russell Whitaker)
Date: Wed, 26 Apr 2006 16:07:31 -0700 (PDT)
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <444FBF79.7010800@zyxod.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
	<20060426174223.30888.qmail@cdy.org> <444FBF79.7010800@zyxod.com>
Message-ID: <Pine.LNX.4.63.0604261600090.2457@bigred.russwhit.org>



On Wed, 26 Apr 2006, Eric Poulsen wrote:

> Peter Stuge wrote:
>> On Wed, Apr 26, 2006 at 09:02:12AM -0700, Eric Poulsen wrote:
>>
>>> As usual, flipping to the factory BIOS, seeing the "corrupt CMOS"
>>> message, and re-writing the CMOS fixed the issue.
>>>
>>
>> Are you sure this is actually the case, as opposed to "after
>> rebooting with the factory BIOS the system does not crash immediately
>> on the next boot with LinuxBIOS" - they are quite different.
>>
> I'm not sure I fully understand your definition / distinction.  Here are
> some options:
>
> 1) Use factory BIOS, re-save CMOS, Boot OS, Reboot later using LB
> 2) Use factory BIOS, NOT re-save CMOS, Boot OS, Reboot later using LB
> 3) Use factory BIOS, re-save CMOS, powerdown, boot use LB
> 4) Use factory BIOS, NOT re-save CMOS, powerdown, boot use LB
> 5) Other ?
>
> "re-save CMOS" means entering BIOS menu and choosing "save changes and exit"
>
> When I have the crash problem, I have been using option #3.  I'm not
> sure if that answers your question =)
>
> If the "using defaults" message from the Factory BIOS does NOT re-write
> the CMOS, I suspect that #2 and #4 WON'T fix the problem.  I'm fairly
> certain that #1 fixes the issue.
>
> Actually booting the OS after the CMOS reset doesn't seem to be necessary.
>
>>
>>> I immediately flipped back to LB, and it worked as expected.
>>>
>>
>> Worked reliably or did not crash while you were looking?
>>
> The crash _always_ occurs during initial kernel execution, before 'init'
> starts.  It never crashes once it fully boots.  I'm not sure what
> "reliably" vs "while looking" means.  Once it goes into 'crash mode', it
> never fully boots.
>> Can you reliably reproduce the crash? If not there's no way to tell
>> if the problem has been fixed or merely isn't manifesting itself at
>> that particular point in time.
>>
>> Does just rebooting with LinuxBIOS produce different results than
>> factory(resetCMOS)->LinuxBIOS?
>>
> Rebooting with LB crashes every time, until I reset the CMOS with the
> Factory BIOS.  This is why I think it might be a CMOS issue -- the
> crashing seems stateful.
>> I second Richard on running memtest86, RAM problems can cause all
>> sorts of funny things.
>>
> I'll hit the ram test ASAP.  I've had other weird issues, such as the
> kernel taking a REALLY LONG time to initialize stuff.  This is new RAM,
> so hopefully still under warranty.
>>
[..]
You might try replacing the CMOS battery. If its voltage is a little low
it would cause the CMOS to loose a bit or two over time.

   Russ



From pada at chemonline.de  Thu Apr 27 01:23:00 2006
From: pada at chemonline.de (Daniel Parthey)
Date: Thu, 27 Apr 2006 01:23:00 +0200
Subject: [LinuxBIOS] Is there sched_clock equivalent in LB?
In-Reply-To: <444FBE4B.4040006@zyxod.com>
References: <444FBE4B.4040006@zyxod.com>
Message-ID: <20060426232300.GA21714@daniel.localdomain>

Eric Poulsen schrieb:
> I was going to hack LB a bit, and add a timestamp, just like you see in 
> the newer Linux kernels, to look for potential bottlenecks specific to 
> my MLB. The kernel printk uses sched_clock() to get the current time.  
> Is there an equivalent call in LB?  I've looked through the code base 
> for files / code that has *clock* or *time* or something similar, but 
> without much luck.

I suppose MLB means VIA EPIA ML Board?

On Intel compatible Pentium (or higher) boards like VIA EPIA, you could
read the Time Stamp Counter (TSC) CPU register which tells you the number
of cycles from the last machine reset. Use the "cpuid" assembler command
as a barrier (to prevent out-of-order command execution) in combination
with the "rdtsc" assembler command to read the time time stamp counter.
The linux kernel sourcecode contains examples for this.

If you manage to get some inline assembler code into linuxbios,
you could take two time stamp counter (TSC) values and store them somewhere.
You can convert the number of ticks into real time units afterwards,
you could either use the processor speed from /proc/cpuinfo or determine
the number of processor cycles per second on your processor yourself.
Disable automatic CPU clock adjust to have the CPU run at constant speed.

bye,
Daniel.
-- 
Jabber: pada at jabber.ccc.de



From pada at chemonline.de  Thu Apr 27 01:54:10 2006
From: pada at chemonline.de (Daniel Parthey)
Date: Thu, 27 Apr 2006 01:54:10 +0200
Subject: [LinuxBIOS] Epia ML 5000 success
In-Reply-To: <8a0c36780604250914n68abd307tf084f1570ab7a078@mail.gmail.com>
References: <444E46D8.3050501@zyxod.com>
	<8a0c36780604250914n68abd307tf084f1570ab7a078@mail.gmail.com>
Message-ID: <20060426235410.GA22086@daniel.localdomain>

Richard Smith schrieb:
> On 4/25/06, Eric Poulsen <eric at zyxod.com> wrote:
> > I'll write up my efforts as a HOWTO in the near future.
> 
> Please, please, please make sure you follow through on this and pester
> us to get the info up on the wiki and in the HOWTO section of the
> tree.

IMHO the HOWTOs and Docs should not be written by a single person, but
should be developed and improved with the help of the whole community.

Would you mind making the wiki public, so that everybody here can create
a wiki account by himself (like subscription to this list works) and
contribute some small piece of docs, or do you have had bad experiences
with an unmoderated wiki registration?

Some people would probably never try to write an e-mail to Ron or Stefan
and register as a "contributor", even if they had to add some small but
important facts about their particular linuxbios setup.

Daniel.
-- 
Jabber: pada at jabber.ccc.de



From smithbone at gmail.com  Thu Apr 27 01:56:00 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 18:56:00 -0500
Subject: [LinuxBIOS]  Is there sched_clock equivalent in LB?
In-Reply-To: <8a0c36780604261655h18ba2ebcmad7a4beec687a921@mail.gmail.com>
References: <444FBE4B.4040006@zyxod.com>
	<20060426232300.GA21714@daniel.localdomain>
	<8a0c36780604261655h18ba2ebcmad7a4beec687a921@mail.gmail.com>
Message-ID: <8a0c36780604261656n56c0edf3uf45a7a21d263d63f@mail.gmail.com>

On 4/26/06, Daniel Parthey <pada at chemonline.de> wrote:
> Eric Poulsen schrieb:

> > my MLB. The kernel printk uses sched_clock() to get the current time.
> > Is there an equivalent call in LB?  I've looked through the code base
> > for files / code that has *clock* or *time* or something similar, but
> > without much luck.
>
> I suppose MLB means VIA EPIA ML Board?
>
> On Intel compatible Pentium (or higher) boards like VIA EPIA, you could
> read the Time Stamp Counter (TSC) CPU register which tells you the number

cpu/x86/tsc/delay_tsc.c should have the info you need

--
Richard A. Smith


--
Richard A. Smith



From johnson.xu at gmail.com  Thu Apr 27 04:24:39 2006
From: johnson.xu at gmail.com (Zhen Xu)
Date: Thu, 27 Apr 2006 10:24:39 +0800
Subject: [LinuxBIOS] Want to know whether linuxbios works on my PC
In-Reply-To: <8a0c36780604260853h67e2d9d6ufd7457cafe0d3ace@mail.gmail.com>
References: <2ea7d6950604260046rce499cyafe0b6024c4cdbdb@mail.gmail.com>
	<8a0c36780604260853h67e2d9d6ufd7457cafe0d3ace@mail.gmail.com>
Message-ID: <2ea7d6950604261924n236c3f3ew6511b897a604efc1@mail.gmail.com>

You mean Linuxbios won't work on my PC? If so, it's a bit sad.

In fact, I want to do some experiments on the TPM chip on the motherboard of
this PC.
Is there any motherboard with TPM chip on which Linuxbios can work?


On 4/26/06, Richard Smith <smithbone at gmail.com> wrote:
>
> On 4/26/06, Zhen Xu <johnson.xu at gmail.com> wrote:
>
> > Hi, all,
> >
> >  I'm interested in linuxbios and planning to do some experiments with
> it.
> > However, I don't know whether linuxbios works on my PC. It's a IBM
> > thinkcentre 8114, chip set is Intel 945G and the result of 'listpci
> -vvv' is
> > as below:
>
> I seem to remember that we haven't been able to get any good Docs on
> this chipset.  Its not in the tree.
>
> --
> Richard A. Smith
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060427/fcddc667/attachment.html>

From smithbone at gmail.com  Thu Apr 27 04:32:55 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 21:32:55 -0500
Subject: [LinuxBIOS] Want to know whether linuxbios works on my PC
In-Reply-To: <2ea7d6950604261924n236c3f3ew6511b897a604efc1@mail.gmail.com>
References: <2ea7d6950604260046rce499cyafe0b6024c4cdbdb@mail.gmail.com>
	<8a0c36780604260853h67e2d9d6ufd7457cafe0d3ace@mail.gmail.com>
	<2ea7d6950604261924n236c3f3ew6511b897a604efc1@mail.gmail.com>
Message-ID: <8a0c36780604261932x20b78d22jfdfc23d3b60ac7e4@mail.gmail.com>

On 4/26/06, Zhen Xu <johnson.xu at gmail.com> wrote:

> You mean Linuxbios won't work on my PC? If so, it's a bit sad.

LinuxBIOS support depends largly on 2 factors.  People to do the
mainboard port and the datasheets to make it happen.  We are short in
both catagories.

--
Richard A. Smith



From johnson.xu at gmail.com  Thu Apr 27 04:59:42 2006
From: johnson.xu at gmail.com (Zhen Xu)
Date: Thu, 27 Apr 2006 10:59:42 +0800
Subject: [LinuxBIOS] Want to know whether linuxbios works on my PC
In-Reply-To: <8a0c36780604261932x20b78d22jfdfc23d3b60ac7e4@mail.gmail.com>
References: <2ea7d6950604260046rce499cyafe0b6024c4cdbdb@mail.gmail.com>
	<8a0c36780604260853h67e2d9d6ufd7457cafe0d3ace@mail.gmail.com>
	<2ea7d6950604261924n236c3f3ew6511b897a604efc1@mail.gmail.com>
	<8a0c36780604261932x20b78d22jfdfc23d3b60ac7e4@mail.gmail.com>
Message-ID: <2ea7d6950604261959s3b1b9512ta630f1feddfd5fe3@mail.gmail.com>

Maybe I can do something. But my knowledge on hardware and firmware is very
limited. How can I begin?

On 4/27/06, Richard Smith <smithbone at gmail.com> wrote:
>
> On 4/26/06, Zhen Xu <johnson.xu at gmail.com> wrote:
>
> > You mean Linuxbios won't work on my PC? If so, it's a bit sad.
>
> LinuxBIOS support depends largly on 2 factors.  People to do the
> mainboard port and the datasheets to make it happen.  We are short in
> both catagories.
>
> --
> Richard A. Smith
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060427/8a868ac4/attachment.html>

From rminnich at lanl.gov  Thu Apr 27 05:03:09 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 26 Apr 2006 21:03:09 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060426152211.GA13826@coresystems.de>
References: <m3slo16l9o.fsf@maxwell.lnxi.com>
	<444F34C0.5080303@suehsi.de>	<444F3EA2.1000509@suehsi.de>
	<m3lktswvdu.fsf@maxwell.lnxi.com>	<444F56BC.8050906@suehsi.de>	<20060426103209.GA14218@coresystems.de>	<444F7FCD.3070406@suehsi.de>
	<444F8A0F.1050607@suehsi.de>	<20060426140526.GA3910@coresystems.de>
	<444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de>
Message-ID: <4450346D.70509@lanl.gov>

Stefan Reinauer wrote:
> * Christian S?hs <chris at suehsi.de> [060426 18:35]:
> 
>>Thanks, the output is as expected. There are only FF
>>
>>What about the irq_table, which is later copied. The verify fails to.
>>For the same reason ?? CONFIG_COMPRESSED is default 1 or 0 ???
> 
>  
> No, different reason. I guess the ram at 0xc0000 is not visible or
> writable. The datasheet usually knows how to make that area writable.
> 
> 
> 
> Stefan.
> 


That c0000 memory, in the emulator in linuxbios, is most likely 
emulated. I would have to look.

Just remember, this is an emulator. There's no need to copy it to 
physical c0000, and we most likely don't. Again, this is memory, I can't 
look right now.

ron



From rminnich at lanl.gov  Thu Apr 27 05:13:05 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 26 Apr 2006 21:13:05 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <8a0c36780604260944k781cdeecgc7e3d16ccaa6f3b9@mail.gmail.com>
References: <m3fyk2i07i.fsf@maxwell.lnxi.com>
	<444F34C0.5080303@suehsi.de>	<444F3EA2.1000509@suehsi.de>
	<m3lktswvdu.fsf@maxwell.lnxi.com>	<444F56BC.8050906@suehsi.de>
	<20060426103209.GA14218@coresystems.de>	<444F7FCD.3070406@suehsi.de>
	<444F8A0F.1050607@suehsi.de>	<20060426140526.GA3910@coresystems.de>
	<444FA15E.8050408@suehsi.de>
	<8a0c36780604260944k781cdeecgc7e3d16ccaa6f3b9@mail.gmail.com>
Message-ID: <445036C1.9040401@lanl.gov>

Richard Smith wrote:
> On 4/26/06, Christian S?hs <chris at suehsi.de> wrote:
> 
> 
>>rom address for PCI: 00:09.0 = fffc0000
>>copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes
>>entering emulator
>>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>.
> 
> 
> Does the emulator not check for a valid ROM signature after it
> completes the copy?
> That needs to be fixed.

OH NO.

I just walked this code and did not realize we are wasting time copying 
the code to physical 0xc0000.

I don't see any reason to do this. I will talk to Ollie about it.

ron



From rminnich at lanl.gov  Thu Apr 27 05:14:27 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 26 Apr 2006 21:14:27 -0600
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <444F447D.1040108@suehsi.de>
References: <20060424124236.GA9541@coresystems.de>	<444CE768.1010606@suehsi.de>	<444CEAD6.3070901@suehsi.de>	<444D0F84.3060004@suehsi.de>	<8a0c36780604240947u4d887398ud2b969a444faa15e@mail.gmail.com>	<444D3E07.6010209@suehsi.de>	<20060424201007.GA32112@coresystems.de>	<444D4E7A.6040408@suehsi.de>	<444D5318.3000707@suehsi.de>	<444D5610.7050207@suehsi.de>	<20060424220735.GA15237@coresystems.de>	<444DE14C.8050402@suehsi.de>	<444E50A4.9080208@suehsi.de>	<444E44F9.3080107@lanl.gov>	<444E64BA.40306@suehsi.de>	<444E525D.9030408@lanl.gov>	<444E69B4.6000808@suehsi.de>	<444E6EE0.5000806@suehsi.de>	<444E7101.80600@suehsi.de>	<444E6048.4050302@lanl.gov>	<444E78C5.5030300@suehsi.de>	<444E6847.4080103@lanl.gov>	<444E9617.7080508@suehsi.de>	<444E98D0.3070401@suehsi.de>	<444EA64B.7050700@gmx.net>
	<444F447D.1040108@suehsi.de>
Message-ID: <44503713.3050708@lanl.gov>

can you run lspci -H1.

That goes to the hardware. You have to do it as root. If -H1 fails, do -H2.

There is clearly a problem with shadow rom and c segment, and stupid 
code should do a memcmp after the copy.

I appreciate your patience, and I am sorry this is being such a pain in 
the neck.

ron



From rminnich at lanl.gov  Thu Apr 27 05:15:31 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 26 Apr 2006 21:15:31 -0600
Subject: [LinuxBIOS] Want to know whether linuxbios works on my PC
In-Reply-To: <2ea7d6950604260046rce499cyafe0b6024c4cdbdb@mail.gmail.com>
References: <2ea7d6950604260046rce499cyafe0b6024c4cdbdb@mail.gmail.com>
Message-ID: <44503753.3010006@lanl.gov>

Zhen Xu wrote:
> Hi, all,
> 
> I'm interested in linuxbios and planning to do some experiments with it. 
> However, I don't know whether linuxbios works on my PC. It's a IBM 
> thinkcentre 8114, chip set is Intel 945G and the result of 'listpci 
> -vvv' is as below:

no, I'm sorry, intel is not a supporter of linuxbios at this time. We 
hope that will someday change -- they make nice parts.

ron




From eric at zyxod.com  Thu Apr 27 05:31:23 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 20:31:23 -0700
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>	
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
Message-ID: <44503B0B.4080101@zyxod.com>

Richard Smith wrote:

>On 4/26/06, Eric Poulsen <eric at zyxod.com> wrote:
>  
>
>>My kernel crash issue is attached below.  This one isn't an Exception 6
>>(that I can tell), but it's one I've seen before.  This happened twice
>>    
>>
>
>
>Have you used memtest86 as a payload and verified that your RAM is solid?
>
>--
>Richard A. Smith
>
>  
>

Factory BIOS:
Ran memtest86+ for four hours -- no errors.

Walltime Cached  RsvdMem MemMap    Cache ECC Test
          224M       76K e820-std  on    off std

LinuxBIOS + filo
Errors from C0000 to EFEFC
Walltime Cached  RsvdMem MemMap    Cache ECC Test
          224M        0  LinuxBIOS on    off std

Obviously, memtest86 isn't skipping the cmos -- I managed to pause it 
just as it hit C000, and looked at the error result -- AA 55 was in 
there.  It's reading the cmos, and failing to test it, as it should.

I'm not sure if this is a real issue with LB or not ...





From rminnich at lanl.gov  Thu Apr 27 05:24:17 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 26 Apr 2006 21:24:17 -0600
Subject: [LinuxBIOS] Is there sched_clock equivalent in LB?
In-Reply-To: <444FBE4B.4040006@zyxod.com>
References: <444FBE4B.4040006@zyxod.com>
Message-ID: <44503961.1090403@lanl.gov>

Eric Poulsen wrote:
> I was going to hack LB a bit, and add a timestamp, just like you see in 
> the newer Linux kernels, to look for potential bottlenecks specific to 
> my MLB. The kernel printk uses sched_clock() to get the current time.  
> Is there an equivalent call in LB?  I've looked through the code base 
> for files / code that has *clock* or *time* or something similar, but 
> without much luck.
> 
Look at ollie's serial_post. He added a tsc counter some time ago.

thanks

ron



From eric at zyxod.com  Thu Apr 27 05:34:10 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 20:34:10 -0700
Subject: [LinuxBIOS] Kernel crash output
In-Reply-To: <8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>	
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
Message-ID: <44503BB2.5020706@zyxod.com>

Richard Smith wrote:

>On 4/26/06, Eric Poulsen <eric at zyxod.com> wrote:
>  
>
>>My kernel crash issue is attached below.  This one isn't an Exception 6
>>(that I can tell), but it's one I've seen before.  This happened twice
>>    
>>
>
>
>Have you used memtest86 as a payload and verified that your RAM is solid?
>
>--
>Richard A. Smith
>
>  
>
Oh yeah, one other thing.

I booted LB, got a kernel crash, rebooted and ran memtest86 in LB, got 
the errors, rebooted again to a kernel, and it worked -- didn't need to 
reset the cmos using the factory BIOS.



From rminnich at lanl.gov  Thu Apr 27 05:28:42 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 26 Apr 2006 21:28:42 -0600
Subject: [LinuxBIOS] Tyan S2881 build tutorial online
In-Reply-To: <20060426220830.GA12620@io.pong.be>
References: <20060426220830.GA12620@io.pong.be>
Message-ID: <44503A6A.8070405@lanl.gov>

Ward Vandewege wrote:

> 
> We will be deploying 2 or 3 of these GX28 boxes shortly. Soon, all
> @(lists.)gnu.org and @fsf.org e-mail will be processed by machines running
> LinuxBIOS!

Ward, you have just totally made my day. Thanks, it's been a long one. 
This is GREAT.

ron



From eric at zyxod.com  Thu Apr 27 05:37:06 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 20:37:06 -0700
Subject: [LinuxBIOS] Is there sched_clock equivalent in LB?
In-Reply-To: <20060426232300.GA21714@daniel.localdomain>
References: <444FBE4B.4040006@zyxod.com>
	<20060426232300.GA21714@daniel.localdomain>
Message-ID: <44503C62.3040003@zyxod.com>

Daniel Parthey wrote:

>Eric Poulsen schrieb:
>  
>
>>I was going to hack LB a bit, and add a timestamp, just like you see in 
>>the newer Linux kernels, to look for potential bottlenecks specific to 
>>my MLB. The kernel printk uses sched_clock() to get the current time.  
>>Is there an equivalent call in LB?  I've looked through the code base 
>>for files / code that has *clock* or *time* or something similar, but 
>>without much luck.
>>    
>>
>
>I suppose MLB means VIA EPIA ML Board?
>  
>
I had meant Main Logic Board, but I guess it works both ways.

>On Intel compatible Pentium (or higher) boards like VIA EPIA, you could
>read the Time Stamp Counter (TSC) CPU register which tells you the number
>of cycles from the last machine reset. Use the "cpuid" assembler command
>as a barrier (to prevent out-of-order command execution) in combination
>with the "rdtsc" assembler command to read the time time stamp counter.
>The linux kernel sourcecode contains examples for this.
>  
>
My Intel assembly is 15 years rusty -- I'd have better luck doing this 
on a PIC.  My co-worker hacks Intel assembly -- I'll get him to help me.

>If you manage to get some inline assembler code into linuxbios,
>you could take two time stamp counter (TSC) values and store them somewhere.
>You can convert the number of ticks into real time units afterwards,
>you could either use the processor speed from /proc/cpuinfo or determine
>the number of processor cycles per second on your processor yourself.
>Disable automatic CPU clock adjust to have the CPU run at constant speed.
>
>bye,
>Daniel.
>  
>




From rminnich at lanl.gov  Thu Apr 27 05:32:57 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 26 Apr 2006 21:32:57 -0600
Subject: [LinuxBIOS] Epia ML 5000 success
In-Reply-To: <20060426235410.GA22086@daniel.localdomain>
References: <444E46D8.3050501@zyxod.com>	<8a0c36780604250914n68abd307tf084f1570ab7a078@mail.gmail.com>
	<20060426235410.GA22086@daniel.localdomain>
Message-ID: <44503B69.7050004@lanl.gov>

Daniel Parthey wrote:

> Would you mind making the wiki public, so that everybody here can create
> a wiki account by himself (like subscription to this list works) and
> contribute some small piece of docs, or do you have had bad experiences
> with an unmoderated wiki registration?


There have been way too many problem with jerks adding themselves to 
wikis and uploading viruses. We even had viruses uploaded to the tracker 
for a while.

It's better to have a human in the loop.

I really appreciate your willingness to add stuff to the wiki, please 
get an account !

thanks!

ron



From smithbone at gmail.com  Thu Apr 27 06:28:58 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 26 Apr 2006 23:28:58 -0500
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <44503AEE.4050900@zyxod.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<44503AEE.4050900@zyxod.com>
Message-ID: <8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>

>  LinuxBIOS + filo
>  Errors from C0000 to EFEFC
>  Walltime Cached  RsvdMem MemMap    Cache ECC Test
>            224M        0  LinuxBIOS on    off std
>
>  Obviously, memtest86 isn't skipping the cmos -- I managed to pause it just
> as it hit C000, and looked at the error result -- AA 55 was in there.  It's
> reading the cmos, and failing to test it, as it should.

That range is not CMOS.  CMOS is 128 bytes and you access it via
portIO.  Memtest86 never hits CMOS.  Those are your legacy video bios
and other shadow area ranges.  Depending on how they are enabled by
your setup code they may not be writeable.

Doubtfull its a problem though as Linux won't use those area for RAM.

--
Richard A. Smith



From rminnich at lanl.gov  Thu Apr 27 06:29:46 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 26 Apr 2006 22:29:46 -0600
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>
References: <444E5BD7.2080007@zyxod.com>
	<444E6DFF.4090208@lanl.gov>	<444F9984.6040207@zyxod.com>	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>	<44503AEE.4050900@zyxod.com>
	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>
Message-ID: <445048BA.6070808@lanl.gov>

OK, I know that at one point we had a motherboard that had weird cmos 
hardware. The cmos bits seemed to control motherboard functions BEFORE 
the CPU executed first instruction. What I really think was going on was 
that a piece of hardware also received the CMOS writes ... it was weird.

Eric, can you quick patch LB so that ALL writes to cmos are disabled? 
Just comment them out. Then try again. Something weird is going on.

ron



From eric at zyxod.com  Thu Apr 27 07:20:59 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 22:20:59 -0700
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>	
	<444F9984.6040207@zyxod.com>	
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>	
	<44503AEE.4050900@zyxod.com>
	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>
Message-ID: <445054BB.8020706@zyxod.com>

Ack, you're right -- was thinking ROM, but typed CMOS.  Well, makes my 
RAM tests pointless under LB.  I don't think it's a HW RAM problem, as 
it tested just fine under factory BIOS.

Richard Smith wrote:

>> LinuxBIOS + filo
>> Errors from C0000 to EFEFC
>> Walltime Cached  RsvdMem MemMap    Cache ECC Test
>>           224M        0  LinuxBIOS on    off std
>>
>> Obviously, memtest86 isn't skipping the cmos -- I managed to pause it just
>>as it hit C000, and looked at the error result -- AA 55 was in there.  It's
>>reading the cmos, and failing to test it, as it should.
>>    
>>
>
>That range is not CMOS.  CMOS is 128 bytes and you access it via
>portIO.  Memtest86 never hits CMOS.  Those are your legacy video bios
>and other shadow area ranges.  Depending on how they are enabled by
>your setup code they may not be writeable.
>
>Doubtfull its a problem though as Linux won't use those area for RAM.
>
>--
>Richard A. Smith
>
>  
>




From eric at zyxod.com  Thu Apr 27 07:21:41 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 26 Apr 2006 22:21:41 -0700
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <445048BA.6070808@lanl.gov>
References: <444E5BD7.2080007@zyxod.com>
	<444E6DFF.4090208@lanl.gov>	<444F9984.6040207@zyxod.com>	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>	<44503AEE.4050900@zyxod.com>
	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>
	<445048BA.6070808@lanl.gov>
Message-ID: <445054E5.8090306@zyxod.com>

Yes, but not tonight =)  Soon.

Ronald G Minnich wrote:

> OK, I know that at one point we had a motherboard that had weird cmos 
> hardware. The cmos bits seemed to control motherboard functions BEFORE 
> the CPU executed first instruction. What I really think was going on 
> was that a piece of hardware also received the CMOS writes ... it was 
> weird.
>
> Eric, can you quick patch LB so that ALL writes to cmos are disabled? 
> Just comment them out. Then try again. Something weird is going on.
>
> ron
>




From smithbone at gmail.com  Thu Apr 27 07:29:30 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 00:29:30 -0500
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <445054BB.8020706@zyxod.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<44503AEE.4050900@zyxod.com>
	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>
	<445054BB.8020706@zyxod.com>
Message-ID: <8a0c36780604262229t193a77aegafa169e56eea2322@mail.gmail.com>

On 4/27/06, Eric Poulsen <eric at zyxod.com> wrote:

> Ack, you're right -- was thinking ROM, but typed CMOS.  Well, makes my
> RAM tests pointless under LB.  I don't think it's a HW RAM problem, as
> it tested just fine under factory BIOS.

Well I was more concerned with the RAM under LinuxBIOS.  Ram settings
are very tricky.  Just makeing sure your board wasn't on the edge of
some timing or buffer drive spec.  That would be the cause of a lot of
op code issues.

--
Richard A. Smith



From chris at suehsi.de  Thu Apr 27 10:57:34 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 10:57:34 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
References: <m3lktswvdu.fsf@maxwell.lnxi.com>	<20060426140526.GA3910@coresystems.de>
	<444FA15E.8050408@suehsi.de>	<20060426152211.GA13826@coresystems.de>
	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>
	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>
	<444FC6A7.4080002@suehsi.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
Message-ID: <4450877E.3000501@suehsi.de>


> But that may be a lot of extra overhead I know some of the romcc
> setups are alreday tight on rom space.
> 
> To test you can just change line 36 in GX setup to be:
>         .long   BC_XMAP_2, 0xb0000000
> 

That doesn't work, after that I changed also the line 57 in 
model_gx1_init.c to the same value with no success.

Than I thinked about the value.


BC_XMAP_2 = 00000000h is default.

This word described the read/write/cache/pci access for 8 adress ranges.
for each range we have to set 4 bits. If I want to enable read write for 
all 8 ranges I should set bit 1 & 2 to high.

--> first range  0011
--> second range 0011
and so on

= 00110011001100110011001100110011

this should be 0x33333333

I have insert this to the both files and it works ;)

(but at the moment I'm not sure)

ok, what happens.

The LB debug spokes out the vga.bios on 0xc0000, now (for now I have not 
verified, if this is the whole vga.bios)
and the emu is running much longer as before in printed debug lines.
Later the emu stops with no error and the system seems to hang, but we 
should now on the right way.

A few questions.

0xc0000 - 0xfffff is normaly Cached?
Means, should I set the cache bit?

How is the range 640k-1MB normally set in other systems.

If I right above, BC_XMAP_1 is set to 0x60 I think that is not very much 
for a system. think about my other problems later.

I would like to set the magic bit for vga to 00 (at the moment it is set 
for 4K I/O range and all vga instructions are enabled)



chris

chris




> Seems to me we've had this discussion before but I never remember the result. :(
> 
> --
> Richard A. Smith
> 




From chris at suehsi.de  Thu Apr 27 11:12:00 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 11:12:00 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <4450877E.3000501@suehsi.de>
References: <m3lktswvdu.fsf@maxwell.lnxi.com>	<20060426140526.GA3910@coresystems.de>	<444FA15E.8050408@suehsi.de>	<20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
	<4450877E.3000501@suehsi.de>
Message-ID: <44508AE0.4080805@suehsi.de>

Here is the output

chris
> 
> 
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug_7.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060427/d9762a5e/attachment.ksh>

From stepan at coresystems.de  Thu Apr 27 10:52:11 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 27 Apr 2006 10:52:11 +0200
Subject: [LinuxBIOS] Epia ML 5000 success
In-Reply-To: <20060426235410.GA22086@daniel.localdomain>
References: <444E46D8.3050501@zyxod.com>
	<8a0c36780604250914n68abd307tf084f1570ab7a078@mail.gmail.com>
	<20060426235410.GA22086@daniel.localdomain>
Message-ID: <20060427085211.GA22299@coresystems.de>

* Daniel Parthey <pada at chemonline.de> [060427 01:54]:
> Would you mind making the wiki public, so that everybody here can create
> a wiki account by himself (like subscription to this list works) and
> contribute some small piece of docs, or do you have had bad experiences
> with an unmoderated wiki registration?
 
No, sorry, I'm not going to do that. For two reasons:

 - wiki spammers/hackers
 - quality of the wiki information

> Some people would probably never try to write an e-mail to Ron or Stefan
> and register as a "contributor", even if they had to add some small but
> important facts about their particular linuxbios setup.

Why would you think so? A lot of people write to us asking for an
account to "see the secret information we hide on the web pages".

Which makes me think, thanks god they did not accidently start writing
stuff in the wiki before even reading.

Stefan




From stepan at coresystems.de  Thu Apr 27 11:02:02 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 27 Apr 2006 11:02:02 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <4450877E.3000501@suehsi.de>
References: <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de>
	<444FA357.7000907@suehsi.de>
	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
	<20060426165244.GA26131@coresystems.de>
	<444FBB2B.6030701@suehsi.de> <444FC1E3.50802@suehsi.de>
	<444FC6A7.4080002@suehsi.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
	<4450877E.3000501@suehsi.de>
Message-ID: <20060427090201.GB22299@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060427 10:57]:
> 0xc0000 - 0xfffff is normaly Cached?

you can often decide about this in the bios options. which makes little
sense, except you plan to rub your nose permanently on an old rom chip.

> Means, should I set the cache bit?
 
You might, if you plan to put something there that should be readable
later (and is read a lot of times). So if you are planning to use Linux
you don't need to care.

> How is the range 640k-1MB normally set in other systems.

0xe0000-0xfffff is always "cached" in awkward bios, as they uncompress 
parts of their code to those memory adresses where it stays for "bios
callbacks". We don't have that, so its not an issue.

You might want to play with this again if you switch CONFIG_COMPRESS on
but want the pirq table in 0xf0000-0xfffff without failing.

> I would like to set the magic bit for vga to 00 (at the moment it is set 
> for 4K I/O range and all vga instructions are enabled)
 
run lspci -xxx on LinuxBIOS and factory BIOS and start comparing the
differences, or start looking in the datasheets for it..
 
    Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Thu Apr 27 11:09:09 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 27 Apr 2006 11:09:09 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <44508AE0.4080805@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>
	<444FA357.7000907@suehsi.de>
	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
	<20060426165244.GA26131@coresystems.de>
	<444FBB2B.6030701@suehsi.de> <444FC1E3.50802@suehsi.de>
	<444FC6A7.4080002@suehsi.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>
Message-ID: <20060427090909.GC22299@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060427 11:12]:
> Here is the output
 
Try disabling quite some of the debug stuff (i would start with
trace_on.. This will rule out timing issues.

> 	AX=2001  BX=0405  CX=0000  DX=03c4  SP=ffe8  BP=fff6  SI=0000  DI=0c97
> 	DS=0000  ES=c000  SS=c000  CS=c000  IP=6bc4   NV UP DI PL NZ NA PO NC
> c000:6bc2 8a05                MOV	AL,[DI]
> 	AX=2067  BX=0405  CX=0000  DX=03c4  SP=ffe8  BP=fff6  SI=0000  DI=0c97
> 	DS=0000  ES=c000  SS=c000  CS=c000  IP=6bc5   NV UP DI PL NZ NA PO NC
> c000:6bc4 47                  INC	DI
> 	AX=2067  BX=0405  CX=0000  DX=03c4  SP=ffe8  BP=fff6  SI=0000  DI=0c98
> 	DS=0000  ES=c000  SS=c000  CS=c000  IP=6bc7   NV UP DI PL NZ NA PO NC
> c000:6bc5 b2c2                MOV	DL,c2
> 	AX=2067  BX=0405  CX=0000  DX=03c2  SP=ffe8  BP=fff6  SI=0000  DI=0c98
> 	DS=0000  ES=c000  SS=c000  CS=c000  IP=6bc8   NV UP DI PL NZ NA PO NC
> c000:6bc7 ee                  OUT	DX,AL
> 	A

So 3c2 (DX) is the Misc Output Register of VGA. But it might one of the
previous outbs that make it hang. Better keep that log for later
debugging.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Thu Apr 27 11:11:48 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 27 Apr 2006 11:11:48 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <4450346D.70509@lanl.gov>
References: <444F3EA2.1000509@suehsi.de> <m3lktswvdu.fsf@maxwell.lnxi.com>
	<444F56BC.8050906@suehsi.de>
	<20060426103209.GA14218@coresystems.de>
	<444F7FCD.3070406@suehsi.de> <444F8A0F.1050607@suehsi.de>
	<20060426140526.GA3910@coresystems.de> <444FA15E.8050408@suehsi.de>
	<20060426152211.GA13826@coresystems.de> <4450346D.70509@lanl.gov>
Message-ID: <20060427091148.GD22299@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060427 05:03]:
> That c0000 memory, in the emulator in linuxbios, is most likely 
> emulated.

The emulator is setup to use the real memory in the 
0x000000-0xfffff area.

> Just remember, this is an emulator. There's no need to copy it to 
> physical c0000, and we most likely don't. 

It sounds funny, but we do. 

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Thu Apr 27 11:27:46 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 27 Apr 2006 11:27:46 +0200
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <44503B0B.4080101@zyxod.com>
References: <444E5BD7.2080007@zyxod.com> <444E6DFF.4090208@lanl.gov>
	<444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<44503B0B.4080101@zyxod.com>
Message-ID: <20060427092746.GA20638@coresystems.de>

* Eric Poulsen <eric at zyxod.com> [060427 05:31]:
> Factory BIOS:
> Ran memtest86+ for four hours -- no errors.
> 
> Walltime Cached  RsvdMem MemMap    Cache ECC Test
>           224M       76K e820-std  on    off std
> 
> LinuxBIOS + filo
> Errors from C0000 to EFEFC
> Walltime Cached  RsvdMem MemMap    Cache ECC Test
>           224M        0  LinuxBIOS on    off std
> 
> Obviously, memtest86 isn't skipping the cmos -- I managed to pause it 
> just as it hit C000, and looked at the error result -- AA 55 was in 
> there.  It's reading the cmos, and failing to test it, as it should.

Is the factory bios specially marking the C segment in the e820 table?

I doubt they mark it as overwritable ram.

Stefan


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Thu Apr 27 13:41:00 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 13:41:00 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <20060427090909.GC22299@coresystems.de>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>
	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>
	<44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de>
Message-ID: <4450ADCC.3020102@suehsi.de>


>  
> Try disabling quite some of the debug stuff (i would start with
> trace_on.. This will rule out timing issues.
> 
> 

Well, thanks to all my heros here ;)

Step by step and now it runs.

Ok, I have disabled the additional debug lines for the image verifying 
and disabled the XEMU_trace_on()

After a minute (after 3 int vectors, where the screens changed its 
status from standby to on) the Console comes up.

Puuuuh hard work ;)

I think to disable completly the debug in the emulator will things make 
faster ( I hope so)

12.4 is still there, you see the 4K adress range on lspci.
I'm not sure but why is this on 12.4?
However, now I will try to enable the other memory and disable the 
internal vga stuff completly.

snipped output attached:
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug_8.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060427/8bd2052d/attachment.ksh>

From chris at suehsi.de  Thu Apr 27 13:58:52 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 13:58:52 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <20060427090201.GB22299@coresystems.de>
References: <444FA15E.8050408@suehsi.de>	<20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>
	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>
	<20060427090201.GB22299@coresystems.de>
Message-ID: <4450B1FC.5050509@suehsi.de>


> You might want to play with this again if you switch CONFIG_COMPRESS on
> but want the pirq table in 0xf0000-0xfffff without failing.
> 
> 

What is the default. I think CONFIG_COMPRESSED is default set to 1

BC_XMAP_3 is also disabled in the current state, there is the 0xf0000 
range located and therefor not writable.

this should be the reason for failing.

chris



From chris at suehsi.de  Thu Apr 27 14:20:23 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 14:20:23 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <4450B1FC.5050509@suehsi.de>
References: <444FA15E.8050408@suehsi.de>	<20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<20060427090201.GB22299@coresystems.de>
	<4450B1FC.5050509@suehsi.de>
Message-ID: <4450B707.8020701@suehsi.de>


> What is the default. I think CONFIG_COMPRESSED is default set to 1
> 
> BC_XMAP_3 is also disabled in the current state, there is the 0xf0000 
> range located and therefor not writable.
> 
> this should be the reason for failing.
>


Yup, I have enabled the memory and the irq_table is verified well ;)



> chris
> 




From chris at suehsi.de  Thu Apr 27 14:22:39 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 14:22:39 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450ADCC.3020102@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de>
Message-ID: <4450B78F.4080101@suehsi.de>


> 
> Puuuuh hard work ;)
> 
> I think to disable completly the debug in the emulator will things make 
> faster ( I hope so)
> 

It seems not :(

To initialize the vga is done in 90!!! seconds :(

I'm frustrated ;)

chris




From lucasvr at gobolinux.org  Thu Apr 27 13:09:43 2006
From: lucasvr at gobolinux.org (Lucas C. Villa Real)
Date: Thu, 27 Apr 2006 08:09:43 -0300
Subject: [LinuxBIOS] Is there sched_clock equivalent in LB?
In-Reply-To: <44503C62.3040003@zyxod.com>
References: <444FBE4B.4040006@zyxod.com>
	<20060426232300.GA21714@daniel.localdomain>
	<44503C62.3040003@zyxod.com>
Message-ID: <2c03f9590604270409r56e25d8fu1dbffca5637de7f0@mail.gmail.com>

On 4/27/06, Eric Poulsen <eric at zyxod.com> wrote:
> Daniel Parthey wrote:
>
> >Eric Poulsen schrieb:
> >
> >
> >>I was going to hack LB a bit, and add a timestamp, just like you see in
> >>the newer Linux kernels, to look for potential bottlenecks specific to
> >>my MLB. The kernel printk uses sched_clock() to get the current time.
> >>Is there an equivalent call in LB?  I've looked through the code base
> >>for files / code that has *clock* or *time* or something similar, but
> >>without much luck.
> >>
> >>
> >
> >I suppose MLB means VIA EPIA ML Board?
> >
> >
> I had meant Main Logic Board, but I guess it works both ways.
>
> >On Intel compatible Pentium (or higher) boards like VIA EPIA, you could
> >read the Time Stamp Counter (TSC) CPU register which tells you the number
> >of cycles from the last machine reset. Use the "cpuid" assembler command
> >as a barrier (to prevent out-of-order command execution) in combination
> >with the "rdtsc" assembler command to read the time time stamp counter.
> >The linux kernel sourcecode contains examples for this.
> >
> >
> My Intel assembly is 15 years rusty -- I'd have better luck doing this
> on a PIC.  My co-worker hacks Intel assembly -- I'll get him to help me.

I'm not yet started at LB development, but this sample code can
probably do the job for you, given that you're using GCC:

   #define do_rdtsc(ticks) \
     __asm__ volatile (".byte 0x0f, 0x31" : "=A" (ticks));

   uint64_t current_ticks;
   do_rdtsc(current_ticks);

This instruction returns a 64-bit value in EDX:EAX. If you don't need
to use 64 bits, getting the lower 32 bits will require a change on
"=A" by "=a" and on uint64_t by uint32_t.

Hope that helps,

--
Lucas
powered by /dev/dsp



From chris at suehsi.de  Thu Apr 27 15:25:24 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 15:25:24 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
References: <m3lktswvdu.fsf@maxwell.lnxi.com>	<20060426140526.GA3910@coresystems.de>
	<444FA15E.8050408@suehsi.de>	<20060426152211.GA13826@coresystems.de>
	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>
	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>
	<444FC6A7.4080002@suehsi.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
Message-ID: <4450C644.6060202@suehsi.de>


> 
> To test you can just change line 36 in GX setup to be:
>         .long   BC_XMAP_2, 0xb0000000
> 

Well, I see. You want to enable the PCI accessable, too.

Should be 1011 = b

but what about the other ranges.

How should I read the word.

00 00 00 00
^^ ^^ ^^ ^^
01 23 45 67

or

76 54 32 10

where are the first 4 bits located? Right or Left?

It seems you like the first read

but in that case only the first 16K are enabled
for 0xb0000000

= c0000 - c3fff

I'm not sure, but the debug output is not much fast. If I remember right 
for this test I haven't seen other characters as FF

and so the other read is right

chris



From rminnich at lanl.gov  Thu Apr 27 15:22:13 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 07:22:13 -0600
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <445054BB.8020706@zyxod.com>
References: <444E5BD7.2080007@zyxod.com>
	<444E6DFF.4090208@lanl.gov>		<444F9984.6040207@zyxod.com>		<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>		<44503AEE.4050900@zyxod.com>	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>
	<445054BB.8020706@zyxod.com>
Message-ID: <4450C585.5060800@lanl.gov>

Eric Poulsen wrote:
> Ack, you're right -- was thinking ROM, but typed CMOS.  Well, makes my 
> RAM tests pointless under LB.  I don't think it's a HW RAM problem, as 
> it tested just fine under factory BIOS.


the factory bios ram tests are useless.

thanks

ron



From rminnich at lanl.gov  Thu Apr 27 15:27:21 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 07:27:21 -0600
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450B78F.4080101@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>
	<4450B78F.4080101@suehsi.de>
Message-ID: <4450C6B9.50406@lanl.gov>

Christian S?hs wrote:
>>Puuuuh hard work ;)
>>
>>I think to disable completly the debug in the emulator will things make 
>>faster ( I hope so)
>>
> 
> 
> It seems not :(
> 
> To initialize the vga is done in 90!!! seconds :(


WOW. WHAT is going on ? Normal vga is enabled in a second or two at 
worst in most cases.

ron



From steven.goodrich at amd.com  Thu Apr 27 15:41:06 2006
From: steven.goodrich at amd.com (Goodrich,Steven)
Date: Thu, 27 Apr 2006 08:41:06 -0500
Subject: [LinuxBIOS] Loading "other" OS's?
Message-ID: <0E81348C5627674A9C0061413EBFF5F74F4270@SAUSEXMB2.amd.com>

I work on AMD's Geode processors -- in the BIOS group -- and I'd like to
know if LinuxBIOS can meet our needs for loading other Operating Systems
(Windows CE) in addition to Linux.  Can anyone tell me how I'd load a
WinCE image using LinuxBIOS as the loader?
 
Thanks!

    -- Steve G.

Steve Goodrich (Steven.Goodrich at amd.com <mailto:Steven.Goodrich at amd.com>
)
Advanced Micro Devices, Inc.
1351 S. Sunset Street
Mail Stop 83-36
Longmont, CO  80501
303-774-5129    (fax: 303-774-5801)
http://www.amd.com/embeddedprocessors 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060427/cf668792/attachment.html>

From stepan at coresystems.de  Thu Apr 27 16:35:44 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 27 Apr 2006 16:35:44 +0200
Subject: [LinuxBIOS] Loading "other" OS's?
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4270@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4270@SAUSEXMB2.amd.com>
Message-ID: <20060427143544.GA28879@coresystems.de>

* Goodrich,Steven <steven.goodrich at amd.com> [060427 15:41]:
> I work on AMD's Geode processors -- in the BIOS group -- and I'd like to know
> if LinuxBIOS can meet our needs for loading other Operating Systems (Windows
> CE) in addition to Linux.  Can anyone tell me how I'd load a WinCE image using
> LinuxBIOS as the loader?

I haven't looked at Win CE in particular, but most "other" operating
systems can be booted with a relatively low effort. It just has not been
standardized yet.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Thu Apr 27 17:57:36 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 17:57:36 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450C6B9.50406@lanl.gov>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	<4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov>
Message-ID: <4450E9F0.1000904@suehsi.de>


>>
>>To initialize the vga is done in 90!!! seconds :(
> 
> 
> 
> WOW. WHAT is going on ? Normal vga is enabled in a second or two at 
> worst in most cases.

Good question, I don't know. I hope you has some answers :D

chris

> 
> ron
> 




From chris at suehsi.de  Thu Apr 27 18:03:57 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 18:03:57 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450ADCC.3020102@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>
	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>
	<44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de>
Message-ID: <4450EB6D.3090601@suehsi.de>

Ok,
> rom address for PCI: 00:09.0 = fffc0000
> copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes
> int10 vector at c41b4

Screen comes up from standby with no output

> int10 vector at c41b4

Sreen flickers two times in about 30 sec

> int10 vector at c41b4

It seems after that, the console is switched on quick,

> halt_sys: file /root/src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
> halted								// But it starts


I think, i should enable again the debug, because in the first try, as I 
say system hangs, I havn't wait long enough ;)

chris



From smithbone at gmail.com  Thu Apr 27 16:53:12 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 09:53:12 -0500
Subject: [LinuxBIOS] Loading "other" OS's?
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4270@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4270@SAUSEXMB2.amd.com>
Message-ID: <8a0c36780604270753j6173089crb6a90958b10d47d8@mail.gmail.com>

On 4/27/06, Goodrich,Steven <steven.goodrich at amd.com> wrote:
>
> I work on AMD's Geode processors -- in the BIOS group -- and I'd like to
> know if LinuxBIOS can meet our needs for loading other Operating Systems
> (Windows CE) in addition to Linux.  Can anyone tell me how I'd load a WinCE
> image using LinuxBIOS as the loader?

Thats good to see that you are looking our way.

Its really going to depend on what kind of Legacy BIOS services WinCE
depends on.  I know CE is somewhat cross platform.  Does it depend on
legacy BIOS services?

If so then:

Have a look at ADLO on the wiki under payloads.  Using ADLO+bochs bios
you should be able to provide an enviroment that is close to what the
CE loader would expect.

Using ADLO+Bochs win2k has been sucessfully loaded and I've used it to
init several different video cards and run LILO. (Never tried GRUB)

All of this however was done under V1.  Nobody has tried to use ADLO
under V2.  Porting it over however should be trivial since its just a
payload.  No one has needed it yet I guess.

The copy of Bochs BIOS included with ADLO is really old and could
probally use an update.  I'm sure many more bios services have been
added.  If you update the Bochs BIOS you will have to change the IDE
routines.  They work ok for the "emulated" ide but not when you run
them on real hardware.    I don't remember offhand what the exact
changes were but they were not too complicated.

If not:

You will need to create/convert your winCE image into an ELF image. 
An elf image payload will just load and run.

I guess a hybird solution might be to load FILO as the payload and
extend FILO to be able to grok WinCE images.  Is the structure of the
WinCE image known?

--
Richard A. Smith



From smithbone at gmail.com  Thu Apr 27 17:07:37 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 10:07:37 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4450C6B9.50406@lanl.gov>
References: <20060426152211.GA13826@coresystems.de> <444FC1E3.50802@suehsi.de>
	<444FC6A7.4080002@suehsi.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de> <4450ADCC.3020102@suehsi.de>
	<4450B78F.4080101@suehsi.de> <4450C6B9.50406@lanl.gov>
Message-ID: <8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>

> > It seems not :(
> >
> > To initialize the vga is done in 90!!! seconds :(
>
>
> WOW. WHAT is going on ? Normal vga is enabled in a second or two at
> worst in most cases.
>

Its interesting that Nick Barker reported a long delay when trying to
run the via video bios on and epia under  the emulator.  Only his bios
never worked.  Chris is using a gx1 and sees a  long delay as well but
his actually works.

In both cases its a somewhat off-color x86.  I wonder if the emulator
is making some assumption that isn't valid on these platforms.

Chris:  I don't remember you reporting that the usermode emulator took
that long.  Will you please enable all the same debugging options and
compare the run times.

Another thing to consider is that the in-tree emulator may be running
in a non-optimal enviroment where the user-mode emulator has had Linux
booted to fix up the chipset.

What does the emulator do with access to the timer?  I know I had a
problem a long time ago under the user mode emulator with a vbios that
didn't like the extra delays associated with being under the emulator.
 It caused the bios's delay function to hang out for _much_ longer
than requested.

--
Richard A. Smith



From rminnich at lanl.gov  Thu Apr 27 17:09:11 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 09:09:11 -0600
Subject: [LinuxBIOS] Loading "other" OS's?
In-Reply-To: <8a0c36780604270753j6173089crb6a90958b10d47d8@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4270@SAUSEXMB2.amd.com>
	<8a0c36780604270753j6173089crb6a90958b10d47d8@mail.gmail.com>
Message-ID: <4450DE97.1060805@lanl.gov>

Richard Smith wrote:

> Its really going to depend on what kind of Legacy BIOS services WinCE
> depends on.  I know CE is somewhat cross platform.  Does it depend on
> legacy BIOS services?

I know that someobody was booting CE years ago under linuxbios. Hamish? 
Was that you?


I don't think they needed ADLO.


> 
> You will need to create/convert your winCE image into an ELF image. 
> An elf image payload will just load and run.
> 

we might consider adding a handler for CE binaries. I'm already thinking 
of adding one for Plan 9 a.out anyway.

ron



From rminnich at lanl.gov  Thu Apr 27 17:09:45 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 09:09:45 -0600
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450E9F0.1000904@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	<4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov> <4450E9F0.1000904@suehsi.de>
Message-ID: <4450DEB9.6030608@lanl.gov>

Christian S?hs wrote:
> 
>>>
>>> To initialize the vga is done in 90!!! seconds :(
>>
>>
>>
>>
>> WOW. WHAT is going on ? Normal vga is enabled in a second or two at 
>> worst in most cases.
> 
> 
> Good question, I don't know. I hope you has some answers :D

First, obvious possible issue is that C segment is not cached.

But I want to KILL that use of C segment. I'm going to ask Ollie about 
this today.

ron



From smithbone at gmail.com  Thu Apr 27 17:18:13 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 10:18:13 -0500
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <4450C644.6060202@suehsi.de>
References: <m3lktswvdu.fsf@maxwell.lnxi.com>
	<20060426152211.GA13826@coresystems.de> <444FA357.7000907@suehsi.de>
	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>
	<20060426165244.GA26131@coresystems.de> <444FBB2B.6030701@suehsi.de>
	<444FC1E3.50802@suehsi.de> <444FC6A7.4080002@suehsi.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
	<4450C644.6060202@suehsi.de>
Message-ID: <8a0c36780604270818i5038bd5drede88bb9fef4ab0d@mail.gmail.com>

On 4/27/06, Christian S?hs <chris at suehsi.de> wrote:

> > To test you can just change line 36 in GX setup to be:
> >         .long   BC_XMAP_2, 0xb0000000
> >
>
> Well, I see. You want to enable the PCI accessable, too.
>
> Should be 1011 = b

Right.  I wasn't sure if it needed that but it sounds reasonable.  The
cache bit may also by some thing to play with.  Actually what you need
to do is boot with factory BIOS and read back the settings to see what
they have.

> but what about the other ranges.

There shouldn't be much of a problem with setting them all.  I was
just picking a starting point.

It would be be a good idea if you just enabled them one-by-one so that
we know what ranges it _really_ needs.  Perhpas we can make them on by
default.

> 76 54 32 10
> where are the first 4 bits located? Right or Left?

Bit 31 is the left most bit and Bit 0 is the right most.

0x76543210 would be:

0111 0110 0101 0100 0011 0010 0001 0000

--
Richard A. Smith



From rminnich at lanl.gov  Thu Apr 27 17:10:22 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 09:10:22 -0600
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450EB6D.3090601@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>
	<4450EB6D.3090601@suehsi.de>
Message-ID: <4450DEDE.2090902@lanl.gov>

Christian S?hs wrote:
> Ok,
> 
>>rom address for PCI: 00:09.0 = fffc0000
>>copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes
>>int10 vector at c41b4
> 
> 
> Screen comes up from standby with no output
> 
> 
>>int10 vector at c41b4
> 
> 
> Sreen flickers two times in about 30 sec
> 
> 
>>int10 vector at c41b4
> 
> 
> It seems after that, the console is switched on quick,
> 
> 
>>halt_sys: file /root/src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
>>halted								// But it starts

That's just how we force the emulator to quit. This is a "GOOD" message :-0)

ron



From chris at suehsi.de  Thu Apr 27 18:35:37 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 18:35:37 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
References: <20060426152211.GA13826@coresystems.de>
	<444FC1E3.50802@suehsi.de>	 <444FC6A7.4080002@suehsi.de>	
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>	
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de>	 <4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov>
	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
Message-ID: <4450F2D9.3040603@suehsi.de>


> 
> Chris:  I don't remember you reporting that the usermode emulator took
> that long.  Will you please enable all the same debugging options and
> compare the run times.
> 

Ok, I will have a second try with enabled debug
XEMU_trace_on()

As I say, I'm not sure if I wait long enough :D

Unfortunatly, I can't find the debug stuff for "testbios"
Is there any or is it done via parameter like --debug

chris



From rminnich at lanl.gov  Thu Apr 27 17:18:52 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 09:18:52 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
References: <20060426152211.GA13826@coresystems.de>
	<444FC1E3.50802@suehsi.de>	 <444FC6A7.4080002@suehsi.de>	
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>	
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de>	 <4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov>
	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
Message-ID: <4450E0DC.70900@lanl.gov>

Richard Smith wrote:

> In both cases its a somewhat off-color x86.  I wonder if the emulator
> is making some assumption that isn't valid on these platforms.

I'm sorta convinced that it is becuase C0000 is not cached. Here is a 
simple test:

In this file:
src/devices/pci_rom.c

see this code:
         if (PCI_CLASS_DISPLAY_VGA == rom_data->class_hi) {
#if CONFIG_CONSOLE_VGA == 1
         #if CONFIG_CONSOLE_VGA_MULTI == 0
                 if (dev != vga_pri) return NULL; // only one VGA supported
         #endif
                 printk_debug("copying VGA ROM Image from 0x%x to 0x%x, 
0x%x bytes\n",
                             rom_header, PCI_VGA_RAM_IMAGE_START, rom_size);
                 memcpy(PCI_VGA_RAM_IMAGE_START, rom_header, rom_size);
                 vga_inited = 1;
                 return (struct rom_header *) (PCI_VGA_RAM_IMAGE_START);
#endif
         } else {

OK, let's fake it out. This is gross, but This IS A Test: add just 3 
lines after the 'if':

         if (PCI_CLASS_DISPLAY_VGA == rom_data->class_hi) {
			/* THIS IS A TEST */
		static char image[64*1024];
#undef PCI_VGA_RAM_IMAGE_START
#define PCI_VGA_RAM_IMAGE_START image
			/* THIS IS THE END OF THE CHANGES */
#if CONFIG_CONSOLE_VGA == 1
         #if CONFIG_CONSOLE_VGA_MULTI == 0
                 if (dev != vga_pri) return NULL; // only one VGA supported
         #endif
                 printk_debug("copying VGA ROM Image from 0x%x to 0x%x, 
0x%x bytes\n",
                             rom_header, PCI_VGA_RAM_IMAGE_START, rom_size);
                 memcpy(PCI_VGA_RAM_IMAGE_START, rom_header, rom_size);
                 vga_inited = 1;
                 return (struct rom_header *) (PCI_VGA_RAM_IMAGE_START);
#endif
         } else {


This is going to relocate the vga image to cached memory. This is OK! 
The emulator can use anything as memory -- it's an emulator.

I think this is ought to work. It's worth a try ...

> 
> Chris:  I don't remember you reporting that the usermode emulator took
> that long.  Will you please enable all the same debugging options and
> compare the run times.

yes, and the big difference: user-mode emulator just uses ram for the C 
segment ...

> 
> Another thing to consider is that the in-tree emulator may be running
> in a non-optimal enviroment where the user-mode emulator has had Linux
> booted to fix up the chipset.

I think it's caching. optimization should not be a 100x slowdown, in 
this case.

Let's try this if that's ok.

ron



From smithbone at gmail.com  Thu Apr 27 17:34:54 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 10:34:54 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4450E0DC.70900@lanl.gov>
References: <20060426152211.GA13826@coresystems.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de> <4450ADCC.3020102@suehsi.de>
	<4450B78F.4080101@suehsi.de> <4450C6B9.50406@lanl.gov>
	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
	<4450E0DC.70900@lanl.gov>
Message-ID: <8a0c36780604270834y6016cb6fn47a5ee8bae19c8d9@mail.gmail.com>

>
> I think it's caching. optimization should not be a 100x slowdown, in
> this case.
>
> Let's try this if that's ok.

Thats what I meant by non-optimal. *grin*

--
Richard A. Smith



From eric at zyxod.com  Thu Apr 27 18:06:28 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 27 Apr 2006 09:06:28 -0700
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <4450C585.5060800@lanl.gov>
References: <444E5BD7.2080007@zyxod.com>	<444E6DFF.4090208@lanl.gov>		<444F9984.6040207@zyxod.com>		<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>		<44503AEE.4050900@zyxod.com>	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>	<445054BB.8020706@zyxod.com>
	<4450C585.5060800@lanl.gov>
Message-ID: <4450EC04.2070606@zyxod.com>

I should have been more clear: I ran memtest86+ using the Factory BIOS 
and Grub

Ronald G Minnich wrote:
> Eric Poulsen wrote:
>   
>> Ack, you're right -- was thinking ROM, but typed CMOS.  Well, makes my 
>> RAM tests pointless under LB.  I don't think it's a HW RAM problem, as 
>> it tested just fine under factory BIOS.
>>     
>
>
> the factory bios ram tests are useless.
>
> thanks
>
> ron
>
>   




From chris at suehsi.de  Thu Apr 27 19:41:10 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 19:41:10 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4450E0DC.70900@lanl.gov>
References: <20060426152211.GA13826@coresystems.de>	<444FC1E3.50802@suehsi.de>	
	<444FC6A7.4080002@suehsi.de>		<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>		<4450877E.3000501@suehsi.de>
	<44508AE0.4080805@suehsi.de>		<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	
	<4450B78F.4080101@suehsi.de>	<4450C6B9.50406@lanl.gov>	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
	<4450E0DC.70900@lanl.gov>
Message-ID: <44510236.8000803@suehsi.de>


> 
> I think it's caching. optimization should not be a 100x slowdown, in 
> this case.
> 
> Let's try this if that's ok.
> 
> ron
> 

Sorry, but that doesn't work :(

her is the output.

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_image.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060427/16f6def2/attachment.ksh>

From chris at suehsi.de  Thu Apr 27 19:43:19 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 19:43:19 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450DEB9.6030608@lanl.gov>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	<4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov> <4450E9F0.1000904@suehsi.de>
	<4450DEB9.6030608@lanl.gov>
Message-ID: <445102B7.6000908@suehsi.de>


>>
>>
>>
>> Good question, I don't know. I hope you has some answers :D
> 
> 
> First, obvious possible issue is that C segment is not cached.

Well, at the moment c0000 - cffff are not cached, they are only r/w and 
pci accessable

> 
> But I want to KILL that use of C segment. I'm going to ask Ollie about 
> this today.
> 
> ron
> 




From chris at suehsi.de  Thu Apr 27 19:47:29 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 19:47:29 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
References: <20060426152211.GA13826@coresystems.de>
	<444FC1E3.50802@suehsi.de>	 <444FC6A7.4080002@suehsi.de>	
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>	
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de>	 <4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov>
	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
Message-ID: <445103B1.805@suehsi.de>


> 
> Chris:  I don't remember you reporting that the usermode emulator took
> that long.  Will you please enable all the same debugging options and
> compare the run times.
>

I have enabled all debug lines in biosemu.c
XEMU_trace_on() is disabled, because I remember that the machine stops 
or hangs.

In this case LB stops too after a few lines.

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_debug_2.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060427/ceee0f04/attachment.ksh>

From chris at suehsi.de  Thu Apr 27 19:50:29 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 19:50:29 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4450E0DC.70900@lanl.gov>
References: <20060426152211.GA13826@coresystems.de>	<444FC1E3.50802@suehsi.de>	
	<444FC6A7.4080002@suehsi.de>		<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>		<4450877E.3000501@suehsi.de>
	<44508AE0.4080805@suehsi.de>		<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	
	<4450B78F.4080101@suehsi.de>	<4450C6B9.50406@lanl.gov>	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
	<4450E0DC.70900@lanl.gov>
Message-ID: <44510465.7030500@suehsi.de>


> 			/* THIS IS A TEST */
> 		static char image[64*1024];

should I use 32*1024 instead

> #undef PCI_VGA_RAM_IMAGE_START
> #define PCI_VGA_RAM_IMAGE_START image
> 			/* THIS IS THE END OF THE CHANGES */



From smithbone at gmail.com  Thu Apr 27 18:34:14 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 11:34:14 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <445103B1.805@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de> <4450ADCC.3020102@suehsi.de>
	<4450B78F.4080101@suehsi.de> <4450C6B9.50406@lanl.gov>
	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
	<445103B1.805@suehsi.de>
Message-ID: <8a0c36780604270934l1683032es94e0c352c44212f9@mail.gmail.com>

On 4/27/06, Christian S?hs <chris at suehsi.de> wrote:

> I have enabled all debug lines in biosemu.c
> XEMU_trace_on() is disabled, because I remember that the machine stops
> or hangs.
>

Ok.. I don't know about the rest of you but I'm awash in all the
different permutatios.  I don't know what worked and what didn't.

Can yo post up a summary of what things work and what things don't. 
Both usemode and in-tree.

--
Richard A. Smith



From chris at suehsi.de  Thu Apr 27 20:03:46 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 20:03:46 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44510465.7030500@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FC1E3.50802@suehsi.de>		<444FC6A7.4080002@suehsi.de>		<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>		<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>		<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>		<4450B78F.4080101@suehsi.de>	<4450C6B9.50406@lanl.gov>	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>	<4450E0DC.70900@lanl.gov>
	<44510465.7030500@suehsi.de>
Message-ID: <44510782.2010509@suehsi.de>

Christian S?hs schrieb:
>>			/* THIS IS A TEST */
>>		static char image[64*1024];
> 
> 
> should I use 32*1024 instead

The result is the same :D

> 
> 
>>#undef PCI_VGA_RAM_IMAGE_START
>>#define PCI_VGA_RAM_IMAGE_START image
>>			/* THIS IS THE END OF THE CHANGES */
> 
> 





From rminnich at lanl.gov  Thu Apr 27 18:45:52 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 10:45:52 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44510236.8000803@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FC1E3.50802@suehsi.de>	
	<444FC6A7.4080002@suehsi.de>		<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>		<4450877E.3000501@suehsi.de>
	<44508AE0.4080805@suehsi.de>		<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	
	<4450B78F.4080101@suehsi.de>	<4450C6B9.50406@lanl.gov>	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
	<4450E0DC.70900@lanl.gov> <44510236.8000803@suehsi.de>
Message-ID: <4450F540.3000307@lanl.gov>

Christian S?hs wrote:
> 
>>
>> I think it's caching. optimization should not be a 100x slowdown, in 
>> this case.
>>
>> Let's try this if that's ok.
>>
>> ron
>>
> 
> Sorry, but that doesn't work :(


I'll dig a little deeper. Best guess is the emulator is still using 
physical c0000.

Sorry, will have to check it out tonight.

There goes my movie :-)

ron



From rminnich at lanl.gov  Thu Apr 27 18:46:59 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 10:46:59 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44510465.7030500@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FC1E3.50802@suehsi.de>	
	<444FC6A7.4080002@suehsi.de>		<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>		<4450877E.3000501@suehsi.de>
	<44508AE0.4080805@suehsi.de>		<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	
	<4450B78F.4080101@suehsi.de>	<4450C6B9.50406@lanl.gov>	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
	<4450E0DC.70900@lanl.gov> <44510465.7030500@suehsi.de>
Message-ID: <4450F583.9040901@lanl.gov>

Christian S?hs wrote:
> 
>>             /* THIS IS A TEST */
>>         static char image[64*1024];
> 
> 
> should I use 32*1024 instead

no, that should make no difference.


Thanks, again, for all your efforts on this.

I'll keep looking too.

I will be digging into this code soon for OLPC.

ron



From rminnich at lanl.gov  Thu Apr 27 18:47:39 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 10:47:39 -0600
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <4450EC04.2070606@zyxod.com>
References: <444E5BD7.2080007@zyxod.com>	<444E6DFF.4090208@lanl.gov>		<444F9984.6040207@zyxod.com>		<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>		<44503AEE.4050900@zyxod.com>	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>	<445054BB.8020706@zyxod.com>
	<4450C585.5060800@lanl.gov> <4450EC04.2070606@zyxod.com>
Message-ID: <4450F5AB.8060905@lanl.gov>

Eric Poulsen wrote:
> I should have been more clear: I ran memtest86+ using the Factory BIOS 
> and Grub

you need to run it under LB.
thanks
ron



From rminnich at lanl.gov  Thu Apr 27 18:48:34 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 10:48:34 -0600
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <445102B7.6000908@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	<4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov> <4450E9F0.1000904@suehsi.de>
	<4450DEB9.6030608@lanl.gov> <445102B7.6000908@suehsi.de>
Message-ID: <4450F5E2.1070502@lanl.gov>

Christian S?hs wrote:
> 
>>>
>>>
>>>
>>> Good question, I don't know. I hope you has some answers :D
>>
>>
>>
>> First, obvious possible issue is that C segment is not cached.
> 
> 
> Well, at the moment c0000 - cffff are not cached, they are only r/w and 
> pci accessable


Please make them cached.

thanks

ron



From chris at suehsi.de  Thu Apr 27 20:28:04 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 20:28:04 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450F5E2.1070502@lanl.gov>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	<4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov> <4450E9F0.1000904@suehsi.de>
	<4450DEB9.6030608@lanl.gov> <445102B7.6000908@suehsi.de>
	<4450F5E2.1070502@lanl.gov>
Message-ID: <44510D34.9050802@suehsi.de>


>> Well, at the moment c0000 - cffff are not cached, they are only r/w 
>> and pci accessable
> 
>

I have tried that, without success :(


> 
> Please make them cached.
> 
> thanks
> 
> ron
> 




From chris at suehsi.de  Thu Apr 27 20:53:38 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 20:53:38 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604270934l1683032es94e0c352c44212f9@mail.gmail.com>
References: <20060426152211.GA13826@coresystems.de>	
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>	
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de>	 <4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov>	
	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>	
	<445103B1.805@suehsi.de>
	<8a0c36780604270934l1683032es94e0c352c44212f9@mail.gmail.com>
Message-ID: <44511332.6060508@suehsi.de>


> Can yo post up a summary of what things work and what things don't. 
> Both usemode and in-tree.
>

I can try that.

testbios:
VGA comes up after 6 seconds.
minimal Debug says, that there are 3

run_bios_int calls

after the first call screen goes from standby to on
after the second call flickering
after the third of them VGA is initialized.

LB:
nearly the same, but it tooks ca. 80-90 seconds to initialize the vga
in this time there are also 3 int calls
with the same results as above
after the third of them VGA is initialized

------------------------------------------

debugging.

LB:
first way
enable DEBUG in debug.h
enable XEMU_trace_on() in biosemu.c

after a while the system seems to hang. There is no more debug output. 
The screen don't change their state from standby to on.
Could be before the first call is done.

second way
enables all debug lines in biosemu.c
the same as before. it seems after the same time the system hangs.

the timing is relative.
means, the real emulatur debug output does write more lines for the same 
debug output as the printk debugs from biosemu.c so it tooks more time

it seems, that the system stops at the same place, but I'm not sure.


If you wish I can post the necessary cap files again.

chris



> --
> Richard A. Smith
> 




From rminnich at lanl.gov  Thu Apr 27 19:30:33 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 11:30:33 -0600
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <44510D34.9050802@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	<4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov> <4450E9F0.1000904@suehsi.de>
	<4450DEB9.6030608@lanl.gov> <445102B7.6000908@suehsi.de>
	<4450F5E2.1070502@lanl.gov> <44510D34.9050802@suehsi.de>
Message-ID: <4450FFB9.3030003@lanl.gov>


well, this chipset is doing something very weird.

I will try to push on the 'don't use physical c0000 in the emulator' 
side of this.

ron



From stuge-linuxbios at cdy.org  Thu Apr 27 19:48:25 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 27 Apr 2006 19:48:25 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4450F540.3000307@lanl.gov>
References: <4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de> <4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov>
	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>
	<4450E0DC.70900@lanl.gov> <44510236.8000803@suehsi.de>
	<4450F540.3000307@lanl.gov>
Message-ID: <20060427174825.11206.qmail@cdy.org>

On Thu, Apr 27, 2006 at 10:45:52AM -0600, Ronald G Minnich wrote:
> I'll dig a little deeper. Best guess is the emulator is still using
> physical c0000.

You could try enabling caching in the Geode control register.

Instead of 0x33333333 try 0x77777777 for BC_XMAP_2.

The right solution is clearly to make x86emu use other RAM though.


//Peter



From eric at zyxod.com  Thu Apr 27 19:42:41 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 27 Apr 2006 10:42:41 -0700
Subject: [LinuxBIOS] Spradic linking errors
Message-ID: <44510291.2030204@zyxod.com>

I'm getting these errors sporadically when compiling.  I am doing 'make 
clean,' but it doesn't help.  At one point, I changed the config and 
re-ran buildtarget, then changed the config back and re-built, and it 
seem to clear it up.  Anyone have any idea on what's causing this?

86/16bit/entry16.lds 
/usr/src/LinuxBIOSv2.ml/src//cpu/x86/32bit/entry32.lds 
/usr/src/LinuxBIOSv2.ml/src//cpu/x86/16bit/reset16.lds 
/usr/src/LinuxBIOSv2.ml/src//arch/i386/lib/id.lds 
/usr/src/LinuxBIOSv2.ml/src//arch/i386/lib/failover.lds ; do echo /\* 
$file \*/ >> ldscript.ld; cat $file >> ldscript.ld ; done
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
/usr/bin/ld: section .reset [00000000fffffff0 -> 00000000ffffffff] 
overlaps section .rom [00000000ffffb646 -> 0000000100001b1f]
/usr/bin/ld: section .id [00000000ffffffd8 -> 00000000ffffffef] overlaps 
section .rom [00000000ffffb646 -> 0000000100001b1f]
/usr/bin/ld: linuxbios: section .data lma 0xffffb648 overlaps previous 
sections
crt0.o: In function `L1058':
crt0.S:(.rom.text+0xef): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1072':
crt0.S:(.rom.text+0x2b1): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1080':
crt0.S:(.rom.text+0x2f7): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1087':
crt0.S:(.rom.text+0x353): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1093':
crt0.S:(.rom.text+0x39f): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1099':
crt0.S:(.rom.text+0x3eb): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1105':
crt0.S:(.rom.text+0x437): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1111':
crt0.S:(.rom.text+0x483): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1117':
crt0.S:(.rom.text+0x4cf): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1123':
crt0.S:(.rom.text+0x51b): relocation truncated to fit: R_386_32 against 
`.rom.data'
crt0.o: In function `L1129':
crt0.S:(.rom.text+0x562): additional relocation overflows omitted from 
the output
collect2: ld returned 1 exit status




From eric at zyxod.com  Thu Apr 27 19:46:18 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 27 Apr 2006 10:46:18 -0700
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <4450F5AB.8060905@lanl.gov>
References: <444E5BD7.2080007@zyxod.com>	<444E6DFF.4090208@lanl.gov>		<444F9984.6040207@zyxod.com>		<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>		<44503AEE.4050900@zyxod.com>	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>	<445054BB.8020706@zyxod.com>
	<4450C585.5060800@lanl.gov> <4450EC04.2070606@zyxod.com>
	<4450F5AB.8060905@lanl.gov>
Message-ID: <4451036A.90103@zyxod.com>

Ron, re-read my original email.  I DID run it (memtest86+) under both LB 
and Factory BIOS.  I get several thousand of errors (under LB) because 
memtest86 is trying to check the shadow area from C000 to EFEFC.  I 
suspect the "MemMap" (whatever that is) is wrong.  Makes the ram testing 
a bit difficult, because "real" errors are lost in the noise.

Factory BIOS:
Ran memtest86+ for four hours -- no errors.

Walltime Cached  RsvdMem MemMap    Cache ECC Test
          224M       76K e820-std  on    off std

_LinuxBIOS_ + filo
Errors from C0000 to EFEFC
Walltime Cached  RsvdMem MemMap    Cache ECC Test
          224M        0  LinuxBIOS on    off std



Ronald G Minnich wrote:
> Eric Poulsen wrote:
>> I should have been more clear: I ran memtest86+ using the Factory 
>> BIOS and Grub
>
> you need to run it under LB.
> thanks
> ron
>




From chris at suehsi.de  Thu Apr 27 21:11:01 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 21:11:01 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060427174825.11206.qmail@cdy.org>
References: <4450877E.3000501@suehsi.de>
	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>
	<4450B78F.4080101@suehsi.de>	<4450C6B9.50406@lanl.gov>	<8a0c36780604270807r13249466t6de29603544e67af@mail.gmail.com>	<4450E0DC.70900@lanl.gov>
	<44510236.8000803@suehsi.de>	<4450F540.3000307@lanl.gov>
	<20060427174825.11206.qmail@cdy.org>
Message-ID: <44511745.8040002@suehsi.de>


> 
> You could try enabling caching in the Geode control register.
> 
> Instead of 0x33333333 try 0x77777777 for BC_XMAP_2.
>

I have set it to 0xFFFFFFFF

but I can give it a chance :D

> The right solution is clearly to make x86emu use other RAM though.
> 
> 
> //Peter
> 




From chris at suehsi.de  Thu Apr 27 21:35:02 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 21:35:02 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450FFB9.3030003@lanl.gov>
References: <20060426152211.GA13826@coresystems.de>	<444FA357.7000907@suehsi.de>	<8a0c36780604260942i33e5dc22h4641e15cc5318596@mail.gmail.com>	<20060426165244.GA26131@coresystems.de>	<444FBB2B.6030701@suehsi.de>	<444FC1E3.50802@suehsi.de>	<444FC6A7.4080002@suehsi.de>	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>	<4450877E.3000501@suehsi.de>	<44508AE0.4080805@suehsi.de>	<20060427090909.GC22299@coresystems.de>	<4450ADCC.3020102@suehsi.de>	<4450B78F.4080101@suehsi.de>	<4450C6B9.50406@lanl.gov>
	<4450E9F0.1000904@suehsi.de>	<4450DEB9.6030608@lanl.gov>
	<445102B7.6000908@suehsi.de>	<4450F5E2.1070502@lanl.gov>
	<44510D34.9050802@suehsi.de> <4450FFB9.3030003@lanl.gov>
Message-ID: <44511CE6.3080507@suehsi.de>

Ronald G Minnich schrieb:
> well, this chipset is doing something very weird.
> 
> I will try to push on the 'don't use physical c0000 in the emulator' 
> side of this.
> 
> ron
> 
OK, and than it runs, but we do know nothing about the reasons :D

Well, remember.
There are two other problems for me, which I could not explain.

It seems there is a bottleneck and I think the reason therefor are not 
proper settings for the CPU.

BC_XMAP_1 is set to 0x60

a look to the datasheets says that therefore are not much things 
enabled. I guess there is a whole piece of memory not writeable, more 
not useable.

ok first.

after filo has load the kernel and the initrd, there is a jump and the 
kernel is uncompressing. I'm not sure, but one of them needs more time 
as it should, also I think this is done somewhere in the memory.

second
my system boots readonly, but I don't know why
means VFS: booting bla,bla readonly

For me the whole stuff is running out of the ram
It could be that unuseable memory segments are needed for that.

chris



From smithbone at gmail.com  Thu Apr 27 20:25:26 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 13:25:26 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44511CE6.3080507@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>
	<4450B78F.4080101@suehsi.de> <4450C6B9.50406@lanl.gov>
	<4450E9F0.1000904@suehsi.de> <4450DEB9.6030608@lanl.gov>
	<445102B7.6000908@suehsi.de> <4450F5E2.1070502@lanl.gov>
	<44510D34.9050802@suehsi.de> <4450FFB9.3030003@lanl.gov>
	<44511CE6.3080507@suehsi.de>
Message-ID: <8a0c36780604271125u4bd83c67xab33e0f0a82cd74c@mail.gmail.com>

>
> For me the whole stuff is running out of the ram
> It could be that unuseable memory segments are needed for that.
>

Run memtest as a payload and see where it errors.

Also you need to rip the BC_XMAP_* settings while booted under the factory bios.

--
Richard A. Smith



From rminnich at lanl.gov  Thu Apr 27 20:41:16 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 12:41:16 -0600
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <4451036A.90103@zyxod.com>
References: <444E5BD7.2080007@zyxod.com>	<444E6DFF.4090208@lanl.gov>		<444F9984.6040207@zyxod.com>		<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>		<44503AEE.4050900@zyxod.com>	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>	<445054BB.8020706@zyxod.com>
	<4450C585.5060800@lanl.gov> <4450EC04.2070606@zyxod.com>
	<4450F5AB.8060905@lanl.gov> <4451036A.90103@zyxod.com>
Message-ID: <4451104C.9020406@lanl.gov>

Eric Poulsen wrote:
> Ron, re-read my original email.  I DID run it (memtest86+) under both LB 
> and Factory BIOS.  I get several thousand of errors (under LB) because 
> memtest86 is trying to check the shadow area from C000 to EFEFC.  I 
> suspect the "MemMap" (whatever that is) is wrong.  Makes the ram testing 
> a bit difficult, because "real" errors are lost in the noise.

sorry. But you can build memtest to only check the 1M+ area .. that's 
how I do it. misread your mail.

ron



From steven.goodrich at amd.com  Thu Apr 27 20:49:22 2006
From: steven.goodrich at amd.com (Goodrich,Steven)
Date: Thu, 27 Apr 2006 13:49:22 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
Message-ID: <0E81348C5627674A9C0061413EBFF5F74F4391@SAUSEXMB2.amd.com>

Sorry, I've not been following this thread.  It's a Geode?  Could I get some info, like what CPU and what Southbridge?

    -- Steve G. 

Steve Goodrich (Steven.Goodrich at amd.com)
Advanced Micro Devices, Inc.

-----Original Message-----
From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Christian S?hs
Sent: Thursday, April 27, 2006 1:11 PM
To: Peter Stuge
Cc: LinuxBIOS
Subject: Re: [LinuxBIOS] MB1030 / 3036 VGA comes up :D


> 
> You could try enabling caching in the Geode control register.
> 
> Instead of 0x33333333 try 0x77777777 for BC_XMAP_2.
>

I have set it to 0xFFFFFFFF

but I can give it a chance :D

> The right solution is clearly to make x86emu use other RAM though.
> 
> 
> //Peter
> 


--
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From smithbone at gmail.com  Thu Apr 27 21:12:08 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 14:12:08 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4391@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4391@SAUSEXMB2.amd.com>
Message-ID: <8a0c36780604271212o1a8f1282u6bf4b7241f192ffb@mail.gmail.com>

On 4/27/06, Goodrich,Steven <steven.goodrich at amd.com> wrote:

> Sorry, I've not been following this thread.  It's a Geode?  Could I get some info, like what >CPU and what Southbridge?

Woohoo in come the big guns.

He's using the eaglelion/5cbm Config.lb.  But the board is a bit different.
Somewhere in all the threads (4 so far) is an lspci but this is what I
dug up in my quick scan of the start of the thread(s).

Cyrix Media GXM CPU up to 300MHz.

NSC CS5530 or Cyrix CX5530 Southbridge
NSC SuperIO PC97137
Cyberpro 500x Video Chipset

Lan (sometimes on board) realtek 8139
DOC Support
PC104 Connector
Sound on board


--
Richard A. Smith



From smithbone at gmail.com  Thu Apr 27 21:22:33 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 14:22:33 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4391@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4391@SAUSEXMB2.amd.com>
Message-ID: <8a0c36780604271222r155d7b4ek149de822d9dd0954@mail.gmail.com>

On 4/27/06, Goodrich,Steven <steven.goodrich at amd.com> wrote:

> Sorry, I've not been following this thread.  It's a Geode?  Could I get some info, like what CPU and what Southbridge?

I found an lspci. One thing we have noticed is that under the factory
bios the 5530 video controller does _not_ show up in the lspci but it
does under LB.  So there are some magic bits somewhere that disable
that device.

lspci -vv //complete output boot with factory bios
// there is no PCI 12.4
// first LB tries without CONFIG_PCI_ROM_RUN and CONFIG_CONSOLE_VGA
looks nearly same
// only 00:09.0 looks different, of course.

00:00.0 0600: 1078:0001
       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
       Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
       Latency: 0

00:09.0 0300: 10ea:5000 (rev 02)
       Subsystem: 0280:7000
       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
       Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
       Latency: 32, Cache Line Size 08
       Interrupt: pin A routed to IRQ 10
       Region 0: Memory at d0000000 (32-bit, non-prefetchable) [size=16M]
       Expansion ROM at <unassigned> [disabled] [size=64K]

00:12.0 0601: 1078:0100
       Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
       Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
       Latency: 64, Cache Line Size 04

00:12.1 0680: 1078:0101
       Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
       Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
       Region 0: Memory at 40012000 (32-bit, non-prefetchable) [size=256]

00:12.2 0101: 1078:0102 (prog-if 80)
       Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
       Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
       Latency: 0
       Region 4: I/O ports at f000 [size=16]

00:12.3 0401: 1078:0103
       Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
       Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
       Latency: 0
       Region 0: Memory at 40011000 (32-bit, non-prefetchable) [size=128]

00:13.0 0c03: 0e11:a0f8 (rev 06) (prog-if 10)
       Subsystem: 0e11:a0f8
       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
       Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
       Latency: 32 (20000ns max), Cache Line Size 08
       Interrupt: pin A routed to IRQ 11
       Region 0: Memory at d2003000 (32-bit, non-prefetchable) [size=4K]



--
Richard A. Smith



From chris at suehsi.de  Thu Apr 27 23:41:21 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 23:41:21 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604271212o1a8f1282u6bf4b7241f192ffb@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4391@SAUSEXMB2.amd.com>
	<8a0c36780604271212o1a8f1282u6bf4b7241f192ffb@mail.gmail.com>
Message-ID: <44513A81.3090301@suehsi.de>


> 
> Cyrix Media GXM CPU up to 300MHz.
>

For me, it is a National Geode gx1 200MHZ and cs5530
but it should be nearly the same ;)
National build that stuff :D

There are other revisions with Cyrix Processors, Cyrix Southbridge and a 
older cyberpro grafik (2010 I think) called stb1030

the SuperIO is the same

> NSC CS5530 or Cyrix CX5530 Southbridge
> NSC SuperIO PC97137
> Cyberpro 500x Video Chipset
> 
> Lan (sometimes on board) realtek 8139
> DOC Support
> PC104 Connector
> Sound on board
> 
> 
> --
> Richard A. Smith
> 




From chris at suehsi.de  Thu Apr 27 23:44:51 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 27 Apr 2006 23:44:51 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604271125u4bd83c67xab33e0f0a82cd74c@mail.gmail.com>
References: <20060426152211.GA13826@coresystems.de>	<4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov>	<4450E9F0.1000904@suehsi.de>
	<4450DEB9.6030608@lanl.gov>	<445102B7.6000908@suehsi.de>
	<4450F5E2.1070502@lanl.gov>	<44510D34.9050802@suehsi.de>
	<4450FFB9.3030003@lanl.gov>	<44511CE6.3080507@suehsi.de>
	<8a0c36780604271125u4bd83c67xab33e0f0a82cd74c@mail.gmail.com>
Message-ID: <44513B53.6000503@suehsi.de>


> 
> Run memtest as a payload and see where it errors.
> 
> Also you need to rip the BC_XMAP_* settings while booted under the factory bios.
> 

Fine ;) How can I get them.

> --
> Richard A. Smith
> 




From smithbone at gmail.com  Thu Apr 27 23:00:28 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 16:00:28 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44513B53.6000503@suehsi.de>
References: <20060426152211.GA13826@coresystems.de>
	<4450E9F0.1000904@suehsi.de> <4450DEB9.6030608@lanl.gov>
	<445102B7.6000908@suehsi.de> <4450F5E2.1070502@lanl.gov>
	<44510D34.9050802@suehsi.de> <4450FFB9.3030003@lanl.gov>
	<44511CE6.3080507@suehsi.de>
	<8a0c36780604271125u4bd83c67xab33e0f0a82cd74c@mail.gmail.com>
	<44513B53.6000503@suehsi.de>
Message-ID: <8a0c36780604271400t30f840fh55d8f45d2f31b4e0@mail.gmail.com>

On 4/27/06, Christian S?hs <chris at suehsi.de> wrote:
>
> >
> > Run memtest as a payload and see where it errors.
> >
> > Also you need to rip the BC_XMAP_* settings while booted under the factory bios.
> >
>
> Fine ;) How can I get them.

Do you have an account here?

http://wwwd.amd.com/AMD/developer.nsf/

There are tools there for DOS and linux that can read various things. 
Its not obvious to me if the XMAP registers are in the list of thingsn
they can read.

If not then you will have to study the LinuxBIOS source and the gx1
datasheet to figure out how to write a small program that can read
them.

--
Richard A. Smith



From stepan at coresystems.de  Thu Apr 27 23:46:54 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 27 Apr 2006 23:46:54 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <4450DEB9.6030608@lanl.gov>
References: <444FC6A7.4080002@suehsi.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de> <4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov> <4450E9F0.1000904@suehsi.de>
	<4450DEB9.6030608@lanl.gov>
Message-ID: <20060427214653.GC19370@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060427 17:09]:
> First, obvious possible issue is that C segment is not cached.
> 
> But I want to KILL that use of C segment. I'm going to ask Ollie about 
> this today.

I would imagine this is due to the way the x86 emulator works. It
expects a memory region from 0x00000 to 0xfffff. In this region the
graphics rom has to sit at 0xc0000 for compatibility issues.
graphics roms are "allowed" to assume they live at 0xc0000.

So we should not change this but instead get caching and c,d,e-seg
writing work correctly and maybe in a standard way/at a standard
position in LinuxBIOS.

This would also allow us to incorporate ADLO or other stuff that allows
booting more OSes.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From steven.goodrich at amd.com  Thu Apr 27 23:47:01 2006
From: steven.goodrich at amd.com (Goodrich,Steven)
Date: Thu, 27 Apr 2006 16:47:01 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
Message-ID: <0E81348C5627674A9C0061413EBFF5F74F4407@SAUSEXMB2.amd.com>

We have an older board (from before I came to be with AMD) which was built with a GXm, CS5530, and NSC 97317 SIO.   I can pull preferred register settings from a document if that would help.  

Our preferred settings for this platform were:

BC_XMAP_1 = 0x1300C060
BC_XMAP_2 = 0x09999999
BC_XMAP_3 = 0x99****99 (* = don't care)

Are you loading an SMM handler on this platform?

    -- Steve G. 

Steve Goodrich (Steven.Goodrich at amd.com)
Advanced Micro Devices, Inc.

-----Original Message-----
From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Richard Smith
Sent: Thursday, April 27, 2006 3:00 PM
To: Christian S?hs
Cc: Stefan Reinauer; LinuxBIOS
Subject: Re: [LinuxBIOS] MB1030 / 3036 VGA comes up :D

On 4/27/06, Christian S?hs <chris at suehsi.de> wrote:
>
> >
> > Run memtest as a payload and see where it errors.
> >
> > Also you need to rip the BC_XMAP_* settings while booted under the factory bios.
> >
>
> Fine ;) How can I get them.

Do you have an account here?

http://wwwd.amd.com/AMD/developer.nsf/

There are tools there for DOS and linux that can read various things. 
Its not obvious to me if the XMAP registers are in the list of thingsn they can read.

If not then you will have to study the LinuxBIOS source and the gx1 datasheet to figure out how to write a small program that can read them.

--
Richard A. Smith

--
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From stepan at coresystems.de  Thu Apr 27 23:48:25 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 27 Apr 2006 23:48:25 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <44510D34.9050802@suehsi.de>
References: <44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de> <4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov> <4450E9F0.1000904@suehsi.de>
	<4450DEB9.6030608@lanl.gov> <445102B7.6000908@suehsi.de>
	<4450F5E2.1070502@lanl.gov> <44510D34.9050802@suehsi.de>
Message-ID: <20060427214824.GD19370@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060427 20:28]:
> 
> >>Well, at the moment c0000 - cffff are not cached, they are only r/w 
> >>and pci accessable
> >
> >
> 
> I have tried that, without success :(

What does "without success" mean? It wasn't cached? Or it wasnt
writable? Or something else went wrong? Or the behavior was the same as
before?

S.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Fri Apr 28 00:00:24 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 28 Apr 2006 00:00:24 +0200
Subject: [LinuxBIOS] Spradic linking errors
In-Reply-To: <44510291.2030204@zyxod.com>
References: <44510291.2030204@zyxod.com>
Message-ID: <20060427220024.GE19370@coresystems.de>

* Eric Poulsen <eric at zyxod.com> [060427 19:42]:
> I'm getting these errors sporadically when compiling.  I am doing 'make 
> clean,' but it doesn't help.  At one point, I changed the config and 
> re-ran buildtarget, then changed the config back and re-built, and it 
> seem to clear it up.  Anyone have any idea on what's causing this?

[..]

increase ROM_IMAGE_SIZE in your target Config.lb file.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Fri Apr 28 00:01:48 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 28 Apr 2006 00:01:48 +0200
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <4451104C.9020406@lanl.gov>
References: <444F9984.6040207@zyxod.com>
	<8a0c36780604260949u4ae3740dl3f6807db8e8a3749@mail.gmail.com>
	<44503AEE.4050900@zyxod.com>
	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>
	<445054BB.8020706@zyxod.com> <4450C585.5060800@lanl.gov>
	<4450EC04.2070606@zyxod.com> <4450F5AB.8060905@lanl.gov>
	<4451036A.90103@zyxod.com> <4451104C.9020406@lanl.gov>
Message-ID: <20060427220147.GF19370@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060427 20:41]:
> sorry. But you can build memtest to only check the 1M+ area .. that's 
> how I do it. misread your mail.

question is why is this not needed with legacy bios? Can we emulate
their behavior easily?

S.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Fri Apr 28 00:07:26 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 28 Apr 2006 00:07:26 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4407@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4407@SAUSEXMB2.amd.com>
Message-ID: <20060427220726.GB24216@coresystems.de>

* Goodrich,Steven <steven.goodrich at amd.com> [060427 23:47]:
> Are you loading an SMM handler on this platform?

We don't do any SMM stuff (yet). Is there any good reason to do so?
Except the very nice Debugger available as SMI code from AMD's website?

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Fri Apr 28 00:10:45 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 17:10:45 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4407@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4407@SAUSEXMB2.amd.com>
Message-ID: <8a0c36780604271510j6c2da6deudb514bd0bfa049b9@mail.gmail.com>

On 4/27/06, Goodrich,Steven <steven.goodrich at amd.com> wrote:
> We have an older board (from before I came to be with AMD) which was built with a GXm, CS5530, and NSC 97317 SIO.   I can pull preferred register settings from a document if that would help.

Yes those would probally help..

> Our preferred settings for this platform were:
>
> BC_XMAP_1 = 0x1300C060
> BC_XMAP_2 = 0x09999999
> BC_XMAP_3 = 0x99****99 (* = don't care)

Or perhpaps just confuse things more.  9's in XMAP2 is PCI accessable,
No Cache, No Write, Read.

I'm not sure how you would load the shadow copy of the bios into this
range with write disabled .  Until we started setting the write bit
for these ranges the emulator was getting all 0xFFs for its data.

> Are you loading an SMM handler on this platform?

Dosen't look like it.  Is that a big problem?  I know for the gx2 it's
a big issue since it dosen't have PCI config space without it.  But
this part seems to have PCI config method #1 without SMM.

--
Richard A. Smith



From smithbone at gmail.com  Fri Apr 28 00:18:31 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 27 Apr 2006 17:18:31 -0500
Subject: [LinuxBIOS] Kernel crash output: Memtest86+ output
In-Reply-To: <20060427220147.GF19370@coresystems.de>
References: <444F9984.6040207@zyxod.com> <44503AEE.4050900@zyxod.com>
	<8a0c36780604262128i20c5aab1n288b501cc7f06ebd@mail.gmail.com>
	<445054BB.8020706@zyxod.com> <4450C585.5060800@lanl.gov>
	<4450EC04.2070606@zyxod.com> <4450F5AB.8060905@lanl.gov>
	<4451036A.90103@zyxod.com> <4451104C.9020406@lanl.gov>
	<20060427220147.GF19370@coresystems.de>
Message-ID: <8a0c36780604271518n135168cdq3a5b2270f219136d@mail.gmail.com>

>
> question is why is this not needed with legacy bios? Can we emulate
> their behavior easily?

I think its already there.  Notice what Reserved memeory map it used
for factory.

       224M       76K e820-std  on    off std

the e820 map.

And for LB

          224M        0  LinuxBIOS on    off std

The LinuxBIOS map.  So you may not have your LB reserved memory map
setup.  I can't help you much on setting that up since I wasn't even
aware we had a reserved memory map but memtest had to get that from
somewhere.

--
Richard A. Smith



From rminnich at lanl.gov  Fri Apr 28 00:11:27 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 27 Apr 2006 16:11:27 -0600
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <20060427214653.GC19370@coresystems.de>
References: <444FC6A7.4080002@suehsi.de>
	<8a0c36780604261235y52d357dfmc5fb81be9e1636b0@mail.gmail.com>
	<4450877E.3000501@suehsi.de> <44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de> <4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov> <4450E9F0.1000904@suehsi.de>
	<4450DEB9.6030608@lanl.gov> <20060427214653.GC19370@coresystems.de>
Message-ID: <4451418F.3000005@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060427 17:09]:
> 
>>First, obvious possible issue is that C segment is not cached.
>>
>>But I want to KILL that use of C segment. I'm going to ask Ollie about 
>>this today.
> 
> 
> I would imagine this is due to the way the x86 emulator works. It
> expects a memory region from 0x00000 to 0xfffff. In this region the
> graphics rom has to sit at 0xc0000 for compatibility issues.
> graphics roms are "allowed" to assume they live at 0xc0000.

stefan, it's emulated memory at 0xf0000. We can just as easily emulate 
the memory at c0000. It's an emulator, we can do anything we want.

Then we don't have to fight this caching nonsense on every new machine.

ron



From steven.goodrich at amd.com  Fri Apr 28 01:06:39 2006
From: steven.goodrich at amd.com (Goodrich,Steven)
Date: Thu, 27 Apr 2006 18:06:39 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
Message-ID: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>

 
Hmm... Let me back up a step.  I'm apparently answering a question
you're not asking.  Your problem is that you want to disable the
internal video (and PCI header) and use external, right?  Is that it?

    -- Steve G. 

Steve Goodrich (Steven.Goodrich at amd.com)
Advanced Micro Devices, Inc.

-----Original Message-----
From: Richard Smith [mailto:smithbone at gmail.com] 
Sent: Thursday, April 27, 2006 4:11 PM
To: Goodrich,Steven
Cc: LinuxBIOS
Subject: Re: [LinuxBIOS] MB1030 / 3036 VGA comes up :D

On 4/27/06, Goodrich,Steven <steven.goodrich at amd.com> wrote:
> We have an older board (from before I came to be with AMD) which was
built with a GXm, CS5530, and NSC 97317 SIO.   I can pull preferred
register settings from a document if that would help.

Yes those would probally help..

> Our preferred settings for this platform were:
>
> BC_XMAP_1 = 0x1300C060
> BC_XMAP_2 = 0x09999999
> BC_XMAP_3 = 0x99****99 (* = don't care)

Or perhpaps just confuse things more.  9's in XMAP2 is PCI accessable,
No Cache, No Write, Read.

I'm not sure how you would load the shadow copy of the bios into this
range with write disabled .  Until we started setting the write bit for
these ranges the emulator was getting all 0xFFs for its data.

> Are you loading an SMM handler on this platform?

Dosen't look like it.  Is that a big problem?  I know for the gx2 it's a
big issue since it dosen't have PCI config space without it.  But this
part seems to have PCI config method #1 without SMM.

--
Richard A. Smith





From steven.goodrich at amd.com  Fri Apr 28 01:07:04 2006
From: steven.goodrich at amd.com (Goodrich,Steven)
Date: Thu, 27 Apr 2006 18:07:04 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
Message-ID: <0E81348C5627674A9C0061413EBFF5F74F4443@SAUSEXMB2.amd.com>

No... Just trying to figure out what you've got on the system.

    -- Steve G. 

Steve Goodrich (Steven.Goodrich at amd.com)
Advanced Micro Devices, Inc.

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at coresystems.de] 
Sent: Thursday, April 27, 2006 4:07 PM
To: Goodrich,Steven
Cc: LinuxBIOS
Subject: Re: [LinuxBIOS] MB1030 / 3036 VGA comes up :D

* Goodrich,Steven <steven.goodrich at amd.com> [060427 23:47]:
> Are you loading an SMM handler on this platform?

We don't do any SMM stuff (yet). Is there any good reason to do so?
Except the very nice Debugger available as SMI code from AMD's website?

Stefan

--
coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 * Fax: +49 761 7664613
Email: info at coresystems.de  * http://www.coresystems.de/





From chris at suehsi.de  Fri Apr 28 11:27:11 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 28 Apr 2006 11:27:11 +0200
Subject: [LinuxBIOS] MB1030 / 3036  VGA comes up :D
In-Reply-To: <20060427214824.GD19370@coresystems.de>
References: <44508AE0.4080805@suehsi.de>
	<20060427090909.GC22299@coresystems.de>
	<4450ADCC.3020102@suehsi.de> <4450B78F.4080101@suehsi.de>
	<4450C6B9.50406@lanl.gov> <4450E9F0.1000904@suehsi.de>
	<4450DEB9.6030608@lanl.gov> <445102B7.6000908@suehsi.de>
	<4450F5E2.1070502@lanl.gov> <44510D34.9050802@suehsi.de>
	<20060427214824.GD19370@coresystems.de>
Message-ID: <4451DFEF.70907@suehsi.de>

Stefan Reinauer schrieb:
> * Christian S?hs <chris at suehsi.de> [060427 20:28]:
> 
>>>>Well, at the moment c0000 - cffff are not cached, they are only r/w 
>>>>and pci accessable
>>>
>>>
>>I have tried that, without success :(
> 
> 
> What does "without success" mean? It wasn't cached? Or it wasnt
> writable? Or something else went wrong? Or the behavior was the same as
> before?
> 

Behaviour was the same as before.

chris

> S.
> 





From chris at suehsi.de  Fri Apr 28 11:51:43 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 28 Apr 2006 11:51:43 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
Message-ID: <4451E5AF.1070304@suehsi.de>

Goodrich,Steven schrieb:
>  
> Hmm... Let me back up a step.  I'm apparently answering a question
> you're not asking.  Your problem is that you want to disable the
> internal video (and PCI header) and use external, right?  Is that it?

Yes, but
Not really external, the "onboard" Cyberpro 5000 graphic chipset looks 
like a integrated pci card with own memory. I guess external is the 
right word for that :D

Under factory bios, the device 00:12.4 is not shown with lspci.
We know, that it is possible to disable the special graphic instructions 
for the Geode CPU, but I think 00:12.4 is the integrated graphic stuff 
at the southbridge cs5530.
So, is it automaticaly disabled, when the Geode Graphic stuff is 
disabled or is there a magic bit for the cs5530 itself?

However, it would be fine to totally disable device 00:12.4

Our current main problem is the slow coming up "external" vga device.
It takes around 90 seconds to initialize this device under LB with the 
emulator.


>>Our preferred settings for this platform were:
>>
>>BC_XMAP_1 = 0x1300C060

That could help, currently is it set to 0x60

>>BC_XMAP_2 = 0x09999999
>>BC_XMAP_3 = 0x99****99 (* = don't care)
> 
> 
> Or perhpaps just confuse things more.  9's in XMAP2 is PCI accessable,
> No Cache, No Write, Read.
> 

What about CPU revisions, could it be that this registers have changed 
in the time? I guess, I use an older datassheet.

chris



From stepan at coresystems.de  Fri Apr 28 10:41:54 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 28 Apr 2006 10:41:54 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
Message-ID: <20060428084154.GA26438@coresystems.de>

* Goodrich,Steven <steven.goodrich at amd.com> [060428 01:06]:
>  
> Hmm... Let me back up a step.  I'm apparently answering a question
> you're not asking.  Your problem is that you want to disable the
> internal video (and PCI header) and use external, right?  Is that it?

The second problem we are facing is when initializing VGA we are executing 
the option roms in an emulator to keep things encapsulated. When we do
this in userspace, the whole process takes round about 3s whereas in
LinuxBIOS the same emulator (x86emu as used in X.org) needs 90s.

Two theories:
 - caching of the C segment is messed up
 - timing is messed up

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Fri Apr 28 18:40:37 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 28 Apr 2006 18:40:37 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060428084154.GA26438@coresystems.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
Message-ID: <44524585.5040902@suehsi.de>


> Two theories:
>  - caching of the C segment is messed up
>  - timing is messed up
>

Sorry, I'm not a bit guru. What is the result of that.

0x040000000>>30

bitwise rightshift

is it 0x04 ??

chris




From rminnich at lanl.gov  Fri Apr 28 17:20:23 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 28 Apr 2006 09:20:23 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44524585.5040902@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>
	<44524585.5040902@suehsi.de>
Message-ID: <445232B7.1070802@lanl.gov>

Christian S?hs wrote:
>>Two theories:
>> - caching of the C segment is messed up
>> - timing is messed up
>>
> 
> 
> Sorry, I'm not a bit guru. What is the result of that.
> 
> 0x040000000>>30
> 
> bitwise rightshift
> 
> is it 0x04 ??
> 
> chris
> 
> 

Get the aardvark, calculator, acalc. It makes this stuff really easy.

in acalc, you would do this:
x40000000
30
sr


and get 1.

ron



From smithbone at gmail.com  Fri Apr 28 17:49:32 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 28 Apr 2006 10:49:32 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060428084154.GA26438@coresystems.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
Message-ID: <8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>

> this in userspace, the whole process takes round about 3s whereas in
> LinuxBIOS the same emulator (x86emu as used in X.org) needs 90s.
>

This is actually something that I've wanted to look at but not had the
time.  The emulator in LB is from the same parent as X.org but its not
the same at all.  Our base revision is quite old.

Yes I know we fixed a lot bugs in our tree but the fact remains that I
can take the X.org setup in a multi-card, multi-head enviroment and it
will post the 2nd card in almost every card I've tried.  Our user
space emu has nowhere near that level of success.

I think an upstream sync or at least a diff with the current emu in
X.org would be a good idea.  I'ts been on my list of stuff to do.  But
time, money.. yada yada.

--
Richard A. Smith



From chris at suehsi.de  Fri Apr 28 19:16:04 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 28 Apr 2006 19:16:04 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <445232B7.1070802@lanl.gov>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>	<44524585.5040902@suehsi.de>
	<445232B7.1070802@lanl.gov>
Message-ID: <44524DD4.3040203@suehsi.de>


> 
> in acalc, you would do this:
> x40000000
> 30
> sr
>

Well, the graphic instructions for the geode are disabled in that case :D

because this value is writen to b8h (Graphic Control Registers)

However,
I'm not sure what I should do next.

I think i will play around with the BC_XMAP_1 registers and will set the 
amd prefered values :D

Currently the whole video RAM section seems to be disabled.
a0000 - bffff

chris

> 
> and get 1.
> 
> ron
> 




From smithbone at gmail.com  Fri Apr 28 18:10:40 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 28 Apr 2006 11:10:40 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44524DD4.3040203@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de> <44524585.5040902@suehsi.de>
	<445232B7.1070802@lanl.gov> <44524DD4.3040203@suehsi.de>
Message-ID: <8a0c36780604280910m5871f379uc386426448c40fed@mail.gmail.com>

On 4/28/06, Christian S?hs <chris at suehsi.de> wrote:

> I think i will play around with the BC_XMAP_1 registers and will set the
> amd prefered values :D
>
> Currently the whole video RAM section seems to be disabled.
> a0000 - bffff

Yeah but remember it all works from the userspace emu with the same settings.

--
Richard A. Smith



From steven.goodrich at amd.com  Fri Apr 28 18:17:41 2006
From: steven.goodrich at amd.com (Goodrich,Steven)
Date: Fri, 28 Apr 2006 11:17:41 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
Message-ID: <0E81348C5627674A9C0061413EBFF5F74F45AA@SAUSEXMB2.amd.com>

In our BIOS for the related platform, I don't see how we're disabling PCI.  I see that we set DC_FB_ST_OFFSET (GX_BASE + 0x8310) to 0 and also DC_DUR_ST_OFFSET (GX_BASE + 0x8318).

Is the 00:12:4 a PCI address?  Does that decode to Bus 0, Device 12 (decimal?), Function 4?

    -- Steve G. 

Steve Goodrich (Steven.Goodrich at amd.com)
Advanced Micro Devices, Inc.

-----Original Message-----
From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Christian S?hs
Sent: Friday, April 28, 2006 11:16 AM
To: Ronald G Minnich
Cc: Stefan Reinauer; Goodrich,Steven; LinuxBIOS
Subject: Re: [LinuxBIOS] MB1030 / 3036 VGA comes up :D


> 
> in acalc, you would do this:
> x40000000
> 30
> sr
>

Well, the graphic instructions for the geode are disabled in that case :D

because this value is writen to b8h (Graphic Control Registers)

However,
I'm not sure what I should do next.

I think i will play around with the BC_XMAP_1 registers and will set the amd prefered values :D

Currently the whole video RAM section seems to be disabled.
a0000 - bffff

chris

> 
> and get 1.
> 
> ron
> 


--
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From smithbone at gmail.com  Fri Apr 28 18:36:58 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 28 Apr 2006 11:36:58 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F45AA@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F45AA@SAUSEXMB2.amd.com>
Message-ID: <8a0c36780604280936x7667b97bu38038a4c93b82506@mail.gmail.com>

On 4/28/06, Goodrich,Steven <steven.goodrich at amd.com> wrote:

> In our BIOS for the related platform, I don't see how we're disabling PCI.  I see that we set DC_FB_ST_OFFSET (GX_BASE + 0x8310) to 0 and also DC_DUR_ST_OFFSET (GX_BASE + 0x8318).
>
> Is the 00:12:4 a PCI address?  Does that decode to Bus 0, Device 12 (decimal?), Function 4?

Yeah. Its the VGA device in the cs5530.

--
Richard A. Smith



From chris at suehsi.de  Fri Apr 28 20:00:27 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 28 Apr 2006 20:00:27 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F45AA@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F45AA@SAUSEXMB2.amd.com>
Message-ID: <4452583B.4000207@suehsi.de>

Goodrich,Steven schrieb:
> In our BIOS for the related platform, I don't see how we're disabling PCI.  I see that we set DC_FB_ST_OFFSET (GX_BASE + 0x8310) to 0 and also DC_DUR_ST_OFFSET (GX_BASE + 0x8318).
> 
> Is the 00:12:4 a PCI address?  Does that decode to Bus 0, Device 12 (decimal?), Function 4?
> 
>     -- Steve G. 
> 
Yes,

1078:0104 [VendorID:DeviceID] that is the integrated Video Controller 
from the CS5530.

It should be possible to disable this device completly.

But how?

chris



From chris at suehsi.de  Fri Apr 28 20:15:51 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 28 Apr 2006 20:15:51 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604280910m5871f379uc386426448c40fed@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>
	<44524585.5040902@suehsi.de>	<445232B7.1070802@lanl.gov>
	<44524DD4.3040203@suehsi.de>
	<8a0c36780604280910m5871f379uc386426448c40fed@mail.gmail.com>
Message-ID: <44525BD7.9010906@suehsi.de>


> 
> Yeah but remember it all works from the userspace emu with the same settings.
> 
> --
> Richard A. Smith
> 

Ok, I will wait for a better in tree emulator :D

chris



From smithbone at gmail.com  Fri Apr 28 19:10:17 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 28 Apr 2006 12:10:17 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44525BD7.9010906@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de> <44524585.5040902@suehsi.de>
	<445232B7.1070802@lanl.gov> <44524DD4.3040203@suehsi.de>
	<8a0c36780604280910m5871f379uc386426448c40fed@mail.gmail.com>
	<44525BD7.9010906@suehsi.de>
Message-ID: <8a0c36780604281010y3c154b50j75401bb76a418df0@mail.gmail.com>

On 4/28/06, Christian S?hs <chris at suehsi.de> wrote:
>
> >
> > Yeah but remember it all works from the userspace emu with the same settings.
>
> Ok, I will wait for a better in tree emulator :D

Hmmm giving this some more thought and based on what Ron has said this
I think I made an Apples to Oranges comparison.

Since we still don't know _what_ is really going on, seems reasonable
to just try everything.  So go ahead and play with those bit settings.
 Can't hurt.

--
Richard A. Smith



From stepan at coresystems.de  Fri Apr 28 19:26:05 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 28 Apr 2006 19:26:05 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
Message-ID: <20060428172605.GA15973@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060428 17:49]:
> This is actually something that I've wanted to look at but not had the
> time.  The emulator in LB is from the same parent as X.org but its not
> the same at all.  Our base revision is quite old.
 
The base revision should be 0.8 iirc, so its the latest one released
from scitechsoft. (BTW, does anyone know why scitech put it to
"obsolete"?)

There are some patches in our tree that are potentially missing in the
X.org tree and a lot more patches are missing the other way round.

> Yes I know we fixed a lot bugs in our tree but the fact remains that I
> can take the X.org setup in a multi-card, multi-head enviroment and it
> will post the 2nd card in almost every card I've tried.  Our user
> space emu has nowhere near that level of success.
 
Yes, the bios emulation in our setup is absolutely minimal, most stuff
is commented out. So we really only emulate the PCI interrupt 1a. No
surprise lots of cards don't work that work in X..

> I think an upstream sync or at least a diff with the current emu in
> X.org would be a good idea.  I'ts been on my list of stuff to do.  But
> time, money.. yada yada.

Yes, it has on mine, and on Egbert's (Egbert Eich from the FreeDesktop
project, CCed) as well.. I already set up a development repository for
that a couple of years ago, but we never got to work on that any
further. 

Another thing is still we should go vm86 mode instead of x86 emulation.
X.org does the same and they're successful with it.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From eric at zyxod.com  Fri Apr 28 19:26:28 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Fri, 28 Apr 2006 10:26:28 -0700
Subject: [LinuxBIOS] Spradic linking errors
In-Reply-To: <20060427220024.GE19370@coresystems.de>
References: <44510291.2030204@zyxod.com>
	<20060427220024.GE19370@coresystems.de>
Message-ID: <44525044.6020904@zyxod.com>

That was it, thanks.

Stefan Reinauer wrote:
> * Eric Poulsen <eric at zyxod.com> [060427 19:42]:
>   
>> I'm getting these errors sporadically when compiling.  I am doing 'make 
>> clean,' but it doesn't help.  At one point, I changed the config and 
>> re-ran buildtarget, then changed the config back and re-built, and it 
>> seem to clear it up.  Anyone have any idea on what's causing this?
>>     
>
> [..]
>
> increase ROM_IMAGE_SIZE in your target Config.lb file.
>
> Stefan
>
>   




From stepan at coresystems.de  Fri Apr 28 19:27:33 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 28 Apr 2006 19:27:33 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44524585.5040902@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<44524585.5040902@suehsi.de>
Message-ID: <20060428172733.GB15973@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060428 18:40]:
> 
> >Two theories:
> > - caching of the C segment is messed up
> > - timing is messed up
> >
> 
> Sorry, I'm not a bit guru. What is the result of that.
> 
> 0x040000000>>30

type in bash:

 $ printf "0x%x\n" $(( 0x040000000>>30 ))

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ollie at lanl.gov  Fri Apr 28 19:31:51 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 28 Apr 2006 11:31:51 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060428172605.GA15973@coresystems.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<20060428172605.GA15973@coresystems.de>
Message-ID: <1146245511.10690.0.camel@logarithm.lanl.gov>

On Fri, 2006-04-28 at 19:26 +0200, Stefan Reinauer wrote:
> 
> Another thing is still we should go vm86 mode instead of x86 emulation.
> X.org does the same and they're successful with it.
> 

Not available for K8 64-bit mode.
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From rminnich at lanl.gov  Fri Apr 28 19:28:34 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 28 Apr 2006 11:28:34 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060428172605.GA15973@coresystems.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<20060428172605.GA15973@coresystems.de>
Message-ID: <445250C2.3070803@lanl.gov>

Stefan Reinauer wrote:

>  
> Yes, the bios emulation in our setup is absolutely minimal, most stuff
> is commented out. So we really only emulate the PCI interrupt 1a. No
> surprise lots of cards don't work that work in X..

guys, what cards don't work. We had a huge stack of cards here that all 
worked fine.


> Another thing is still we should go vm86 mode instead of x86 emulation.
> X.org does the same and they're successful with it.

That won't work well on a non-x86, right?

ron



From rminnich at lanl.gov  Fri Apr 28 19:34:01 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 28 Apr 2006 11:34:01 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <1146245511.10690.0.camel@logarithm.lanl.gov>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>	<20060428172605.GA15973@coresystems.de>
	<1146245511.10690.0.camel@logarithm.lanl.gov>
Message-ID: <44525209.4060808@lanl.gov>

Li-Ta Lo wrote:
> On Fri, 2006-04-28 at 19:26 +0200, Stefan Reinauer wrote:
> 
>>Another thing is still we should go vm86 mode instead of x86 emulation.
>>X.org does the same and they're successful with it.
>>
> 
> 
> Not available for K8 64-bit mode.

yeah, vm86 mode overall is, from my point of view, a step backwards. We 
chose emulation after a lot of trials with other ideas.

So, maybe X works well with lots of cards, but I need to be convinced 
that the problems we're seeing are real emulator problems, not hardware 
setup problems. I'm not convinced we know what is going on here.

ron



From smithbone at gmail.com  Fri Apr 28 20:18:57 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 28 Apr 2006 13:18:57 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <445250C2.3070803@lanl.gov>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<20060428172605.GA15973@coresystems.de> <445250C2.3070803@lanl.gov>
Message-ID: <8a0c36780604281118i1166ac78w5304030ca7c5b832@mail.gmail.com>

> > Yes, the bios emulation in our setup is absolutely minimal, most stuff
> > is commented out. So we really only emulate the PCI interrupt 1a. No
> > surprise lots of cards don't work that work in X..
>
> guys, what cards don't work. We had a huge stack of cards here that all
> worked fine.

Hmm.. Perhaps my info is out of date.  I'll have to go back through my
stack of cards and re-try.

--
Richard A. Smith



From smithbone at gmail.com  Fri Apr 28 20:30:04 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 28 Apr 2006 13:30:04 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44525209.4060808@lanl.gov>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<20060428172605.GA15973@coresystems.de>
	<1146245511.10690.0.camel@logarithm.lanl.gov>
	<44525209.4060808@lanl.gov>
Message-ID: <8a0c36780604281130v63ce13d6yd947b896d4c58747@mail.gmail.com>

On 4/28/06, Ronald G Minnich <rminnich at lanl.gov> wrote:

> So, maybe X works well with lots of cards, but I need to be convinced
> that the problems we're seeing are real emulator problems, not hardware
> setup problems. I'm not convinced we know what is going on here.

I know for a fact I don't know whats going on. *grin*

I'm not suggesting that its an emulator problem and not a
configuration problem.  I'm just trying to go through all the
variables.

--
Richard A. Smith



From steven.goodrich at amd.com  Fri Apr 28 22:37:54 2006
From: steven.goodrich at amd.com (Goodrich,Steven)
Date: Fri, 28 Apr 2006 15:37:54 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA: disabling 00:12:4
Message-ID: <0E81348C5627674A9C0061413EBFF5F74F4679@SAUSEXMB2.amd.com>

I've looked at the original BIOS source and the internal versions of the
documentation, and here's what I've determined:  As near as I can tell,
you cannot disable the PCI header for the device at 00:12:4.  The
original BIOS (written by others on the BIOS team here at AMD in
Colorado) virtualized the PCI headers via SMM code, and that header was
masked when internal graphics were disabled.  Without SMM code, you
cannot do the same thing.
 
Interesting info/notes:
If you disable memory space via the PCI header (PCI header register 04,
bit 1 -- clear to zero), you should disable it somewhat.
 
If the F4 Video Configuration trap bit (F0, Index 42h, bit 1) is set,
the system will generate SMIs when trying to access the PCI header
registers.  This should be clear for a non-SMM system.
 
I suppose you could special-case the device in your PCI scan/enumeration
code, but that is probably more kludgy than you'd like.  Could you
reduce the device's resource requirements to zero?

    -- Steve G.

Steve Goodrich (Steven.Goodrich at amd.com <mailto:Steven.Goodrich at amd.com>
)
Advanced Micro Devices, Inc.
1351 S. Sunset Street
Mail Stop 83-36
Longmont, CO  80501
303-774-5129    (fax: 303-774-5801)
http://www.amd.com/embeddedprocessors 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060428/e3182cad/attachment.html>

From chris at suehsi.de  Sat Apr 29 00:59:25 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 29 Apr 2006 00:59:25 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA: disabling 00:12:4
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4679@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4679@SAUSEXMB2.amd.com>
Message-ID: <44529E4D.8010705@suehsi.de>

Many thanks for that,

Goodrich,Steven schrieb:
> I've looked at the original BIOS source and the internal versions of the 
> documentation, and here's what I've determined:  As near as I can tell, 
> you cannot disable the PCI header for the device at 00:12:4.  The 
> original BIOS (written by others on the BIOS team here at AMD in 
> Colorado) virtualized the PCI headers via SMM code, and that header was 
> masked when internal graphics were disabled.  Without SMM code, you 
> cannot do the same thing.

Okay, First we have thought, that the enabled but not used device causes 
the trouble we have had at the beginning. At the moment it seems there 
is somewhere an other reason for our problems.
However, I will find it ;)

>  
> Interesting info/notes:
> If you disable memory space via the PCI header (PCI header register 04, 
> bit 1 -- clear to zero), you should disable it somewhat.
>  
> If the F4 Video Configuration trap bit (F0, Index 42h, bit 1) is set, 
> the system will generate SMIs when trying to access the PCI header 
> registers.  This should be clear for a non-SMM system.

Yeah, I have read that and it could be useful.

>  
> I suppose you could special-case the device in your PCI scan/enumeration 
> code, but that is probably more kludgy than you'd like.  Could you 
> reduce the device's resource requirements to zero?

I think we could. It is shown, but not allocated at the moment, 
therefore it uses no resources.

regards chris

> 
>     -- Steve G.
> 
> *****Steve Goodrich* (_____Steven.Goodrich at amd.com_ 
> <mailto:Steven.Goodrich at amd.com>)
> Advanced Micro Devices, Inc.
> 1351 S. Sunset Street
> Mail Stop 83-36
> Longmont, CO  80501
> 303-774-5129    (fax: 303-774-5801)
> http://www.amd.com/embeddedprocessors
> 
>  
> 




From smithbone at gmail.com  Fri Apr 28 23:42:57 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 28 Apr 2006 16:42:57 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA: disabling 00:12:4
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F74F4679@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4679@SAUSEXMB2.amd.com>
Message-ID: <8a0c36780604281442rf09c2a4q32bd0b785e6e528b@mail.gmail.com>

On 4/28/06, Goodrich,Steven <steven.goodrich at amd.com> wrote:

>
> I suppose you could special-case the device in your PCI scan/enumeration
> code, but that is probably more kludgy than you'd like.  Could you reduce
> the device's resource requirements to zero?

Well we don't really know if having the device enabled is a problem. 
We were worried that perhaps there was some sort of conflict with the
2 video devices and thats why the factory bios had it disabled.

So If its left alone and not allocated any memory or IO resources it
should effectively not be there.  It it really behaves as proper PCI
device then this should be true.

I think the re-cap on this is if the Config.lb is correct then 0:9.0
will get the VGA resources.  And we just need to disable 12.4s SMI on
config access.  Although it seems to enumerate fine so that may not be
an issue.

That just leaves this pesky 90 second video init issue.

--
Richard A. Smith



From chris at suehsi.de  Sat Apr 29 01:29:26 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 29 Apr 2006 01:29:26 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA: disabling 00:12:4
In-Reply-To: <8a0c36780604281442rf09c2a4q32bd0b785e6e528b@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4679@SAUSEXMB2.amd.com>
	<8a0c36780604281442rf09c2a4q32bd0b785e6e528b@mail.gmail.com>
Message-ID: <4452A556.3000409@suehsi.de>


> 
> That just leaves this pesky 90 second video init issue.
>

Yeeeeaaaaah,
tomorrow I will have a few more tests.

If you have any ideas, let me know.
I do all what you want ;)

First I will try to read out the factory settings.

Next, a question.
Is there something different after a linux boot.
Means, does linux anything what LB not do?
Sets Linux any special registers, I/O ranges or whatever?

Needs/use the emu special resources?

What about the RAM init. It seems, the settings for the memory 
controller are not well done.

and more and more ...

chris

> --
> Richard A. Smith
> 




From stepan at coresystems.de  Sat Apr 29 01:16:17 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 29 Apr 2006 01:16:17 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060424222501.GC27028@io.pong.be>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
	<20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
Message-ID: <20060428231617.GA28043@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060425 00:25]:
> On Tue, Apr 25, 2006 at 12:21:44AM +0200, Stefan Reinauer wrote:
> > * Ronald G Minnich <rminnich at lanl.gov> [060425 00:02]:
> > > this problem goes back to our very first boot some six years ago. Amazing.
> > > 
> > > ATA has outrageous boot delays. I'm sorry to see that SATA has them too. 
> > > I have no good idea how to fix this, unless we can train FILO to know 
> > > that we're coming into boot from power on reset.
> > 
> > What's needed here? Just keep on polling until either a couple more
> > seconds are gone or we finally start seeing the drive?
> > 
> > What features does the etherboot filo have that the official one does
> > not? I'd like to merge those, as file-pre-0.5 has a lot of interesting 
> > stuff that never went into etherboot (and etherboot is a pita to build 
> > compared to filo at least)
> 
> Can we have SATA support directly in filo? That would simplify things
> greatly!

The latest Subversion revision at

   svn://openbios.org/filo/trunk/filo-0.5

should have working S-ATA. I have no S-ATA here so I could not test it.
It's the version that also comes with the GRUB user interface.

It still lacks two things:

 - reading syslinux.cfg from cdroms/dvds to allow really easy CD booting
 - zelf support

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Sat Apr 29 12:38:44 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 29 Apr 2006 12:38:44 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA: disabling 00:12:4
In-Reply-To: <4452A556.3000409@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4679@SAUSEXMB2.amd.com>	<8a0c36780604281442rf09c2a4q32bd0b785e6e528b@mail.gmail.com>
	<4452A556.3000409@suehsi.de>
Message-ID: <44534234.3090400@suehsi.de>


> 
> What about the RAM init. It seems, the settings for the memory 
> controller are not well done.
> 

The settings for the memory config registers are ok.

chris



From andy.somerville at gmail.com  Sat Apr 29 18:49:07 2006
From: andy.somerville at gmail.com (Andy Somerville)
Date: Sat, 29 Apr 2006 12:49:07 -0400
Subject: [LinuxBIOS] State of vt8237 and consequently epia-ms
Message-ID: <ca787df10604290949n6c5583b9na169d53a5f848c2c@mail.gmail.com>

Hi all,


     Im new to linuxbios and the mailing list so please excuse any
newbie stupidity. I was wondering about the state of vt8237
southbridge support. From my limited understanding of linuxBios this
is virtually all that is missing for Epia-MS support since CLE266
northbridge is already supported.

I saw a post in february which mentioned vt8237 and that it was being
worked on, but I have seen nothing since. Forgive me if Ive missed
something.

So I guess my overall question is: Is Epia-MS support a near
possiblity, and what would it take to produce?


       Andy



From hidi at e-tiger.net  Sat Apr 29 19:25:58 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sat, 29 Apr 2006 19:25:58 +0200
Subject: [LinuxBIOS] Linuxbios Tyan S2882D
Message-ID: <725208808.20060429192558@e-tiger.net>

 Dear List!

 I've compiled the BIOS for Tyan S2882D dual Opteron system, I've
 dumped the original videobios (it has good signature:) but seems the
 BIOS doesn't start it! The other problem is that when I load a kernel
 the system simply restarts no output at all. May the absense of the
 videobios cause this? My last message is "Jumping to the entry point"
 The kernel works fine with the original AMI :( BIOS! The FILO and
 Etherboot (via network) also does the same! Does anybody have a good
 linuxbios config for this motherboard? a working binary is welcome
 too :) I would like to find the problem, but it would be to use
 failback code instead of flashing the whole chip once and once:)


-- 
Best regards,
 Hidasi                          mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060429/36d42979/attachment.sig>

From chris at suehsi.de  Sat Apr 29 21:04:11 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 29 Apr 2006 21:04:11 +0200
Subject: [LinuxBIOS] Linuxbios Tyan S2882D
In-Reply-To: <725208808.20060429192558@e-tiger.net>
References: <725208808.20060429192558@e-tiger.net>
Message-ID: <4453B8AB.1010907@suehsi.de>

Hidasi Jozsef schrieb:
>  Dear List!
> 
>  I've compiled the BIOS for Tyan S2882D dual Opteron system, I've
>  dumped the original videobios (it has good signature:) but seems the
>  BIOS doesn't start it! The other problem is that when I load a kernel
>  the system simply restarts no output at all. May the absense of the
>  videobios cause this? My last message is "Jumping to the entry point"
>  The kernel works fine with the original AMI :( BIOS! The FILO and
>  Etherboot (via network) also does the same! Does anybody have a good
>  linuxbios config for this motherboard? a working binary is welcome
>  too :) I would like to find the problem, but it would be to use
>  failback code instead of flashing the whole chip once and once:)
> 
> 
> 
Supports your kernel the console output via serial ?

chris



From talbotx at comcast.net  Sat Apr 29 21:37:06 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Sat, 29 Apr 2006 12:37:06 -0700
Subject: [LinuxBIOS] State of vt8237 and consequently epia-ms
In-Reply-To: <ca787df10604290949n6c5583b9na169d53a5f848c2c@mail.gmail.com>
References: <ca787df10604290949n6c5583b9na169d53a5f848c2c@mail.gmail.com>
Message-ID: <4453C062.6040204@comcast.net>

-Andy
Currently the is no support for the vt8237.
What would it take to support?  Some one who has a few weeks to work on it.
I spent a few weeks, but was never able to get the console running. 
With out that, I had no way of doing debugging.  My board does not have
any PCI slots, so I was unable to use a post card to debug.
-Adam

Andy Somerville wrote:
> Hi all,
>
>
>      Im new to linuxbios and the mailing list so please excuse any
> newbie stupidity. I was wondering about the state of vt8237
> southbridge support. From my limited understanding of linuxBios this
> is virtually all that is missing for Epia-MS support since CLE266
> northbridge is already supported.
>
> I saw a post in february which mentioned vt8237 and that it was being
> worked on, but I have seen nothing since. Forgive me if Ive missed
> something.
>
> So I guess my overall question is: Is Epia-MS support a near
> possiblity, and what would it take to produce?
>
>
>        Andy
>
>   




From stepan at coresystems.de  Sat Apr 29 21:57:00 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 29 Apr 2006 21:57:00 +0200
Subject: [LinuxBIOS] [FEATURE] payload compression
Message-ID: <20060429195700.GA12529@coresystems.de>

Hi,

while I've been working on FILO and OpenBIOS lately I really wished
that they could be used as nrv2b compressed payload, like its possible
with etherboot.

Since etherboot is probably not going to be developed beyond v5.5 and
because the zelf support in etherboot is really ugly, I thought of an
alternative to support compressed payloads easily.

So I wrote a new stream which can be enabled by using
CONFIG_COMPRESSED_ROM_STREAM instead of CONFIG_ROM_STREAM.

When you enable CONFIG_COMPRESSED_ROM_STREAM, the payload you specify
will completely automatically be compressed during the build stage, so
you don't have to do anything except safe space with a few small
changes.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
-------------- next part --------------
Index: src/stream/Config.lb
===================================================================
--- src/stream/Config.lb	(revision 2286)
+++ src/stream/Config.lb	(working copy)
@@ -1,3 +1,4 @@
+uses CONFIG_COMPRESSED_ROM_STREAM
 uses CONFIG_ROM_STREAM
 uses CONFIG_IDE_STREAM
 uses CONFIG_FS_STREAM
@@ -7,6 +8,10 @@
   object rom_stream.o
 end
 
+if CONFIG_COMPRESSED_ROM_STREAM
+  object zrom_stream.o
+end
+
 if CONFIG_IDE_STREAM
   default CONFIG_IDE=1
   object ide_stream.o
Index: src/stream/zrom_stream.c
===================================================================
--- src/stream/zrom_stream.c	(revision 0)
+++ src/stream/zrom_stream.c	(revision 0)
@@ -0,0 +1,133 @@
+#include <console/console.h>
+#include <stdlib.h>
+#include <stddef.h>
+#include <stream/read_bytes.h>
+#include <string.h>
+
+#define GETBIT(bb, src, ilen) \
+    (bc > 0 ? ((bb>>--bc)&1) : (bc=31,\
+    bb=*(const uint32_t *)((src)+ilen),ilen+=4,(bb>>31)&1))
+
+static void unrv2b(uint8_t * src, uint8_t * dst)
+{
+	unsigned long ilen = 0, olen = 0, last_m_off = 1;
+	uint32_t bb = 0;
+	unsigned bc = 0;
+	const uint8_t *m_pos;
+
+	src += 4;
+
+	for (;;) {
+		unsigned int m_off, m_len;
+		while (GETBIT(bb, src, ilen)) {
+			dst[olen++] = src[ilen++];
+		}
+
+		m_off = 1;
+		do {
+			m_off = m_off * 2 + GETBIT(bb, src, ilen);
+		} while (!GETBIT(bb, src, ilen));
+		if (m_off == 2) {
+			m_off = last_m_off;
+		} else {
+			m_off = (m_off - 3) * 256 + src[ilen++];
+			if (m_off == 0xffffffffU)
+				break;
+			last_m_off = ++m_off;
+		}
+
+		m_len = GETBIT(bb, src, ilen);
+		m_len = m_len * 2 + GETBIT(bb, src, ilen);
+		if (m_len == 0) {
+			m_len++;
+			do {
+				m_len = m_len * 2 + GETBIT(bb, src, ilen);
+			} while (!GETBIT(bb, src, ilen));
+			m_len += 2;
+		}
+		m_len += (m_off > 0xd00);
+
+		m_pos = dst + olen - m_off;
+		dst[olen++] = *m_pos++;
+		do {
+			dst[olen++] = *m_pos++;
+		} while (--m_len > 0);
+	}
+
+}
+
+#ifndef CONFIG_ROM_STREAM_START
+#define CONFIG_ROM_STREAM_START 0xffff0000UL
+#endif
+
+unsigned char *rom_start = (unsigned char *)CONFIG_ROM_STREAM_START;
+unsigned char *rom_end = (unsigned char *)(CONFIG_ROM_STREAM_START + PAYLOAD_SIZE - 1);;
+
+extern unsigned char _heap, _eheap;
+
+static const unsigned char *rom;
+
+int stream_init(void)
+{
+	unsigned long compressed_rom_start=rom_start; 
+	unsigned long compressed_rom_end=rom_end; 
+	unsigned int len;
+	
+	len=*(unsigned int *)compressed_rom_start; // LE only for now
+
+	printk_debug (" compressed rom stream: 0x%08lx - 0x%08lx\n",
+				compressed_rom_start, compressed_rom_end);
+
+	rom_start = &_eheap;
+	rom_end = rom_start + len; // LE only for now
+#if 0
+	{
+	int i;
+	for (i=0; i<512; i++) {
+		if( i%16==0) printk_spew("\n%04x :", i);
+		printk_spew(" %02x", *(unsigned char *)(compressed_rom_start+i));
+	}
+	}
+#endif
+	printk_debug(" rom stream: 0x%08lx - 0x%08lx\n", (unsigned long) 
+			rom_start, (unsigned long) rom_end);
+
+	printk_debug("Uncompressing...");
+	unrv2b((uint8_t *) compressed_rom_start, (uint8_t *)rom_start);
+	printk_debug(" done.\n");
+	
+	rom = rom_start;
+
+	return 0;
+}
+
+void stream_fini(void)
+{
+	return;
+}
+
+byte_offset_t stream_skip(byte_offset_t count)
+{
+	byte_offset_t bytes;
+	bytes = count;
+	if ((rom + bytes) > rom_end) {
+		printk_warning(" overflowed source buffer\n");
+		bytes = 0;
+		if (rom <= rom_end) {
+			bytes = (rom_end - rom) + 1;
+		}
+	}
+	rom += bytes;
+	return bytes;
+}
+
+byte_offset_t stream_read(void *vdest, byte_offset_t count)
+{
+	unsigned char *dest = vdest;
+	const unsigned char *src = rom;
+	byte_offset_t bytes;
+
+	bytes = stream_skip(count);
+	memcpy(dest, src, bytes);
+	return bytes;
+}
Index: src/stream/rom_stream.c
===================================================================
--- src/stream/rom_stream.c	(revision 2286)
+++ src/stream/rom_stream.c	(working copy)
@@ -18,8 +18,8 @@
  */
 
 /*XXXXXXXXXXXXXX */
-/*static const */unsigned char *rom_start = (void *)CONFIG_ROM_STREAM_START;
-/*static const */unsigned char *rom_end   = (void *)(CONFIG_ROM_STREAM_START + PAYLOAD_SIZE - 1);
+/*static const */unsigned char *rom_start = (unsigned char *)CONFIG_ROM_STREAM_START;
+/*static const */unsigned char *rom_end   = (unsigned char *)(CONFIG_ROM_STREAM_START + PAYLOAD_SIZE - 1);
 /*XXXXXXXXXXXXXX */
 static const unsigned char *rom;
 
Index: src/config/Options.lb
===================================================================
--- src/config/Options.lb	(revision 2286)
+++ src/config/Options.lb	(working copy)
@@ -564,6 +564,11 @@
 	export always
 	comment "ROM stream start location"
 end
+define CONFIG_COMPRESSED_ROM_STREAM
+	default 0
+	export always
+	comment "compressed boot image is located in ROM" 
+end
 define CONFIG_FS_STREAM
 	default 0
 	export always
Index: src/arch/i386/Config.lb
===================================================================
--- src/arch/i386/Config.lb	(revision 2286)
+++ src/arch/i386/Config.lb	(working copy)
@@ -18,9 +18,22 @@
 	action	"$(HOSTCC) -O2 -DENCODE -DDECODE -DMAIN -DVERBOSE -DNDEBUG -DBITSIZE=32 -DENDIAN=0 $< -o $@"
 end
 
+makerule payload
+	depends "$(PAYLOAD)"
+	action  "cp $< $@"
+end
+
+makerule payload.nrv2b
+	depends "$(PAYLOAD) nrv2b"
+	action  "./nrv2b e $(PAYLOAD) $@"
+end
+
+makedefine PAYLOAD-1:=payload
+makedefine PAYLOAD-$(CONFIG_COMPRESSED_ROM_STREAM):=payload.nrv2b
+
 makerule linuxbios.rom 
-	depends	"linuxbios.strip buildrom" 
-	action "./buildrom $< $@ $(PAYLOAD) $(ROM_IMAGE_SIZE) $(ROM_SECTION_SIZE)"
+	depends	"linuxbios.strip buildrom $(PAYLOAD-1)" 
+	action "./buildrom $< $@ $(PAYLOAD-1) $(ROM_IMAGE_SIZE) $(ROM_SECTION_SIZE)"
 end
 
 makerule crt0.S

From chris at suehsi.de  Sat Apr 29 23:36:12 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 29 Apr 2006 23:36:12 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604281130v63ce13d6yd947b896d4c58747@mail.gmail.com> 
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>	<20060428172605.GA15973@coresystems.de>	<1146245511.10690.0.camel@logarithm.lanl.gov>	<44525209.4060808@lanl.gov>
	<8a0c36780604281130v63ce13d6yd947b896d4c58747@mail.gmail.com> 
Message-ID: <4453DC4C.4050401@suehsi.de>

There is a little question for me,
is this a normal output?

Why is the run_bios_int called three times?
Remember, on LB I have three calls, too.
What is done after these calls.
It seems that there are no differences between the second and the third one.

There is a ip (initial point) flag for testbios. Is there someting else 
for the inTree one.

Is testbios faster with given ip.

chris

> 
> QLC-> ./testbios --abseg /dev/mem -s 32768 aw512n.bin
> running file aw512n.bin
> No base specified. defaulting to 0xc0000
> No initial code segment specified. defaulting to 0xc000
> No initial instruction pointer specified. defaulting to 0x0003
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x42
> updating int vector 0x42
> updating int vector 0x43
> updating int vector 0x43
> updating int vector 0x1f
> updating int vector 0x1f
> updating int vector 0x1d
> updating int vector 0x1d
> updating int vector 0x1d
> updating int vector 0x1d
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> int10 vector at c41b4
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> run_bios_int: INT 10 CS:IP = c000:41b4
> updating int vector 0x43
> updating int vector 0x43
> updating int vector 0x43
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> int10 vector at c41b4
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> run_bios_int: INT 10 CS:IP = c000:41b4
> updating int vector 0x43
> updating int vector 0x43
> updating int vector 0x43
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> int10 vector at c41b4
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> updating int vector 0x10
> run_bios_int: INT 10 CS:IP = c000:41b4
> updating int vector 0x43
> updating int vector 0x43
> updating int vector 0x1d
> updating int vector 0x1d
> QLC-> 




From hidi at e-tiger.net  Sat Apr 29 22:25:35 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sat, 29 Apr 2006 22:25:35 +0200
Subject: [LinuxBIOS] Tyan S2882
In-Reply-To: <4453DC4C.4050401@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<20060428172605.GA15973@coresystems.de>
	<1146245511.10690.0.camel@logarithm.lanl.gov>
	<44525209.4060808@lanl.gov>
	<8a0c36780604281130v63ce13d6yd947b896d4c58747@mail.gmail.com>
	<4453DC4C.4050401@suehsi.de>
Message-ID: <1939618224.20060429222535@e-tiger.net>

Dear List!

 I've managed out, the dumping from linux with the working BIOS is not
 a good way in this case, it reports 32kByte BIOS ROM however it's
 36kbyte in the real world:) just extract it from the BIOS.

 I still cannot boot, no message at all FILO loads and immediatelly
 restarts the system (After jumping to the entry point), Etherboot
 hangs. Please help!

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060429/cfa11307/attachment.sig>

From hidi at e-tiger.net  Sat Apr 29 22:28:51 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sat, 29 Apr 2006 22:28:51 +0200
Subject: [LinuxBIOS] S2882 Video
Message-ID: <1901629097.20060429222851@e-tiger.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

Sorry for disturbing you:)

I got this:

rom address for PCI: 04:06.0 = fff80000
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x9000 bytes
entering emulator
halt_sys: file /src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
PCI: 04:08.0 init


besides it displays the rest booting stuff, so what's this???

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQEVAwUARFPMg3YPIL9PySTHAQHAnQf/WKXO4UdMeSa1c7g/Avbj90ilt/H0iwzX
Z1RKR4HRdrHKer2Vgt6JYiX15+XjteLYxDbeQmNaVTTu6nevr+APQLn/cbDdA3eN
ZtcAQlbmFfrpjQgPQ/vYAfaxTAAvrUUOyS+P8yAYbwB7d73shxH7Z2ZjyhmEiISr
NRMbBx3RnWufdKp5JZmnjlcJhGmZzDrjL8Xqmq8Va+A4eFBgEguv6ws5PWQ8ONsh
Ecm+go+/qesY/7NA1HLMBVdo9GEf5YMtJRLXppvQIBR6YmWViumNcxHjXAsDJpXL
Zk5lSISTU4AGGUdqRL52jcHBQYBRS7GGfzjcM5JT9ML0lWvxgNZlPQ==
=yz6z
-----END PGP SIGNATURE-----






From yinghailu at gmail.com  Sat Apr 29 23:21:46 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 29 Apr 2006 14:21:46 -0700
Subject: [LinuxBIOS] S2882 Video
In-Reply-To: <1901629097.20060429222851@e-tiger.net>
References: <1901629097.20060429222851@e-tiger.net>
Message-ID: <2ea3fae10604291421w20c4dc86w21a96828c59514d@mail.gmail.com>

that mean your vga rom is executed successfully...

YH

On 4/29/06, Hidasi Jozsef <hidi at e-tiger.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: MD5
>
> Sorry for disturbing you:)
>
> I got this:
>
> rom address for PCI: 04:06.0 = fff80000
> copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x9000 bytes
> entering emulator
> halt_sys: file /src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
> PCI: 04:08.0 init
>
>
> besides it displays the rest booting stuff, so what's this???
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6
>
> iQEVAwUARFPMg3YPIL9PySTHAQHAnQf/WKXO4UdMeSa1c7g/Avbj90ilt/H0iwzX
> Z1RKR4HRdrHKer2Vgt6JYiX15+XjteLYxDbeQmNaVTTu6nevr+APQLn/cbDdA3eN
> ZtcAQlbmFfrpjQgPQ/vYAfaxTAAvrUUOyS+P8yAYbwB7d73shxH7Z2ZjyhmEiISr
> NRMbBx3RnWufdKp5JZmnjlcJhGmZzDrjL8Xqmq8Va+A4eFBgEguv6ws5PWQ8ONsh
> Ecm+go+/qesY/7NA1HLMBVdo9GEf5YMtJRLXppvQIBR6YmWViumNcxHjXAsDJpXL
> Zk5lSISTU4AGGUdqRL52jcHBQYBRS7GGfzjcM5JT9ML0lWvxgNZlPQ==
> =yz6z
> -----END PGP SIGNATURE-----
>
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From yinghailu at gmail.com  Sat Apr 29 23:33:59 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 29 Apr 2006 14:33:59 -0700
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <20060429195700.GA12529@coresystems.de>
References: <20060429195700.GA12529@coresystems.de>
Message-ID: <2ea3fae10604291433m5b316527vfd51af5b1f2afee9@mail.gmail.com>

sounds good.
you need to notice one thing...
check if it could cross the [0xa0000, 0xd0000)...

To make it easier, You may just set CONFIG_TOP_MEM_K to 4096, and
_RAM_START to 1M...

YH

On 4/29/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> Hi,
>
> while I've been working on FILO and OpenBIOS lately I really wished
> that they could be used as nrv2b compressed payload, like its possible
> with etherboot.
>
> Since etherboot is probably not going to be developed beyond v5.5 and
> because the zelf support in etherboot is really ugly, I thought of an
> alternative to support compressed payloads easily.
>
> So I wrote a new stream which can be enabled by using
> CONFIG_COMPRESSED_ROM_STREAM instead of CONFIG_ROM_STREAM.
>
> When you enable CONFIG_COMPRESSED_ROM_STREAM, the payload you specify
> will completely automatically be compressed during the build stage, so
> you don't have to do anything except safe space with a few small
> changes.
>
> Stefan
>
> --
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>



From hidi at e-tiger.net  Sat Apr 29 23:37:58 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sat, 29 Apr 2006 23:37:58 +0200
Subject: [LinuxBIOS] S2882 Video
In-Reply-To: <2ea3fae10604291421w20c4dc86w21a96828c59514d@mail.gmail.com>
References: <1901629097.20060429222851@e-tiger.net>
	<2ea3fae10604291421w20c4dc86w21a96828c59514d@mail.gmail.com>
Message-ID: <97921176.20060429233758@e-tiger.net>

Hi!

 Thank you, but instead of this text it would be nicer to display
 everything is ok:) Can anybody help me a working linuxbios rom for
 s2882?:) I can't boot I've tryed several kernels yet none of them
 works! :(


Saturday, April 29, 2006, 11:21:46 PM, you wrote:

> that mean your vga rom is executed successfully...

> YH

> On 4/29/06, Hidasi Jozsef <hidi at e-tiger.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: MD5
>>
>> Sorry for disturbing you:)
>>
>> I got this:
>>
>> rom address for PCI: 04:06.0 = fff80000
>> copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x9000 bytes
>> entering emulator
>> halt_sys: file /src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
>> PCI: 04:08.0 init
>>
>>
>> besides it displays the rest booting stuff, so what's this???
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: 2.6
>>
>> iQEVAwUARFPMg3YPIL9PySTHAQHAnQf/WKXO4UdMeSa1c7g/Avbj90ilt/H0iwzX
>> Z1RKR4HRdrHKer2Vgt6JYiX15+XjteLYxDbeQmNaVTTu6nevr+APQLn/cbDdA3eN
>> ZtcAQlbmFfrpjQgPQ/vYAfaxTAAvrUUOyS+P8yAYbwB7d73shxH7Z2ZjyhmEiISr
>> NRMbBx3RnWufdKp5JZmnjlcJhGmZzDrjL8Xqmq8Va+A4eFBgEguv6ws5PWQ8ONsh
>> Ecm+go+/qesY/7NA1HLMBVdo9GEf5YMtJRLXppvQIBR6YmWViumNcxHjXAsDJpXL
>> Zk5lSISTU4AGGUdqRL52jcHBQYBRS7GGfzjcM5JT9ML0lWvxgNZlPQ==
>> =yz6z
>> -----END PGP SIGNATURE-----
>>
>>
>>
>>
>> --
>> linuxbios mailing list
>> linuxbios at linuxbios.org
>> http://www.openbios.org/mailman/listinfo/linuxbios
>>



-- 
Best regards,
 Hidasi                            mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060429/344caa21/attachment.sig>

From stepan at coresystems.de  Sat Apr 29 23:39:38 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 29 Apr 2006 23:39:38 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4453DC4C.4050401@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<20060428172605.GA15973@coresystems.de>
	<1146245511.10690.0.camel@logarithm.lanl.gov>
	<44525209.4060808@lanl.gov>
	<8a0c36780604281130v63ce13d6yd947b896d4c58747@mail.gmail.com>
	<4453DC4C.4050401@suehsi.de>
Message-ID: <20060429213938.GA21520@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060429 23:36]:
> Why is the run_bios_int called three times?

Your graphics card option rom tries to output 3 lines of text, most
likely. See Ralph Brown's Interrupt List on INT 10h.

> It seems that there are no differences between the second and the third one.

It's the same subroutine within the graphics card option rom, yes.


> There is a ip (initial point) flag for testbios. Is there someting else 
> for the inTree one.
 
It's "instruction pointer". 

> Is testbios faster with given ip.

No, the correct IP is automatically chosen. This is only needed for
non-PCI option roms. Specifying something else than the default will
not even work.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From yinghailu at gmail.com  Sat Apr 29 23:41:03 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 29 Apr 2006 14:41:03 -0700
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <2ea3fae10604291433m5b316527vfd51af5b1f2afee9@mail.gmail.com>
References: <20060429195700.GA12529@coresystems.de>
	<2ea3fae10604291433m5b316527vfd51af5b1f2afee9@mail.gmail.com>
Message-ID: <2ea3fae10604291441s44293900i28593e9df786da8c@mail.gmail.com>

the copy_and_run already have the same function that from nrv2b.c, So
we share the function...

YH

On 4/29/06, yhlu <yinghailu at gmail.com> wrote:
> sounds good.
> you need to notice one thing...
> check if it could cross the [0xa0000, 0xd0000)...
>
> To make it easier, You may just set CONFIG_TOP_MEM_K to 4096, and
> _RAM_START to 1M...
>
> YH
>
> On 4/29/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> > Hi,
> >
> > while I've been working on FILO and OpenBIOS lately I really wished
> > that they could be used as nrv2b compressed payload, like its possible
> > with etherboot.
> >
> > Since etherboot is probably not going to be developed beyond v5.5 and
> > because the zelf support in etherboot is really ugly, I thought of an
> > alternative to support compressed payloads easily.
> >
> > So I wrote a new stream which can be enabled by using
> > CONFIG_COMPRESSED_ROM_STREAM instead of CONFIG_ROM_STREAM.
> >
> > When you enable CONFIG_COMPRESSED_ROM_STREAM, the payload you specify
> > will completely automatically be compressed during the build stage, so
> > you don't have to do anything except safe space with a few small
> > changes.
> >
> > Stefan
> >
> > --
> > coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
> >      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> > Email: info at coresystems.de  ? http://www.coresystems.de/
> >
> >
> > --
> > linuxbios mailing list
> > linuxbios at linuxbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> >
> >
> >
>



From yinghailu at gmail.com  Sat Apr 29 23:51:25 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 29 Apr 2006 14:51:25 -0700
Subject: [LinuxBIOS] S2882 Video
In-Reply-To: <97921176.20060429233758@e-tiger.net>
References: <1901629097.20060429222851@e-tiger.net>
	<2ea3fae10604291421w20c4dc86w21a96828c59514d@mail.gmail.com>
	<97921176.20060429233758@e-tiger.net>
Message-ID: <2ea3fae10604291451ud4d1481kb3584970974c9391@mail.gmail.com>

You need to use mkelfImage to make some zelf from kernel, and initrd...

YH

On 4/29/06, Hidasi Jozsef <hidi at e-tiger.net> wrote:
> Hi!
>
>  Thank you, but instead of this text it would be nicer to display
>  everything is ok:) Can anybody help me a working linuxbios rom for
>  s2882?:) I can't boot I've tryed several kernels yet none of them
>  works! :(
>
>
> Saturday, April 29, 2006, 11:21:46 PM, you wrote:
>
> > that mean your vga rom is executed successfully...
>
> > YH
>
> > On 4/29/06, Hidasi Jozsef <hidi at e-tiger.net> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: MD5
> >>
> >> Sorry for disturbing you:)
> >>
> >> I got this:
> >>
> >> rom address for PCI: 04:06.0 = fff80000
> >> copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x9000 bytes
> >> entering emulator
> >> halt_sys: file /src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
> >> PCI: 04:08.0 init
> >>
> >>
> >> besides it displays the rest booting stuff, so what's this???
> >>
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: 2.6
> >>
> >> iQEVAwUARFPMg3YPIL9PySTHAQHAnQf/WKXO4UdMeSa1c7g/Avbj90ilt/H0iwzX
> >> Z1RKR4HRdrHKer2Vgt6JYiX15+XjteLYxDbeQmNaVTTu6nevr+APQLn/cbDdA3eN
> >> ZtcAQlbmFfrpjQgPQ/vYAfaxTAAvrUUOyS+P8yAYbwB7d73shxH7Z2ZjyhmEiISr
> >> NRMbBx3RnWufdKp5JZmnjlcJhGmZzDrjL8Xqmq8Va+A4eFBgEguv6ws5PWQ8ONsh
> >> Ecm+go+/qesY/7NA1HLMBVdo9GEf5YMtJRLXppvQIBR6YmWViumNcxHjXAsDJpXL
> >> Zk5lSISTU4AGGUdqRL52jcHBQYBRS7GGfzjcM5JT9ML0lWvxgNZlPQ==
> >> =yz6z
> >> -----END PGP SIGNATURE-----
> >>
> >>
> >>
> >>
> >> --
> >> linuxbios mailing list
> >> linuxbios at linuxbios.org
> >> http://www.openbios.org/mailman/listinfo/linuxbios
> >>
>
>
>
> --
> Best regards,
>  Hidasi                            mailto:hidi at e-tiger.net
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>



From stepan at coresystems.de  Sat Apr 29 23:56:49 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 29 Apr 2006 23:56:49 +0200
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <2ea3fae10604291433m5b316527vfd51af5b1f2afee9@mail.gmail.com>
References: <20060429195700.GA12529@coresystems.de>
	<2ea3fae10604291433m5b316527vfd51af5b1f2afee9@mail.gmail.com>
Message-ID: <20060429215649.GA22296@coresystems.de>

* yhlu <yinghailu at gmail.com> [060429 23:33]:
> sounds good.
> you need to notice one thing...
> check if it could cross the [0xa0000, 0xd0000)...

ah right, I did not think of that. 

I originally rewrote the nrv2b decompressor so that it delivers 1 byte
per function call while not needing an additional decompression space.
But unfortunately this only seems to be possible with recursive calls
and it makes some 30000 recursive calls for decompressing a simple 
200byte makefile. So I figured the buffer is the better solution..

> To make it easier, You may just set CONFIG_TOP_MEM_K to 4096, and
> _RAM_START to 1M...

Why would I need to change CONFIG_LB_MEM_TOPK? It's 2048 by default, and
if it's kbytes and I put _RAM_START to 1M I'd still have a whole MByte
for the decompressed payload, or do I miss something?

Hm, trying to follow your suggestion while reading the code..

_RAMSTART vs _RAMBASE - What's the difference?

_RAMSTART is defined here, but never used anywhere in the whole source
code... Can we kill it, or is there some code in some queue who will
start using it?

src/config/Options.lb:define _RAMSTART
src/mainboard/totalimpact/briq/Options.lb:default _RAMSTART=0x00100000
src/mainboard/motorola/sandpoint/Options.lb:default _RAMSTART=0x00100000
src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb:default _RAMSTART=0x00100000

_RAMBASE is used in many places. I assume it is supposed to be the same
as _RAMSTART, but I am not sure.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Sat Apr 29 23:59:31 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 29 Apr 2006 23:59:31 +0200
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <2ea3fae10604291441s44293900i28593e9df786da8c@mail.gmail.com>
References: <20060429195700.GA12529@coresystems.de>
	<2ea3fae10604291433m5b316527vfd51af5b1f2afee9@mail.gmail.com>
	<2ea3fae10604291441s44293900i28593e9df786da8c@mail.gmail.com>
Message-ID: <20060429215931.GB22296@coresystems.de>

* yhlu <yinghailu at gmail.com> [060429 23:41]:
> the copy_and_run already have the same function that from nrv2b.c, So
> we share the function...

Yes. I actually took it from copy_and_run.c. 

Should we put it to lib/unrv2b.c or similar and reference it in both
places? 

I would assume that we have to compile it twice in any case, as the one
time it is running in CAR/romcc context and the other time we're in
"late gcc" context.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From yinghailu at gmail.com  Sun Apr 30 00:10:39 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 29 Apr 2006 15:10:39 -0700
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <20060429215649.GA22296@coresystems.de>
References: <20060429195700.GA12529@coresystems.de>
	<2ea3fae10604291433m5b316527vfd51af5b1f2afee9@mail.gmail.com>
	<20060429215649.GA22296@coresystems.de>
Message-ID: <2ea3fae10604291510w2625ed47ida699b7d966e8251@mail.gmail.com>

Wait...You only need to set _RAMBASE to 1M..., and don't need to touch
CONFIG_MAX_TOP_MEM_K, because at the time all ram mtrr and etc are
initialized well...

Another problem put the payload on somewhere after may cause the
problem for final kerenal..., kernel need to start from 1M....?

So We may need to
1. _RAMBASE for linuxbios_ram ... from 1M or 0x4000
2. _PAYLOAD_BASE it should be somewhere safe for all...
a. sth place before 0xa0000, or b. last Mbytes before end of TOM...

payloads will be
1. Etherboot, zelf
2. FILO,
3. OpenBIOS
4. zelf from kernel and initram disk...less than 4Mbyte or 16Mbyte...

How about compress ratio for nrv2b?

YH



From hidi at e-tiger.net  Sun Apr 30 00:11:51 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sun, 30 Apr 2006 00:11:51 +0200
Subject: [LinuxBIOS] WORK! :) Power button question
Message-ID: <592068803.20060430001151@e-tiger.net>


 IT WORKS! Thanks for you all! :) Just another low priority question:
 is there any way to read the status of the power button? I mean it
 somebody pushed it?


 

  

-- 
Best regards,
 Hidasi                          mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060430/04140392/attachment.sig>

From yinghailu at gmail.com  Sun Apr 30 00:11:58 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 29 Apr 2006 15:11:58 -0700
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <20060429215931.GB22296@coresystems.de>
References: <20060429195700.GA12529@coresystems.de>
	<2ea3fae10604291433m5b316527vfd51af5b1f2afee9@mail.gmail.com>
	<2ea3fae10604291441s44293900i28593e9df786da8c@mail.gmail.com>
	<20060429215931.GB22296@coresystems.de>
Message-ID: <2ea3fae10604291511s95f6ce1lbde2063b5dced368@mail.gmail.com>

Good.  lib/unrv2b.c and CAR could include it....

YH

On 4/29/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * yhlu <yinghailu at gmail.com> [060429 23:41]:
> > the copy_and_run already have the same function that from nrv2b.c, So
> > we share the function...
>
> Yes. I actually took it from copy_and_run.c.
>
> Should we put it to lib/unrv2b.c or similar and reference it in both
> places?
>
> I would assume that we have to compile it twice in any case, as the one
> time it is running in CAR/romcc context and the other time we're in
> "late gcc" context.
>
> Stefan
>
> --
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
>



From hawke at hawkesnest.net  Sun Apr 30 02:05:59 2006
From: hawke at hawkesnest.net (Alex L. Mauer)
Date: Sat, 29 Apr 2006 19:05:59 -0500
Subject: [LinuxBIOS] EPIA non-M?
Message-ID: <e30v1u$d74$1@sea.gmane.org>

What's the current status of LinuxBIOS on plain EPIA boards?  It seems
to be very unclear.  The "Supported motherboards" Wiki page lists it,
but has a lot of "???".  The build tutorial page -- like all the others
-- links to nothing.  The FreeBIOS howto says it doesn't have VGA
support, though that is of course two years out of date.

When I build it, the generated BIOS image is 256k -- which doesn't leave
space to prepend a VGA BIOS.  So is the status of LinuxBIOS on these
boards the same as it was with FreeBIOS 2 years ago?

Thanks
-Alex Mauer "hawke"





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060429/7d971f46/attachment.sig>

From rminnich at lanl.gov  Sun Apr 30 05:41:34 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 29 Apr 2006 21:41:34 -0600
Subject: [LinuxBIOS] Linuxbios Tyan S2882D
In-Reply-To: <725208808.20060429192558@e-tiger.net>
References: <725208808.20060429192558@e-tiger.net>
Message-ID: <445431EE.9090806@lanl.gov>

Hidasi Jozsef wrote:
>  Dear List!
> 
>  I've compiled the BIOS for Tyan S2882D dual Opteron system, I've
>  dumped the original videobios (it has good signature:) but seems the
>  BIOS doesn't start it! The other problem is that when I load a kernel
>  the system simply restarts no output at all. May the absense of the
>  videobios cause this? My last message is "Jumping to the entry point"
>  The kernel works fine with the original AMI :( BIOS! The FILO and
>  Etherboot (via network) also does the same! Does anybody have a good
>  linuxbios config for this motherboard? a working binary is welcome
>  too :) I would like to find the problem, but it would be to use
>  failback code instead of flashing the whole chip once and once:)
> 
> 
> 

build a serial-only kernel. Enable early printk.

Boot the kernel with this
hda1:/vmlinuz console=ttyS0,115200 earlyprintk=ttyS0,115200,keep

send us the output.

ron



From rminnich at lanl.gov  Sun Apr 30 05:46:20 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 29 Apr 2006 21:46:20 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4453DC4C.4050401@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>	<20060428172605.GA15973@coresystems.de>	<1146245511.10690.0.camel@logarithm.lanl.gov>	<44525209.4060808@lanl.gov>
	<8a0c36780604281130v63ce13d6yd947b896d4c58747@mail.gmail.com>
	<4453DC4C.4050401@suehsi.de>
Message-ID: <4454330C.90208@lanl.gov>

Christian S?hs wrote:
> There is a little question for me,
> is this a normal output?

looks ok to me.

> 
> Why is the run_bios_int called three times?

the interrupt was called three times, I think. run_bios_int IIRC just 
means "this bios int was called, service it".

> Remember, on LB I have three calls, too.
> What is done after these calls.
> It seems that there are no differences between the second and the third 
> one.
> 
> There is a ip (initial point) flag for testbios. Is there someting else 
> for the inTree one.

no, because PCI ROMS dictate the initial IP.

I only added that option years ago when I was still trying to figure out 
how this all worked.

> 
> Is testbios faster with given ip.

no.

thanks

ron



From rminnich at lanl.gov  Sun Apr 30 05:46:59 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 29 Apr 2006 21:46:59 -0600
Subject: [LinuxBIOS] Tyan S2882
In-Reply-To: <1939618224.20060429222535@e-tiger.net>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>	<20060428172605.GA15973@coresystems.de>	<1146245511.10690.0.camel@logarithm.lanl.gov>	<44525209.4060808@lanl.gov>	<8a0c36780604281130v63ce13d6yd947b896d4c58747@mail.gmail.com>	<4453DC4C.4050401@suehsi.de>
	<1939618224.20060429222535@e-tiger.net>
Message-ID: <44543333.4090104@lanl.gov>

recommend you do NO VGA until this board works. Stick with serial for now.

ron



From rminnich at lanl.gov  Sun Apr 30 05:47:54 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 29 Apr 2006 21:47:54 -0600
Subject: [LinuxBIOS] S2882 Video
In-Reply-To: <1901629097.20060429222851@e-tiger.net>
References: <1901629097.20060429222851@e-tiger.net>
Message-ID: <4454336A.6090806@lanl.gov>

Hidasi Jozsef wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: MD5
> 
> Sorry for disturbing you:)
> 
> I got this:
> 
> rom address for PCI: 04:06.0 = fff80000
> copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x9000 bytes
> entering emulator
> halt_sys: file /src/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
> PCI: 04:08.0 init


it means that it successfully ran the VGA rom.

We need more serial output.

ron



From rminnich at lanl.gov  Sun Apr 30 05:48:39 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 29 Apr 2006 21:48:39 -0600
Subject: [LinuxBIOS] S2882 Video
In-Reply-To: <97921176.20060429233758@e-tiger.net>
References: <1901629097.20060429222851@e-tiger.net>	<2ea3fae10604291421w20c4dc86w21a96828c59514d@mail.gmail.com>
	<97921176.20060429233758@e-tiger.net>
Message-ID: <44543397.6080204@lanl.gov>

Hidasi Jozsef wrote:
> Hi!
> 
>  Thank you, but instead of this text it would be nicer to display
>  everything is ok:) 


Agreed. That message SUCKS. I will accept patches :-)



we need that serial output from earlyprintk.

ron



From rminnich at lanl.gov  Sun Apr 30 05:49:33 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 29 Apr 2006 21:49:33 -0600
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <592068803.20060430001151@e-tiger.net>
References: <592068803.20060430001151@e-tiger.net>
Message-ID: <445433CD.9080308@lanl.gov>

Hidasi Jozsef wrote:
>  IT WORKS! Thanks for you all! :) Just another low priority question:
>  is there any way to read the status of the power button? I mean it
>  somebody pushed it?


we'll only answer that question if you send us a HOWTO and writeup on
1. what you did
2. what SVN version
3. do you have graphics.

thanks

ron



From rminnich at lanl.gov  Sun Apr 30 05:51:07 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 29 Apr 2006 21:51:07 -0600
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <e30v1u$d74$1@sea.gmane.org>
References: <e30v1u$d74$1@sea.gmane.org>
Message-ID: <4454342B.3080107@lanl.gov>

Alex L. Mauer wrote:
> What's the current status of LinuxBIOS on plain EPIA boards?  It seems
> to be very unclear.  The "Supported motherboards" Wiki page lists it,
> but has a lot of "???".  The build tutorial page -- like all the others
> -- links to nothing.  The FreeBIOS howto says it doesn't have VGA
> support, though that is of course two years out of date.
> 

nobody has had time to fix it, and we've had no requests. Some commit 
busted it when people tried to upgrade it for later EPIAs -- sorry.

I'm sorry, I don't think it works.

thanks

ron



From rminnich at lanl.gov  Sun Apr 30 06:01:13 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 29 Apr 2006 22:01:13 -0600
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <445433CD.9080308@lanl.gov>
References: <592068803.20060430001151@e-tiger.net> <445433CD.9080308@lanl.gov>
Message-ID: <44543689.2070600@lanl.gov>

Ronald G Minnich wrote:
> Hidasi Jozsef wrote:
> 
>> IT WORKS! Thanks for you all! :) Just another low priority question:
>> is there any way to read the status of the power button? I mean it
>> somebody pushed it?
> 
> 
> 
> we'll only answer that question if you send us a HOWTO and writeup on
> 1. what you did
> 2. what SVN version
> 3. do you have graphics.
> 
> thanks
> 
> ron
> 

Sorry, I forgot the :-) on this.

Thanks for doing this work. It is wonderful to see more ports being done.

ron



From eric at zyxod.com  Sun Apr 30 07:40:57 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Sat, 29 Apr 2006 22:40:57 -0700
Subject: [LinuxBIOS] Epia ML 5000 VGA (Again!) -- Moving backwards, somehow.
Message-ID: <44544DE9.1050701@zyxod.com>

I've been trying to accomplish several things:

1) LB on Via Epia ML 5000
2) VGA working
3) Figuring out weird boot errors that seem to be "fixed" by the factory 
BIOS.  Running memtest86+ under LB.

I _was_ on step 3, but in the course of events, I went back to step 2.  
VGA is now NOT working again, but with a different error; see below.

Since I was messing around with making an ML tree, adding a bit of 
custom stuff, and removing initializations for devices that don't exist 
on the ML (floppy, CF reader), I figured I had done something wrong.

Soooo, I went back to the "stock" LinuxBIOSv2, revision 2100, known to 
work with the Epia M.  This particular revision worked for me, albeit 
with the long delay at the beginning because of the firewire search.

Essentially, whenever, I add ...

    #VGA Console
    option CONFIG_CONSOLE_VGA=1
    option CONFIG_PCI_ROM_RUN=1

... to the Config.lb, it doesn't work, giving the error below.

Mysteriously, my "weird boot crashes that are fixed by factory CMOS" 
problems aren't exhibiting themselves.

Unfortunately, I cannot run memtest86 under LB without VGA.

Any ideas?

--------------------------------------------------------------------

0

LinuxBIOS-1.1.8.0Fallback Sat Apr 29 22:12:48 PDT 2006 starting...
 Enabling mainboard devices
 Enabling shadow ram
vt8623 init starting
Detecting Memory
Number of Banks 04
Number of Rows 0d
Priamry DRAM width08
No Columns 0a
MA type e0
Bank 0 (*16 Mb) 10
No Physical Banks 01
Total Memory (*16 Mb) 10
CAS Supported 2 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)75
Starting at CAS 3
We can do CAS 2.5
We can do CAS 2
tRP 48
tRCD 48
tRAS 28
Low Bond 00  High Bondbe  Setting DQS delay7evt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00
50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00
60:02 ff 00 30 d6 32 01 2a 42 2d 43 58 00 44 00 00
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 02
80:0f 65 00 00 80 00 00 00 02 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00
b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00
AGP
 Doing MTRR init.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Sat Apr 29 22:12:48 PDT 2006 booting...
clocks_per_usec: 838
Enumerating buses...
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123] enabled
PCI: 00:01.0 [1106/b091] enabled
Disabling static device: PCI: 00:0a.0
Disabling static device: PCI: 00:0a.1
In vt8235_enable 1106 3038.
PCI: 00:10.0 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 3104.
PCI: 00:10.3 [1106/3104] enabled
In vt8235_enable 1106 3177.
Initialising Devices
PCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106 0571.
PCI: 00:11.1 [1106/0571] enabled
In vt8235_enable 1106 3059.
PCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122] enabled
PCI: pci_scan_bus returning with max=01
vt1211 enabling PNP devices.
PNP: 002e.0 enabled
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
vt1211 enabling PNP devices.
PNP: 002e.b enabled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Allocating VGA resource PCI: 01:00.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:01.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
I would set ram size to 0x40000 Kbytes
PCI: 00:10.0 20 <- [0x0000001800 - 0x000000181f] io
PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f] io
PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io
PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff] mem
Done setting resources.
Done allocating resources.
Enabling resourcess...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 143
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <- 141
PCI: 00:10.1 subsystem <- 00/00
PCI: 00:10.1 cmd <- 141
PCI: 00:10.2 subsystem <- 00/00
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.0 - enabling
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PCI: 00:11.1 cmd <- 147
PCI: 00:11.5 subsystem <- 00/00
PCI: 00:11.5 cmd <- 141
PCI: 00:12.0 cmd <- 1c3
done.
Initializing devices...
Root Device init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
Invalid CMOS LB checksum
pci_routing_fixup: dev is 0001ad40
setting firewire
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.2
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
setting cardbus slot
setting riser slot
PNP: 002e.0 init
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 init
PCI: 00:12.0 init
Configuring VIA Rhine LAN
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Centaur device 673
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000
PCI: 00:01.0 init
VT8623 AGP random fixup ...
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0x100
Unexpected Exception: 13 @ 10:000121c3 - Halting
Code: 0 eflags: 00010012
eax: 00000012 ebx: 00024530 ecx: 00023fa8 edx: 00000012
edi: 00018a90 esi: ffff946b ebp: 00023f84 esp: 00023f84




From hawke at hawkesnest.net  Sun Apr 30 08:50:24 2006
From: hawke at hawkesnest.net (Alex L. Mauer)
Date: Sun, 30 Apr 2006 01:50:24 -0500
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <4454342B.3080107@lanl.gov>
References: <e30v1u$d74$1@sea.gmane.org> <4454342B.3080107@lanl.gov>
Message-ID: <e31mo9$2bj$1@sea.gmane.org>

Ronald G Minnich wrote:
> nobody has had time to fix it, and we've had no requests. Some commit 
> busted it when people tried to upgrade it for later EPIAs -- sorry.

Well, that's OK -- it's free software after all.  But I guess this could
be considered to be a request, then.  If/when someone gets the time,
even updating the status to indicate that it doesn't work would be nice;
fixing/creating the VGA support would be much appreciated as well.

-Alex Mauer "hawke"

-- 
Bad - You get pulled over for doing 90 in a school zone and you're drunk
off your ass again at three in the afternoon.
Worse - The cop is drunk too, and he's a mean drunk.
FUCK! - A mean drunk that's actually a swarm of semi-sentient
flesh-eating beetles.
OpenPGP key id: 51192FF2 @ subkeys.pgp.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060430/0f498a12/attachment.sig>

From hidi at e-tiger.net  Sat Apr 29 19:14:27 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sat, 29 Apr 2006 19:14:27 +0200
Subject: [LinuxBIOS] Linuxbios Tyan S2882D
Message-ID: <1028009761.20060429191427@e-tiger.net>

 Dear List!

 I've compiled the BIOS for Tyan S2882D dual Opteron system, I've
 dumped the original videobios (it has good signature:) but seems the
 BIOS doesn't start it! The other problem is that when I load a kernel
 the system simply restarts no output at all. May the absense of the
 videobios cause this? My last message is "Jumping to the entry point"
 The kernel works fine with the original AMI :( BIOS! The FILO and
 Etherboot (via network) also does the same! Does anybody have a good
 linuxbios config for this motherboard? a working binary is welcome
 too :) I would like to find the problem, but it would be to use
 failback code instead of flashing the whole chip once and once:)


-- 
Best regards,
 Hidasi                          mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060429/3f36c512/attachment.sig>

From alank at compsoc.nuigalway.ie  Sun Apr 30 02:48:22 2006
From: alank at compsoc.nuigalway.ie (alank at compsoc.nuigalway.ie)
Date: Sun, 30 Apr 2006 01:48:22 +0100
Subject: [LinuxBIOS] Support for Asus A7N8X mainboard with nVidia MCP-T
	Southbridge?
Message-ID: <1146358102.445409567c764@www.compsoc.nuigalway.ie>

Hi,

As far as I can see no Asus mainboards are listed as supported by the LinuxBIOS
project. My board is an ASUS A7N8X Deluxe rev 2.0 with a nVidia nForce2 MCP-T
Southbridge and an nVidia nForce2 SPP Northbridge.

My BIOS is a 4MB PLCC with codes:
AN8D2
1003
C302
GM J6

I have downloaded the latest snapshot of LinuxBIOSv2,
as I said ASUS are not listed under the src/mainboard tree,

However /nvidia/ck804 is listed under the southbridge src tree.

The following is the output of "lspci -vvv" on my system. I would be very
grateful if anyone can tell me is there any current or future support of ASUS
planned for LinuxBIOS.

regards,

Alan Keaveney,
Ireland.

=======================================================================
0000:00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?)
(rev c1)
        Subsystem: Asustek Computer, Inc.: Unknown device 80ac
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [40] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans-
64bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1
        Capabilities: [60] #08 [2001]

0000:00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
        Subsystem: Asustek Computer, Inc.: Unknown device 80ac
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-

0000:00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
        Subsystem: Asustek Computer, Inc.: Unknown device 80ac
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-

0000:00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
        Subsystem: Asustek Computer, Inc.: Unknown device 80ac
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-

0000:00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
        Subsystem: Asustek Computer, Inc.: Unknown device 80ac
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-

0000:00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
        Subsystem: Asustek Computer, Inc.: Unknown device 80ac
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-

0000:00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
        Subsystem: Asustek Computer, Inc. A7N8X Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [48] #08 [01e1]

0000:00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
        Subsystem: Asustek Computer, Inc.: Unknown device 0c11
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 5
        Region 0: I/O ports at e000 [size=32]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
(prog-if 10 [OHCI])
        Subsystem: Asustek Computer, Inc. A7N8X Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 22
        Region 0: Memory at ed087000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
(prog-if 10 [OHCI])
        Subsystem: Asustek Computer, Inc. A7N8X Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin B routed to IRQ 21
        Region 0: Memory at ed082000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
(prog-if 20 [EHCI])
        Subsystem: Asustek Computer, Inc. A7N8X Mainboard
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin C routed to IRQ 20
        Region 0: Memory at ed083000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [44] #0a [2080]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller
(rev a1)
        Subsystem: Asustek Computer, Inc. A7N8X Mainboard onboard nForce2
Ethernet
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 22
        Region 0: Memory at ed086000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at e400 [size=8]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

0000:00:05.0 Multimedia audio controller: nVidia Corporation nForce MultiMedia
audio [Via VT82C686B] (rev a2)
        Subsystem: Asustek Computer, Inc.: Unknown device 0c11
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 3000ns max)
        Interrupt: pin A routed to IRQ 5
        Region 0: Memory at ed000000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio
Controler (MCP) (rev a1)
        Subsystem: Asustek Computer, Inc.: Unknown device 8095
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (500ns min, 1250ns max)
        Interrupt: pin A routed to IRQ 20
        Region 0: I/O ports at d000 [size=256]
        Region 1: I/O ports at d400 [size=128]
        Region 2: Memory at ed080000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
(prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        I/O behind bridge: 0000a000-0000bfff
        Memory behind bridge: eb000000-ecffffff
        Prefetchable memory behind bridge: fff00000-000fffff
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

0000:00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2) (prog-if 8a
[Master SecP PriP])
        Subsystem: Asustek Computer, Inc.: Unknown device 0c11
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Region 4: I/O ports at f000 [size=16]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:0c.0 PCI bridge: nVidia Corporation nForce2 PCI Bridge (rev a3) (prog-if
00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: e6000000-e7ffffff
        Prefetchable memory behind bridge: fff00000-000fffff
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
0000:00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire (IEEE
1394) Controller (rev a3) (prog-if 10 [OHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 809a
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 22
        Region 0: Memory at ed084000 (32-bit, non-prefetchable) [size=2K]
        Region 1: Memory at ed085000 (32-bit, non-prefetchable) [size=64]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1) (prog-if 00
[Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 209
        Bus: primary=00, secondary=03, subordinate=03, sec-latency=32
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: e8000000-eaffffff
        Prefetchable memory behind bridge: e4000000-e5ffffff
        BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-

0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology
Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
        Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) Asus A7N8X
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 208, Cache Line Size: 0x08 (32 bytes)
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at a000 [size=8]
        Region 1: I/O ports at a400 [size=4]
        Region 2: I/O ports at a800 [size=8]
        Region 3: I/O ports at ac00 [size=4]
        Region 4: I/O ports at b000 [size=16]
        Region 5: Memory at ec000000 (32-bit, non-prefetchable) [size=512]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

0000:02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB Integrated Fast
Ethernet Controller [Tornado] (rev 40)
        Subsystem: Asustek Computer, Inc. A7N8X Deluxe onboard 3C920B-EMB
Integrated Fast Ethernet Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 208 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes)
        Interrupt: pin A routed to IRQ 21
        Region 0: I/O ports at c000 [size=128]
        Region 1: Memory at e7000000 (32-bit, non-prefetchable) [size=128]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
0000:03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev
01) (prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G550 Dual Head DDR 32Mb
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 208 (4000ns min, 8000ns max), Cache Line Size: 0x08 (32 bytes)
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at e4000000 (32-bit, prefetchable) [size=32M]
        Region 1: Memory at e8000000 (32-bit, non-prefetchable) [size=16K]
        Region 2: Memory at e9000000 (32-bit, non-prefetchable) [size=8M]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [f0] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans-
64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW-
Rate=x1




From stepan at coresystems.de  Sun Apr 30 09:55:29 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 30 Apr 2006 09:55:29 +0200
Subject: [LinuxBIOS] S2882 Video
In-Reply-To: <44543397.6080204@lanl.gov>
References: <1901629097.20060429222851@e-tiger.net>
	<2ea3fae10604291421w20c4dc86w21a96828c59514d@mail.gmail.com>
	<97921176.20060429233758@e-tiger.net> <44543397.6080204@lanl.gov>
Message-ID: <20060430075529.GA25145@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060430 05:48]:
> Hidasi Jozsef wrote:
> > Hi!
> > 
> >  Thank you, but instead of this text it would be nicer to display
> >  everything is ok:) 
> 
> 
> Agreed. That message SUCKS. I will accept patches :-)
 
This is the code that prints the message in src/include/x86emu/x86emu.h

#ifdef  DEBUG
#define HALT_SYS()      \
        printk("halt_sys: file %s, line %d\n", __FILE__, __LINE__); \
        X86EMU_halt_sys();
#else
#define HALT_SYS()      X86EMU_halt_sys()
#endif

DEBUG is undefined in devices/emulator/x86emu/debug.h and never set in
the emulator files.. any idea why the message is printed at all? 

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From chris at suehsi.de  Sun Apr 30 13:40:22 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 30 Apr 2006 13:40:22 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
Message-ID: <4454A226.3020108@suehsi.de>


> I think an upstream sync or at least a diff with the current emu in
> X.org would be a good idea.  I'ts been on my list of stuff to do.  But
> time, money.. yada yada.
>

I think it is not really hard to include the diff.
I have had a look into the newer code and if I see that right, there are 
not so much changes.

I have also seen, that the LB inTree version differs to the X.org one. 
i.e. the ops2c is much smaller then the orginal.
I think there are many functions, which you have commented out, right?

However, I will try it.
Two file versions later, the ops.c had have a great change, to support 
special VGA Bioses, but I'm not sure if that will help for my problems.

First I will change all diffs to the functions, which are in the intree 
x86emu.

After that I try the new stuff and report what happens :D

chris.

Maybe, we are in luck.
If it will work, I can try to get run the emulator on my epia m.



> --
> Richard A. Smith
> 




From stepan at coresystems.de  Sun Apr 30 12:39:24 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 30 Apr 2006 12:39:24 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4454A226.3020108@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<4454A226.3020108@suehsi.de>
Message-ID: <20060430103923.GA19323@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060430 13:40]:
> I have also seen, that the LB inTree version differs to the X.org one. 
> i.e. the ops2c is much smaller then the orginal.

Yes, someone refactored x86emu a while ago and made it a lot smaller,
so that it would easily fit into a normal size bios together with the
rest of LinuxBIOS and the payload(s)

> I think there are many functions, which you have commented out, right?
 
Only in the int callback emulation. The x86emu part itself is complete.

> However, I will try it.
> Two file versions later, the ops.c had have a great change, to support 
> special VGA Bioses, but I'm not sure if that will help for my problems.
 
Cool! It probably makes sense to use a really old version of
XFree86/X.org and look at the changes rather than diffing the files
1:1..

Stefan.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From hidi at e-tiger.net  Sun Apr 30 14:43:37 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sun, 30 Apr 2006 14:43:37 +0200
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <445433CD.9080308@lanl.gov>
References: <592068803.20060430001151@e-tiger.net> <445433CD.9080308@lanl.gov>
Message-ID: <1085214046.20060430144337@e-tiger.net>

Hello Ronald,

  I'll answer the questions:
    1. Compiled LinuxBIOS for
         Tyan S2882
         2 Opteron processors
         4GByte RAM
         -
         Integrated VGA
         Integrated Sata Silicon images

       This was the first time I've worked with
       LinuxBIOS so I have to get more knowledge about the
       whole code before to be able to develope it. :)

       I've dumped the VGA BIOS ROM what seems to be
       32kbytes based at 0xc0000 (follows the BIOS of
       the two Promise SATA cards), so I've mentioned
       before somewhy it DIDN'T work!! It DIDN't initialized
       the VGA however the linuxbios wrote that message what
       you said it means everything is OK, but it wasn't!
       After all, I got to be crazy about this, I extracted
       it from the AMI BIOS ROM the extracted ROM was 36kbytes!!
       I don't know where was the lost 4kbytes:) After all, with
       this new ROM Video works fine! The message is till the same.
       (I've moved the VIDEO ROM after the payload of the failback
       BIOS because it got crazy if somebody messes up the normal
       bios:)
       -Some minor modifications in the board config...
    2. SVN Snapshoot on 28th of April
    3. Yes, I do now :))

    So I like linuxbios :) It should be fine if almost the all
    functions would work just like with the original AMI BIOS,
    so I'm not familiar with ACPI, but as I deal with electronics
    too it's not a hopeless thing to me to answer this:)
    The first but minor question is that how can we make the
    power button to work:) The other is what are the requirements
    of PowerNow! to work?



Sunday, April 30, 2006, 5:49:33 AM, you wrote:

> Hidasi Jozsef wrote:
>>  IT WORKS! Thanks for you all! :) Just another low priority question:
>>  is there any way to read the status of the power button? I mean it
>>  somebody pushed it?


> we'll only answer that question if you send us a HOWTO and writeup on
> 1. what you did
> 2. what SVN version
> 3. do you have graphics.

> thanks

> ron



-- 
Best regards,
 Hidasi                            mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060430/3a434c92/attachment.sig>

From chris at suehsi.de  Sun Apr 30 16:05:10 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Sun, 30 Apr 2006 16:05:10 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060430103923.GA19323@coresystems.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<4454A226.3020108@suehsi.de>
	<20060430103923.GA19323@coresystems.de>
Message-ID: <4454C416.4040906@suehsi.de>

Stefan Reinauer schrieb:
> * Christian S?hs <chris at suehsi.de> [060430 13:40]:
> 
>>I have also seen, that the LB inTree version differs to the X.org one.


Sorry, I have looked to the xfree86 one :D
but this one has its last update 10 month ago, the X.org version seems 
to be older. (last update 23months)

>  
> Cool! It probably makes sense to use a really old version of
> XFree86/X.org and look at the changes rather than diffing the files
> 1:1..

Yeah, but I can't get a point to start :D I'm not sure what we need.

The inTree stuff based on X.org?

chris

> 
> Stefan.
> 





From rminnich at lanl.gov  Sun Apr 30 17:53:56 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 30 Apr 2006 09:53:56 -0600
Subject: [LinuxBIOS] Support for Asus A7N8X mainboard with nVidia MCP-T
 Southbridge?
In-Reply-To: <1146358102.445409567c764@www.compsoc.nuigalway.ie>
References: <1146358102.445409567c764@www.compsoc.nuigalway.ie>
Message-ID: <4454DD94.8040605@lanl.gov>

you'll need to get nvidia to get you docs for the north.

ron



From yinghailu at gmail.com  Sun Apr 30 18:21:21 2006
From: yinghailu at gmail.com (yhlu)
Date: Sun, 30 Apr 2006 09:21:21 -0700
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <1085214046.20060430144337@e-tiger.net>
References: <592068803.20060430001151@e-tiger.net> <445433CD.9080308@lanl.gov>
	<1085214046.20060430144337@e-tiger.net>
Message-ID: <2ea3fae10604300921h68e77875mcedd0ee1c7caa530@mail.gmail.com>

add acpi support to s2882 should be easy, because serengeti_leopard
already include the acpi support...., and all with amd 8111...

you can compare the two MB, and move some code from serngeti_leopard
to s2882....and test it.

YH



From hidi at e-tiger.net  Sun Apr 30 18:22:57 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sun, 30 Apr 2006 18:22:57 +0200
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <2ea3fae10604300921h68e77875mcedd0ee1c7caa530@mail.gmail.com>
References: <592068803.20060430001151@e-tiger.net> <445433CD.9080308@lanl.gov>
	<1085214046.20060430144337@e-tiger.net>
	<2ea3fae10604300921h68e77875mcedd0ee1c7caa530@mail.gmail.com>
Message-ID: <525286460.20060430182257@e-tiger.net>

Hello yhlu,

That's what I'm doing now:)


Sunday, April 30, 2006, 6:21:21 PM, you wrote:

> add acpi support to s2882 should be easy, because serengeti_leopard
> already include the acpi support...., and all with amd 8111...

> you can compare the two MB, and move some code from serngeti_leopard
> to s2882....and test it.

> YH


-- 
Best regards,
 Hidasi                            mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060430/2d00abe7/attachment.sig>

From hidi at e-tiger.net  Sun Apr 30 18:28:11 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sun, 30 Apr 2006 18:28:11 +0200
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <2ea3fae10604300921h68e77875mcedd0ee1c7caa530@mail.gmail.com>
References: <592068803.20060430001151@e-tiger.net> <445433CD.9080308@lanl.gov>
	<1085214046.20060430144337@e-tiger.net>
	<2ea3fae10604300921h68e77875mcedd0ee1c7caa530@mail.gmail.com>
Message-ID: <1646875161.20060430182811@e-tiger.net>


Where can I download that IASL compiler stuff?


Sunday, April 30, 2006, 6:21:21 PM, you wrote:

> add acpi support to s2882 should be easy, because serengeti_leopard
> already include the acpi support...., and all with amd 8111...

> you can compare the two MB, and move some code from serngeti_leopard
> to s2882....and test it.

> YH


-- 
Best regards,
 Hidasi                            mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060430/5deab737/attachment.sig>

From paul.collomb1 at libertysurf.fr  Sun Apr 30 19:10:06 2006
From: paul.collomb1 at libertysurf.fr (=?iso-8859-1?Q?paul.collomb1@libertysurf.fr?=)
Date: Sun, 30 Apr 2006 19:10:06 +0200
Subject: [LinuxBIOS] =?iso-8859-1?q?Tyan_S2460?=
Message-ID: <IYJP0U$616938D319B081580ECC4FCBE7730AC4@aliceadsl.fr>

Hi, 
do you think if exist a possibility for intall linuxbios on a TYAN S2460 motherboard ? 
Thanks 

-------------- ALICE HAUT DEBIT : TRIPLE PLAY A 29,95 EUR/MOIS -------------- 
D?couvrez vite ALICEBOX : avec le modem WIFI, profitez de l'ADSL, de la TELEPHONIE et en exclusivit? de la TELEVISION ! 
B?n?ficiez aussi de la hotline gratuite 24h/24 ! Soumis ? conditions. Pour en profiter cliquez ici http://abonnement.aliceadsl.fr







From yinghailu at gmail.com  Sun Apr 30 20:24:08 2006
From: yinghailu at gmail.com (yhlu)
Date: Sun, 30 Apr 2006 11:24:08 -0700
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <1646875161.20060430182811@e-tiger.net>
References: <592068803.20060430001151@e-tiger.net> <445433CD.9080308@lanl.gov>
	<1085214046.20060430144337@e-tiger.net>
	<2ea3fae10604300921h68e77875mcedd0ee1c7caa530@mail.gmail.com>
	<1646875161.20060430182811@e-tiger.net>
Message-ID: <2ea3fae10604301124n1c1a0f53yba734c1ab4752f08@mail.gmail.com>

what is your Linux dist...? If it is suse, you can install the package
from the source disk...

YH



From smithbone at gmail.com  Sun Apr 30 22:03:28 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 30 Apr 2006 15:03:28 -0500
Subject: [LinuxBIOS] Epia ML 5000 VGA (Again!) -- Moving backwards,
	somehow.
In-Reply-To: <44544DE9.1050701@zyxod.com>
References: <44544DE9.1050701@zyxod.com>
Message-ID: <8a0c36780604301303r3b6fd10eta4c5955acbef2ae1@mail.gmail.com>

> Mysteriously, my "weird boot crashes that are fixed by factory CMOS"
> problems aren't exhibiting themselves.
>
> Unfortunately, I cannot run memtest86 under LB without VGA.
>

You can recompile memtest86 to use the serial port rather than VGA.


--
Richard A. Smith



From smithbone at gmail.com  Sun Apr 30 22:07:13 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 30 Apr 2006 15:07:13 -0500
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <e31mo9$2bj$1@sea.gmane.org>
References: <e30v1u$d74$1@sea.gmane.org> <4454342B.3080107@lanl.gov>
	<e31mo9$2bj$1@sea.gmane.org>
Message-ID: <8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>

On 4/30/06, Alex L. Mauer <hawke at hawkesnest.net> wrote:

> Ronald G Minnich wrote:
> > nobody has had time to fix it, and we've had no requests. Some commit
> > busted it when people tried to upgrade it for later EPIAs -- sorry.
>
> Well, that's OK -- it's free software after all.  But I guess this could
> be considered to be a request, then.  If/when someone gets the time,
> even updating the status to indicate that it doesn't work would be nice;
> fixing/creating the VGA support would be much appreciated as well.

What happens wne you boot with the current version?
Don't try any  vga just do serial to start with.



From hidi at e-tiger.net  Sun Apr 30 22:09:55 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Sun, 30 Apr 2006 22:09:55 +0200
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <2ea3fae10604301124n1c1a0f53yba734c1ab4752f08@mail.gmail.com>
References: <592068803.20060430001151@e-tiger.net> <445433CD.9080308@lanl.gov>
	<1085214046.20060430144337@e-tiger.net>
	<2ea3fae10604300921h68e77875mcedd0ee1c7caa530@mail.gmail.com>
	<1646875161.20060430182811@e-tiger.net>
	<2ea3fae10604301124n1c1a0f53yba734c1ab4752f08@mail.gmail.com>
Message-ID: <386809661.20060430220955@e-tiger.net>

Hi!

/usr/sbin/iasl -tc /src/LinuxBIOSv2/src/mainboard/tyan/s2882/dx/pci2.asl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20060421 [Apr 30 2006]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

Segmentation fault


any suggestions?



Sunday, April 30, 2006, 8:24:08 PM, you wrote:

> what is your Linux dist...? If it is suse, you can install the package
> from the source disk...

> YH



-- 
Best regards,
 Hidasi                            mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060430/d231af9c/attachment.sig>

From smithbone at gmail.com  Sun Apr 30 23:19:26 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 30 Apr 2006 16:19:26 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4454C416.4040906@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<4454A226.3020108@suehsi.de> <20060430103923.GA19323@coresystems.de>
	<4454C416.4040906@suehsi.de>
Message-ID: <8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>

> > Cool! It probably makes sense to use a really old version of
> > XFree86/X.org and look at the changes rather than diffing the files
> > 1:1..
>
> Yeah, but I can't get a point to start :D I'm not sure what we need.

Now you know why I haven't done it yet.  Its a little more than just a
diff of the trees.

> The inTree stuff based on X.org?

The in-tree stuf is based on the ./util/vgabios stuff which came from
xfree86 long ago.  The X.org fork should not be that much different
than the xfree86 stuff.  The stuff in-tree has the directory structure
cleaned up so its more sane.

Rather than diff the in-tree to the X.org or xfree86 I would start by
diffing the stuff in util/vgabios/x86emu first.  That will let you see
what has been introduced into the X* stuff.  I would then fork a copy
of vgabios and test all the updates.  Then when you understand what
changes were made you can try to roll them into the in-tree.

Speak of all this my question still stand about IO to the timer.   Is
this intercepted or bare metal?     From what I see all IO is passed
directly on to the hardware.

In V1 I had a vga bios that did not do very well with the large jump
in timer reads caused by the emulator.  It made the delay routine sit
and spin for long periods of time.  I had the source to the bios so I
was able to fix it there rather than in the emulator.

The symptoms were similar to what Chris is seeing.

Chris, please disable all your current emu debug stuff and then apply
this patch and send the output.
This should show the timer IO accesses but not  all the other stuff to
keep the noise level down.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: show_timer_io.patch
Type: text/x-diff
Size: 996 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060430/f3c0214f/attachment.bin>

From lists at seicento.selfip.org  Sun Apr 30 23:29:31 2006
From: lists at seicento.selfip.org (lists at seicento.selfip.org)
Date: Sun, 30 Apr 2006 23:29:31 +0200 (CEST)
Subject: [LinuxBIOS] newbi questions for VIA EPIS MII6000E target
Message-ID: <Pine.LNX.4.63.0604302309070.5800@web.seicento.selfip.org>

Hi all ... I'm about to make my first attempt to boot my MII6000E from the 
onboard CF adapter so pleas forgive my possibly stupid questions.

I have a few questions regarding this:
VIA's fartboot firmware tells me that it's mandatory to use mkelfImage on 
bothe kernel and initrd, is this also true for linuxBIOS ?
Even if vga bios is copied over from original flash will video be blank 
untill kernel initializes the video card or will it be possible to see the 
tipical "loading linux ......" and consequent tipical kernel messages on 
video ?
If the latter is possible would I need to avoid passing console to be 
serial amongst the kernel options ?
According to documentation on the linuxBIOS home
http://www.linuxbios.org/index.php/Payloads
the etherboot payload has bothe ide and net boot capabilities ... will 
this let me boot from the onboard CF adapter ?
What adjustments must I make to the EPIA-M-howto documentation to use the 
etherboot payload ?

Regards
David