rhalkyard / sethernet Goto Github PK

The ENC624J600 has a hardware cryptography engine that can do modular exponentiation, and calculate MD5 and SHA1 digests (the datasheet also says it does AES, but the errata indicates this is buggy and should not be used).

There seems to be some interest in adding support for modern TLS to the classic Mac OS, and even a working implementation, but it sounds as though offload is the only practical way this could be achieved on 68k machines.

Additional Control calls could be added to the driver to expose this functionality to applications.

While the SEthernet/30 driver is just a file that you can drop into your Extensions folder, the SEthernet driver cannot work this way, and must be installed as a DRVR resource into the System file (since the Extension loading mechanism appears to require the Slot Manager). This is easy enough to do with ResEdit, but it's an ugly thing to have to put into the installation instructions.

The Apple Installer SDK is available on the Macintosh Garden. It looks hideously convoluted, but it'd be neat to leverage that to create a runnable installer like a real product would have.

The EGetInfo call exposes a bunch of performance and diagnostic counters, which the SEthernet driver supports to the best of its abillity. Find some software that can display these counters, or write our own.

The current README and documentation are very technical. Write some user-facing documentation that covers:

• Where and how to buy boards
• What Macs they work on
• Supported System Software and Network Software versions
• How to install drivers
• Basic troubleshooting tips
• Links to resources on Mac networking

The declaration ROM of the SEthernet/30 is a flash chip, and the SEthernet/30 glue logic allows for it to be programmed by the host system.

Verify that the programming glue logic works, and write a tool to reflash the declaration ROM.

The original plan was to bring up the SEthernet card on a Macintosh SE first, as its hardware is simpler. However, my SE suffered a hard disk failure and has been out of action, so I've focused my Rev0 bringup efforts on the SEthernet/30 card for the SE/30. This has largely been a success (save for some hardware bugs that can be worked around).

At some point before making boards available, I should still make sure the SEthernet board works though.

The Revision 0 schematics and boards pull the /INT-SPISEL pin up, instead of down. This causes the ENC624J600 to come up in SPI mode, which is rather useless for our purposes.

Workaround

Pull SPISEL down by cutting the 3.3V supply to the SPISEL pullup resistor (10K, R5 on SEthernet, R2 on SEthernet/30), and connecting the resistor to ground instead.

Because the ENC624J600 has no hardware reset input, spurious interrupts may be generated on a warm restart if the link state changes or packets are received. This may cause a Sad Mac or a System Error during early boot.

Workaround

Shut the Mac down fully and cold-boot it, or disconnect the ethernet cable before warm-restarting and only reconnect it after the driver has loaded.

If the system has crashed, the MacsBug command sm <base-address>+7f6e 1000;rb (where <base-address> is the card base address) will reset the ENC624J600 to put it into a safe state, and then reboot the system.

JLCPCB have a very affordable PCB-assembly service. Rework the design to support this:

