HP/DEC/Compaq

Hi,
I have B160L & 715/80 HP 9000 workstations and wondering what kind of memory it wants (currenly both have 128M installed). Sure, it's 72pin parity FPM memory which must be installed in pairs, but everything I tried to plug there led to computers not even get started (ie they power off immidiatly).

What's the secret?

UPD: And one more thing I'd like to found out. Those workstations have EISA (and even PCI on B160L). Is it theoretically possible to make HP/UX (I'm running it) to see PC style IDE ISA controller (and drives) plugged there? More, isn't it possible to boot from that?

dreadbit wrote: Hi,
I have B160L & 715/80 HP 9000 workstations and wondering what kind of memory it wants (currenly both have 128M installed). Sure, it's 72pin parity FPM memory which must be installed in pairs, but everything I tried to plug there led to computers not even get started (ie they power off immidiatly).

Not parity... these systems require ECC simms. Also, the 715/80 will not accept simms larger than 32MB.

dreadbit wrote: UPD: And one more thing I'd like to found out. Those workstations have EISA (and even PCI on B160L). Is it theoretically possible to make HP/UX (I'm running it) to see PC style IDE ISA controller (and drives) plugged there? More, isn't it possible to boot from that?

HP/UX could theoretically use it if you could find a driver for your particular board (preferrably PCI), but don't expect to be able to boot from it.

miod wrote: Not parity... these systems require ECC simms. Also, the 715/80 will not accept simms larger than 32MB.

But is it normal behavior for system not even to start? (immediate poweroff)

Is it possible visually to understand if the SIMM is ECC or just parity?
SIMMs I've tried were Compaq 272771 and Goldstar E71042/E114072.

miod wrote:

dreadbit wrote: Is it theoretically possible to make HP/UX (I'm running it) to see PC style IDE ISA controller (and drives) plugged there? More, isn't it possible to boot from that?

HP/UX could theoretically use it if you could find a driver for your particular board (preferrably PCI), but don't expect to be able to boot from it.

Yes, this is that I've expected. It there a good place to look for those drivers [which should be linked in kernel, right?] or it's better not waste time and start with DDK?

Why PCI is preferable? As I understand all the ISA cards should use single driver (and I expect at least it to exists ). The thing I do not understand how should it be accessible on 0x1F0 and is there such thing as IO bus addressing in HPPA.

EISA is not the same as ISA; you can insert an ISA card into an EISA slot, but there is no guarantee that it is recognized. (That's because EISA and PCI have "configuration space" that can be probed, ISA does not). In the case of the Indigo2, some ISA cards can be recognized through special kernel build instructions. Something which may or may not be possible on a Snake.
You obviously cannot use any PC BIOS calls because none of them exist. Whatever host firmware is on the card, intended for PC boot loading, is also useless as it will never be read.
All I/O on RISC is memory mapped, there is no in/out. Any registers and memories on a card must be mapped prior to use. If these registers are all fully documented, as is the case for some SCSI cards, writing a driver is not that difficult (given knowledge of the kernel, the device type, etc). No-name ATA cards are least likely to be documented.

dreadbit wrote:

miod wrote: Not parity... these systems require ECC simms. Also, the 715/80 will not accept simms larger than 32MB.

But is it normal behavior for system not even to start? (immediate poweroff)

If the onboard electronics "consider" the situation very bad, yes - at least on the 715.

miod wrote: Why PCI is preferable?

A PCI "Super I/O" card based around a Natsemi PC87560 probably would have the best chance to get recognized and have an HP/UX driver, since this is what was put onboard the later generation (B1000, B2000).

C3700 && C3750 also used IDE chipsets. Kernel driver has just enough smarts to drive a simple block device for the PATA dvdrom.

You'll run into trouble with the PCI card being initialised differently (irq/dma/ports) on the systems compared to a PC. There's a lot to do kernel module wise. Still.. would be fun.

You'll run into trouble with the PCI card being initialised differently (irq/dma/ports) on the systems compared to a PC.

As I understand, some initial PCI initialization (assigning irq/dma/ports) should be done with ROM/Firmware/BIOS/Bootloader (or what's the name of it in case of HPPA computers?) (even if they are unsupporded by bootloader). Nothing strange that the card will behave different from PC. And the kernel should read that "PCI resource tree" (or what's the name of it) provided by Bootloader.

Do I understand it correctly or this knowledge is unusable in the world of HPPA computers?

There's a lot to do kernel module wise. Still.. would be fun.

How theoretically I can affect it? In case of HPUX I can statically link it into kernel, and statically link it out of kernel, or try to hack the binary. Is that's all I can do?

dreadbit wrote:

You'll run into trouble with the PCI card being initialised differently (irq/dma/ports) on the systems compared to a PC.

As I understand, some initial PCI initialization (assigning irq/dma/ports) should be done with ROM/Firmware/BIOS/Bootloader (or what's the name of it in case of HPPA computers?) (even if they are unsupporded by bootloader). Nothing strange that the card will behave different from PC. And the kernel should read that "PCI resource tree" (or what's the name of it) provided by Bootloader.

Do I understand it correctly or this knowledge is unusable in the world of HPPA computers?

The PA-RISC proms do not have a real PCI BIOS, and will only initialize known devices from a fixed list, i.e. all the onboard devices but nothing more. Even the official HP dual-port NICs boards featuring two PCI Ethernet controllers behind an HP-designed PCI bridge aren't initialized by the PROM, and require specific setup from HP-UX.

The chances of getting a random PCI card correctly set up by the PROM are zero, unless the card and its placement confuse the PROM into thinking this is one of the on-board devices it knows about.