From gniibe at fsij.org  Wed May  9 10:47:19 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 09 May 2018 17:47:19 +0900
Subject: USB vendor ID 0000 on Blue Pill
In-Reply-To: <20180409110731.1d2671d5@faultier2go>
References: <20180406182618.2d3ff0d3@faultier2go>
 <CACi+kjpAQscCpo8HTrNWPiPNfg0zdVHQf7BKfviajBQPoRZL7A@mail.gmail.com>
 <20180407174158.2bd49482@faultier2go> <87sh85cegs.fsf@iwagami.gniibe.org>
 <c307c94b-039d-58b9-4dd4-129488a5f627@digitalbrains.com>
 <20180409110731.1d2671d5@faultier2go>
Message-ID: <878t8t1ai0.fsf@fsij.org>

Hello,

Sorry for my late response.  I was in ShenZhen in April and got BluePill
board with GD32F103CB, helped by friends at SZDIY.

Marian Buschsieweke <marian.buschsieweke at ovgu.de> wrote:
> imho the new naming convention suggested by Peter Lebbing is more obvious and
> has the advantage to remain compatible with old HowTos.
>
> Also, I personally believe there is no harm in building building both versions
> by default. This also seems to me the more common case that users want the
> image with vid & pid included, so it would be nice to have this case covered by
> default.

I agree.  Actually, regnual has regnual-no-vidpid.elf.  I will introduce
*-no-vidpid.elf, and make *.elf (or *.bin) have VID:PID.

Today, I did the change for NeuG.  I will do that for Gnuk.
-- 


From gniibe at fsij.org  Wed May  9 10:55:01 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 09 May 2018 17:55:01 +0900
Subject: GD32F103CB
Message-ID: <87603x1a56.fsf@fsij.org>

Hello,

In ShenZhen, I managed to get GD32F103CB.  It's LQFP48 version.  I
changed Chopstx so that it can work with GD32F103CB.  The changes are
clock setting for GD32F103 running 96MHz, and minor update of drivers
(USB driver, ADC driver, and flash protection).

Apparently, the peripherals are different implementations.

And the small change of drivers revealed a USB bug of NeuG/Gnuk, and
initialization problem of Fraucheky.  All fixed.
-- 


From tomli at tomli.me  Thu May 10 16:28:39 2018
From: tomli at tomli.me (tomli at tomli.me)
Date: Thu, 10 May 2018 22:28:39 +0800
Subject: GD32F103CB
In-Reply-To: <87603x1a56.fsf@fsij.org>
References: <87603x1a56.fsf@fsij.org>
Message-ID: <20180510142839.GA221334@x220>

On Wed, May 09, 2018 at 05:55:01PM +0900, NIIBE Yutaka wrote:
> Hello,
> 
> In ShenZhen, I managed to get GD32F103CB.  It's LQFP48 version.  I
> changed Chopstx so that it can work with GD32F103CB.  The changes are
> clock setting for GD32F103 running 96MHz, and minor update of drivers
> (USB driver, ADC driver, and flash protection).
> 
> Apparently, the peripherals are different implementations.
> 
> And the small change of drivers revealed a USB bug of NeuG/Gnuk, and
> initialization problem of Fraucheky.  All fixed.

Thanks for your great work! There is little extra time for me in these
days so I temporaryly stopped the project I mentioned earlier in this
year, but will continue soon. 

I have a dozen of GD32F103TBU6, in QFN-36 package. I'll show up in the
upcoming meetup, hopefully my chips would be helpful for your development.

Happy Hacking,

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: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20180510/56d83ea7/attachment.sig>

From gniibe at fsij.org  Thu May 10 22:41:48 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 11 May 2018 05:41:48 +0900
Subject: GD32F103CB
In-Reply-To: <20180510142839.GA221334@x220>
References: <87603x1a56.fsf@fsij.org> <20180510142839.GA221334@x220>
Message-ID: <878t8rmeer.fsf@fsij.org>

Tom Li <tomli at tomli.me> wrote:
> Thanks for your great work! There is little extra time for me in these
> days so I temporaryly stopped the project I mentioned earlier in this
> year, but will continue soon. 

No problem.  Thanks.  Just like your effort, it took some time for me to
figure out the difference of peripherals (USB, ADC, and Flash ROM), but
it was manageable.

Only a single real problem to be fixed is... a tool like OpenOCD.  To
unlock the protection, GD32F103 requires writing 0x5aa5, but for some
reason, "stm32f1x unlock 0" didn't work for me.  I manually did
following to unlock the device:

    mww 0x40022004 0x45670123
    mww 0x40022004 0xcdef89ab
    mww 0x40022008 0x45670123
    mww 0x40022008 0xcdef89ab
    mdw 0x40022010
    mdh 0x1ffff800 8
    mww 0x40022010 0x0210
    mwh 0x1ffff800 0x5aa5
    mdw 0x4002200c