• Add BOM part numbers for JLC's part library
• Optimize part selection for cost and availability from JLC
• Eliminate through-hole parts and IC sockets where possible
• Eliminate requirement for pre-programmed parts (see #5 and #6)

When the driver is opened, the ENC624J600 is reset, which causes the link to be interrupted. While the time for the MAC and PHY to come back after a reset is defined in the datasheet and accounted for in the driver, the time for a link to be reestablished is not (and probably depends on too many external parameters to really ever define). Judging by the time between the link light going out and coming back on again, I'd guess it's of the order of 0.5-1 second.

It's only natural for software to open the driver and then immediately begin transmitting packets, and this is exactly what happens during boot - the driver is opened, and then AppleTalk sends out a bunch of 'who has this address?' AARP packets as part of its address-assignment algorithm.

The ENC624J600 seems to be perfectly happy to 'transmit' a packet on a down link, and reports success in doing so, but even when checking for link state and failing the transmit in software, those packets are simply lost - it seems as though AppleTalk simply sends some number of packets and does not check how many succeeded or not.

Depending on how long the link takes to come up, this means that either some of the 'who has' packets are dropped (not ideal, but so long as one gets through, address assignment should work as it should), or all of them are dropped, which could potentially result in the computer taking an already-in-use address.

As mentioned above, failing transmission on a down link does not seem to be enough - either we should wait for the link to come up as part of the reset process, or queue transmits on a down link (rather than failing them) and only actually send them when a link comes up. Both of these options have associated issues in handling the case of a link not being there at all, but it's probably better to add some complexity to deal with that, rather than potentially breaking AppleTalk address assignment.

Revision 0 SEthernet boards have the SE PDS pins numbered from the wrong end. This causes the machine to fail to power on with the card installed, due to a short between +12V and ground.

It should be possible to install the connector on the other side of the board to get the correct pinout, but clearances may become an issue. Probably just going to put the SE on hold until rev1.

On Revision 1 of the SEthernet/30 board, the 8-way connector to the breakout board is positioned in such a way that it fouls the hard drive cage.

This connector should be either relocated, or replaced with a right-angle connector with a lower profile.

I'm currently using surface-mount PLCC sockets for a project, specifically this one:

https://www.mouser.com/ProductDetail/575-946817

I've found that the footprint of the socket is the same as for soldering a PLCC directly to the board, except that it requires more space around the pads. If it's feasible, I suggest leaving room so that you or others will have the option of using this type of socket.

I'm not likely to build this myself, so I don't have any skin in the game. I just wanted to pass on a tip in case it might be useful.

The SEthernet/30 extension's Finder resources are broken. It gets recognised as an extension, but shows up as a "Document" file with no icon. This should get fixed.

Access patterns involving two or more 'back to back' write cycles (Longword writes, and unaligned word writes) do not give the ENC624J600 enough time to successfully complete one write before starting the next. This causes intermittent corruption of data written to card RAM.

Workaround

Software should avoid longword and unaligned-word writes on Revision 0 hardware.

Moving glue logic from GALs to a CPLD will be advantageous in several ways:

• Reduce the SEthernet/30's 3 glue-logic GALs into 1 chip
• Allow for in-system programming of glue logic via JTAG
• More gates will allow for more sophisticated glue logic (in particular, mitigations for #2, #3 and #4)

The ATF1502AS looks like a suitable candidate - it's cheap, in production, works at 5V logic levels, and is compatible with the CUPL toolchain I have been using for the GALs.

The 68030 PDS bus is too fast for the ENC624J600. This causes card behavior to be erratic, with read operations returning invalid data.

Workaround

Add an additional GAL to insert wait states.

• Carefully cut the traces connecting U4 pin 4 to ground on both sides of the board (a small countersink bit works well for this).

• Program a GAL16V8/ATF16V8 with the equations in pld/se30/se30-bodge.pld and 'dead bug' it to a convenient place on the circuit board, connected as follows:

Connect a 0.1uF capacitor across pins 10 and 20.

It is preferable to use the ENC624J600's software-configurable CLKOUT pin as a clock source, but the clock signal available on pin c38 of the PDS connector (16MHz C16M on the SE/30 and IIsi, 20MHz CPUCLK on the IIfx) can be used as a more easily-soldered alternative.

The default CLKOUT frequency of 4MHz (COCON=1011) gives ample timing margin, 25MHz (COCON=0010) gives
an optimal wait-state delay of 80 nanoseconds.

It'd be really nice to have a fully automated build process and do some kind of CI type thing.

KiBot can be used to automate all kinds of output from KiCad.

Automating CUPL will be harder, but it should be doable with WINE.

Per the ENC624J600 datasheet, there must be a couple of nanoseconds' delay between asserting CS and byte strobes B0SEL/B1SEL (T_PSP1 and T_PSP5 in the attached charts).

For write cycles, this is not a problem, since the 68k asserts its data strobes (from which we derive B0SEL/B1SEL) 1 clock after /AS (from which we derive /CS).

However, in read cycles, the 68k asserts data and address strobes simultaneously, meaning that we need to create this delay ourselves. In rev0, this is achieved by having a GAL propagation delay between the CS and B0SEL/B1SEL outputs - for the SE/30 card, this comes as a side effect of having multiple GALs in the glue logic. For the SE card, this was achieved by use of a feedback pin instead of an internal logic term (see c221345).

For the CPLD-based logic proposed in #5, this will need to be taken into account somehow. Adding an extra round-trip through the CPLD is probably more delay than we want, so another option would be to add a logic gate between the CPLD and the ENC624J600 to insert a small delay - the 74LVC2G17 dual non-inverting buffer looks to be a suitable candidate, with a propagation delay of 1.0-4.3ns at V_CC=5V.

As far as I have been able to test on the SEthernet/30 board that I have built, the driver is largely complete. It loads successfully, and passes MacTCP traffic without error. However, it appears to cause crashes when handling AppleTalk traffic - the system goes off into the weeds, with stack corruption obscuring where things actually went wrong.

Needless to say, this is suboptimal.

Just based on when the crash appears to occur (right after the first time a DDP packet is received), the prime suspect is the ReadPacket/ReadRest routine, which is passed as a callback to protocol handlers, but it's not obvious where it's going wrong.

This project really should have some kind of a license. Add one.

Inside Macintosh warns strongly against doing synchronous IO at interrupt time, since this can cause interrupt-driven drivers (such as ours) to deadlock.

Unfortunately, some software does this anyway. Such a deadlock can easily be replicated by attempting to mount a large (>300MB) disk image in Disk Copy 6.3 over AppleShare on ethernet - after mounting the image, the system locks up inside a synchronous IO call which never completes because interrupts are masked. I'm not filing it as a bug, as the exact same lockup occurs using an Asante MacCon NuBus card on a Mac IIfx with Apple's own drivers.

However, it should be possible to handle this in a more graceful fashion and recover from it - in the Disk Copy case, manually failing the IO call in MacsBug (by setting the parameter block's return code to -1) unblocks the system and everything proceeds as normal (presumably the IO operation gets retried or something).

A possible solution could be to establish a timeout for interrupt handling, after which all pending IO would be failed. This in turn would require that the interrupt handler to run as a Deferred Task, so that it could be interrupted by a Time Manager task handling the timeout. Care would need to be taken to keep the driver and hardware in a sane state through this, but it should be at least somewhat more robust than having the system hang - notably the ae driver in A/UX does something similar, using a timeout to guard against missed interrupts or a 'stuck' transmitter.

On a fresh install of System 7.5.3 on my SE/30, the SEthernet/30 card does not appear in the Network control panel, even though it is available in the MacTCP control panel and works as it should under TCP/IP.

Switching to Open Transport allows the card to be selected and function for both TCP/IP and AppleTalk, but since 7.5.3 defaults to Classic Networking, it'd be nice to be able to support it 'out of the box'.

The declaration ROM programming tool will be one of the first things users see when they start using their SEthernet/30 (since boards will come from the manufacturer unprogrammed), and while the current console-based application does the job, it's pretty rough around the edges, and for some reason Retro68 console apps are absolutely enormous.

Rewrite it as a Mac-like GUI application, with a focus on ease of use for first-time users.

https://github.com/neozeed/aux2 contains most of the A/UX kernel source, and the example driver from the Driver Developer Kit (although the accompanying book is nowhere to be found online).

Of particular interest is https://github.com/neozeed/aux2/blob/main/io/if_ae6.c, which is the ae driver for DP8390-based cards. Between that and the example driver, it should be possible to figure out how to write, package, and install an out-of-tree driver for the SEthernet/30.

See also https://github.com/SolraBizna/testc and https://github.com/cheesestraws/aux-minivnc for other out-of-tree A/UX drivers.