The collected works of miod - Page 5

escimo wrote:

Sudos wrote: if it wasn't for having to watch power consumption, I'd already have my Sun-4/260 or 370 up and running if I could get them to boot. 25MHz SPARC, what a power house!

Sun-4/260 with 25MHz? That's super-speed, indeed. Didn't know that the S-25 chipset was available or is compatible.

No, the 4/260 runs at 16.66MHz (and can be underclocked to 12.5MHz if needed). It's the 4/370 which sports a fast 25MHz cpu.

vishnu wrote: What OS do you run on those museum pieces?

My 4/260 dual boots SunOS 4.1 on the internal SCSI disk, and OpenBSD on the SMD disk cabinet. Perfect for long, cold winter nights!

uunix wrote: Now, are you meant to to create the sendmail.cf from the sendmail.mc like

Code: Select all

m4 sendmail.cf < sendmail.mc

I'm sure you mean here (after making a backup of the previous sendmail.cf first).

uunix wrote: Anyway, going back to the m4 sendmail.mc > sendmail.cf,
IF I have just a few lines in my mc files, will it integrate into the complete cf file or will it over-write the cf and leave the cf in the same state as the as the original mc file (a few lines)?

Il will overwrite the file, of course - that's what shell redirections do.

The usual Idiom will however be something like , as the .mc macros need to be defined somewhere. Replace /wherever with the directory name of the sendmail configuration machinery.

cybercow wrote: The hardware identification for G cards is probably stored in the altera asic, so the hardware signature will stay like that for now.

No, the hardware identification comes from PCI configuration space register access, and are likely those of the DEC chip itself and in no way emulated by the FPGA chip.

cybercow wrote: Those would be preliminary steps, what do you guys think about this ?

There's a risk that not all PCI address lines are wired, since the board was designed with the DEC chip in mind. So not all PCI devices would work.

Also, the FPGA chip might have some GIO addresses hardcoded, and would not allow more than one PCI BAR to be set (the BAR being probably initialized by the FPGA upon powerup).

Last but not least, the FPGA probably handles bus timing for DMA operations, and might not work correctly if DMA transfers from another PCI device are larger than a particular limit, or cross specific alignment boundaries.

cybercow wrote: i'm still not sure what to do with the interrupt (int_l) pin, the PCI interface should have INT#A, INT#B, INT#C, INT#D, though they resides on the optional group.

A given PCI device will only have one interrupt pin, unless it advertize itself as a multifunction device, in which case the subdevices are allowed to use different interrupt pins. Since the DEC chip is not a multifunction device, it makes perfect sense for it to only have one outgoing interrupt pin, which allows the FPGA to route it straight to the GIO interrupt line - it is very unlikely that the FPGA has support for the other interrupt pins.

ivelegacy wrote: while e500 (PowerPC by Freescale) is 4 cores

This is complete nonsense. e500 is a PowerPC architecture specification. Freescale is producing various e500 (or e500v2) processors in its ``QorIQ'' family, and some of them (such as the P4080) happen to have four cores, but not all e500 processors do.

ClassicHasClass wrote: I'm here, but I have no life.

Hey, that's MY line!

astouffer wrote: Now I don't have the special HP-HIL keyboard so I can't interact in any way.

