vince@tc.fluke.COM (Craig Johnson) (02/02/91)
I have been playing for some time with the idea of building my own combo board so that I could expand my system using the cheap RAM SIMMs that are available, get another couple of serial ports, and gain some experience toward constructing some more ambitious expansion cards. I've had the design worked out for some time now, but one thing that was holding me back was determining what the magic ID code is that is contained in the tiny ROM on the combo board (I intend to let the software believe that my combo board is a real AT&T combo board). A couple of days ago I finally was able to borrow a real combo board and examine it. Since the ID ROM was soldered-in, rather than unsolder it and try to read it in a PROM programmer, I decided to see if I could get at its contents through software. My first attempt was to try gaining access through /dev/mem (which I'd never played with before). Unfortunately, /dev/mem appears to only let you get to physical memory locations that are decoded in "user" mode. Most/all the I/O in the Unix PC is only accessible in privileged "supervisor" mode (used by the kernel). So I decided to try a loadable device driver instead. Starting with Mike "Ford" Ditto's vidram driver, it was a small effort to modify it to allow access to any physical address in the machine. The driver I created is accessed through a device called /dev/io. It is a character device. You simply open the device, seek to the address you want to read, and then read a stream of bytes -- as many as you want. It works beautifully. There was the ID ROM sitting from 0xc3fff0 to 0xc3ffff. I also read the 8530's registers just for fun. I have not tried using it to write to I/O yet, but it should work ok provided byte I/O is acceptable. Modifications would be need before you could use this to write to word-wide registers. So gang, is there anyone out there hacking on the guts of this machine that feels like this driver would help them? Let me know if you're interested and if warranted I'll post it in a few days. I'm looking forward to getting the device driver document from Thad so I can learn some about block devices next. I've been wondering if the vidram driver wouldn't work a lot better as a block device. Then the screen could be accessed with bcopy or maybe even with the DMA hardware. By the way, can anyone tell me the purpose of the subyte() and fubyte() calls in the vidram driver? They appear to simply move a byte at a time in/out of the "u" user structure. Why can't the data in the user structure be accessed directly like the other elements of the structure? ---- Craig V. Johnson ...!fluke!vince John Fluke Mfg. Co. or Everett, WA vince@tc.fluke.com ----
jmm@eci386.uucp (John Macdonald) (02/13/91)
In article <1991Feb1.184009.2624@tc.fluke.COM> vince@tc.fluke.COM (Craig Johnson) writes: [...] |By the way, can anyone tell me the purpose of the subyte() and fubyte() |calls in the vidram driver? They appear to simply move a byte at a time |in/out of the "u" user structure. Why can't the data in the user |structure be accessed directly like the other elements of the structure? I apologize if I'm telling people something they already know, especially since I haven't ever looked at the vidram driver or any other 3b1 driver, but here goes anyway. In other Unix kernels that I have worked on, fubyte and subyte are used to fetch and store a byte of data from/to the user address space. They are provided as routines (possibly macros) to allow enclosing the access in protection code that will catch addressing faults without causing a kernel panic. Usually the user structure does not need such protection however, unless it gets paged out to the swap area along with the rest of the process's data (I think that this is handled differently in different Unix implementations). If the driver is responding to an interrupt, then it has to allow for the possibility that the process that it is working for might have been swapped out. -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386