Shell File: Download Here
Weight:
3.0g VoCore
6.0g Shell
20.0g VoCore + Dock + Shell
VoCore: Driver Attribute
I need to export flash factory id to user space, but current m25p80.c do not support that. My old blog has get that id, and output it into log.
Now move a little forward, show it in user space.
We can get the id by cat its interface.
cat /sys/devices/10000000.palmbus/10000b00.spi/spi_master/spi32766/spi32766.0/factory_id D16330-6417232123
The code is simple, need to change two parts of the source.
First add attribute to m25p80.c
static ssize_t m25p_factory_id_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
const struct spi_device *spi = to_spi_device(dev);
u8 code[5], id[8];
code[0] = OPCODE_FACTORY_ID;
if(spi_write_then_read(spi, &code, 5, id, 8) < 0)
return sprintf(buf, "\n");
return sprintf(buf, "%02X%02X%02X-%02X%02X%02X%02X%02X\n",
id[0], id[1], id[2], id[3], id[4], id[5], id[6], id[7]);
}
static DEVICE_ATTR(factory_id, S_IRUGO, m25p_factory_id_show, NULL);
DEVICE_ATTR is used to declare attribute, it has four parameters:
factory_id is the name, that is also the attribute file name in sys folder.
S_IRUGO is the file access privilege, S_IRUGO = r--r--r--
m25p_factory_id_show is a callback once user call standard read through factory_id(that sys attribute interface file).
NULL is a callback for standard write, but we do not need that for current usage, so it is null.
OPCODE_FACTORY_ID is 0x4b, that is from datasheet. Looks like every SPI flash chip has that interface and a factory id, so why not make it as a public attribute?
Now, the attribute interface is ready.
We put the following code into m25p_probe(before return), so once the driver is ready, this attribute will show in the sys folder.
device_create_file(&spi->dev, &dev_attr_factory_id);
Also will commit a patch to openwrt.org, need some time learn how to do that. 🙂
VoCore: SPI & MicroSD 9
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.
VoCore: Mass Production
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. 🙂
VoCore: Dock PCB Ready
So beautiful 🙂 Feel like they are unreal.
VoCore: First Batch & Manual
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.
VoCore v1.0 & Dock Mass Production Schedule
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.
VoCore v1.0 Pin Map
VoCore: SPI & MicroSD 8
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.
VoCore: SPI & MicroSD 7
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.