Date: Fri, 16 Oct 2009 13:25:31 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jkim@FreeBSD.org Cc: xcllnt@mac.com, freebsd-arch@FreeBSD.org Subject: Re: x86BIOS and the ISA bus and low memory in general... Message-ID: <20091016.132531.377201063.imp@bsdimp.com> In-Reply-To: <200910161504.09685.jkim@FreeBSD.org> References: <200910161400.00564.jkim@FreeBSD.org> <20091016.122539.-1383511515.imp@bsdimp.com> <200910161504.09685.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200910161504.09685.jkim@FreeBSD.org>
Jung-uk Kim <jkim@FreeBSD.org> writes:
: On Friday 16 October 2009 02:25 pm, M. Warner Losh wrote:
: > In message: <200910161400.00564.jkim@FreeBSD.org>
: >
: > Jung-uk Kim <jkim@FreeBSD.org> writes:
: > : On Friday 16 October 2009 01:46 pm, Jung-uk Kim wrote:
: > : > On Thursday 15 October 2009 04:37 pm, Marcel Moolenaar wrote:
: > : > > On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote:
: > : > > > [[ redirected to arch@ ]]
: > : > > >
: > : > > > In message: <200910151431.53236.jkim@FreeBSD.org>
: > : > > > Jung-uk Kim <jkim@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?
: > : > >
: > : > > It depends on the platform. On an Itanium machine I have the
: > : > > VGA frame buffer is at physical address 0xA0000-0xC0000.
: > : >
: > : > The address is the same, then. :-)
: > : >
: > : > > The only requirement is that you use non-cached I/O,
: > : > > otherwise you get a machine check. This can mean a
: > : > > non-identity mapping or not. It all depends...
: > : >
: > : > I couldn't find a way to manipulate memory attribute directly
: > : > on ia64, i.e., mem_range_attr_{get,set}() and
: > : > pmap_mapdev_attr() only exist on amd64 and i386. Does
: > : > pmap_mapdev() set the attribute as UC?
: > :
: > : It seems pmap_mapdev() on ia64 uses IA64_PHYS_TO_RR6() macro. If
: > : I read the source correctly, then it is gives UC mapped "view" of
: > : the physical address, right? If so, orm(4) can simply do
: > : pmap_mapdev()/pmap_unmapdev() around bus_space_read_region_1().
: > : Am I right?
: >
: > I don't think that's the right solution here. The pmap_mapdev
: > stuff should happen when the resource is activated...
:
: For that, I guess we need another resource flag, e.g., RF_DEVICE,
: maybe?
No. The activate will be able to do this. If we need to, we can move
the activate from MI to MD.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091016.132531.377201063.imp>