Now I am back to SPI driver for the microSD.
Thanks to Noltari, made such great process, this is the post http://vonger.cn/?topic=vocore-second-spi

SPI_CS1 is working normal now. We found the SD card not working is caused by the SPI speed is too high when SD card in init process.(Noltari SPI-GPIO firmware works, confirmed that is the problem).

RT5350 SPI lowest speed is 937.5KHz, but SD card init request speed is lower than 400KHz. It is a hardware broken.

But do not that hurry to say this SPI-microSD dead, let’s think this another way, at least, we have a temporary solution here 😀 Noltari’s firmware is able to make SPI flash and SPI microSD work same time already, just the boot time much longer, from 30seconds to 50 seconds..

We did not dead here yet. 😀 I think there still have some chance to make it happen.

What is SPI?
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus

How SPI transfer data?
From my understanding, SPI is working this way: Data -> Message -> Bytes
Data buffer is split into small messages, one message is about 512bytes, the bytes in the message are send through SPI one by one.
Message is the atom SPI operation. That means, it won’t change to other SPI attributes(such as clock speed, chip select, bits length etc) until one message is done.

Before message send, the upper SPI driver will call spi_setup to setup the transfer attributes(in rt2880-spi.c). The chance is here.

My plan is to combine the two SPI drivers, hardware driver and software driver. For high speed SPI devices we can use hardware(write to hardware register), for low speed(< 935KHz) devices we can use software(SPI-bitbang, write to GPIOs). From datasheet, the GPIO mode and SPI mode can be easily switched by writing to the pinctrl register. Just need some tricks to make sure the two drivers won't fight each other. 🙂 There will be a new powerful SPI driver for all boards have such problem, I'd better to patch this in spi.c but not rt2880-spi.c. About CPU consume, software SPI will cost a lot of CPU for high speed device, but for low speed ones, the performance is much better. SD card requested 400KHz for init only, so it just send hundred bytes, that cost can be ignored, so no effect to hole system.

Last week we are focus on the mass production.
From the beta production, we found some problems and that might lead to big problems in mass production.

1. Some parts in BOM are changed.
The factory engineer said they changed the BOM parts by their exists parts. That is a default rule, so they did not notice me that.

Before production, we found the flash chip was changed from W25Q64FVTIM to W25Q64FVSSIG. There are two kinds of alpha board, 200pcs are using W25Q64FVTIM, and 100pcs are using W25Q64FVSSIG. W25Q64FVTIM is 1mm tall, same as SDRAM, W25Q64FVSSIG is 2.3mm tall. W25Q64FVTIM cost is 30% higher than W25Q64FVSSIG and it is rare in market. W25Q64FVTIM is the only prefect one due to its small size and later hobbyists can easily hack it to other SOIC8 chip(VSOP8 is compatible with SOIC8).
PS: current mass production buy out all exists W25Q64FVTIM in ShenZhen electronics market. 😀

When I get the demo board, I found the power inductance is changed from LQH2HPN2R2MJ0L to SWPA252010S2R2MT(final version it is SWPA252012S3R3MT). From datasheet, Sunlord one have better performance in higher current(>600mA) but its resistance is 0.21ohm compared Murata one is 0.14ohm. So that might make the power consume a little higher, about 0.015w. This is not prefect, but acceptable due to better performance.

2. Test process.
They are using QA tool for mass production quality test, that tool is mainly used for router and phone(that factory is big, main job is to make router/phone parts for Samsung and TP-LINK) but never did such develop board for hobbyist. OpenWrt wifi driver do not support QA tool due to it do not have RT5350 native io control. I want VoCore to have a prefect quality, so it must use the QA tool. We use RT5350 SDK to run QA then flash it to openwrt for other tests. That process is complex and the factory is unhappy, I have to code a helper application(auto test from telnet/serial), also this app helps the factory to test their other production, so they are happy after that, and no manual operation also helps VoCore avoid test mistakes. 🙂

