This blog will include two parts, first, make one VoCore2(name it host) into a JTAG compatible device, like JLINK; second, enable another one VoCore2(name it client) JTAG port, so we can use host JTAG connect to it and debug.

OK, let’s start how to make it.

JTAG Host Device

1. OpenOCD only requires some GPIOs to make the JTAG work in TAP mode, so let’s define some GPIOs as JTAG pins.

JTAG has five pins, TMS, TCLK, JRST, TDO, TDI. SRST is for system reset, openOCD will use this pin to reset client VoCore.

2. Add pull up resistor to all of the JTAG pins.

3. Now install openocd to VoCore2. I have uploaded openocd package Makefile to github.com/vonger/vocore2, in utils/openocd folder, or you can directly use the openocd Makefile in openwrt official feeds named “package”.

It will require some depends: hidapi_0.8.0-rc1-2_mipsel_24kc.ipk, libftdi1_1.4-6_mipsel_24kc.ipk, libusb-1.0_1.0.22-1_mipsel_24kc.ipk, libusb-compat_0.1.5-1_mipsel_24kc.ipk

Note: actually we do not need hidapi, libusb, but install it is the most easy way, so we do not have to modify its Makefile.

4. Download openOCD configure file for VoCore2. I am using configure from https://github.com/Neutree/MT7688-OpenOCD, jlink-gpio.cfg. Because my GPIO setting is different, so need to modify its pin define.

# tck tms tdi tdo
 sysfsgpio_jtag_nums 40 41 42 43
 sysfsgpio_srst_num 39
 sysfsgpio_trst_num 38 

 bindto 0.0.0.0

Note: For OpenWrt 21.02, gpio start from 416, not 0. It is weird but true, we need to use gpio 456(416+40) to export gpio 40. It should be sysfsgpio_jtag_nums 456 457 458 459.

Now, this host JTAG VoCore2 prepare is done. Actually it is ready to debug any JTAG compatible device, just need different cfg files.

If you want to access it from remote, must add bindto command, or openocd will bind to localhost only, can not access from outside. Sad, I spend two hours to solve this problem, I thought it was firewall issue. 🙁

JTAG Client Device

1. We need to change default bootstrap from GPIO to JTAG. One way is directly modify register 0x10000010 SYSCFG0, but it will back to GPIO mode once you reboot. Another way is to modify bootstrap resistor, we have to use this way.

2. connect host JTAG cables to it. All of the six cables are necessary.

3. connect client VoCore2 and host VoCore2 GND together, to avoid data transfer issue.

Ready to RUN!

Now we have prepared the JTAG host device and a test client device. We can power them on with 5V.

In host VoCore2, run command: openocd -f jlink-gpio.cfg &, it will create a server process, in jlink-gpio.cfg, we define telnet port is 4444 and gdb port is 3333, then we can use telnet connect to VoCore2 4444 port(remember to open the port at firewall).

Here is my log:

 root@OpenWrt:~# openocd -f jlink_gpio.cfg
 Open On-Chip Debugger 0.10.0
 Licensed under GNU GPL v2
 For bug reports, read
 http://openocd.org/doc/doxygen/bugs.html
 SysfsGPIO nums: tck = 40, tms = 41, tdi = 42, tdo = 43
 SysfsGPIO num: srst = 39
 SysfsGPIO num: trst = 38
 adapter_nsrst_delay: 100
 Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
 jtag_ntrst_delay: 100
 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
 0
 Info : SysfsGPIO JTAG/SWD bitbang driver
 Info : JTAG only mode enabled (specify swclk and swdio gpio to add SWD mode)
 Info : This adapter doesn't support configurable speed
 Info : JTAG tap: mt7688.cpu tap/device found: 0x1762824f (mfg: 0x127 (MIPS Technologies), part: 0x7628, ver: 0x1)
 
 