If the PROM is in HP/UX mode, you can connect a serial cable to the DB25 port at 9600 8N1, and send `R' like mad during powerup until you get output to the serial port. Then, you can make the use of serial console permanent, by going into the configuration mode with `C', and change the onboard serial port mode from `L'ocal to `R'emote, confirm, and power cycle.
There is a similar procedure if the PROM is in Domain mode, but I'm afraid it's been too long and I have forgotten it...

astouffer wrote: What exactly do they mean by CPU board timer? Do they mean the 40Mhz oscillator, real time clock, or maybe the power up timer that takes the CPU out of reset?

This is likely the battery powering the RTC. There is a CR2032 (or is it CR2025?) cell somewhere on the motherboard, near the back connectors, which likely needs to be replaced.

Hmm, maybe I should consider selling my surviving Chalice CATS board (233MHz StrongARM in ATX form factor)...

robespierre wrote: I'd be surprised if the RJ45 was a different pinout from the one used on every Cisco router and just about everything else.

ERL use indeed Cisco-compatible wiring for the serial port, so there is nothing odd about it.

ivelegacy wrote: interesting question: to be, or not to be, Cavium's SDK addicted

It's crap, but they're not giving you much choice if you intend your code to be portable to all Octeon families.

Allow me to contribute to the droolage.

No, nothing really has changed. Hamei has been mostly in write-only mode, and eventually caused a moderator fuse to blow. Nothing surprising, really.

ivelegacy wrote: why? I mean, PROs & CONs with them ?

The Cavium SDK tries hard to be the kernel itself. For example, it comes with its own malloc, spinlocks, mutexes, you name it. Trying to replace this with your kernel's existing facilities is not really supported, and error-prone. Also, it suffers from too much OOP disease, with accessors on top of accessors on top of accessors, hidden by a thick layer of preprocessor macros (see octeon-model.h for a belching example of this). I understand that some layers are necessary because of the broad family of subtly different octeon models, but there seem to be too many of them.

ivelegacy wrote: they could share the same rootfs

I'm not so sure about that. Octeon lack coprocessor 1, i.e. the FPU. So either you need to have proper FPU emulation in the kernel, or you need to compile your userland in soft-float mode, which will suck on SGI where there is no such limitation.

smj wrote: Wait, there's a machine that miod *doesn't* have an example of?!?

I'm staying away of the large iron those days. I mean, I'd love to get my hands on a Crimson or a Challenge, but I don't have room for such a machine and this wouldn't be a reasonable decision.

jan-jaap wrote: Buying a Crimson has nothing to do with reasonable decisions, it's a matter falling victim to incurable red fever .

Yes, but I already have the unique Octane Crimson , remember?

pentium wrote: I-I'm 14 again?

Then get out of my lawn!

ivelegacy wrote: do you think things like the one above will work with ip30 ?

I've used Ricoh PCI<->Cardbus bridges on a Fuel and an Origin 200 (not under IRIX) without any problems; I see no reason for them not to work in an Octane.

ivelegacy wrote: (1) things proved to be working on IP32 do not work not on IP28, this, even if I did a copy preserving file's properties.
(
machine1 : tar -cf app.tar patch, scp app.tar machine2_IP:
machine2 : tar -xf app.tar
)

You won't preserve all file properties if you don't use the `p' option when extracting,

ivelegacy wrote: it seems we can't reprogram DS1981U chips, they are read-only

Of course. That's the whole point of these chips. Some of them also have programmable memory, but there will always be some form of read-only memory used for device identification purposes.

ivelegacy wrote: I do not know the "1wire-standard"

This is basically I2C bit-banging, but over a single wire used to alternatively convey the clock and data signals. Adapting an existing I2C design to 1wire is almost straightforward, except for the device power supply (true 1wire devices have only, well, one wire, and must use some form of vampire capacity to feed off the signals it receives on the wire in order to keep state and be able to do the bit-banging correctly).

robespierre wrote: I was looking at pictures of one of the Solbourne keyboards, and I couldn't figure out why it has both two minidin-8 ports (like a type4) AND ALSO an RJ12 jack. How does that work?

It has two mini-din connectors so that you can plug the keyboard cable on either side. The mouse plugs into the RJ12 jack in the middle. This is similar in spirit to the Sun type 4, except that on the four, the mouse goes into the unused mini din connector.

ivelegacy wrote: I am reading the Risc PC Technical Reference Manual (TRM)
and all the documentation from Simtec (located in Lancashire, North West of England)
they developed a strange kit called " Hydra ", product code AUHYDRA , it comes with 5 CPUSLOT s
it's a sort of multiprocessing kit for RiscPC

Simtec (later bought by Chalice) is well-known for doing all sorts of ARM stuff back in the day. I had heard of the Hydra, but this is actually the first time I've ever found pictures of it, thank you for sharing them!

There used to be some experimental support for it in NetBSD/arm32 in the 1.x days; I'm not sure it survived the split of the arm32 ports afterwards.

If you ever try this, be sure to be very careful with the airflow...

ivelegacy wrote: never checked NetBSD/arm32 v1.* (does it come with support for Hydra?), but I can try to download

The only report of a succesful Hydra boot I could find is http://mail-index.netbsd.org/port-acorn32/2002/11/04/0001.html . Note sure if all the code involved in this ever reached the official source tree, though.

