hate to be clogging up the list but memcpy works!! It looks like the VT8622/8623/8635 all have the same way of dealing with this shadow copy stuff. After losing a couple of hours sleep, I've hit another snag here (partial log):
==================================== setting pci slot setting vt8235 slot Assigning IRQ 5 to 0:11.1 Readback = 5 Assigning IRQ 12 to 0:11.5 Readback = 12 INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1106, did=3122 Setting up VGA, VGABIOS_START: 0xfffc0000 write_protect_vgabios Looks like VGA_ROM is good: 0x55 0xaa VGA copy looks good bus/devfn = 0x100 biosint: # 0x15, eax 0x5f00 ebx 0x100 ecx 0x100 edx 0x12 biosint: ebp 0x138dc esp 0xff2 edi 0xf934 esi 0x141f8 biosint: ip 0x637f cs 0xc000 flags 0x46 calling handleint21() done with handleint21() returning from biosint()...ret=-1 biosint: # 0x1a, eax 0xb108 ebx 0x0 ecx 0x0 edx 0x3d5 biosint: ebp 0x138dc esp 0xfcc edi 0xf6 esi 0x155eb biosint: ip 0x40da cs 0xc000 flags 0x46 calling pcibios() 0xb108: bus 0 devfn 0x0 reg 0xf6 val 0x3 done with pcibios() returning from biosint()...ret=0 =================================================
I've tried to put some debugging outputs but the system just grinds to a halt after the second call to biosint(). It's now my belief that directly manipulating the registers on the Apollo CLE266 northbridge might yield better results for the epia M. VIA doesn't seem inclined to give out the datasheets or source code, as the posts on viaarena indicate. I wonder if looking at the linux driver patches for kernel 2.4 and greater might offer some clues. Any help would be greatly appreciated!
ok, I hate to say this, but I think you should run linuxbios without the vga stuff, boot linux, and run that vgabios under testbios and see if that is better. This will let you know if the vgabios is doing something really weird.
ron
Ronald G. Minnich wrote:
ok, I hate to say this, but I think you should run linuxbios without the vga stuff, boot linux, and run that vgabios under testbios and see if that is better. This will let you know if the vgabios is doing something really weird.
If you have the space. Try X >= 4.3 as well and use: option "InitPrimary" "true" in the Screens section. It's my experience that on some cards X will bring the card to life when testbios won't.
* Richard Smith rsmith@bitworks.com [040908 17:28]:
Ronald G. Minnich wrote:
ok, I hate to say this, but I think you should run linuxbios without the vga stuff, boot linux, and run that vgabios under testbios and see if that is better. This will let you know if the vgabios is doing something really weird.
If you have the space. Try X >= 4.3 as well and use: option "InitPrimary" "true" in the Screens section. It's my experience that on some cards X will bring the card to life when testbios won't.
We should definitely merge our x86emu efforts with those of X.org. I talked about that with Egbert Eich a while ago, but I never got to set something up since then yet. It might take some efforts cleaning out the core of x86emu so that it smoothly fits into both X and our "testbios" payload. But it is definitely worth the effort.
Stefan
On Thu, 2004-09-09 at 01:50, Stefan Reinauer wrote:
- Richard Smith rsmith@bitworks.com [040908 17:28]:
Ronald G. Minnich wrote:
ok, I hate to say this, but I think you should run linuxbios without the vga stuff, boot linux, and run that vgabios under testbios and see if that is better. This will let you know if the vgabios is doing something really weird.
If you have the space. Try X >= 4.3 as well and use: option "InitPrimary" "true" in the Screens section. It's my experience that on some cards X will bring the card to life when testbios won't.
We should definitely merge our x86emu efforts with those of X.org. I talked about that with Egbert Eich a while ago, but I never got to set something up since then yet. It might take some efforts cleaning out the core of x86emu so that it smoothly fits into both X and our "testbios" payload. But it is definitely worth the effort.
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
BTW, I think a fork of x86emu is inevitable. If we want to move testbios into LinuxBIOS, we have to remove all OS/libc dependence from the emulator.
Ollie
Li-Ta Lo wrote:
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
Something is differnt even with 4.3. I can run my ATI M1 bios under testbios and it dosen't work but X with InitPrimary enabled works.
BTW, I think a fork of x86emu is inevitable. If we want to move testbios into LinuxBIOS, we have to remove all OS/libc dependence from the emulator.
There is also a softboot program for the DRI project. I tried to mess with it but it currently requires devmapper to do the ROM mapping it didn't want to work for me.
Hello from Gregg C Levine Richard your statement, "There is also a softboot program for the DRI project. I tried to mess with it but it currently requires devmapper to do the ROM mapping it didn't want to work for me."
It sounds interesting to me, here, but I only have access to the ATI Mach64 based, Rage Pro 3D, video, on one of my machines, and the ATI Rage 128 video, on this one. Can you elaborate? ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios- admin@clustermatic.org] On Behalf Of Richard Smith Sent: Thursday, September 09, 2004 1:09 PM To: ollie@lanl.gov Cc: Stefan Reinauer; rminnich@lanl.gov; Trellix78@aol.com;
LinuxBIOS;
eich@suse.de Subject: Re: epia m vga + memcpy update
Li-Ta Lo wrote:
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
Something is differnt even with 4.3. I can run my ATI M1 bios under testbios and it dosen't work but X with InitPrimary enabled works.
BTW, I think a fork of x86emu is inevitable. If we want to move testbios into LinuxBIOS, we have to remove all OS/libc dependence from the emulator.
There is also a softboot program for the DRI project. I tried to
mess
with it but it currently requires devmapper to do the ROM mapping it didn't want to work for me.
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Thu, 2004-09-09 at 11:08, Richard Smith wrote:
Li-Ta Lo wrote:
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
Something is differnt even with 4.3. I can run my ATI M1 bios under testbios and it dosen't work but X with InitPrimary enabled works.
Interesting. Do you have any idea why ?
Ollie
Li-Ta Lo wrote:
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
Something is differnt even with 4.3. I can run my ATI M1 bios under testbios and it dosen't work but X with InitPrimary enabled works.
Interesting. Do you have any idea why ?
Not really. There's lots of variables. I do have machines that testbios does work with my M1 bios. But these machines boot a COTS bios rather than LB.
For one thing I think the emu in X handles the reads and writes to the timer rather than letting the bios get to the hardware. The stock M1 bios won't run under vgabios at all. The delay functions go into loops that only exit by chance. The X emu will run that code fine.
I have a modified version of the M1 bios that works around the delay issue by effectively removing them so it runs under testbios but it still dosen't bring the card to life. Its possible that my "fix" is part of the problem since timeing can be critical but I wouldn't expect the emulator to running too fast and I don't think too slow would be a problem.
Gregg C Levine wrote:
It sounds interesting to me, here, but I only have access to the ATI Mach64 based, Rage Pro 3D, video, on one of my machines, and the ATI Rage 128 video, on this one. Can you elaborate?
I got the code from a something that came across the fremebuffer dev list. But it should all be in the DRI cvs. check http://dri.sourceforge.net for all the details.
On Thu, 2004-09-09 at 11:58, Richard Smith wrote:
Li-Ta Lo wrote:
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
Something is differnt even with 4.3. I can run my ATI M1 bios under testbios and it dosen't work but X with InitPrimary enabled works.
Interesting. Do you have any idea why ?
Not really. There's lots of variables. I do have machines that testbios does work with my M1 bios. But these machines boot a COTS bios rather than LB.
For one thing I think the emu in X handles the reads and writes to the timer rather than letting the bios get to the hardware. The stock M1 bios won't run under vgabios at all. The delay functions go into loops that only exit by chance. The X emu will run that code fine.
I have a modified version of the M1 bios that works around the delay issue by effectively removing them so it runs under testbios but it still dosen't bring the card to life. Its possible that my "fix" is part of the problem since timeing can be critical but I wouldn't expect the emulator to running too fast and I don't think too slow would be a problem.
So you still think it is the timer ? Did you try to access the timer HW in testbios ?
Ollie
Li-Ta Lo wrote:
So you still think it is the timer ?
It may not be the only problem. But its one problem. The flaky results I get seem to match up with wierd timeing problems.
I haven't allocated a lot of time on this because we have found that our board has hardware problems with the pci bus. And it's difficult to seperate out all the individual issues.
But testbios dosen't work on an ASUS P2B booting LB or COTS and my modified ATI vbios. Nor does LB+ADLO+BOCHS with the original M1 vbios. X with InitPrimary works both under COTS and LB but that was using using the orginal M1 bios not my "fixed" version.
So see I still have a lot of apples->oranges comparisons. I'll try to scratch out sometime and build a consistent maxrix of everything that works and what dosen't.
This is where having that PCI expansion ROM stuff working would come in _real_ handy.
Did you try to access the timer HW in testbios ?
I think HW access is what you _don't_ want to happen. Rather than allow the vbios to fiddle with the actuall timer hw it needs to provide a software legacy timer interface that increments consistent with the emu "clock". The only hardware IO that should be allowed untrapped is the IO range requested by the card and the Legacy VGA ranges. Currently testbios lets the vbios access any port it wishes. The X emu must be doing this or the ATI M1 bios would not work.
This has to happen for non-x86 platform stuff as well which don't even have a x86 type timer.
On Thu, 2004-09-09 at 12:58, Richard Smith wrote:
Li-Ta Lo wrote:
So you still think it is the timer ?
It may not be the only problem. But its one problem. The flaky results I get seem to match up with wierd timeing problems.
I haven't allocated a lot of time on this because we have found that our board has hardware problems with the pci bus. And it's difficult to seperate out all the individual issues.
But testbios dosen't work on an ASUS P2B booting LB or COTS and my modified ATI vbios. Nor does LB+ADLO+BOCHS with the original M1 vbios. X with InitPrimary works both under COTS and LB but that was using using the orginal M1 bios not my "fixed" version.
So see I still have a lot of apples->oranges comparisons. I'll try to scratch out sometime and build a consistent maxrix of everything that works and what dosen't.
This is where having that PCI expansion ROM stuff working would come in _real_ handy.
Did you try to access the timer HW in testbios ?
I think HW access is what you _don't_ want to happen. Rather than allow the vbios to fiddle with the actuall timer hw it needs to provide a software legacy timer interface that increments consistent with the emu "clock". The only hardware IO that should be allowed untrapped is the IO range requested by the card and the Legacy VGA ranges. Currently testbios lets the vbios access any port it wishes. The X emu must be doing this or the ATI M1 bios would not work.
Do you mean the InitPrimary thing has software emulation for the timer ?
Ollie
Li-Ta Lo wrote:
"clock". The only hardware IO that should be allowed untrapped is the IO range requested by the card and the Legacy VGA ranges. Currently testbios lets the vbios access any port it wishes. The X emu must be doing this or the ATI M1 bios would not work.
Do you mean the InitPrimary thing has software emulation for the timer ?
By default X only softboots secondary display adapters. If you specifiy Option "InitPrimary" "true" in the Screens section it will try to softboot the card even if its the primary display. So when I say with InitPrimary I mean using X 4.3's emu.
* Li-Ta Lo ollie@lanl.gov [040909 18:26]:
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
Yes. But not only the x86 emulation itself is interesting, but also the legacy bios emulation around it. There are so many branches and forks out there, we _have_ to do something to unite them, otherwise we cannot reach our goal in this area. Nobody knows what the others are really doing.
I am going to set up an GNU Arch repository on openbios.org asap so we can set a starting point for development.
We need some clarification on what parts belong in this repository, and which ones don't. Like, where do the PCI access functions go, logically, in this picture?
Stefan
On Mon, 2004-09-13 at 06:26, Stefan Reinauer wrote:
- Li-Ta Lo ollie@lanl.gov [040909 18:26]:
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
Yes. But not only the x86 emulation itself is interesting, but also the legacy bios emulation around it. There are so many branches and forks out there, we _have_ to do something to unite them, otherwise we cannot reach our goal in this area. Nobody knows what the others are really doing.
I am going to set up an GNU Arch repository on openbios.org asap so we can set a starting point for development.
We need some clarification on what parts belong in this repository, and which ones don't. Like, where do the PCI access functions go, logically, in this picture?
Why do we need PCI access function in the emulator ? If the BIOS wants to access PCI CS, it jsut do it by itself. If you are talking about the int 0x1A emulation, it should be in the "helper functions" as the IO/MEM access routines. So the x86emu should be seperated in two parts, one is the core x86 instruction emulation/virtual machine and other is the IO/MEM/INT support functions.
Ollie
On Mon, 2004-09-13 at 06:26, Stefan Reinauer wrote:
- Li-Ta Lo ollie@lanl.gov [040909 18:26]:
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
Yes. But not only the x86 emulation itself is interesting, but also the legacy bios emulation around it. There are so many branches and forks out there, we _have_ to do something to unite them, otherwise we cannot reach our goal in this area. Nobody knows what the others are really doing.
Do you have a list of people who is doing things on x86emu ? I only one I found the the old scitech ftp and XF86 distribution.
Ollie
Stefan Reinauer wrote:
- Li-Ta Lo ollie@lanl.gov [040909 18:26]:
Did they do anything on the "core" x86emu? Last time I checked, XF86 4.4.0 has almost the same x86emu as testbios.
Yes. But not only the x86 emulation itself is interesting, but also the legacy bios emulation around it. There are so many branches and forks
This is probally where the difference matters most for things like vbios. support of the legacy bios calls. VGA card bioses are really fragile. One wrong return value and its off the trolly or hung in some sort of loop.
out there, we _have_ to do something to unite them, otherwise we cannot reach our goal in this area. Nobody knows what the others are really doing.
I am going to set up an GNU Arch repository on openbios.org asap so we can set a starting point for development.
Cool. I'm going to route this info back to Jon Smirl who seems to be in charge of the DRI x86emu stuff hopefully he can merge in any improvements from his stuff.
* Li-Ta Lo ollie@lanl.gov [040913 17:29]:
Do you have a list of people who is doing things on x86emu ? I only one I found the the old scitech ftp and XF86 distribution.
Another one is Milo, the Alpha Linux Bootloader..
Stefan
On Mon, 2004-09-13 at 13:14, Stefan Reinauer wrote:
- Li-Ta Lo ollie@lanl.gov [040913 17:29]:
Do you have a list of people who is doing things on x86emu ? I only one I found the the old scitech ftp and XF86 distribution.
Another one is Milo, the Alpha Linux Bootloader..
Is there anyone still working on that ? I thought Alpha is dead now.
Ollie
* Li-Ta Lo ollie@lanl.gov [040913 21:35]:
Another one is Milo, the Alpha Linux Bootloader..
Is there anyone still working on that ? I thought Alpha is dead now.
Ollie
Not really.. the last couple of years only me and Jay Estabrook were working on Milo anyways. It is a big nasty bunch of code that noone really wants to touch. I still have the plans to use the last few code snippets that are usable to get OpenBIOS as a simple bootloader for AlphaBIOS/ARCS based machines. Like, the PAL code and some early init should still be usable, all kernel linkage must be removed. No idea whether I will actually get to do this before everybody stopped using these machines though ;) My own Alpha machine is SRM based, so I have no immediate pressure or testing possibilities anyways.
Stefan
Hello from Gregg C Levine Funny you should be bringing that up now. HP is holding a road show on the state of the art as applied to the Alpha, and relatives, here in NYC, tomorrow Wednesday the 15.
They have already told me, that the EV7z processors will stay active at least until something runs out. Figure about the next ten years. The original blue Alphas, are supported, I mean you can call them and ask for support for parts, and manuals, but that's it. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios- admin@clustermatic.org] On Behalf Of Stefan Reinauer Sent: Tuesday, September 14, 2004 3:14 AM To: Li-Ta Lo Cc: Richard Smith; rminnich@lanl.gov; Trellix78@aol.com; LinuxBIOS; eich@suse.de Subject: Re: epia m vga + memcpy update
- Li-Ta Lo ollie@lanl.gov [040913 21:35]:
Another one is Milo, the Alpha Linux Bootloader..
Is there anyone still working on that ? I thought Alpha is dead
now.
Ollie
Not really.. the last couple of years only me and Jay Estabrook were working on Milo anyways. It is a big nasty bunch of code that noone really wants to touch. I still have the plans to use the last few code snippets that are
usable
to get OpenBIOS as a simple bootloader for AlphaBIOS/ARCS based machines. Like, the PAL code and some early init should still be
usable,
all kernel linkage must be removed. No idea whether I will actually get to do this before everybody
stopped
using these machines though ;) My own Alpha machine is SRM based, so I have no immediate pressure
or
testing possibilities anyways.
Stefan
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Tue, 14 Sep 2004, Stefan Reinauer wrote:
Not really.. the last couple of years only me and Jay Estabrook were working on Milo anyways. It is a big nasty bunch of code that noone really wants to touch.
sound as if you were talking about BOCHS BIOS :-)
* Adam Sulmicki adam@cfar.umd.edu [040914 20:22]:
On Tue, 14 Sep 2004, Stefan Reinauer wrote:
Not really.. the last couple of years only me and Jay Estabrook were working on Milo anyways. It is a big nasty bunch of code that noone really wants to touch.
sound as if you were talking about BOCHS BIOS :-)
It's about 200 kloc linking against a couple of million lines of linux kernel code.. bochs bios is nasty, but I think Milo exceeds this. Which is the main reason I stopped updating it.. building it with recent compilers and recent kernels would require a major rewrite of some parts
Stefan
Stefan Reinauer wrote:
- Adam Sulmicki adam@cfar.umd.edu [040914 20:22]:
working on Milo anyways. It is a big nasty bunch of code that noone really wants to touch.
sound as if you were talking about BOCHS BIOS :-)
It's about 200 kloc linking against a couple of million lines of linux kernel code.. bochs bios is nasty, but I think Milo exceeds this. Which
I don't think the 'C' portion of the bochs stuff is that bad. I was able to manipulate it quite eaisly. The assembly portion however is a different story. That stuff is fragile.
-
Adam Sulmicki -
Gregg C Levine -
Li-Ta Lo -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer -
Trellix78＠aol.com