This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgStatus 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 at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)