And telnet side (I am new to openOCD, I guess this log means it already works somehow)

 
 Vongers-MacBook-Pro-2:~ vonger$ nc 192.168.61.1 4444
 Info : accepting 'telnet' connection on tcp/4444
 Open On-Chip Debugger
 > ddrinit
 ddrinit
 Warn : target not halted
 target not halted
 Error: mem2array: Read @ 0xb0000028, w=4, cnt=1, failed
 mem2array: Read @ 0xb0000028, w=4, cnt=1, failed
 jlink_gpio.cfg:50: Error: 
 in procedure 'ddrinit' 
 at file "jlink_gpio.cfg", line 50
 jlink_gpio.cfg:50: Error: 
 in procedure 'ddrinit' 
 at file "jlink_gpio.cfg", line 50
 > halt
 halt
 target halted in MIPS32 mode due to debug-request, pc: 0x8000b1a8
 target halted in MIPS32 mode due to debug-request, pc: 0x8000b1a8
 > reg
 ===== mips32 registers
 (0) r0 (/32): 0x00000000
 (1) r1 (/32): 0x00000001
 (2) r2 (/32): 0x81000040
 (3) r3 (/32): 0x804E5220
 (4) r4 (/32): 0x810BC180
 (5) r5 (/32): 0x00000000
 (6) r6 (/32): 0x00100000
 (7) r7 (/32): 0x00000001
 (8) r8 (/32): 0x10000000
 (9) r9 (/32): 0x10000000
 (10) r10 (/32): 0x00000000
 (11) r11 (/32): 0x706C6174
 (12) r12 (/32): 0x08000000
 (13) r13 (/32): 0x00000003
 (14) r14 (/32): 0x00000000
 (15) r15 (/32): 0xFF200000
 (16) r16 (/32): 0x804A9A90
 (17) r17 (/32): 0x00008000
 (18) r18 (/32): 0x00000001
 (19) r19 (/32): 0x00100000
 (20) r20 (/32): 0x81000040
 (21) r21 (/32): 0xFFFFFFFF
 (22) r22 (/32): 0x00001001
 (23) r23 (/32): 0x00000000
 (24) r24 (/32): 0x00000003
 (25) r25 (/32): 0x00000002
 (26) r26 (/32): 0x87FF0000
 (27) r27 (/32): 0x00000000
 (28) r28 (/32): 0x80458000
 (29) r29 (/32): 0x80459CD0
 (30) r30 (/32): 0x0000001F
 (31) r31 (/32): 0x80491CE4
 (32) status (/32): 0x10000000
 (33) lo (/32): 0x00000088
 (34) hi (/32): 0x00000000
 (35) badvaddr (/32): 0x77E8BA18
 (36) cause (/32): 0x40008008
 (37) pc (/32): 0xFF200208
 (38) f0 (/32): 0x00000000
 (39) f1 (/32): 0x00000000
 (40) f2 (/32): 0x00000000
 (41) f3 (/32): 0x00000000
 (42) f4 (/32): 0x00000000
 (43) f5 (/32): 0x00000000
 (44) f6 (/32): 0x00000000
 (45) f7 (/32): 0x00000000
 (46) f8 (/32): 0x00000000
 (47) f9 (/32): 0x00000000
 (48) f10 (/32): 0x00000000
 (49) f11 (/32): 0x00000000
 (50) f12 (/32): 0x00000000
 (51) f13 (/32): 0x00000000
 (52) f14 (/32): 0x00000000
 (53) f15 (/32): 0x00000000
 (54) f16 (/32): 0x00000000
 (55) f17 (/32): 0x00000000
 (56) f18 (/32): 0x00000000
 (57) f19 (/32): 0x00000000
 (58) f20 (/32): 0x00000000
 (59) f21 (/32): 0x00000000
 (60) f22 (/32): 0x00000000
 (61) f23 (/32): 0x00000000
 (62) f24 (/32): 0x00000000
 (63) f25 (/32): 0x00000000
 (64) f26 (/32): 0x00000000
 (65) f27 (/32): 0x00000000
 (66) f28 (/32): 0x00000000
 (67) f29 (/32): 0x00000000
 (68) f30 (/32): 0x00000000
 (69) f31 (/32): 0x00000000
 (70) fcsr (/32): 0x00000000
 (71) fir (/32): 0x00000000 

On VoCore2 Ultimate dock, we have a chip GD32F150G8U6 which is used as USB2TTL chip, so we can login to VoCore2 console through USB.

