9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] I hate Jim!
@ 2004-01-19 18:46 Lucio De Re
  2004-01-19 19:09 ` Lucio De Re
  0 siblings, 1 reply; 4+ messages in thread
From: Lucio De Re @ 2004-01-19 18:46 UTC (permalink / raw)
  To: 9fans mailing list

In fact, I don't!  I was looking for a catchy subject.

I have made a minute amount of progress with the SiS 550 AGP/VGA
controller, to the extent that I seem to be reflecting the aperture
location and size correctly (I have changed the size and it got
picked up correctly - the base didn't move, though, I wonder if it
ought to have).

Little did I know how many things are conspiring against even an
old programming hand like me getting a VGA driver working.

The SiS 550, according to the developer who produced the XFree86
driver I'm using as the documentation, is entirely undocumented.
SiS have supplied unfinished device drivers to the XFree86 project
and are almost actively denying access to their technical information.

That whinge out the way, I'm assuming that the following questions
will not turn out to be so SiS specific that no one will be able to
answer them.

In the XFree86 driver, I find the following snippet:

pSiS->IODBase = pScrn->domainIOBase;
/* We "patch" the PIOOffset inside vgaHW in order to force
 * the vgaHW module to use our relocated i/o ports.
 */
VGAHWPTR(pScrn)->PIOOffset = pSiS->IODBase + (pSiS->PciInfo->ioBase[2] & 0xFFFC) - 0x380;

I took the liberty of moving the first line closer to the point where
it is firstly significant for the sake of clarity (I wish the developer
had done it, took me a while to put the two sections of the code
together).

The 0x380 is clearly a magic number relating to VGA registers (primary
VGA?  or more global, even?): I note that the Plan 9 code uses it as
the base for the VGA registers.  The XFree86 driver uses offsets from
this, with some glaring inconsistencies.

What I totally fail to discover or understand, is the "domainIOBase".
I presume it is an XFree86 entity, but I can't easily find out how it
is established and used.  A nudge in the right direction will help, I
think.  Then, I suppose I have to accept as gospel truth that the I/O
ports get relocated.  Again, I can't fathom how that happens, or why,
or where.  Maybe one of you has seen analogous behaviour elsewhere and
can explain it.  Private mail is perfectly fine.  I keep hoping that
at the end of this exercise I'll be able to provide documentation that
will help in future attempts, but that may be a pipe dream.  If it
does happen, I'll be keen to include any suggestions from better
skilled developers in the final document, so please let me know if
that's OK with you.

Lastly, at least for the now, I have no idea what this MMIO thing is
all about.  I get hints that wondrous things can be done with it, but
I can't piece enough bits of usage either in the Plan 9 code or in the
SiS driver for XFree86 to indicate how to set it up or use it.  I feel
like I'm totally blind to some perfectly obvious facility.  Are there
any references that might help me understand this concept?  And how it
fits into the scheme of VGA management?

I get a very vague feeling that it involves being able to used queued
I/O as well, but I really have no clue.

Now, having made it clear that I really know extremely little about
the target jmk set me (I'm not sure I'm not the butt of a very
complex joke), let me confirm your scepticism by explaining how
far I got.

I can now type:

	echo type sis550 > /dev/vgactl

and get back:

	Looking for a SiS adapter
	Looking for some I/O details
	Probably vain quest for map tables
	PCI aperture sizes: 0xa1 => 8388608
	Aperture: at 0x90000000 - Size: 8388608

thereafter:

	cat /dev/vgactl

yields:

	type sis550
	blank time 30 idle 0 state on
	hwaccel on
	hwblank off
	panning off
	addr 0x90000000

I used Kenji's i81x driver as template, thank you, Kenji.  I'll refrain
from commenting on the XFree86 code, it's a gift horse.

Anyone wants to see the mess I'm trying to disentangle, shout and I'll
post it to my web site, I won't offer, it's really not anything to be
proud of.  Although the fact that my PCI configuration access (read)
functions actually worked first time after I discovered you have to
read four bytes at the time had me utterly amazed.

In short:  Help!

++L


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9fans] I hate Jim!
  2004-01-19 18:46 [9fans] I hate Jim! Lucio De Re
@ 2004-01-19 19:09 ` Lucio De Re
  2004-01-19 23:06   ` [9fans] General factotum questions Jack Johnson
  0 siblings, 1 reply; 4+ messages in thread
From: Lucio De Re @ 2004-01-19 19:09 UTC (permalink / raw)
  To: 9fans mailing list

On Mon, Jan 19, 2004 at 08:46:39PM +0200, Lucio De Re wrote:
>
> Now, having made it clear that I really know extremely little about
> the target jmk set me (I'm not sure I'm not the butt of a very
> complex joke), let me confirm your scepticism by explaining how
> far I got.
>
One other thing may be critical:  The XFree86 code uses, as you
may have noticed in the snippet I mentioned, pSiS->PciInfo->ioBase[2].

The Plan 9 PCI descriptor does not include I/O details.  Can this
be corrected for future use, or am I barking up the wrong tree?
Could somebody with the details, please tell me where this information
can be retrieved from the PCI configuration table, if I have to
snoop that for the stuff I seem to need?

++L


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [9fans] General factotum questions
  2004-01-19 19:09 ` Lucio De Re
