In message [off-list ref] 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/
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/
Wolfgang Denk wrote:
In message [off-list ref] you wrote:
quoted
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.
quoted
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.
quoted
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/
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/