Menu
▾
▴
linux-fbdev-devel
|
From: Geert U. <ge...@li...> - 2003-03-18 09:09:01
|
On Mon, 17 Mar 2003, Jon Smirl wrote:
> Plan B is to copy the ROM to something like 8000 or
> 9000. But the question there is, are VBIOS ROMs still
> written to run position independent give the PCI C000
> requirement?
Probably. Some drivers are even compressed, since they don't fit in the ROM.
So they have to be decompressed elsewhere.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Antonino D. <ad...@po...> - 2003-03-18 10:03:39
|
On Tue, 2003-03-18 at 07:41, Jon Smirl wrote: > The C000 must be a PCI restriction, it was not there > during ISA days. It's not. It's IBM defining that VGA ROM should be at segment C000. > Plan A: how is C000:0 protected; does the chipset > hardware do it or is it done via the descriptor > tables? Descriptor tables can be fixed but there is > probably no general solution to chipset protection. > This is most probably chipset specific. > On the other hand, we may be lucky and the PCI spec > has specified a standard way for enabling write > protect. Could there be a BIOS INT xx function for > this? > If writable shadow ROM is to be supported, this has to be a specific implementation by the BIOS vendor. The standard (well, at least by Phoenix), does not define any BIOS service to do this. > Plan B is to copy the ROM to something like 8000 or > 9000. But the question there is, are VBIOS ROMs still > written to run position independent give the PCI C000 > requirement? It won't run. I already tried it. > > Plan C is go into VM86 mode during early boot and > remap the memory. That means go to protected mode first, then vm86, since vm86 can only be entered in protected mode. Personally, this is too much work. > > Plan D would be to get enough info to write the code > in protected mode. That's one plan. Emulate real-mode x86 while in real-mode/protected mode. However, x86emu requires a bunch of functions to parse and execute the opcodes. > > Are there more ways to do this? I've thought of 2 more things. The first is similar to Unreal Mode or Voodoo mode. This mode was employed by DOS game developers before the advent of protected mode DOS. They initialize the GDT to have a segment limit of 4G, go to protected mode, then immediately switch back to real mode. Upon return to real mode, they now have a segment:offset of 16:32 instead of 16:16. This is real mode with a 4 Gigabyte address limit. The variant of what I'm thinking is to do the same thing, but instead of adjusting the segment limit, adjust the base address of the GDT by an offset of 1 MB. Copy the memory contents from 0 - 1 MB and place them at 1 - 2 MB. Then, go to protected mode and back to real mode. Hopefully, if this works, I can now have an address space that starts at 0x100000 (1MB) but would still appear to everyone as starting at 0 effectively bypassing BIOS protection of expansion segments. I'm not sure if the above will work though, but should be easy enough to experiment on. But if anyone knows that it won't work, let me know. The other one is proposed by Kendall. Let's just have a userspace daemon that does all BIOS requests. The second is easy to implement since we already have the tools. Also, you can literally request for BIOS services anytime. Plus, it can even run on non-x86 using an emulator. The first may not work at all, and even if it does, will run only once. Also, it has to be coded in assembly and though I've done a lot of assembly before, it takes too long to code. But it does have the advantage of initializing adapters before the kernel loads, so we can have multiple framebuffers loaded at boot time. I'm still weighing which I should look first into. The second seems to be more useful, the first is much more interesting. What do you think? Tony |
|
From: Jon S. <jon...@ya...> - 2003-03-18 17:08:02
|
Here is a description of how to control the shadow write protect for a SIS chipset. It is done by writing to PCI config space. There is a slim chance that this is a standard procedure. http://www.missl.cs.umd.edu/Projects/sebos/winint/index1.html When you copied to 8000 ot 9000, did you copy the ROM or the image at C000? I compared a dump of C000 to the ROM and they don't match. ATI may have overlaid some code during the init procedure. So I guess we are stuck with a user space daemon. Athlon-64 and IA64 will require the entire VM86 emulator. Last I checked the scitech emulator (ver8) han't implemented all of the instructions needed to run the ATI ROMs so it will need some work. How do the Transmeta tools work? Could we turn the ROMs into a C program and compile them again? Or use something like use an emulator to capture the reset sequence and then compile it for protected mode. I tried a couple of reverse engineering tools on the ROMs but I didn't get very far. I don't have access to the ATI Radeon documentation so it is hard for me to tell what is going on. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Antonino D. <ad...@po...> - 2003-03-19 05:18:55
Attachments:
detect.S
|
On Wed, 2003-03-19 at 01:07, Jon Smirl wrote: > Here is a description of how to control the shadow > write protect for a SIS chipset. It is done by writing > to PCI config space. There is a slim chance that this > is a standard procedure. > > http://www.missl.cs.umd.edu/Projects/sebos/winint/index1.html > I tried this part, and it doesn't work with the chipset I'm using. Plus, PCI config space register 0x70 is device specific, only the first 64 bytes is defined generically. > When you copied to 8000 ot 9000, did you copy the ROM > or the image at C000? I compared a dump of C000 to the > ROM and they don't match. ATI may have overlaid some > code during the init procedure. I copied the actual ROM (pointed to by Expansion ROM base address 0x30) and placed it in 0xc000 and 0x8000. 0xc000 of course is write protected by the BIOS, and it won't run in 0x8000. Yes, the final BIOS image can be different from the initial image. Most of the time, the initial image is larger, or needs decompression. Some of the newer ROM's may even use the POST Memory Manager Specification (kinda like a POST-specific malloc and family) during INIT, but this is available only during POST, and memory allocated by the PMM is unavailable after POST. > > So I guess we are stuck with a user space daemon. > Athlon-64 and IA64 will require the entire VM86 > emulator. Last I checked the scitech emulator (ver8) > han't implemented all of the instructions needed to > run the ATI ROMs so it will need some work. > > How do the Transmeta tools work? Could we turn the > ROMs into a C program and compile them again? Or use > something like use an emulator to capture the reset > sequence and then compile it for protected mode. > That's another problem. Some of the BIOS services used during INIT may become unavailable after POST, so emulating ROM's can either be caused by this or by an incomplete emulator. > I tried a couple of reverse engineering tools on the > ROMs but I didn't get very far. I don't have access to > the ATI Radeon documentation so it is hard for me to > tell what is going on. > Our best hope is for graphics manufacturer to drop VGA :-) which should allow for relocatable ROM's and therefore initialization of multiple graphics adapters. Second best hope is for manufacturer's to open up the source for initializing devices without having to initialize the VGA BIOS. Anyway, attached is the code I'm using. It basically saves the video state, disables all VGA controllers, disables VGA routing on PCI-PCI bridges, searches for valid expansion ROM addresss on VGA class devices, copies it into a scratch segment, verifies the ROM, copies the verified ROM to 0xc000 and call 0xc000:0003. Of course, the "copies the verified ROM to 0xc000" part will fail, so the "call 0xc000:0003" will just warmboot your primary display again. You have to place the file in linux/arch/i386/boot Then in setup.S add "include detect.S" and call init_video #preferably before or after 'call video' I'll probably drop effort on this (for now) and concentrate on adding a userspace daemon. Tony |
|
From: Jon S. <jon...@ya...> - 2003-03-19 06:07:13
|
Thanks for making an extreme effort at trying to get this work. I wish the video card vendors paid attention to the list so that they would have an idea of what lengths their customers will take in order to use their products. It's times like this that made me abandon the Microsoft world and become a Linux convert. Does anyone have a good ATI contact? Maybe they'll at least see the light and provide us with the info needed to avoid a user mode solution for their hardware. I agree that the user mode solution is the easiest path from here. V0.6 of the scitech x86emu works to reset my radeon with a minor tweak - INT 15 needs to be implement to simply return 1. I have had no success in getting V0.8 to work but I didn't try very hard given that V0.6 is working for me. The emulator hangs on both versions. Just to report on what I'm doing to keep busy, I have a full DRI accelerated Mesa running standalone on most Radeons100-300. The accelerated Mesa uses both DRM and FB drivers. I'm in the process of modifying embedded QT (which contains a window manager) to run on it as an OpenGL application. The goal is to see if OpenGL would make an effective alternative platform to X. There is a lot of code to write before this all works, contributions welcome. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Jon S. <jon...@ya...> - 2003-03-18 00:00:53
|
This describes a BIOS INT for controlling the write protect on the shadow RAM. http://216.239.33.100/search?q=cache:ekBz42QrBngC:www.digital-logic.de/support/download/Treiber/misc/pcchip/c%26t/INT1F.TXT+shadow+BIOS+write+protect+int&hl=en&ie=UTF-8 Unsure if this is a standard BIOS feature. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Jon S. <jon...@ya...> - 2003-03-11 23:54:02
|
Check out: arch/i386/pci/pcbios.c http://members.datafast.net.au/dft0802/specs/bios21.pdf ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com |
|
From: <sy...@sc...> - 2003-03-12 12:08:57
|
On Tue, Mar 11, 2003 at 08:49:46PM +0800, Antonino Daplas wrote: > Hi, >=20 > I was wondering how to get the EDID block, and my first thought was to > implement DDC. But it is tricky to implement, Forgive my ignorance but why is it tricky? As I understand it DDC1 only involves reading from the monitor or does EDID require something more? Reading stuff from my monitor via /dev/i2c works fine with matroxfb. I just tried this and I can see my monitors model in the returned data but parse-edid doesn't understand the data so I'm not sure it's the EDID. Also the BIOS solution will fail when someone decides to change their monitor. This got me thinking that with a real DDC solution would it be feasible to have the driver re-read the EDID periodically and/or on mode switch to prevent using bad modes? --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |
|
From: Jon S. <jon...@ya...> - 2003-03-12 16:16:36
|
The tricky part is getting the DDC data from inside a device driver as opposed to a user mode app. Plus, not all cards support the I2C bus, some use other means that are hidden by the BIOS. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com |
|
From: Antonino D. <ad...@po...> - 2003-03-12 17:41:33
|
On Wed, 2003-03-12 at 20:10, Ville Syrj=E4l=E4 wrote: > On Tue, Mar 11, 2003 at 08:49:46PM +0800, Antonino Daplas wrote: > > Hi, > >=20 > > I was wondering how to get the EDID block, and my first thought was to > > implement DDC. But it is tricky to implement, >=20 > Forgive my ignorance but why is it tricky? As I understand it DDC1 only > involves reading from the monitor or does EDID require something more? It will require that each driver provide a means of getting the EDID from the monitor, either via i2c or by some hardware specific means. Matrox users are the fortunate few since the author implemented an i2c backend. >=20 > Reading stuff from my monitor via /dev/i2c works fine with matroxfb. I > just tried this and I can see my monitors model in the returned data but > parse-edid doesn't understand the data so I'm not sure it's the EDID. >=20 > Also the BIOS solution will fail when someone decides to change their > monitor. This got me thinking that with a real DDC solution would it be > feasible to have the driver re-read the EDID periodically and/or on mode > switch to prevent using bad modes? >=20 That's okay. The get_EDID() function can get the EDID block several ways. 1. via the driver if it has its own method of getting the EDID block (1st choice) 2. via userland - EDID block (ie get-edid > edid.dmp) uploaded to driver via ioctl (2nd choice) 3. through an arch-specific method -- VBE for x86, OF for PPC, etc (last choice) When a user changes monitors without rebooting, he/she can upload an edid block appropriate for the display. Tony |
|
From: <sy...@sc...> - 2003-03-12 18:45:35
|
On Thu, Mar 13, 2003 at 01:38:19AM +0800, Antonino Daplas wrote: > Matrox users are the fortunate few since the author implemented an i2c > backend. ;) > That's okay. The get_EDID() function can get the EDID block several > ways. >=20 > 1. via the driver if it has its own method of getting the EDID block > (1st choice) >=20 > 2. via userland - EDID block (ie get-edid > edid.dmp) uploaded to > driver via ioctl (2nd choice) >=20 > 3. through an arch-specific method -- VBE for x86, OF for PPC, etc > (last choice) >=20 > When a user changes monitors without rebooting, he/she can upload an > edid block appropriate for the display. Sounds good. BTW are there public docs available about EDID & DDC? VESA doesn't like poor open-source developers :( --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |
Thanks for helping keep SourceForge clean.
X