30 Jul
2011
30 Jul
'11
11:30 p.m.
Status update:
On Sun, Jul 24, 2011 at 10:55:54AM +0200, Harald Welte wrote:
However, at91lib does (obviously) not support my
sam7dfu boot loader /
flasher. DFU has been proven an exremely helpful tool for R&D type
projects, where you need quick turn-around times for testing new code
in absence of a JTAG setup. Using the SAM-BA loader is pretty annoying
even after a short time, the constant cycles of usb-plug/unplug, jumper
closing and opeing quickly wears out not only your nerves but even the
usb plug or socket. I know people who have built USB cables with a
power switch in the Vbus line, but even that does only half the trick.
So what I'm now doing is adding linker scripts + startup magic to
at91lib so it can build .bin files that can be downloaded using the
sam7dfu bootloader on the device, and dfu-util on the host PC.
this has now been done, the result is available in
git://git.gnumonks.org/at91work.git
for BOARD=simtrace it will create a *-flash_dfu.bin files, which can be
downloaded into a board running sam7dfu using dfu-util.
What's missing is the DFU configuration descriptors and the 'switch from
application to DFU mode' logic that allows you to flash new application
firmware without having to push the bootloader+reset buttons.
* use the at91lib-provided CCID code to build a
second firmware image
for a 'reader mode', where the PC can use simtrace as smartcard
reader
I've been working on that. However, progress is slow due to various
insufficiencies in the Atmel CCID code. Now I'm getting the first
couple of ATRs out of it using openct on the PC side.
* finally, add a 'softsim' mode, where the PC
can simulate the SIM
card to the phone. I'm not sure what I'll do on the USB protocol
side for this. Chances are high it's again CDC-ACM - but this time
simultaneously with CCID for the reader side, for man-in-the-middle.
Unfortunately the sam7s has only 4 USB end points, I almost forgot about
that. A CCID device already needs all four of them, so we cannot have a
concurrent CDC-ACM device or similar.
The only reasonable way seems to be the PC_to_RDR_Escape messages which
are built into CCID. This way at least the reader part will be
compliant to a standard protocol, only the 'card simulation' part is
different.
If somebody ever does another version of the hardware, it might be worth
using a pin-to-pin compatible SAM3S, which would provide 7 USB endpoints
and thus work the way I originally thought in my last mail.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)