But GD32F150G8U6 has much more function than just USB2TTL, it has AD/DA convert inside. We can disable USB2TTL and switch it to AD/DA function. VoCore2 UART2 can be used to get AD/DA data from GD32F150.

This is current dock GD32F150 part of sch, PA0-PA7 and BOOT are exported; TXD/RXD are connected to VoCore2; USB DM/DP are connected to microUSB on dock.

In order to make AD/DA work, need to write a small firmware for GD32F150. we have toolchain already, use ARM-M3 default toolchain, link is here: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

Also we need some library to help us use the chip. GD32F150 library I upload to the blog server, can download here: http://vonger.cn/misc/vocore2/GD32F1x0_Firmware_Library_v3.1.0.rar

Once compiled finish, we can use gd32up to load it to chip(do not forget to set the BOOT pin to high-5V when flash firmware), source code at github.com/vonger/gd32tools, this one can be compiled by VoCore2 toolchain gcc and run in VoCore2 directly.

Here are some examples source code about GD32F150: http://vonger.cn/misc/vocore2/GD32150G8U6.HSI.zip

VoCore2 Ultimate is using example 22_USB_VirtualComPort, I modified its USB pull up pin in usb_hwp.c to GPIOA,GPIO_PIN_13 to fit the hardware.

To be continue… later I will try to write a demo code about AD/DA firmware.If you want to try it first, check example 18_ADC_conversion_triggered_by_timer and 19_DAC_Digital_To_Analog_Conversion

Currently we can directly use python3.6 on VoCore2.
Install python3 is easy, need to download some ipk packages.
I have uploaded them to http://vonger.cn/misc/vocore2/ipk/
Download the ipk files to VoCore2 /tmp folder, call opkg install *.ipk to install.

note: or download from http://downloads.openwrt.org/releases/18.06.5/packages/mipsel_24kc/packages/, it should be latest version.

Then in VoCore2 directly call python3 to run it.

In order to start further hack on MT7628 spi driver, must make the test process clear first.

I am using spidev_test.c in linux kernel for the test.
To compile it,
1. enable spidev in make menuconfig -> Kernel Modules -> SPI Support -> kmod-spi-dev
2. enable spidev_test in make menuconfig -> Utilities -> spidev_test

For firmware part, need to prepare DTS.
add this to openwrt/target/linux/ramips/dts/VOCORE2.dts:&spi0

        spidev@1 {
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = "rohm,dh2228fv";
                reg = <1>;
                spi-max-frequency = <100000000>;
        };

modify one line to enable spi0 cs1 in openwrt/target/linux/ramips/dts/mt7628an.dtsi
note: this should be optional, without it still work for me, because the cs1 register is default set to cs1 already.

-pinctrl-0 = <&spi_pins>;
+pinctrl-0 = <&spi_pins>, <&spi_cs1_pins>;

And we can use this way to add more SPI device by set some GPIO as CS pin. Later I will write a patch for it.

compatible = “rohm,dh2228fv” this line is necessary, without it, kernel will complain…but actually we do not care which type of device is used.
spi-max-frequency = <100000000> this line means max spi we can set upto 100MHz, I do not think its SPI can reach 100MHz. And from my test, 66MHz should be its max speed. Anyway, without DMA, even 10MHz it can not reach.

spi-mt7621.c this spi driver full duplex mode do not allow buffer size more than 16byte, we use half duplex to avoid issue when test, remove it.

static int mt7621_spi_transfer_one_message(struct spi_master *master,
                                           struct spi_message *m)
{
        struct spi_device *spi = m->spi;
/*
#ifdef CONFIG_SOC_MT7620
      int cs = spi->chip_select;

      if (cs)
              return mt7621_spi_transfer_full_duplex(master, m);
#endif
*/
        return mt7621_spi_transfer_half_duplex(master, m);
}

OK, now we can make the firmware and start to test the origin spi driver.

call “spidev_test -D /dev/spidev0.1 -p 12345678901234567890”, works normal.

Every time when macos update to new version, always broken something, I guess that is an important reason it has very few virus.

When I compile openwrt 18.06.5 in macos, I get new problems.

