From gniibe at fsij.org  Thu Mar  1 02:58:51 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 01 Mar 2018 10:58:51 +0900
Subject: Status Update: Initial Experiments with the GD32 chip
In-Reply-To: <20180224101820.GA63080@x220>
References: <20180224101820.GA63080@x220>
Message-ID: <878tbcblpg.fsf@iwagami.gniibe.org>

tomli at tomli.me wrote:
> I got a new working ST-Link programmer and did some experiments on this GD32
> chip in this week.

Thanks a lot for sharing your experience.  It is quite interesting.

Could you please confirm two things.

  (1) Zero-wait state access to flash
  (2) 16-bit halfword access in flash programming

According to my reading of the GD32F103x User Manual, both are
supported (in the section 2. Flash memory controller).

> 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.

While this is acceptable...

> 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.

... This would be not.  I thought as if internal SRAM copies full of
128KiB.  I wonder how slow it is.. and/or if it is OK (in China)
advertising the chip as "zero-wait access" when it's only partially
(quarter) true.

If it's only for the first 32KiB, I would not like to use this chip...

Zero-wait is important for killing an attack vector of possible timing
attack.

> 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.

Currently, the use of data in flash by Gnuk (the data format) depends on
halfword size access.

We will need major change if 16-bit access is not supported.

> 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.

It sounds like it's an issue (or two) of USB driver.  I mean, software.

> 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.

OK.  Let's see.

Today, I find this one:

   https://www.tindie.com/products/maxtch/sushibits-arm-development-kits/

It seems it's from Shanghai.  I'll try to find other.
-- 


From alex at nitrokey.com  Mon Mar  5 10:26:16 2018
From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey)
Date: Mon, 5 Mar 2018 10:26:16 +0100
Subject: Gnuk version 1.2.8 considered stable for production use?
Message-ID: <42c2a815-c3c3-49f5-26bd-a9740571f3cd@nitrokey.com>

Hi NIIBE,

would you recommend to make use of the newest version of Gnuk (1.2.8) in
production (after some testing of course). As you did some vital changes
due to the admin-less factory-reset we would be interested in using it
for our Nitrokey Start...

Kind regards
Alex



From gniibe at fsij.org  Tue Mar  6 07:31:00 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 06 Mar 2018 15:31:00 +0900
Subject: Gnuk version 1.2.8 considered stable for production use?
In-Reply-To: <42c2a815-c3c3-49f5-26bd-a9740571f3cd@nitrokey.com>
References: <42c2a815-c3c3-49f5-26bd-a9740571f3cd@nitrokey.com>
Message-ID: <87k1upemvv.fsf@iwagami.gniibe.org>

Alexander Paetzelt | Nitrokey <alex at nitrokey.com> wrote:
> would you recommend to make use of the newest version of Gnuk (1.2.8) in
> production (after some testing of course).

I sold FST-01G with Gnuk 1.2.8 at FOSDEM.  So, it is relatively better
release, I suppose.

After the release, I found a bug of KDF DO object access.  It's better
to be applied.

For next step, I'm currently considering about possible format change of
counters (signature counter, PIN error counter), data objects, and
private keys.  Typical use case is that only information of counters is
updated, data objects and keys are only written at personalization time.
Current code highly depends on the MCU; That is, NOR flash of 16-bit
word-size, which allows update by writing zero.
-- 


From gniibe at fsij.org  Tue Mar 13 06:13:38 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 13 Mar 2018 14:13:38 +0900
Subject: Gnuk version 1.2.8 considered stable for production use?
In-Reply-To: <87k1upemvv.fsf@iwagami.gniibe.org>
References: <42c2a815-c3c3-49f5-26bd-a9740571f3cd@nitrokey.com>
 <87k1upemvv.fsf@iwagami.gniibe.org>
Message-ID: <874llk5zi5.fsf@iwagami.gniibe.org>

Today, I found a bug of factory-reset.  Fix is now pushed.

Please note that you need to update your installation procedure;
Typing "make" only builds build/gnuk.elf (and others).  You need to
invoke "make build/gnuk-vidpid.elf" to get the image with VID:PID.
And it is gnuk-vidpid.bin to be flashed.
--