I thought the 4100 L2 cache was off-chip? That said, I've never compared my S4000 and S4100 to spot the differences on the mobo...

uunix wrote: What would you do, if they (sgi) dropped you an email which read..

"Yole [username]
We watch the forum and you're a pretty cool guy.. here's a link to ALL the IRIX source code. You own it now."

I would try not to wake up too quickly from that dream.

pilot345 wrote: Woww, another 24bit card for SBUS sparcs??

I only ever knew about the Fujitsu AG-10E and the rasterflex and rasterflex-hr 24 bit cards, never seen this

You are missing the Sun ZX/Leo and the Parallax boards. Have a look at http://hyperstation.de/SBus-Framebuffer/sbus_framebuffer.html for pictures.

Checking the state of my SMD disk cabinet after my last relocation accross the country. Looks like one of them will need another low-level format, but my SunOS setup is not working anymore, I'll have to reinstall from tape. Looks like a nice weekend project. Hopefully it will be raining outside, so this will be an acceptable passtime.

Y888099 wrote:

smj wrote: NCD-19b, -16c, etc - 68k-based models, before any MIPS or 88k models)

Weren't 68Ks (020? 030? 040?) a bit slot? Never seen any 88K model, what does it run? VxWorks?

NCD X terminals run an in-house NCD development featuring a BSD TCP/IP stack for Ethernet and a token ring stack from Thursby Software Systems (TSSnet).

I am not aware of VmWorks ever being ported to 88k systems.

robespierre wrote: The OS was basically the same, but the BeBox had some special peripherals ("GeekPort") and always booted directly from OpenFirmware.

From ROM, rather. There was no OpenFirmware on BeBoxens.

robespierre wrote:

miod wrote: From ROM, rather. There was no OpenFirmware on BeBoxens.

Hmm, weird. I always thought they were PReP/CHRP machines.

The BeBox hardware is PReP, but the firmware in ROM, not being OpenFirmware, is obviously not PReP-compliant.

uunix wrote: Of course you don't have too.. it's you own business.. BUT..

When people come round your house and say.. 'wow .. what do you do with that stuff?' [Your' SGI gear]

What do you say?

I like to call it 'my dark side.'

Well, the obvious reason is ``in case the furnace breaks''. Might not work if you're living in Florida or snowless areas, though

Raion-Fox wrote: If it runs on Alpha then it should work as I know Alpha had big endian UNIX on it at some point.

I'm afraid you must be confusing with something else. Alpha is little endian, and can't change endianness at reset time (unlike mips).

astouffer wrote: Does anyone have a B132l or similar series box? If so would they be kind enough to take a picture of the system board near the front audio jacks? I acquired one that suffered some damage and sheered this one part off. It currently does not power up and this may be the cause. Thanks.

I'm terribly sorry, I forgot and I'm about to be about of town for a few days. This is a B132L, not a +, but apart from the PCI voltage, this should be identical. Does this ugly shot help? Do you want a better close-up of some areas?

Glad to be of help. Plus, I seized the opportunity to dust the machine this morning. This hadn't happened in the last 15 years

astouffer wrote: It currently does not power up and this may be the cause.

IIRC there is a magnetic (or optical?) sensor preventing the machine from powering up unless the case is correctly closed. If you plan to test it with the cover removed, be sure to put a magnet (or anything opaque?) in the ``security'' labeled slit, left of the volume control.

miod wrote:

astouffer wrote: It currently does not power up and this may be the cause.

IIRC there is a magnetic (or optical?) sensor preventing the machine from powering up unless the case is correctly closed. If you plan to test it with the cover removed, be sure to put a magnet (or anything opaque?) in the ``security'' labeled slit, left of the volume control.

Just checked, this is an optical sensor. Simply placing a screwdriver blade in the slit will let the machine power on with the cover removed. Remove the screwdriver, and it will power off immediately. Works with a small sheet of dark paper too.

Can you run tcpdump on the tftp server machine (tcpdump ether host <ethernet address of the tadpole machine>) to check that a tftp transfer really occurs?

If the transfer seems to go well but nothing happens after it seems completed, you might want to make the file unpadded by appending a few random bytes to it, in order for it no longer to be a multiple of 512 bytes. Some PROMs do not handle multiples of 512 bytes well in their tftp code...