[Oberon] RISC.img format

[Magnus Karlsson]

 >> 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 
http://www.circlemud.org/jelson/sdcard/SDCardStandardv1.9.pdf

/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 
clock speed
/
Magnus

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
>
> https://en.wikipedia.org/wiki/MultiMediaCard
> https://en.wikipedia.org/wiki/SD_cards
>
> 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
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>
>
> -- 
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160213/9572d417/attachment.html>