MPX8xx: MMC over SPI....

MPX8xx: MMC over SPI....

[David Jander]

Hi all,

I know that Wolfgang Denk is going to flame me right away for this, but I'll
do it anyway :-)
I am going to write a SPI driver and on top of that a MMC driver for linux for
the MPC852T, unless there is something already out there.
Anyone tried this before and has some sources to share? Or pointers to
sources?

Greetings,

--
David Jander
Protonic Holland.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPX8xx: MMC over SPI....

[Jaap-Jan Boor]

On Tuesday 09 March 2004 14:18, David Jander wrote:
> Hi all,
>
> I know that Wolfgang Denk is going to flame me right away for this, but
> I'll do it anyway :-)
> I am going to write a SPI driver and on top of that a MMC driver for linux
> for the MPC852T, unless there is something already out there.

the SPI driver is there. It's in the Denx kernel src

Jaap-Jan

> Anyone tried this before and has some sources to share? Or pointers to
> sources?
>
> Greetings,
>
> --
> David Jander
> Protonic Holland.
>

--
J.G.J. Boor			  Anton Philipsweg 1
Software Engineer		  1223 KZ Hilversum
AimSys bv              		  tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum   mailto:jjboor@aimsys.nl


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPX8xx: MMC over SPI....

[Wolfgang Denk]

Dear David,

in message <200403091418.22891.david.jander@protonic.nl> you wrote:
>
> I know that Wolfgang Denk is going to flame me right away for this, but I'll
> do it anyway :-)

I'm sorry if I caused the impression I would flame people  for  using
SPI.  This  was  definitely  not my intention. But I think it is only
fair to share some experience, and warn you not  to  run  into  well-
known problems.

> I am going to write a SPI driver and on top of that a MMC driver for linux for
> the MPC852T, unless there is something already out there.
> Anyone tried this before and has some sources to share? Or pointers to
> sources?

The SPI driver is there, but I don't recommend to use it for any type
of data transfers that require any  significant  bandwidth.  Motorola
writes:

        The SPI was not designed to be a high-bandwidth channel. It
        can run very quickly for bursts of up to 16-bits. But the
        peripheral has no FIFO and low priority in the MPC860 and
        thus you cannot burst lots of data quickly through the
        interface.
        ...
        Note that the SPI is of lower priority internally than the
        SCCs, thus, the SPI will be the first device to be "starved".
        Since it has no FIFO, it is especially sensitive to underruns.
        The best way to prevent this is to use a buffer size of 1
        "character" (of size programmed in the mode register).
        ...

Also, you should be aware that the SPI  protocol  is  implemented  as
microcode  running  on the CPM, so any high-speed data transfers will
suck up CPM performance.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"...and the fully armed nuclear warheads, are, of  course,  merely  a
courtesy detail."

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPX8xx: MMC over SPI....

[Kate Alhola]

Wolfgang Denk wrote:

