I own a Jensen for three month now and started to port some good old
Linux/Intel software this weekend. What I used was an 1.3.28 kernel together
with the gcc 2.7.0 (although I know that there exist newer versions, but I am
glad enough that my system is running... :-) ).
I want to port SVGALib and XFree, too, but I had trouble compiling them for
the first time. I mean, not that sort of normal trouble, but there is
something very strange with a couple of kernel includes:
As I understood it, every software that does some sort of (Intel-based) ported
I/O accesses has to include <asm/io.h>. If not compiling the kernel this
include file defines prototypes for inb/outb stuff (and some more). Note,
that I am well aware of the fact that all Alphas do map the I/O regs into
the normal memory address space.
Now, my problems arise after io.h includes the architecture-depended
<asm/jensen.h>. There inb/outb are redefined.
No problem, I thought, just comment the redefinitions out (in jensen.h) and
everything should work right! "Nearly" everything worked right. I wrote a
small program (some sort of a fast hack) that grabs some I/O permissions
and reads some I/O ports. This is what I found out:
1. I only have access to the I/O ports of the two serial COMs, the LP port,
the keyboard controller and the floppy controller. I have no access to
the VGA regs and the other regs of my ADAPTEC 1742 (the floppy controller
is placed on the board of the SCSI host adapter).
2. I get the following "data rythm" when I read all I/O regs:
data <0xff> <0xff> <0xff> data <0xff> <0xff> ....
I thought that exactly this should not happen, because the inb/outb
functions always shift register addresses before accessing them,
so that any user-level software has __not__ to worry about the effects
of the sparse address mapping.
3. If I do a 'cat /proc/ioports' the line for vga-regs is followed by
a '+' (something important??)
4. 'set_hae' is always undefined, but the linker prompts no warnings. Perhaps
someone can tell me where the __real__ inb/outb functions (and set_hae)
are defined. I found out that sethae (without underscore!) is a system
call.
After taking the redefinitions away it was even possible to compile SVGALib
(I only hoped (!) to have some success when running it), but all demos
cause segmentation faults and my own test progs got hung. I had to abort them
by CTRL-C all the time.
Perhaps someone can help me with this problem (it must occur with all other
architectures, too, because even their architecture-depended includes redefine
inb/outb related stuff).
Thanks in advance,
Stephan