[Gnuk-users] Improving the reproducibility and transparency

[NIIBE Yutaka]

Hello,

While they/we are going to celebrate Chinese New Year, I got
FRMD-KL43Z today.

I'm currently considering the reproducibility and transparency for
Gnuk Token and NeuG TRNG device.

You see, I have been learning in the development, with feedback from
users.

It was pointed out that I haven't released the test plan to
manufacture FST-01.  I was careless or had not considered deeply at
that time.  I don't have the document of the test plan in the form I
can publish.

Now, I understand it is important.

I would have excuses: It would not be included as a requirement for
the reproducibility of device, because it could be still reproducible
without that.  A test plan would depend on a specific manufacturer,
and its usefulness would be questionable in some cases...

Those are excuses.

Thus, in 2014, when I asked manufacturing of FSM-55 (the LED matrix
display which shows "GNU's Not Unix!"), I published the release plan
on the web beforehand:

    http://www.gniibe.org/memo/development/fsm-55/fsm-55-testplan.html

I will do same, for FS-BB48.  I will do same when I will have another
opportunity to manufacture a revision of FST-01 again.

And this week, I was impressed when I found my orders of Fusion PCB
became automatically available to public:

	Design 1:
	http://www.seeedstudio.com/service/O1o7w7R9

	Design 2:
	http://www.seeedstudio.com/service/hyJxJl27


Next, it was pointed out it depends on proprietary implementation in
the process.  Specifically, the firmware programming to MCU's flash
is done by ST-Link/V2, as seen in the test plan for FSM-55.

This is an important issue.  When I do that like following the test
plan for FSM-55 (I mean, I use ST-Link/V2 with vendor supplied tool on
a proprietary operating system), It is very difficult or mostly
impossible for me that I assure users that the firmware on the MCU is
really the one I asked.

Last summer, Noodles kindly published an article:


http://www.earth.li/~noodles/blog/2015/08/program-fst01-with-buspirate.html

This is great because it enables us to make sure correctness of the
firmware programming process.

I think that major problem would not be the proprietary firmware of
the programmer, but the dependency of proprietary tool and the
proprietary operating system on host PC.

I'm currently considering something like this; This would be a
practical solution.

     [ host PC, possibly with proprietary operating system ]
                      |
                      | USB or serial connection
                      |   by SSH or terminal tool
                      |
		      V
         [ A board like BBG (Beagle Bone Green) or BBB]
                      |
                      | SWD connection
                      |
		      V
               [ Target board ]


Technically speaking, only a bit-banging is required for programming
flash with SWD.  So, something like Bus Pirate is enough, or even bare
FT232H board (like https://www.adafruit.com/products/2264, or
http://akizukidenshi.com/catalog/g/gK-06503/) could be used with
OpenOCD.

Introducing BBG sounds over kill, but I believe that it makes sense,
or it gives us huge benefit to control things.

When test plans using (something like) BBG will be common among
manufacturers, we will have free software friendly manufacturers,
and it will become easier for us to achieve transparency.

That's my current thoughts.  Thanks to Kaz Kojima for discussion in
person.  Well, I'd need to modify OpenOCD if I want direct connection
from BBG to a target board.  The setup of:

     host PC -> BBG -> Bus Pirate / FT232H -> target board

is still OK (for me), though.
--