Re: NetBSD and VMEbus RAM

The MM-6230 manual says "The user must initialize the memory module to allow the parity generator to store ODD parity otherwise the module will assert BERR* for any subsequent read cycle."

The first time that NetBSD reads an uninitialized location from this RAM it will cause a bus error. BetBSD might scan RAM locations to see how much RAM is available.

You can either write an initialization routine that writes to all memory locations on the board before NetBSD touches it, or you can move jumper E1-E2 to E2-E3 to prevent the board from causing a BERR*.

On Thu, Aug 13, 2020 at 2:35 PM Chris Hanson <cmhanson%eschatologist.net@localhost> wrote:

NetBSD has grown a bit over the years and my 32MB MVME167 appears to hit swap during execution of /etc/rc from the 9.0-stable branch. So I thought I’d try adding a RAM board.

I added a Micro Memory MM-6230 8MB board (addressed at 0xFB000000) to my system, and followed the instructions in the installation guide for telling NetBSD about it.

Unfortunately, it appears that NetBSD dies on the first access to the board as system RAM; around the time ntpd starts the system hangs and I get a yellow FAIL light on the MVME167.

I’ve confirmed that the RAM board works by writing a little program to write data to it via /dev/mem at power up, the RAM board’s parity error light comes on, and writing to it via my program clears the light, so I suspect an issue with NetBSD or something in its VME interaction.

Has anyone else had success recently with VMEbus memory boards? Where do I even begin to debug this? The board supports A32 and D32/16/8 so access itself shouldn’t be a problem. Would I be better off just writing a dumb block device driver and treating the board as a fast swap device? Did I make a mistake in leaving the board set to 0xFB000000?

— Chris
— who’s surprised there aren’t cheap & simple 1GB VMEbus RAM boards available

Sent from my iPhone