VoCore: Mass Production 6

I am crazy…
The factory just made a new big mistake(or accident), they deleted all the test log, just for a stupid reason, those test logs took too much disk space…and they ‘think’ the productions had done the test, that should be useless. Simply ignore my notify, ye, I notified them to keep the log at least three times, in face or phone call. T-T Now they are trying to recover the deleted data…
I planed to use that log to trace the production quality…If user gets the VoCore but has problem, at least I have some data to trace.
They agree if the log can not back, they will test again, but I can not wait. Just hope the log be recovered.

VoCore: Two UARTs

Enable two UARTs for VoCore, one UART lite, one UART full.
Just need to change DTS a little:(new dts)

/dts-v1/;

/include/ "rt5350.dtsi"

/ {
	compatible = "VoCore", "ralink,rt5350-soc";
	model = "VoCore";

	palmbus@10000000 {
		gpio1: gpio@660 {
			status = "okay";
		};

		i2c@900 {
			status = "okay";
		};

		spi@b00 {
			status = "okay";

			m25p80@0 {
				#address-cells = <1>;
				#size-cells = <1>;
				compatible = "w25q128";
				reg = <0>;
				linux,modalias = "m25p80", "w25q128";
				spi-max-frequency = <10000000>;

				partition@0 {
					label = "uboot";
					reg = <0x0 0x30000>;
					read-only;
				};

				partition@30000 {
					label = "uboot-env";
					reg = <0x30000 0x10000>;
					read-only;
				};

				factory: partition@40000 {
					label = "factory";
					reg = <0x40000 0x10000>;
					read-only;
				};

				partition@50000 {
					label = "firmware";
					reg = <0x50000 0xfb0000>;
				};
			};
			
			mmc-slot@1 {
				compatible = "mmc-spi-slot";
				reg = <1>;
				voltage-range = <3300 3300>;
				spi-max-frequency = <10000000>;
				broken-cd;
			};
		};
	
		uart@500 {	
			status = "okay";
		};
	};

	pinctrl {
		state_default: pinctrl0 {
			gpio {
				ralink,group = "jtag", "led";
				ralink,function = "gpio";
			};
		};
	};

	ethernet@10100000 {
		mtd-mac-address = <&factory 0x4>;
	};

	esw@10110000 {
		ralink,portmap = <0x17>;
	};

	wmac@10180000 {
		ralink,mtd-eeprom = <&factory 0>;
	};

	ehci@101c0000 {
		status = "okay";
	};

	ohci@101c1000 {
		status = "okay";
	};

	gpio-export {
		compatible = "gpio-export";
		#size-cells = <0>;

		gpio0 {
			gpio-export,name = "gpio0";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio0 0 0>;
		};

		/* JTAG */
		gpio17 {
			/* JTAG_TDO */
			gpio-export,name = "gpio17";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio0 17 0>;
		};
		gpio18 {
			/* JTAG_TDI */
			gpio-export,name = "gpio18";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio0 18 0>;
		};
		gpio19 {
			/* JTAG_TMS */
			gpio-export,name = "gpio19";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio0 19 0>;
		};
		gpio20 {
			/* JTAG_TCLK */
			gpio-export,name = "gpio20";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio0 20 0>;
		};
		gpio21 {
			/* JTAG_TRST_N */
			gpio-export,name = "gpio21";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio0 21 0>;
		};

		/* ETH LEDs */
		gpio22 {
			/* ETH0_LED */
			gpio-export,name = "gpio22";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio1 0 0>;
		};
		gpio23 {
			/* ETH1_LED */
			gpio-export,name = "gpio23";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio1 1 0>;
		};
		gpio24 {
			/* ETH2_LED */
			gpio-export,name = "gpio24";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio1 2 0>;
		};
		gpio25 {
			/* ETH3_LED */
			gpio-export,name = "gpio25";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio1 3 0>;
		};
		gpio26 {
			/* ETH4_LED */
			gpio-export,name = "gpio26";
			gpio-export,direction_may_change = <1>;
			gpios = <&gpio1 4 0>;
		};
	};

	gpio-leds {
		compatible = "gpio-leds";
		status {
			/* UARTF_RXD */
			label = "vocore:green:status";
			gpios = <&gpio0 10 0>;
		};
		eth {
			/* UARTF_DTR_N */
			label = "vocore:orange:eth";
			gpios = <&gpio0 11 0>;
		};
	};
};

First, enable uart@500

uart@500 {	
	status = "okay";
};

Then, remove uartf from ralink,group:gpio.

	pinctrl {
		state_default: pinctrl0 {
			gpio {
				ralink,group = "jtag", "led"; -> remove "uartf"
				ralink,function = "gpio";
			};
		};
	};

Finally, delete the code that export uartf as gpio:
in gpio-export section, remove gpio7, gpio8, gpio9, gpio10, gpio11, gpio12, gpio13, gpio14. If we keep them will get some error in log, but no effect to system boot.
PS: find a possible bug here, gpio10 and gpio11 are missed :)

Now good news is the two UARTs work same time, bad news is we lose eight gpio. ;)
Hope one day a hero will make a new rt5350-uart driver, so that allows ralink-function=”uartf,gpio”, then we can save 4 gpios. It is a good chance to practise Linux driver code. :D

New Site VoCore.io

The new site has opened recently :)
I try to make the site as simple as possible, hope you like it.
Special thanks to Kovács Kornél, a great work.
Some parts are still under construction, if you have good idea, please mail to vonger@live.com.
Especially the wiki part :D

