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
-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
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
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
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
-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
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
-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
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
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
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
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.
-- Richard A. Smith
* Richard Smith smithbone@gmail.com [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
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 smithbone@gmail.com [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
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
On Thu, 19 Jan 2006 16:07:33 -0700 Ronald G Minnich rminnich@lanl.gov 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.
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 a.borisov@tesv.tmb.ru wrote:
On Thu, 19 Jan 2006 16:07:33 -0700 Ronald G Minnich rminnich@lanl.gov 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.
-- Sincerely, Anton Borisov
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
On 1/24/06, ron minnich rminnich@gmail.com 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.
-- Richard A. Smith