Forum Discussion
Honored ContributoruClinux MMC SPI Driver
Just to let everyone know, an MMC SPI Driver for Alteras SPI Core (modified) is in the works.. currently, cards can be recognized, read/write, and even partitioned.. but some bugs are being worked out. If anyone is interested in an early release, let me know....
56 Replies
Altera_ForumYa, I have a 1C12 and a 2S60 Stratix II Eval board that I can try it on. Unfortunately, I won't bea ble to try it tonite as I'm working remotely into my board http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif
- Altera_Forum
The problem doesn't seem to be going away when I set it to 16M. I couldn't even boot the kernel on 8M, didn't strip it down enough...
- Altera_Forum
I wonder if others can help out the tests,
I am testing with altera cf core to a cf drive of 1GB, formated to fat. mount -t vfat /dev/hda1 /mnt dd count=1000000 bs=512 if=/dev/zero of=/mnt/z2 free (or df) it will write a file of 500MB of zero. after the dd write, the next command will have "page allocation" fault with a new kernel. When I reduce the ddr size in ptf, without change to sof, from 64M to 8M,16M,32M, the problem disappeared. - Altera_Forum
What I don't get is why this is happening with the newer kernels if it's a hardware issue? It should happen in the older ones, no?
This iswhat I think it is; I think the fact that it worked for 32M and not 64M for you doesn't mean that there is a problem with 64M necessarily. I think it's very dependant on the kernel build. I use 32M normally, and 16M still gave me a problem. I'm sure if others try this, they will find different numbers. I think it's something much more fundamental... maybe a byte-alignment issue, something quirky like that. - Altera_Forum
I tried ddr core 3.3.1, the result is the same.
I am back to kernel patch work. - Altera_Forum
I tested more boards, with even larger dd count.
ddr sdram 128MB on 2C20, passed. sdram 32MB on 1C6, passed. only one new board has the failure, ddr sdram 64MB on 2C8, failed. but reduce hwselect to 32M,16M,8M passed. I have checked several patches of other arch from kernel.org, and can not find critical update from 2.6.11 to 2.6.12. The board with problem is PQFP package of cycloneII . It was before I read the SSN guide. I wonder different kernels may have different buffer cache algo, so that 2.6.11 does not trigger the failure. I will check SSN more carefully on that board. - Altera_Forum
Interesting; what's SSN?
- Altera_Forum--- Quote Start --- originally posted by jdhar@Apr 7 2006, 03:49 PM interesting; what's ssn?
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=14119)
--- quote end ---
--- Quote End --- Cyclone II Simultaneous Switching Noise (SSN) Customer Guidelines (but it is altera confidential. you may check with altera)
- Altera_Forum
hippo, if it's hardware, like you may be suggesting, a few things don't make sense: First, DDR running at 80M is very slow, so I wouldn't think SSN would be a problem. I have tried it on two boards of the same hardware, and both have the same problem. Secondly, I'm using the 2C35 in a BGA package, so SSN is even less likely. Also, why would it fail just for block device accesses? The CF or MMC doesnt' even DMA into RAM, so it will be much slower. Ethernet on the other hand, does, but that seems to be ok???
Also, I ran the DDR tester core on my hardware a long time ago at 100M+ and there were no failures. AND.. why would it work for 32M but not 64M when you change the PTF? The hardware is still the same. I don't necessarily think the problem is in the kernel... it might be in the core or the fabric. But I have no idea how to figure this one out, there are too many places to start! - Altera_Forum
hippo, I back-ported my MMC driver to 2.6.11, and the problem is gone. This was as suspected since the problem was there without MMC, but I really don't think it's hardware.
Oh so confusing!
