11 Feb
2012
11 Feb
'12
10:42 p.m.
Hi
It seems to me that simtrace looses a byte between 2 URB transfers from the device. To
trace the problem down, I wrote a little test-program, running the same APDU against the
smart card.
I’m using simtrace to trace the card on the HW level and at the very same time I trace on
the PCSC layer of the OS. Of cause the 2 APDU traces should give exactly the same results.
Surprisimgly I found that the simtrace is swallowing one byte between two URB chunks
transferred.
Please find below the 2 logs A.) PCSC trace, B.) simtrace output. In this example simtrace
is missing 1 byte (“7F”) between the two URB chunks a.) and b.). This missing byte causes
to scrow up the analyser (APDU number 5). The same problem occurs also between the next
two URB chunks b.) and c.): This time a “00” gets lost ... etc etc.
A.) The PCSC traces as reference: =======================================
1.) transmitted:
80 C2 00 00 28 D8 00 01 6F 00 F5 EF BF B1 8C 76 16 00 0E 43 6F 6E 74 65 6E 74
4D 61 6E 61 67 65 72 00 C0 4B 4E 7F BD 00 04 4D 53 43 4D
received:
61 05
2.) transmitted:
00 C0 00 00 05
received:
01 00 00 00 05 90 00
3.) transmitted:
80 C2 00 00 12 D8 00 05 6F 00 C0 4B 4E 7F BD DE EC 00 04 4D 53 43 4D
received:
61 0F
4.) transmitted:
00 C0 00 00 0F
received:
00 D2 5D 1C 11 27 00 07 37 2E 31 2E 30 2E 30 90 00
5.) transmitted:
80 C2 00 00 14 D8 00 05 6F 00 C0 4B 4E 7F BD 81 87 00 04 4D 53 43 4D 05 00
received:
61 1A
6.) transmitted:
00 C0 00 00 1A
received:
00 D2 5D 1C 45 A3 00 00 00 10 2E 4E 45 54 57 01 13 51 21 9C 77 14 27 14 FF FF
90 00
7.) transmitted:
80 C2 00 00 12 D8 00 05 6F 00 C0 4B 4E 7F BD FA 3B 00 04 4D 53 43 4D
received:
61 12
8.) transmitted:
00 C0 00 00 12
received:
00 D2 5D 1C 45 A3 00 00 00 08 83 17 65 55 19 7E A5 EB 90 00
9.) transmitted:
80 C2 00 00 1E D8 00 05 6F 00 C0 4B 4E 7F BD 24 FE 00 04 4D 53 43 4D 00 00 00
08 FC 66 34 93 BD 58 68 54
received:
90 00
10.) transmitted:
80 C2 00 00 13 D8 00 05 6F 00 C0 4B 4E 7F BD 6D 08 00 04 4D 53 43 4D 02
received:
61 0A
11.) transmitted:
00 C0 00 00 0A
received:
00 D2 5D 1C 61 C0 00 00 00 05 90 00
B.) The simtrace output: ================================================
simtrace - GSM SIM and smartcard tracing
(C) 2010 by Harald Welte <laforge(a)gnumonks.org>
Entering main loop
URB: 01 01 00 00 3b 16 96 41 73 74 72 69 64
ATR APDU: 3b 16 96 41 73 74 72 69 64
a.) URB: 01 00 00 00 80 c2 00 00 28 c2 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e
74 65 6e 74 4d 61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05 00 c0 00 00 05
c0 01 00 00 00 05 90 00 80 c2 00 00 12 c2 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53
43 4d 61 0f 00 c0 00 00 0f c0 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00 80 c2 00
00 14 c2 d8 00 05 6f 00 c0 4b 4e
1.) APDU: 80 c2 00 00 28 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74 65 6e 74 4d
61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05
2.) APDU: 00 c0 00 00 05 01 00 00 00 05 90 00
3.) APDU: 80 c2 00 00 12 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43 4d 61 0f
4.) APDU: 00 c0 00 00 0f 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00
b.) URB: 01 00 00 00 bd 81 00 04 4d 53 43 4d 05 00 61 1a 00 c0 00 00 1a c0 00 d2 5d 1c 45
a3 00 00 00 10 2e 4e 45 54 57 01 13 51 21 9c 77 14 27 14 ff ff 90 00 80 c2 00 00 12 c2 d8
00 05 6f 00 c0 4b 4e 7f bd fa 3b 00 04 4d 53 43 4d 61 12 00 c0 00 00 12 c0 00 d2 5d 1c 45
a3 00 00 00 08 83 17 65 55 19 7e a5 eb 90 00 80 c2 00 00 1e c2 d8 00 05 6f 00 c0 4b 4e 7f
bd 24 fe 00 04 4d 53 43 4d 00 00
5.) APDU: 80 c2 00 00 14 d8 00 05 6f 00 c0 4b 4e bd 81 00 04 4d 53 43 4d 05 00 61 1a 00 c0
APDU: 00 00 1a c0 00 d2 5d
APDU: 1c 45 a3 00 00 00 10
APDU: 2e 4e 45 54 57 01 13
APDU: 51 21 9c 77 14 27 14
APDU: ff ff 90 00 80 c2 00
APDU: 00 12 c2 d8 00 05 6f
APDU: 00 c0 4b 4e 7f bd fa
APDU: 3b 00 04 4d 53 43 4d
APDU: 61 12 00 c0 00 00 12
APDU: c0 00 d2 5d 1c 45 a3
APDU: 00 00 00 08 83 17 65
APDU: 55 19 7e a5 eb 90 00
c.)URB: 01 04 00 00 08 fc 66 34 93 bd 58 68 54
d.)URB: 01 04 00 00 90 00 80 c2 00 00 13 c2 d8 00 05 6f 00 c0 4b 4e 7f bd 6d 08 00 04 4d
53 43 4d 02 61 0a 00 c0 00 00 0a c0 00 d2 5d 1c 61 c0 00 00 00 05 90 00
APDU: 80 c2 00 00 1e d8 00 05 6f 00 c0 4b 4e 7f bd 24 fe 00 04 4d 53 43 4d 00 00 08 fc 66
34 93 bd 58 68 54 90 00 80
APDU: c2 00 00 13 c2 d8 00
APDU: 05 6f 00 c0 4b 4e 7f
APDU: bd 6d 08 00 04 4d 53
APDU: 43 4d 02 61 0a 00 c0
APDU: 00 00 0a c0 00 d2 5d
APDU: 1c 61 c0 00 00 00 05
URB: 01 01 00 00 3b 16 96 41 73 74 72 69 64
ATR APDU: 3b 16 96 41 73 74 72 69 64
==========================================================
Is this a problem of simtrace or the firmware?
Am I using a wrong firmware?
Thanks,
Ben
12 Feb
12 Feb
11:04 a.m.
Hi Ben,
On Sat, Feb 11, 2012 at 10:42:32PM +0100, Myonium wrote:
It seems to me that simtrace looses a byte between 2
URB transfers
from the device. To trace the problem down, I wrote a little
test-program, running the same APDU against the smart card.
Interesting. This hasn't been seen so far. Can you please let us know
more about your setup, particularly the baud rate you're running at? My
immediate assumption would be that the PPS is selecting a high-speed
rate and we run into an overflow somewhere, possibly in reading the UART FIFO.
If you can force your reader to use a lower rate (e.g. by using a very
old card, or explicit commands on the host/reader side) it would be
worth trying it at different speeds and checking if there is any change
in behavior.
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)
11:12 a.m.
It seems to me
that simtrace looses a byte between 2 URB transfers
from the device. To trace the problem down, I wrote a little
test-program, running the same APDU against the smart card.
Interesting. This hasn't been seen so far.
2:46 p.m.
On Feb 12, 2012, at 11:04 AM, Harald Welte wrote:
Thank you for the fast reply.
Your assumption (speed issue) most probably right. It happened to me with a new “Gemalto
.NET v2.0” card which has baud rates up to 223kbps.
Would the simtrace device give me the transfer rate? How would you suggest to measure it?
To contrast it, I run the same setup (different APDUs) with a "old" Cyberflex
32k card. => I got a 100% match. No bytes lost. It's not a general issue.
Btw. a neat idea to run the card with a different speed when tracing ....
Interesting to see from the traces (new Gemalto .NET v2.0 card), that there is not PPS
negotiation. I would probably have to make a warm reset to trigger that. Indeed that would
be a nice experiment also I currently have no clue how to do it ... in theory that would
be something, which could be included into the firmware ... what do you think? (The
simtrace firmware would always negotiate a speed it could handle ....)
Regards,
Ben
It seems to me
that simtrace looses a byte between 2 URB transfers
from the device. To trace the problem down, I wrote a little
test-program, running the same APDU against the smart card.
Interesting. This hasn't been seen so far. Can you please let us know
more about your setup, particularly the baud rate you're running at? My
immediate assumption would be that the PPS is selecting a high-speed
rate and we run into an overflow somewhere, possibly in reading the UART FIFO.
If you can force your reader to use a lower rate (e.g. by using a very
old card, or explicit commands on the host/reader side) it would be
worth trying it at different speeds and checking if there is any change
in behavior.
3:22 p.m.
Hi again,
On Sun, Feb 12, 2012 at 02:46:37PM +0100, Myonium wrote:
Thank you for the fast reply.
Your assumption (speed issue) most probably right. It happened to me
with a new “Gemalto .NET v2.0” card which has baud rates up to
223kbps. Would the simtrace device give me the transfer rate? How
would you suggest to measure it?
If you look at the serial console, it should even tell you the
negotiated PPS settings. So far there is no code to export this via USB
t othe host PC, as far as I remember. However, it would be simple to
add it in case you don't happen to have a matching serial cable. Please
let me know.
Btw. a neat idea to run the card with a different
speed when tracing ....
Interesting to see from the traces (new Gemalto .NET v2.0 card), that
there is not PPS negotiation. I would probably have to make a warm
reset to trigger that. Indeed that would be a nice experiment also I
currently have no clue how to do it ... in theory that would be
something, which could be included into the firmware ... what do you
think? (The simtrace firmware would always negotiate a speed it could
handle ....)
Well, I think that the firmware can be fixed to handle all the speeds,
and we should try that as a primary goal. But yes, twisting the ATR
bytes in order to ensure the Fi/Di values cannot be selected above a
certain speed might very well be a nice idea. It's more in the area of
a man-in-the-middle than a purely passive trace, though.
--
- 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)
3:42 p.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
On Sun, Feb 12, 2012 at 03:22:41PM +0100, Harald Welte wrote:
Hi again,
On Sun, Feb 12, 2012 at 02:46:37PM +0100, Myonium wrote:
I've quickly implemented this, but don't have time to test it right now.
Please update your simtrace host utility to rev.
b14d0ad2792d3f76ec21e141229840c736a2f23c or later, and use firmware
4f7ca20bf40b911c035264d86ef0359d20e7ac88 or later. I've attached a
firmware image (for dfu-util flashing) for your reference.
The simtrace program on the host pc should print something like
PPS(Fi=X/Di=Y) once a PPS happens, using the values that were obtained
from the acual PPS sniffing.
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)
Thank you for the fast reply.
Your assumption (speed issue) most probably right. It happened to me
with a new “Gemalto .NET v2.0” card which has baud rates up to
223kbps. Would the simtrace device give me the transfer rate? How
would you suggest to measure it?
If you look at the serial console, it should even tell you the
negotiated PPS settings. So far there is no code to export this via USB
t othe host PC, as far as I remember. However, it would be simple to
add it in case you don't happen to have a matching serial cable. Please
let me know.
14 Feb
14 Feb
11:41 p.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
Hi again,
On Sun, Feb 12, 2012 at 02:46:37PM +0100, Myonium wrote:
I've quickly implemented this, but don't have time to test it right now.
Please update your simtrace host utility to rev.
b14d0ad2792d3f76ec21e141229840c736a2f23c or later, and use firmware
4f7ca20bf40b911c035264d86ef0359d20e7ac88 or later. I've attached a
firmware image (for dfu-util flashing) for your reference.
The simtrace program on the host pc should print something like
PPS(Fi=X/Di=Y) once a PPS happens, using the values that were obtained
from the acual PPS sniffing. Thank you for the fast reply.
Your assumption (speed issue) most probably right. It happened to me
with a new “Gemalto .NET v2.0” card which has baud rates up to
223kbps. Would the simtrace device give me the transfer rate? How
would you suggest to measure it?
If you look at the serial console, it should even tell you the
negotiated PPS settings. So far there is no code to export this via USB
t othe host PC, as far as I remember. However, it would be simple to
add it in case you don't happen to have a matching serial cable. Please
let me know. 
15 Feb
15 Feb
11:14 a.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
On 02/14/2012 11:41 PM, Myonium wrote:
What do you think would be the maximum speed the
current HW (v1.1) could handle (if tuned a little bit ;-) ?
Hi,
just from the expectation: The SAM7 should support all modes of ISO 7816-3 so
I would expect that the SIMtrace works with all of them as well. My debug
proposal would be:
Topic:
Find out where the byte(s) is lost.
How:
I am not sure if the debug uart code is IRQ driven and if it has a rather long
queue.. but... I would start by dumping every received byte to the other UART
and compare the results.
Reasoning:
This should isolate the problem to be either on the USART (receiving data
properly) or in our USB code.
Before one starts:
Are you sure that the data is missing in the 'URB', in contrast to the host
utility losing them when splitting APDUs?
9:35 p.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
On Feb 15, 2012, at 11:14 AM, Holger Hans Peter Freyther wrote:
Before one starts:
Are you sure that the data is missing in the 'URB', in contrast to the host
utility losing them when splitting APDUs?
Yes, I printed out the URB from simtrace. That was the way I discovered the missing bytes.
Of cause the APDU analyzer screws up if a byte is missing.
Missing bytes were (in all cases I analyzed) always between URB chunks. Please find below
2 samples:
Sample A.) In this case between URB a.) and b.) the byte "7F" gets lost. The
last APDU should be " 80 C2 00 00 14 D8 00 05 6F 00 C0 4B 4E 7F BD 81 87 00 04 4D 53
43 4D 05 00".
ATR APDU: 3b 16 96 41 73 74 72 69 64
a.)URB: 01 00 00 00 80 c2 00 00 28 c2 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e
74 65 6e 74 4d 61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05 00 c0 00 00 05
c0 01 00 00 00 05 90 00 80 c2 00 00 12 c2 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53
43 4d 61 0f 00 c0 00 00 0f c0 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00 80 c2 00
00 14 c2 d8 00 05 6f 00 c0 4b 4e
APDU: 80 c2 00 00 28 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74 65 6e 74 4d 61
6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05
APDU: 00 c0 00 00 05 01 00 00 00 05 90 00
APDU: 80 c2 00 00 12 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43 4d 61 0f
APDU: 00 c0 00 00 0f 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00
b.)URB: 01 00 00 00 bd 81 87 00 04 4d 53 43 4d 05 00 61 1a 00 c0 00 00 1a c0 00 d2 5d 1c
45 a3 00 00 00 10 2e 4e 45 54 57 01 13 51 21 9c 77 14 27 14 ff ff 90 00 80 c2 00 00 12 c2
d8 00 05 6f 00 c0 4b 4e 7f bd fa 3b 00 04 4d 53 43 4d 61 12 00 c0 00 00 12 c0 00 d2 5d 1c
45 a3 00 00 00 08 ef d2 66 21 9d 45 61 5c 90 00 80 c2 00 00 1e c2 d8 00 05 6f 00 c0 4b 4e
7f bd 24 fe 00 04 4d 53 43 4d 00
APDU: 80 c2 00 00 14 d8 00 05 6f 00 c0 4b 4e bd 81 87 00 04 4d 53 43 4d 05 00 61 1a 00
Sample B.) In this Sample the byte "BD" is lost. (Again the last APDU should be
" 80 C2 00 00 14 D8 00 05 6F 00 C0 4B 4E 7F BD 81 87 00 04 4D 53 43 4D 05 00".)
ATR APDU: 3b 16 96 41 73 74 72 69 64
URB: 01 00 00 00 80 c2 00 00 28 c2 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74
65 6e 74 4d 61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05 00 c0 00 00 05 c0
01 00 00 00 05 90 00 80 c2 00 00 12 c2 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43
4d 61 0f 00 c0 00 00 0f c0 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00 80 c2 00 00
14 c2 d8 00 05 6f 00 c0 4b 4e
APDU: 80 c2 00 00 28 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74 65 6e 74 4d 61
6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05
APDU: 00 c0 00 00 05 01 00 00 00 05 90 00
APDU: 80 c2 00 00 12 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43 4d 61 0f
APDU: 00 c0 00 00 0f 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00
URB: 01 00 00 00 7f 81 87 04 4d 53 43 4d 05 00 61 1a 00 c0 00 00 1a c0 00 d2 5d 1c 45 a3
00 00 00 10 2e 4e 45 54 57 01 13 51 21 9c 77 14 27 14 ff ff 90 00 80 c2 00 00 12 c2 d8 00
05 6f 00 c0 4b 4e 7f bd fa 3b 00 04 4d 53 43 4d 61 12 00 c0 00 00 12 c0 00 d2 5d 1c 45 a3
00 00 00 08 51 e6 e0 88 2a 26 cb 51 90 00 80 c2 00 00 1e c2 d8 00 05 6f 00 c0 4b 4e 7f bd
24 fe 00 04 4d 53 43 4d 00 00
APDU: 80 c2 00 00 14 d8 00 05 6f 00 c0 4b 4e 7f 81 87 04 4d 53 43 4d 05 00 61 1a 00 c0
I will try to analyse this ... as I can only spend time in the evenings for that, it will
take me some time ...
Regards,
Ben
16 Feb
16 Feb
10:54 p.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
On Feb 15, 2012, at 11:14 AM, Holger Hans Peter Freyther wrote:
How:
I am not sure if the debug uart code is IRQ driven and if it has a rather long
queue.. but... I would start by dumping every received byte to the other UART
and compare the results.
Not sure if I got you right ... what I tried was the following ...
In “simtrace/iso7816_uart.c” I added to the function “process_byte” a line to dump all
bytes “DEBUGPCR("IN=0x%08x", byte);”
First the reference bytes, traced on PC/SC layer:
========= snip ===================================
transmitted:
80 C2 00 00 13 D8 00 05 6F 00 C0 4B 4E 7F BD 6D 08 00 04 4D 53 43 4D 02
received:
61 0A
transmitted:
00 C0 00 00 0A
received:
00 D2 5D 1C 61 C0 00 00 00 05 90 00
========= snip ===================================
and that is what I got from the serial debug connection (an x marks a match, missing bytes
are appended):
========= snip ===================================
...
IN=0x00000080 x
IN=0x000000c2 x
IN=0x00000000 00
IN=0x00000013 x
IN=0x000000c2
IN=0x000000d8 x
IN=0x00000000 05
IN=0x0000006f 00
IN=0x000000c0 x
IN=0x0000004b 4E
IN=0x0000007f BD
IN=0x0000006d 08
IN=0x00000000 x
IN=0x00000004 4D
IN=0x00000053 x
IN=0x0000004d x
IN=0x00000002 x
IN=0x00000061 x
IN=0x0000000a x
IN=0x00000000 x
IN=0x000000c0 x
IN=0x00000000 00
IN=0x0000000a x
IN=0x000000c0
IN=0x00000000 x
IN=0x000000d2 5D
IN=0x0000001c 61
IN=0x000000c0 x
IN=0x00000000 x
IN=0x00000000 x
IN=0x00000005 x
IN=0x00000090 x
IN=0x00000000 x
WRAP DURING APPEND
__pio_irq_demux(43): PIO_ISR_STATUS = 0x11e004d6
RST
computed Fi(1) Di(1) ratio: 372
__pio_irq_demux(43): PIO_ISR_STATUS = 0x11800494
RST
========= snip ===================================
Result:
a.) There are several missing bytes.
b.) There are two bytes (“C2” and “C0”) too much???
My debug serial connection is at a very slow rate (115200Bps) compared to the smart card
communication. So I assume it is to be expected, that I’m missing here some bytes ...
Where would be a better way to dump the bytes without interfering / disturbing too much
....
Grateful for any suggestions
17 Feb
17 Feb
12:11 a.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
Myonium wrote:
I printed out the URB from simtrace.
You could have a look using usbmon as well. mount debugfs, then build
and run http://people.redhat.com/zaitcev/linux/usbmon-6.tar.gz on
the bus.
//Peter
12:15 a.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
Myonium wrote:
Where would be a better way to dump the bytes without
interfering
/ disturbing too much ....
Grateful for any suggestions
Reserve a buffer in RAM on the microcontroller big enough to hold the
two first USB transfers and some 100 bytes extra. Fill the buffer
where you now do the debug print. Send buffer as ASCII over UART when
it has filled up. Compare with output from the usbmon tool. (Use %02x
format string.)
//Peter
18 Feb
18 Feb
11:12 a.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
Thanks, Peter, please find below the first results from the “speed issue” analysis:
1.) I contrasted the URB chunks received in “simtrace host” with the usbmon output. =>
There is a 100% match. No data is lost in the “simtrace host program”.
2.) I increased and decreased the buffer size (rctx) of the firmware. => If there were
bytes lost, than always between URB chunks. Decreasing the buffer size improved the
situation a lot! Reducing the buffer size from 128B (default) to 32B almost eliminated the
lost byte problem (1 of 5 failed). With a buffer size of 16B I never had a lost byte.
=> Conclusion: The send_rctx with a “large” buffer is so expensive, that we are loosing
bytes while sending the chunk.
It solved the problem for me, by setting the buffer to 16B. However any idea how we could
lighten the send data process? Any other conclusions?
Regards,
Ben
On Feb 17, 2012, at 12:11 AM, Peter Stuge wrote:
Myonium wrote:
I printed out the URB from simtrace.
You could have a look using usbmon as well. mount debugfs, then build
and run http://people.redhat.com/zaitcev/linux/usbmon-6.tar.gz on
the bus.
//Peter
8:18 p.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
Myonium wrote:
Thanks, Peter, please find below the first results
from the “speed
issue" analysis:
Good work.
1.) I contrasted the URB chunks received in “simtrace
host” with
the usbmon output. => There is a 100% match. No data is lost in the
“simtrace host program”.
Ok.
2.) I increased and decreased the buffer size (rctx)
of the
firmware. => If there were bytes lost, than always between URB
chunks. Decreasing the buffer size improved the situation a lot!
Reducing the buffer size from 128B (default) to 32B almost
eliminated the lost byte problem (1 of 5 failed). With a buffer
size of 16B I never had a lost byte.
=> Conclusion: The send_rctx with a “large” buffer is so expensive,
that we are loosing bytes while sending the chunk. It solved the
problem for me, by setting the buffer to 16B. However any idea how
we could lighten the send data process? Any other conclusions?
Your findings make sense.
I note that all data to be transmitted is copied byte for byte from
the rctx data buffer into the USB peripheral memory. I had expected
zero copy. During copying, interrupts are disabled.
Basically the USB "framework" would need to be rewritten specifically
for zero copy operation, if the hardware actually allows that.
Meanwhile, going down to 16 or even 8 bytes per packet is fine IMO.
//Peter
19 Feb
19 Feb
12:38 a.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
Hi Peter and others,
On Sat, Feb 18, 2012 at 08:18:33PM +0100, Peter Stuge wrote:
I note that all data to be transmitted is copied byte
for byte from
the rctx data buffer into the USB peripheral memory. I had expected
zero copy. During copying, interrupts are disabled.
Basically the USB "framework" would need to be rewritten specifically
for zero copy operation, if the hardware actually allows that.
unfortunately the old USB peripheral in the sam7s does not have DMA, you
have to use FIFO / MMIO to put the data onto USB. It's really sad,
almost all other peripherals can do DMA, but not the USB device
controller.
I'd love to investigate this further, but I don't have the time right
now, sorry :/
--
- 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)
12:57 a.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
Harald Welte wrote:
I figured as much. Perhaps writing to the FIFO can happen already
when initially receiving the data from the serial port, ie. without
first storing to a buffer in RAM. But I think this will have some
non-trivial consequences for the code.
//Peter
Basically the
USB "framework" would need to be rewritten specifically
for zero copy operation, if the hardware actually allows that.
unfortunately the old USB peripheral in the sam7s does not have DMA, you
have to use FIFO / MMIO to put the data onto USB. It's really sad,
almost all other peripherals can do DMA, but not the USB device
controller.
1:02 a.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
Peter Stuge wrote:
Perhaps writing to the FIFO can happen already when
initially
receiving the data from the serial port
Another approach is to do copying with interrupts enabled. It might
then instead require a bit from the buffer management, to avoid the
receive interrupt from stomping on unsent data.
//Peter
10:03 a.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
Hi
On Sun, Feb 19, 2012 at 1:02 AM, Peter Stuge <peter(a)stuge.se> wrote:
Peter Stuge wrote:
Are FIQ disabled as well ? Or could we move uart RX to fiq ?
Cheers,
Sylvain
Perhaps writing to the FIFO can happen already
when initially
receiving the data from the serial port
Another approach is to do copying with interrupts enabled. It might
then instead require a bit from the buffer management, to avoid the
receive interrupt from stomping on unsent data.
12:50 p.m.
New subject: Printing Fi/Di values from simtrace host tool (PPS)
On Sun, Feb 19, 2012 at 10:03:30AM +0100, Sylvain Munaut wrote:
Hi
On Sun, Feb 19, 2012 at 1:02 AM, Peter Stuge <peter(a)stuge.se> wrote:
IIRC, the UART is even DMA capable (via the PDC), but the problem is
that we have to act on each byte in realtime to watch for Fi/Di changes
(PPS) which can occur basically at any time. So I think it will have
to remain software manually pulling out each byte from the UART.
--
- 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)
Peter Stuge wrote:
Are FIQ disabled as well ? Or could we move uart RX to fiq ? Perhaps writing to the FIFO can happen already
when initially
receiving the data from the serial port
Another approach is to do copying with interrupts enabled. It might
then instead require a bit from the buffer management, to avoid the
receive interrupt from stomping on unsent data.
21 Mar
21 Mar
11:48 p.m.
New subject: lost bytes in ISO7816 UART receive
Hi Peter and others,
On Sat, Feb 18, 2012 at 08:18:33PM +0100, Peter Stuge wrote:
I note that all data to be transmitted is copied byte
for byte from
the rctx data buffer into the USB peripheral memory. I had expected
zero copy. During copying, interrupts are disabled.
I'm actually not sure on the latter part:
* the hardware and IRQ handler code supports nested interrupts
* the core IRQ handler assembly code re-enables interrupts immediately
even before calling the USB driver
* the endpoint re-fill code called from the irq handler
__udp_refill_ep() doesn't contain any explicit local_irq_disable()
* the USART interrupt priority (4) is higher than the USB prio (2)
So based on all this, the USART interrupt should happily be served as a
nested IRQ even while the USB driver is re-filling the end-point FIFO.
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)
4441
days inactive
4480
days old
19 comments
5 participants
participants (5)
-
Harald Welte -
Holger Hans Peter Freyther -
Myonium -
Peter Stuge -
Sylvain Munaut