[Oberon] RISC.img format
magnus at saanlima.com
Sun Feb 14 02:35:24 CET 2016
>> Ignoring the multiplicity of standards overlaid onto SD / MMC, you
can talk to all cards with a simple SPI port; the only complication is
the requirement to go slow until a faster rate is negotiated.
This is a common misunderstanding. In SPI mode there is no need to go
slow initially, you can go at full speed right away. The need for slow
speed is in SD or MMC mode where the pins are initially open-drain in
order to support multiple cards on the same bus. In SPI mode the
signaling is always push-pull and you can clock the card at typically up
to 25 MHz from the start.
See Appendix A in this document
/Timing specifications //
//Design engineers must meet the rise, fall, setup, hold, and other SD
Card and MultiMediaCard bus timing specifications. If they want to
support MultiMediaCards in their design, the clock speed should be
controllable by the host. This is due to the MultiMediaCard's
open-drain mode; the MultiMediaCard powers up in the open-drain mode and
cannot handle a clock faster than 400 Khz. Once the MultiMediaCard
completes the initialization process, the card switches to the push-pull
mode. In the push-pull mode the MultiMediaCard can run at the maximum
On 2/13/2016 11:12 AM, enso wrote:
> SD cards are not entirely KISS, but close (or is it MMC that is
> simple?). Well, if you read
> you should be satisfyingly confused.
> Ignoring the multiplicity of standards overlaid onto SD / MMC, you can
> talk to all cards with a simple SPI port; the only complication is the
> requirement to go slow until a faster rate is negotiated.
> Communication is relatively simple once you figure out a consistent
> way to initialize the card (that works for all the different brands),
> mostly reading and writing fixed-size 'sectors'.
> Unlike USB and HDMI, you can use a few FPGA pins directly connected to
> the port and no proprietary 'black boxes'.
> Like VGA and PS/2, these are from a simpler time, before businesses
> blindly followed the Jobsian obfuscation requirements to keep
> 'consumers' from 'looking under the hood' or 'knowing what they want'.
> On 02/13/2016 05:55 AM, eas lab wrote:
>> Yes SDs are magically cost-effective.
>> And the problem about finite-life and <even wearing> seems not relevant.
>> I guess they don't have the monsterous software requirement problem that
>> USB has, since they don't need to ID what class of USB they are.
>> Another example of KISS ?
>> Does any of the ETHO documentation describe the SD driver, down to the
>> register level?
>> == Chris Glur.
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon