The collected works of ssch1034

Dear All,

I am in the process of getting an SB0090 card for my sound-lacking Fuel. As it happens I have a rather simple
audio card (Creative ECTIVA TP0033, Vendor ID 0x1102 and device 0x0006) lying around and was aching to find out
whether the associated driver can be tweaked to accept this cheapie. Following the ideas of substituting these PCI vendor/device
keys which are used to register the card at the system with substitutes (as for the tg1 Copper cards) I changed the emu_dd.o driver
accordingly and waited what would happen. Just a quick autoconfig -vf and then it was time to boot...

Well the system didn't crash and went normal until the screen turned black and I was expecting a hardware reset.
But eventually (after 10 nail-biting seconds) it recovered with some PCI related complaints (what else would you expect at that stage..)
and continued booting as nothing ever happened. Well then I tried the hard inventory and to my absolute surprise I got a reported
audio card:

Iris Audio Processor: version EMU revision A0, number 1

All audio panels and applications worked, BUT of course NO sound was emitted from the speakers, except a click when I muted the sound
on the apanel.

What have I learned: By modification of PCI card drivers you get them at least to boot on this system - whether it'll work is whole different story.
So, I am thinking of getting at least one Terratec Aureon Cards (sky or space, not Fun and all the others) which have exactly the same
audio chip (Envy24HT ICE1724) as the M-Audio revolution 7.1 series. They all go for around 10-20 Euros on eBay if you'd find one, while
the latter is hardly ever for sale (at least in the non-US world).

Attached: stock picture of the audio card I played around with.



So best of luck in case you guys like to test an unknown card on your SGI system and maybe an unexpected jewel can be discovered.

Regards
Stefan

vishnu wrote: What editor did you use to change emu_dd.o? If I may be so bold as to enquire...

Dear Vishnu,

I just used hexedit, which is probably part of the nekochan's freeware. Hope that helps.

Regards
Stefan

recondas wrote: Thanks ssch1034, and let me echo foetz' welcome to nekochan.

On the odd chance you haven't already seen them or might find them useful, there are links to a few SoundBlaster/EMU related posts in the
The IP35 (Fuel, Tezro, O300, O350) Hardware Aggregator ; there was a brief disucussion on discovering compatible EMU10k1 boards a few years back; and there's some background info on audio devices (including EMU-based variants) in the audio library resources man page.

Is the TP0033 an EMU-based device? Be interesting to know what's hiding under the ECTIVA label on your board.

Thanks for the advice. I'll check the card and let you know. I wonder however, why would IRIX look it up in the patched emu_dd.o rather than
mad_dd.o or rad_dd.o if it wasn't a EMU card? As I only modified this object and got IRIX to accept it I am sure it must have been the correct
object file. After all the entries in emu_dd.o were already close to the IDs of this card (If I remember correctly I changed the device
from 0x0004 to 0x0006 or vice versa as the vendor id was the same). The thing is that the hardware might be different, but you're right - it
is worth checking.

I am currently bidding on ICE1724HT Cards and see how I go with these M-Audio equivalents (at least from a chip-wise perspective they should be compatible).

Another big endeavour would be to write your own PCI driver. But that is probably way out of reach unless you have a great deal of experience.

Cheers
Stefan

recondas wrote: Thanks ssch1034, and let me echo foetz' welcome to nekochan.

Is the TP0033 an EMU-based device? Be interesting to know what's hiding under the ECTIVA label on your board.

There is absolutely nothing printed/etched onto the chips surface! That's odd.
Other sources identify it as a OPTi 82C929A with 20x30x2 pins
which can also be found on a legacy ISA (16-bit) sound card


Regards
Stefan

ivelegacy wrote: hi
I am still blocked with 3Com 3C996B-T Gigabit Network Card, I got one but ...
I prefer to have an original card instead of hacking the flash (I do not have the equipment to fix the CRC)
which does not completely work, Irix claims errors, and I do not want to patch the driver
...

I don't have a card and aiming for an original one is a noble course, BUT in case your happy with a CRC corrected one,
I might be able to assist:
Mine is ..aehm, WAS a Compaq NC7770 with a s/n HZMR525.. and different PN, which IRIX didn't like.

