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

[M. Warner Losh]

[[ redirected to arch@ ]]

In message: <200910151431.53236.jkim@...>
            Jung-uk Kim <jkim@...> 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
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Marcel Moolenaar-4]

On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote:

> [[ redirected to arch@ ]]
>
> In message: <200910151431.53236.jkim@...>
>            Jung-uk Kim <jkim@...> 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
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/O ports don't exist and there's a memory region for generating
I/O port accesses, but the translation is not linear, so you
can't work with a single base and port offset to get this to work.
See ia64_ioport_address() in sys/ia64/ia64/machdep.c

--
Marcel Moolenaar
xcllnt@...



_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Jung-uk Kim]

On Thursday 15 October 2009 03:45 pm, M. Warner Losh wrote:

> [[ redirected to arch@ ]]
>
> In message: <200910151431.53236.jkim@...>
>             Jung-uk Kim <jkim@...> 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?

No, you are not.  It's just a non-functional prototype for non-PC
architectures. :-)

> 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...

You mean 15-16MB ISA hole, right?  It's not implemented yet.  Probably
I should but I haven't seen any BIOS requiring the memory hole ATM.

> 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.

Actually that's my goal but I wasn't sure whether it is ever usable on
*non-PC* arches.  Then, orm(4) debate caught my eyes. :-)

> 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.

Thanks, I will keep that in mind.

> 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.

No, I have no intention to support BDA emulation, never. :-) Only IVT
will be supported, e.g., vesa(4) calls POST on non-PC arches and it
sets up the INT 10h vector.  Subsequent INT 10h calls are naturally
emulated.

> 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?)

Correct.

> 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..

Yes, it's the former, at least for now, e.g., using VBE calls on
powerpc or sparc64.  If my memory serves, NetBSD or OpenBSD can call
video POST in ddb when display is corrupt, I think.

Jung-uk Kim
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Jung-uk Kim]

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@...>
> >            Jung-uk Kim <jkim@...> 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?

> I/O ports don't exist and there's a memory region for generating
> I/O port accesses, but the translation is not linear, so you
> can't work with a single base and port offset to get this to work.
> See ia64_ioport_address() in sys/ia64/ia64/machdep.c

It seems there are PC-compatible inline functions {in,out}[bwl] in
sys/ia64/include/cpufunc.h.  Will they work as I expect?

Thanks,

Jung-uk Kim
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Jung-uk Kim]

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@...>
> > >            Jung-uk Kim <jkim@...> 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?

Jung-uk Kim

> > I/O ports don't exist and there's a memory region for generating
> > I/O port accesses, but the translation is not linear, so you
> > can't work with a single base and port offset to get this to
> > work. See ia64_ioport_address() in sys/ia64/ia64/machdep.c
>
> It seems there are PC-compatible inline functions {in,out}[bwl] in
> sys/ia64/include/cpufunc.h.  Will they work as I expect?
>
> Thanks,
>
> Jung-uk Kim

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[John Baldwin]

On Friday 16 October 2009 1:59:58 pm Jung-uk Kim wrote:

> 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@...>
> > > >            Jung-uk Kim <jkim@...> 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 think you need to back up a bit.  Instead of having a bunch of MD
code to provide ISA access for each arch, instead do what Warner
suggests which is to create a psuedo ISA device that attaches to isa0
and acts as a proxy for ISA I/O.  It can allocate ISA resources for
both memory and I/O access and then use bus_space_*() accesses to
perform actual I/O.  This will be MI.  The only problem I can see with
this approach is if a BIOS call attempts to frob a resource that another
ISA device already owns.  There may be ways around that though.

--
John Baldwin
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[M. Warner Losh]

In message: <200910161400.00564.jkim@...>
            Jung-uk Kim <jkim@...> 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@...>
: > > >            Jung-uk Kim <jkim@...> 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...

Warner
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Jung-uk Kim]

On Friday 16 October 2009 02:25 pm, M. Warner Losh wrote:

> In message: <200910161400.00564.jkim@...>
>
>             Jung-uk Kim <jkim@...> 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@...>
> : > > >            Jung-uk Kim <jkim@...> 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?

Jung-uk Kim
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Jung-uk Kim]

On Friday 16 October 2009 02:19 pm, John Baldwin wrote:

> On Friday 16 October 2009 1:59:58 pm Jung-uk Kim wrote:
> > 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@...>
> > > > >            Jung-uk Kim <jkim@...> 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 think you need to back up a bit.  Instead of having a bunch of MD
> code to provide ISA access for each arch, instead do what Warner
> suggests which is to create a psuedo ISA device that attaches to
> isa0 and acts as a proxy for ISA I/O.  It can allocate ISA
> resources for both memory and I/O access and then use bus_space_*()
> accesses to perform actual I/O.  This will be MI.  The only problem
> I can see with this approach is if a BIOS call attempts to frob a
> resource that another ISA device already owns.  There may be ways
> around that though.

That's very interesting idea and it may be very useful for
paravirtualized environment, I guess.  However, it's beyond my free
time. :-(

Just in case, I updated the source and uploaded it here:

http://people.freebsd.org/~jkim/x86bios-20091016.tar.bz2

For the efficiency reasons, I'd like to keep the amd64/i386 code as
is.  Feel free to fill in the MI implementation if you want.

Thanks,

Jung-uk Kim
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[M. Warner Losh]

In message: <200910161504.09685.jkim@...>
            Jung-uk Kim <jkim@...> writes:
: On Friday 16 October 2009 02:25 pm, M. Warner Losh wrote:
: > In message: <200910161400.00564.jkim@...>
: >
: >             Jung-uk Kim <jkim@...> 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@...>
: > : > > >            Jung-uk Kim <jkim@...> 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
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Marcel Moolenaar-4]

On Oct 16, 2009, at 10:46 AM, Jung-uk Kim wrote:
>>>
>>> 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. :-)

On this one machine it happens to be the same. On another machine
there's no addressable memory below 768TB (yes, terabyte), so as
I said: it depends.

>> 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?

New KPIs are typically only implemented for i386 and amd64.
It's one of the many unnecessary difficulties one faces
when trying to port or maintain a platform.

> It seems there are PC-compatible inline functions {in,out}[bwl] in
> sys/ia64/include/cpufunc.h.  Will they work as I expect?

Yes, but it's always been my intention to remove them. Don't
base any implementation on the existence of these...

FYI,

--
Marcel Moolenaar
xcllnt@...



_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Marcel Moolenaar-4]

On Oct 16, 2009, at 10:59 AM, Jung-uk Kim wrote:
>
> 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?

Not quite. pmap_mapdev() assumes that the passed physical address
is valid. It not being a valid physical address was the pivotal
problem and the reason why I limited orm(4) to i386 and amd64.

--
Marcel Moolenaar
xcllnt@...



_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."