New hardware support or replacement proposal

historical

Hi E:V:A,

On Fri, Mar 17, 2017 at 01:30:43PM +0200, E:V:A wrote:

> The current SIMtrace processor (AT91SAM7) is based on the 55 MHz
> ARMv4T uP, whereas the next generation SIMtrace2 is to use (AT91SAM3)
> which is based on a 96 MHz Cortex-M3. This is all great and dandy, but
> it does limit the hardware and software development to people who are
> already very familiar with that hardware. Why are these needed? They
> are needed so that we can have 2 SIM (USART) interfaces and that we
> can translate the signals found on those to/from a USB endpoint on the
> USB port. This is all done in the firmware, written in C + Assembly.

The AT91SAMxx controllers have been specifically chosen as they are the
only controllers I could find on the market which allow (even though not
officially explicitly documented) an UART in ISO7816-mode on the *card
side*.

A normal UART does not typically support ISO7816 mode.  Yes, you can
hack together something like a "Phoenix style" reader with wiring
together Rx and Tx of a regular (RS-232 style) UART, but you will
violate smard card interface specs in all places back and forward.

While a lot of microcontrollers have ISO7816 support in the UART, the
hardware is designed in a way that restricts this to implementing the
Reader-Side of ISO7816, and not the Card side - be alone a passive
tracing.

The requirements are subtly different between those modes, for example
when it comes to
* who is a master and who is a slave of the clock
* being able to count the clock cycles to derive ETU and Waiting Time
  from it
* the card generates the ACK/NACK in case of partiy error, while the
  reader or a sniffer doesn't

So I am somewhat puzzled how you would want to do this (and do it
"correctly" as per the ISO7816-1/-2/-3) with generic UARTs that have no
ISO7816 moe to begin with?

> There are too many advantages to ignore...
> - The huge RPi developer community

Who - no offence - most likely don't understand the intrinsics of
ISO7186?  I don't want to be cynical, but if people wanted to contribute
to the SIMtrace project, they could have done so in pure software, by
simply extending/completing the wireshark dissectors beyond my initial
code.  Until today, the contents of the EFs are not decoded, for
example.  Would be great if the were, but they weren't.  I don't think
this will change based on whether we use a Raspberry Pi or not on the
hardware side.

> - The high clockspeed and 512+ Mb of RAM

Not sure that is an advantage?  Why is that an advantage?  We don't use
most of the orders-of-magnitude lower RAM nor flash on the existing
devices even in the past years.

> - All interfaces you can dream of, except JTAG

...and JTAG is probably the most useful interface you can have when
implementing low-level code that's very close to hardware?

> - A huge reduction on the BOM. I've counted that we may remove about
> 50 components by using this solution instead of the current v1.3 one.

There's no problem with the BOM part count as-is?  Also.

> - A huge reduction to about 1/3 of what is currently used of the PCB footprint.

well, but then you have a RPi alongside with that, which is larger than
the original PCB footprint

> - A large reduction of production price due to above.

not sure if the production cost difference really matters.

> - Easy to port drivers when understood

Depends on what exact hardware interface you will come up to handle the
ISO7816 lower layers.  The complexity is mostly in the ISO7816 state
machines, and they won't change.

And to be honest, I don't think an in-kernel-bitbanging
implementation/driver of a ISO7816 soft-uart is going to be easy to
understand (it just has to replicate what the SAMx hardware has), and it
will particularly not be easy to develop and/or debug.

With the SAMx based devices, I have probably about 15-20 seconds of
development cycles between making a change, reflashing + restarting the
board via DFU, and running the new software.  Try that with re-compiling
kernel code, crashing your entire board and having to reboot Linux all
the time, ...

> The RPi's only has one UART so to get a second, we need to use
> bit-banging of their GPIO,SPI or I2C. There are already solutions out
> there and the much higher clock-rate of both devices allow you to run
> up to 250 MHz on a single GPIO pin, so that would allow you to
> multiplex a number of virtual/emulated UARTs. (Perhaps similarly to
> what was already done when SIMtrace was using the FT232r?) 