1. GCC compiler version must greater than 4.8

I have no idea about this issue…it works before, I do not remember I change anything.

Solution:
brew install gcc@9
ln -s /usr/local/bin/gcc-9 /usr/local/bin/gcc
ln -s /usr/local/bin/g++-9 /usr/local/bin/g++
add /usr/local/bin to $PATH(in ~/.profile), set it at higher level than /usr/bin to cover macos default gcc path.

2. variably modified ‘bytes’ at file scope

I think this is because xcode update change the header file…
in standard C language, array size must be const, a fixed number.

This is not allowed(as I remember this way is allowed in C++?):
const int kAuthorizationExternalFormLength = 32;
int array[kAuthorizationExternalFormLength];

But this is OK:
#define kAuthorizationExternalFormLength 32
int array[kAuthorizationExternalFormLength];

Solution:

sudo vi /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h

directly change const to #define. Ugly but works 🙂

3. Emm, after a while, cmake can not compile…
Solution:
rm /usr/local/bin/gcc /usr/local/bin/g++
ln -s /usr/bin/gcc /usr/local/bin/gcc
ln -s /usr/bin/g++ /usr/local/bin/g++

change it back, then works…maybe I should directly patch openwrt Makefile. :’)

Finally I find a better solution
Once 1 passed, we can change it back to gcc 4.2.1 which is macos clang, then everything works normal. so weird.

I make a simple 3D module of VoCore2, hopefully this can help more or less. 🙂

Link: http://vonger.cn/misc/vocore2/vocore2.3d.stp.zip

Preview:

Once I want to use AdHoc as mesh network base…but mt7628 driver do not support it.

Now I just find WDS in the menu…it should be a better way to do mesh, I will study into this, must be a lot of fun 🙂
VoCore2 has so many hidden features, from 2014, it is almost five years, I still can not totally master it.

I wrote a simple tool to update vocore2 firmware or uboot through serial port, now upload to github.
This tool might still have bugs…use carefully, I only tested it with VoCore2 uboot. 🙂

Usage is very simple:

1. use usb2ttl connect to your vocore2 uart2(TXD2/RXD2)
2. reboot vocore2 (or power up it), it will show a list of uboot.
3. press ‘0’, call uboot upgrade firmware.
4. once VoCore2 uboot console shows “## Ready for binary (kermit) download to 0x80100000 at 115200 bps…”, close console. then use this tool, call “nkermit [your port] [file]”
The port is the TTY port, for example, in windows, it is COM1, COM2, COM4 etc…in macos it is /dev/tty.xxxxxxxxx. File is the file you want to upload, normally VoCore2 upgrade firmware file is named by date, like 20191127.bin.

github link: https://github.com/vonger/nkermit

New firmware is ready 🙂

In new firmware, the first release of screen driver is embedded, also fix many bugs.
This will be last version for openwrt 18.06.4, next version we will move to openwrt 18.06.5

Download at http://vonger.cn/misc/vocore2/20191127.bin

Thanks for Leo, I find this new patch https://github.com/openwrt/openwrt/pull/1954.
This patch increases a lot of SPI speed. I have a quick check, looks like it speeds up because of morebuf mode.

...

	/*
	 * Select SPI device 7, enable "more buffer mode" and disable
	 * full-duplex (only half-duplex really works on this chip
	 * reliably)
	 */
	master = mt7621_spi_read(rs, MT7621_SPI_MASTER);
	master |= MASTER_RS_SLAVE_SEL | MASTER_MORE_BUFMODE;
	master &= ~MASTER_FULL_DUPLEX;
	mt7621_spi_write(rs, MT7621_SPI_MASTER, master);

...

static void mt7621_spi_read_half_duplex(struct mt7621_spi *rs,
					int rx_len, u8 *buf)
...
		mt7621_spi_write(rs, MT7621_SPI_MOREBUF, val);

That is nice. A good example about morebuf mode, this should be an important mode for dma. This code saves me a lot time, now I can directly try interrupt and dma.

Currently DMA source address can be fixed and max burst size is 16DWs, in morebuf + half duplex mode we use 8DWs. So DMA should work no problem. We will see later 🙂