The collected works of canavan - Page 1

lisp wrote: When I backed up my IRIX disks, I used linux. dd the raw device to a file, and use it as you would an ISO.

I think the problem was to make bootable CDs from the files downloadable from sgi.com. I for one would like to have bootable 6.5.21 CDs. Has anyone here tried that (with any release)? I think the method to create bootable CDs has been discussed on mailto:[email protected] or the debian mips list. (don't worry, I'm not trying to run linux on my O2, I've got some cobalt computers that have mips CPUs)

If there are all the files to boot of the net, one should be able to make a bootable CD as well, after all, you can boot of the harddisk after you have installed it. Once you have the files on an EFS partition, you probably have to install sash etc. in the volume header. What else would be required?

Hakimoto wrote: I´m sure they have a borg that churns them out for ´em.

It turns out to be easy. Follow the advice at sgiaddict, but add the following steps:

resize the volume header with "fx -x" to about 22 MB, while you're there, set the boot info so that boot=swap=0.
6.5.21, CD 1 needs a 600MB filesystem.
Grab sashARCS and sash64 from the eoe_ files. while you're at it, get the fx and stand/ide files as well and rename them apropriately. (hey, how does that work without dd??? There just must be a way with inst).

use hexedit to look into the "sa" file that came with the overlay



There's the miniroot at offset (512*0x04A7) and it's 0x0124F800 bytes long. Extract with dd. Use bc with ibase=16 to convert if you have nothing else at hand. For 6.5.21 dd if=sa bs=1 skip=$[1191*512] count=19200000 of=../mr works, and dd if=sa bs=512 skip=$[1191] count=37500 of=../mr is quite a bit faster.

Install sash* and mr in the volume header (should look like this afterwards):


then drop the fx.* and ide.* files in the /stand directory, everything else goes into /dist.

You may have to make .IM and .IM_XXXX files similar to this:


I chose XXXX=2664, but I have no Idea how SGI makes them up.

dd as in sgiaddict's instructions, then just cdrecord -v myefsimage.img

At least that seems works for me, I just booted to the miniroot install

Some more things one shouldn't forget when making efs CDs:

remove /lost+found, it's of no use on a CD
umount the filesystem before dd-ing it into your image
you can also do (dd if=dev/rdsk/dks0d2vh bs=4096 && dd if=/dev/rdsk/dks0d2s7 bs=4096) | cdrecord -v - to get by without an image
use mkfs to delete the partition before starting the next CD instead of rm -rf, since this will cause the files copied there afterwards not to be as fragmented.

One more bug to fix: after exiting, one cannot move the mouse past x=1280, and I suspect y=1024. Logging off and back on fixes that, but it feels kind of weird not to be able to reach my ov on the far right of my desktop.

warerat wrote: The PCI riser has a Dallas serial prom (looks like a little TO-92 transistor) on it with the serial number of the machine encoded on it. I think if it's not there the ethernet won't work or some message comes up at the console.

Neither the ethernet nor any licensed software will work if the PCI riser is not plugged in. However, one could do away with the metal frame, or use a R7k CPU in an R10k Mainboard module, with all the additional space for the R10k/R12k CPUs. I wouldn't think that is neccesary, given theminiscule power consumption of the R7k CPUs.

There are at least two different O2 R5k chassis - one that is upgradable to R10k (has two screws at the bottom that hold the separator between the leftmost drivebay and the mainboard, and the small rectangular black plastic part under the leftmost drivebay is removable), and the other one that isn't (no screws for the separator, one larger plastic part under all drivebays and a/v module).

chicago-joe wrote: LoWeN Wrote

would an O2 with an R5K@180Mhz be a "good base" for that mod.

The cpu chips on the 180 and 200MHz O2s are V5000 series chips made by NEC and are completely different, swapping a RM7000C chip for a V5000 chip is out of the question. This was my answer to a question Shtoink had earlier on the same subject:

I don't know much about Indys, but the 180 and 200MHz O2s use the NEC v5000 cpu chip. I'll bet the R5000 series Indys use the same series of cpu chips. NEC made a V5000A series chip (pin and command compatable) that maxed out at 266MHz and I have seen these around so they are available. I downloaded the data and use guides for both and the only problems I see are that the 150, 180, 200 cpus use a 3.3V core and IO voltage and the 250 and 266 cpus use a 2.5V core and 3.3V IO voltage and there is not a 2.5 mutiplier for the core speed. I don't know how hard it would be to modify the voltages on the cpu card, if it could be done at all. I don't know what would happen if you ran a 266 chip with 3.3V on the core, it would get HOT so you would have to cool it well and I would think the chip life would be shorter but it might still last quite a while and should be much better in performance. To get around the core speed problem you would have to change the control resistors on the PLL chip (ICS9159-10) to change the Xtal to output ratio to 93/20 (66MHz X cpu mult of 4) to run the chip at 266MHz, this should be easy enough to do. I might try this with an O2 200MHz cpu board, I would think if it works on an O2 board it could be made to work on an Indy cpu board.

[...]

I think Indys would be a much better candidate for the VR5k upgrade, since at least some of the CPU boards have voltage regulators on them (according to http://www.reputable.com/indytech.html ). There's one visible on http://www.schrotthal.de/sgi/indy/indy_r5000_cpu.jpg In an indy, there should be some glue logic between the 5V and 3.3 V parts, so with some luck, I/O and core voltages are separate already.

My O2 R5k modules don't look like it could be possible to convert them to 2.5V core without some kind of adapter socket.

chicago-joe wrote: I don't know much about Indys, but the 180 and 200MHz O2s use the NEC v5000 cpu chip. I'll bet the R5000 series Indys use the same series of cpu chips. NEC made a V5000A series chip (pin and command compatable) that maxed out at 266MHz and I have seen these around so they are available. I downloaded the data and use guides for both and the only problems I see are that the 150, 180, 200 cpus use a 3.3V core and IO voltage and the 250 and 266 cpus use a 2.5V core and 3.3V IO
[...]

Voltages will be the smallest problem, as opposed to packaging - O2 and Indy use PGA CPUs, the VR5000A is available as BGA only, with a different package size (29mm edge length vs 47mm) and different pin count. Someone would have to design something like this

http://www.isipkg.com/images/adp_bga_pga.jpg

and fitting a voltage regulator on that pcb should be easy, compared to the design of the thing itsself.

lisp wrote: I haven't got any images from Cyclone either - I thought it might just be my graphics - I shall look into it.

I seems it's my good old friend, the gcc -O2 and beyond optimization bug. I don't remember which of the four files have to be compiled with -O0 to get anything visible, but I think it goes along with an initialization problem in cyclone, i.e. I have to resize the window before anything gets drawn. Cyclone is nice but slow as molasses (on my O2 R5k/200, that is).

CC -o hello hello.cpp -linventor

or so might help. You may need -lInventorXt and lSgm -lXm -lXt -lX11 as well, and, asl always with linking, order matters. Additionally, you symbols look so totally un-mangled, so maybe you really should try using an actual C++ compiler.

I can only see two possible reasons why this could fail: (1) DVD-Roms may not allow 512 byte sectors off DVDs (or require special instructions to be sent to do so) and (2) what's the size limit of EFS anyway? I don't think either of them are going to get in the way, but lacking DVD drives or recorders, I won't be able to try in the near future. If you are going to test this, try making a bootable CD-R first, and when that works, record the very same image to a DVD(+-)RW and try booting that.

I've spent a few hours on that last november, decided that crossVec is useless and commented out every reference to it. Works for my O2s, mailed rss's author and never heard back from him. I must have forgotten to post my results here ;-(

Have you tried burning the exact same image you have used successfully for a CD on a DVD? If so, and you can't even mount that DVD with irix running normally (i.e. not miniroot), then I strongly suspect a problem with sector size as someone mentioned on comp.sys.sgi.*. What kind of drive are you using on your SGI? Something official, a Toshiba? Or a recorder with ACARD?

Has anyone here ever tried modding a 030-0950-002 RADical PCI card for 3.3V? Does the card work with 5V (e.g. in an O2) afterwards? According to the old page on reality.sgi.com that's not even on realitydiluted anymore, the pins to be cut are "P2 pins A10,A16,A59,B19 and B59", essentially all the +5V/VCC pins. Did I count them properly as in the images below? (shamelessly lifted from viewtopic.php?t=8556&start=30 )

Do you happen to have firmware packages for ST3146707LC or ST373307LC?

Dr. Dave wrote: The trick, as you've noted then, is to figure out what SGI used, and hack the driver which should work fine.

Don't hack the driver, hack the card. There's a thread somewhere here where at least two methods are described to do this, and there's also a list of "acceptable" PCI ids (and there's only one for the 5704):
http://forums.nekochan.net/viewtopic.php?p=22940#p22940

competentcompton wrote: added neko_paraview323.tardist to incoming.

neko_paraview323 refers to its parts as My Product/My Image/My Subsystem, could you please change that to neko_... and sw.eoe like all(?) other nekoware packages do?

You don't need PCI-X, a bog standard 32bit PCI slot is enough, assuming there are no components physically blocking the space behind the slot.

Looks like you need to fix your -I flags for cc and CC as well. In addition to that you'll have to add an -rpath to the LDFLAGS. The easiest way to get going is to just export all the environment variables as documented in the wiki http://www.nekochan.net/wiki/index.php/Packaging_Software#Build_Environment

You can really just write the entire dump nekonoko posted into any card. The serial number (SN) in there has no practical use. The start of the VPD section is apparently always 0x100 (= 256 dec). I've used the following script to call ethtool, hexsgivpd contains just the hex values, preceded by exactly one space each, as shown in the example below. Everything after byte 48 (the clear text part) is ignored. To actually execute this, remove the echo before ethtool.


If you really think you have to adjust the serial number or anything else, you should fix the checksum as well. The checksum is called RV and besides the checksum istself, it is apparently used to pad the VPD to 96 bytes, so that you'll have to adjust the length of the RV field as well if you delete or add anything. The checksum itself is in the first payload byte, i.e. the second byte after RV, the first being the length. The checksum does not cover the clear text name of the device (e.g. "SGI Gigabit Ethernet Controller"), but everything after that, including the RV itself. The sum of all the bytes covered modulo 256 should be 0x00. I've used the shell code below to compute the checksum over the hexdump, this time just hex bytes with one space, no linebreaks etc. The original contents of the vpd of my HP NC7770 was:
I doubt that upgrading the firmware will make any difference at all, most of the eeprom is just a PC Bios boot rom, and I'm certain that the irix driver brings along its own copy that matches the driver. The firmware itself is tiny, the largest for the tg3 driver in linux is less that 2000 bytes long.

I just converted an IBM dual port netxtreme 1000t to a SGI 5704. It's rather straightforward if you have read the instructions for modding a 3c996B. In linux,I could see that the chp and subsys vendor and device ids were both 14e4:1648, just like the values ar a0..a7 in the eeprom of both devices (eth3 and eth4 for me). To make both ports usable in IRIX, I had to run thte following for eth3 and eth4:

After a reboot, lspci listed the card as:

Finally, in IRIX, tgcmd inventory shows:

And hinv -v lists it as

Does anyone know how to renumber this card so that it appears as tg0 and tg1?

No "UNSUPPORTED" messages showing up?

No, but that problem has been solved for the 3com cards that were affected.

Yep, that's set in /etc/ioconfig.conf. Either delete it and let IRIX regenerate it next boot (it will pull the stale entries), or edit it manually.

That almost does it - this card starts as tg1 and tg2, but that's good enough for me.

It appears that those are the correct pins to cut, and the card works in a Fuel afterwards, instead of preventing the fuel from starting at all. I haven't tested it in a 5V machine yet.

Some icons for irix that I haven't published anywhere yet.

I've used a transparent .XPM and sxpm (it's in freeware fw_libxpm), but not in nekoware to draw the blowfish icon. Since that covers exactly those places where you want to click, either create your parts elsewhere and drag them to the final destination, or keep using Alt-F1/Alt-F3.

Driver 4.8.0 works for me, current /etc/wacom.pref is as below (with a few device definitions snipped), there's no serial device configured for Serial Port 1 in System/System Manager/Hardware and Devices.

mcblack wrote: The output of

Code: Select all

cat test.dump | cut -b 1-$[3*16] |sed -e 's/ /+/g' | tr a-z A-Z

is

Code: Select all

66+99+55+AA+08+00+00+00+00+00+03+21+00+00+02+00+

Apparently, my instructions weren't clear enough. There needs to be one leading space, and no trailing spaces in hexsgi, then the snippet above will generate a vaild input for bc. Alternatively, you could swap the \(00 and \) to \( and 00\).

zizban wrote: Venus rotates clockwise, unlike the rest of the planets. Your Venus has the wrong rotation.

Apparently fixed in 1.3, but it's still spinning 24 times too fast, its rotation period is 243 days not hours. Also, the north poles of all planets are precisely orthogonal to the ecliptic plane, while they should be tilted by e.g. 23 degrees for earth or 97 degrees for Uranus, and all the planets orbital planes should be slightly inclined to one another, not all in a single plane. But it does indeed look good.