Re: Mapping Video BIOS?
On Saturday, 26 July 2003 at 22:18:59 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: Presuming that it's the ROM driver, I get this in the dmesg I posted: pnpbios: Bad PnP BIOS data checksum That's likely the problem. However, PnP BIOS information isn't the same thing that the orm[sic] driver probes for. They look related. I've now found the orm output: orm0: Option ROMs at iomem 0xe-0xe3fff,0xdf800-0xd,0xd-0xd17ff,0xc-0xcefff on isa0 The last one is the video BIOS. It's interesting to note that it doesn't report the 4 kB BIOS at 0xcf000, which suggests that at this point the 16 kB area is already unmapped. I've worked around the problem by compiling the video BIOS into the X server and not trying to access the BIOS in the machine. Obviously not a solution, but it works for the moment. I'd really like to track down the problem. Does anybody have an idea? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Saturday, 26 July 2003 at 22:18:59 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : Presuming that it's the ROM driver, I get this in the dmesg I posted: : pnpbios: Bad PnP BIOS data checksum : : That's likely the problem. However, PnP BIOS information isn't the : same thing that the orm[sic] driver probes for. : : They look related. I've now found the orm output: : : orm0: Option ROMs at iomem 0xe-0xe3fff,0xdf800-0xd,0xd-0xd17ff,0xc-0xcefff on isa0 : : The last one is the video BIOS. It's interesting to note that it : doesn't report the 4 kB BIOS at 0xcf000, which suggests that at this : point the 16 kB area is already unmapped. H, The list comes from scanning the ISA HOLE for certain memory signatures. These signatures have a length in them that say I'm a rom that's X long. I don't think that it suggests that things are 'unmapped'... : I've worked around the problem by compiling the video BIOS into the X : server and not trying to access the BIOS in the machine. Obviously : not a solution, but it works for the moment. I'd really like to track : down the problem. Does anybody have an idea? I don't, I'm sorry. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Sunday, 27 July 2003 at 21:42:35 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: On Saturday, 26 July 2003 at 22:18:59 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: Presuming that it's the ROM driver, I get this in the dmesg I posted: pnpbios: Bad PnP BIOS data checksum That's likely the problem. However, PnP BIOS information isn't the same thing that the orm[sic] driver probes for. They look related. I've now found the orm output: orm0: Option ROMs at iomem 0xe-0xe3fff,0xdf800-0xd,0xd-0xd17ff,0xc-0xcefff on isa0 The last one is the video BIOS. It's interesting to note that it doesn't report the 4 kB BIOS at 0xcf000, which suggests that at this point the 16 kB area is already unmapped. H, The list comes from scanning the ISA HOLE for certain memory signatures. These signatures have a length in them that say I'm a rom that's X long. Sure. The data at offset 0xc are: C000: 55 AA 78 E9 44 06 00 00-00 00 00 00 00 00 00 00 U.x.D... The 0xaa55 is the BIOS signature (Here be a BIOS), and the 0x78 is the length byte (120 sectors, or 60 kB). That's how orm0 knows the end address. I don't think that it suggests that things are 'unmapped'... If the area between 0xcc000 and 0xc had been mapped, orm0 would have found this too: C000:F000 55 AA 08 E8 6D 0B CB 11-FE 02 00 00 00 00 00 00 U...m... I've worked around the problem by compiling the video BIOS into the X server and not trying to access the BIOS in the machine. Obviously not a solution, but it works for the moment. I'd really like to track down the problem. Does anybody have an idea? I don't, I'm sorry. Understood. I was hoping that somebody else might have some ideas. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : Sure. The data at offset 0xc are: : : C000: 55 AA 78 E9 44 06 00 00-00 00 00 00 00 00 00 00 U.x.D... : : The 0xaa55 is the BIOS signature (Here be a BIOS), and the 0x78 is : the length byte (120 sectors, or 60 kB). That's how orm0 knows the : end address. : : I don't think that it suggests that things are 'unmapped'... : : If the area between 0xcc000 and 0xc had been mapped, orm0 would : have found this too: : : C000:F000 55 AA 08 E8 6D 0B CB 11-FE 02 00 00 00 00 00 00 U...m... 08 - 4k It could also be that there's a bug in orm that's missing it... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Sunday, 27 July 2003 at 22:03:57 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: Sure. The data at offset 0xc are: C000: 55 AA 78 E9 44 06 00 00-00 00 00 00 00 00 00 00 U.x.D... The 0xaa55 is the BIOS signature (Here be a BIOS), and the 0x78 is the length byte (120 sectors, or 60 kB). That's how orm0 knows the end address. I don't think that it suggests that things are 'unmapped'... If the area between 0xcc000 and 0xc had been mapped, orm0 would have found this too: C000:F000 55 AA 08 E8 6D 0B CB 11-FE 02 00 00 00 00 00 00 U...m... 08 - 4k Correct. It should have shown a BIOS from 0xcf000 to 0xc It could also be that there's a bug in orm that's missing it... Sure, but given the other indications, that's not so likely. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
Where are you getting the data? A windows tool? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote: Where are you getting the data? A windows tool? If you're talking about the BIOS contents I'm printing, yes, I'm using a Microsoft tool called DEBUG (which has been around since before Microsoft bought DOS :-). Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote: : Where are you getting the data? A windows tool? : : If you're talking about the BIOS contents I'm printing, yes, I'm using : a Microsoft tool called DEBUG (which has been around since before : Microsoft bought DOS :-). I don't suppose that you could use FreeBSD's /dev/mem + od? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Sunday, 27 July 2003 at 22:17:32 -0600, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Greg 'groggy' Lehey [EMAIL PROTECTED] writes:
On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote:
Where are you getting the data? A windows tool?
If you're talking about the BIOS contents I'm printing, yes, I'm using
a Microsoft tool called DEBUG (which has been around since before
Microsoft bought DOS :-).
I don't suppose that you could use FreeBSD's /dev/mem + od?
Yup, can do.
# dd if=/dev/mem bs=64k skip=12 count=1 | hd | less
55 aa 78 e9 44 06 00 00 00 00 00 00 00 00 00 00 |U.x.D...|
0010 00 00 00 00 00 00 00 00 68 01 00 00 00 00 49 42 |h.IB|
...
bff0 04 03 80 00 0c 00 00 00 20 00 10 0b 3e 00 02 40 | .@|
c000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ||
*
0001
That's pretty much what I expected. Up to offset bff0, it's identical
with the Microsoft dump.
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
pgp0.pgp
Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Sunday, 27 July 2003 at 22:17:32 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote: : Where are you getting the data? A windows tool? : : If you're talking about the BIOS contents I'm printing, yes, I'm using : a Microsoft tool called DEBUG (which has been around since before : Microsoft bought DOS :-). : : I don't suppose that you could use FreeBSD's /dev/mem + od? : : Yup, can do. : : # dd if=/dev/mem bs=64k skip=12 count=1 | hd | less : : 55 aa 78 e9 44 06 00 00 00 00 00 00 00 00 00 00 |U.x.D...| : 0010 00 00 00 00 00 00 00 00 68 01 00 00 00 00 49 42 |h.IB| : ... : bff0 04 03 80 00 0c 00 00 00 20 00 10 0b 3e 00 02 40 | .@| : c000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || : * : 0001 : : That's pretty much what I expected. Up to offset bff0, it's identical : with the Microsoft dump. Shouldn't you be looking at 0x000c instead of 0xc000? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Sunday, 27 July 2003 at 22:32:42 -0600, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Greg 'groggy' Lehey [EMAIL PROTECTED] writes:
On Sunday, 27 July 2003 at 22:17:32 -0600, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Greg 'groggy' Lehey [EMAIL PROTECTED] writes:
On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote:
Where are you getting the data? A windows tool?
If you're talking about the BIOS contents I'm printing, yes, I'm using
a Microsoft tool called DEBUG (which has been around since before
Microsoft bought DOS :-).
I don't suppose that you could use FreeBSD's /dev/mem + od?
Yup, can do.
dd if=/dev/mem bs=64k skip=12 count=1 | hd | less
55 aa 78 e9 44 06 00 00 00 00 00 00 00 00 00 00 |U.x.D...|
0010 00 00 00 00 00 00 00 00 68 01 00 00 00 00 49 42 |h.IB|
...
bff0 04 03 80 00 0c 00 00 00 20 00 10 0b 3e 00 02 40 | .@|
c000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ||
*
0001
That's pretty much what I expected. Up to offset bff0, it's identical
with the Microsoft dump.
Shouldn't you be looking at 0x000c instead of 0xc000?
Yes, I am. Look at the calculations in the dd above: skip 12 blocks
of 64 kB, or 0xc. If you mean the output of Microsoft's DEBUG,
that's in 8086 real mode, segment:offset. The segment registers are
logically shifted 4 bits to the left, so C000: is 0xc.
Greg
--
See complete headers for address and phone numbers
pgp0.pgp
Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Sunday, 27 July 2003 at 22:32:42 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Sunday, 27 July 2003 at 22:17:32 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote: : Where are you getting the data? A windows tool? : : If you're talking about the BIOS contents I'm printing, yes, I'm using : a Microsoft tool called DEBUG (which has been around since before : Microsoft bought DOS :-). : : I don't suppose that you could use FreeBSD's /dev/mem + od? : : Yup, can do. : : dd if=/dev/mem bs=64k skip=12 count=1 | hd | less : : 55 aa 78 e9 44 06 00 00 00 00 00 00 00 00 00 00 |U.x.D...| :0010 00 00 00 00 00 00 00 00 68 01 00 00 00 00 49 42 |h.IB| :... :bff0 04 03 80 00 0c 00 00 00 20 00 10 0b 3e 00 02 40 | .@| :c000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || :* :0001 : : That's pretty much what I expected. Up to offset bff0, it's identical : with the Microsoft dump. : : Shouldn't you be looking at 0x000c instead of 0xc000? : : Yes, I am. Look at the calculations in the dd above: skip 12 blocks : of 64 kB, or 0xc. If you mean the output of Microsoft's DEBUG, : that's in 8086 real mode, segment:offset. The segment registers are : logically shifted 4 bits to the left, so C000: is 0xc. No, didn't see the skip. Looks like weird things are going on :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Mapping Video BIOS?
I've spent the last couple of days tracking down a problem starting X on a Dell Inspiron 5100. I've got as far as discovering that the video BIOS is not being completely mapped: it's 60 kB long, but only 48 kB are being mapped into memory. To make matters worse, the machine doesn't have a serial port, so I can't apply a kernel debugger to find out what's going on. Can anybody point me in the right direction? Where should I be looking for this? Is this memory mapped permanently, or is it only during X startup? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
On Sat, Jul 26, 2003 at 05:32:17PM +0930, Greg 'groggy' Lehey wrote: Can anybody point me in the right direction? Where should I be looking for this? Is this memory mapped permanently, or is it only during X startup? The video BIOS is usually mapped by system BIOS into real memory to begin with, so it should be just sitting there. There are usually northbridge chipset registers for dealing with this sort of thing. The SMM mode might reuse that window, though, but generally this is hidden from non-SMM mode applications. You're in luck - been rebuilding X, so have xc tarballs handy. The XFree86 code responsible is: xc/programs/Xserver/hw/xfree86/int10 Some drivers like to call VBE via int10h, so this module acts as a bridge. It just memcpy()'s the ROM and uses various methods, depending on the compilation target, to call int10h. Is the onboard video AGP/PCI? It is possible that the device isn't reporting its memory window in the ROM BAR correctly. I've seen this happen with some low-end network cards before. Try my tools at this URL to check this: http://www.incunabulum.com/code/projects/pci/freebsd/ BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Saturday, 26 July 2003 at 9:41:14 +0100, Bruce M Simpson wrote: On Sat, Jul 26, 2003 at 05:32:17PM +0930, Greg 'groggy' Lehey wrote: Can anybody point me in the right direction? Where should I be looking for this? Is this memory mapped permanently, or is it only during X startup? The video BIOS is usually mapped by system BIOS into real memory to begin with, so it should be just sitting there. There are usually northbridge chipset registers for dealing with this sort of thing. The SMM mode might reuse that window, though, but generally this is hidden from non-SMM mode applications. You're in luck - been rebuilding X, so have xc tarballs handy. The XFree86 code responsible is: xc/programs/Xserver/hw/xfree86/int10 Yup, I've been playing around with it. I currently have my arms in xf86ExtendedInitInt10, which does the mapping. It tries to map 256 kB of memory, and I suppose it does, for some definition: (II) RADEON(0): mapped system memory at 0xc, len 0x4, video BIOS offset 0xc, to 0x28368000 But at 0xcc00, I get: (gdb) x/20x 0x28373ff0 0x28373ff0: 0x00800304 0x000c 0x0b100020 0x4002003e 0x28374000: 0x 0x 0x 0x 0x28374010: 0x 0x 0x 0x I've looked in the same space with Microsoft, which says: C000:BFF0 04 03 80 00 0C 00 00 00-20 00 10 0B 3E 00 02 40 .@ C000:C000 00 2E 05 01 06 10 40 01-90 01 02 97 01 45 01 0D [EMAIL PROTECTED] Some drivers like to call VBE via int10h, so this module acts as a bridge. It just memcpy()'s the ROM and uses various methods, depending on the compilation target, to call int10h. Is the onboard video AGP/PCI? Intel 82845, if that's the correct answer. I've put the dmesg up at http://www.lemis.com/grog/Inspiron/dmesg.boot. It is possible that the device isn't reporting its memory window in the ROM BAR correctly. I've seen this happen with some low-end network cards before. I could believe that, but I think we have a different problem here: since it's mapping up to the end of low memory. My guess is that something else shares this space, and that it has been turned off. I'm going to carry on investigating, but if anybody else recognizes the problem, I'd be interested to hear from you. Try my tools at this URL to check this: http://www.incunabulum.com/code/projects/pci/freebsd/ Thanks, I'll try that anyway. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : machine doesn't have a serial port, so I can't apply a kernel debugger : to find out what's going on. Does it have a firewire port? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Saturday, 26 July 2003 at 11:27:06 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: machine doesn't have a serial port, so I can't apply a kernel debugger to find out what's going on. Does it have a firewire port? Yes. How can I use that? I had also expected that you could shed some light on the BIOS mapping issue. Since my last message I've become pretty sure that it must be something to do with the chip set setup. Is it possible that we're not mapping the entire area 0xc to 0xf? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Saturday, 26 July 2003 at 11:27:06 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : machine doesn't have a serial port, so I can't apply a kernel debugger : to find out what's going on. : : Does it have a firewire port? : : Yes. How can I use that? If you have a second machine with firewire, then you can use the firewire port as your console. Look at /usr/ports/devel/dcons. It is one of the under-publicized cool features from Japan (Thanks Shimokawa-san!). : I had also expected that you could shed some light on the BIOS mapping : issue. Since my last message I've become pretty sure that it must be : something to do with the chip set setup. Is it possible that we're : not mapping the entire area 0xc to 0xf? I'm not sure what you mean by this question. Since OLDCARD works, and requires read/write access to that physical memory range, I doubt that it is unmapped. It may be the case that we aren't setting things up so that XFree86 can call the BIOS, but given that we used PCIBIOS before ACPI, it seems unlikely. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Saturday, 26 July 2003 at 18:44:43 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: On Saturday, 26 July 2003 at 11:27:06 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: machine doesn't have a serial port, so I can't apply a kernel debugger to find out what's going on. Does it have a firewire port? Yes. How can I use that? If you have a second machine with firewire, then you can use the firewire port as your console. Look at /usr/ports/devel/dcons. It is one of the under-publicized cool features from Japan (Thanks Shimokawa-san!). Ah, good stuff. I'll have to check if it also works with gdb. Unfortunately, this is my only machine with firewire. I was wondering if there were USB/conventional serial converters that I could use. I had also expected that you could shed some light on the BIOS mapping issue. Since my last message I've become pretty sure that it must be something to do with the chip set setup. Is it possible that we're not mapping the entire area 0xc to 0xf? I'm not sure what you mean by this question. Since OLDCARD works, and requires read/write access to that physical memory range, I doubt that it is unmapped. I'm not sure at what level. I suspect that something in the chipset is turning off that area of memory, or mapping something else to it. The dump from Microsoft shows that there's another BIOS at 0xcf000, but what I have mapped in memory shows only 0xff up to address 0xd, where I find another BIOS signature: 0x28377fe0: 0x 0x 0x 0x 0x28377ff0: 0x 0x 0x 0x 0x28378000: 0xe80caa55 0x4ecb14c8 0x033b 0x 0x28378010: 0x 0x0020 0x00600040 0x90c08b2e 0x28378020: 0x49444e55 0xea16 0x0c9d0201 0xad100800 It may be the case that we aren't setting things up so that XFree86 can call the BIOS, but given that we used PCIBIOS before ACPI, it seems unlikely. Well, this is a new laptop, so it's possible that something *is* getting set up incorrectly. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Saturday, 26 July 2003 at 18:44:43 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Saturday, 26 July 2003 at 11:27:06 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : machine doesn't have a serial port, so I can't apply a kernel debugger : to find out what's going on. : : Does it have a firewire port? : : Yes. How can I use that? : : If you have a second machine with firewire, then you can use the : firewire port as your console. Look at /usr/ports/devel/dcons. It is : one of the under-publicized cool features from Japan (Thanks : Shimokawa-san!). : : Ah, good stuff. I'll have to check if it also works with gdb. : Unfortunately, this is my only machine with firewire. I was wondering : if there were USB/conventional serial converters that I could use. None of them support console access, as far as I know. : I had also expected that you could shed some light on the BIOS mapping : issue. Since my last message I've become pretty sure that it must be : something to do with the chip set setup. Is it possible that we're : not mapping the entire area 0xc to 0xf? : : I'm not sure what you mean by this question. Since OLDCARD works, and : requires read/write access to that physical memory range, I doubt that : it is unmapped. : : I'm not sure at what level. I suspect that something in the chipset : is turning off that area of memory, or mapping something else to it. : The dump from Microsoft shows that there's another BIOS at 0xcf000, : but what I have mapped in memory shows only 0xff up to address : 0xd, where I find another BIOS signature: : : 0x28377fe0: 0x 0x 0x 0x : 0x28377ff0: 0x 0x 0x 0x : 0x28378000: 0xe80caa55 0x4ecb14c8 0x033b 0x : 0x28378010: 0x 0x0020 0x00600040 0x90c08b2e : 0x28378020: 0x49444e55 0xea16 0x0c9d0201 0xad100800 Typically, there are a number of different ROM sections. The orm driver searches for these things out. Does it report anything : It may be the case that we aren't setting things up so that XFree86 : can call the BIOS, but given that we used PCIBIOS before ACPI, it : seems unlikely. : : Well, this is a new laptop, so it's possible that something *is* : getting set up incorrectly. True. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Saturday, 26 July 2003 at 19:47:50 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: On Saturday, 26 July 2003 at 18:44:43 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: I had also expected that you could shed some light on the BIOS mapping issue. Since my last message I've become pretty sure that it must be something to do with the chip set setup. Is it possible that we're not mapping the entire area 0xc to 0xf? I'm not sure what you mean by this question. Since OLDCARD works, and requires read/write access to that physical memory range, I doubt that it is unmapped. I'm not sure at what level. I suspect that something in the chipset is turning off that area of memory, or mapping something else to it. The dump from Microsoft shows that there's another BIOS at 0xcf000, but what I have mapped in memory shows only 0xff up to address 0xd, where I find another BIOS signature: 0x28377fe0: 0x 0x 0x 0x 0x28377ff0: 0x 0x 0x 0x 0x28378000: 0xe80caa55 0x4ecb14c8 0x033b 0x 0x28378010: 0x 0x0020 0x00600040 0x90c08b2e 0x28378020: 0x49444e55 0xea16 0x0c9d0201 0xad100800 Typically, there are a number of different ROM sections. The orm driver searches for these things out. Does it report anything Presuming that it's the ROM driver, I get this in the dmesg I posted: pnpbios: Bad PnP BIOS data checksum That's pretty much the same problem reported by the X server. Where would I go from there? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : Presuming that it's the ROM driver, I get this in the dmesg I posted: : pnpbios: Bad PnP BIOS data checksum That's likely the problem. However, PnP BIOS information isn't the same thing that the orm[sic] driver probes for. : Where would I go from there? Not sure. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