>>I am going to write a SPI driver and on top of that a MMC driver for linux for
>>the MPC852T, unless there is something already out there.
>>Anyone tried this before and has some sources to share? Or pointers to
>>sources?
>>
>>
I am just doing same thing for mpc5200 ( http://www.iti.fi/iti5200.php )
board.
In this board there is MMC connector connected to PSC

>
>The SPI driver is there, but I don't recommend to use it for any type
>of data transfers that require any  significant  bandwidth.  Motorola
>writes:
>
>
There is simple spi driver arch/ppc/8260_io/cpm_spi.c but i think that
one like
i2c subsystem will be much more usefull. I have been planning make one based
on i2c driver.

I am plannigg 3-layer model like in i2c or USB. interface-HW-driver in
lowest level,
then subsystem driver and then target HW driver. Like in this case
PSC_SPI-> SPI_subsystem->MMC  ---->FS

>        The SPI was not designed to be a high-bandwidth channel. It
>        can run very quickly for bursts of up to 16-bits. But the
>        peripheral has no FIFO and low priority in the MPC860 and
>        thus you cannot burst lots of data quickly through the
>        interface.
>        ...
>        Note that the SPI is of lower priority internally than the
>        SCCs, thus, the SPI will be the first device to be "starved".
>        Since it has no FIFO, it is especially sensitive to underruns.
>        The best way to prevent this is to use a buffer size of 1
>        "character" (of size programmed in the mode register).
>        ...
>
>
>
There is same problem in mpc5200 SPI and for this reason i am planning to
use PSC in SPI mode. Then i will have fifo etc. I am also considering to
use bestcom DMA. I just have heard that there is lot of problems with it
when used with I2S. What is actually causing the problems ?
Bestcom API library ? Should it be better to use directly bestcom HW
without library ?

>Also, you should be aware that the SPI  protocol  is  implemented  as
>microcode  running  on the CPM, so any high-speed data transfers will
>suck up CPM performance.
>
>

Of cource it does not give best performance but it is also wery simple
glueless
interface to cheap small low cost mass media. If we like to have full fast
MMC/SD interface then we should consider some FPGA implementation
but in most cases simpler will give enough proformace.

Kate

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPX8xx: MMC over SPI....

[Wolfgang Denk]

In message <404E51E7.4070909@iti.fi> you wrote:
>
> There is simple spi driver arch/ppc/8260_io/cpm_spi.c but i think that
> one like
> i2c subsystem will be much more usefull. I have been planning make one based
> on i2c driver.

Arghh.... Why do you think you need all this overhead?

> I am plannigg 3-layer model like in i2c or USB. interface-HW-driver in
> lowest level,
> then subsystem driver and then target HW driver. Like in this case
> PSC_SPI-> SPI_subsystem->MMC  ---->FS

Remember that SPI is always very board-specific. I'm not sure that it
really makes sense to create a special "SPI subsystem"  -  especially
when you use I2C as a model (which IMHO is just a lot of overkill).

> There is same problem in mpc5200 SPI and for this reason i am planning to
> use PSC in SPI mode. Then i will have fifo etc. I am also considering to
> use bestcom DMA. I just have heard that there is lot of problems with it
> when used with I2S. What is actually causing the problems ?

The design of the available (at the moment) bestcomm code.

> Bestcom API library ? Should it be better to use directly bestcom HW
> without library ?

Do yourself a favour and use the official API. Otherwise you will end
up relying on a lot of internal things that may (and will) be cahnged
with the next version of the bestcomm code.

> Of cource it does not give best performance but it is also wery simple
> glueless
> interface to cheap small low cost mass media. If we like to have full fast
> MMC/SD interface then we should consider some FPGA implementation
> but in most cases simpler will give enough proformace.

I don't know your exact application,  but  it  always  gives  me  the
creeps when I read the phrases "mass storage device" and "SPI bus" in
the same sentence. I tend to summarize this as follows:
"mass storage device"  + "SPI bus" = need for redesign :-)

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPX8xx: MMC over SPI....

[Jaap-Jan Boor]

Hi,

I agree in this with Wolfgang, I have had very bad experiences
with SPI as inter processor communication channel in the past.
And then you are in the luxury position of having 'intelligence'
(processors) on both sides which can detect and clean up the
CPM's SPI mess.

Jaap-Jan

On Wed, 2004-03-10 at 00:59, Wolfgang Denk wrote:
>
> I don't know your exact application,  but  it  always  gives  me  the
> creeps when I read the phrases "mass storage device" and "SPI bus" in
> the same sentence. I tend to summarize this as follows:
> "mass storage device"  + "SPI bus" = need for redesign :-)
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> By the way, ALL software projects are done by iterative  prototyping.
> Some companies call their prototypes "releases", that's all.
>

____
J.G.J. Boor			  Anton Philipsweg 1
Software Engineer		  1223 KZ Hilversum
AimSys bv              		  tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum   mailto:jjboor@aimsys.nl


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPX8xx: MMC over SPI....

[Kate Alhola]

Wolfgang Denk wrote:

>In message <404E51E7.4070909@iti.fi> you wrote:
>
>
>>There is simple spi driver arch/ppc/8260_io/cpm_spi.c but i think that
>>one like
>>i2c subsystem will be much more usefull. I have been planning make one based
>>on i2c driver.
>>
>>
>
>Arghh.... Why do you think you need all this overhead?
>
>
Base idea is just make abstraction layer that allows to use diferent devices
via same SPI with unified programmin interface.

