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-bangin...
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
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
On Fri, Mar 17, 2017 at 04:09:22PM +0100, Harald Welte wrote:
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 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.
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@gnumonks.org wrote:
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.
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 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.
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.
- 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?
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.
- 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.
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.
- 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.
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.
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.
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. :)
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
Hi E:V:A,
On Tue, Mar 21, 2017 at 04:40:05PM +0200, E:V:A wrote:
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.
I would be highly surprised. You basically have to start from scratch.
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.
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.
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, ...
-
E:V:A -
Harald Welte -
Kévin Redon