x86BIOS and the ISA bus and low memory in general...

[M. Warner Losh]

[[ redirected to arch@ ]]

In message: <200910151431.53236.jkim at FreeBSD.org>
            Jung-uk Kim <jkim at FreeBSD.org> writes:
<snip>
: This is actually very interesting discussion for me because one of my 
: pet projects is extending x86bios to support non-PC architectures.  
: If anyone is interested, the current source tarball is here:
: 
: http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2
: 
: Especially, please see the code around #ifdef X86BIOS_COMPAT_ARCH.  
: Basically, mapping I/O ports and orm(4) is missing.  We don't have to 
: implement I/O ports but orm(4) vs. bus_space(9) is critical to make 
: it a reality.  Please consider it as a real practical example for 
: orm, not just a blackhole driver. :-)

I thought that most video cards had I/O ports as well as video RAM
that needed to be mapped...  Am I crazy?

I'm looking at the code and have a few questions.

It looks like you are allocating memory from 0x1000 to 0xa0000 with a
contig malloc, and then redirecting the emulator's read/write into
that array.  But I don't see where the memory reads for the so-called
ISA ROM hole are going.  I was looking for that hoping I could find
them so I could comment on them...

orm uses bus_space today to do its read/write of the memory.  I'd
imagine that if you wanted to touch actual hardware, then you'd need
to have drivers and/or the emulator use the same path to accomplish
this.

While in theory one could have multiple ISA busses in a system, as a
practical matter nobody does this.  Even when you have weird expansion
busses on laptop docking stations, you'd have them all mapped into one
space.  This means we can likely make some simplifying assumptions
that there is a single ISA bus on the system.  I don't know if we have
to make that assumption, but it is something to keep in the back of
our heads.

This suggests that the emulation device would have to attach somehow
to the ISA bus to make sure that the right translations (wherever they
happen) can happen.  But there's a catch...

The readw/readb macros in the atkbd.c driver likely need to change to
bus space macros of some kind to make this work.  I'm unsure how,
exactly, to make that happen since these addresses aren't for anything
on the actual ISA bus, but rather are for data that's contained in the
contigmalloc'd area.  They aren't really ISA bus addresses, yet they
are expected to be there by the drivers.  bus_space suggests itself
for this as well, but it isn't at all clear how that might be
accomplished because ES could point anywhere in the first MB of RAM
(since 16-bit operations are limited to 1MB with segments, right?)

This is a very interesting project...  Is the goal to emulate the BIOS
or execute the BIOS that might be loaded on the expansion cards in
these weird environments.  I'm guessing the former, but you never
know..

Warner