17 Mar
2017
17 Mar
'17
12:30 p.m.
Dear SIMtrace Developers,
After having spent a few days reviewing your SIMtrace hardware and FW
and its development,
I would like to propose you to consider supporting the following project.
Background:
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.
Proposal:
The new project would utilize a RaspberryPi-Zero-W in the external
slave configuration or a RPi3 doubling as a host. The RPi-0 is a 1GHz
ARM processor (ARM1176JZF-S) and could possibly also be used as a
headless host via WiFi. (RPi0 has OTG USB, RPi3 doesn't.) The Rpi3 is
a quad-core 64-bit Cortex-A53, that can be used as anything. Thus
porting A53 to M3 might be more easy.
Advantages:
There are too many advantages to ignore...
- The huge RPi developer community
- The high clockspeed and 512+ Mb of RAM
- All interfaces you can dream of, except JTAG
- 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.
- A huge reduction to about 1/3 of what is currently used of the PCB footprint.
- A large reduction of production price due to above.
- Easy to port drivers when understood
- Provide a more attractive and useful product combo (RPi-0 + ST hat)
than what is currently offered.
Disadvantages:
- Need porting of current FW drivers to RPi's
- Possible proprietary limitation to the complete Broadcom datasheets
- Need to CAD and manufacture a new PCB
- New Rpi-0/3 drivers would need testing for use with 2 SIM IF's.
Other:
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?) The library
used for this is the PGPIO from here:
http://abyz.co.uk/rpi/pigpio/download.html
and a Python based test-script can be found here:
https://www.rs-online.com/designspark/raspberry-pi-2nd-uart-a-k-a-bit-bangi…
Finally, please don't get me wrong. This is not at all a critique of
what has already been done. The development of the ST is a great piece
of work and obviously very flexible and cross platform compatible by
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 would love to hear what the community and Osmocom think about this.
Cheers,
E:V:A
17 Mar
17 Mar
4:09 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
18 Mar
18 Mar
12:35 a.m.
On Fri, Mar 17, 2017 at 04:09:22PM +0100, Harald Welte wrote:
I share Harald's view.
The RPi would simply replace the micro-controller and this comes with a lot of
disadvantages.
With the RPi you would always have to keep in sync with all the underlying layer (a
complete OS), and also keep the OS up to date. Plus it's hard to guess how long this
hardware would be supported and available.
The only advantage (e.g. problem it would solve) would be to make the entry level lower
(writing software on an OS might be easier than low level micro-controller code). But on
the other side that would also open gate for much more newcomer questions for less
technically involved developer.
I don't mind newcomers, after all SIMtrace was also my first hardware project, but
there are numerous other non-hardware related aspects already which didn't get any
contribution (host software, wireshark dissector, or simply wiki documentation). I am not
sure lowering the entry to the more technical aspects would change this.
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.
21 Mar
21 Mar
3:40 p.m.
Dear Harald and Kevin,
Although, interesting from a purely academic view, you have both
already convinced me about the redundancy of using RPi for this
project. However, let me still respond to your answers.
On Fri, Mar 17, 2017 at 5:09 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Well a lot of security projects are using just the RPi3 and Zero for
testing all sorts of things, including using Wireshark for decoding
LTE and what not. Mostly for the reasons of simplicity, portability,
accessibility and low price.
The high clockspeed allow you to emulate various high speed interfaces
and dissect their protocols in real time.
The large RAM let you save loads of data reomtely as a IoT and lots
more, like a full native OS.
For complex devices like phones and TVs etc, Yes, but for THIS device
that only consist of 3 serial ports, I simply have no idea who would
use this and for what, after production.
Well, to be anal about this, then you should also add the footprint
and price of your PC HW that you use to plugin to.The point here, was
that you would have one extremely small stand-alone computer that does
everything you currently do, but to half the price of the SIMtrace HW
itself.
I can't argue with you on this point since I haven't even looked
enough into it. But, looking at the code for the ISO7816 labelled
bits, and knowing that there are a lot of already available I/F
bit-banging solutions for the RPi, is probably what triggered my
interest of this, in the first place.
That was the idea. And since RPi is ARM and popular for all sorts of
other embedded devices. I guess there ought to be a similar solution
out there already.
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?
I think its rather an academic interest in being able to push the
limits of popular embedded hardware. For example, the usage of RPi as
a successful FM (and 1000 Km range on HF) transmitter, is really
something exceptional. (All IMHO of course.) The more uses we can find
for these things, the more interest people will have to try out their
ideas.
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. 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. 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.
This is an entertaining answer as RPis have been used as weather
stations in arctic climates where winter Temp can easily reach -20C. I
doubt you will find anyone doing any SIMtracing there. :)
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.
I agree and as I said on top, you have me convinced. As for your other
comments, I think I already covered the relevant ones in the other
thread.
Thanks again for your team effort and support.
Cheers,
E:V:A
5:51 p.m.
Hi E:V:A,
On Tue, Mar 21, 2017 at 04:40:05PM +0200, E:V:A wrote:
I would be highly surprised. You basically have to start from scratch.
Well, this may be the case, but there is one topic of using commercial
temperature rated equipment out of spec (which may work in many cases,
but may break in all kinds of ways, also from one production batch to
the other, because a different capacitor model/brand was used, and it
has a different thermal curve, which doesn't require the performance at
-20 or even down to -40 centigrade. So basically "you are just lucky"
The other part is in professional industrial electronics development
(which I've been doing for quite some years, with interruptions), where
you make sure that all parts you use are fully qualified over the
industrial temperature range, and you cannot have the above-mentioned
surprises.
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.
That was the idea. And since RPi is ARM and popular for all sorts of
other embedded devices. I guess there ought to be a similar solution
out there already. 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.
This is an entertaining answer as RPis have been used as weather
stations in arctic climates where winter Temp can easily reach -20C. I doubt you will find anyone doing any SIMtracing
there. :)
You would be surprised. Some people are using SIMtrace or related
devices as part of permanent installations in order to assess e.g.
cellular network security.
As much as I appreciate the enthusiasm, creativity and success of a lot
of the arduino/raspi/... based embedded projects that kome from the
wider maker community, there are quite some parts I don't like about it.
The lack of industrial tmeperature/climate spec on the one hand, the
incredibly complex and large software stack that might need to be
maintained. The issue about using commercial-grade SD/MMC cards as
opposed to industrial-grade mmc (wit proper SMART-like features to get
advance notification of wear levelling statistics) or good old NOR flash
(SAM3), ...
I agree and as I said on top, you have me convinced.
Great!
So let's hope you can find some time and energy got help out. As
indicated, I'm happy to send out some free SIMtrace with SAM3, or
alternatively you could help with (re)integrating the tracing
functionality in the simtrace2.x firmware branch, or porting the
simtrace2.x firmware to 1.x hardware, or work on wireshark dissectors,
...
--
- 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)
2600
days inactive
2604
days old
4 comments
3 participants
participants (3)
-
E:V:A -
Harald Welte -
Kévin Redon