82 25 00 43 6f 6d 70 61 71 20 4e 43 37 37 37 30 .%.Compaq NC7770
20 47 69 67 61 62 69 74 20 53 65 72 76 65 72 20 Gigabit Server
41 64 61 70 74 65 72 00 90 55 00 50 4e 0a 32 38 Adapter..U.PN.28
34 36 38 35 2d 30 30 33 45 43 02 30 45 53 4e 0a 4685-003EC.0ESN.
48 5a 4d 52 35 32 35 39 39 46 4d 4e 04 30 45 31 HZMR52599FMN.0E1
31 52 56 2c e9 00 00 00 00 00 00 00 00 00 00 00 1RV.............

So I also substituted most data with
82 20 00 53 47 49 20 47 69 67 61 62 69 74 20 45 . .SGI Gigabit E
74 68 65 72 6E 65 74 20 43 6F 6E 74 72 6F 6C 6C thernet Controll
65 72 00 90 5A 00 50 4E 07 39 32 31 30 32 38 39 er..Z.PN.9210289
45 43 04 30 30 30 32 53 4E 0A 57 45 43 52 46 46 EC.0002SN.WECRFF
36 41 38 39 4D 4E 04 31 30 42 37 52 56 32 78 00 6A89MN.10B7RV2x.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

noticing the wrong s/n, checksum and an Asset tag of COMPAQ (starting at 0x183 with YACOMPAQ), which I also didn't like.
So I changed that to YASGI (although apparently a genuine SGI card spits out N/A) and moving the remainder starting
with RW and checksum byte 0x70 up 3 bytes (SGI=3 vs COMPAQ=6) and making it 0x73 (70h+3h=73h).

For the CRC in the VPD section I left the first byte following RV (32h) as it was and removed the second and applied the script
(previously posted) to sum up all the bytes starting from PN to the RV bytes:

( echo obase=16
echo ibase=16
echo \(00 `cat $HEXDUMP | cut -b 1-$[3*16] `\)%100 | sed -e 's/ /+/g' | tr a-z A-Z ) | bc

with $HEXDUMP being:

82 20 00 53 47 49 20 47 69 67 61 62 69 74 20 45 . .SGI Gigabit E
74 68 65 72 6E 65 74 20 43 6F 6E 74 72 6F 6C 6C thernet Controll
65 72 00 90 5A 00 50 4E 07 39 32 31 30 32 38 39 er..Z.PN.9210289
45 43 04 30 30 30 32 53 4E 0A 48 5a 4d 52 35 32 EC.0002SN.HZMR52
35 39 39 46 4D 4E 04 31 30 42 37 52 56 32 22 00 599FMN.10B7RV2x.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

The difference of this value up to 00 is the checksum. So, for example, in my case I got DE and the CRC would be 22 as
DEh + 22h equals 100h or short 00h. Putting this value into the correct spot:

ethtool -E eth2 magic 0x669955aa offset 0x14e value 0x22

fixed the checksum issue as can be seen in lspci -vv:

0a:0e.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
Subsystem: Silicon Graphics Intl. Corp. Gigabit Ethernet (Copper)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (16000ns min), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 23
Region 0: Memory at f6400000 (64-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at d0900000 [disabled] [size=64K]
Capabilities: [40] PCI-X non-bridge device
Command: DPERE- ERO+ RBC=512 OST=1
Status: Dev=ff:1f.1 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=512 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
Product Name: SGI Gigabit Ethernet Controller
Read-only fields:
[PN] Part number: 9210289
[EC] Engineering changes: 0002
[SN] Serial number: HZMR52599F
[MN] Manufacture ID: 31 30 42 37
[RV] Reserved: checksum good , 49 byte(s) reserved
Read/write fields:
[YA] Asset tag: SGI
[RW] Read-write area: 115 byte(s) free
End
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: e6b26757af57dff4 Data: a19e
Kernel driver in use: tg3
Kernel modules: tg3

Note that I kept the original s/n of the Compaq card. Changing the MAC address didn't change the checksum,
so I assume you could put in there what number you fancy. MAC starts at 0x7e, in my case 00:0b:cd:52:59:5f.
The first 3 bytes point to HP/Compaq cards and the last are covered in the s/n. I guess that concludes my
mocking around with that card. Have fun.

Regards
Stefan