SD card support comes to RISC OS
Posted by Steve Revill Thu, 07 Jun 2012 21:26:00 GMT
RISC OS Open and Piccolo Systems are very pleased to announce the release of a general-purpose MMC/SD filing system for RISC OS.
ROOL have signed an agreement with Piccolo Systems to publish the source code to the driver and related software under an Open Source licence within the ROOL CVS repository. It will be integrated into the OMAP3 developer ROM build, found on our downloads pages to give native support for SD cards on the Beagleboard, Beagleboard-xM, DevKit8000 (untested) and IGEPv2 (untested).
The new code, published today, includes:
- SDIODriver – the driver for SDHCI controllers
- SDFS – a FileCore filing system that uses SDIODriver to access data stored on a wide range of memory cards
- SDCMOS – works with recent bootloader scripts to ensure CMOS settings persist across reboots, even for users without EEPROM carrier boards, and without requiring the boot SD card to be left in the slot at all times
- OMAP3 HAL – adds hardware-specific declarations and support routines to enable SDIODriver to drive the main SD slot on popular boards
Supported memory card types include MMC, MMCplus, RS-MMC, MMCmobile, SD, SDHC, SDXC, MiniSD, MicroSD and MicroSDHC, of capacities up to 256 GB. Access speeds of up to 14.5 MB/s (card dependent) have been measured on Beagleboards.
Over the past couple of months, this work has already benefited RISC OS, with changes, bug fixes and other improvements already in CVS for the following components:
- FileCore – many changes and improvements, including faster mounting of media
- DOSFS – tweaks and fixes, including allowing construction of bootable DOS-formatted media
- HForm – support for formatting SD cards, amongst many other bug fixes
- SyncLib – new library of architecture-independent synchronisation primitives
- SDFSFiler – a desktop front-end to the SD filing system
At the moment, the SDFS code should be considered a beta release until we are ready to call it stable (it will be one of the deciding factors going into a 5.20 stable release of RISC OS).
Is that the ‘royal we’ on the Piccolo page?
Would this be incorporated into the RPi port in the near future?
RPi support is under development. Mainly ironing-out the last few issues.
Speaking as a corporate entity, we are not amused :)
And yes, Raspberry Pi support was always very much a part of the plan. I expect Pandaboard support won’t be too much further behind, either.
Does the screen shot on the piccolo web site show SDFS working on a Raspberry Pi?
Will this be released in time for the Midlands User Group show on 7th July 2012 in Kenilworth and will ROOL be there?
As it happens, the screen shot is indeed from a Raspberry Pi – it predates Jeffrey’s recent USB work, which is why there are no other drives shown. I’d like to think the Pi version will be ready for release in that sort of time frame, but I can’t make any promises. As for ROOL’s attendance at the MUG show, I’m afraid I can’t say yet.
Nice work, Piccolo Systems – great that this is an open source release!
Will it be rolled into the Raspberry Pi build in due course please?
I’ve just uploaded Raspberry Pi support to CVS, so it will be in tonight’s autobuild. But please note that unlike the OMAP3 version, it is not reliable in its current state. The Raspberry Pi seems to be very picky about its SD cards, don’t be surprised if you see a lot of disc errors, especially for larger data transfers.
Is the unreliability confimed to writes to the SD card? Can SD card reads corrupt the card?
It does seem to vary a lot depending upon exactly which card you use, but it does affect reads as well as writes. On the plus side, the CRCs used “on the wire” mean that you’re unlikely to get silent corruption of the card – but you may find that writes do not complete successfully, leading to inconsistent data in a file, or if you’re really unlucky, in a directory or the disc map/FAT. Look out for “Disc error 08” or “Disc error 23”, that’s what I’ve been seeing a lot of.
I know a lot of people are keen to use SDFS on the Pi, and this gives you a flavour of it, but I can’t emphasise enough that it’s significantly less stable than the beagleboard version. One reason for sharing it at this point is to see how much of a problem it is for people in general – it’s possible that I have a dodgy board, for example.