On Mon, 1 Oct 2001 S. Krishnan wrote:
Which video display adapter are you using, and with
I'm afraid I don't know. How can I find out?
how much RAM?
256 kB RAM.
Thanks.
Parul Mathur
On 3 Oct 2001, Parul Mathur wrote:
how much RAM?
256 kB RAM.
With 256KB Video RAM, I don't think you can run X at 8bpp either. Try 16 colour VGA mode. It probably isn't set in your XF86Config file, so run xf86config or Xconfigurator to set it. This may set the XF86Config file, which you will then have to copy to XF86Config-4
Philip
--- Parul Mathur parulmat@rediffmail.com wrote:
On Mon, 1 Oct 2001 S. Krishnan wrote:
Which video display adapter are you using, and
with
I'm afraid I don't know. How can I find out?
how much RAM?
256 kB RAM.
Good chances thhat this is either (most probably) an ISA card or a very old PCI card. As Philip says, the only way you can really get it to work is by running the 16 colour VGA server. Any other mode will need more video RAM than you have available. Why don't you open up the box and take a look at the VGA card (assuming it is not an onboard assembly on the motherboard) to see if you can figure out the manufacturer and part number?
If you have a system with available PCI slots (generally available only on Pentium+ systems, but I've seen a (very) few 486's with PCI), I suggest that you upgrade your video to a rather more recent card. A PCI (non-AGP) card with 1 MB ought to (if available) cost around Rs. 400 to 500, while more modern PCI cards would cost a couple of hundreds more. Your advantage here is that you would be able to run with better colour depth and resolution, not to mention speed.
Best regards,
Krishnan
__________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com
hiyee there luggers.......
i am using a i810 board with Award Bios. Part of the project on Linux is that i have to make direct acess to a memory location f000:cdcd part of the flash bios and grep fpr a string in the bios.
This real address is wat i hav obtained from DOS real mode using debug f000:cdcd.
#include <stdio.h>
int main() {
int i; char *ptr; ptr = (char *)0xf000cdcd;
for(i=0; i<=500; i++) { printf("%c",ptr); *ptr++; }
}
This is some code i got together with some help for a dear friend...But this still doesnt get the string from memory. I doubt Linux is even allowing me to access the BIOS memory. Is this funda of protected mode not allowing me to access those parts of memory. If so wat system calls need i to pass to get into real mode and make that access to the BIOS memory.
Luggers.....ny help is highly appreciated...
TIA.
Trevor Warren
===== ( >- LINUX, It's all about CHOICE -< ) /~\ __ http://www.trevorwarren.com __ /~\ | ) / mailto: trevorwarren@yahoo.com \ (/ | |_|_ \ Urgent ->9820349221@maxtouch.co.in / / _|_| ___________________________________/
__________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com
On Wed, 3 Oct 2001, Trevor Warren wrote:
i am using a i810 board with Award Bios. Part of the project on Linux is that i have to make direct acess to a memory location f000:cdcd part of the flash bios and grep fpr a string in the bios.
First off, that address is a real mode address (segment:offset). In protected mode, addresses are more than that, 32 or 64 bits (or 20 if you use an 8088).
Also, I think that you have to set up a special device in your proc file system to access your flash ram. Check in make menuconfig.
Philip
--- Philip S Tellis philip.tellis@iname.com wrote:
On Wed, 3 Oct 2001, Trevor Warren wrote:
i am using a i810 board with Award Bios. Part of
the
project on Linux is that i have to make direct
acess
to a memory location f000:cdcd part of the flash
bios
and grep fpr a string in the bios.
First off, that address is a real mode address (segment:offset). In protected mode, addresses are more than that, 32 or 64 bits (or 20 if you use an 8088).
You will have to convert the segment:offset address into a real linear address. Microsoft compilers used a macro called MK_FP (for Make Far Pointer), whose job is to convert 16 bit segment:offset addresses to a linear address. This would work quite well under real mode, but would fail under protected mode, for all the reasons listed below.
Incidentally, a protected mode address can also be 16 bit, (though not on Linux except if you're running legacy Win16 apps under Wine), if you're using Win16 or similar code (maybe ELKS for Linux users?). This was the way Windows 3.x worked (and ELKS too, I think). <End history>:-)
Right now, however, you will be looking at a 32 bit pointer which can address a flat linear space of 4 GB (2^32).
However, you cannot directly address physical memory under Linux, or for that matter any modern multitasking OS that supports virtual memory (such as the Unices and Win NT, etc. You *can* do it under Win9x, I believe, if you're willing to use some trickery, but that is not relevant here). Your code will be running in its own process, which has its own virtual memory space which is mapped by the memory manager to the actual physical memory. This memory is mapped using page tables. Each process thus runs in its own memory arena, which effectively precludes you from accessing actual physical addresses. In any case, do remember that protected mode does not even use segment memory addresses, but instead uses selectors, which are very different creatures.
The second thing is that you are seeking to access the system BIOS area, which is actually not part of the user memory arena at all. It is part of the system area, and as such I am not sure whether a user space process will be allowed to access it at all (it is not allowed under Windows NT).
Thus, I believe that the only way you will be able to access physical addresses at all will be through a kernel construct, in this case a device driver. You will have to write a small device driver that accesses the required area for you, and returns a string with the result. You could use printk() if you just want to print the results out to the console.
Also, I think that you have to set up a special device in your proc file system to access your flash ram. Check in make menuconfig.
Don't know about this; why don't you check it out? If you can access the flash through the BIOS, it will save a whole lot of trouble writing drivers.
BTW, Philip, the 8088 does (did?) not have protected mode.
Rgds,
Krishnan
__________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com
Sometime Today, S. Krishnan assembled some asciibets to say:
BTW, Philip, the 8088 does (did?) not have protected mode.
No, I was referring to the address bus size actually. I did have a 8088 many moons ago, and ran Win 3.0 in real mode - without a mouse. It's also where I learnt to program the hardware.
Philip
--- "S. Krishnan" sri_krishnan@yahoo.com wrote:
--- Philip S Tellis philip.tellis@iname.com wrote:
On Wed, 3 Oct 2001, Trevor Warren wrote:
Don't know about this; why don't you check it out? If you can access the flash through the BIOS, it will save a whole lot of trouble writing drivers.
[snip] Again Philip and Krishnan.... Thx for the tremendous insight into the issue. I could pat u on ur back personally for the insight u hav given me into the matter...'-)
The issue still remains.....should i or shouldn't i use a C prog to make this BIOS memory access, some1 on the LIH was kind enough to suggest this soln. Do u think this is the right 1 around...
-->Untested code
int fd = open ("/dev/mem", O_RDONLY); seek (fd, 0xfcdbd, SEEK_SET); read (....); ... close (fd);
-->Untested code
or would i be forced into writin a Kernel Device driver 'cause of the reasons of my c/c++ progs havin their own memory space which isn't allowed to directly access memory locations. Will this iostream() operation opening a read buffer into /dev/mem be the right way to get the job done. Also if 0xfcdcd the corresponding 32bit address for f000:cdcd in REAL mode access.
Trevor Warren
BTW, Philip, the 8088 does (did?) not have protected mode.
Rgds,
Krishnan
Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com _______________________________________________
===== ( >- LINUX, It's all about CHOICE -< ) /~\ __ http://www.trevorwarren.com __ /~\ | ) / mailto: trevorwarren@yahoo.com \ (/ | |_|_ \ Urgent ->9820349221@maxtouch.co.in / / _|_| ___________________________________/
__________________________________________________ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
--- Trevor Warren trevorwarren@yahoo.com wrote:
--- "S. Krishnan" sri_krishnan@yahoo.com wrote: The issue still remains.....should i or shouldn't i use a C prog to make this BIOS memory access, some1 on the LIH was kind enough to suggest this soln. Do u think this is the right 1 around...
-->Untested code
int fd = open ("/dev/mem", O_RDONLY); seek (fd, 0xfcdbd, SEEK_SET); read (....); ... close (fd);
-->Untested code
A reference to the PROC (5) man page describes /dev/mem as providing direct access to the physical memory, before it is virtualized into different user processes. However, it clarifies that /dev/mem is *not* the same as the mem in proc. I quote below:
<snip>
mem
This is not the same as the mem (1:1) device, despite the fact that it has the same device numbers. The /dev/mem device is the physical memory before any address translation is done, but the mem file here is the memory of the process that accesses it. This cannot be mmap(2) \h'-1''ed currently, and will not be until a general mmap(2) is added to the kernel. (This might have happened by the time you read this.)
<endsnip>
I guess you should be OK if you try to open /dev/mem and do a seek on the resulting handle. Please check the permissions on the device before you execute the program - my BSD 4.2 box here at work has /dev/mem set to be accessible only to root. Try it and see if it works; I think it ought to. If not you can always write that kernel module...
or would i be forced into writin a Kernel Device driver 'cause of the reasons of my c/c++ progs havin their own memory space which isn't allowed to directly access memory locations.
As above.
Will this iostream() operation opening a read buffer into /dev/mem be the right way to get the job done.
That is one way; another would be to use the C file operations functionality in glibc rather than this C++ stuff, which I would advise; it's less complex (at least for me).
Also if 0xfcdcd the corresponding 32bit address for f000:cdcd in REAL mode access.
do a ((0xf000<<4) | 0xcdcd) - this will verify that the result is 0xfcdcd.
HTH,
Krishnan
__________________________________________________ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
--- "S. Krishnan" sri_krishnan@yahoo.com wrote:
A reference to the PROC (5) man page describes /dev/mem as providing direct access to the physical memory, before it is virtualized into different user processes. However, it clarifies that /dev/mem is *not* the same as the mem in proc. I quote below: mem
[snip] thx again Krishnan.....for the insight into the matter. The stuff's done thx to u, philip and Prakash from LIH. This time around is another issue, but nothin for concern. The machine i hav compiled the code on is a 128Meg RAM machine. Now the code RUNs works perfecto on this 1 but when the same code is RUN on 64Megs of RAM the code won't be able to find the data in the same location as it did in the prev case. I am at a loss to understand....the data that i inserted into the BIOS which i am accessin at RUN time is at the same location irrespective of the amounts of RAM in the machine. The difference remains that while the code executes only at run time am i actually askin it to make the fetch from absolute memory address 0xfcdcd. I haven't tried this 1 out, but i GUESS, when i recompile the code with the 64Megs, things will work again. Why is this limitation occuring....i understand that the reference to the abso memory location in the EEPROM is dynamic but the data fetch location still doesn't change....This is really strange......but also very interesting...'-)
Trevor Warren
This is not the same as the mem (1:1) device, despite the fact that it has the same device numbers. The /dev/mem device is the physical memory before any address translation is done, but the mem file here is the memory of the process that accesses it. This
do a ((0xf000<<4) | 0xcdcd) - this will verify that the result is 0xfcdcd.
HTH,
Krishnan
===== ( >- LINUX, It's all about CHOICE -< ) /~\ __ http://www.trevorwarren.com __ /~\ | ) / mailto: trevorwarren@yahoo.com \ (/ | |_|_ \ Urgent ->9820349221@maxtouch.co.in / / _|_| ___________________________________/
__________________________________________________ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
--- Trevor Warren trevorwarren@yahoo.com wrote:
This time around is another issue, but nothin for concern. The machine i hav compiled the code on is a 128Meg RAM machine. Now the code RUNs works perfecto on this 1 but when the same code is RUN on 64Megs of RAM the code won't be able to find the data in the same location as it did in the prev case. I am at a loss to understand....the data that i inserted into the BIOS which i am accessin at RUN time is at the same location irrespective of the amounts of RAM in the machine.
Maybe RAM access differences - as an uneducated guess, I agree with your idea that you will need to recompile to run the code on the new machine. As to why, I will not hazard a guess, since I am not at all familiar with the internals of the /dev/mem system
Rgds,
Krishnan
__________________________________________________ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
Hi everyone,
I have installed Redhat 7.1, I found that there are two "rc.local" file, one is in the "/etc/" directory and the other is in the "/etc/rc.d/" directory and both are exactly the same.
On SuSE Linux I found that rc.local resides in /etc/rc.d/, what is the significance of the other rc.local file ?
I dunno whether I should mention it here, I have crack for XWinPro, anyone needs it can mail me.
Bhushan
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Oct 6, 2001 at 12:16, Bhushan Tiwari wrote:
I have installed Redhat 7.1, I found that there are two "rc.local" file, one is in the "/etc/" directory and the other is in the "/etc/rc.d/" directory and both are exactly the same.
I only have one in /etc/rc.d and I have Redhat (patched and firewalled, don't bother trying to break in).
Sometime Today, Bhushan Tiwari assembled some asciibets to say:
I have installed Redhat 7.1, I found that there are two "rc.local" file, one is in the "/etc/" directory and the other is in the "/etc/rc.d/" directory and both are exactly the same.
If you look really close, you'll find that they are both the same file. If you edit one, the other changes too. It's probably a little troll, sitting on your disk, mirroring all your changes... then again, it could just be a symlink.
On SuSE Linux I found that rc.local resides in /etc/rc.d/, what is the significance of the other rc.local file ?
/etc is the FHS (File Heirarchy Standard) place for the rc.* and init.d files/directories. Earlier versions of distros used to put everything in /etc/rc.d. RedHat now follows the FHS (Debian always followed it), hence the change.
I dunno whether I should mention it here, I have crack for XWinPro,
No, you shouldn't. This group is about freedom. Any violation of such freedom cannot be allowed. Piracy violates the rights of the developer, and cannot be condoned. If you don't like the licence, don't use the software.
Philip
Hi everyone, rc.local in the /etc directory is a symlink to the /etc/rc.d/rc.local isn't it ? bye bhushan
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Hi all,
I have compiled new kernel (2.4.10) without module support. The box boots perfectly except a message in kern.log that "Cannot find map file". I use grub (instead of lilo) to boot.
The message above is first in the log when kernel boots.
Regards pankaj
On Fri, 5 Oct 2001, Pankaj Jangid wrote:
I have compiled new kernel (2.4.10) without module support. The box boots perfectly except a message in kern.log that "Cannot find map file". I use grub (instead of lilo) to boot.
Make sure your System.map file is in /boot. There should probably also be a symlink from System.map-2.4.10 to it. You will have to copy your System.map from /usr/src/linux
Philip
-
Bhushan Tiwari -
Pankaj Jangid -
Parul Mathur -
Philip S Tellis -
S. Krishnan -
Satya -
Trevor Warren