New hardware support or replacement proposal

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/.

E:V:A xdae3v3a at gmail.com
Tue Mar 21 14:40:05 UTC 2017


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 at 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



More information about the simtrace mailing list