In linux kernel, there are several important files for SPI/MMC part.

spi.c
spi.h
mmc_spi.c
mmc_spi.h
of_mmc_spi.c

From openwrt side, one file related to it.
spi-rt2880.c

But spi-rt2880.c only supports one SPI device, the flash chip.
There is a patch but not work, after I apply that, get the following error log.

[   15.050000] mmc_spi spi32766.1: OF: voltage-ranges unspecified
[   15.060000] mmc_spi spi32766.1: ASSUMING 3.2-3.4 V slot power
[   15.100000] mmc_spi spi32766.1: TX failed, err=-145
[   15.110000] mmc_spi spi32766.1: TX failed, err=-145
[   15.120000] mmc_spi spi32766.1: setup: unsupported mode bits 4
[   15.130000] mmc_spi spi32766.1: can't change chip-select polarity
[   15.140000] mmc_spi spi32766.1: setup: requested speed is too low 400000 Hz
[   15.180000] mmc_spi spi32766.1: SD/MMC host mmc0, no DMA, no WP, no poweroff

In the datasheet, RT5350 SPI is so good. All SPI features are supported, even SPI slave mode.

RT5350 SPI have the following features:
1. MSB first or LSB first
2. SPI clock default state 0 or 1
3. RX/TX data captured on the rising or falling edge of the SPI clock signal.(So RT5350 supports all the four modes of SPI)
4. SPI polarity indicator low active or high active.

Looks like there is no hardware problem to make the microSD over SPI come true. 🙂

[   15.050000] mmc_spi spi32766.1: OF: voltage-ranges unspecified
[   15.060000] mmc_spi spi32766.1: ASSUMING 3.2-3.4 V slot power
[   15.100000] mmc_spi spi32766.1: TX failed, err=-145
[   15.110000] mmc_spi spi32766.1: TX failed, err=-145

In dts, I did not add the voltage-ranges, after add that line, this fixed.
This voltage-ranges is useless but necessary to compatible with mmc-spi/spi driver, RT5350F do not have hardware support that feature.

[   15.120000] mmc_spi spi32766.1: setup: unsupported mode bits 4

This is caused by SPI_CS_HIGH(0x04) is not proper supported by rt2880-spi driver.

[   15.130000] mmc_spi spi32766.1: can't change chip-select polarity

rt2880-spi driver do not support that too, old driver only support one spi slave, do not need that. The patch has some code about that, but there might be bug.

[   15.140000] mmc_spi spi32766.1: setup: requested speed is too low 400000 Hz

This is not a real problem, the dts error stopped platform struct init, so setup is trying to setup the speed to zero.

Now, code is the only solution. 🙂
First, I will try to fix the patched rt2880-spi driver.
Then try to write a new one(rt5350-spi.c?) support all 5350 SPI features, so it will have a better compatible with linux SPI driver or other device based on SPI.

VoCore Bottom/Top:

VoCore with Dock:

VoCore using Dock as heat sink, the max temperature is under 61C 

I am happy now 🙂 The environment temperature is 30.4C

I soldered it last night. 🙂

The VoCore with Dock size is 25x25x19mm.

This is the final logo for release, everything is ready!

These days when I read the linux SPI driver code, I find there is no big issue to have two SPI slave device on one SPI master at driver part.

SPI mmc(mircoSD) is mostly used to download, it will take most of SPI traffic.
SPI flash is only used when the system is booting…then unless you change config or download ipk, it is free.

This is the key message in the source: (include/linux/spi.h:335)

The logic to assign SPI traffic is FIFO. SPI traffic is based on SPI message, that is atomic for one message.(There is a cs_change inside the message structure to break the message transfer, but we will never use that for this simple situation) So even there is heavy load on SPI mmc part, SPI flash part will not be fatal delayed once its SPI message in the FIFO queue.

If there is no other special condition, I think the work I need to do is just change the dts file, add mmc-spi-slot to that dts, and it will work normal.

In the mmc_spi.c, why they leave that note?
Still need to do more research on the source code.

From alpha test, there are some people report me the RT5350 chips were so warm.
I had found that in v0.3, v0.5, in fact, that is not a big issue.(the people worried about that, due to for most situations the higher temperature means the chip is not stable)
This is the part from RT5350F datasheet:

Maximum Junction Temperature(Plastic Package), not sure it means the plastic case or the inside semiconductor. I get from my infrared thermometers, max case temp is below 70C(that time it is early summer my house is about 24C). If inside temp is 20C more than outside, it will be 90C, still far from 125C, so that is hot but will effect module stable.
In Operating Conditions, it works from -10C to 55C, in my test, it should be the house temperature. In my old blog, I referred, it worked normal in Xi’an outdoor temperature over 50C. That almost reach its max. Just make a simple calculate on that situation, the junction temperature on plastic shell should be around 120C. So if you do not leave it in Sahara Desert, it should work normal.

This module is mainly for hobbyist, and from this part of datasheet, I do not recommend to use it in industry. RT5350 is the bottleneck of VoCore, rest chips(SDRAM, Flash, DC-DC, Reset) are much better than it(-40C~85C), but RT5350 is never a performance chip, it is a cost-effective chip 🙂 From the first version, I choose it for its balance. Maybe MT7688 will be better, but I do not think that will have as good cost as RT5350.

