Re: NetBSD and VMEbus RAM
Michael Thompson <[email protected]> Thu, 13 Aug 2020 16:31:54 -0400
| Newsgroups | gmane.os.netbsd.ports.mvme68k |
|---|---|
| Message-ID | <CAH1BU=_ETvQy83qb9P9wWukc1ON-HARvZkFbV62KgsyK0LUf8A@mail.gmail.com> |
--000000000000ba8cee05acc83221 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 <[email protected]> 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=E2=80=99d 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 telli= ng > 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 g= et > a yellow FAIL light on the MVME167. > > I=E2=80=99ve confirmed that the RAM board works by writing a little progr= am to > write data to it via /dev/mem at power up, the RAM board=E2=80=99s 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=E2=80=99t 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? > > =E2=80=94 Chris > =E2=80=94 who=E2=80=99s surprised there aren=E2=80=99t cheap & simple 1= GB VMEbus RAM boards > available > > Sent from my iPhone > --=20 Michael Thompson --000000000000ba8cee05acc83221 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">The=C2=A0MM-6230=C2=A0manual says "The user must init= ialize the memory module to allow the parity generator to store ODD parity = otherwise the module will assert BERR* for any subsequent read cycle."= <br><div><br></div><div>The first time that NetBSD reads an uninitialized l= ocation from this RAM it will cause a bus error. BetBSD might scan RAM loca= tions to see how much RAM is available.</div><div><br></div><div>You can ei= ther 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*.</div></div><br><div class=3D"gma= il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 13, 2020 at 2:3= 5 PM Chris Hanson <<a href=3D"mailto:[email protected]">cmhanso= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= ;padding-left:1ex">NetBSD has grown a bit over the years and my 32MB MVME16= 7 appears to hit swap during execution of /etc/rc from the 9.0-stable branc= h. So I thought I=E2=80=99d try adding a RAM board.<br> <br> I added a Micro Memory MM-6230 8MB board (addressed at 0xFB000000) to my sy= stem, and followed the instructions in the installation guide for telling N= etBSD about it.<br> <br> 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 ye= llow FAIL light on the MVME167.<br> <br> I=E2=80=99ve 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=E2=80=99s pari= ty 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.<br> <br> 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 its= elf shouldn=E2=80=99t be a problem. Would I be better off just writing a du= mb block device driver and treating the board as a fast swap device? Did I = make a mistake in leaving the board set to 0xFB000000?<br> <br> =C2=A0 =E2=80=94 Chris<br> =C2=A0 =E2=80=94 who=E2=80=99s surprised there aren=E2=80=99t cheap & s= imple 1GB VMEbus RAM boards available<br> <br> Sent from my iPhone<br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature">Michael Thompson</div> --000000000000ba8cee05acc83221--