Sonnet Tempo ATA133 and ATA100 PCI - PROMISE cards flashing quest

[DearthnVader]

Update the card also works in my PM9600 and is bootable without a redirect.

My Beige G3( Rev A ) has a really buggy version of OF the load command trigger the FCODE evaluator and does not work as expected so I was unable to load the full rom for the card.

Tho @joevt and my 16k firmware does work as expected in the Beige G3.

I think I mixed and matched part1 of the 16k firmware with V4.5.0 and part2 with Joe's V3.5.0, so I'll have to fix that.

 

[joevt]

I think I mixed and matched part1 of the 16k firmware with V4.5.0 and part2 with Joe's V3.5.0, so I'll have to fix that.

I think my part2 was from Tempo 133 Firmware 4.0.app? Is there a way to know the version from the firmware or do you need to know what installer it came from? I suppose I can compare the part1 with the installers to be sure.
I see there's a version in the part2 firmware that says 3.5.0 - this version appears in the name registry.

Anyway, let's work on the v4.5.0. Can you post a link to this? I have apps named "ata133_lgdrv_45" and "Tempo ATA133 Firmware 4.5.app" which appear to be identical so I may already have it.

cd "/Volumes/Updates/Third Party System Software/Sonnet/ATA133 Jaguar lg drive support2"
file1="ata133_lgdrv_45"
file2="Tempo ATA133 Firmware 4.5.app"
cat "$file1" | md5
cat "$file2" | md5
xattr -px com.apple.ResourceFork "$file1" | md5
xattr -px com.apple.ResourceFork "$file2" | md5
derez "$file1" | md5
derez "$file2" | md5

The md5 of the part1 firmware (fwre_136) is 020bd4e9df3ce64461c707656728d719 (the binary contents of the resource which I have placed in fwre_136.rom)
Please compare md5 to make sure we're talking about the same firmware.