view

VoCore: SPI & MicroSD 11

Just waiting for factory…So I am on SPI again. :)

Last time I have done the driver, but it is not working with mmc. I think there must be something wrong with it, but after my test, the driver works quite well, so I guess I should make some mistake in mmc driver config.
NEW SOURCE CODE HERE: spi-rt2880.c

I soldered another flash to a bare VoCore board, so I do not have to solder the eight wires. Connect CS1->CS0, SPICLK->SPICLK, MOSI->MOSI, MISO->MISO, also pull HOLD/WP to high, so now VoCore SPI1 is controlling the second flash.
It works very well by current openwrt in high speed(>935KHz).

Add the following code to replace spidev@1 in VOCORE.dts, set the flash to 500KHz.

m25p80@1 {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "w25q128";
    reg = <1>;
    linux,modalias = "m25p80", "w25q128";
    spi-max-frequency = <500000>;

    partition@0 {
        label = "xxxx";
        reg = <0x0 0x1000000>;
    };
};

Hardware part connection:
IMG_20140929_101537

IMG_20140929_101119

From my test, the data is normal.

root@OpenWrt:/sys/devices/10000000.palmbus/10000b00.spi/spi_master/spi32766/spi32766.1# ls
driver      factory_id  modalias    mtd         subsystem   uevent
root@OpenWrt:/sys/devices/10000000.palmbus/10000b00.spi/spi_master/spi32766/spi32766.1# cat factory_id
D26210-44DB40312F

Its log:

Mon Sep 29 02:06:27 2014 authpriv.notice dropbear[1175]: Password auth succeeded for 'root' from 192.168.61.159:58928
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.940000] m25p80 spi32766.1: low speed mode.
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.960000] m25p80 spi32766.1: delay = 1000
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.970000] m25p80 spi32766.1: low speed mode.
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.980000] m25p80 spi32766.1: delay = 1000
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.980000] m25p80 spi32766.1: cs = 1, on
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1462.000000] m25p80 spi32766.1: bit/x: 8,5
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1462.000000] m25p80 spi32766.1: low speed mode.

Read data from the flash is also normal, just a little slow:

root@OpenWrt:/# hexdump -C /dev/mtdblock6 | head -10
00000000  27 05 19 56 d6 62 66 a6  53 88 7f 17 00 01 96 c0  |'..V.bf.S.......|
00000010  80 20 00 00 80 20 00 00  a3 c1 ed e5 05 05 01 00  |. ... ..........|
00000020  53 50 49 20 46 6c 61 73  68 20 49 6d 61 67 65 00  |SPI Flash Image.|
00000030  06 50 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.P..............|
00000040  ff 00 00 10 00 00 00 00  fd 00 00 10 00 00 00 00  |................|
00000050  e9 01 00 10 00 00 00 00  e7 01 00 10 00 00 00 00  |................|
00000060  e5 01 00 10 00 00 00 00  e3 01 00 10 00 00 00 00  |................|
00000070  e1 01 00 10 00 00 00 00  df 01 00 10 00 00 00 00  |................|
00000080  dd 01 00 10 00 00 00 00  db 01 00 10 00 00 00 00  |................|
00000090  d9 01 00 10 00 00 00 00  d7 01 00 10 00 00 00 00  |................|

I think last time I should did something wrong in the mmc driver config…

VoCore: How to Get FCCID

Many people ask me about how to pass the FCCID. In fact, the process is not that complex.

That is benefit to there are many module companies’ productions are using RT5350 in ShenZhen, and the foundry I choose has such production already(they also many good software, I am free to use). So I just send VoCore sample to the laboratory, and leave the foundry engineer’s phone number to the laboratory, they did rest for me, that saved me a lot of time.

PS: before the sample send to Lab, the beta version has already tested in factory, all results look good, so my confidence is from there.

About the sample, first of all, the board must in good quality. I am not sure what test they will do, but if the quality is not good, it might broken in half way. My samples are made by machine, better than my hand make ones.

About the test process, I knows little about that, I only know if the EMC can not pass, the laboratory will ask you if you want to add a metal shell, then do the test again(of course, your FCCID production photo will show the shell too, and your final production must have that metal shell)

VoCore passed FCCID in one time without any shell, that should thanks to the simulation software, when I design it, I set its simulation parameters to 1GHz, 3.3V to all traces, the sim result max crosstalk voltage is under 60mV, it should be a good result due to other board such as RM04 the crosstalk value greater than 300mV, its 30% traces even more than 800mV, maybe such reason they have to have a shell. The software I used name is HyperLync. :)

To lower the crosstalk voltage, we must keep trace distance 3W at least. And the trace should as short as possible.

Autumn comes, my house temperature is 25C, and test on new VoCore with dock several hours, the max temperature on the surface is lower than 50C, very good :) not hot anymore, just a little warm.

VoCore: Mass Production 5

Now, looks like everything is back to normal, all parts are ready now.
This is the ship time update:
If no big issue again, VoCore will be in SMT line about this Wednesday.
SMT will be done about this Sat, then test will take 3~4 work days.
Sep.30~Oct.6, the seven days is China National Day, so factory will not do any work.
Today will prepare the early bird ship.(early bird with dock will ship with the composed batch).
Oct.7 will ship the VoCore without dock.
VoCore + Dock(solder the pins, compose VoCore & Dock, package and test) will take about 5~7 work days.
So composed VoCore + Dock will ship about Oct.13~Oct.17.