About the forum on freshdesk.

Hi every reader,
Due to many people report me the forum server(freshdesk.com) is in their mail spam list, so they can not register or receive mail from it…

And another big issue is this freshdesk.com is not friendly at all. After the free trial over, they just close the forum(nobody is able to login) and do not give me even a minute to move the data or public a notify! I really hate that and do not trust them anymore.

Lucky me, there is not many topics yet, I have to move it back to vonger.cn, at least this is under my control. A new forum is here http://vonger.cn/?forum=vocore.

VoCore: SPI Flash Unique ID

SPI microSD is not done yet :) Just finish an easy driver patch.
This patch is used to get unique id from flash chip. That id is also VoCore Unique ID(unless you change the flash chip). It will be used to get back factory setting(include mac address, wifi parameter, etc.) If you change the flash partition “factory”(512 bytes) and want to change it back. That factory setting can be downloaded from this site by this VoCore Unique ID.

Download new driver file m25p80.c

diff the origin m25p80.c and my m25p80.c

< /* Used for Winbond flashes only. */
< #define OPCODE_WINBOND_ID    0x4b    /* Get flash unique id */
< /* flash unique id probe */
< static int unique_id_prob(struct spi_device *spi, u8 *id)
< {
<     int			tmp;
<     u8			code[5];
<     code[0] = OPCODE_WINBOND_ID;
<     tmp = spi_write_then_read(spi, &code, 5, id, 8);
<     if (tmp < 0) {
<         pr_debug("%s: error %d reading UNIQUE ID\n",
<                 dev_name(&spi->dev), tmp);
<         return tmp;
<     }
<     return 0;
< }
<     /* show unique id in kernel debug log for w25q64 or w25q128. */
<     if(info->jedec_id == 0xef4017 || info->jedec_id == 0xef4018) {
<         u8 unique_id[8];
<         if(!unique_id_prob(spi, unique_id)) {
<             dev_warn(&spi->dev, "flash id: %02x%02x%02x%02x%02x%02x%02x%02x\n",
<                     unique_id[7], unique_id[6], unique_id[5], unique_id[4],
<                     unique_id[3], unique_id[2], unique_id[1], unique_id[0]);
<         } else {
<             dev_warn(&spi->dev, "failed to get flash unique id.\n");
<         }
<     }

Part of bootup log:
This is tested by using winbond flash, but from read other chip datasheet, this is supported too.

Now the openwrt is compiled under mac :) I do not have to use linux vm anymore. This makes the process a little faster. Thanks Markus Z for the tip, http://vocore.freshdesk.com/support/discussions/topics/1000033335

PS: there is a small bug in m25p80.c, jedec id of s25fl064k and w25q64 are same. w25q64(Winbond) jedec id is correct, so s25fl064k(Spansion) has a wrong id in the source. Is there anybody know its real jedec id? We should fix that little bug in linux kernel.

VoCore: SPI & MicroSD 3

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


From openwrt side, one file related to it.

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(0×04) 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: SPI & MicroSD 2

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)
Screen Shot 2014-07-07 at 17.11.50

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.

VoCore: Temperature

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. :)

VoCore: SPI & MicroSD

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. :D

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.
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.

This part will cost some time :)

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