So I guess the first thing to do is modify it so you can load it and extract the part 2 contents (the decompressed firmware). I've taken the part1 rom, made the modifications discussed previously (rename themask variable so it's not mask or fcode 124, replaced to variable_xxx with variable_xxx !, made all definitions external, gave some functions more descriptive names, removed the pci header (since you might be loading it manually in some environments that don't like the pci header), and added some code at the end to dump the contents of the decompressed rom.

 

[666sheep]

I'm back in business
So I got the proper .4th file from Tempo 133 Firmware 4.0.app and I'll switch to v4.5.0 to get in line with you.

Edit:
Link to the file I'm now working on is: https://www.sonnettech.com/support/downloads/software/ata133_jag_lg_drv450.zip

And md5s of this one are:

cat "$file1" | md5
7ba7ad7ad07b17d5b7f9405bccbfdff0

xattr -px com.apple.ResourceFork "$file1" | md5
f5565e5c0f41ba50ae76f92887f7fc84

derez "$file1" | md5
6fd95887d26e63885145e8585a26a696

The progress you've made so far is impressive, I'll try to keep up.

 

[DearthnVader]

I have a Mac OS 9 Sonnet Flasher to flash the Promise Fastrack100 TX2 and Promise Ultra133 TX2 with the 16k FCODE ROM, but it requires a script I wrote to build the properties of the card that will need to be edited for the specific Mac and PCI slot you are using it in, and I can help with that, it's not too hard.

I don't recommend flashing the FASTTrac100 TX2 just yet, as you lose the ability to use the entire 66k flashrom, so you can't flash it back to the PC BIOS.

I do, however, have a Mac OS 9 flasher that can restore the 16k PC Bios to the Ultra133 TX2.

If anyone wants to test with these FCODE ROM's please let me know and I'll put together a package for download and some instructions.

 

[joevt]

I'm back in business
So I got the proper .4th file from Tempo 133 Firmware 4.0.app and I'll switch to v4.5.0 to get in line with you.

Edit:
Link to the file I'm now working on is: https://www.sonnettech.com/support/downloads/software/ata133_jag_lg_drv450.zip

And md5s of this one are:

cat "$file1" | md5
7ba7ad7ad07b17d5b7f9405bccbfdff0

xattr -px com.apple.ResourceFork "$file1" | md5
f5565e5c0f41ba50ae76f92887f7fc84

derez "$file1" | md5
6fd95887d26e63885145e8585a26a696

The progress you've made so far is impressive, I'll try to keep up.

The md5 of the entire app matches (7ba7ad7ad07b17d5b7f9405bccbfdff0). The md5 of the resource fork and derez doesn't match - maybe different versions of macOS might produce different output - would need to compare output of the commands (without md5) to be sure. But it doesn't matter. I didn't include their md5s because the important thing is the firmware - convert it to binary and md5 that to make sure its the same as mine 020bd4e9df3ce64461c707656728d719

Then you can use DumpPCIRom on the firmware binary (what we're calling part 1) to produce 4th code and compare that to the one I posted with the changes.
Then use toke to make a binary of mine.
load it into Open Firmware from disk, and byte-load the result to execute it (inside a selected dev where it can create properties)
It should output the compressed firmware part (what we're calling part 2).
Convert that hex output to a binary, use DumpPCIRom on that, extract the OS 9 ndrv and the OS X mkext (convert them to separate binary files that can be loaded by their OSs), remove their code from the 4th text to reduce the size of that so toke can create a rom that is 16K (set the tokenizer rom-size to 4000).

 

[666sheep]

Regarding the ability to flash more than 16k, we could try to check how modified flashrom is accessing 32k of internal PDC2026x EPROM. It might give some more ideas.

If anyone wants to test with these FCODE ROM's please let me know and I'll put together a package for download and some instructions.

I'd grab the package for better understanding the whole mechanism and for testing purposes. I have Ultra100 TX2 and Maxtor branded version of Ultra133 TX2. My testing rig is G4 GE 500 DP with OS 9.2.1

The md5 of the entire app matches (7ba7ad7ad07b17d5b7f9405bccbfdff0). The md5 of the resource fork and derez doesn't match - maybe different versions of macOS might produce different output - would need to compare output of the commands (without md5) to be sure. But it doesn't matter. I didn't include their md5s because the important thing is the firmware - convert it to binary and md5 that to make sure its the same as mine 020bd4e9df3ce64461c707656728d719
(...)

OK, will do. Thanks for detailed instructions.

 

[joevt]

Thanks for detailed instructions

Detailed instructions would require me to research and perform all the steps, and document the results with example commands and their output. I'm hoping one of you will do all that. Post here if you get blocked at a step.

 

[DearthnVader]

Regarding the ability to flash more than 16k, we could try to check how modified flashrom is accessing 32k of internal PDC2026x EPROM. It might give some more ideas.

Flashrom doesn't have support for the PDC chips with internal flash memory, there is nothing we can learn from it, tho I did email the author of atapromise support in flashrom, I have not received a reply.

There is a hardware mod that allows the older PDC chips with external EEPROMs to use the full EEPROM.

WeetHet - Hardware - Converting a Promise Ultra 100 controller to a Fastrak RAID controller

www.weethet.nl

I'd grab the package for better understanding the whole mechanism and for testing purposes. I have Ultra100 TX2 and Maxtor branded version of Ultra133 TX2. My testing rig is G4 GE 500 DP with OS 9.2.1

Could you post some hi-res images of your cards, please?

 

[666sheep]

I did email the author of atapromise support in flashrom

That's what I meant, maybe phrased it wrong.

Here are pics:



Full images attached (JPG), if you'd need a better quality I uploaded 600 DPI TIFFs from my flatbed scanner here - link is valid for 15 days.

Edit: I'm afraid that HW mod from your link is only for external EEPROM cards, not for these with internal ones.
What could help would be the datasheet of PDC20268/9 IC. But I'm searching for one since week or two and no dice.

 

[DearthnVader]

That's what I meant, maybe phrased it wrong.

Here are pics:
View attachment 1953274
View attachment 1953273

Full images attached (JPG), if you'd need a better quality I uploaded 600 DPI TIFFs from my flatbed scanner here - link is valid for 15 days.

Edit: I'm afraid that HW mod from your link is only for external EEPROM cards, not for these with internal ones.
What could help would be the datasheet of PDC20268/9 IC. But I'm searching for one since week or two and no dice.

Both cards appear to use the same Rev. A PCB and should be compatible with our 16k FCODE. SATA_Man said that PDC20268/69/70 should work and maybe 71, but all the 71 cards I've seen use a different PCB.

I can confirm the PDC20270 works and the PDC20269 with the 16k FCODE ROM, then loading the full FCODE ROM from disk.

I'll have some words on the performance of the chips later.........

 

[LightBulbFun]

Open Firmware doesn't find any disks connected to the card /pci/UlrtaTek133/FrmTk-0/sd but no /disk@.

are you sure about this?
because that sounds like it may have found a disk or is it at least presenting a node for a disk, IIRC (its been a while mind) when browsing PCI SATA/ATA cards in OF the disks that are plugged into them

im pretty positive hard disks attached to PCI ATA/SATA cards in OF dont show up as disk@, but simply show up as sd, which I think stands for SCSI Disk which makes sense given that most PCI ATA/SATA cards enumerate themselves as SCSI cards (this is true for the Firmtek 3112 SATA cards and the ACARD AEC 6820M)

if you do a dir /pci/UlrtaTek133/FrmTk-0/sd@1:,\

or dir /pci/UlrtaTek133/FrmTk-0/sd:,\

or something such what do you get?

however its been a long time since I last poked at PCI card attached disks in OF so I am little rusty on the exact device tree layout for them sadly, so you could still be right, and that it went /sd/disk when a disk was detected, I need to figure out which mac has my 6820M in it and drag it out for testing at some point!

 

[joevt]

Detailed instructions would require me to research and perform all the steps, and document the results with example commands and their output. I'm hoping one of you will do all that. Post here if you get blocked at a step.

So I went ahead and tried it on my G5. It seems my modified part 1 is able to do the decompression. So I grabbed the hex, got the part 2 fcode, converted to forth, extracted/stripped the ndrv and mkext.

#=========================================================================================
# Setup the path to point to the joevt toke and DumpPCIRom.sh scripts
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/joevt/Library/Python/2.7/bin:/opt/X11/bin:/Library/Apple/usr/bin:/Volumes/Updates/Docs/Open_Firmware_and_Forth/OpenBIOS/JoesOpenBIOSStuff/detok/obj-amd64:/Volumes/Updates/Docs/Open_Firmware_and_Forth/OpenBIOS/JoesOpenBIOSStuff/toke/obj-amd64:/Volumes/Updates/Docs/Open_Firmware_and_Forth/MacOSX

cd "/Volumes/Updates/Third Party System Software/Sonnet/ATA133 Jaguar lg drive support2"


# On the Power Mac G5, boot Mac OS X and get the IP address from System Preferences.app.
# It will be something like 192.168.0.121

# Boot into Open Firmware (Command-Option-O-F)
# Redirect input and output to telnet
" enet:telnet,192.168.0.121" io

# In macOS on another machine, use telnet in Terminal.app to access Open Firmware on the Power Mac G5.
telnet 192.168.0.121

# List the devices starting from the root
dev /
ls

# List the device aliases
devalias

# Print the nvram variables
printenv

# For the boot-device nvram variable, it will say something like this:
boot-device             66697273 742d626f 6f742f40 303a392c 5c5c3a74 627869

# Translate that to text like this (in macOS):
xxd -p -r <<< "66697273 742d626f 6f742f40 303a392c 5c5c3a74 627869"

# Result:
first-boot/@0:9,\\:tbxi

# "first-boot" is a device alias for "/ht@0,f2000000/pci@9/k2-sata-root@c/k2-sata"
# The "@0" part after "first-boot/" is short for "disk@0" (in a device node name, you can omit the part before "@", or you can exclude the part starting at "@", or you can include both parts to make an exact match)
# The ":9" is the partition number
# The "," delimits the parameters
# "\\:txbi" means search for files of type "tbxi"
# The entire path is "/ht@0,f2000000/pci@9/k2-sata-root@c/k2-sata/disk@0"
# This matches the "hd" alias "/ht/pci@9/k2-sata-root/k2-sata@0/disk@0"

# List the files of the boot volume.
dir hd:9,\ 

# Load the fcode for the modified part 1 firmware file (modifications discussed previously in post #77)
load hd:9,\Trio45.2.rom

# The load address is stored in load-base. The size is stored in load-size.
# Execute the fcode.
load-base ['] c@ byte-load

# The Trio45.2.rom (which we modified from the original part 1 rom) decompresses the part 2 rom and outputs the hex.
# use macOS to convert the hex to binary.
mkdir -p part2
xxd -p -r '
all the hex
' \
> part2/part2.1.rom

# Convert it to Forth, and view the result to make sure we captured it properly (check the checksum).
DumpPCIRom.sh part2/part2.1.rom > part2/part2.2.4th 2> part2/part2.2.dumplog
bbedit part2/part2.2.4th part2/part2.2.dumplog

# Convert the Forth to fcode and convert that to Forth and compare with the original Forth to make sure the first call to DumpPCIRom worked correctly.
mkdir -p part2/verify
toke -v -o part2/verify/part2.3.rom part2/part2.2.4th > part2/verify/part2.3.tokelog
DumpPCIRom.sh part2/verify/part2.3.rom > part2/verify/part2.4.4th 2> part2/verify/part2.4.dumplog

bbedit part2/verify/part2.3.tokelog part2/verify/part2.4.4th part2/verify/part2.4.dumplog
bbdiff part2/part2.2.4th part2/verify/part2.4.4th
# The only difference is that the joevt toke uses the -1 word instead of a -1 literal to save 4 bytes.

# Extract the Mac OS 9 ndrv and the Mac OS X mkext
mkdir -p drivers
eval "$(
perl -E '
	$name = "unknown"; $hex = "";
	while (<>) {
		if (/^" "\([ 0-9A-F]+/../^property/) {
			if (/^" "\(([ 0-9A-F]+)/) { $hex = $hex . ($1 =~ s/ //gr); }
			if (/^" ([^"]*)"/) { $name = $1; }
			if (/^property/) {
				print "xxd -p -r <<< " . $hex . " > \"drivers/" . $name . "\"\n";
				$name = "unknown"; $hex = "";
			}
		}
	}
' \
part2/part2.2.4th
)"

# Give them better names.
mv drivers/driver,AAPL,MacOSX,PowerPC drivers/Trio45.mkext
mv drivers/driver,AAPL,MacOS,PowerPC drivers/Trio45.ndrv

# Check the contents.
file drivers/Trio45.ndrv
drivers/Trio45.ndrv: header for PowerPC PEF executable

# DumpPEF from macOS 9 would help verify the contents of that.
# For the mkext, there is a command to extract the kext:

mkextunpack -v -d drivers drivers/Trio45.mkext
Found 1 kexts:
UltraTek133P_48 - com.firmtek.driver.UltraTek133P_48 (3.0)

# Use the file command to check the architecture. Of course it's ppc since there's no reason for an Open Firmware rom to inclue x86 code.
file drivers/UltraTek133P_48.kext/Contents/macOS/*
drivers/UltraTek133P_48.kext/Contents/macOS/UltraTek133P_48: Mach-O object ppc

# Make a 16K option rom using the PCI Option ROM header from the original 4th.
# Use the Forth from part 2 but strip the Mac OS 9 and Mac OS X drivers. The result is actually less than 8K.
mkdir -p part2/stripped
sed -nE '/(tokenizer\[) .* (\]tokenizer rom-size)/s//\1\ 4000 \2/; 1,/rom-size/p' org/fwre_136.2.4th > part2/stripped/part2.5.4th
echo >> part2/stripped/part2.5.4th
perl -E '
	while (<>) {
		if (/^" "\([ 0-9A-F]+/../^property/) {}
		else { print $_; }
	}
' \
part2/verify/part2.4.4th >> part2/stripped/part2.5.4th # use the verify result as the source since it will have the proper comments for our toke changes (our toke uses -1 word instead of -1 literal)
echo "pci-end" >> part2/stripped/part2.5.4th

toke -v -o part2/stripped/part2.6.rom part2/stripped/part2.5.4th > part2/stripped/part2.6.tokelog

# Verify the result
mkdir -p part2/stripped/verify
DumpPCIRom.sh part2/stripped/part2.6.rom > part2/stripped/verify/part2.7.4th 2> part2/stripped/verify/part2.7.dumplog
bbdiff part2/stripped/part2.5.4th part2/stripped/verify/part2.7.4th

# Compare with original that contains the drivers.
bbdiff part2/verify/part2.4.4th part2/stripped/verify/part2.7.4th

 

[DearthnVader]

Ok, so I got another FASTTrack 100 TX2 and did a careful inspection of the Reg and Assigned Addresses .properties, and they are identical between our 16k FCODE and the unflashed FastTrack card in the same slot in my QS.

While the hacked Sonnet Flasher, with the help of my OF script was able to flash the full FCODE ROM to the first FastTrack card I got, it failed to verify the FCODE ROM the first time around 57k, but fully verified the second time I hit the update button and reported success.

However, I had no clue if or what the Device ID was going to change to, it changed from 0x6268 to 0x4d68, and as the FCODE ROM Device ID was set to 0x4d69 this simply means the FCODE is going to be ignored by Open Firmware as the Device ID's don't match.

Also, after this flash, the AA properties changed of 0x24 and 0x30 from 0x10000( 66k ) to 0x4000 ( 16k ).

So @joevt, here is the $10k question, if I change the Device ID to 0x4d68 in the FCODE ROM and flash it, will I still be stuck with Open Firmware only able to read 16k of the Flash ROM?

We know the FCODE fiddles with the AA properties and builds them as 66k, but if early in the boot process the card is only presenting the values for 16k are we even going to get far enough in the FCODE to enable the full read of 66k?

It would be interesting to know if we flashed the actual Sonnet Retail Tempo 133 ATA card if the Device ID would change to 0x4d68 like it does for the other cards, but those cards are selling on Ebay for upwards of $150, and we may just end up with a card that we can't flash the full 66k FCODE ROM back too.

Turning a $150+ card into a $20 PC card.

I'm still on the lookout for the Sonnet card to compare the impedance of the resisters to see if Sonnet's PCB has hard coded device ID set to 0x4d69 and Flashrom size set to 66k via a resister change. I'm just not going to pay $150 to find out. Comparing the cards with the hi-res pictures I have of the Sonnet card, they are identical in PCB and resister position with the three PC Cards I have, but that doesn't mean I didn't miss something or the impedance of the resisters I can't read are the same.

The PC Ultra133 changes the Device ID from 0x4d69 to 0x4d68 when we flash our 16k FCODE ROM to it, and changes back to 0x4d69 when we flash it back with the PC BIOS for the card. So we know the PC BIOS has a Mask that can change the Device ID, but I don't see anywhere in the FCODE where that Mask exists in the Mac ROM.

This leads me to think it's the impedance of some resister, hard coding the Device ID to 0x4d69 on the real Sonnet card, because it's the only thing that is really left that could be true.

 

[joevt]

pci-probe discovers the size of each BAR by writing ones to all the bits of the BAR in the config registers and reading the result. The bits that are still zero represent the size. I don't know how changing the option rom affects that behaviour.

You can change the vendor and device id in the pci header so it matches the vendor and device id of the card by changing the pci-header tokenizer line.
But I don't think you can change the vendor and device id in the config registers.

I guess the pci-probe sets the device and vendor ids to what it found in the config registers.
Maybe the fcode can modify those properties to match what the driver is looking for. But this will only work if the driver doesn't also check the config registers.

I noticed that there's a copy of the vendor and product IDs at offset 0x20 of the pci header (in the Variable length pad bytes). I don't know if these bytes are used for anything. This is not included in the modified pci rom.

 

[666sheep]

You can change the vendor and device id in the pci header so it matches the vendor and device id of the card by changing the pci-header tokenizer line.

I'm still thinking about what (S)ATAman said on macos9lives:

I don't recall any modification being necessary - except the driver and flasher change to recognize the ID-s.

(...)
The problem is not the firmware or even how to flash it into anything which has PDC 20268... PDC 20269 on it (...)

Edit: I'm lacking a spare time for devoting this completely, but I got some ideas which I want to test. I'll be back and I'll share my findings (if any will be interesting).

 

[ervus]

This is an interesting thread and I applaud the effort. I'm not very experienced with these type of cards but I do have a generic SIIG PCI ATA133 controller in one of my power macs. It has a 500GB drive that boots OSX. I got the card mainly to get around the 120GB limit of the built-in controller. So I'm curious what the appeal of the sonnet card is. Does it do RAID or is it faster maybe? I think there are a bunch of different versions of PCI IDE disk controllers like Acard, rocketRAID, SiliconImage, etc., but I don't know how many of them work in power macs.

These days, it seems like PCI SATA controllers would be of interest for connecting newer drives to our computers.

 

[weckart]

This is an interesting thread and I applaud the effort. I'm not very experienced with these type of cards but I do have a generic SIIG PCI ATA133 controller in one of my power macs. It has a 500GB drive that boots OSX. I got the card mainly to get around the 120GB limit of the built-in controller. So I'm curious what the appeal of the sonnet card is. Does it do RAID or is it faster maybe? I think there are a bunch of different versions of PCI IDE disk controllers like Acard, rocketRAID, SiliconImage, etc., but I don't know how many of them work in power macs.

These days, it seems like PCI SATA controllers would be of interest for connecting newer drives to our computers.

The appeal is that the Sonnet uses what appears to be a reference design for its ATA PCI adapters, which are can be found reasonably easily from other vendors. Flashing it gives you one option for more drives in your PowerMac, especially if you want to run OS9. It's getting harder to find the right two port SATA card and getting one of those to work under OS9 requires modifying the card somewhat.

 

[reddrag0n]

i have read all this info, but i'm still lost. is there a flasher to flash the ultra100 tx2 to a mac firmware? i recently got one card and no way does it boot on a mac. i can see it in 8.6, 9 and X but thats all i can do with it. i see a 405a 0x4d68 and thats where it stays.

 

[DearthnVader]

i have read all this info, but i'm still lost. is there a flasher to flash the ultra100 tx2 to a mac firmware? i recently got one card and no way does it boot on a mac. i can see it in 8.6, 9 and X but thats all i can do with it. i see a 405a 0x4d68 and thats where it stays.

We have a reduced firmware that can be flashed to the card from OS 9 with a modified Sonnet Flasher, however, it will not allow the card to be flashed back with the 66k PC BIOS for the tx2 and requires some Open Firmware commands to load the full Mac FCODE so you can boot or use the card in the Mac OS upon each boot.

In my PM9600 it is unable to boot OS X, only the Classic Mac OS. I've still yet to figure how to unlock the full 66k of on chip flash rom for this card.

 

[reddrag0n]

Thats fine by me, not like my 7500 can boot anything past 9.1 anyways. So where would i find this flasher and modded rom? Or do i have to sacrifice a virgin in order to get the files?

 

[DearthnVader]

Thats fine by me, not like my 7500 can boot anything past 9.1 anyways. So where would i find this flasher and modded rom? Or do i have to sacrifice a virgin in order to get the files?

It's kind of convoluted, you have to install the card, boot into Open Firmware, run a script that will build some properties for the card so that the Sonnet Flasher will see it as a valid card to flash the FCODE Rom( reduced ). I can provide the script, but it requires a New World Mac to run it, something about OF on these old world machines doesn't allow this script to run.

Even then, you have to edit the script for the exact properties the new world Mac gives the card in Open Firmware. If you can do a telnet session into Open Firmware on a new world Mac and dump the properties I can edit the script for you with the exact properties you need and upload it with the instructions on how to run it.

Then I can upload the modified Sonnet Flasher that will flash the reduced firmware for the tx2. Then upon each boot you will need to run some commands to load the full FCODE ROM for the card, but this can be done with an NVRAMRC script so as to automate it on boot.

However, the 7500 can't read HFS/HFS+ disks from OF, so you'll need to load the firmware from a DOS formatted floppy each boot. I automate this on my PM9600 and it only add 10 second or so to boot time.

 

[reddrag0n]

So your saying that the card will only work in one machine? From what i am reading, say if i flash it to work on the 7500, if i get a different machine say an 8600, it won’t work because of the specific properties that was written to the cards rom?

 

[DearthnVader]

So your saying that the card will only work in one machine? From what i am reading, say if i flash it to work on the 7500, if i get a different machine say an 8600, it won’t work because of the specific properties that was written to the cards rom?

Once you flash the rom it can be moved to a new machine, but the new machine will need an NVRAMRC script to use the card.

 

[reddrag0n]

Ah ok, well i tried to telnet into the quicksilver from my mac pro. Tried installing the telnet client and github said telnet was no longer available via homebrew. So is there another way to get the rom dump?

 

[DearthnVader]

Ah ok, well i tried to telnet into the quicksilver from my mac pro. Tried installing the telnet client and github said telnet was no longer available via homebrew. So is there another way to get the rom dump?

The QS can be a problem with telnet, mine open the telnet session, but there is no input, others have reported the same.