I will read how OpenOCD does for unlock.  Probably, it's identification
of the device.
-- 


From tomli at tomli.me  Fri May 11 04:31:20 2018
From: tomli at tomli.me (tomli at tomli.me)
Date: Fri, 11 May 2018 10:31:20 +0800
Subject: GD32F103CB
In-Reply-To: <878t8rmeer.fsf@fsij.org>
References: <87603x1a56.fsf@fsij.org> <20180510142839.GA221334@x220>
 <878t8rmeer.fsf@fsij.org>
Message-ID: <20180511023120.GA283756@x220>

On Fri, May 11, 2018 at 05:41:48AM +0900, NIIBE Yutaka wrote:
> Tom Li <tomli at tomli.me> wrote:
> > Thanks for your great work! There is little extra time for me in these
> > days so I temporaryly stopped the project I mentioned earlier in this
> > year, but will continue soon. 

> Only a single real problem to be fixed is... a tool like OpenOCD.  To
> unlock the protection, GD32F103 requires writing 0x5aa5, but for some
> reason, "stm32f1x unlock 0" didn't work for me.  I manually did
> following to unlock the device:
> 
>     mww 0x40022004 0x45670123
>     mww 0x40022004 0xcdef89ab
>     mww 0x40022008 0x45670123
>     mww 0x40022008 0xcdef89ab
>     mdw 0x40022010
>     mdh 0x1ffff800 8
>     mww 0x40022010 0x0210
>     mwh 0x1ffff800 0x5aa5
>     mdw 0x4002200c

I'm not entirely sure, but GD32 has its own additional protection modes,
including Readout Protection and Page Write Protection, which cannot be
deactivated by a standard "stm32f1x unlock 0", also, it seems that the
Readout Protection would be switched on, to an enable state whenever the
power is re-applied, even if it has been disabled previously. I think
it's an anti-tamper feature.

This is why I have reported these quirks to the mailing list by the end of
February, in case someone needs a link:

https://lists.gnupg.org/pipermail/gnuk-users/2018-February/000020.html

IMHO, the real long-term solution is contributing a patch to OpenOCD,
introducing these additional commands for those who are working with
GD32. But it seemed even these hacks I mentioned did not work reliably.

We probably should check the datasheet for confirmation and do some
additional tests.

Happy Hacking

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: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20180511/5f0686e3/attachment.sig>

From gniibe at fsij.org  Fri May 11 23:26:29 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 12 May 2018 06:26:29 +0900
Subject: GD32F103TB (was: GD32F103CB)
In-Reply-To: <20180511023120.GA283756@x220>
References: <87603x1a56.fsf@fsij.org> <20180510142839.GA221334@x220>
 <878t8rmeer.fsf@fsij.org> <20180511023120.GA283756@x220>
Message-ID: <87vabt994q.fsf@fsij.org>

Hello, 

It was nice to meet you.  And thanks for your board with GD32F103TB, and
the chip of GD32F103TB.  Well, I didn't expected you are so young.  :-)

This morning, I successfully built and tested Gnuk 1.2.10 with the
board.

It just requires a change like this:

==========================
--- board-fst-01g.h	2018-01-19 22:12:38.736218579 +0900
+++ board-fst-01r.h	2018-05-12 06:11:11.687258627 +0900
@@ -1,12 +1,16 @@
-#define BOARD_NAME "FST-01G"
-#define BOARD_ID    0x8801277f
-/* echo -n "FST-01G" | sha256sum | sed -e 's/^.*\(........\)  -$/\1/' */
+#define BOARD_NAME "FST-01R"
+#define BOARD_ID    0x8e8266af
+/* echo -n "FST-01R" | sha256sum | sed -e 's/^.*\(........\)  -$/\1/' */
+
+#define MCU_STM32F1_GD32F1 1
+#define STM32_USBPRE                    STM32_USBPRE_DIV2
+#define STM32_ADCPRE                    STM32_ADCPRE_DIV8
 
 #define MCU_STM32F1 1
 #define STM32F10X_MD		/* Medium-density device */
 
 #define STM32_PLLXTPRE                  STM32_PLLXTPRE_DIV1
-#define STM32_PLLMUL_VALUE              6
+#define STM32_PLLMUL_VALUE              8
 #define STM32_HSECLK                    12000000
 
 #define GPIO_LED_BASE   GPIOB_BASE
--