There are some ways to lower the chip temperature:
1. Thermal holes under the 5350 chip.
For current VoCore size… No way to add that. 🙂
2. Heak sink.
As I said, use the dock as heat sink, will lower its temperature at least 10C.
3. Lower CPU frequency.
This is also a good choice, but need to do it on hardware part…once done, hard to change back, so if there is any software way, this will be better.
4. Software shutdown function.
There are scripts in RT5350F SDK can be used to shutdown function of RT5350. But openwrt do not have that. I think I can get that memory address and make it work on openwrt. It will save some power and also lower the temperature.

Any other good ideas are welcomed here. 🙂

Hardware part do not have big issue now, just pin 9, 10 are the microSD detector pin, but there is no place on PCB, have to ignore them…

Now working on the software part, that really stunned me. 😀

I thought that should be already perfectly supported by openwrt driver…But after I check the  driver carefully, I think I have to modify that code or find another way.

The code is under linux kernel source, source/drivers/mmc/host/mmc_spi.c

There is a note in that source…

 58  * - MMC depends on a different chipselect management policy than the
 59  *   SPI interface currently supports for shared bus segments:  it needs
 60  *   to issue multiple spi_message requests with the chipselect active,
 61  *   using the results of one message to decide the next one to issue.
 62  *
 63  *   Pending updates to the programming interface, this driver expects
 64  *   that it not share the bus with other drivers (precluding conflicts).

Does that mean this driver can not work with the exists SPI flash?

And there is a good solution but for other router chip.
http://wiki.openwrt.org/ru/toh/tp-link/tl-mr3420/deep.mmc.hack
I did not try that yet, it might be able to work on RT5350 but need more checks.

I do not want to use GPIO for this, but this way looks much easier.
http://wiki.openwrt.org/doc/howto/mmc_over_gpio

This part will cost some time 🙂

Any idea is welcome here. Please leave a comment, that will help a lot. 🙂

🙂 I do not have to maintain this forum now.

Software Part:

Here is my kermit config(put it in ~/.kermrc).(other UART software should work too)
(to get kermit into mac, please install macport then call sudo port install kermit)

set line /dev/tty.usbserial
define sz !sz \%0 > /dev/tty.usbserial < /dev/tty.usbserial
set speed 57600
set carrier-watch off
set prefixing all
set parity none
set stop-bits 1
set modem none
set file type bin
set file name lit
set flow-control none
set prompt “MacOS Kermit> ”

Let me explain this:
57600, 8, n, 1, those are the most important parameters.

set line /dev/tty.usbserial
USB-TTL driver position.

set speed 57600
default speed is 57600.

set parity none
8n1, n is this one.

set stop-bits 1
8n1, 1 is this one.

Then, use kermit -c to connect to the UART.

Upload firmware through UART.
There are two ways to download(press ‘x’ once VoCore is booted):
1. tftp
2. uart(loadb then jump out kermit console to send the file)

After load the bin file, then erase linux part by command

erase linux

Final, copy bin to flash.

cp.linux 2c0004

2c0004 is the size of my bin file, change to yours.

I highly recommend to use mtd through wifi, that is much faster.

Hardware Part:

Need one USB-TTL:

USB-TTL needs three pins(the red part of the following picture) to connect to VoCore.
VoCore.RXD2 => USB_TTL.TXD
VoCore.TXD2 => USB_TTL.RXD
VoCore.GND/Power.GND => USB_TTL.GND
(do not forget connect their GND together, or there will be a lot of garbled text)

WARNING: this is alpha board pin map, release version pin map please read the datasheet on vocore.io/wiki Introduce part.

WARNING: this is alpha board pin map, release version pin map please read the datasheet on vocore.io/wiki Introduce part.

The blue part is the power pin.
It allows 3.3V~6.0V power input, my suggestion is to use 3.6V~5.4V due to input power is converted by DCDC. If you use 3.3V input, please directly connect to 3.3V at the orange part.

The orange part 3.3V can be use as
a. Output: if you connect power to 3.3V~6.0V pin.
b. Input: if you connect 3.2~3.4V power to it.

power 3.3V~6.0V input is convert to 3.3V then to the chip.
Like this:

My compiled Kermit: http://vonger.cn/upload/tools/kermit

The dock features are confirmed.

1. USB(5V power).
2. USB 2.0 host.
3. RJ45 with protection and two GPIO controlled LED.
4. Micro SD card(TF Card) slot.
5. Two 2.0mm screws hole.

All tests are passed 🙂

The small dock is used to make the tiniest DIY router(29.0 x 27.0 x 21.4mm), it is not a breakout board…someone said my breakout board is ridiculous, now I can tell him, he made a mistake. 😀 That is never my real target from beginning.(but anyway, it can be used as a breakout board if you want 🙂 )

Really thank for my friend Zhiwei De 🙂 We will provide the 3D printer plastic shell blueprint later, then a very small router with SD card slot is born(and it can be used same function as PirateBox but a little more portable and more functions)

Here is the video:

This is only for alpha, release version do not need such fix 🙂
Thanks for my teammate WuTong, this video looks so professional. And special thanks for my friend Alex helped to make this video.

Some notes from WuTong:

1. Better to have a tip iron, that will help a lot.

2. Better to have this tool to keep it in position.

3. Better to have a light.

PS: in the package there are are some resistors, four 154Kohm and four 158ohm, those are useless now, just ignore them.