Re: Pinouts for the P4 connector in 3/80, maybe others?
Jeremy Cooper <[email protected]> Sat, 6 May 2023 14:00:56 -0700
| Newsgroups | gmane.os.netbsd.ports.sun3 |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_7F167FA0-3629-4961-9861-568EF70FFC2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2023-05-6, at 02:00, Romain Dolbeau <[email protected]> wrote: >=20 > TL;DR: looking for pinouts of the P4 connector in 3/80, possibly other > sun3x (3400 CPU board) and early sun 4 (4300 CPU board) >=20 =E2=80=A6 > And also, how does (if it does) the system detect the framebuffer on > said P4 device (SBus is easy with OpenBoot/OPenFirmware, not sure what > the 3/80 does, haven't tried booting mine n 20 years and the PSU seems > long dead, idly wondering how to resurrect it with a modern display). TL;DR: the code tries bus accesses at known addresses and moves on if = there is a failure or the read doesn=E2=80=99t match a known value. =20 The system almost certainly tries to detect the frame buffers it knows = about by performing read probe at the known physical address of specific = registers of the board(s) in question.=20 As an example, let=E2=80=99s follow how a bwtwo might get detected. = First, the pre-compiled device list is consulted. For bwtwo on a sun3x, = that=E2=80=99s here: = https://github.com/NetBSD/src/blob/6d3558670664274649a21e11f8dddab0ecc1f1c= 6/sys/arch/sun3/conf/GENERIC3X#L205 = <https://github.com/NetBSD/src/blob/6d3558670664274649a21e11f8dddab0ecc1f1= c6/sys/arch/sun3/conf/GENERIC3X#L205> That instructs the device driver to attempt to probe the board at = physical base address 0x50300000. At runtime that will result in = ca->ca_paddr being set to 0x50300000 in this function, which will then = attempt to peek a 32 bit value at that address to see if it reads back = as a known constant for any of the various bwtwo/cg4 frame buffers that = respond at this address. = https://github.com/NetBSD/src/blob/6d3558670664274649a21e11f8dddab0ecc1f1c= 6/sys/arch/sun3/dev/cg4.c#L167 = <https://github.com/NetBSD/src/blob/6d3558670664274649a21e11f8dddab0ecc1f1= c6/sys/arch/sun3/dev/cg4.c#L167> -J= --Apple-Mail=_7F167FA0-3629-4961-9861-568EF70FFC2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On 2023-05-6, at 02:00, Romain Dolbeau <<a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D"">TL;DR: looking for pinouts of the P4 connector in 3/80, = possibly other<br class=3D"">sun3x (3400 CPU board) and early sun 4 = (4300 CPU board)<br class=3D""><br = class=3D""></div></div></blockquote>=E2=80=A6</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = class=3D"">And also, how does (if it does) the system detect the = framebuffer on<br class=3D"">said P4 device (SBus is easy with = OpenBoot/OPenFirmware, not sure what<br class=3D"">the 3/80 does, = haven't tried booting mine n 20 years and the PSU seems<br class=3D"">long= dead, idly wondering how to resurrect it with a modern display).<br = class=3D""></div></div></blockquote></div><div class=3D""><br = class=3D""></div>TL;DR: the code tries bus accesses at known addresses = and moves on if there is a failure or the read doesn=E2=80=99t match a = known value.<div class=3D""> <br class=3D""><div class=3D"">The = system almost certainly tries to detect the frame buffers it knows about = by performing read probe at the known physical address of specific = registers of the board(s) in question. </div><div class=3D""><br = class=3D""></div><div class=3D"">As an example, let=E2=80=99s follow how = a bwtwo might get detected. First, the pre-compiled device list is = consulted. For bwtwo on a sun3x, that=E2=80=99s here:</div><div = class=3D""><br class=3D""></div><div class=3D""><a = href=3D"https://github.com/NetBSD/src/blob/6d3558670664274649a21e11f8dddab= 0ecc1f1c6/sys/arch/sun3/conf/GENERIC3X#L205" = class=3D"">https://github.com/NetBSD/src/blob/6d3558670664274649a21e11f8dd= dab0ecc1f1c6/sys/arch/sun3/conf/GENERIC3X#L205</a></div><div = class=3D""><br class=3D""></div><div class=3D"">That instructs the = device driver to attempt to probe the board at physical base address = 0x50300000. At runtime that will result in ca->ca_paddr being set to = 0x50300000 in this function, which will then attempt to peek a 32 bit = value at that address to see if it reads back as a known constant for = any of the various bwtwo/cg4 frame buffers that respond at this = address.</div><div class=3D""><br class=3D""></div><div class=3D""><a = href=3D"https://github.com/NetBSD/src/blob/6d3558670664274649a21e11f8dddab= 0ecc1f1c6/sys/arch/sun3/dev/cg4.c#L167" = class=3D"">https://github.com/NetBSD/src/blob/6d3558670664274649a21e11f8dd= dab0ecc1f1c6/sys/arch/sun3/dev/cg4.c#L167</a></div><div class=3D""><br = class=3D""></div><div class=3D"">-J</div></div></body></html>= --Apple-Mail=_7F167FA0-3629-4961-9861-568EF70FFC2B--