Ron,
I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom to 0xfff8c000, ( the second 48k).
The result is When execute the option rom produce following output, and it seems In the option rom doesn't process bus/dev/func properly.
Regards
YH.
INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1002, did=4752 0x55 0xaa 0x48 0xeb 0x7b 0x2e 0x65 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 biosint: # 0x1a, eax 0xb109 ebx 0x0 ecx 0x3f8 edx 0xc2cc biosint: ebp 0x16788 esp 0xfd6 edi 0x2e esi 0xe578 biosint: ip 0x29c cs 0x0 flags 0x46 0xb109: BAD DEVICE bus 0 devfn 0x0 0xb109: bus 0 devfn 0x0 reg 0x2e val 0xffff biosint: # 0x1a, eax 0xb109 ebx 0x0 ecx 0xffff edx 0xc2cc biosint: ebp 0x16788 esp 0xfd6 edi 0x14 esi 0xe578 biosint: ip 0x308 cs 0x0 flags 0x46 0xb109: BAD DEVICE bus 0 devfn 0x0 0xb109: bus 0 devfn 0x0 reg 0x14 val 0xffff biosint: # 0x1a, eax 0xb10a ebx 0x0 ecx 0x3 edx 0xc2cc biosint: ebp 0x16788 esp 0xfd6 edi 0x18 esi 0xe578 biosint: ip 0x32d cs 0x0 flags 0x86 0xb10a: BAD DEVICE bus 0 devfn 0x0 0xb10a: bus 0 devfn 0x0 reg 0x18 val 0xffffffff biosint: # 0x1a, eax 0xb108 ebx 0x0 ecx 0x84 edx 0xb108 biosint: ebp 0x10fa4 esp 0xf96 edi 0x4 esi 0x1b1 biosint: ip 0x84e9 cs 0x0 flags 0x46 0xb108: BAD DEVICE bus 0 devfn 0x0 0xb108: bus 0 devfn 0x0 reg 0x4 val 0xff biosint: # 0x1a, eax 0xb10b ebx 0x0 ecx 0xff edx 0xb10b biosint: ebp 0x10fa4 esp 0xf9a edi 0x4 esi 0x1b2 biosint: ip 0x841b cs 0x0 flags 0x46 0xb10b: BAD DEVICE bus 0 devfn 0x0 0xb10b: bus 0 devfn 0x0 reg 0x4 val 0xff biosint: # 0x1a, eax 0xb10c ebx 0x0 ecx 0x0 edx 0xb10c biosint: ebp 0x10fa4 esp 0xf9a edi 0x0 esi 0x1b4 biosint: ip 0x841b cs 0x0 flags 0x46 0xb10c: BAD DEVICE bus 0 devfn 0x0 0xb10c: bus 0 devfn 0x0 reg 0x0 val 0x0 " -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年8月11日 10:07 收件人: YhLu 抄送: SONE Takeshi; linuxbios@clustermatic.org 主题: re: Supporting extension ROMs and beyond...
On Mon, 11 Aug 2003, YhLu wrote:
If I only want to use addon AGP Display adapter ROM, I don't need to use VGABIOS? How about PCIBIOS?
does the rom need pcibios support? if so, you need both of these modules.
ron
On Mon, 11 Aug 2003, YhLu wrote:
I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom to 0xfff8c000, ( the second 48k).
ah, well, we shouldn't really do that until we resolve the VGA bios question.
Looks, however, looke tehre is a bug ... Takeshi can perhaps address it better than I.
I did look at our three options today: emulation, ADLO, and VGABIOS.
VGABIOS is almost 100% C save for the 32-16 trampoline code.
ADLO rombios.c is mostly assembly code with C wrappers around it.
Emulation is C.
Emulation is 256K
ADLO is 64K.
VGABIOS is much less, something like 16K last time I built it.
The functions that VGABIOS needs to finish up to have as complete support as bringing up graphics as ADLO are not that many in number. Which makes sense: what a VGA BIOS needs to do is diddle its own registers, so most BISO functionality is not that useful for them.
ADLO will not find the option rom on a card and use it; VGABIOS will.
The most portable long-term way to go is emulation. I don't have room.
These are the issues I have seen so far.
ron
* ron minnich rminnich@lanl.gov [030812 01:21]:
I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom to 0xfff8c000, ( the second 48k).
ah, well, we shouldn't really do that until we resolve the VGA bios question.
It sounds cleaner to work on a seperated version of the legacy emulation code since no matter what it does, it won't mess up the LinuxBIOS core.
I did look at our three options today: emulation, ADLO, and VGABIOS.
VGABIOS is almost 100% C save for the 32-16 trampoline code.
ADLO rombios.c is mostly assembly code with C wrappers around it.
Emulation is C.
Emulation is 256K
ADLO is 64K.
VGABIOS is much less, something like 16K last time I built it.
Emulation and ADLO go hand in hand I think. There are 2 different problems to be addressed:
1) x86 realmode code execution. 2) legacy api emulation/implementation (pcibios, etc)
* LinuxBIOS1 on x86 supports 1) directly and does 2 with an emulation (pcibios.c)
* ADLO on x86 supports 1) and does 2) using the bochs bios image.
* "testbios" from the freebios1 tree (util/vgabios) supports 1) with an x86 emulation and 2) with an emulation as well. (int*.c)
Now x86emu comes with some example code doing legacy emulation, either in vm86 mode on x86 or with the cpu emulation on non-x86 cpus. This is how XFree86 does it.
In my opinion writing the legacy emulation code (2) in C certainly makes sense, since it will run on all platforms by recompiling and it can be driven by either the realmode idt code (like in linuxbios1) or by an x86emu, depending on your platform.
OTOH, making an x86emu capable version of ADLO can make the day as well, running the whole blob of bochs bios in the emulation. This looks closest to a normal PC, but definitely needs tweaking as well. Looking at the several thousand lines of bochs bios intermixed assembler and C code I am not sure whether I would want to touch this at all. bochs bios has problems in quite some places and a clean 32bit rewrite of the legacy interface that is enough to interface with vga and scsi devices is not an overwhelming effort.
Looking at the size I got the x86emu emulation including an incomplete legacy bios emulation plus userland pci code (testbios) to below 150k with -Os, so it would fit in a 256k rom with linuxbios and etherboot pretty easily. On x86 most of the code can be dropped leaving probably less than 32k for the legacy emulation.
The functions that VGABIOS needs to finish up to have as complete support as bringing up graphics as ADLO are not that many in number. Which makes sense: what a VGA BIOS needs to do is diddle its own registers, so most BISO functionality is not that useful for them.
Still it can be easily enhanced to cope with more hardware if someone needs this. Even some disk interfacing code to be able to load a kernel from a scsi device just by using the scsi controller's firmware seems only little extra work
ADLO will not find the option rom on a card and use it; VGABIOS will.
This is probably only a matter of setting the right shadow/ram/rom mapping configuration?
Stefan
* Stefan Reinauer stepan@suse.de [030812 12:36]:
- x86 realmode code execution.
- legacy api emulation/implementation (pcibios, etc)
In my opinion writing the legacy emulation code (2) in C certainly makes sense, since it will run on all platforms by recompiling and it can be driven by either the realmode idt code (like in linuxbios1) or by an x86emu, depending on your platform.
I looked at the official x86emu code at ftp://ftp.scitechsoft.com/devel/x86emu/x86emu-0.8.tar.gz
This contains something pretty similar than what we need in the v86bios directory. It's a bios emulation that either plugs into vm86 or x86emu.
Looking at the size I got the x86emu emulation including an incomplete legacy bios emulation plus userland pci code (testbios) to below 150k with -Os, so it would fit in a 256k rom with linuxbios and etherboot pretty easily. On x86 most of the code can be dropped leaving probably less than 32k for the legacy emulation.
compiling v86bios.vm86 from above I get everything into 20k.
Stefan
On Tue, 12 Aug 2003, Stefan Reinauer wrote:
I looked at the official x86emu code at ftp://ftp.scitechsoft.com/devel/x86emu/x86emu-0.8.tar.gz
I wonder if my bug fixes ever made it in. They had some "issues" (well, bugs) with prefix 0x66 instruction parsing.
hmm.
This contains something pretty similar than what we need in the v86bios directory. It's a bios emulation that either plugs into vm86 or x86emu.
OK you lost me. This is an emulator for the x86, that can parse x86 binary instruction streams, or this is a BIOS emulator?
compiling v86bios.vm86 from above I get everything into 20k.
I'll yank it down and take a look.
thanks
ron
On Tue, 12 Aug 2003, ron minnich wrote:
compiling v86bios.vm86 from above I get everything into 20k.
not the emulator, surely. Just the bios support code, right?
Let's get our terms right.
BIOS support code -> the code in ADLO, or the linuxbios support code, that provides BIOS support functions to expansion roms emulator -> A software program that can interpret x86 instruction streams and execute them
Let's stop using the term 'BIOS emulation' -- it's way too confusing!
The x86 emulator need to support the needs of an expansion rom bios is ca. 150K at best.
The BIOS support code is tiny -- I'm not surprised at 20k.
ron
* ron minnich rminnich@lanl.gov [030812 16:06]:
On Tue, 12 Aug 2003, ron minnich wrote:
compiling v86bios.vm86 from above I get everything into 20k.
not the emulator, surely. Just the bios support code, right?
yes.
The x86 emulator need to support the needs of an expansion rom bios is ca. 150K at best.
The BIOS support code is tiny -- I'm not surprised at 20k.
But that 20k is all you ever need on x86 machines. the 150k are still useful for non-x86 platforms out there where 150k of flash are probably cheaper than buying hardware that is reported to work without option rom. Most non-x86 platforms come with bigger eeproms than average x86 machines anyways. Gzip on testbios (full blown x86emu + bios support code) shrinks the size from 150k down to 53k here.
Stefan
well, 20K of full bios support answers one of Eric's objections ;-)
but we still need callbacks, right?
Still this is promising if emulator + bios gets to 53K, still rather large, but interesting.
Stefan, do you plan to test this? anyone else?
ron
On Tue, Aug 12, 2003 at 04:27:46PM +0200, Stefan Reinauer wrote:
The BIOS support code is tiny -- I'm not surprised at 20k.
But that 20k is all you ever need on x86 machines.
I looked at the x86emu but int.c only contains PCI services and some other little functions. This is pretty much like what we have now in LinuxBIOS for VGA BIOS support.
What I found really interesting in that source tree is the 'happy_cards' file, which tells what various VGA BIOS's do, and what the author had to do to make them happy.
-- Takeshi
* ron minnich rminnich@lanl.gov [030812 15:39]:
On Tue, 12 Aug 2003, Stefan Reinauer wrote: I wonder if my bug fixes ever made it in. They had some "issues" (well, bugs) with prefix 0x66 instruction parsing.
Don't know, but this version is from 2001. It also does not contain the latest fixes from xfree (which is using it, too) either.
This contains something pretty similar than what we need in the v86bios directory. It's a bios emulation that either plugs into vm86 or x86emu.
OK you lost me. This is an emulator for the x86, that can parse x86 binary instruction streams, or this is a BIOS emulator?
x86emu in general is the x86 emulator. But the source tar ball comes with this little program written by the XFree86-Developer Egbert Eich.
* It uses _either_ vm86 mode (on x86 cpus) _or_ x86emu (on non x86 cpus) to execute the graphics cards option rom. The cpu code is in either x86emu.c or v86.c depending on whether you are on x86 or not.
* it implements an int handler, similar to util/vgabios/ that currently only implements int 0x10 and 0x1a. The interrupt handler code is in int.c
This application is running in user space, using /dev/mem to access the rom. When pushing this down to the bios level it could get stripped down to access the roms and do io directly.
The code is a bit nasty, the Makefile wants to have an s/^\ \ \ \ /\t/ before it works with the gnu make i use and the bison parser does not compile either, but that is not needed for vbios but only vor the debugging utilities that Egbert wrote..
Stefan
On Tue, 12 Aug 2003, Stefan Reinauer wrote:
Emulation and ADLO go hand in hand I think. There are 2 different problems to be addressed:
I'm not so sure. The emulation code supports the INT functions needed for vga setup. I would actually be inclined to dump ADLO rombios.c completely and replace it with real C code.
ADLO is a great proof-of-concept but after walking the code I find too much assembly in there, most of it not needed.
It's the bochs heritage.
If you look at the x86 emulator in the freebios tree, you can see it supports emulation and in addition provides (in normal C, not bcc) 32-bit functions for vga calls to the bios.
- x86 realmode code execution.
- legacy api emulation/implementation (pcibios, etc)
- LinuxBIOS1 on x86 supports 1) directly and does 2 with an emulation (pcibios.c)
I'm not sure I agree with your definitions.
Emulation means (to me) emulating an x86 via software instruction decoding and execution.
the pcibios code is not doing emulation -- it is supporting pcibios functions, albeit in 32-bit mode.
While the x86emu will fit in with etherboot, it won't fit in with a linux kernel.
ron
* ron minnich rminnich@lanl.gov [030812 15:33]:
On Tue, 12 Aug 2003, Stefan Reinauer wrote:
I'm not so sure. The emulation code supports the INT functions needed for vga setup. I would actually be inclined to dump ADLO rombios.c completely and replace it with real C code.
which is what the freebios1 bioscall code and util/vgabios/testbios do already, just in a non-complete way.
ADLO is a great proof-of-concept but after walking the code I find too much assembly in there, most of it not needed.
It's the bochs heritage.
definitely. they put a lot of focus on having all the fixed address bios entries at the right place, but we hopefully dont need that to initialize vga (at least the milo x86 emulation code never did that)
If you look at the x86 emulator in the freebios tree, you can see it supports emulation and in addition provides (in normal C, not bcc) 32-bit functions for vga calls to the bios.
- x86 realmode code execution.
- legacy api emulation/implementation (pcibios, etc)
- LinuxBIOS1 on x86 supports 1) directly and does 2 with an emulation (pcibios.c)
I'm not sure I agree with your definitions.
Emulation means (to me) emulating an x86 via software instruction decoding and execution.
I used emulation in addition when calling 32bit C code instead of a 16bit bios interrupt. Just replace this with "legacy support code" then.
the pcibios code is not doing emulation -- it is supporting pcibios functions, albeit in 32-bit mode.
While the x86emu will fit in with etherboot, it won't fit in with a linux kernel.
I agree, but it is still a really big step forward. When you want video support, you either have network or a disk or a completely custom application without linux anyways.
Stefan
On Tue, 12 Aug 2003, Stefan Reinauer wrote:
I agree, but it is still a really big step forward. When you want video support, you either have network or a disk or a completely custom application without linux anyways.
yes. Do you think we should test this as an ELF payload?
ron
* ron minnich rminnich@lanl.gov [030812 17:40]:
I agree, but it is still a really big step forward. When you want video support, you either have network or a disk or a completely custom application without linux anyways.
yes. Do you think we should test this as an ELF payload?
I'll look into this. vm86.c uses the vm86old linux systemcall to run realmode code. I'll try to use the realmode idt code that is already in linuxbios1 instead.
Stefan
Stefan Reinauer stepan@suse.de writes:
- ron minnich rminnich@lanl.gov [030812 15:33]:
On Tue, 12 Aug 2003, Stefan Reinauer wrote:
I'm not so sure. The emulation code supports the INT functions needed for vga setup. I would actually be inclined to dump ADLO rombios.c completely and replace it with real C code.
which is what the freebios1 bioscall code and util/vgabios/testbios do already, just in a non-complete way.
ADLO is a great proof-of-concept but after walking the code I find too much assembly in there, most of it not needed.
It's the bochs heritage.
definitely. they put a lot of focus on having all the fixed address bios entries at the right place, but we hopefully dont need that to initialize vga (at least the milo x86 emulation code never did that)
Looking at the various specifications there is an additional route we can take. We can have the 16bit trampoline detect if it is running in v86 mode, and if so use the appropriate DPMI/VCPI/XMS functions to switch to protected mode instead of our hand crafted code.
That should allow us to run under Win9x, freedos, and djgpp. For Freebsd we will probably need a couple of the very most common calls implemented in the 16bit trampoline as well. And of course we can still implement the legacy entry points.
- It is not clear what an Option ROM will care about so being as backward compatible as possible is a real plus.
- Going with a solution that can (at least in theory) handle all of the legacy backwards compatibility cases will allow us to concentrate on a single implementation.
- Going with a solution that is primarily 32bit C code will allow us to reuse the code in appropriate ways.
- Not using v86 mode by default will allow a high degree of compatibility anyway.
Does a version of ADLO that runs as 32bit C code sound reasonable?
Eric
On Sun, Aug 17, 2003 at 12:30:49PM -0600, Eric W. Biederman wrote:
Looking at the various specifications there is an additional route we can take. We can have the 16bit trampoline detect if it is running in v86 mode, and if so use the appropriate DPMI/VCPI/XMS functions to switch to protected mode instead of our hand crafted code.
That should allow us to run under Win9x, freedos, and djgpp. For Freebsd we will probably need a couple of the very most common calls implemented in the 16bit trampoline as well. And of course we can still implement the legacy entry points.
Very interesting.
It is not clear what an Option ROM will care about so being as backward compatible as possible is a real plus.
Going with a solution that can (at least in theory) handle all of the legacy backwards compatibility cases will allow us to concentrate on a single implementation.
Going with a solution that is primarily 32bit C code will allow us to reuse the code in appropriate ways.
Not using v86 mode by default will allow a high degree of compatibility anyway.
Does a version of ADLO that runs as 32bit C code sound reasonable?
What do you think about non-x86?
-- Takeshi
I have gotten back to doing some work on the vga of the epia-800, and can't seem to get linux to fully boot. It panics as below. If anyone has any ideas on what this might be, I would appreciate the help. The kernel is 2.4.21. I am using the std epia config with a few mods to boot from IDE.
-Steve
... CPU: Centaur VIA Ezra stepping 08 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd general protection fault: 0000 CPU: 0 EIP: 0010:[<c0144ebe>] Not tainted EFLAGS: 00010286 eax: c3eb0000 ebx: 00000f00 ecx: c3eb0000 edx: ffffffff esi: c3eb0000 edi: ffffffff ebp: c10e9f64 esp: c10e9ef8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c10e9000) Stack: 00000f00 c3eb0000 c3eb05a0 c10e9f64 ffffffff 00000000 00000000 00000000 c01130dc 00000f00 c3eb0000 c10e8000 c10e9fa0 00000000 c10e9f64 c3eb0000 00000000 fffffff4 c0116654 00000000 c02c1ba0 00000001 c010740e 00000f00 Call Trace: [<c01130dc>] [<c0116654>] [<c010740e>] [<c01087b3>] [<c017adef>] [<c010706b>] [<c0112c08>] [<c017adef>] [<c017adef>] [<c0105073>] [<c0107074>]
Code: ff 07 8b 44 24 24 a9 00 00 02 00 0f 84 9b 02 00 00 bb 00 e0 <0>Kernel panic: Attempted to kill init!
Run that log through ksymoops. As it is it's meaningless.
Regards,
Jeff
On Tue, Aug 19, 2003 at 10:09:50PM -0700, Steve Gehlbach wrote:
I have gotten back to doing some work on the vga of the epia-800, and can't seem to get linux to fully boot. It panics as below. If anyone has any ideas on what this might be, I would appreciate the help. The kernel is 2.4.21. I am using the std epia config with a few mods to boot from IDE.
-Steve
... CPU: Centaur VIA Ezra stepping 08 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd general protection fault: 0000 CPU: 0 EIP: 0010:[<c0144ebe>] Not tainted EFLAGS: 00010286 eax: c3eb0000 ebx: 00000f00 ecx: c3eb0000 edx: ffffffff esi: c3eb0000 edi: ffffffff ebp: c10e9f64 esp: c10e9ef8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c10e9000) Stack: 00000f00 c3eb0000 c3eb05a0 c10e9f64 ffffffff 00000000 00000000 00000000 c01130dc 00000f00 c3eb0000 c10e8000 c10e9fa0 00000000 c10e9f64 c3eb0000 00000000 fffffff4 c0116654 00000000 c02c1ba0 00000001 c010740e 00000f00 Call Trace: [<c01130dc>] [<c0116654>] [<c010740e>] [<c01087b3>] [<c017adef>] [<c010706b>] [<c0112c08>] [<c017adef>] [<c017adef>] [<c0105073>] [<c0107074>]
Code: ff 07 8b 44 24 24 a9 00 00 02 00 0f 84 9b 02 00 00 bb 00 e0 <0>Kernel panic: Attempted to kill init!
Jeff Noxon wrote:
Run that log through ksymoops. As it is it's meaningless.
Good point:
CPU: 0 EIP: 0010:[<c0146f37>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: c3eb2000 ebx: c3eb2000 ecx: 00000f00 edx: ffffffff esi: 00000f00 edi: ffffffff ebp: c10ebf64 esp: c10ebefc ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c10eb000) Stack: c3eb2000 00000f00 c3eb25a0 c10ebf64 ffffffff 00000000 00000000 00000000 c0113401 00000f00 c3eb2000 c10ea000 c10ebfa0 00000000 c10ebf64 00000000 fffffff4 c01169a6 00000000 c02f8ba0 00000001 c01075a5 00000f00 00000078 Call Trace: [<c0113401>] [<c01169a6>] [<c01075a5>] [<c01089d3>] [<c017e748>] [<c01071eb>] [<c0112f54>] [<c017e748>] [<c017e748>] [<c010507e>] [<c01071f4>] Code: ff 07 8b 44 24 24 a9 00 00 02 00 0f 84 a6 02 00 00 bb 00 e0
EIP; c0146f37 <copy_namespace+3b/360> <=====
eax; c3eb2000 <END_OF_CODE+3b8e090/????> ebx; c3eb2000 <END_OF_CODE+3b8e090/????> ecx; 00000f00 Before first symbol edx; ffffffff <END_OF_CODE+3fcdc08f/????> esi; 00000f00 Before first symbol edi; ffffffff <END_OF_CODE+3fcdc08f/????> ebp; c10ebf64 <END_OF_CODE+dc7ff4/????> esp; c10ebefc <END_OF_CODE+dc7f8c/????>
Trace; c0113401 <do_fork+491/7c8> Trace; c01169a6 <tasklet_hi_action+4a/70> Trace; c01075a5 <sys_clone+1d/24> Trace; c01089d3 <system_call+33/40> Trace; c017e748 <jfsIOWait+0/194> Trace; c01071eb <arch_kernel_thread+1f/38> Trace; c0112f54 <kernel_thread+6c/88> Trace; c017e748 <jfsIOWait+0/194> Trace; c017e748 <jfsIOWait+0/194> Trace; c010507e <init+1a/14c> Trace; c01071f4 <arch_kernel_thread+28/38>
Code; c0146f37 <copy_namespace+3b/360> 00000000 <_EIP>: Code; c0146f37 <copy_namespace+3b/360> <===== 0: ff 07 incl (%edi) <===== Code; c0146f39 <copy_namespace+3d/360> 2: 8b 44 24 24 mov 0x24(%esp,1),%eax Code; c0146f3d <copy_namespace+41/360> 6: a9 00 00 02 00 test $0x20000,%eax Code; c0146f42 <copy_namespace+46/360> b: 0f 84 a6 02 00 00 je 2b7 <_EIP+0x2b7> c01471ee <copy_namespace+2f2/360> Code; c0146f48 <copy_namespace+4c/360> 11: bb 00 e0 00 00 mov $0xe000,%ebx
<0>Kernel panic: Attempted to kill init!
----------
Memory seems to be correct:
Jumping to boot code Linux version 2.4.21 (root@nexpath70.kesa.com) (gcc version 2.95.4 20011002 (Debian prerelease)) #24 Wed Aug 20 09:57:32 PDT 2003 BIOS-provided physical RAM map: BIOS-e801: 0000000000000000 - 000000000009f000 (usable) BIOS-e801: 0000000000100000 - 0000000003f00000 (usable) 63MB LOWMEM available. On node 0 totalpages: 16128 zone(0): 4096 pages. zone(1): 12032 pages. zone(2): 0 pages. Kernel command line: root=/dev/hda1 ro console=ttyS0,115200n8 Initializing CPU#0 Detected 800.048 MHz processor. Calibrating delay loop... 1595.80 BogoMIPS Memory: 61152k/64512k available (1360k kernel code, 2972k reserved, 383k data, 264k init, 0k highmem) .....
Steve
Steve Gehlbach wrote:
Jeff Noxon wrote:
Run that log through ksymoops. As it is it's meaningless.
Never mind, I found the problem. RAM was not getting init'ed correctly for the SDRAM I was using. I was not completely sync'ed to the repository, and did not have the latest northbridge files. Main reason was that ide.c, ide.h were broken for secondary ide, but I backed up one rev on each got that to work.
-Steve
On Wed, 20 Aug 2003, Steve Gehlbach wrote:
Never mind, I found the problem. RAM was not getting init'ed correctly for the SDRAM I was using. I was not completely sync'ed to the repository, and did not have the latest northbridge files. Main reason was that ide.c, ide.h were broken for secondary ide, but I backed up one rev on each got that to work.
ok. That kind of thing is usually ram.
We need to get this ide mess fixed.
ron
On 17 Aug 2003, Eric W. Biederman wrote:
Does a version of ADLO that runs as 32bit C code sound reasonable?
it sounds interesting, I'll look at this too.
I'm back sporadically now until tuesday, back then for real.
2000 messages to dig through.
ron
In newer 2.5/2.6 kernelS, there's a framebuffer option for initializing a Rage XL without BIOS support. These ATI Rage XLs show up integrated into a great variety of server boards, so I thought this tidbit would be of interest to many of you. Has anyone had luck with this code though? I, so far, have not. Blank screen, very diagnosable..
- Adam Agnew
On Mon, Aug 11, 2003 at 05:21:06PM -0600, ron minnich wrote:
On Mon, 11 Aug 2003, YhLu wrote:
I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom to 0xfff8c000, ( the second 48k).
ah, well, we shouldn't really do that until we resolve the VGA bios question.
Looks, however, looke tehre is a bug ... Takeshi can perhaps address it better than I.
PCI spec requires System BIOS to provide Bus/Dev/Fn of the device in AX register when calling option ROM during POST. This way multiple instances of same PCI device can be initialized one by one, I guess.
And, vgabios.c doesn't do that.
YhLu, you can at first hardcode the bus/devfn of your VGA card in the assembly part of the vgabios.c, and see what happens.
-- Takeshi
On Sun, 17 Aug 2003, SONE Takeshi wrote:
And, vgabios.c doesn't do that.
gee, I thought I had it doing that. I will try to fix this when I get back.
ron
On Sun, 17 Aug 2003, SONE Takeshi wrote:
On Mon, Aug 11, 2003 at 05:21:06PM -0600, ron minnich wrote:
On Mon, 11 Aug 2003, YhLu wrote:
I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom to 0xfff8c000, ( the second 48k).
Looks, however, looke tehre is a bug ... Takeshi can perhaps address it better than I.
PCI spec requires System BIOS to provide Bus/Dev/Fn of the device in AX register when calling option ROM during POST. This way multiple instances of same PCI device can be initialized one by one, I guess.
And, vgabios.c doesn't do that.
I have a fixed vgabios.c if anyone wants to test it that should now put bus/dev/fn in the ax register.
ron
On Sun, 17 Aug 2003, SONE Takeshi wrote:
PCI spec requires System BIOS to provide Bus/Dev/Fn of the device
BTW I am assuming the format is (bus << 8) | devfn, correct?
ron
-
Adam Agnew -
ebiederman＠lnxi.com -
Jeff Noxon -
ron minnich -
SONE Takeshi -
SONE Takeshi -
Stefan Reinauer -
Steve Gehlbach -
YhLu