>>I am plannigg 3-layer model like in i2c or USB. interface-HW-driver in
>>lowest level,
>>then subsystem driver and then target HW driver. Like in this case
>>PSC_SPI-> SPI_subsystem->MMC  ---->FS
>>
>>
>
>Remember that SPI is always very board-specific. I'm not sure that it
>really makes sense to create a special "SPI subsystem"  -  especially
>when you use I2C as a model (which IMHO is just a lot of overkill).
>
>
>
Just for that reason i like to create abstraction layed that hides board
specific
things inside. Even the SPI interfaces are board specific, still the SPI
works
basically same way.

I even donn't think that i2c model is overkill. Like in this my
itipower5200 board
there is in base configuration MMC card and then TSC2301 audio codec/
touchscreen ADC / generic ADC chip. To addition there may be other
SPI-interfaced stuff depending of applitation where the board is used.

To application layer there should be MMC visible as disc, touch screen
visible as pointer device, Audio codec as audio device and then
the ADC visible as own device driver. In this audio part. The control
port of this codec is SPI but the actual audio data goes via I2S

So, when there may be even multiple diferent SPI interfaces and many
high level devices that have multiple stantard interfaces and all used
by separate tasks i think that the same type than used in I2S is not
overkill at all.

>>Of cource it does not give best performance but it is also wery simple
>>glueless
>>interface to cheap small low cost mass media. If we like to have full fast
>>MMC/SD interface then we should consider some FPGA implementation
>>but in most cases simpler will give enough proformace.
>>
>>
>
>I don't know your exact application,  but  it  always  gives  me  the
>creeps when I read the phrases "mass storage device" and "SPI bus" in
>the same sentence. I tend to summarize this as follows:
>"mass storage device"  + "SPI bus" = need for redesign :-)
>
>
>
SPI is still stantard mode in MMC cards. The other "native" mode
is also single bit serial mode but it does need extra glue logic.
Also speed is still wery equivalent than USB memories.

The higest performance is
not allways goal. In my board i have two mass device options. CF card
connected to 5200 IDE port CF used in IDE emulation mode and then
MMC connected to SPI and Nand flas as "fixed disc".

MMC is smaal cheap and common. It can be interfaced to about
any processor about null or minimum interface logic.
It is easiest implement as hot-swap removable device becuase
there is just so few signals. I

I still think that MMC has lot of advantages in many applications
but at finally i let user to make choice between them. CF is
choice if non hot swap faster mass memory is needed. MMC or USB
memory is choice if cheap small hot swap memory is needed.



Kate

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

some LINUX boot-up message loss

[song sam]

Hi,

I have a puzzle on booting LINUX under u-boot on my
custom 8xx board.Some boot-up message didn't come up
as DEMO board did.What's the problem with between
linux kernel and u-boot?For the sake of unsuccessful
behaviors on serveral big applications(some small
programs worked fine with booted linux kernel),I
suspect these unexpected results have something to do
with the loss message.Any hints?

Demo Board boot-up message:

u-boot>run flash_nfs
## Booting image at ff880000 ...
   Image Name:   Linux-2.4.18_mvl30-rpxlite
   Image Type:   PowerPC Linux Kernel Image (gzip
compressed)
   Data Size:    733665 Bytes = 716.5 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x03FBE928 => set upper limit
to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFFA2
bd address  = 0x03FBEFC4
memstart    = 0x00000000
memsize     = 0x04000000
flashstart  = 0xFF000000
flashsize   = 0x01000000
flashoffset = 0x0001B400
sramstart   = 0x00000000
sramsize    = 0x00000000
immr_base   = 0xFA200000
bootflags   = 0x00000001
intfreq     =     48 MHz
busfreq     =     24 MHz
ethaddr     = 00:10:EC:00:37:5B
IP addr     = 172.16.115.7
baudrate    =   9600 bps
No initrd
## Transferring control to Linux (at address 00000000)
...
[kernel booted fine and applications did well]

My Board boot-up message:

u-boot>run net_nfs
TFTP from server 172.16.115.6; our IP address is
172.16.115.12
Filename 'uImage'.
Load address: 0x200000
Loading:
#################################################################
done
Bytes transferred = 741868 (b51ec hex)
## Booting image at 00200000 ...
   Image Name:   Linux-2.4.18_mvl30-rpxlite
   Image Type:   PowerPC Linux Kernel Image (gzip
compressed)
   Data Size:    741804 Bytes = 724.4 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
...
[kernel booted fine but some big applications failed]

Thanks in advance!

Sam

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/