3. Packages.
There are thousands of packages contains different perks. That is a big work. I write a small application to filter the packages, about 2200+ packages are normal, but hundreds of packages are incorrect. Some only have Dock but no VoCore, some addresses are not right, have to email them later and deal manually. If I have next crowd-funding campaign, I will make the perks as simple as possible. 🙂

So beautiful 🙂 Feel like they are unreal.

This manual is used to FCCID…Just first page, there will be more later.

(My English is not that good 🙂 Kindly let me know if there is any mistake)

And about 1700km away, at ShenZhen, the mass production for first 200pcs has online. Here is some factory pictures( First Batch ) There are so many brilliant people working on this 🙂 Thanks for WuTong and Alex taking these pictures.

The software part is stopped this week, focus on the mass production. This can not afford any mistake.

There are a lot of work simultaneously:

-> VoCore v1.0:
Aug.14 ~ Aug.17 First 200 units VoCore v1.0 release version(beta) and test.
Aug.17 ~ Aug.18 Send sample to FCCID.
Aug.17 ~ Aug.25 VoCore v1.0 final PCB mass production.
Aug.26 ~ Sep.06 SMT VoCore and assemble with Dock.
Sep.07 ~ Sep.10 FCCID done, make FCCID tag.
Sep.06 ~ Sep.10 Package and ship.

-> VoCore v1.0 Dock:
Aug.13 ~ Aug.20 Dock PCB mass production.
Aug.21 ~ Aug.25 SMT & Assemble Dock.
Sep.03 ~ Sep.06 Combine VoCore and the Dock.
Sep.06 ~ Sep.10 Package and ship.

-> New site & forum:
Aug.03 ~ Aug.15 Mockup.
Aug.16 ~ Aug.22 Home/Forum/Wiki page.
Aug.22 ~ Aug.25 VoCore Manual, new site online.
Aug.26 ~ Sep.01 Project page.
Sep.01 ~ Sep.15 Store page.

Ship will take about 5~20 days.
From Alpha, average ship time(about 100 package):

Position         Average Time    Note
Australia          8 days        No offical data.
Austria            10 days       No offical data.
Belgium            12 days
Brazil             >40 days      Not arrive yet, just get Brazil.
Bulgaria           14 days
Canada             14 days
Czech Republic     14 days
Denmark            11 days
Finland            14 days
France             10 days
Germany            15 days
Greece             26 days
Hungary            20 days
Israel             22 days
Italy              20 days
Netherlands        10 days
New Zealand        8 days
Norway             17 days
Poland             14 days
Russian Federation 21 days
Spain              36 days
Sweden             30 days
Switzerland        12 days
Taiwan             14 days
Thailand           9 days
Turkey             16 days
United Kingdom     7 days
United States      7 days

To US,UK and Asia the speed is acceptable, 90% packages are delivered in one week; To Europe countries, the speed is fair, about two weeks for most of them, but Spain, Greece, Sweden takes very long time… Even worse, to Brazil, that package is still on the way…I think I can swim there in 40 days.

Yesterday, just get some result from MISO but I do not know whether or not it is right result, or at least it is not random result caused by the noise.

Today, I still not sure whether or not it is right mmc driver request result, but I am sure it is not a random result.

I just test it in this way:
spidev_test -D/dev/spidev32766.1 -s4000000
spidev_test -D/dev/spidev32766.1 -s8000000
spidev_test -D/dev/spidev32766.1 -s16000000
spidev_test -D/dev/spidev32766.1 -s32000000
spidev_test -D/dev/spidev32766.1 -s64000000

4MHz ~ 32MHz are same result. 64MHz is not same as them.

root@OpenWrt:/# spidev_test -D/dev/spidev32766.1 -s32000000
spi mode: 0
bits per word: 8
max speed: 32000000 Hz (32000 KHz)