Ok, so you'd be usign hihg-speed bit-banging and implement everyting in
software, like a 'software defined ISO7816 UART'.   That's quite some
coe that needs to be developed.

> using USB, but for compact embedded devices, such as RPi's etc, all
> that extra HW is redundant and expensive to produce and maintain. Even
> more so than combining the RPi + this add-on, while improving cross
> platform connectivity and IoT support.

I'm very happy to receive your suggestions, but what I keep wondering is
"what is the problem that he's trying to solve"?

You can probably hardly beat the performance (and power consumption) of
a small embedded device around a microcontroller.  I also would be very
surprised if you can beat the BOM cost of the existing hardware while
maintaining the same capabilities in terms of tracing, MITM, card reader
and card emulation/forwarding

The BOM cost of the SIMtrace is basically
* the SAM7/SAM3 microcontroller
* the SIM card slot
* the flexible PCB cables/adapters
* the other connectors and TVS/ESD protection
* the bus switch to connect/disconnect SIM and Phone

All of the above - except the microcontroller - you would also need in
your proposed solution *together* with a raspberry pi.  How sould all of
that have lower BOM cost?

Also, keep in mind that the SAM7/SAM3 support full industrial
temperature range, which is not offered by consumer-grade devics like
the Raspberry Pi.

I would also argue that most poeple use the SIMtrace as a
mesurement/debuggin device.  At their desk, between a phone and a SIM
card.  To do some testing/analtysis.  And doing that via a USB
peripheral is more convenient than having an ethernet or wifi attached
system, which requires an operating system (and related updates),
network configuration, etc.

I mean, we don't have Ethernet/WiFi attached chip card readers, but
USB-CCID attached ones.  We have the same for keyboard, mice, or all
kinds of other peripherals.

For specific use cases (like embedded devices with "remote SIM" feature)
we have built some devices at sysmocom that use the SAM3 + SIMtrace
firmware as part of larger embedded systems.  In that case, one or
multiple SAM3 are attached to up to four cellular modems and to some
extent also to industrial-grade ARM SoM (like TI AM335x based ones).
At that point you also have a fully-fledged embedded device with a
larger CPU, Ethernet/WiFi/etc.  - but still we decided to use the
dedicated, USB-Attached SAM3s.  Why? Because the have a reliable, known
hardware implementation of multiple fully ISO7816 compatible UARTs, and
the associated timing and state machines will run in hardware, no matter
what the linux-running main CPU of the system does.  I always prefer
hard-wired logic and bare-iron implementations on dedicated CPU cores
over any virtualized "software defined" implementation, which might or
might not at some point get pre-empted at the wrong point.

> I would love to hear what the community and Osmocom think about this.

I'm also very much looking forward to feedback from other people.

I really do appreciate your interest, but I am absolutely not convinced
that this proposal is solving any actual problem or disadvangage.

Rather than rebuilding what we alreay have based on different
technology, I would much rather like to see people invest their time in
extending what we already have.  This could be on the firmware side, but
could also be on the hardware side.  The existing PCB design is far from
great (it was one of the first circuit boards ever made by Kevin, so of
course it would look quite different by somebody who has more experience
at it). But hey, it has worked for many years :)

A new circuit board could also have support for different voltages (we
currently do only 3.3V, but with level shifters it would be possible to
do 1.8V and  5V logic levels, too).  We could design the board to fit in
some standard enclosure to avoid the "bare pcb getting short-circuited
on my desk or damaged by ESD" issue.  We could add a battery charger IC
(for charging via USB) and a small Li-Ion battery for offline tracing to
the SPI flash that we have in the design for this reason ever sinc day1,
but which nobody ever used.

For heaven's sake, in all those 5 years of SIMtrace being available,
people haven't even managed to do something as simple as to use libusb
hot-plugging API to keep the program running across SIMrtace
disconnects.  Those are really low-hanging fruits, and don't rquire any
special skills or background beyond regular C application development on
Linux.  No knowledge about hardware or SIM card protocols needed.

So I think there are *many* things that people with an interest in the
project could do.  Building a completely different hardware +
drivers/firmware to re-create what already works does not seem like the
most efficient investment in time.

Regards,
	Harald
-- 
- 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)