@ 2004-01-19 23:06   ` Jack Johnson
  2004-01-19 23:31     ` mirtchov
  0 siblings, 1 reply; 4+ messages in thread
From: Jack Johnson @ 2004-01-19 23:06 UTC (permalink / raw)
  To: 9fans

Now that my wife is making the migration over to her new iBook (and now
that I have a laptop to borrow), I'm slowly working my way back into
the fold and re-installing Plan 9 on my box at home.

Because it's been a while, I'm unfamiliar with the day-to-day usage of
factotum.  I know what it does and generally how it works, but does
factotum require an authentication server in order to function
properly?  Is it best to run a cpuserver kernel on a standalone
workstation to get full factotum functionality?

On a related note, I was trying to run vncs so I could work from the
couch and compile the cpuserver kernel, set up drawterm on the laptop,
set up Venti, etc., and noted that it uses the Inferno/POP password
from factotum for authentication.  I read that passwd will prompt to
change the Inferno/POP password, which (of course) I tried but it
replied that there was no auth server, which led me to the
factotum/authserver symbiosis question.

(I also read that the fossil snapshots should show up in /snapshot,
which doesn't exist in a standard fossil installation.  Any trick
there, or additional docs I should read to clarify that?)

Any pointers would be greatly appreciated.

-Jack



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9fans] General factotum questions
  2004-01-19 23:06   ` [9fans] General factotum questions Jack Johnson
@ 2004-01-19 23:31     ` mirtchov
  0 siblings, 0 replies; 4+ messages in thread
From: mirtchov @ 2004-01-19 23:31 UTC (permalink / raw)
  To: 9fans

> Because it's been a while, I'm unfamiliar with the day-to-day usage of
> factotum.  I know what it does and generally how it works, but does
> factotum require an authentication server in order to function
> properly?  Is it best to run a cpuserver kernel on a standalone
> workstation to get full factotum functionality?

factotum works by storing your secure keys and authenticating for you
whenever you're required to authenticate somewhere.  by itself
factotum doesn't require an authentication server to work properly,
because there is nothing it authenticates, instead it is just used as
a shortcut so you won't have to type your passwords more than once.

for example my factotum currently holds passwords for a few ftp
servers, a few ssh ones, several plan9 machines and random stuff like
vnc sessions.

to make factotum always remember your passwords you need secstore (but
not an auth server).

>
> On a related note, I was trying to run vncs so I could work from the
> couch and compile the cpuserver kernel, set up drawterm on the laptop,
> set up Venti, etc., and noted that it uses the Inferno/POP password
> from factotum for authentication.  I read that passwd will prompt to
> change the Inferno/POP password, which (of course) I tried but it
> replied that there was no auth server, which led me to the
> factotum/authserver symbiosis question.

try auth/changeuser instead of passwd -- run it as the host owner and
reset the authentication information.  that's a workaround though, I'm
not sure I know what the proper answer to your question is.

>
> (I also read that the fossil snapshots should show up in /snapshot,
> which doesn't exist in a standard fossil installation.  Any trick
> there, or additional docs I should read to clarify that?)

/snapshot is local for the fossil server, i.e.  you see it only when
connected to the console..  in that sense the venti archive shows up
under /archive and the active partition (the one mounted as your
/root) is under /active.  when you want to see the permissions of a
current file using the fossil command 'stat' you prepend /active to
the path, i.e.:

	main: stat /active/usr/andrey/tmp

the 9fs command may be used to mount /snapshot and /archive under your
namespace -- 9fs snap mounts /snapshot at /n/snap; 9fs dump mounts
/archive under /n/dump.  when you set up 'snaptimes' in fossil and
accumulate a bit more data in venti you'll see how they're laid out on
disk.

the yesterday(1) and history(1) commands will use /n/dump and do the
9fs dance for you.

andrey



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-01-19 23:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-19 18:46 [9fans] I hate Jim! Lucio De Re
2004-01-19 19:09 ` Lucio De Re
2004-01-19 23:06   ` [9fans] General factotum questions Jack Johnson
2004-01-19 23:31     ` mirtchov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).