40 3F E0 00 3F FF 
FF FF FF FF FF F0 
5F FF FF FF FF FF 
FF FC 17 FF FF FF 
FF FF FF FF 05 FF 
FF FF FF FF FF FF 
C1 7F 
root@OpenWrt:/# spidev_test -D/dev/spidev32766.1 -s64000000
spi mode: 0
bits per word: 8
max speed: 60000000 Hz (60000 KHz)

20 1F F0 00 1F FF 
FF FF FF FF FF F8 
2F FF FF FF FF FF 
FF FE 0B FF FF FF 
FF FF FF FF 82 FF 
FF FF FF FF FF FF 
E0 BF 

I do not know a byte of the result, but I am sure the result is not random noise.
So I guess the TF card support up to 30MHz, it is 1/4 of system timer who is 120MHz.

The result has so many 0xFF, that might be an error result due to R3(MISO) is pulled to VCC.
So I change the hardware a little, switch R3 from pulling to VCC to pulling to GND. If the result has many 0x00 replace that 0xFF, the hardware must not right and the result is not really from TF card.

root@OpenWrt:/# spidev_test -D/dev/spidev32766.1 -s32000000
spi mode: 0
bits per word: 8
max speed: 32000000 Hz (32000 KHz)

00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 
root@OpenWrt:/# spidev_test -D/dev/spidev32766.1 -s32000000
spi mode: 0
bits per word: 8
max speed: 32000000 Hz (32000 KHz)

40 3F E0 00 3F FF 
FF FF FF FF FF F0 
5F FF FF FF FF FF 
FF FC 17 FF FF FF 
FF FF FF FF 05 FF 
FF FF FF FF FF FF 
C1 7F 
root@OpenWrt:/# 

First result, the slot of TF card is empty.
Second result, plug TF card into slot. It is same result as we pull MISO to high. I am sure now, the data is from TF card.

So, the hardware is totally fixed, just need to find a way to make the mmc-spi-slot driver work. That will take some time, have to go plan B, no time left for factory firmware.

Finally here is some good news. The SD card reply me.. 😀 Not sure whose problem now(might not the hardware problem), due to the reply is from spidev_test, the mmc driver still refuse its work. 🙂
PS: VoCore: SPI & MicroSD 6 is done yesterday actually. Just too busy to publish it.

Anyway, R4 R5 is removed from the dock.

This is the result.

spidev_test is in linux source, at /linux-3.10.49/Documentation/spi/spidev_test.c
And add this code to VOCORE.dts:spi@b00 to enable spidev driver.(replace that mmc-slot@1 if it exists)

spidev@1 {
    compatible = "linux,spidev";
    reg = <1>;
    spi-max-frequency = <1000000>;
};

spidev_test is simple, just send the SD boot code through the SPI to the microSD card.
I did not check whether or not the reply is correct yet 🙂 Have some food first, I guess there is no big issue.

The factory contacted me today, the first 200pcs(beta, same as release one) will be done about Aug.12 and I need at least one day to test the new firmware, so there is only three days left to SPI CS1 driver, or we have to go plan B, leave that part alone for mass production then use update firmware to fix that.

Just did more test and check today.
There are some missing parts(it should not in openwrt code either)

SPI RESET REGISTER(address: 0x10000034)

SPI CS1 MODE REGISTER(address: 0x10000060)

SPI CS1 WATCHDOG RESET NOTE

This note is not that important, but this remind me, we have some SPI pin be pulled to GND in VoCore for the bootstrap!!!

They are SPI_CLK, SPI_MOSI. 🙂

There are push to GND…

And compare my dock circuit, they are pull to VCC…

Ye, HERE IT IS, my dock is not compatible with that VoCore.

That might the possible reason why the TF card do not reply me. The circuit is like this now…That 20K ohm resistor is planed to pull SPI_MOSI to VCC but now weaken the signal, due to that 4.7k ohm push it to GND… 0.8V happens to at the edge of VIL(Input LOW Voltage) of microSD card.

There is no big issue for dock, this part is able to public now 🙂
R1, R2 is 300ohm, rest are all 20Kohm.(R4, R5 NC)

VoCore.dock.sch
VoCore.dock.pcb