1. use bl_mcu_sdk as submodule than intrusive modification (because bouffalolab has not accept my pr)
2. move codes to firmware/app/usb2uartjtag and do a few fixes because of updated sdk
3. move usbd_ftdi.c/.h also to firmware/app/usb2uartjtag and update CMakeList.txt
4. delete ld file because not needed
5. update the build_firmware.yml with checked and passed

Details about codes fix:

1. change DMA_CHANNEL_* to DEVICE_CTRL_DMA_CHANNEL_* in uart_interface.c
2. change uart_register() and dma_register() to use two params than three
3. change irq_disable() and irq_enable() to cpu_global_irq_disable() and cpu_global_irq_enable()

All of my work are just move and rename and a little fix, and if there is any bug I cant recognized, please tell me and I will reply soon.

Application usb2dualuart is added to examples/usb/usb2dualuart.

Basically, usb2dualuart is cloned from usb2uartjtag and kept close resemblance. Unfortunately, the BSP has to be modified.

Known issues :

• no idea how the EEPROM is functioning, related code not modified
• no idea what's going on with SIO_POLL_MODEM_STATUS_REQUEST in ftdi_vendor_request_handler()
• bflb_platform_printf() is not nullified at compile-time, it is disabled at runtime instead
• documentation not updated

To build, run "make APP=usb2dualuart"

The mpsse implementation seems to be buggy. I cannot get this adapter to reliably work with OpenOCD. At times OpenOCD just hangs with the message "Haven't made progress in mpsse_flush()..."

This seems to happen more with OpenOCD 0.11.0-4, but I have also seen it happen with 0.10.0, which comes with Ubuntu (18.04 LTS).

With my purchased Sipeed RV Debugger Plus, which seems to use this firmware, I am not getting any successful JTAG connection using OpenOCD.

One issue is that the setup and hold times on TDI and TMS are near zero. This is wrong!

TDI and TCK toggle AT THE SAME TIME. Even more so, TDI / TMS also change on the falling edge of TCK. I did not expect this, and it is highly suspicious.

Please fix, as this adapter is totally unusable with a timing like this.

I'm experiencing USB enumeration issues on the Tang Nano 1K, 4K, and 9K boards. It seems that they use the same chip and presumably also the same firmware as this project so I'm reporting it here. Correct me if I'm wrong.

The problem is that when I try to connect the programmer to my computer over a USB hub, it fails to enumerate.

[29332.909014] usb 7-1.2: new full-speed USB device number 8 using xhci_hcd
[29338.196264] usb 7-1.2: device descriptor read/64, error -71
[29343.532540] usb 7-1.2: device descriptor read/64, error -71
[29343.722499] usb 7-1.2: new full-speed USB device number 9 using xhci_hcd
[29348.862626] usb 7-1.2: device descriptor read/64, error -71
[29354.196037] usb 7-1.2: device descriptor read/64, error -71
[29354.302915] usb 7-1-port2: attempt power cycle
[29354.916045] usb 7-1.2: new full-speed USB device number 10 using xhci_hcd
[29360.086242] xhci_hcd 0000:0a:00.3: Timeout while waiting for setup device command
[29365.419676] xhci_hcd 0000:0a:00.3: Timeout while waiting for setup device command
[29365.626240] usb 7-1.2: device not accepting address 10, error -62
[29365.709582] usb 7-1.2: new full-speed USB device number 11 using xhci_hcd
[29365.709791] usb 7-1.2: Device not responding to setup address.
[29365.916323] usb 7-1.2: Device not responding to setup address.
[29366.123016] usb 7-1.2: device not accepting address 11, error -71
[29366.123294] usb 7-1-port2: unable to enumerate USB device

This also happens on the front-panel USB hubs if there are other USB devices connected to the adjacent ports. However, if I unplug all other devices from the front panel it successfully enumerates again.

Enumeration works fine when directly connecting to USB ports in the motherboard.

I haven't experienced any enumeration issues with my other USB devices on these hubs so it seems like the issue related to the BL702 implementation.

1. entry.S doesn't build with popular toolchains. The fix is exactly the same as in: https://github.com/robertlipe/bl_mcu_sdk/commit/b44f151b2c70917c95ffeec665d23c07e491cbbf

2. $ make download fails when run on a non-Linux system because The uploader is provided as a Linux-only binary. This is an offshoot of https://github.com/bouffalolab/bl_iot_sdk/issues/20

How to build on Debian Buster

To build RV-Debugger-BL702 you need a compiler. which is available in the following 3 packages.

binutils-riscv64-unknown-elf
gcc-riscv64-unknown-elf
picolibc-riscv64-unknown-elf

Current stable, Buster, does not have these packages. So we'll have to borrow them from current testing, Bullseye.

Specifically you'll need the following 3 package files. ( at the time of writing )

pool/main/b/binutils-riscv64-unknown-elf/binutils-riscv64-unknown-elf_2.32.2020.04+dfsg-2_amd64.deb
pool/main/g/gcc-riscv64-unknown-elf/gcc-riscv64-unknown-elf_8.3.0.2019.08+dfsg-1_amd64.deb
pool/main/p/picolibc/picolibc-riscv64-unknown-elf_1.5.1-2_all.deb

Which can be found at the following locations respectively.

https://ftp.debian.org/debian/pool/main/b/binutils-riscv64-unknown-elf/
https://ftp.debian.org/debian/pool/main/g/gcc-riscv64-unknown-elf/
https://ftp.debian.org/debian/pool/main/p/picolibc/

Install those 3 packages using dpkg command.

> dpkg -i binutils-riscv64-unknown-elf_2.32.2020.04+dfsg-2_amd64.deb
> dpkg -i gcc-riscv64-unknown-elf_8.3.0.2019.08+dfsg-1_amd64.deb
> dpkg -i picolibc-riscv64-unknown-elf_1.5.1-2_all.deb

note: you need root privilege

clone this repo and do a small patching.

> git clone https://github.com/sipeed/RV-Debugger-BL702
> cd RV-Debugger-BL702
> echo "add_compile_options(-specs=picolibc.specs)" >> tools/cmake/compiler_flags.cmake
> echo "add_link_options(-specs=picolibc.specs)" >> tools/cmake/compiler_flags.cmake

then edit CMakeList.txt .

@@ -1,1 +1,1 @@
- cmake_minimum_required(VERSION 3.15)
+ cmake_minimum_required(VERSION 3.13)

finally fire up the make command.

> make

and binary firmware file will be created at out/usb/usb2uartjtag/main.bin .

of course you need make and cmake. so do install them if you haven't yet.

> apt install make cmake

note: you need root privilege