ModTashtalk: lt0 driver for Linux
- Thread starter twelvetone12
- Start date
twelvetone12
Well-known member
@NJRoadfan This is so cool!! Fantastic!! Sorry I did not send you my netatalk conf, I am away and I can't access my linux box, I was thinking of setting up a document with the various configurations we have. Thanks for the code, I will include the mods in the repo.
I think there should be no need to append the packet size after the CRC. For the reset, if it is needed, we can add it in the open() and maybe add an ioctl for it.
The "frame error" is 0x00 0xFE. I always get plenty of those, particularly when the line is idle. I thought it was because of the sketchiness of my setup (I hacked the internal modem port of my PB100 and I'm to lazy to add a pull-up after buffer, so I think the input to TashTalk floats), but if you have them also I'm unsure what they can be.
For the packet size: I think it is OK to make the MTU a bit bigger in the driver, we could add a bit more just to be safe. I'm not sure how userspace produces such large packets anyways.
At this stage I still miss node id arbitration, which is the next thing to add. I'm not 100% sure how to implement it, since netatalk expects it to be synchronous: it does an SIOCSIFADDR and SIOCGIFADDR back-to-back, and the SIOCSIFADDR is blocking while arbitrating the address. If I understand correctly, the COPS driver tries to get the address suggested by netatalk via SIOCSIFADDR, and blocks until finished. Then netatalk calls SIOCGIFADDR to get the actual address (the suggested one or another). I will need to see how to reproduce this. I also miss ENQ and ACK managing but that should be easy.
And after this, lots of cleaning up since it is all quite a mess right now
And maybe the LocalTalk to USB adapter?
I think there should be no need to append the packet size after the CRC. For the reset, if it is needed, we can add it in the open() and maybe add an ioctl for it.
The "frame error" is 0x00 0xFE. I always get plenty of those, particularly when the line is idle. I thought it was because of the sketchiness of my setup (I hacked the internal modem port of my PB100 and I'm to lazy to add a pull-up after buffer, so I think the input to TashTalk floats), but if you have them also I'm unsure what they can be.
For the packet size: I think it is OK to make the MTU a bit bigger in the driver, we could add a bit more just to be safe. I'm not sure how userspace produces such large packets anyways.
At this stage I still miss node id arbitration, which is the next thing to add. I'm not 100% sure how to implement it, since netatalk expects it to be synchronous: it does an SIOCSIFADDR and SIOCGIFADDR back-to-back, and the SIOCSIFADDR is blocking while arbitrating the address. If I understand correctly, the COPS driver tries to get the address suggested by netatalk via SIOCSIFADDR, and blocks until finished. Then netatalk calls SIOCGIFADDR to get the actual address (the suggested one or another). I will need to see how to reproduce this. I also miss ENQ and ACK managing but that should be easy.
And after this, lots of cleaning up since it is all quite a mess right now
And maybe the LocalTalk to USB adapter?
Tashtari
PIC Whisperer
If it is needed, I'd be really interested to figure out why so I can correct it on the firmware side. No reason you guys should have to work with a half-working LocalTalk transceiver...
I'm really perplexed about this. TashTalk's receiver does not just interpret line noise as framing errors. Even if the line is floating when idle, there would have to be inversions detected on the line that look like a zero followed by a series of seven ones. Need to get some scope traces...
It's a bit of a hack, but you could have the driver regularly send out ENQs for all 254 possible addresses and build and keep a map of which addresses are in use. Then SIOCSIFADDR could return immediately because it would know whether the requested address is in use or not.
twelvetone12
Well-known member
I'm going to add the pull{up/down} (I don't remember which) and try to get some scope screenshots for you later this week.
The default algorithm for AppleTalk Node ID allows for a "hint", which is usually the last configured Node ID for the host. Basically atalkd is trying to quickly acquire a Node ID since the odds are high the last one used is still free. The following SIOCGIFADDR is to catch if the address changed due to a conflict. It isn't doing anything out of the ordinary.
It's custom with drivers to reset any found hardware to a "known" state during loading and initialization. It's good practice. The one corner case I'm concerned about is what is still in the Tx buffers if I terminate the serial line discipline with Ctrl-C and then restart it. Blasting it with null characters solves the problem.
Tashtari
PIC Whisperer
Oh, during loading and initialization is fine, I was worried you meant periodically during normal operation.
twelvetone12
Well-known member
I can do that when the driver is opened by the line discipline, I will have a look.
I'm not sure about the buffers not flushing, since they should be de allocated when the driver is closed, but I can test that.
I'm not sure about the buffers not flushing, since they should be de allocated when the driver is closed, but I can test that.
Got around to testing netbooting with my main accelerated IIgs. I was afraid the framing errors would slow things down, but it seems to boot just as fast as it does via the Shiva Fastpath 5. Maybe I'll get one setup and stopwatch the boot. I think its roughly 1.5MB of many small files loading off of the AFP server. A good stress test. So far, ever since I made those minor changes to the driver, things seem to be rock solid.
Regarding node assignment, I have at least one piece of hardware that hard codes it by default. The Kinetics Fastpath 4 and Shiva Fastpath 5 both default to Node 220 when reset to factory. Mostly because that is where the configuration software goes to look for it.
Regarding node assignment, I have at least one piece of hardware that hard codes it by default. The Kinetics Fastpath 4 and Shiva Fastpath 5 both default to Node 220 when reset to factory. Mostly because that is where the configuration software goes to look for it.
Tashtari
PIC Whisperer
So I powered up my ROM 01 IIgs to try and duplicate the framing errors. I don't have a netboot server set up, so this is just the ROM-based LocalTalk bootstrapping code, but I didn't get a single framing error from TashTalk. Not sure if this is good or bad news...
For reference, in my setup I have my Raspberry Pi (with a TashTalk 2 hat) connected to the Macs by a fairly long length of cat5e, using PhoneNet dongles.
For reference, in my setup I have my Raspberry Pi (with a TashTalk 2 hat) connected to the Macs by a fairly long length of cat5e, using PhoneNet dongles.
twelvetone12
Well-known member
Quick question: on TashTalk 1 the LocalTalk input should be idle low or high?
Tashtari
PIC Whisperer
I expect the input to idle high on both TashTalk 1.x and 2.x. It might be okay for it to idle low, too, but I'm not sure, I need to dig into the code again...
twelvetone12
Well-known member
No problem, it is just to add a pull-up after mi tri-state buffer in my setup I suspect that is what generates the frame errors on my system.
I suspect that is what generates the frame errors on my system.
Tashtari
PIC Whisperer
It seems strange to me that that could cause a framing error, but I suppose we'll see what happens...
twelvetone12
Well-known member
The serial on the modem port continuously outputs data even when it disables the transceiver, so the interference could come from that (keep in mind, my setup is dodgy on this respect)
twelvetone12
Well-known member
Pull-up added, the framing errors seem to have disappeared!
Now there is a problem with afpd that I cannot copy filoes from the mac to the pc, but it does not seem the driver's fault, I have no idea what is going on (printing and copying files to the mac works perfectly)
Now there is a problem with afpd that I cannot copy filoes from the mac to the pc, but it does not seem the driver's fault, I have no idea what is going on
(printing and copying files to the mac works perfectly)twelvetone12
Well-known member
Yes afpd seems to do some weird stuff with permissions, I will have a look there later, for the moment I want to make sure the driver is working, finish up what is missing, and clean it up. BTW I merged you patch, many thanks!
slipperygrey
Well-known member
If you narrow down an obvious bug in afpd please don't hesitate to file a ticket and/or PR with the upstream project.
https://github.com/Netatalk/netatalk/issuestwelvetone12
Well-known member
Mini update: I implemented a basic ENQ responder and basic arbitration for the address, and cleaned up stuff around the code. It is slowly getting there Next steps are making a read usb -> lt interface so I can test it with other macs, and trying to figure out what is wrong with afpd.
Next steps are making a read usb -> lt interface so I can test it with other macs, and trying to figure out what is wrong with afpd.Similar threads
