[chulofiasco]

Here are some observations I've made while experimenting with the Personal Video option for the IP30 platform: 

Test System Config:

• 2 250 MHZ IP30 Processors
  
• Secondary unified instruction/data cache size: 1 Mbyte
  
• CPU: MIPS R10000 Processor Chip Revision: 3.4
  
• FPU: MIPS R10010 Floating Point Chip Revision: 0.0
  
• Main memory size: 1536 Mbytes
  
• Heart ASIC: Revision F
  
• Xbow ASIC: Revision 1.4
  
• Graphics board: EMXI
  
• Personal Video: unit 1, revision 2.0
  

 
Parts:
Location: /hw/node
      PM20250MHZ Board: barcode GMC898     part 030-1286-002 rev  B
Location: /hw/node/xtalk/15
            IP30 Board: barcode HHF024     part 030-1467-001 rev  B
Location: /hw/node/xtalk/15/pci/2
             FP1 Board: barcode KBP446     part 030-0891-003 rev  G
    PWR.SPPLY.ER Board: barcode AAE1370060 part 060-0035-003 rev  A
Location: /hw/node/xtalk/12
           MOT20 Board: barcode GKK281     part 030-1240-003 rev  D
Location: /hw/node/xtalk/11
             EVO Board: barcode JHY266     part 030-1156-003 rev  B
 
Encountered System Tolerances:
Memory:
Max Memory: 1.5 GB
Following errors will appear in the console if you’ve exceeded this limit, option will behave erratically.
WARNING: evoVgi1DMA: FAILED to get lowmem pool 14
WARNING: dms lomem: DMA page 0x18662 too high – set SRV_LOMEM_POOL
 
Note: Should modifying SRV_LOMEM_POOL resolve this 1.5GB limit, I do not know, as I don’t know how to set, or even what is, SRV_LOMEM_POOL.
 
CPU:
While not all CPU options have been tested, I have had success with a PM20-250 module.

A PM10-600 yielded the following errors in /var/adm/SYSLOG:
Jan  4 09:16:58 4A:IRIS unix: WARNING: _evo_i2c_reg Transfer failed: i2caddr 0x88 reg 89 rw 1 code -256
Jan  4 09:16:58 4A:IRIS unix: WARNING: _evo_i2c_reg Transfer failed: i2caddr 0x88 reg 90 rw 1 code -256
Jan  4 09:16:58 4A:IRIS unix: WARNING: _evo_i2c_reg Transfer failed: i2caddr 0x88 reg 91 rw 1 code -256 … continues
 
With this CPU, option behaves erratically: Composite and SVideo features on the option are nonfunctional, a connected O2 Cam will produce video in.
 
Note: This fellow seems to also have encountered the 600MHz incompatibility: Link to Struggles of Another
 
Additional Ruminations:
If you haven’t connected anything to the O2 Cam Port, expect to find this in /var/adm/SYSLOG:
Jan  4 17:29:32 3D:KILAUEA videod[1300]: impactBind: can't open /dev/mgv: No such file or directory
Jan  4 17:29:32 3D:KILAUEA videod[1300]: can't open /dev/mgv: No such file or directory
Jan  4 17:29:32 3D:KILAUEA videod[1300]: impactBind: Unable to add device impact (0)
 
The above message resolved for me, and did not reappear after connecting a Miranda VIVO SDI device to the O2 Cam Port.  (Error did not persist after removal of the Miranda device.)
 
The EVO has three configurations: EVO, EVO + Miranda (SDI) or EVO + O2 Cam.
 
hinv output will show the following for the base board:
Personal Video: unit 1, revision 2.0
 
With a Miranda device connected to the O2 Cam Port, hinv output changes:
Personal Video: unit 1, revision 2.0, SDI1 version 16 connected
 
With an O2 Cam connected to the port, hinv output changes again:
Personal Video: unit 1, revision 2.0, DigCam version 1.2 connected
 
Miranda Device:
Model: VIVO
ASS: 0069-9912-0
Docs: Click for Documentation

If anyone else has useful bits related to the above, please add them to this thread.  It would be helpful for future hardware explorers to have such a resource to reference.

---

Here are some related TechPubs:
OCTANE™ Personal Video Programmer’s Guide
OCTANE™ Personal Video Installation Guide
Octane® Workstation Owner’s Guide

[robespierre]

There are sometimes restrictions on where in memory I/O devices can access via DMA, depending on the number and size of address windows in IOMMUs or other chips. Notably, the EVO is derived from Impact Video for the Indigo2, on which physical memory is limited to 1 GB, so it is likely that it was not designed to access all of the memory installable on the Octane architecture. So to make this work, the kernel needs to reserve memory areas within the area accessible by the peripheral, and SRV_LOMEM_POOL appears to be the mechanism. Kernel parameters are set using systune(1M).

Code:

# systune -r SRV_LOMEM_POOL 1

using "-r" to limit the fallout to the running system only. But this parameter may need to rebuild the kernel in order to work, I don't know. You can search the database at /var/sysgen/mtune and see if it's documented.

The chips on the graphics and video boards are configured by commands set over the I2C bus, so somewhere in the system there is a I2C master. I'm afraid I don't know the details of how this is wired, whether it's exposed over the XIO connector, etc.

[chulofiasco]

Thanks, robespierre. I thought about using systune to tweak that, however I got the following response:

symbol: SRV_LOMEM_POOL not found

[robespierre]

"SRV" stands for SpeedRacer (Octane code name) Video. Try searching mtune for variations on those names, the error string may not have been updated.

[chulofiasco]

"SRV" stands for SpeedRacer (Octane code name) Video. Try searching mtune for variations on those names, the error string may not have been updated.

These are available:

group: srv (statically changeable)
        srv_number_of_pools = 2 (0x2)
        srv_poolsize = 52428800 (0x3200000)

group: evo (statically changeable)
        evo_number_of_pools = 2 (0x2)
        evo_poolsize = 52428800 (0x3200000)