Disk Speed Upgrades (aka The Bootable PCI SATA & SSD thread)

[(S)ATAman]

PCI to PCIe is a lie. it´s cofefe. the democrats invented it.

It kind of works here, but need more extensive tests.
For now everything is postponed, to make the 3112 and 3114 work without protection and in full modus operandi.
The next will be probably 3124 and than Marvell 6042. The 3124 has Open Firmware, but no "9". 6042 has neither, but it is a better chip than 3124.

Unfortunately need a "beige" G3 and some magic for Promise, their copy protection is THAT "good" (20269), it confuses a heck of me.
And I wrote the code for 20269.

I am not in hurry, will wait till borders are open, now I can't buy any beige (unless I want to pay for international shipping) because I can't reach my post box in Germany.
Luckily there is time and more, than enough things to do.

My employer from the US is OK to send me masks, here I can't buy any.

And as far as the COVID-19... the brother of my "ex", his wife and my older kid got it, not only me. We think, my youngest kid may had it, too.
We ate it for lunch - but still unsure, was it really tasty or not. More barbecue sauce would be better.
My wife is all the time next to our youngest kid, if he had - I think, it's impossible that she won't have it. Unlike the rest of us, she did not notice anything.

But don't do that at home on your own, please. Our gang is really bad-ass. 

[IIO]

stay well. yes i can imagine that your whole family is like you. even the smallest ones eat firmware for breakfast.

[toomanydatsuns]

Finally catching up on this fascinating thread, and it knocked loose a buried memory from my time working at a network storage appliance vendor... There might be an interesting SSD option for the Late 2005 PCIe G5.

Our company's marketing was all about selling "IOPS" (anyone remember FusionIO? ), and we ended up being an early adopter of the OCZ RevoDrive. The biggest complaint about the original RevoDrive / RevoDrive X2 was that OCZ used a "lazy" design and didn't implement a "real" PCIe RAID controller.



The card itself has a PCIe 1.0 x4 interface, but the signal is immediately routed to a Pericom PI7C9X130 (a reversible PCIe to 64-bit PCI-X bridge). The Pericom connects to (S)ATAman's old friend, the Silicon Image SiI 3124. From there, the 3124 is connected to two Sandforce SF-1200 series SSD controllers (or four on the X2), and each of those connects to a bunch of MLC chips.

My recollection is that the X2 really could only get close to 1GB/s in perfect laboratory conditions, but generally had pretty good performance in "real life".

But, as long as the G5 and/or Open Firmware don't freak out about the Pericom bridge, I'd bet that (S)ATAman's 3124 firmware could be flashed onto one of these cards, and it might be a very nice option for the PCIe G5s. OCZ even used to provide a flashing tool for Windows and Linux, though I have no idea where to find it now.

I found a few threads on MacRumors talking about using it on the 1,1-5,1 Mac Pro, using an off-the-shelf SiI3124 driver:

https://forums.macrumors.com/threads/ocz-revodrive-x2-pcie-ssd.1045512/?post=12841570#post-12841570
https://forums.macrumors.com/threads/revodrive-in-mac-osx.1246308/?post=13550721#post-13550721


And some reviews of the card itself from back in the day, getting into a bit of the architecture:

https://www.techspot.com/review/342-ocz-revodrive-x2-pcie-ssd/page2.html
https://www.anandtech.com/show/3997/ocz-revodrive-x2-review


These things are getting cheap on eBay, so I've ordered one for a laugh. If anyone knows how the G5s respond to that particular Pericom bridge, I'd love to know. Otherwise, I'll post an update in a week or two when it arrives 

[Pushpull76]

I bought several time ago a new Sonnet Tempo X4P to do some experiments, is there any way to use it under macos 9 ? Maybe with a Seritek firmware reflash?

[V.Yakob]

Now I've got to PCI - SATA on my MDD 2003.

I used this instruction on the forum as a basis.

Bought several boards SIL3112 and ROM chip on Aliexpress.
Such ROM chips can be used to replace: AM29LV040B, MX29LV040, PM39LV040.

A ROM chip was installed on the boards I received after a few weeks of tedious waiting: AM28F010-150JC. According to the datasheets specification, this ROM has a supply voltage range of 4.5V - 5.5V, but the new PM39LV040 ROM has a power supply of 2.7V - 3.6V. In order for magic smoke not to get out of the board, it is necessary to transfer the (jumper) 0 Ohm resistor R25 to R24.

