From laforge at gnumonks.org Mon Feb 6 18:39:06 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 6 Feb 2012 19:39:06 +0100 Subject: SIM dissector now wireshark mainline Message-ID: <20120206183906.GB14467@prithivi.gnumonks.org> Hi all! JFYI, the SIM protocol dissector has finally been merged into wirshark mainline (svn rev. 40854). This means that the daily builds from https://www.wireshark.org/download/automated/osx/ and https://www.wireshark.org/download/automated/win32/ will now work out-of-the-box for SIM card tracing, without applying any patches. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From myonium at gmail.com Sat Feb 11 21:42:32 2012 From: myonium at gmail.com (Myonium) Date: Sat, 11 Feb 2012 22:42:32 +0100 Subject: Loosing 1 byte on each chunk of URB transfer Message-ID: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> 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 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 From laforge at gnumonks.org Sun Feb 12 10:04:56 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 12 Feb 2012 11:04:56 +0100 Subject: Loosing 1 byte on each chunk of URB transfer In-Reply-To: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> Message-ID: <20120212100456.GX1898@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sun Feb 12 10:12:29 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 12 Feb 2012 11:12:29 +0100 Subject: Loosing 1 byte on each chunk of URB transfer In-Reply-To: <20120212100456.GX1898@prithivi.gnumonks.org> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> Message-ID: >> 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. Actually I think that's what I've noticed when I try listening to the communication between a LTE mifi and the SIM, except I was loosing two chars from time to time. I never got to the bottom of the issue tough, but at least I can reproduce it locally and have a deeper look. Cheers, Sylvain From myonium at gmail.com Sun Feb 12 13:46:37 2012 From: myonium at gmail.com (Myonium) Date: Sun, 12 Feb 2012 14:46:37 +0100 Subject: Loosing 1 byte on each chunk of URB transfer In-Reply-To: <20120212100456.GX1898@prithivi.gnumonks.org> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> Message-ID: On Feb 12, 2012, at 11:04 AM, Harald Welte 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. 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 From laforge at gnumonks.org Sun Feb 12 14:22:41 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 12 Feb 2012 15:22:41 +0100 Subject: Loosing 1 byte on each chunk of URB transfer In-Reply-To: References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> Message-ID: <20120212142241.GG1898@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Feb 12 14:42:04 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 12 Feb 2012 15:42:04 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <20120212142241.GG1898@prithivi.gnumonks.org> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> Message-ID: <20120212144204.GH1898@prithivi.gnumonks.org> 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: > > > 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. 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: main_simtrace.bin Type: application/octet-stream Size: 20856 bytes Desc: not available URL: From myonium at gmail.com Tue Feb 14 22:41:29 2012 From: myonium at gmail.com (Myonium) Date: Tue, 14 Feb 2012 23:41:29 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <20120212144204.GH1898@prithivi.gnumonks.org> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> Message-ID: >> 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. > > 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. Unfortunately ,there seems to be a bug in firmware rev. 4f7ca20bf40b911c035264d86ef0359d20e7ac88. I tested on my device "v1.1p": ATR don?t get through anymore. Just a ?b3? byte. The smart card isn?t responding to a reset ... I had to go back to firmware ?v0.4?. Than it is working again ... tried the process twice back and forth... will have a look at the code of the new revision next weekend. In the meantime I found a serial cable: On the console I get the following output: found Fi=9 Di=6 computed Fi(9) Di(6) ratio: 16 __pio_irq_demux(43): PIO_ISR_STATUS = 0x11e006d6 RST computed Fi(1) Di(1) ratio: 372 __pio_irq_demux(43): PIO_ISR_STATUS = 0x11800494 RST computed Fi(1) Di(1) ratio: 372 I compiled the firmware ?v0.4? with DEBUG=0. About 1 of 5 runs, it works with no bytes lost. In the other 4 runs bytes are swallowed between URB chunks ... What do you think would be the maximum speed the current HW (v1.1) could handle (if tuned a little bit ;-) ? Thanks, Ben From holger at freyther.de Wed Feb 15 10:14:05 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 15 Feb 2012 11:14:05 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> Message-ID: <4F3B856D.1050409@freyther.de> 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? From myonium at gmail.com Wed Feb 15 20:35:43 2012 From: myonium at gmail.com (Myonium) Date: Wed, 15 Feb 2012 21:35:43 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <4F3B856D.1050409@freyther.de> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> Message-ID: 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 From lists at kaiser.cx Wed Feb 15 22:43:23 2012 From: lists at kaiser.cx (Martin Kaiser) Date: Wed, 15 Feb 2012 23:43:23 +0100 Subject: 1.1p board not recognized Message-ID: <20120215224323.GA5825@viti.kaiser.cx> Dear all, I'm struggling to get started with a 1.1p board. When I connect it via USB (with no simcard inserted and no connection to a phone), the red led is on. Sometimes, both leds remain off after connecting the board when I have a simcard inserted and a phone connected. On one box (debian lenny), the board is never recognized by lsusb or kernel messages. Do I need anything special (other than basic usb support) compiled into the kernel for libusb to do its work in user space? I tried dfu-util -l, the board wasn't listed. On a second box (debian squeeze) there's log messages when the usb is connected Feb 15 22:34:44 greta kernel: [186232.651806] usb 1-1.1: new full speed USB device using ehci_hcd and address 13 Feb 15 22:34:44 greta kernel: [186232.745566] usb 1-1.1: New USB device found, idVendor=16c0, idProduct=0762 Feb 15 22:34:44 greta kernel: [186232.745573] usb 1-1.1: New USB device strings: Mfr=4, Product=5, SerialNumber=0 Feb 15 22:34:44 greta kernel: [186232.745577] usb 1-1.1: Product: SimTrace SIM Sniffer - Runtime Mode Feb 15 22:34:44 greta kernel: [186232.745581] usb 1-1.1: Manufacturer: sysmocom - systems for mobile communications GmbH Feb 15 22:34:44 greta kernel: [186232.745694] usb 1-1.1: configuration #1 chosen from 1 choice lsusb doesn't show anything either the red led is on after connecting, simtrace (linked against libusb-1.0) says "can't open USB device" After some more tries, dfu-util recognizes the board root at greta:~# dfu-util -l dfu-util - (C) 2007-2008 by OpenMoko Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY dfu-util does currently only support DFU version 1.0 Found DFU: [0x16c0:0x0762] devnum=17, cfg=0, intf=0, alt=0, name="SimTrace DFU Interface - Application Partition" Found DFU: [0x16c0:0x0762] devnum=17, cfg=0, intf=0, alt=1, name="SimTrace DFU Interface - Bootloader Partition" Found DFU: [0x16c0:0x0762] devnum=17, cfg=0, intf=0, alt=2, name="SimTrace DFU Interface - RAM" However, I'm not able to write a firmware. I tried the main_simtrace.bin that Harald posted to this list some days ago. root at greta:~# dfu-util -d 16c0:0762 -a0 -D /home/martin/tmp/main_simtrace.bin -R dfu-util - (C) 2007-2008 by OpenMoko Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY dfu-util does currently only support DFU version 1.0 Opening USB Device 0x16c0:0x0762... Found Runtime: [0x16c0:0x0762] devnum=17, cfg=0, intf=0, alt=0, name="SimTrace DFU Interface - Application Partition" Claiming USB DFU Interface... Setting Alternate Setting #0 ... Determining device status: state = dfuERROR, status = 8 dfuERROR, clearing status Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing Transfer Size = 0x0100 bytes_per_hash=417 Starting download: [#################################################dfu_download: usb_control_msg returned -32: error sending control message: Broken pipe Error during download Retrying multiple times, I always get the same error. I tried resetting the board with the bootloader button pressed, this didn't change anything. While trying to flash the firmware, there was no sim inserted and no phone connected. Does anyone have an idea what else I can try to track down the problems and get the board up and running? Thanks in advance, Martin From peter at stuge.se Wed Feb 15 23:32:15 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 16 Feb 2012 00:32:15 +0100 Subject: 1.1p board not recognized In-Reply-To: <20120215224323.GA5825@viti.kaiser.cx> References: <20120215224323.GA5825@viti.kaiser.cx> Message-ID: <20120215233215.18650.qmail@stuge.se> Martin Kaiser wrote: > On one box (debian lenny), the board is never recognized by lsusb > or kernel messages. If the kernel doesn't recognize the device and does not even output a message similar to: usb 5-2: new full speed USB device number 2 using uhci_hcd Then there is something fairly low level wrong with either device, cable, or host. > Do I need anything special (other than basic usb support) compiled > into the kernel for libusb to do its work in user space? CONFIG_USB=y CONFIG_USB_SUPPORT=y Those along with a modern udev is enough. If lsusb outputs anything at all when you run it (also without simtrace connected) you are good. //Peter From laforge at gnumonks.org Thu Feb 16 07:41:42 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 16 Feb 2012 08:41:42 +0100 Subject: 1.1p board not recognized In-Reply-To: <20120215224323.GA5825@viti.kaiser.cx> References: <20120215224323.GA5825@viti.kaiser.cx> Message-ID: <20120216074142.GI15803@prithivi.gnumonks.org> Hi Martin, On Wed, Feb 15, 2012 at 11:43:23PM +0100, Martin Kaiser wrote: > I tried dfu-util -l, the board wasn't listed. > > On a second box (debian squeeze) there's log messages when the usb is > connected > > Feb 15 22:34:44 greta kernel: [186232.651806] usb 1-1.1: new full speed > USB device using ehci_hcd and address 13 > Feb 15 22:34:44 greta kernel: [186232.745566] usb 1-1.1: New USB device > found, idVendor=16c0, idProduct=0762 > Feb 15 22:34:44 greta kernel: [186232.745573] usb 1-1.1: New USB device > strings: Mfr=4, Product=5, SerialNumber=0 > Feb 15 22:34:44 greta kernel: [186232.745577] usb 1-1.1: Product: > SimTrace SIM Sniffer - Runtime Mode > Feb 15 22:34:44 greta kernel: [186232.745581] usb 1-1.1: Manufacturer: > sysmocom - systems for mobile communications GmbH > Feb 15 22:34:44 greta kernel: [186232.745694] usb 1-1.1: configuration > #1 chosen from 1 choice > > lsusb doesn't show anything either that's really weird, if the kernel has recognized it and read the device and string descriptors, it should also show up in lsusb. The information lsusb uses is gathered by exactly those kernel log messages above. > the red led is on after connecting, simtrace (linked against libusb-1.0) > says "can't open USB device" ths was running as root? can you post a 'strace -f -s1024 ./simtrace' to see what's happening on a system call level? > root at greta:~# dfu-util -l > dfu-util - (C) 2007-2008 by OpenMoko Inc. > This program is Free Software and has ABSOLUTELY NO WARRANTY > > dfu-util does currently only support DFU version 1.0 > > Found DFU: [0x16c0:0x0762] devnum=17, cfg=0, intf=0, alt=0, > name="SimTrace DFU Interface - Application Partition" > Found DFU: [0x16c0:0x0762] devnum=17, cfg=0, intf=0, alt=1, > name="SimTrace DFU Interface - Bootloader Partition" > Found DFU: [0x16c0:0x0762] devnum=17, cfg=0, intf=0, alt=2, > name="SimTrace DFU Interface - RAM" > > > However, I'm not able to write a firmware. I tried the main_simtrace.bin > that Harald posted to this list some days ago. > > root at greta:~# dfu-util -d 16c0:0762 -a0 -D > /home/martin/tmp/main_simtrace.bin -R > dfu-util - (C) 2007-2008 by OpenMoko Inc. > This program is Free Software and has ABSOLUTELY NO WARRANTY > > dfu-util does currently only support DFU version 1.0 > > Opening USB Device 0x16c0:0x0762... > Found Runtime: [0x16c0:0x0762] devnum=17, cfg=0, intf=0, alt=0, > name="SimTrace DFU Interface - Application Partition" > Claiming USB DFU Interface... > Setting Alternate Setting #0 ... > Determining device status: state = dfuERROR, status = 8 > dfuERROR, clearing status > Determining device status: state = dfuIDLE, status = 0 > dfuIDLE, continuing > Transfer Size = 0x0100 > bytes_per_hash=417 > Starting download: > [#################################################dfu_download: > usb_control_msg returned -32: error sending control message: Broken pipe > Error during download that's almost at the end of the dlwonload, quite strange. You don't happen to have a compatible serial cable (T191, OsmocomBB, ...) that could be used to look at the serial console output of the device? Also, if you have a self-powered USB hub around (i.e. with its own power supply), it would be interesting to see if that makes any difference. > Does anyone have an idea what else I can try to track down the problems > and get the board up and running? Assuming this board was bought from sysmocom, I think after a few more experiments (see above) we will replace it with another one. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From lists at kaiser.cx Thu Feb 16 12:29:56 2012 From: lists at kaiser.cx (Martin Kaiser) Date: Thu, 16 Feb 2012 13:29:56 +0100 Subject: 1.1p board not recognized In-Reply-To: <20120216074142.GI15803@prithivi.gnumonks.org> References: <20120215224323.GA5825@viti.kaiser.cx> <20120216074142.GI15803@prithivi.gnumonks.org> Message-ID: <20120216122956.GA25933@viti.kaiser.cx> Hi Harald, thanks for your help. Thus wrote Harald Welte (laforge at gnumonks.org): > > Feb 15 22:34:44 greta kernel: [186232.651806] usb 1-1.1: new full speed > > USB device using ehci_hcd and address 13 > > Feb 15 22:34:44 greta kernel: [186232.745566] usb 1-1.1: New USB device > > found, idVendor=16c0, idProduct=0762 > > Feb 15 22:34:44 greta kernel: [186232.745573] usb 1-1.1: New USB device > > strings: Mfr=4, Product=5, SerialNumber=0 > > Feb 15 22:34:44 greta kernel: [186232.745577] usb 1-1.1: Product: > > SimTrace SIM Sniffer - Runtime Mode > > Feb 15 22:34:44 greta kernel: [186232.745581] usb 1-1.1: Manufacturer: > > sysmocom - systems for mobile communications GmbH > > Feb 15 22:34:44 greta kernel: [186232.745694] usb 1-1.1: configuration > > #1 chosen from 1 choice > > lsusb doesn't show anything either > that's really weird, if the kernel has recognized it and read the device > and string descriptors, it should also show up in lsusb. The > information lsusb uses is gathered by exactly those kernel log messages > above. ok, makes sense. I just noticed the line "SimTrace SIM Sniffer - Runtime Mode". After trying the dfu things, the behaviour is different: When I connect phone+sim card, the board is not recognized. I see no kernel messages and no lsusb output. When I plug in the usb with no phone/sim, then press reset while holding the bootloader button, the board is recognized by the kernel, identifies as SimTrace SIM Sniffer - DFU Mode and shows up in lusb as Bus 001 Device 015: ID 16c0:0762 VOTI > > the red led is on after connecting, simtrace (linked against libusb-1.0) > > says "can't open USB device" > ths was running as root? can you post a 'strace -f -s1024 ./simtrace' > to see what's happening on a system call level? yes, I tried runninng as root I assume this makes no sense if the board is not in Runtime Mode? After trying the firmware update, the board will only start in DFU Mode. Looks like the failed dfu update erased/corrupted the firmware. When I run simtrace while the board is in dfu mode, there's a different error message. The board is found, but no data can be read. That's probably what's expected when the board is in dfu mode. root at skogar:/home/martin/src/simtrace/host# ./simtrace simtrace - GSM SIM and smartcard tracing (C) 2010 by Harald Welte Entering main loop BULK IN transfer error; rc=-1 strace output is ... open("/sys/bus/usb/devices/usb1/descriptors", O_RDONLY) = 8 read(8, "\22\1\0\2\t\0\0 at k\35\2\0\6\2\3\2\1\1", 18) = 18 close(8) = 0 open("/sys/bus/usb/devices/usb2/descriptors", O_RDONLY) = 8 read(8, "\22\1\20\1\t\0\0 at k\35\1\0\6\2\3\2\1\1", 18) = 18 close(8) = 0 open("/sys/bus/usb/devices/usb3/descriptors", O_RDONLY) = 8 read(8, "\22\1\20\1\t\0\0 at k\35\1\0\6\2\3\2\1\1", 18) = 18 close(8) = 0 open("/sys/bus/usb/devices/usb4/descriptors", O_RDONLY) = 8 read(8, "\22\1\20\1\t\0\0 at k\35\1\0\6\2\3\2\1\1", 18) = 18 close(8) = 0 open("/sys/bus/usb/devices/1-3/descriptors", O_RDONLY) = 8 read(8, "\22\1\0\2\357\2\1@\2\4uv\4\0\3\1\0\1", 18) = 18 close(8) = 0 open("/sys/bus/usb/devices/1-2/descriptors", O_RDONLY) = 8 read(8, "\22\1\0\2\t\0\1@\t\4Z\0\0\1\0\0\0\1", 18) = 18 close(8) = 0 open("/sys/bus/usb/devices/1-2.4/descriptors", O_RDONLY) = 8 read(8, "\22\1\0\2\t\0\1@\t\4Z\0\0\1\0\0\0\1", 18) = 18 close(8) = 0 open("/sys/bus/usb/devices/1-2.4.3/descriptors", O_RDONLY) = 8 read(8, "\22\1\0\1\0\0\0\10\300\26b\7\0\0\1\2\0\1", 18) = 18 close(8) = 0 open("/dev/bus/usb/001/018", O_RDWR) = 8 write(4, "\1", 1) = 1 read(3, "\1", 1) = 1 ioctl(8, USBDEVFS_CLAIMINTERFACE, 0x7fff79fa933c) = 0 write(1, "Entering main loop\n", 19Entering main loop ) = 19 ioctl(8, USBDEVFS_SUBMITURB or USBDEVFS_SUBMITURB32, 0x16a7a00) = -1 ENOENT (No such file or directory) write(2, "BULK IN transfer error; rc=-1\n", 30BULK IN transfer error; rc=-1 ) = 30 ioctl(8, USBDEVFS_RELEASEINTERFACE, 0x7fff79fa933c) = 0 write(4, "\1", 1) = 1 read(3, "\1", 1) = 1 close(8) = 0 close(3) = 0 close(4) = 0 close(5) = 0 exit_group(0) = ? > > Setting Alternate Setting #0 ... > > Determining device status: state = dfuERROR, status = 8 > > dfuERROR, clearing status > > Determining device status: state = dfuIDLE, status = 0 > > dfuIDLE, continuing > > Transfer Size = 0x0100 > > bytes_per_hash=417 > > Starting download: > > [#################################################dfu_download: > > usb_control_msg returned -32: error sending control message: Broken pipe > > Error during download > that's almost at the end of the dlwonload, quite strange. > You don't happen to have a compatible serial cable (T191, OsmocomBB, > ...) that could be used to look at the serial console output of the > device? I don't have such a cable, should have ordered one along with the board. > Also, if you have a self-powered USB hub around (i.e. with its own power > supply), it would be interesting to see if that makes any difference. I've just checked this, it makes no difference. The error message is exactly the same. Would this sam-ba mode help here? From reading the website, I understand this is used when the bootloader is corrupted. It seems the bootloader is ok here as the board comes up in dfu mode. > Assuming this board was bought from sysmocom, I think after a few more > experiments (see above) we will replace it with another one. I'd appreciate this as a last resort. Best regards, Martin From myonium at gmail.com Thu Feb 16 22:06:11 2012 From: myonium at gmail.com (Myonium) Date: Thu, 16 Feb 2012 23:06:11 +0100 Subject: Corrupted git repository? Message-ID: <8F22E990-62D0-48A9-B7B8-267A86AFB002@gmail.com> Hi I?m not very familiar with git, but there is something strange with the git repository ?git://git.gnumonks.org/openpcd.git?: First of all the the identical revision number ?4f7ca20bf40b911c035264d86ef0359d20e7ac88? appears several times: git rev-parse --all 4f7ca20bf40b911c035264d86ef0359d20e7ac88 4f7ca20bf40b911c035264d86ef0359d20e7ac88 4f7ca20bf40b911c035264d86ef0359d20e7ac88 f49cbc1f2503f737a96296993133aec065910935 4f7ca20bf40b911c035264d86ef0359d20e7ac88 3aa065ac48f21ce7c4d0879686fb07b04a60771f 45c13574ff89e3139567943e6a6cae82e754eab0 0febfc567d3f9441811a5490f0ea4d960798d313 Compiling ?4f7ca20bf40b911c035264d86ef0359d20e7ac88? results in a not working firmware, even so the changes (PPS changes from Harald) are all correct. (I applied these changes to the v0.4 firmware (revision ebf16b4ddf0dcbadf96aebdec3304f703917fdc7) and it works all nicely.) Could somebody have a look ... Regards, Ben From myonium at gmail.com Thu Feb 16 21:54:12 2012 From: myonium at gmail.com (Myonium) Date: Thu, 16 Feb 2012 22:54:12 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <4F3B856D.1050409@freyther.de> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> Message-ID: <9360E2F0-3914-4CDC-99E6-4A4E295A32DB@gmail.com> 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 From peter at stuge.se Thu Feb 16 23:11:14 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 17 Feb 2012 00:11:14 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> Message-ID: <20120216231114.3219.qmail@stuge.se> 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 From peter at stuge.se Thu Feb 16 23:15:36 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 17 Feb 2012 00:15:36 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <9360E2F0-3914-4CDC-99E6-4A4E295A32DB@gmail.com> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> <9360E2F0-3914-4CDC-99E6-4A4E295A32DB@gmail.com> Message-ID: <20120216231536.3542.qmail@stuge.se> 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 From myonium at gmail.com Sat Feb 18 10:12:13 2012 From: myonium at gmail.com (Myonium) Date: Sat, 18 Feb 2012 11:12:13 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <20120216231114.3219.qmail@stuge.se> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> <20120216231114.3219.qmail@stuge.se> Message-ID: <5434FE82-9A42-4876-94BC-1D1B6DF49C69@gmail.com> 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 > From peter at stuge.se Sat Feb 18 19:18:33 2012 From: peter at stuge.se (Peter Stuge) Date: Sat, 18 Feb 2012 20:18:33 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <5434FE82-9A42-4876-94BC-1D1B6DF49C69@gmail.com> References: <6535E9FD-73C7-4E63-8A53-AAD9579B20D0@gmail.com> <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> <20120216231114.3219.qmail@stuge.se> <5434FE82-9A42-4876-94BC-1D1B6DF49C69@gmail.com> Message-ID: <20120218191833.17427.qmail@stuge.se> 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 From laforge at gnumonks.org Sat Feb 18 23:38:03 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 19 Feb 2012 00:38:03 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <20120218191833.17427.qmail@stuge.se> References: <20120212100456.GX1898@prithivi.gnumonks.org> <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> <20120216231114.3219.qmail@stuge.se> <5434FE82-9A42-4876-94BC-1D1B6DF49C69@gmail.com> <20120218191833.17427.qmail@stuge.se> Message-ID: <20120218233803.GX3026@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Sat Feb 18 23:57:45 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 00:57:45 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <20120218233803.GX3026@prithivi.gnumonks.org> References: <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> <20120216231114.3219.qmail@stuge.se> <5434FE82-9A42-4876-94BC-1D1B6DF49C69@gmail.com> <20120218191833.17427.qmail@stuge.se> <20120218233803.GX3026@prithivi.gnumonks.org> Message-ID: <20120218235746.7728.qmail@stuge.se> Harald Welte wrote: > > 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 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 From peter at stuge.se Sun Feb 19 00:02:44 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 01:02:44 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <20120218235746.7728.qmail@stuge.se> References: <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> <20120216231114.3219.qmail@stuge.se> <5434FE82-9A42-4876-94BC-1D1B6DF49C69@gmail.com> <20120218191833.17427.qmail@stuge.se> <20120218233803.GX3026@prithivi.gnumonks.org> <20120218235746.7728.qmail@stuge.se> Message-ID: <20120219000244.8112.qmail@stuge.se> 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 From 246tnt at gmail.com Sun Feb 19 09:03:30 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 19 Feb 2012 10:03:30 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: <20120219000244.8112.qmail@stuge.se> References: <20120212142241.GG1898@prithivi.gnumonks.org> <20120212144204.GH1898@prithivi.gnumonks.org> <4F3B856D.1050409@freyther.de> <20120216231114.3219.qmail@stuge.se> <5434FE82-9A42-4876-94BC-1D1B6DF49C69@gmail.com> <20120218191833.17427.qmail@stuge.se> <20120218233803.GX3026@prithivi.gnumonks.org> <20120218235746.7728.qmail@stuge.se> <20120219000244.8112.qmail@stuge.se> Message-ID: Hi On Sun, Feb 19, 2012 at 1:02 AM, Peter Stuge wrote: > 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. Are FIQ disabled as well ? Or could we move uart RX to fiq ? Cheers, Sylvain From laforge at gnumonks.org Sun Feb 19 11:50:05 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 19 Feb 2012 12:50:05 +0100 Subject: Printing Fi/Di values from simtrace host tool (PPS) In-Reply-To: References: <4F3B856D.1050409@freyther.de> <20120216231114.3219.qmail@stuge.se> <5434FE82-9A42-4876-94BC-1D1B6DF49C69@gmail.com> <20120218191833.17427.qmail@stuge.se> <20120218233803.GX3026@prithivi.gnumonks.org> <20120218235746.7728.qmail@stuge.se> <20120219000244.8112.qmail@stuge.se> Message-ID: <20120219115005.GZ3026@prithivi.gnumonks.org> 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 wrote: > > 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. > > Are FIQ disabled as well ? Or could we move uart RX to fiq ? 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From lists at kaiser.cx Sun Feb 19 18:31:46 2012 From: lists at kaiser.cx (Martin Kaiser) Date: Sun, 19 Feb 2012 19:31:46 +0100 Subject: 1.1p board not recognized In-Reply-To: <20120216122956.GA25933@viti.kaiser.cx> References: <20120215224323.GA5825@viti.kaiser.cx> <20120216074142.GI15803@prithivi.gnumonks.org> <20120216122956.GA25933@viti.kaiser.cx> Message-ID: <20120219183146.GA9522@viti.kaiser.cx> Hi, here's an update about my struggle to get the board working. On one of my boxes, using Debian lenny, the board is not recognized at all, regardless of the mode. On a debian squeeze box, it looks like there's 3 scenarios - the board is recognized by USB in "runtime mode", this only works when there's no phone and no sim connected. The red led is on in the case. - when I connect a phone and sim, the board is not recognized at all. The red led remains off. - the board is recognized by USB in dfu mode I tried updating the firmware, this time I used a main_simtrace.bin that I compiled myself root at skogar:~# dfu-util -d 16c0:0762 -a0 -D ./main_simtrace.bin -R dfu-util - (C) 2007-2008 by OpenMoko Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY dfu-util does currently only support DFU version 1.0 Opening USB Device 0x16c0:0x0762... Found Runtime: [0x16c0:0x0762] devnum=2, cfg=0, intf=0, alt=0, name="SimTrace DFU Interface - Application Partition" Claiming USB DFU Interface... Setting Alternate Setting #0 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing Transfer Size = 0x0100 bytes_per_hash=416 Starting download: [##################################################] finished! state(7) = dfuMANIFEST, status(0) = No error condition is present state(2) = dfuIDLE, status(0) = No error condition is present Done! can't detach: error sending control message: Broken pipe Resetting USB to switch back to runtime mode I'm not sure if that is a successful update, though. The board comes up in runtime mode but stops working when phone/sim are connected. - I tried activating the sam-ba mode by following the steps in http://bb.osmocom.org/trac/wiki/SIMtrace/Firmware This does not work at all, the board remains in (non-working) runtime mode, it does not come up in sam-ba mode. Any more ideas? Thanks, best regards, Martin From laforge at gnumonks.org Sun Feb 19 19:14:44 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 19 Feb 2012 20:14:44 +0100 Subject: 1.1p board not recognized In-Reply-To: <20120219183146.GA9522@viti.kaiser.cx> References: <20120215224323.GA5825@viti.kaiser.cx> <20120216074142.GI15803@prithivi.gnumonks.org> <20120216122956.GA25933@viti.kaiser.cx> <20120219183146.GA9522@viti.kaiser.cx> Message-ID: <20120219191444.GE3026@prithivi.gnumonks.org> Hi Martin, On Sun, Feb 19, 2012 at 07:31:46PM +0100, Martin Kaiser wrote: > here's an update about my struggle to get the board working. I really think you should return the board to sysmocom, we will have a look at it and either send back a new one (likely) or try to repair it, depending on the problem. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)