[LinuxBIOS] one last note

[Ronald G Minnich]

if anyone out there has a copy of a version of the  v2 repo that can 
build a working via epia, hopefully recent, I'm willing to work with that.

Current problem, btw, is that the via epia samuel 2 cpu hangs up in the 
mtrr init code. I suspect someone updated that, for -m or -m2,  in such 
a way that it broke older cpus.

if I comment out mtrr init, i.e.

Index: src/cpu/via/model_centaur/model_centaur_init.c
===================================================================
--- src/cpu/via/model_centaur/model_centaur_init.c      (revision 2158)
+++ src/cpu/via/model_centaur/model_centaur_init.c      (working copy)
@@ -15,7 +15,7 @@
  {
         /* Turn on caching if we haven't already */
         x86_enable_cache();
-       x86_setup_mtrrs(36);
+//     x86_setup_mtrrs(36);
         x86_mtrr_check();

/* Enable the local cpu apics */

then it will come up -- with no working cache. And the enet problem then 
occurs.

I could use some help and perspetive here. I know some of you have epias 
-- could you take a look?

But I have other, newer things to do, and fixing an old CPU just can not 
take priority. Sorry.

ron

[Adam Talbot]

-Ron
LinuxBIOSv2-2158 can compile the epia, but I do not know it it boots, 
have no such board to test on. If this helps any, here is my tree. The 
epia-m does not compile.
http://www.batbuilds.com/webfolders/LinuxBIOSv2-2158.tar.bz2
-Adam

Ronald G Minnich wrote:
> if anyone out there has a copy of a version of the  v2 repo that can 
> build a working via epia, hopefully recent, I'm willing to work with that.
>
> Current problem, btw, is that the via epia samuel 2 cpu hangs up in the 
> mtrr init code. I suspect someone updated that, for -m or -m2,  in such 
> a way that it broke older cpus.
>
> if I comment out mtrr init, i.e.
> Index: src/cpu/via/model_centaur/model_centaur_init.c
>
> --- src/cpu/via/model_centaur/model_centaur_init.c      (revision 2158)
> +++ src/cpu/via/model_centaur/model_centaur_init.c      (working copy)
> @@ -15,7 +15,7 @@
>  {
>         /* Turn on caching if we haven't already */
>         x86_enable_cache();
>   x86_setup_mtrrs(36);
>
> +//     x86_setup_mtrrs(36);
>         x86_mtrr_check();
>     /* Enable the local cpu apics */
>
> then it will come up -- with no working cache. And the enet problem then 
> occurs.
>
> I could use some help and perspetive here. I know some of you have epias 
> -- could you take a look?
>
> But I have other, newer things to do, and fixing an old CPU just can not 
> take priority. Sorry.
>
> ron

[Ronald G Minnich]

Thanks, adam!

if this works, I've got a starting point.

BTW, anyone out there interested in GX2? We're starting work this week, 
actually meaning Hamish is going to show us how it's done :-)

ron

[Adam Talbot]

Currently trying to port the EBC3410, but if I could find a small GX2 
board for a good price I would switch. My project is all about boot time 
and that built in DDR memory controler REALY speeds things up.
My current board.
http://www.bcmcom.com/bcm_product_ebc3410.htm
-Adam Talbot
P.S.  irq table fixed, thank you.

Ronald G Minnich wrote:
> Thanks, adam!
>
> if this works, I've got a starting point.
>
> BTW, anyone out there interested in GX2? We're starting work this 
> week, actually meaning Hamish is going to show us how it's done :-)
>
> ron

[Ronald G Minnich]

Adam Talbot wrote:
> Currently trying to port the EBC3410, but if I could find a small GX2 
> board for a good price I would switch. My project is all about boot time 
> and that built in DDR memory controler REALY speeds things up.
> My current board.
> http://www.bcmcom.com/bcm_product_ebc3410.htm

Adam, if you do this port, it will help gx2.

What are you doing about the VSA stuff?

The geode has some real IP baggage .... I'm trying to talk to AMD about 
this, as it dates back to the NSC days. If we go with Geode, and we want 
(e.g.) VGA, we're going to have a huge binary blob of proprietary code 
in the middle of linuxbios. Hmm, not that much different than VGA, eh? 
But, you get the big blob from these guys: 
http://www.insydetech.com/productcenter/amd/geodesite/index.cfm

i.e., a proprietary BIOS vendor seems to be the control point for the 
AMD geode code, although the code seems to be freely available in some 
form or another. This is kind of weird. I don't quite know why it is 
done this way.

ron

[Adam Talbot]

-Ron
To day I will sound like a n00b.  VSA?
-Adam

Ronald G Minnich wrote:
> Adam Talbot wrote:
> > Currently trying to port the EBC3410, but if I could find a small GX2 
> > board for a good price I would switch. My project is all about boot 
> > time and that built in DDR memory controler REALY speeds things up.
> > My current board.
> > http://www.bcmcom.com/bcm_product_ebc3410.htm
>
> Adam, if you do this port, it will help gx2.
>
> What are you doing about the VSA stuff?
>
> The geode has some real IP baggage .... I'm trying to talk to AMD 
> about this, as it dates back to the NSC days. If we go with Geode, and 
> we want (e.g.) VGA, we're going to have a huge binary blob of 
> proprietary code in the middle of linuxbios. Hmm, not that much 
> different than VGA, eh? But, you get the big blob from these guys: 
> http://www.insydetech.com/productcenter/amd/geodesite/index.cfm
>
> i.e., a proprietary BIOS vendor seems to be the control point for the 
> AMD geode code, although the code seems to be freely available in some 
> form or another. This is kind of weird. I don't quite know why it is 
> done this way.
>
> ron

[Ronald G Minnich]

Adam Talbot wrote:
> -Ron
> To day I will sound like a n00b.  VSA?

A strange piece of software that is installed and acts like hardware -- 
certain ops trap to it, I think.

really odd. I can't find a good writeup on it, since it is mostly 
proprietary.

ron

[Adam Talbot]

-Ron
Well, I just got my code compiling.  But I have nothing on the console.  
What settings/files would you advise I check. Serial debug is set at 9, 
but I am seeing nothing. Ideas?
-Adam

Ronald G Minnich wrote:
> Adam Talbot wrote:
> > -Ron
> > To day I will sound like a n00b.  VSA?
>
> A strange piece of software that is installed and acts like hardware 
> -- certain ops trap to it, I think.
>
> really odd. I can't find a good writeup on it, since it is mostly 
> proprietary.
>
> ron

[Ronald G Minnich]

Adam Talbot wrote:
> -Ron
> Well, I just got my code compiling.  But I have nothing on the console.  
> What settings/files would you advise I check. Serial debug is set at 9, 
> but I am seeing nothing. Ideas?

First step: boot fuctory bios and make sure minicom works for you. Check 
settings on the chips under fuctory bios.

do you have a post card?

Beep won't work, I think, since no VSA in there yet.

do you have a POST card?

ron

[Peter Stuge]

On Sun, Jan 22, 2006 at 11:04:43PM -0700, Ronald G Minnich wrote:
> Beep won't work, I think, since no VSA in there yet.

^G doesn't work but programming PIT2 to make some sound should work.
> do you have a POST card?

Definately the way to go, unless you have a logic analyzer nearby.

//Peter

[Peter Stuge]

On Sun, Jan 22, 2006 at 09:40:27PM -0700, Ronald G Minnich wrote:
> Adam Talbot wrote:
> > -Ron
> > To day I will sound like a n00b.  VSA?
>
> A strange piece of software that is installed and acts like hardware
> -- certain ops trap to it, I think.
>
> really odd. I can't find a good writeup on it, since it is mostly 
> proprietary.

VSA=Virtual System Architecture
VSM=VSA module

The BIOS inits VSA and all available VSMs. A VSM claims IO or int
resources.

VSA uses SMM to run VSMs when the OS accesses those resources.
(outb(xx,0x220) in kernel -> smint -> dispatched to audio VSM)

NSC had two documents describing it:
"VSA/BIOS Porting Guide"
and
"Virtual System Architecture BIOS Porting Guide"

Don't ask how they differ, I don't remember.

//Peter

[Richard Smith]

> BTW, anyone out there interested in GX2? We're starting work this week,
> actually meaning Hamish is going to show us how it's done :-)

Bitworks has been interested in using the GX2 as a replacement for our
STPC based stuff.  However its faceing _strong_ competition from the
newer 32 bit ARM micros we are also playing with.  The ARMS are
cheaper, they boot (a kernel) in a hearbeat, no legacy bios crap and
one test shows that even with software float emulation the performance
for our apps is just as good as the STPC.

The GX2 of course would be a much higher performance part but we
aren't quite convinced we need that yet.

I really dislike the thought of dealing with all that VSA crap.

[Stefan Reinauer]

* Richard Smith  [060123 14:29]:
> The GX2 of course would be a much higher performance part but we
> aren't quite convinced we need that yet.
>
> I really dislike the thought of dealing with all that VSA crap.

We should remember there was a VSA implementation floating around
lately that has not been approved by AMD yet.

The question is whether a VSA loader helps any since it probably won't
allow us to put VSA modules in our source tree anyways. Are those
modules owned by legacy bios vendors, similar to ACPI?

Stefan

[Hamish Guthrie]

Just to clarify how the VSA stuff works - I am using it sucessfully with 
GX1 and the code for GX2 is very similar.

Firstly, the VSA code is supplied in binary form only, and the code is 
owned by AMD, and AMD are quite happy for this to be included with a 
LinuxBIOS implementation (this has been cleared with them). Also, the 
VGA BIOS written by Elpin systems can be used royalty free on the Geode 
processors (also been cleared with AMD).

The issue is that each VSA module (there are a number of them), has 
real-mode initialization code which has to be called in real mode (well 
it is actually best to do it in flat mode), but it is 16-bit code. Also, 
the VGA BIOS REQUIRES that the VGA VSA module is loaded. Also, the 
framebuffer driver and the X drivers use calls to the VGA BIOS, so to 
get all of that stuff running without the VSA is a no-no.

As a dirty hack I have done an implementation for the GX1 which uses a 
thing called Xpress Loader - this is loader code which basically gets 
all the hardware running - detects RAM and loads all of the VSA modules. 
Xpress Loader was written by National Semiconductor and now belongs to 
AMD, and is provided free of charge to anyone who wants to use it. This 
has also been cleared with AMD.

All I have then done is to create a stripped down version of LinuxBIOS 
in the V2 tree which skips all of the low-level init, does the PCI 
enumerations etc., and then uses whatever loader you want to load the 
kernel and boot into Linux.

The boot process is therefore as follows:

Initial boot vectors to the modified Xpress Loader code.
Xpress loader inits RAM, a couple of other bits and pieces, installs the 
VSA modules, initializes the VSA modules, installs the VGA bios, and 
enters text mode.
Finally Xpress Loader vectors to the stripped down LinuxBIOS which 
switches into protected mode and then does it's magic.

Hamish

Stefan Reinauer wrote:
> Richard Smith  [060123 14:29]:
> > The GX2 of course would be a much higher performance part but we
> > aren't quite convinced we need that yet.
> >
> > I really dislike the thought of dealing with all that VSA crap.
>
> We should remember there was a VSA implementation floating around
> lately that has not been approved by AMD yet.
>
> The question is whether a VSA loader helps any since it probably won't
> allow us to put VSA modules in our source tree anyways. Are those
> modules owned by legacy bios vendors, similar to ACPI?
>
> Stefan

[Ronald G Minnich]

Can someone out there please confirm that epia-m works for them, with 
verison 2100, and see if it works with the latest?

thanks

ron

[LinuxBIOS] one last note for epia

[Anton Borisov]

On Thu, 19 Jan 2006 16:07:33 -0700
Ronald G Minnich  wrote:
> if anyone out there has a copy of a version of the  v2 repo that can 
> build a working via epia, hopefully recent, I'm willing to work with that.
>
> Current problem, btw, is that the via epia samuel 2 cpu hangs up in the 
> mtrr init code. I suspect someone updated that, for -m or -m2,  in such 
> a way that it broke older cpus.

Ron, my board is epia-m 10k. cpuid = 0x695. It works fine with v2080 (Barker's patch applied). And it perfectly
boots and does poweroffs with v2161 and v2163. So I see no problems with that.

[LinuxBIOS] one last note for epia

[ron minnich]

So you have vga and all the other features as well? What board vendor/model
is this? I'd like to put it on the web page.

thanks

ron

On 1/23/06, Anton Borisov  wrote:
> On Thu, 19 Jan 2006 16:07:33 -0700
> Ronald G Minnich  wrote:
> > if anyone out there has a copy of a version of the  v2 repo that can
> > build a working via epia, hopefully recent, I'm willing to work with
>
> that.
> > Current problem, btw, is that the via epia samuel 2 cpu hangs up in the
> > mtrr init code. I suspect someone updated that, for -m or -m2,  in such
> > a way that it broke older cpus.
>
> Ron, my board is epia-m 10k. cpuid = 0x695. It works fine with v2080
> (Barker's patch applied). And it perfectly
> boots and does poweroffs with v2161 and v2163. So I see no problems with
> that.

[LinuxBIOS] one last note for epia

[Richard Smith]

On 1/24/06, ron minnich  wrote:
> So you have vga and all the other features as well? What board vendor/model
> is this? I'd like to put it on the web page.

Anton,

I thought you had to make some changes that were not compatible with
the epia m tree as it stands.  The action stefan and I thought best
was to create a new mainboard directory.  I don't believe thats
happened yet.

We probally want to get this all fixed up before any success reports
show up on the webpage or we will just have to deal with a lot of
failure reports on the list.

IIRC the issues were that your board does not have a device that the
current tree probes for and this caused a long delay in booting as the
code loops through looking for all devices on all busses.  Then there
was some VGA wierdness that I think was solved by write protecting the
legacy VGA bios range.