Original


Modified


After flashing the chip ROM, replacing the ROM on the board and transferring the resistor, it's time for truth - testing!

When I turned on PM for the first time after installing the board, I was interested in seeing the board in EFI, for this:
1. hold during booting ⌥ (Option);
2. when the boot menu appears, press CTRL+Z;
(I think it's easier than ⌘+⌥+F+O  )
3. to list all devices, enter: dev / ls

If Seri-Tek is on the list, then everything is done correctly, and you can connect disks. If the disks are already connected, enter multi-boot to return to the boot menu.


I connected 2 SSDs: Netac SSD 256GB and Crucial CT250MX500SSD1.

Mac OS 9, Mac OS X 10.4, Mac OS X 10.5 were installed without problems and work perfectly.

The first thing that caught the eye was that the disk size is displayed correctly. When connected to PATA or through a PATA to SATA adapter, the disk capacity was always 128 Gb, despite the fact that I could make 3 partitions of 80 GB each, and they would be displayed normally. At the same time, in Mac OS X, the disk size is always displayed correctly.


Of course, I checked the speed of these disks with QuickBench.
Netac tests


Crucial tests



Just in case, I attach the firmware (SIL3112-Flashing.zip) for the ROM chip here. Also on the macrumors forum I came across compressed firmware (SIL3112-reduced.zip) up to 64kb for SIL3112, they report that it works, but I haven't checked it yet, maybe I'll do it later.

[V.Yakob]

Today I checked the operation of sleep mode on Mac OS 9.2.2, Mac OS 10.4 and Mac OS 10.5 -- without problems. The computer falls asleep according to the configured schedule from inactivity and wakes up after interacting. I didn't notice any hangs.
I also checked the operation of large disks: 500 GB and 1000 GB.
In Mac OS 10.4 and 10.5, everything works normally, without problems.
In Mac OS 9.2.2, such disks cannot be initialized: the process hangs and terminates without any errors, but the disk remains unlabeled.
If initialization is performed in another OS, the disk is mounted with the correct size and seems to work fine.

Connected HGST 1 Tb. 



Question(!)
I know that such cards do not work in QuickSilver, and it seems that there is an option to fix it by replacing the voltage regulator (U2). Who knows for sure in which other models such a problem manifests itself?

[ivanshpak]

Check out the reduced ROM Seritek, it's interesting.

And by the way, I can’t find the message where it was posted

[V.Yakob]

This is a reduced weibetech. It probably won't work for booting, but it can be useful in OS X. Apparently, there are boards where applicable. I added it here so as not to lose it.
But as I said, I haven't tried it.
Link.

[zefrenchtoon]

Hi!

Here is some work from dosdude1 ... one more time 

https://68kmla.org/bb/index.php?threads/silicon-image-sil3112-flashing-easier-way-using-flashrom.7013/page-2#post-470798

[DieHard]

Literally 10 years later from when this topic was started by Chris and Dosdude unearths the lost Dutchman's treasure...

Quote from Dosdude:

I have a huge update for you all. After many hours of reverse engineering, I was able to SUCCESSFULLY PATCH that SeriTek 1S2 ROM for the SIl3112 cards, allowing it to work with ANY 512K EEPROM! It functions just as it would with a "supported" EEPROM, working with and booting both OS X and OS9! The patched ROM image is attached. Please test, and let me know how it works!

See link in previous post and pictures

The SeriTek 1S2 2 Port SATA PCI G4 Card averages $150 or MORE on fleabay, so this is a game changer and a gift by Dosdude who is obviously not a greedy person, in fact a true hero in my eyes.

So I am guessing in theory, cards like this @ $15 amazon:
https://www.amazon.com/2-Channel-Array-Expansion-SATA150-Windows/dp/B083LQ2VKC/ref=sr_1_1?crid=3R5CBQUVFBJQY&keywords=Controller+Card+Sil3112&qid=1674583970&sprefix=controller+card+sil3112%2Caps%2C281&sr=8-1

will be able to be turned into inexpensive OS9 Bootable SATA cards. 

Perhaps there is a kind soul that wants to make a small, but reasonable profit, and give us a price for cards that are modded and ready to go.  Everyone's time is worth money and many will not be able to make their own card, so it is critical that a member that has the time and resources will take this knowledge and help the masses.  Hopefully, this will make the precious OS9 bootable SATA cards in reach for all

[smilesdavis]

just when i found 2 sonnets after a year of search rofl

[dosdude1]

I suppose I should have posted in this thread instead, but yes indeed, I have successfully patched out the EEPROM ID check in the SeriTek/1S2 ROM! After doing so, though, I had intended to see if I could reduce the ROM enough to get it to fit onto a 128K EEPROM, but unfortunately there is just too much there to be able to reduce it and retain its full functionality. With that said, however, there is an older version of the ROM, v5.0.7, that apparently is small enough to fit on a 128K EEPROM. Of course it never actually worked with a 128K EEPROM installed, as the ID check prevented it, but with the appropriate patches, could be made to work no issues. The problem, though, is I haven't been able to find a copy of that version of the ROM anywhere. So if someone could dig up a copy, that would be AMAZING, and of course be the ultimate solution to flashing these cards without having to replace their EEPROM. My patched version of the SeriTek/1S2 v5.1.3 ROM is attached.

[joevt]

How much bigger than 128K is the patched ROM? Maybe you could add compression to make it fit (if it isn't already compressed). The lzss algorithm is probably simple enough to implement in Open Firmware. The Sonnet cards used this method.

[dosdude1]

How much bigger than 128K is the patched ROM? Maybe you could add compression to make it fit (if it isn't already compressed). The lzss algorithm is probably simple enough to implement in Open Firmware. The Sonnet cards used this method.

It comes out to around 138K. Most of the space is being taken up by the OS X NDRV, but that is already compressed (it's an mkext shoved in as binary data).

[joevt]

I would run it through a compressor to see if it can get to less than 128K anyway. Compare compressing with and without the mkext part.

Here's a lzss decompressor (C code) https://forums.macrumors.com/threads/question-how-powerful-of-a-graphics-card-will-work-in-a-beige-power-macintosh-g3.2303689/post-31602677
I used it for decompressing New World Mac Open Firmware.
I included a version that does compression and decompression but I haven't checked if the compression produces output that can be decompressed by the version that decompresses Mac New World Open Firmware. It shouldn't matter. The point is that the decompression algorithm is simple enough to implement in Open Firmware.

I would decompress to memory outside the Open Firmware dictionary since that is a limited resource. I would avoid using encode-bytes+ if that is using space in the dictionary. Maybe there's a fcode trick to include binary blobs larger than a string of 256 characters. I am thinking something like this:

Code: [Select]

" "(00012345)" \ encode the size of the binary blob in a small string here; the following code only works if the address of this string is pointing to this fcode
decompress \ this takes the address from the stack of the string, reads the 4 bytes representing the length of the binary blob below, adds an offset to skip this decompress call and skip the following branch fcode to get the address of the blob,
\ branch fcode goes here to jump over the following 12345 bytes of the binary blob.
« 12345 bytes of stuff goes here»
executedecompressedfcodeimage
To make this work will also require modification to the tokenizer to support arbitrary length binary blobs that will produce the fcode output described above.
Another problem is that this only works for blobs that are less than 32K since that is the limit of the branch fcode. In that case, do it without the branch, have the blob at the end of the uncompressed first stage fcode, include the offset of the binary blob in the string that encodes the length.
Actually, the Open Firmware spec says that strings are copied from fcode to a temporary buffer (str0 or str1 in Mac Open Firmware), therefore you can't get a pointer to fcode that way. You may just want to map the PCI ROM and get the binary blob from that. Or forget this and use encode-bytes+.

[ssp3]

It comes out to around 138K. Most of the space is being taken up by the OS X NDRV, but that is already compressed (it's an mkext shoved in as binary data).

Indeed, starting from around offset 0x21d70 it contains all zeroes.
I know nothing about ROM dissasembling, their structures etc. (I wish, I knew, since I'm trying to finalize my WD MyBook Studio Firewire jailbreak), but, can't the firmware, by someone skilled in the trade
a) be optimized at the machine code level manually, or/and
b) decompiled and then re-compiled with different optimization level (min size) or with different compiler
to get the final file size under 128k?

I've loaded the firmware in Hopper and, when looking at some of the procedures in pseudo-code mode and checking/unchecking 'remove potentially dead code' checkbox, there were some differences.

[joevt]

Indeed, starting from around offset 0x21d70 it contains all zeroes.
I know nothing about ROM dissasembling, their structures etc. (I wish, I knew, since I'm trying to finalize my WD MyBook Studio Firewire jailbreak), but, can't the firmware, by someone skilled in the trade
a) be optimized at the machine code level manually, or/and

manually is a lot of manual work.

b) decompiled and then re-compiled with different optimization level (min size) or with different compiler
to get the final file size under 128k?

You can decompile and re-compile fcode with just a couple clicks. There's no optimizing that can be done here except the tokenizer can choose to convert some 5 byte literals to single byte fcode (the numbers -1,0,1,2,3 for example). A smarter tokenizer could reuse duplicate field definitions - basically a field is an fcode that adds a number to a number on the stack. A 5+ field for one struct is exactly the same as a 5+ field for another struct. Also, a tokenizer could replace code that doesn't use fields with a field fcode - for example "100 +" could be replaced with a 100+ field fcode if it exists.

You can disassemble assembly code into something that can be reassembled with some effort. There's no optimization for assembly code.

Decompiling from assembly to C code is difficult. Tools like Hopper or IDA usually don't produce code that can be easily compiled that behaves exactly the same as the original. Optimizers can be applied to C code though.

I've loaded the firmware in Hopper and, when looking at some of the procedures in pseudo-code mode and checking/unchecking 'remove potentially dead code' checkbox, there were some differences.

What did you load in Hopper? The firmware for a Power Mac PCIe card contains a lot of Open Firmware code which Hopper knows nothing about. Did you extract the NDRV? Without extracting the NDRV it will contain 5 or 6 bytes of fcode for every 250+ bytes of PowerPC code. Hopper doesn't produce pseudo code for PowerPC code - are you looking at Intel code? The "remove potentially dead code" option might make the pseudo code easier to read - or it might make the pseudo code less accurate.

[Borgmac]

Quote from DieHard

Perhaps there is a kind soul that wants to make a small, but reasonable profit, and give us a price for cards that are modded and ready to go.  Everyone's time is worth money and many will not be able to make their own card, so it is critical that a member that has the time and resources will take this knowledge and help the masses.  Hopefully, this will make the precious OS9 bootable SATA cards in reach for all

I am not up to that level yet, but I have been working on the famous Chernobyl Quicksilver to find an easy way to install Linux and Flashrom to be able to flash the Sil3112 SATA cards on a PowerMac G4.
Starting from a very basic knowledge of UNIX, it took me a while to find an easy Linux setup without burning one CD for every Linux version.
I have found a solution, using the cheap IDE to SATA adapter for an Inland 120 GB SSD, but it is using an app (BalenaEtcher) requiring Mac OS 10.10 minimum
The next step is to install the Flashrom program, compatible with the Linux version installed.
Then I will need to find a way to copy directly the Linux CD to the SSD without the BalenaEtcher, which I know is possible
Will continue to work on that and flash my first card.
Then I could have some time available...

[ssp3]

What did you load in Hopper? The firmware for a Power Mac PCIe card contains a lot of Open Firmware code which Hopper knows nothing about. Did you extract the NDRV? Without extracting the NDRV it will contain 5 or 6 bytes of fcode for every 250+ bytes of PowerPC code. Hopper doesn't produce pseudo code for PowerPC code - are you looking at Intel code? The "remove potentially dead code" option might make the pseudo code easier to read - or it might make the pseudo code less accurate.

As I already said, I have no idea what kind of code is contained in 1s2 firmware. And it was my question to someone skilled in the trade, not a statement
I loaded it in Hopper just for kicks and saw that parts of it were recognized as Intel procedures, albeit with some strange looking instructions here and there.

[joevt]

I looked at the dosdude 1S2_512-patched.rom.

My tokenizer saves 199 bytes by converting numbers like 0,1,2,3 from 5 bytes to 1 byte. The fcode is 138343 bytes. 135.1 KiB.
Without the fcode that encodes the ndrv and mkext, the fcode is 10595 bytes. 10.3 KiB.
lzss cannot compress the mkext - it grows from 70069 to 75172 bytes.
lzss does a pretty good job on the ndrv - it shrinks from 54648 to 30527 bytes.
That's probably sufficient to get the size of the rom to less than 128 KiB (after you add forth code that does lzss decompression). You wouldn't have to compress all the fcode, or even the fcode that produces the ndrv. Instead compress the ndrv binary, include that as a series of encode-bytes+ in the forth code, then add forth code that uses the lzss decompress function on the result of that to create the blob for the ndrv property.

The lzss decompression function is less than 50 lines of C code so it should be pretty easy to convert it to forth.