bl_iot_sdk
bl_iot_sdk copied to clipboard
bouffalolab
Missing portable flash loader
For Windows there is BLFlashCube and for Linux, there's a binary of flash_build, but not really the source. This is problematic for developers on MacOS (with two processor types), Raspberry Pi, or devices like Chromebooks, both of which are popular in the education and emerging markets.
Could you please consider releasing the tools to program a device totally from source for at least the three major Ones that you've clearly intended to support?
Something that can reset the device to "factory" settings from source, creating partitions, etc. as well as replacing individual programs, and that can be easily automated (such as from Makefiles) would be welcome. Being able to reprogram configuration and code partitions individually seems pretty key.
I was pretty bummed when my prototype device finally arrived and I realized I can't flash it as I've also drawn blanks on programming it with OpenOCD.
Thanx!
@robertlipe Please check https://github.com/bouffalolab/BLOpenFlasher. it is workable. If you have any question, please let me know. BTW, I am trying to change it to pure golang, also will support openocd later.
Thanx. This looks promising. I changed the dev name in the obvious way:
- utils.StartProgram("/dev/ttyUSB0", nil, 512000, "bl602/eflash_loader/eflash_loader_40m.bin", 2000000, bins, 5000)
- // utils.StartProgram("/dev/ttyUSB0", nil, 512000, "bl602/eflash_loader/eflash_loader_40m.bin", 2000000, bins, 5000)
- utils.StartProgram("/dev/cu.usbserial-110", nil, 512000, "bl602/eflash_loader/eflash_loader_40m.bin", 2000000, bins, 5000)
It makes a lot of noise, but dies with a whimper: 13056 0 2 2 = 13056 10420383 0 8 8 = 10420383 CmdReset /dev/cu.usbserial-110---RESET Module--- /dev/cu.usbserial-110 Next to CmdShakeHand /dev/cu.usbserial-110 14:0 <- /dev/cu.usbserial-110 14:0 <- /dev/cu.usbserial-110 14:0 <- /dev/cu.usbserial-110 Next to CmdReset /dev/cu.usbserial-110---RESET Module--- /dev/cu.usbserial-110 Next to CmdShakeHand /dev/cu.usbserial-110 14:0 <- /dev/cu.usbserial-110 14:0 <- /dev/cu.usbserial-110 14:0 <- /dev/cu.usbserial-110 Next to CmdReset /dev/cu.usbserial-110---RESET Module--- /dev/cu.usbserial-110 Next to CmdShakeHand /dev/cu.usbserial-110 14:0 <- /dev/cu.usbserial-110 14:0 <- /dev/cu.usbserial-110 14:0 <- /dev/cu.usbserial-110 Next to CmdReset /dev/cu.usbserial-110 Next to ErrorShakeHand ErrorShakeHand can not be located! /dev/cu.usbserial-110 -----Failure-----
It seems correct that there isn't a function of that name: % ack CmdShakeHand utils/util_program.go 192: return "CmdShakeHand" 195:func (this *config)CmdShakeHand() string{ robertlipe@Roberts-M1 BLOpenFlasher % ack ErrorShakeHand utils/util_program.go 138: return "ErrorShakeHand"
But I'm guessing we should focus on WHY the handshake is failing...
My go is non-existent, but this looks like it's the third iteration of CmdReset() attempting to reconfigure the device and failing.
This is on a PineCone. Jumper for GPIO8 is in the non-default (outer edge) position. Reset button changes nothing. Unplugging changes nothing.
@robertlipe
- Make sure bl602 in program mode, IO8 pull up during booting
- If your uart can not support 512000, use slower baudrate
IO8 was mentioned in my final paragraph.
I can the bit rates down to 9600 without meaningful change.
I multiplied the error maxes by 100 and let it run for a Very Long Time until it ended in the same way. More Retries didn't help.
Confirmed an Intel Mac fails the same way as my M1 did. Will try other OSes soon.
On Tue, Dec 1, 2020, 3:26 AM Yafei [email protected] wrote:
@robertlipe https://github.com/robertlipe
- Make sure bl602 in program mode, IO8 pull up during booting
- If your uart can not support 512000, use slower baudrate
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bouffalolab/bl_iot_sdk/issues/20#issuecomment-736340515, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD354YXSABJMTZAVFPJ3SSSZE5ANCNFSM4UINPDRA .
Yes, with the jumper in the other position and after a reset, I can cu -s 9600 -l /dev/thatserialport and successfully speak with a CLI/admin panel on the BL602. So the serial adapter is recognized on Macs out of the box. There's no visible loss of data; things in columns are in columns and escape sequences aren't garbled.
It behaves identically on my tenured x86 MBP, which has a bunch of random drivers for various GPS and USB/Serial adapters and my fresh-from-the-box M1 MBP, where this was the first serial device attached, I think.s
On Tue, Dec 1, 2020 at 6:22 PM Yafei [email protected] wrote:
Could you please confirm the USB2Uart converter work well on Mac? Thanks
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bouffalolab/bl_iot_sdk/issues/20#issuecomment-736905167, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD33GICGYC37HU6IVWBLSSWCE7ANCNFSM4UINPDRA .
This code was tested on Raspberry Pi. I am setting up env on Mac and will try it tomorrow.
I'm trying to write a program tool in Rust. The protocol part is ok and it's still not available before the implementation of the generation of the image.
https://github.com/spacemeowx2/blflash
Is there some documentation about this? I think I will try to implement it by reading BLOpenFlasher
@spacemeowx2 Thank you very much! I spent some time on this issue@macos, and found it's related to the uart package. So, I am testing rust's performance this afternoon, and glad that you have implemented one. The following is the brief
Partition, load data from partition_cfg_2M.toml 16: [0...3]{0x42 0x46 0x50 0x54} [6...7]{N} [12...15]{crc32 of [0...11]} 36xN：[0...2]{type}[3...11]{name}[12...15]{address0}[16...19]{address1}[20...23]{size0}[24...27]{size1} 4:{crc32 for [16...(16+36*N-1)]}
Image = Bootinfo+compiled.bin BootInfo: load data from efuse_bootheader_cfg.conf, then following configKeys' definition to compose the data. offset: byte offset pos: bit offset after byte offset bitlen: bit width There are some special cases:
- compiled bin is 16byte aligned 2.bootinfo uses 176 byte, and compiled bin's offset is 8K for boot2, 4K for FW, between them all bytes are set 0xff 3.[96...99]{CRC32 for [12...95]} 4.[112...115]{CRC32 for [104...111]} 5.[132...163]{SHA256 for compiled bin with 16byte aligned} 6.[172...175]{CRC32 for [0...171]}
As for dts/dtb, it's standard.
@YafeiJin Thanks for the quick response!
I found that in the configKeys, chip_erase_time is 16 bits length. But in efuse_bootheader_cfg.conf, it's overflowed to 200000 . Is there any mistakes?
I think my blflash is working now. Tested with https://github.com/bouffalolab/BLOpenFlasher/blob/main/bl602/bl602.bin
cargo run flash -p COM5 D:\bl602.bin -f
Finished dev [unoptimized + debuginfo] target(s) in 0.13s
Running `target\debug\blflash.exe flash -p COM5 D:\bl602.bin -f`
[2020-12-04T15:52:13Z INFO blflash::flasher] Start connection...
[2020-12-04T15:52:13Z TRACE blflash::flasher] 5ms send count 55
[2020-12-04T15:52:13Z TRACE blflash::flasher] handshake sent elapsed 243.7µs
[2020-12-04T15:52:13Z INFO blflash::flasher] Connection Succeed
[2020-12-04T15:52:13Z INFO blflash] Bootrom version: 1
[2020-12-04T15:52:13Z TRACE blflash] Boot info: BootInfo { bootrom_version: 1, otp_info: [0, 0, 0, 0, 3, 0, 0, 0, 84, 9a, 2, 42, e8, b4, 1f, 0] }
[2020-12-04T15:52:13Z INFO blflash::flasher] Sending eflash_loader...
[2020-12-04T15:52:16Z INFO blflash::flasher] Finished 2.6961671s 10.60KB/s
[2020-12-04T15:52:16Z TRACE blflash::flasher] 5ms send count 1000
[2020-12-04T15:52:16Z TRACE blflash::flasher] handshake sent elapsed 6.5683ms
[2020-12-04T15:52:16Z INFO blflash::flasher] Erase flash addr: 0 size: 47504
[2020-12-04T15:52:17Z INFO blflash::flasher] Program flash... 5c1171f14166fd0df84e0f2686366535e1360f704200163b79e4c812ef1afb95
[2020-12-04T15:52:17Z INFO blflash::flasher] Program done 501.1308ms 92.60KB/s
[2020-12-04T15:52:17Z INFO blflash::flasher] Erase flash addr: e000 size: 272
[2020-12-04T15:52:17Z INFO blflash::flasher] Program flash... da4d2fe7d42a71246b0e84d64665b70ad701435f89716c48e6f23ef55340eaa0
[2020-12-04T15:52:17Z INFO blflash::flasher] Program done 5.0379ms 53.12KB/s
[2020-12-04T15:52:17Z INFO blflash::flasher] Erase flash addr: f000 size: 272
[2020-12-04T15:52:17Z INFO blflash::flasher] Program flash... da4d2fe7d42a71246b0e84d64665b70ad701435f89716c48e6f23ef55340eaa0
[2020-12-04T15:52:17Z INFO blflash::flasher] Program done 4.9033ms 66.41KB/s
[2020-12-04T15:52:17Z INFO blflash::flasher] Erase flash addr: 10000 size: 869328
[2020-12-04T15:52:21Z INFO blflash::flasher] Program flash... 84aa5e74beeaf3f70573e52aec6524a1552456a0d906ad534a5525406b2b0f71
[2020-12-04T15:52:30Z INFO blflash::flasher] Program done 9.6430788s 88.04KB/s
[2020-12-04T15:52:30Z INFO blflash::flasher] Erase flash addr: 1f8000 size: 5671
[2020-12-04T15:52:30Z INFO blflash::flasher] Program flash... ae42d69b09c2eb134b202b412c00ff175e10b625e2d3c0a2820378bd341926b8
[2020-12-04T15:52:30Z INFO blflash::flasher] Program done 60.8145ms 92.30KB/s
[2020-12-04T15:52:31Z INFO blflash] Success
Starting bl602 now....
Booting BL602 Chip...
██████╗ ██╗ ██████╗ ██████╗ ██████╗
██╔══██╗██║ ██╔════╝ ██╔═████╗╚════██╗
██████╔╝██║ ███████╗ ██║██╔██║ █████╔╝
██╔══██╗██║ ██╔═══██╗████╔╝██║██╔═══╝
██████╔╝███████╗╚██████╔╝╚██████╔╝███████╗
╚═════╝ ╚══════╝ ╚═════╝ ╚═════╝ ╚══════╝
------------------------------------------------------------
RISC-V Core Feature:RV32-ACFIMX
Build Version: Fix_wifi_scan_too_long-2-gdf8defc2-dirty
Build Version: Fix_wifi_scan_too_long-2-gdf8defc2-dirty
PHY Version: a0_final-45-g5ee0659
RF Version: f76e39a
Build Date: Nov 13 2020
Build Time: 17:27:44
------------------------------------------------------------
Heap 94853@0x4202857b, 2144@0x420497a0
@spacemeowx2 It's really cool. Thanks. It will be helpful. I will learn rust from your project ;)