SDHC

It’s been a long time coming, but I’m happy to announce that I have finally finished SDHC support. Ehh, well, just for the RH/RP06 though. And the RH still only supports just one disk.
The reason it took so long is that besides just adding SDHC I’ve also redone enough of the disk controller that it now only claims the bus to do high-speed, max 256 cycle transfers – basically, reading or writing a whole sector in one go. The old controller would lock the bus from the moment the ‘go’ bit in the controller was set, until the end of the transaction – and, depending on the card speed and the length of the transaction, that could take a really long time.
The old controller would also run the interface to the SD card at the CPU clock speed, but the new one uses a fixed 25Mhz clock – usually at least double the CPU speed. Although a lot of time in the card interaction is still going to be spent waiting for the card to finish reading or writing a sector and I think most of that waiting is not dependent on the interface – but it will still make a bit of difference.
I did some simple benchmarking to see how much faster the new controller would be.  For the first test, the run was as follows: load a copy of my 2.11BSD system onto a card, then run time make in the /usr/src/sys/PDP2011 directory – once on my old DE0Nano with the old controller, and once on another DE0Nano with the new controller:

de0n old : 1624.8 real       945.2 user       496.0 sys     (100/14=7.14)
de0n new : 1570.4 real      1000.6 user       263.3 sys     (90/14=6.42)

Hmm, a bit faster, but not as much as I had hoped for… and, I’m not quite sure why, but with all the console stuff enabled, I couldn’t get either board to run at full speed; the max I could get out of the old version was some 7Mhz at the cpu, and 6.42 for the new version. Surprising, since there shouldn’t be a direct speed impact in most of the console logic… it’ll need some debugging. In the meantime, to make the test of the SD controller a bit more interesting, I did a run with the console stuff disabled:

de0n new : 1082.8 real       626.4 user       159.4 sys     (140/14=10 - without pidp11 console)

Ah, that’s more like it!
Then, for a second test, I was curious how fast different types and brands of cards would go. So, I took a handful of fairly low end but current micro-SDHC cards against my old micro-SD (without HC). Not entirely fair of course, since there is about a 10 year age difference… but then, the cards I checked were the cheapest I could find from a local supplier. Oh, I’m not at all sure all SDHC cards are from the same generation, so don’t read too much into the brand name columns…

san old    1897.0 real       623.1 user       149.2 sys     (Sandisk SD (not HC) 512Mb >10 years old)
san grey   1070.8 real       628.7 user       152.9 sys     (Sandisk Ultra Class-10 UHS1 16GB 'up to 80MB/s')
san red    1059.8 real       626.9 user       155.4 sys     (Sandisk Ultra Class-10 UHS1 16GB 'up to 98MB/s')
adata      1020.6 real       633.1 user       152.6 sys     (Adata Premier UHS-1 Class-10 16GB)
transcend  1053.4 real       632.7 user       151.7 sys     (Transcend Premium UHS1 32Gb 'up to 90B/s')
kingston   1047.0 real       630.2 user       152.7 sys     (Kingston Class-4 8GB)

So, almost twice as fast, I hear you think. Well, maybe even better, and that’s something I should probably already have mentioned for the first test: one of the things with the long and frequent locking of the bus is that it would cause missed clock interrupts – basically, that occurs whenever the bus is locked longer than one timer interrupt. And with the heavy I/O during a kernel build… those missed interrupts easily cause the clock to run slow by more than a minute with the old controller, but it’s dead on with the new one. But the ‘time’ command doesn’t know about that… Compare the ‘de0n old’ time of 1624.8 real with the ‘san old’ time of 1897 real, and then factor in the difference in clock speed as noted by the user time… oh, and the difference in sys time? that’s also the time that the bus is locked waiting for the card, excluding clock skew caused by missed interrupts.
The new controller causes the system to remain a lot more responsive under load, it’s really noticeable if you try to login another telnet or serial connection while a build is running. And the disk reporting in vmstat and iostat finally make some sense… in the old version, that didn’t work because the CPU didn’t notice any elapsed time as it was basically frozen during I/O.
I’ve mainly tested the new controller with 2.11BSD and RSX-11MP, and only as RP06. I don’t think that surprises are likely with the other OSses though, but you never know – and, unlike the old version, the new version hasn’t been tested against the old RM test programs yet. I had kind of hoped to add support for multiple disks in the same go, but I hadn’t counted on the complexity of the RH70/RH11 controller in combination with the disks – where some of the control registers are part of the controller, and some are in the disk. So to support multiple disks, it will become necessary to rework those registers that reside in the disk into multiples as well. Not really a trivial exercise. Similarly, I had also hoped that reworking the RK and RL controllers to use the new shared SDHC-SPI backend. No luck though, there’s still a bug in the RK that I can’t find, and I’ve not had time to even start on the RL.
So all of that will have to wait till the winter. Meantime I’ll put up a tar of the latest sources on the download page, but, it’s at best beta quality for now, and as I said, only the RH/RP06 is new, RK and RL are still old.
Oh. Almost forgot. The new controller does use a bit more resources than the old one did – that shouldn’t really be a surprise, since it does implement an extra buffer, and copying from and to it. In comparison with some of the other parts of the PDP2011 system it’s not that big of a deal though. But, maybe the old DE0 board is really too small now.
And another thing: I changed the debug/status LEDs for the new controller. LED0 is now off when the card is online, on when it is not – or while recovering from an error. LED1 is on when the card is not SDHC, off when it is. LED2 is on while doing a read. LED3 is on while doing a write.