From help at tuyizere.org Thu Feb 1 18:13:47 2018 From: help at tuyizere.org (gnuforever) Date: Thu, 01 Feb 2018 17:13:47 +0000 Subject: FST-01G distribution channel In-Reply-To: <87tvv4b3uq.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of "Tue, 30 Jan 2018 09:13:49 +0900") References: <87k1w1eeqw.fsf@tuyizere.org> <871si9kwn1.fsf@tuyizere.org> <874ln5ds4s.fsf@fsij.org> <87shaobquw.fsf@tuyizere.org> <87tvv4b3uq.fsf@iwagami.gniibe.org> Message-ID: <87vafgy6no.fsf@tuyizere.org> NIIBE Yutaka writes: > Unfortunately, I developed BBG-SWD based on the snapshot of OpenOCD. > Perhaps, I will port it to newer OpenOCD and let run it on PocketBeagle, > when I will have next opportunity of manufacturing. Do you accept donation? I would like to contribute. Thank you for your great work! From tomli at tomli.me Sun Feb 4 20:27:51 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Mon, 5 Feb 2018 03:27:51 +0800 Subject: The VID/PID Problem of Gnuk Devices Message-ID: <20180204192751.GA8095@x220> Hello, (TL;DR: start reading from the 5th-paragraph of the mail.) I'm a core member from Beijing GNU/Linux User Group - an informal association for advocating free and open source software and the use of cryptography to protect users' freedom, security and privacy. Recently, we are working on a project to assemble a small quatity (around 10 pieces) of homemade FST-01 compatible hardware tokens. We intended to distribute this token as a gift for our members, contributors and friends. We also planned to sell these tokens with preloaded Gnuk firmware (again, in small quatities), for several reasons. First, since SeeedStudio no longer sells the original FST-01 tokens, for local users who need them, getting it from a local Linux User Group is much more convenient than ordering it from any remote vendors. Second, it can be a good opportunity to promoto the use of free software and cryptography. Third, it would also allow us to recover a portion of the fabrication costs to ensure the balance of our limited budgets. Finally, we also hope the act of making, using and distributing self-assembled Gnuk tokens would encourage the decentralization of the supply of cryptographic devices. I've already created our custom PCBs for these FST-01 tokens, the PCB is a direct copy of the FST-01G design, with our logo and version number. We've attributed Flying Stone Technology as the original designer, as required by CC-BY-SA 3.0. The only problem left is the VID/PID problem. We could distribute these Gnuk tokens with our own VID/PID, but PC-SC and GnuPG would not recongize these tokens as smartcard readers or OpenPGP Cards. We'll have to submit patches to the upstream projects to include our IDs and wait for the next release schedule. Meanwhile, all users would also have to upgrade their local systems to use the latest software packages, otherwise the Gnuk token will be an unknown and unusable device on their systems. This has severely limited the usefulness of these tokens, for example, most people cannot use it since their systems don't recongize it out-of-box, it will be a even bigger problems on specialized GNU/Linux distros, such as a Tails LiveCD - the user may not have the chance to upgrade at all. In conclusion, I have three questions, first, how to patch GnuPG and PC-SC to make them recongize it as a card reader with customized VID/PID? And what is the easiest way to solve the interoperability problem? I've read that FSIJ may accept 3rd-party to use the FSIJ's VID as an authorized "second-source manufacturer", is it possible for us to apply? Also, if we decided to use our own VID/PID in the end, is there a way to avoid this nasty interoperability problem on existing systems? Sincerely, Tom Li Beijing GNU/Linux User Group -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From gniibe at fsij.org Tue Feb 6 02:09:44 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 06 Feb 2018 10:09:44 +0900 Subject: GD32F103 Message-ID: <87607a6i07.fsf@iwagami.gniibe.org> Hello, At FOSDEM, from a friend, I learned this chip: GD32F103 http://gd32mcu.21ic.com/en/index It looks interesting. It is composed by two dies; A die of serial Flash ROM, and a die of MCU core. Apparently, the flash ROM content is encrypted, but the method is unknown (for me). At least, the encryption can not be controlled by a programmer who writes the firmware. The ad says it uses "patented" technology for the encryption, so, some information might be available, possibly in Chinese. I wonder if it is more difficult than STM32F103 against opening-the-chip attack. Well, it can run faster (up to 108MHz) and power consumption is lower. These benefits themselves are worth to try. And it's good if we have an alternative. I would try this chip, if I will have an opportunity. It seems that 36-pin QFN version is not yet available at aliexpress. -- From gniibe at fsij.org Tue Feb 6 02:45:10 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 06 Feb 2018 10:45:10 +0900 Subject: The VID/PID Problem of Gnuk Devices In-Reply-To: <20180204192751.GA8095@x220> References: <20180204192751.GA8095@x220> Message-ID: <87372e6gd5.fsf@iwagami.gniibe.org> Hello, > Recently, we are working on a project to assemble a small quatity (around > 10 pieces) of homemade FST-01 compatible hardware tokens. We intended > to distribute this token as a gift for our members, contributors and > friends. > > We also planned to sell these tokens with preloaded Gnuk firmware > (again, in small quatities), for several reasons. First, since SeeedStudio > no longer sells the original FST-01 tokens, for local users who need > them, getting it from a local Linux User Group is much more convenient > than ordering it from any remote vendors. Second, it can be a good > opportunity to promoto the use of free software and cryptography. Third, > it would also allow us to recover a portion of the fabrication costs > to ensure the balance of our limited budgets. Finally, we also hope the > act of making, using and distributing self-assembled Gnuk tokens would > encourage the decentralization of the supply of cryptographic devices. Great. That's exactly what wanted to do many times, at many times. But I was unable to achieve that goal by myself. I only had a Gnuk workshop (with five people or so) in Japan. Currently, the distribution channel is only FSF shop and me in person. I am pleased that you are going to do. > In conclusion, I have three questions, first, how to patch GnuPG and > PC-SC to make them recongize it as a card reader with customized VID/PID? As upstream GnuPG developer, I think that no changes are required for GnuPG scdaemon itself, for a token with customized VID:PID. All that we need is configuration for accessing the hardware, in a distribution; For example, in Debian, we have an entry for Gnuk Token (of FSIJ): https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/tree/debian/scdaemon.udev For PC/SC, you can send the information to upstream: http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant But, IIRC, it is not mandatory condition to use PC/SC reader. Please note that for GNU/Linux machines, PC/SC is not required, we can just use in-stock CCID driver of GnuPG which accesses directly using libusb. Please try some experiments with customized VID:PID. Well, I'm afraid... some changes are needed for scripts in Gnuk. VID:PID is hard-coded at some places. And the VID:PID is assumed in some examples in documents. > And what is the easiest way to solve the interoperability problem? For Gnuk Token with customized VID:PID, while Nitrokey had an experience, I suppose, we don't know the detail. So, I think that you need to pursue by yourself. Sure, we will help. > I've read that FSIJ may accept 3rd-party to use the FSIJ's VID as > an authorized "second-source manufacturer", is it possible for us to > apply? Yes. I'll ask to members if it will be acceptable. > Also, if we decided to use our own VID/PID in the end, is there a way > to avoid this nasty interoperability problem on existing systems? While I haven't identified the problems, it's not that hard, if any. -- From tomli at tomli.me Tue Feb 6 20:12:37 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Wed, 7 Feb 2018 03:12:37 +0800 Subject: GD32F103 In-Reply-To: <87607a6i07.fsf@iwagami.gniibe.org> References: <87607a6i07.fsf@iwagami.gniibe.org> Message-ID: <20180206191237.GA2872@x220> > At FOSDEM, from a friend, I learned this chip: GD32F103 > It looks interesting. Thanks for the information. Since I'm working on my FST-01-compatible prototype, and just wondering whether there's an "improved" version of this chip available for experiments. This is exactly what I need. I never realized the existence of this chip! > Well, it can run faster (up to 108MHz) and power consumption is lower. > These benefits themselves are worth to try. And it's good if we have an > alternative Even better, the price of the chip is also lower than its STM32F103 counterpart. In addition, GD32F103 has better ESD-ratings: 4 kV (HBM), while STM32F103 can only withstand 2 kV, it can increase the chance of survival of our Gnuk in case of an accident (I've accidentally destroyed two official FST-01s while trying to reprogram it, ESD is the only possible explanation came to my mind, so I learned how to properly ground myself and my workbench as a result, not too bad...) > It is composed by two dies; A die of serial Flash ROM, and a die of MCU > core. Apparently, the flash ROM content is encrypted, but the method is > unknown (for me). GigaDevice is knownly for its flash chips so they also incorporated their flash chips inside the MCU, unsurprisingly. Here are photographs of the chip's die: https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices > The ad says it uses "patented" technology for the encryption, so, some information > might be available, possibly in Chinese. I wonder if it is more difficult than > STM32F103 against opening-the-chip attack. I searched in Chinese, and found the information is limited. If my understanding is correct, in addition to the standard readout protection, GD32F103 implemented an algorithm to distribute and map the data on continuous logical addresses to discontinuous physical address on the flash hardware. Physical attackers need to rearrange the data to correct orders, so yes, it can probably increase costs of attacks. > At least, the encryption can not be controlled by a programmer who writes > the firmware. Just like the readout protection, these security features are transparent to developers, it's good to have them, but we as developers should implement proper encryption inside the firmware (like the AES encryption in Gnuk) instead not relying on these hardware features. We'll be okay. I wonder if we can use a security coprocessor to make an attack more difficult, without really relying on the security coprocessor. For example, if we add a SHA coprocessor, we can ask the coprocessor to do an extra 1000-round SHA-HMAC iteration from the key derived by Gnuk with a random salt. In this way, even if the coprocessor is backdoored and doesn't do anything, Gnuk is still the bottom line of our security. Users' computing freedom and hackability are also unaffected, since they are the ultimate controller of the security coprocessor. It's difficult to find a "secure" MCU without NDA, but it looks like they are lots of simple TPMs avaliable for the mass market. What is your opinion? > I would try this chip, if I will have an opportunity. It seems that > 36-pin QFN version is not yet available at aliexpress. I just placed an order for this chip, and I'm going to try the chip as soon as I receive them. Perhaps I can send a few pieces to Japan via FedEx? I also found some Chinese application notes for porting the program, and some posts on the Internet that document some traps of the chip, I'd like to translate them to English if it is useful for Gnuk development. Finally, I remembered seeing a post about a possible future design of the FST-01 board, including drawing the USB traces on the PCB instead of using a external connector, and the possible shift to newer chips, but I cannot find the mail anymore. Can you send me a link? Happy Hacking, Tom Li -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From gniibe at fsij.org Wed Feb 7 00:01:56 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 07 Feb 2018 08:01:56 +0900 Subject: GD32F103 In-Reply-To: <20180206191237.GA2872@x220> References: <87607a6i07.fsf@iwagami.gniibe.org> <20180206191237.GA2872@x220> Message-ID: <87zi4len8b.fsf@fsij.org> Hello, Thanks for information for GD32F103. Let's see. tomli at tomli.me writes: > I wonder if we can use a security coprocessor to make an attack more > difficult, without really relying on the security coprocessor. In general, I don't want such a feature in device side. It could be a honey-pot. Or, it tends to be immature like ROCA problem. To achieve same, it's far better done in host side. In OpenPGP card V3 specification, I proposed KDF Data Object, so that host side can do more iteration: https://dev.gnupg.org/T3152 In recent Gnuk, it is already implemented. Host side implementation is ready in GnuPG, just waiting next release. https://dev.gnupg.org/T3201 > Finally, I remembered seeing a post about a possible future design of > the FST-01 board, including drawing the USB traces on the PCB instead > of using a external connector, and the possible shift to newer chips, > but I cannot find the mail anymore. Can you send me a link? Do you mean this? https://www.gniibe.org/memo/development/fs-bb48/fs-bb48-idea.html I made prototype. It found that the multiplier is too slow in Cortex-M0+. It would be OK for ECC though. For FS-BB48, I designed 3D part: https://git.gniibe.org/gitweb/?p=gnuk/fs-geta083.git In 2016, I was unable to find better way to manufacture something like FS-GETA083. At that time, using standard USB-A plug is more cheaper and easier. Thus, in 2016, my conclusion was update to FST-01G. https://www.gniibe.org/memo/development/fst-01/fst-01-revision-g.html -- From tomli at tomli.me Wed Feb 7 12:57:18 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Wed, 7 Feb 2018 19:57:18 +0800 Subject: GD32F103 In-Reply-To: <87zi4len8b.fsf@fsij.org> References: <87607a6i07.fsf@iwagami.gniibe.org> <20180206191237.GA2872@x220> <87zi4len8b.fsf@fsij.org> Message-ID: <20180207115718.GA13025@x220> > > I wonder if we can use a security coprocessor to make an attack more > > difficult, without really relying on the security coprocessor. > > In general, I don't want such a feature in device side. It could be a > honey-pot. Or, it tends to be immature like ROCA problem. Yes, this problem is a serious concern. The idea is to make it fail-safe, in other words, use the security coprocessor without trusting it, double-encrypting the already-encrypted data. If the security coprocessor is a honeypot, the worst-case scenario is merely a denial-of-service attack. Unless the coprocessor is customized to launch a hardware-level exploit to the main processor, e.g. doing a power-analysis in real time when the main chip is being used, and saving the results inside the chip for attacks to gain physical access later. These security coprocessors are mainly design to prevent low-cost opening-the-chip attacks by the competitors to copy their programs on mass-market products, rather than cryptography applications. It looks like there are some, don't even require an NSA^H^H^H NDA. These coprocessors may be ineffective, but I don't think they are capable to do these types of malicious attacks. So I don't think there is a problem on security, but in my opinion, the bigger problem is the lack of free software toolchains (no idea about their toolchains) for these coprocessors, but it seems easy to port existing tools since they are using the same common commodity "IP" cores like 8051. Debugging might be another problem. You may not prefer these popentially-questionable chips, but for me I think it's worth to investigate the good, the bad, and the ugly about them. I have a few candidates and I'm going to report everything I have discovered. > To achieve same, it's far better done in host side. In OpenPGP card V3 > specification, I proposed KDF Data Object, so that host side can do more > iteration: > > https://dev.gnupg.org/T3152 > > In recent Gnuk, it is already implemented. Host side implementation is > ready in GnuPG, just waiting next release. https://dev.gnupg.org/T3201 Well done, this is exactly what we need. It's going to dramatically increase our last-line resistance of brute-force attacks after the chip is opened. > Do you mean this? > > https://www.gniibe.org/memo/development/fs-bb48/fs-bb48-idea.html > > I made prototype. It found that the multiplier is too slow in > Cortex-M0+. It would be OK for ECC though. > > For FS-BB48, I designed 3D part: > > https://git.gniibe.org/gitweb/?p=gnuk/fs-geta083.git > > In 2016, I was unable to find better way to manufacture something like > FS-GETA083. At that time, using standard USB-A plug is more cheaper and > easier. > > Thus, in 2016, my conclusion was update to FST-01G. > > https://www.gniibe.org/memo/development/fst-01/fst-01-revision-g.html Bookmarked. Happy Hacking, Tom Li -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From gniibe at fsij.org Fri Feb 9 01:26:12 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 09 Feb 2018 09:26:12 +0900 Subject: GD32F103 In-Reply-To: <20180206191237.GA2872@x220> References: <87607a6i07.fsf@iwagami.gniibe.org> <20180206191237.GA2872@x220> Message-ID: <87y3k3atzv.fsf@fsij.org> tomli at tomli.me wrote: > In addition, GD32F103 has better ESD-ratings: 4 kV (HBM), > while STM32F103 can only withstand 2 kV, it can increase the chance of > survival of our Gnuk in case of an accident (I've accidentally destroyed > two official FST-01s while trying to reprogram it, ESD is the only possible > explanation came to my mind, so I learned how to properly ground myself > and my workbench as a result, not too bad...) You mean ESD-rating of the chip itself. Well, I'd imagine ESD spark in Beijing in winter. :-) For ESD protection from lines, I put a chip. I think it works, if it's from lines. I don't put much efforts against ESD for the PCB design itself, but I believe that most important factor is the strength of the chip itself. If any suggestions, it's welcome. -- From tomli at tomli.me Sat Feb 10 19:27:17 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Sun, 11 Feb 2018 02:27:17 +0800 Subject: Status Update: HW Mysteriously Stopped Working. Development Suspended. Message-ID: <20180210182717.GA146560@x220> Hi. I've received 5 pieces of GD32F103 for testing yesterday! However, I tried to program the new board with a ST-Link-v2-compatible clone, but it didn't work. Then I tried to program a knownly-working FST-01 board, but found it still refused to work, despite the fact that the board was just programmed by this programmer one day ago and working as a Gnuk token on the computer. OpenOCD kept showing the wrong (low) target voltage. I thought it was a wiring program, and tried to hook up the wires again, and suddenly, the magic smoke came out from STM32F103 chip, unbelievable, the power supply never exceeded 3 volts (and it was how I destroyed the other two FST-01s in previous years, that I've mentioned in the mail earlier, the culprit was not ESD but some hidden trap in my broken ST-Link clone?) Today, I tried to use my Raspberry Pi as a SWD programmer by bitbanging, OpenOCD was also to detect the presence of the device, but trapped into a infinite loop of SWD handshaking as soon as SWD was detected. I don't know if it's related to Gnuk. But I found that for cheap ST-Link clones, it is problematic to issue RESET commands under some circumstances, like sleep mode. Tom Li -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From f at 0x52.eu Sat Feb 10 22:46:41 2018 From: f at 0x52.eu (Fox) Date: Sat, 10 Feb 2018 22:46:41 +0100 Subject: Can't flash STM32F101 Message-ID: I have a St-link v2 STM32F101 from aliexpress (clone), and Im trying to flash it with another one. When I run tools/stlinkv2.py I get: ST-Link/V2 version info: 2 17 4 Change ST-Link/V2 mode 0002 -> 0001 Core does not halt, try API V2 halt. ValueError('Status of core is not halt.', 128) What am I doing wrong? -f0x From gniibe at fsij.org Tue Feb 13 04:18:42 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 13 Feb 2018 12:18:42 +0900 Subject: Can't flash STM32F101 In-Reply-To: References: Message-ID: <87r2ppy3u5.fsf@iwagami.gniibe.org> Fox wrote: > I have a St-link v2 STM32F101 from aliexpress (clone), and Im trying to > flash it with another one. > When I run tools/stlinkv2.py I get: > ST-Link/V2 version info: 2 17 4 > Change ST-Link/V2 mode 0002 -> 0001 > Core does not halt, try API V2 halt. > ValueError('Status of core is not halt.', 128) tools/stlinkv2.py would not be good. You can try OpenOCD with options like: -f interface/stlink-v2.cfg -f target/stm32f1x.cfg Or, if the firmware supports sleep mode, you need to connect nRST pin. There are many variants of ST-Link/V2 clone, and some doesn't support nRST pin. Please describe which variant you have. -- From mike at sowbug.com Thu Feb 22 18:39:45 2018 From: mike at sowbug.com (Mike Tsao) Date: Thu, 22 Feb 2018 17:39:45 +0000 Subject: Can't flash STM32F101 In-Reply-To: References: Message-ID: This guide is very helpful: https://nx3d.org/gnuk-st-link-v2/ In particular, pay attention to the photo at the bottom showing how to trigger the reset functionality. I was having trouble getting the reset timing right, so I did something like this: $ for i in `seq 1 500`; do stlink reset; stlink erase; stlink write [bin filename] 0x08000000; done which gave me enough time to hold the CLK/IO jumpers in place with one hand and then drag another jumper across pins 7 and 8 on the STM32 chip to reset it. Note that I was using https://github.com/texane/stlink/ with the C8T6HACK modification at https://github.com/cabo/stlink. The arguments in the bash command above are by memory and are likely incorrect, but you get the idea: wrap a reset/erase/write sequence in a big loop. Finally, note that there are at least three different manufacturers of ST-Link v2 clones, and for some unknown reason they do not all use the same pinout for the four terminal points. You will need a continuity tester to establish the function of the four points, or if you are reckless, you can use trial and error and hope you figure it out without shorting out a component. For one of mine, the power terminals were the outer two points, and SWDIO was the middle one closer to the USB plug, and SWCLK was the other one in the middle. On Sat, Feb 10, 2018 at 3:48 PM Fox wrote: > I have a St-link v2 STM32F101 from aliexpress (clone), and Im trying to > flash it with another one. > When I run tools/stlinkv2.py I get: > ST-Link/V2 version info: 2 17 4 > Change ST-Link/V2 mode 0002 -> 0001 > Core does not halt, try API V2 halt. > ValueError('Status of core is not halt.', 128) > > What am I doing wrong? > > -f0x > > > _______________________________________________ > Gnuk-users mailing list > Gnuk-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnuk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomli at tomli.me Sat Feb 24 11:18:20 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Sat, 24 Feb 2018 18:18:20 +0800 Subject: Status Update: Initial Experiments with the GD32 chip Message-ID: <20180224101820.GA63080@x220> Hello Niibe. I got a new working ST-Link programmer and did some experiments on this GD32 chip in this week. But the USB was not working, presumably due to timings and clock differences between the two chips. I'm going to purchase an official development board to help with my continued experiments, otherwise it's difficult to trace the program dlown. Here's my progress: 1. Because the property of the underlying flash technology by GigaDevice, the first 32 KiB of the flash is zero-wait for reading, but the writing and erasing of the chip is significantly much more longer than STM32, as a result, the programming software needs some modifications. The official application notes recommends: i) increase the erase timeout per page to 300ms, increase the mass erase timeout to 3s. ii) increase the program time per word to 2ms, increase the program time per page to 300ms. In addition, the access time for data behind of first 32 KiB is slow, one should put timing-crtitial data at the beginning of the flash chip. Gnuk also needs to adjust the timeout values for erasing and writing to the flash. 2. The GigaDevice flash doesn't support "block write" mode, which is the default mode to program the flash on OpenOCD, further, OpenOCD will fall back to single halfword (16-bit) accesses when block write is not available, however, it's also doesn't work on this flash. The only known working mode on this chip is the 32-bit fullword access. I've implemented a patch to hack OpenOCD quickly and dirtily and make it work with GD32, but it will break STM32 chips, the longterm solution is adding additional code and merge it to the upstream. 3. GD32 implemented extra readout protection modes, custom instructions is needed to remove the protections for programming and testing. The protections are observed to switch on automatically after __every power cycle__. I believe it's a proactive protection againist physical tampering. 4. Because it only has a USB prescaler of 1, 1.5, 2 and 2.5, it is not possible to get the 48 MHz USB clock on the standard maximum frequence, 105 MHz. The maximum frequency with a working USB is 96 MHz, or a overclocked, out-of-spec 120 MHz. Nevertheless, 96 MHz is still a huge improvement. 5. Even on the same frequency, the application notes claimed some instructions may run faster than its STM32 counterpart. According to the application notes, void delay(void) { uint8_t i; for(i = 0; i < 75; i++); } 7.4 us on STM32, 5.4 us on GD32. By the way, the HSE clock needs a longer time to start and settle, but it's irrelevant to Gnuk since chopstx uses a infinite loop to wait for HSE. 6. I still have problem with USB enumeration and the chip cannot be recognized by the computer. Sometimes the USB CDC demo in chopstx works, sometimes it doesn't, Gnuk simply hangs. This is probably a problem caused by the differences of the clocks and timings of the two chips, perhaps a software thing, perhaps a hardware thing. I'm going to order and wait for the official development board and uses it as the reference platform for further testing, otherwise it's going to be clueless. I think I'd better not to send my chips to you for now, or it will be very confusing and frustrating with the chip. Meanwhile, you could see if there are avaliable development board for sale on AliExpress, once the program runs flawlessly on the development board, I can send a bunch of the QFN chips to you for the new FST-01. 7. The hacky patch is attached at the bottom of this email. After applying the patch, to program a GD32 chip, one needs the following: # Disable Readout Protection openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c 'reset halt' \ -c 'mdb 0x1ffff800 12' -c 'sleep 100' \ -c 'mww 0x40022004 0x45670123' -c 'sleep 100' \ -c 'mww 0x40022004 0xcdef89ab' -c 'sleep 100' \ -c 'mww 0x40022008 0x45670123' -c 'sleep 100' \ -c 'mww 0x40022008 0xcdef89ab' -c 'sleep 100' \ -c 'mww 0x40022010 0x00000260' -c 'sleep 100' \ -c 'mww 0x40022010 0x00000210' -c 'sleep 100' \ -c 'mwh 0x1ffff800 0x5aa5' -c 'sleep 100' \ -c 'shutdown' # Disable Page Write Protection # TODO: What is this exactly? What code is needed to change for Gnuk? openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c 'reset halt' \ -c 'mdb 0x1ffff800 12' -c 'sleep 100' \ -c 'mww 0x40022004 0x45670123' -c 'sleep 100' \ -c 'mww 0x40022004 0xcdef89ab' -c 'sleep 100' \ -c 'mww 0x40022008 0x45670123' -c 'sleep 100' \ -c 'mww 0x40022008 0xcdef89ab' -c 'sleep 100' \ -c 'mww 0x40022010 0x00000210' -c 'sleep 100' \ -c 'mwh 0x1ffff802 0xff00' -c 'sleep 100' \ -c 'mwh 0x1ffff804 0xff00' -c 'sleep 100' \ -c 'mwh 0x1ffff806 0xff00' -c 'sleep 100' \ -c 'mwh 0x1ffff808 0x00ff' -c 'sleep 100' \ -c 'mwh 0x1ffff80a 0x00ff' -c 'sleep 100' \ -c 'mww 0x40022010 0x00000080' -c 'sleep 100' \ -c 'mdb 0x1ffff800 12' -c 'mdw 0x4002201c 1' \ -c 'shutdown' # Mass Erase openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c 'reset halt' \ -c 'flash erase_sector 0 0 31' \ -c 'shutdown' # Program a .bin to 0x08000000, ELF should be okay too openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c 'reset halt' \ -c 'flash write_image gnuk-vidpid.bin 0x8000000 bin' -c 'shutdown' Using other commands such as "mass_erase" or "program" may not work, because of the differences mentioned above. Happy Hacking, Tom Li --- diff -uprN openocd-0.10.0/src/flash/nor/stm32f1x.c openocd-0.10.0.hack/src/flash/nor/stm32f1x.c --- openocd-0.10.0/src/flash/nor/stm32f1x.c 2016-12-25 22:12:54.000000000 +0800 +++ openocd-0.10.0/src/flash/nor/stm32f1x.c 2018-02-19 07:26:57.097567934 +0800 @@ -102,8 +102,8 @@ /* timeout values */ -#define FLASH_WRITE_TIMEOUT 10 -#define FLASH_ERASE_TIMEOUT 100 +#define FLASH_WRITE_TIMEOUT 255 +#define FLASH_ERASE_TIMEOUT 255 struct stm32x_options { uint16_t RDP; @@ -163,7 +163,7 @@ static inline int stm32x_get_flash_statu return target_read_u32(target, stm32x_get_flash_reg(bank, STM32_FLASH_SR), status); } -static int stm32x_wait_status_busy(struct flash_bank *bank, int timeout) +static int stm32x_wait_status_busy(struct flash_bank *bank, unsigned int timeout) { struct target *target = bank->target; uint32_t status; @@ -736,30 +736,21 @@ static int stm32x_write(struct flash_ban if (retval != ERROR_OK) goto cleanup; - /* try using a block write */ - retval = stm32x_write_block(bank, buffer, offset, words_remaining); + while (words_remaining > 0) { + uint32_t value; + memcpy(&value, buffer, sizeof(uint32_t)); - if (retval == ERROR_TARGET_RESOURCE_NOT_AVAILABLE) { - /* if block write failed (no sufficient working area), - * we use normal (slow) single halfword accesses */ - LOG_WARNING("couldn't use block writes, falling back to single memory accesses"); - - while (words_remaining > 0) { - uint16_t value; - memcpy(&value, buffer, sizeof(uint16_t)); - - retval = target_write_u16(target, bank->base + offset, value); - if (retval != ERROR_OK) - goto reset_pg_and_lock; - - retval = stm32x_wait_status_busy(bank, 5); - if (retval != ERROR_OK) - goto reset_pg_and_lock; - - words_remaining--; - buffer += 2; - offset += 2; - } + retval = target_write_u32(target, bank->base + offset, value); + if (retval != ERROR_OK) + goto reset_pg_and_lock; + + retval = stm32x_wait_status_busy(bank, FLASH_ERASE_TIMEOUT); + if (retval != ERROR_OK) + goto reset_pg_and_lock; + + words_remaining -= 2; + buffer += 4; + offset += 4; } reset_pg_and_lock: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: