From holger at freyther.de Mon Oct 3 10:26:14 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 03 Oct 2011 12:26:14 +0200 Subject: simtrace on Mac OSX In-Reply-To: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> Message-ID: <4E898DC6.7080601@freyther.de> On 09/29/2011 09:39 PM, Myonium wrote: > Hi > > I tried SIMTrace with Gemalto java smart cards and it is working great. Hi, just a blind guess, at the Camp we had one or two reports that the device does not properly enumerate on a USB 3.0 port. Could this apply? From holger at freyther.de Mon Oct 3 15:12:26 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 03 Oct 2011 17:12:26 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E898DC6.7080601@freyther.de> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> Message-ID: <4E89D0DA.5010901@freyther.de> On 10/03/2011 12:26 PM, Holger Hans Peter Freyther wrote: > just a blind guess, at the Camp we had one or two reports that the device does > not properly enumerate on a USB 3.0 port. Could this apply? FYI: I tried on a mac (lion) and I can confirm this issue. Will try to play wit that tomorrow. From peter at stuge.se Mon Oct 3 17:41:24 2011 From: peter at stuge.se (Peter Stuge) Date: Mon, 3 Oct 2011 19:41:24 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E89D0DA.5010901@freyther.de> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> <4E89D0DA.5010901@freyther.de> Message-ID: <20111003174124.10819.qmail@stuge.se> Holger Hans Peter Freyther wrote: > On 10/03/2011 12:26 PM, Holger Hans Peter Freyther wrote: > > > just a blind guess, at the Camp we had one or two reports that > > the device does not properly enumerate on a USB 3.0 port. Could > > this apply? > > FYI: I tried on a mac (lion) and I can confirm this issue. Will try > to play wit that tomorrow. Mac OS is really really strict about USB descriptors being correct, where both Windows and Linux are more lenient. But the error messages say the device would not even accept the address it was assigned, so there is some more fundamental problem with the USB firmware. :\ //Peter From holger at freyther.de Mon Oct 3 18:17:00 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 03 Oct 2011 20:17:00 +0200 Subject: simtrace on Mac OSX In-Reply-To: <20111003174124.10819.qmail@stuge.se> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> <4E89D0DA.5010901@freyther.de> <20111003174124.10819.qmail@stuge.se> Message-ID: <4E89FC1C.9090405@freyther.de> On 10/03/2011 07:41 PM, Peter Stuge wrote: > Mac OS is really really strict about USB descriptors being correct, > where both Windows and Linux are more lenient. But the error messages > say the device would not even accept the address it was assigned, so > there is some more fundamental problem with the USB firmware. :\ any debug hints? it will be my first real adventure into the USB land. Right now I would just play trial and error to see how far in the setup things go. :) From peter at stuge.se Mon Oct 3 18:29:17 2011 From: peter at stuge.se (Peter Stuge) Date: Mon, 3 Oct 2011 20:29:17 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E89FC1C.9090405@freyther.de> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> <4E89D0DA.5010901@freyther.de> <20111003174124.10819.qmail@stuge.se> <4E89FC1C.9090405@freyther.de> Message-ID: <20111003182917.17623.qmail@stuge.se> Holger Hans Peter Freyther wrote: > > Mac OS is really really strict about USB descriptors being correct, > > where both Windows and Linux are more lenient. But the error messages > > say the device would not even accept the address it was assigned, so > > there is some more fundamental problem with the USB firmware. :\ > > any debug hints? it will be my first real adventure into the USB > land. Right now I would just play trial and error to see how far in > the setup things go. The device address being assigned by the PC is very very early in the USB enumeration (device discovery after plug-in) process, so something goes wrong pretty early. I understood that the firmware is based on an example firmware from Atmel, so maybe look around their developer resources for any info about known problems with Mac OS. I would probably add some serial output to the firmware in main() and in the USB interrupt handler, and try to see what differs between Mac OS and other systems during enumeration. I recall Harald mentioned an interrupt storm in some circumstances, this could also cause the device address assignment to fail if it isn't fixed already. //Peter From lukash at backstep.net Mon Oct 3 19:47:19 2011 From: lukash at backstep.net (Lukas Kuzmiak) Date: Mon, 3 Oct 2011 21:47:19 +0200 Subject: simtrace on Mac OSX In-Reply-To: <20111003182917.17623.qmail@stuge.se> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> <4E89D0DA.5010901@freyther.de> <20111003174124.10819.qmail@stuge.se> <4E89FC1C.9090405@freyther.de> <20111003182917.17623.qmail@stuge.se> Message-ID: Hey, I can confirm this problem on my fresh OS X 10.7 (Lion) installation. The IRQ storm bug you're referring to was caused by TCK byte difference between T=1 and T=0 protocols and has been fixed in firmware 0.2 ( http://laforge.gnumonks.org/weblog/2011/08/16/). This however should not be related I guess as if you connect the simtrace without a phone and simcard attached to it, this bug should not trigger (correct me if i'm wrong). to debugging: you can use a serial cable connected to the 2.5" jack (something like FTDI based one for osmocom motorola phones if you have one) - that's the debugging interface. I'm currently travelling and don't have my usb->serial cable with me so I will check back at home. Cheers, Lukas On Mon, Oct 3, 2011 at 8:29 PM, Peter Stuge wrote: > Holger Hans Peter Freyther wrote: > > > Mac OS is really really strict about USB descriptors being correct, > > > where both Windows and Linux are more lenient. But the error messages > > > say the device would not even accept the address it was assigned, so > > > there is some more fundamental problem with the USB firmware. :\ > > > > any debug hints? it will be my first real adventure into the USB > > land. Right now I would just play trial and error to see how far in > > the setup things go. > > The device address being assigned by the PC is very very early in the > USB enumeration (device discovery after plug-in) process, so > something goes wrong pretty early. > > I understood that the firmware is based on an example firmware from > Atmel, so maybe look around their developer resources for any info > about known problems with Mac OS. > > I would probably add some serial output to the firmware in main() and > in the USB interrupt handler, and try to see what differs between Mac > OS and other systems during enumeration. > > I recall Harald mentioned an interrupt storm in some circumstances, > this could also cause the device address assignment to fail if it > isn't fixed already. > > > //Peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukash at backstep.net Mon Oct 3 22:35:02 2011 From: lukash at backstep.net (Lukas Kuzmiak) Date: Tue, 4 Oct 2011 00:35:02 +0200 Subject: simtrace on Mac OSX In-Reply-To: References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> <4E89D0DA.5010901@freyther.de> <20111003174124.10819.qmail@stuge.se> <4E89FC1C.9090405@freyther.de> <20111003182917.17623.qmail@stuge.se> Message-ID: I've managed to get the serial traces: *Linux trace on latest firmware (works fine):* (C) 2006-2011 by Harald Welte This software is FREE SOFTWARE licensed under GNU GPL Version 0.1.12-fa72 compiled 20110815-230016 by laforge at nataraja.de.gnumonks.org DEBUG Interface: 0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2 9) Reset RSTC_SR=0x00010200 Inititalizing usbcmd_gen_init udp_open(437): entering USART Initializing pio_irq_register(109): registering handler 0010777c for PIOA 7 ISO_SW Initializing pio_irq_register(109): registering handler 00107c00 for PIOA 8 pio_irq_register(109): registering handler 00107af4 for PIOA 30 USART Entering Rx Mode RST computed Fi(1) Di(1) ratio: 372 MODE: SNIFFER main(76): entering main (idle) loop *Mac OS X 10.7 Lion trace (repeats itself over and over and over (red led blinks every time it resets)):* (C) 2006-2011 by Harald Welte This software is FREE SOFTWARE licensed under GNU GPL Version 0.1.12-fa72 compiled 20110815-230016 by laforge at nataraja.de.gnumonks.org DEBUG Interface: 0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2 9) Reset RSTC_SR=0x00010200 Inititalizing usbcmd_gen_init udp_open(437): entering USART Initializing pio_irq_register(109): registering handler 0010777c for PIOA 7 __pio_irq_demux(43): PIO_ISR_STATUS = 0xffffffff RST computed Fi(1) Di(1) ratio: 372 ISO_SW Initializing pio_irq_register(109): registering handler 00107c00 for PIOA 8 pio_irq_register(109): registering handler 00107af4 for PIOA 30 USART Entering Rx Mode RST computed Fi(1) Di(1) ratio: 372 MODE: SNIFFER main(76): entering main (idle) loop Problem is obviously somewhere in the beginning, Mac OS X trace has these 3 lines more than Linux: __pio_irq_demux(43): PIO_ISR_STATUS = 0xffffffff RST computed Fi(1) Di(1) ratio: 372 I honestly don't know what could be the problem here but perhaps this can lead someone to an idea :) Lukas On Mon, Oct 3, 2011 at 9:47 PM, Lukas Kuzmiak wrote: > Hey, > > I can confirm this problem on my fresh OS X 10.7 (Lion) installation. > > The IRQ storm bug you're referring to was caused by TCK byte difference > between T=1 and T=0 protocols and has been fixed in firmware 0.2 ( > http://laforge.gnumonks.org/weblog/2011/08/16/). > This however should not be related I guess as if you connect the simtrace > without a phone and simcard attached to it, this bug should not trigger > (correct me if i'm wrong). > > to debugging: you can use a serial cable connected to the 2.5" jack > (something like FTDI based one for osmocom motorola phones if you have one) > - that's the debugging interface. I'm currently travelling and don't have my > usb->serial cable with me so I will check back at home. > > Cheers, > Lukas > > On Mon, Oct 3, 2011 at 8:29 PM, Peter Stuge wrote: > >> Holger Hans Peter Freyther wrote: >> > > Mac OS is really really strict about USB descriptors being correct, >> > > where both Windows and Linux are more lenient. But the error messages >> > > say the device would not even accept the address it was assigned, so >> > > there is some more fundamental problem with the USB firmware. :\ >> > >> > any debug hints? it will be my first real adventure into the USB >> > land. Right now I would just play trial and error to see how far in >> > the setup things go. >> >> The device address being assigned by the PC is very very early in the >> USB enumeration (device discovery after plug-in) process, so >> something goes wrong pretty early. >> >> I understood that the firmware is based on an example firmware from >> Atmel, so maybe look around their developer resources for any info >> about known problems with Mac OS. >> >> I would probably add some serial output to the firmware in main() and >> in the USB interrupt handler, and try to see what differs between Mac >> OS and other systems during enumeration. >> >> I recall Harald mentioned an interrupt storm in some circumstances, >> this could also cause the device address assignment to fail if it >> isn't fixed already. >> >> >> //Peter >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Tue Oct 4 09:26:19 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 11:26:19 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E89FC1C.9090405@freyther.de> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> <4E89D0DA.5010901@freyther.de> <20111003174124.10819.qmail@stuge.se> <4E89FC1C.9090405@freyther.de> Message-ID: <4E8AD13B.7080809@freyther.de> On 10/03/2011 08:17 PM, Holger Hans Peter Freyther wrote: > any debug hints? it will be my first real adventure into the USB land. Right > now I would just play trial and error to see how far in the setup things go. I have a first hypothesis/guess... I think we transmit debug messages on EP3 before the device is configured. From holger at freyther.de Tue Oct 4 09:33:09 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 11:33:09 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E8AD13B.7080809@freyther.de> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> <4E89D0DA.5010901@freyther.de> <20111003174124.10819.qmail@stuge.se> <4E89FC1C.9090405@freyther.de> <4E8AD13B.7080809@freyther.de> Message-ID: <4E8AD2D5.6050808@freyther.de> On 10/04/2011 11:26 AM, Holger Hans Peter Freyther wrote: > On 10/03/2011 08:17 PM, Holger Hans Peter Freyther wrote: > I have a first hypothesis/guess... I think we transmit debug messages on EP3 > before the device is configured. > wrong conclusion from looking at wireshark. :) From holger at freyther.de Tue Oct 4 09:44:29 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 11:44:29 +0200 Subject: simtrace on Mac OSX In-Reply-To: <20111003182917.17623.qmail@stuge.se> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> <4E89D0DA.5010901@freyther.de> <20111003174124.10819.qmail@stuge.se> <4E89FC1C.9090405@freyther.de> <20111003182917.17623.qmail@stuge.se> Message-ID: <4E8AD57D.8020309@freyther.de> On 10/03/2011 08:29 PM, Peter Stuge wrote: > I recall Harald mentioned an interrupt storm in some circumstances, > this could also cause the device address assignment to fail if it > isn't fixed already. This was related to the UART code, but yes looking at the serial output i see: RSTC_SR=0x00010200 SRCMP: 1 == Software reset in progress RSTTYP: 2 == Watchdog reset so it is stuck somewhere. time to get a USBJtag adapter.. :) From holger at freyther.de Tue Oct 4 10:48:58 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 12:48:58 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E8AD57D.8020309@freyther.de> References: <10D28ABA-BBAE-44EB-BA2E-76029211590E@gmail.com> <4E898DC6.7080601@freyther.de> <4E89D0DA.5010901@freyther.de> <20111003174124.10819.qmail@stuge.se> <4E89FC1C.9090405@freyther.de> <20111003182917.17623.qmail@stuge.se> <4E8AD57D.8020309@freyther.de> Message-ID: <4E8AE49A.4010908@freyther.de> On 10/04/2011 11:44 AM, Holger Hans Peter Freyther wrote: > SRCMP: 1 == Software reset in progress > RSTTYP: 2 == Watchdog reset > > so it is stuck somewhere. time to get a USBJtag adapter.. :) > Hi, I am lacking USB and AT7SAM knowledge here. I made the debug output synchronous and managed to get here: udp_irq(imr=0x1200, isr=0x0300, state=5): RXSUSP RXRSM END udp_irq(imr=0x1200, isr=0x1000, state=5): ENDBUSRES END udp_irq(imr=0x1203, isr=0x0801, state=5): EP0INT(Control) CSR=0x88804 len=8 bmRequestType=0x80 DATA_IN=1 dfu_state = 0 GET_DESCRIPTOR(wValue=0x0100, wIndex=0x0000) OUT So this means that we at least get a USB request to get our descriptor, and asking for USB_DT_DEVICE. The call is made to: udp_ep0_send_data((const char *) &dev_descriptor, MIN(sizeof(dev_descriptor), wLength)); and it is getting stuck in: udp_ep0_send_zlp(void) { AT91PS_UDP pUdp = AT91C_BASE_UDP; pUdp->UDP_CSR[0] |= AT91C_UDP_TXPKTRDY; while (!(pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP)) ; ^^^^ sending never completes Anyone has a guess? I am going to start to read the Atmel docs now. From spaar at mirider.augusta.de Tue Oct 4 13:34:49 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 04 Oct 2011 13:34:49 CEST Subject: simtrace on Mac OSX Message-ID: <4e8b0b79.mirider@mirider.augusta.de> Hello Holger, On Tue, 04 Oct 2011 12:48:58 +0200, "Holger Hans Peter Freyther" wrote: > > Anyone has a guess? I am going to start to read the Atmel docs now. I don't have time to debug this issue, but a USB Analyzer trace clearly shows that the SET ADDRESS command goes wrong. My guess: The only difference between the Windows and MacOS X trace is a USB Reset between the GET DESCRIPTOR and SET ADDRESS command on Windows, the Reset is not there on MacOS X (don't know what Linux does). So I would look if "upcd.state" is USB_STATE_DEFAULT, if not STD_SET_ADDRESS won't do anything. From my understanding "upcd.state" is set to USB_STATE_DEFAULT on a USB Reset, so it might not be initialized properly. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From holger at freyther.de Tue Oct 4 12:37:09 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 14:37:09 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4e8b0b79.mirider@mirider.augusta.de> References: <4e8b0b79.mirider@mirider.augusta.de> Message-ID: <4E8AFDF5.1010608@freyther.de> On 10/04/2011 01:34 PM, Dieter Spaar wrote: > Hello Holger, > I don't have time to debug this issue, but a USB Analyzer trace clearly > shows that the SET ADDRESS command goes wrong. I thought harald had fixed the issues your USB Analyzer complained about? > My guess: The only difference between the Windows and MacOS X trace is > a USB Reset between the GET DESCRIPTOR and SET ADDRESS command on Windows, > the Reset is not there on MacOS X (don't know what Linux does). yes, the firmware 'stalls' in: while (!(pUdp->UDP_CSR[0] & AT91C_UDP_TXPKTRDY)) for sending a zero length packet... (which is after/part of the GET DESCRIPTOR) response. I think it is from an interrupt handler and maybe we need to check if the transfer has been canceled? > look if "upcd.state" is USB_STATE_DEFAULT, if not STD_SET_ADDRESS won't do > anything. From my understanding "upcd.state" is set to USB_STATE_DEFAULT > on a USB Reset, so it might not be initialized properly. will do, but I think we are stuck in the interrupt handler. From spaar at mirider.augusta.de Tue Oct 4 14:46:47 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 04 Oct 2011 14:46:47 CEST Subject: simtrace on Mac OSX Message-ID: <4e8b1c57.mirider@mirider.augusta.de> Hello Holger, On Tue, 04 Oct 2011 14:37:09 +0200, "Holger Hans Peter Freyther" wrote: > > I thought harald had fixed the issues your USB Analyzer complained about? This was a completly different issue, it was not related to the USB behaviour on MacOS X. > for sending a zero length packet... (which is after/part of the GET > DESCRIPTOR) response. I think it is from an interrupt handler and maybe we > need to check if the transfer has been canceled? The GET DESCRIPTOR request is working fine including the response from the device, the problem is that there is no repsonse on the SET ADDRESS request. > will do, but I think we are stuck in the interrupt handler. As a quick check I would just remove the test for the state when handling SET ADDRESS and see if this helps. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From holger at freyther.de Tue Oct 4 12:58:49 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 14:58:49 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4e8b1c57.mirider@mirider.augusta.de> References: <4e8b1c57.mirider@mirider.augusta.de> Message-ID: <4E8B0309.3090707@freyther.de> On 10/04/2011 02:46 PM, Dieter Spaar wrote: > Hello Holger, >> for sending a zero length packet... (which is after/part of the GET >> DESCRIPTOR) response. I think it is from an interrupt handler and maybe we >> need to check if the transfer has been canceled? > > The GET DESCRIPTOR request is working fine including the response from the > device, the problem is that there is no repsonse on the SET ADDRESS request. > >> will do, but I think we are stuck in the interrupt handler. > > As a quick check I would just remove the test for the state when handling > SET ADDRESS and see if this helps. Hi Dieter, I am not using JTAG to debug so my view i have might be limited. I have put DEBUG_UNBUFFERD in the codepath. So from the messages I print to the serial. With my current information I would claim the firmware does not see the SET ADDRESS (i assume the zpl method needs to check the ISR of the UDP) frame 0> udp_ep0_send_zlp frame 1> udp_ep0_send_data frame 2> udp_ep0_handler frame 3> udp_irq Please don't feel urged to look into it, I quite enjoy learning about USB this way. :) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From holger at freyther.de Tue Oct 4 13:23:37 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 15:23:37 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E8B0309.3090707@freyther.de> References: <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> Message-ID: <4E8B08D9.8050204@freyther.de> On 10/04/2011 02:58 PM, Holger Hans Peter Freyther wrote: > frame 0> udp_ep0_send_zlp > frame 1> udp_ep0_send_data > frame 2> udp_ep0_handler > frame 3> udp_irq Okay, I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending a ZPL for every thing length % 8 == 0 and the device started to work on OSX. I assume we will need to look at the USB spec. :) From spaar at mirider.augusta.de Tue Oct 4 15:26:44 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 04 Oct 2011 15:26:44 CEST Subject: simtrace on Mac OSX Message-ID: <4e8b25b4.mirider@mirider.augusta.de> Hello Holger, On Tue, 04 Oct 2011 14:58:49 +0200, "Holger Hans Peter Freyther" wrote: > > I am not using JTAG to debug so my view i have might be limited. I have put > DEBUG_UNBUFFERD in the codepath. So from the messages I print to the serial. I don't recommend debugging USB issues with JTAG anyway because it might chance the behaviour of the device. > With my current information I would claim the firmware does not see the SET > ADDRESS (i assume the zpl method needs to check the ISR of the UDP) > > frame 0> udp_ep0_send_zlp > frame 1> udp_ep0_send_data > frame 2> udp_ep0_handler > frame 3> udp_irq I can only judge from the trace and using the prebuilt firmware v0.2.2, in this case the GET DESCRIPTOR request is completed, the SET ADDRESS request comes in, is ACKed and no response from the device is sent back when the IN packet from the host arrives. Have you tried to modify the SET ADDRESS handling already ? > Please don't feel urged to look into it, I quite enjoy learning about USB this > way. :) I don't have a working setup here for building the simtrace firmware, so far I only used prebuilt version. So I can't do much and I currently don't have the time to go through the process of creating the build-environment. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From holger at freyther.de Tue Oct 4 14:12:42 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 16:12:42 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E8B08D9.8050204@freyther.de> References: <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> Message-ID: <4E8B145A.8080204@freyther.de> On 10/04/2011 03:23 PM, Holger Hans Peter Freyther wrote: > On 10/04/2011 02:58 PM, Holger Hans Peter Freyther wrote: > Okay, > I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending a ZPL > for every thing length % 8 == 0 and the device started to work on OSX. I > assume we will need to look at the USB spec. :) > I have uploaded alternative firmware for OSX[1] and the 'diff' to revert the above commit. I have to read when to and when not to send a ZPL. [1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/Firmware/ From lukash at backstep.net Tue Oct 4 14:29:09 2011 From: lukash at backstep.net (Lukas Kuzmiak) Date: Tue, 4 Oct 2011 16:29:09 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E8B145A.8080204@freyther.de> References: <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <4E8B145A.8080204@freyther.de> Message-ID: Well done! I'll try it out in the evening and let you know, I think as it's known where the problem is now it won't be hard to find out if there's a mistake with ZPL and how to fix it to have one FW :) Lukas On Tue, Oct 4, 2011 at 4:12 PM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On 10/04/2011 03:23 PM, Holger Hans Peter Freyther wrote: > > On 10/04/2011 02:58 PM, Holger Hans Peter Freyther wrote: > > > Okay, > > I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending > a ZPL > > for every thing length % 8 == 0 and the device started to work on OSX. I > > assume we will need to look at the USB spec. :) > > > > I have uploaded alternative firmware for OSX[1] and the 'diff' to revert > the > above commit. I have to read when to and when not to send a ZPL. > > > [1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/Firmware/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spaar at mirider.augusta.de Tue Oct 4 16:43:28 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 04 Oct 2011 16:43:28 CEST Subject: simtrace on Mac OSX Message-ID: <4e8b37b0.mirider@mirider.augusta.de> Hello Holger, On Tue, 04 Oct 2011 16:12:42 +0200, "Holger Hans Peter Freyther" wrote: > > I have uploaded alternative firmware for OSX[1] and the 'diff' to revert the > above commit. I have to read when to and when not to send a ZPL. Have a look at the requested size from the host, only when the host requests more data than available, the ZLP is needed (if the size sent is an exact multiple of the endpoint size). In my traces I can see that Windows request 64 bytes for the first GET DESCRIPTOR which is only 8 bytes long (so a ZPL should be sent). MacOS X requests 8 bytes, so no ZLP is needed. I still believe there is another issue which will cause problems if a USB Reset is missing between the first GET DESCRIPTOR and the SET ADDRESS request, which I could observe here with my MacOS X installation (an older one from a year ago). Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From holger at freyther.de Tue Oct 4 14:49:37 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 16:49:37 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4e8b37b0.mirider@mirider.augusta.de> References: <4e8b37b0.mirider@mirider.augusta.de> Message-ID: <4E8B1D01.7010309@freyther.de> On 10/04/2011 04:43 PM, Dieter Spaar wrote: > Have a look at the requested size from the host, only when the host > requests more data than available, the ZLP is needed (if the size sent > is an exact multiple of the endpoint size). ahhh. maybe I find something in the USB 2.0 specification about that part now. Thanks for your input! From holger at freyther.de Tue Oct 4 14:54:47 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 16:54:47 +0200 Subject: simtrace on Mac OSX In-Reply-To: References: <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <4E8B145A.8080204@freyther.de> Message-ID: <4E8B1E37.9030106@freyther.de> On 10/04/2011 04:43 PM, Sylvain Munaut wrote: > Where is the firmware hosted btw ? The link on the SIMtrace/Firmware > page is broken ... $ git clone git://git.gnumonks.org/openpcd.git gitdaemon runs, gitweb on gnumonks does not show it though. I mailed harald about it (asking for sam7 utils as well). holger From spaar at mirider.augusta.de Tue Oct 4 17:11:38 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 04 Oct 2011 17:11:38 CEST Subject: simtrace on Mac OSX Message-ID: <4e8b3e4a.mirider@mirider.augusta.de> Hello Holger, On Tue, 04 Oct 2011 16:49:37 +0200, "Holger Hans Peter Freyther" wrote: > > ahhh. maybe I find something in the USB 2.0 specification about that part now. > Thanks for your input! "8.5.3.2 Variable-length Data Stage" Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From 246tnt at gmail.com Tue Oct 4 14:43:39 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 4 Oct 2011 16:43:39 +0200 Subject: simtrace on Mac OSX In-Reply-To: References: <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <4E8B145A.8080204@freyther.de> Message-ID: Where is the firmware hosted btw ? The link on the SIMtrace/Firmware page is broken ... >> [1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/Firmware/ Cheers, Sylvain From holger at freyther.de Tue Oct 4 15:25:01 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 17:25:01 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4e8b3e4a.mirider@mirider.augusta.de> References: <4e8b3e4a.mirider@mirider.augusta.de> Message-ID: <4E8B254D.1020906@freyther.de> On 10/04/2011 05:11 PM, Dieter Spaar wrote: > > "8.5.3.2 Variable-length Data Stage" and 9.4.3 Get Descriptor. What is a Control Pipe? The 'reserved bandwidth/window' for a control request? From spaar at mirider.augusta.de Tue Oct 4 17:36:41 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 04 Oct 2011 17:36:41 CEST Subject: simtrace on Mac OSX Message-ID: <4e8b4429.mirider@mirider.augusta.de> Hello Holger, On Tue, 04 Oct 2011 17:25:01 +0200, "Holger Hans Peter Freyther" wrote: > > and 9.4.3 Get Descriptor. Its the same rule, all the standard device requests are Control Transfers as described in 8.5.3. > What is a Control Pipe? The 'reserved bandwidth/window' for a control > request? Shall I repeat "Terms and Abbreviations" from the specification ;-) ? Control Pipe: Same as a message pipe. Message Pipe: A bi-directional pipe that transfers data using a request/data/status paradigm. The data has an imposed structure that allows requests to be reliably identified and communicated Think about the Control Pipe as the mechanism which transports the Control Transfers and a such the standard device requests. You can also put your own requests there (vendor specific requests). Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From peter at stuge.se Tue Oct 4 17:54:13 2011 From: peter at stuge.se (Peter Stuge) Date: Tue, 4 Oct 2011 19:54:13 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E8B254D.1020906@freyther.de> <4E8B08D9.8050204@freyther.de> References: <4e8b3e4a.mirider@mirider.augusta.de> <4E8B254D.1020906@freyther.de> <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> Message-ID: <20111004175413.12670.qmail@stuge.se> Holger Hans Peter Freyther wrote: > I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added > sending a ZPL for every thing length % 8 == 0 and the device > started to work on OSX. I assume we will need to look at the USB > spec. :) I think that commit is mostly correct, it just overlooks the condition of total data length == requested length, in which case I think no zlp should be sent. Also, hard coding 8 as packet size is not awesome, the value used by the host for this is bMaxPacketSize0 in the device descriptor. (See 9.6.1) At least a define would be good, full-speed devices can choose value here. The same commit also exists earlier in the branch as 8cc090e310545f7858558f74116f707318daf682 with no merges in between. I'm not sure what happened there. Holger Hans Peter Freyther wrote: > > "8.5.3.2 Variable-length Data Stage" > > and 9.4.3 Get Descriptor. > > What is a Control Pipe? USB spec and Windows like to refer to pipes, I think it's a bit redundant, transfers to and from endpoints is good enough imo. :) //Peter From peter at stuge.se Tue Oct 4 18:01:56 2011 From: peter at stuge.se (Peter Stuge) Date: Tue, 4 Oct 2011 20:01:56 +0200 Subject: simtrace on Mac OSX In-Reply-To: <20111004175413.12670.qmail@stuge.se> References: <4e8b3e4a.mirider@mirider.augusta.de> <4E8B254D.1020906@freyther.de> <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <20111004175413.12670.qmail@stuge.se> Message-ID: <20111004180156.13658.qmail@stuge.se> Peter Stuge wrote: > > I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 > > I think that commit is mostly correct, it just overlooks the > condition of total data length == requested length, in which case I > think no zlp should be sent. Make that total data length >= requested length //Peter From holger at freyther.de Tue Oct 4 18:17:00 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 04 Oct 2011 20:17:00 +0200 Subject: simtrace on Mac OSX In-Reply-To: <20111004175413.12670.qmail@stuge.se> References: <4e8b3e4a.mirider@mirider.augusta.de> <4E8B254D.1020906@freyther.de> <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <20111004175413.12670.qmail@stuge.se> Message-ID: <4E8B4D9C.7040609@freyther.de> On 10/04/2011 07:54 PM, Peter Stuge wrote: > Holger Hans Peter Freyther wrote: >> I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added >> sending a ZPL for every thing length % 8 == 0 and the device >> started to work on OSX. I assume we will need to look at the USB >> spec. :) > > I think that commit is mostly correct, it just overlooks the > condition of total data length == requested length, in which case I > think no zlp should be sent. Also, hard coding 8 as packet size is > not awesome, the value used by the host for this is bMaxPacketSize0 > in the device descriptor. (See 9.6.1) At least a define would be > good, full-speed devices can choose value here. So 8.5.3.2 demands that if data.length is an exact multiple of wMaxPacketSize we need to send the ZPL. And 9.4.3 The wLength field specifies the number of bytes to return. If the descriptor is longer than the wLength field, only the initial bytes of the descriptor are returned. If the descriptor is shorter than the wLength field, the device indicates the end of the control transfer by sending a short packet when further data is requested. A short packet is defined as a packet shorter than the maximum payload size or a zero length data packet (refer to Chapter 5). How to put this together? I will try to tomorrow. So as Peter points out we should not send a ZPL if we sent wLength byte but it also happens to be a multiple of wMaxPacketSize? From peter at stuge.se Tue Oct 4 18:33:31 2011 From: peter at stuge.se (Peter Stuge) Date: Tue, 4 Oct 2011 20:33:31 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E8B4D9C.7040609@freyther.de> References: <4e8b3e4a.mirider@mirider.augusta.de> <4E8B254D.1020906@freyther.de> <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <20111004175413.12670.qmail@stuge.se> <4E8B4D9C.7040609@freyther.de> Message-ID: <20111004183331.18996.qmail@stuge.se> Holger Hans Peter Freyther wrote: > So 8.5.3.2 demands that if data.length is an exact multiple of > wMaxPacketSize we need to send the ZPL. It seems that this refers to control pipes other than the one involving endpoint 0, which is often refered to as the default control pipe. (It is mandatory by spec and endpoint 0 does not have an endpoint descriptor, so there is no wMaxPacketSize for endpoint 0. (See 9.6.6) For endpoint 0 this is instead stored in bMaxPacketSize0 in the device descriptor. Also, is data.length the length of the requested data, or is it the length that was requested? Note the difference. The requested data is e.g. the device descriptor. A device descriptor is always 18 bytes. (See 9.6.1) > And 9.4.3 > The wLength field specifies the number of bytes to return. If the > descriptor is longer than the wLength field, only the initial bytes > of the descriptor are returned. This is the case we hit on Mac OS. Since the requested data is longer (18) than the requested length (8) we must send no ZLP, only the first 8 bytes. Mac OS should follow up with another request for more data. > If the descriptor is shorter than the wLength field, the device > indicates the end of the control transfer by sending a short packet > when further data is requested. This case is what we hit on Windows, where 64 bytes are requested. > A short packet is defined as a packet shorter than the maximum > payload size or a zero length data packet (refer to Chapter 5). So for Windows we must also not send ZLP, because 18 bytes is already shorter than 64. Returning 18 bytes is sufficient to say that no more data is coming. > How to put this together? I will try to tomorrow. > So as Peter points out we should not send a ZPL if we sent wLength > byte but it also happens to be a multiple of wMaxPacketSize? Compare length of the descriptor with requested number of bytes. Only when more bytes are requested than the descriptor is long *and* when the descriptor is a multiple of the max packet size (bMaxPacketSize0 for ep0, wMaxPacketSize for the ep in the ep descriptor) then send ZLP. //Peter From spaar at mirider.augusta.de Tue Oct 4 20:43:17 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 04 Oct 2011 20:43:17 CEST Subject: simtrace on Mac OSX Message-ID: <4e8b6fe5.mirider@mirider.augusta.de> Hello Holger, On Tue, 04 Oct 2011 20:17:00 +0200, "Holger Hans Peter Freyther" wrote: > > So 8.5.3.2 demands that if data.length is an exact multiple of wMaxPacketSize > we need to send the ZPL. But only if less data than requested are sent ("A control pipe may have a variable-length data phase in which the host requests more data than is contained"). Its the same rule for GET DESCRIPTOR, no difference. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From laforge at gnumonks.org Thu Oct 6 07:54:12 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 6 Oct 2011 09:54:12 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E8B1E37.9030106@freyther.de> References: <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <4E8B145A.8080204@freyther.de> <4E8B1E37.9030106@freyther.de> Message-ID: <20111006075412.GL6845@prithivi.gnumonks.org> On Tue, Oct 04, 2011 at 04:54:47PM +0200, Holger Hans Peter Freyther wrote: > On 10/04/2011 04:43 PM, Sylvain Munaut wrote: > > Where is the firmware hosted btw ? The link on the SIMtrace/Firmware > > page is broken ... > > $ git clone git://git.gnumonks.org/openpcd.git > > gitdaemon runs, gitweb on gnumonks does not show it though. I mailed harald > about it (asking for sam7 utils as well). the gitweb is up and running again. I have no sam7utils repository, sorry. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Oct 6 08:04:22 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 06 Oct 2011 10:04:22 +0200 Subject: simtrace on Mac OSX In-Reply-To: <20111006075412.GL6845@prithivi.gnumonks.org> References: <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <4E8B145A.8080204@freyther.de> <4E8B1E37.9030106@freyther.de> <20111006075412.GL6845@prithivi.gnumonks.org> Message-ID: <4E8D6106.2080204@freyther.de> On 10/06/2011 09:54 AM, Harald Welte wrote: > > the gitweb is up and running again. I have no sam7utils repository, > sorry. Hi, do you think it makes sense to create one? It took me some time to figure out that it doesn't even connect to the device (or be able to have posix and usb backend in the same binary). I don't know the story about this utility, but IIRC I downloaded a tarball from openocd? holger From laforge at gnumonks.org Sat Oct 8 08:41:03 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 8 Oct 2011 10:41:03 +0200 Subject: simtrace on Mac OSX In-Reply-To: <4E8D6106.2080204@freyther.de> References: <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <4E8B145A.8080204@freyther.de> <4E8B1E37.9030106@freyther.de> <20111006075412.GL6845@prithivi.gnumonks.org> <4E8D6106.2080204@freyther.de> Message-ID: <20111008084103.GN27407@prithivi.gnumonks.org> Hi Holger, On Thu, Oct 06, 2011 at 10:04:22AM +0200, Holger Hans Peter Freyther wrote: > do you think it makes sense to create one? It took me some time to figure out > that it doesn't even connect to the device (or be able to have posix and usb > backend in the same binary). I don't know the story about this utility, but > IIRC I downloaded a tarball from openocd? I think the most current version of the tool (or an equivalent tool) is distributed by Atmel itself, somewhere hidden deep in their download links for the AT91SAM7-EK product. There are even two versions of it, one that uses the raw USB device (via libusb) and one that uses the ttyUSB* device generated by the kernel serial driver for the sam-ba bootloader usb device. Creating a git repo would probably make sense only if we actually had some changes/patcehs to that utility. 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 holger at freyther.de Sat Oct 8 08:53:43 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 08 Oct 2011 10:53:43 +0200 Subject: simtrace on Mac OSX In-Reply-To: <20111008084103.GN27407@prithivi.gnumonks.org> References: <4e8b1c57.mirider@mirider.augusta.de> <4E8B0309.3090707@freyther.de> <4E8B08D9.8050204@freyther.de> <4E8B145A.8080204@freyther.de> <4E8B1E37.9030106@freyther.de> <20111006075412.GL6845@prithivi.gnumonks.org> <4E8D6106.2080204@freyther.de> <20111008084103.GN27407@prithivi.gnumonks.org> Message-ID: <4E900F97.9040100@freyther.de> On 10/08/2011 10:41 AM, Harald Welte wrote: > Hi Holger, > > Creating a git repo would probably make sense only if we actually had > some changes/patcehs to that utility. I have a printf in case the device fails to open, and I would build both (posix, libusbb) backends into the same binary. It took me some minutes to figure out that -l /dev/ttyACM0 was just ignored. holger From holger at freyther.de Sun Oct 9 07:56:46 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 09 Oct 2011 09:56:46 +0200 Subject: Updated usermanual and 'streamlining' of the wiki content Message-ID: <4E9153BE.5080703@freyther.de> Hi all, I have updated the usermanual and provided a section on the Firmware itself (getting, building, programming). This was written at night so I would be very happy if someone could proof read or provide feedback in any other way. I have moved some content in the Wiki as well, everything that is related to Hardware should be in the Hardware article[2] and everything related to the Firmware should be in the Firmware article[3]. I tried hard to not lose any information. Again please take a look. holger [1] http://bb.osmocom.org/trac/raw-attachment/wiki/SIMtrace/usermanual.pdf [2] http://bb.osmocom.org/trac/wiki/SIMtrace/Hardware [3] http://bb.osmocom.org/trac/wiki/SIMtrace/Firmware From holger at freyther.de Sun Oct 9 16:16:09 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 09 Oct 2011 18:16:09 +0200 Subject: Updated usermanual and 'streamlining' of the wiki content In-Reply-To: References: <4E9153BE.5080703@freyther.de> Message-ID: <4E91C8C9.4050604@freyther.de> On 10/09/2011 06:10 PM, Sylvain Munaut wrote: > Maybe just mention the wireshark git on osmocom, which is easier if > you want more than the simtrace patch. Thanks, I plan to update simtrace builds and wireshark packages (also install them into another prefix, and rename it). I will update the docs in the same go then. holger From 246tnt at gmail.com Sun Oct 9 16:10:54 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 9 Oct 2011 18:10:54 +0200 Subject: Updated usermanual and 'streamlining' of the wiki content In-Reply-To: <4E9153BE.5080703@freyther.de> References: <4E9153BE.5080703@freyther.de> Message-ID: Hi, > I have updated the usermanual and provided a section on the Firmware itself > (getting, building, programming). This was written at night so I would be very > happy if someone could proof read or provide feedback in any other way. I did a quick read and it looks good to me. Maybe just mention the wireshark git on osmocom, which is easier if you want more than the simtrace patch. Also, I know than when building wireshark from that git, I have to use the './autogen.sh' that's in there instead of 'autoreconf -i'. I don't know if that applies to a wireshark-1.6 svn checkout as well ... Cheers, Sylvain From laforge at gnumonks.org Mon Oct 10 06:32:08 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 10 Oct 2011 08:32:08 +0200 Subject: Updated usermanual and 'streamlining' of the wiki content In-Reply-To: <4E91C8C9.4050604@freyther.de> References: <4E9153BE.5080703@freyther.de> <4E91C8C9.4050604@freyther.de> Message-ID: <20111010063208.GL27407@prithivi.gnumonks.org> Hi Holger, On Sun, Oct 09, 2011 at 06:16:09PM +0200, Holger Hans Peter Freyther wrote: > On 10/09/2011 06:10 PM, Sylvain Munaut wrote: > > > Maybe just mention the wireshark git on osmocom, which is easier if > > you want more than the simtrace patch. > > Thanks, I plan to update simtrace builds and wireshark packages (also install > them into another prefix, and rename it). I will update the docs in the same > go then. one alternative to offer full wireshark builds would be the conversion/wrapping of the simcard dissector as a plugin. I _believe_ the plugin API is quite stable even over many wireshark versions. but then, the same amount of time could probably be spent in making it more complete and submitting it mainline, instead. -- - 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 Fri Oct 21 18:10:34 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 21 Oct 2011 20:10:34 +0200 Subject: New bugfix firmware v0.3 release (fi/di calculation) Message-ID: <20111021181034.GE1745@prithivi.gnumonks.org> Hi! Thanks to Bjoern Kerler, we now have some bugfixes in fi/di calculation, which apparently was broken for cerain newer phones like the HTC Raphael or GT-S7070. If you had any problems regarding PPS/PTS and higher baud rates of the SIM card interface, feel free to try this new version. The source code can be found in openpcd.git as usual. Firmware can be installed into the application partition using dfu-util. -- - 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-v0.3.bin Type: application/octet-stream Size: 20844 bytes Desc: not available URL: