[nwst-dev] Video on the ns1000

[Jochen R. <jo...@pa...>]

Hi Santiago,

I posted a newer patch on sourceforge which allows to run the S3 chip at
640x480-8, or 80x30. I need to add support for multiple modes, and
perhaps a couple other items. The boot stage does not know how to talk
to the S3 chip, so that still goes over the serial port for now.

I think that XFree86 should work in frame buffer mode, but I could be
wrong. I have done very little testing with this driver so far.

> The filesystem:
> What I've been trying to do is setup a Debian to get it exported through
> NFS, the NFS is ro, so it gives some errors, but seems to work all the well
> that can be expected from this development we are trying to make.

Great, I will take a look at that.

> Starting X:
> Well, we have Linux running, and the pci bus seems to work ok for the
> network card, so, even thought the kernel seems not to be able to init the
> video card, I thought that maybe X could do it, I was going to go for X
> 3.3.6, but there is no compiled version of that on woody, also I seem to
> recall that our S3 is not supported on X 4.1.0, so I had to go for X 4.2.1
> wich is on unstable, tomorrow I'll try to compile X 4.2.1 for woody.

Maybe 3.3.6 works in framebuffer mode, I know fairly little about XFree86
inner workings.

I looked at your log file and had an idea why X may not work.

The NS1000 is essentially a PReP machine, which is what the 82660 host
bridge supports. PReP machines use a weird memory map, in that the addresses
seen by the PCI bus are not the same as those seen by the CPU. I am talking
about physical addresses here, so phys/virt translation comes on top of
that.

A good description of the PReP map is in the Motorola MPC106 UM page 3-2,
or http://e-www.motorola.com/brdata/PDFDB/docs/MPC106UM.pdf page 96.

The S3 chip is mapped on PCI address 0, which is physical 60x bus address
0xc0000000. This has nothing to do with the virtual address 0xc0000000
used as the kernel base.

Now when you do a cat /proc/pci on the ns1000, you see the S3 chip listed
with a 0xc0000000 base address. This is because somewhere in the PReP PCI
config cycle code conversion the address is translated.

XFree86 4.2, otoh, seems to read the value un-translated, sees the 0, and
decides that the device is not mapped, i.e. not usable.

So one option would be to try setpci and change the bar0 from 0x0 to e.g.
0x08000000. The ethernet chip is mapped at 0x04000000 pci or 0xc4000000 cpu
physical. Note: /proc/pci seems to not get updated when pci registers are
changed. I think /proc/bus/pci/00/0e.0 does change dynamically.

sh-2.04# cat /proc/pci
PCI devices found:
  Bus  0, device  11, function  0:
    ISA bridge: IBM Fire Coral (rev 3).
      I/O at 0x100020 [0x100027].
  Bus  0, device  12, function  0:
    Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 37).
      IRQ 15.
      Master Capable.  Latency=128.  Min Gnt=6.Max Lat=255.
      I/O at 0x100000 [0x10001f].
      Non-prefetchable 32 bit memory at 0xc4000000 [0xc400001f].
  Bus  0, device  14, function  0:
    VGA compatible controller: S3 Inc. 86c775/86c785 [Trio 64V2/DX or /GX] (rev 20).
      IRQ 9.
      Non-prefetchable 32 bit memory at 0xc0000000 [0xc3ffffff].
sh-2.04# 
sh-2.04# hexdump /proc/bus/pci/00/0e.0
0000000 3353 0189 0300 0002 1400 0003 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
0000030 0000 0c00 0000 0000 0000 0000 0001 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
*
0000100
sh-2.04# 

PCI bar0 is at offset 0x10. Offset 0x30 is the ROM address, 0x000c0000 in
this case.  the hexdump output is little endian 16-bit words printed as
big endian, I think.

I will put some code into the boot stage to remap the S3 chip in the next
patch.

Jochen