From kevredon at mail.tsaitgaist.info  Wed Nov  9 20:01:35 2011
From: kevredon at mail.tsaitgaist.info (Kevin Redon)
Date: Wed, 09 Nov 2011 21:01:35 +0100
Subject: class C (+1.8V) capabilities
Message-ID: <1320868850-sup-7936@dennou>

Hi,

I found out why class C (+1.8V) capable UICC are still used as class B (+3.3V).
This is because the board provides +3.0V on VCC_PHONE, forcing the phone
to use class B. this voltage is coming from VCC_SIM.
Normally VCC_SIM should only get the power from VCC_PHONE (in sniffing mode),
through the power switch FPF2005, or from the LDO AP3332 (in card reader).
Currently both are enabled (bug). This should be prevented in software as there
is no hardware mechanism to prevent that (fail).
Some power from the LDO is going backwards though the power switch, providing
+3.0V on VCC_PHONE (another hardware fail).

Also, SIMtrace will not be able to decode +1.8V traffic because Vih 
(voltage input high level) is at +2.3V.
One solution would be to power VDDIO at 1.8V, but this is a bad solution
as the USB will not work anymore.

For the v2 board I intend to have the following:
- 1 translator/level shifter for SIM<->CPU, with selectable 1.8/3.3
- 1 translator/level shifter for PHONE<->CPU, with selectable auto/1.8/3.3
- VCC_SIM can be set to VCC_PHONE,1.8V,3.3V
- power forward with diode behaviour

any correction, comments or recommendation are welcome,
kevin



From holger at freyther.de  Wed Nov  9 22:22:12 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed,  9 Nov 2011 23:22:12 +0100
Subject: [PATCH] Respect wLength/window size for USB
Message-ID: <1320877334-21799-1-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <zecke at selfish.org>


This still needs to receive some more testing (untested on Windows
right now) and also consideration how/if we want to upgrade this in
the field. If we consider reflashing the DFU part safe enough. I would
argue that there is still SAMBA to fix things up if someone breaks the
bootloader.

Holger Hans Peter Freyther (1):
  usb: Do not send ZLP when we have filled the window

 firmware/src/dfu/dfu.c          |   46 ++++++++++++++++----------------
 firmware/src/dfu/dfu.h          |    2 +-
 firmware/src/os/pcd_enumerate.c |   54 +++++++++++++++++++++------------------
 3 files changed, 53 insertions(+), 49 deletions(-)

-- 
1.7.7.2




From holger at freyther.de  Wed Nov  9 22:22:13 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed,  9 Nov 2011 23:22:13 +0100
Subject: [PATCH] usb: Do not send ZLP when we have filled the window
In-Reply-To: <1320877334-21799-1-git-send-email-holger@freyther.de>
References: <1320877334-21799-1-git-send-email-holger@freyther.de>
Message-ID: <1320877334-21799-2-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <zecke at selfish.org>

Only send the ZLP if we send less data than was required/asked for
by the host and it is a multiple of the bMaxPacketSize0 (which is
hardcoded to 8 right now).

This is completing the change done in fe88b83e80df8be0351ff38ee6 to
fix SIMtrace attached to OSX and not regress on windows.

Introduce another parameter to udp_ep0_send_data to specify the window
size (wLength) or if not available the default from USB 2.0 specification.
---
 firmware/src/dfu/dfu.c          |   46 ++++++++++++++++----------------
 firmware/src/dfu/dfu.h          |    2 +-
 firmware/src/os/pcd_enumerate.c |   54 +++++++++++++++++++++------------------
 3 files changed, 53 insertions(+), 49 deletions(-)

diff --git a/firmware/src/dfu/dfu.c b/firmware/src/dfu/dfu.c
index 5d6865c..9d1ad10 100644
--- a/firmware/src/dfu/dfu.c
+++ b/firmware/src/dfu/dfu.c
@@ -96,13 +96,15 @@ static void __dfufunc udp_init(void)
 static void __dfufunc udp_ep0_send_zlp(void);
 
 /* Send Data through the control endpoint */
-static void __dfufunc udp_ep0_send_data(const char *pData, u_int32_t length)
+static void __dfufunc udp_ep0_send_data(const char *pData, u_int32_t length,
+					u_int32_t window_length)
 {
 	AT91PS_UDP pUdp = AT91C_BASE_UDP;
-	u_int32_t cpt = 0, len_remain = length;
+	u_int32_t cpt = 0, len_remain;
 	AT91_REG csr;
 
-	DEBUGE("send_data: %u bytes ", length);
+	len_remain = MIN(length, window_length);
+	DEBUGE("send_data: %u/%u bytes ", length, window_length);
 
 	do {
 		cpt = MIN(len_remain, 8);
@@ -135,7 +137,7 @@ static void __dfufunc udp_ep0_send_data(const char *pData, u_int32_t length)
 		while (pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP) ;
 	}
 
-	if ((length % 8) == 0) {
+	if ((length % 8) == 0 && length < window_length) {
 		/* if the length is a multiple of the EP size, we need
 		 * to send another ZLP (zero-length packet) to tell the
 		 * host the transfer has completed.  */
@@ -366,7 +368,7 @@ static __dfufunc int handle_upload(u_int16_t __unused val, u_int16_t len)
 		first_download = 1;
 	}
 
-	udp_ep0_send_data((char *)ptr, len);
+	udp_ep0_send_data((char *)ptr, len, len);
 	ptr+= len;
 
 	return len;
@@ -409,7 +411,7 @@ static __dfufunc void handle_getstatus(void)
 	dstat.iString = 0;
 	/* FIXME: set dstat.bwPollTimeout */
 
-	udp_ep0_send_data((char *)&dstat, sizeof(dstat));
+	udp_ep0_send_data((char *)&dstat, sizeof(dstat), sizeof(dstat));
 }
 
 static void __dfufunc handle_getstate(void)
@@ -417,7 +419,7 @@ static void __dfufunc handle_getstate(void)
 	u_int8_t u8 = dfu_state;
 	DEBUGE("getstate ");
 
-	udp_ep0_send_data((char *)&u8, sizeof(u8));
+	udp_ep0_send_data((char *)&u8, sizeof(u8), sizeof(u8));
 }
 
 /* callback function for DFU requests */
@@ -806,15 +808,13 @@ static __dfufunc void dfu_udp_ep0_handler(void)
 			/* Return Device Descriptor */
 			udp_ep0_send_data((const char *) 
 					  &dfu_dev_descriptor,
-					  MIN(sizeof(dfu_dev_descriptor),
-					      wLength));
+					  sizeof(dfu_dev_descriptor), wLength);
 			break;
 		case USB_DT_CONFIG:
 			/* Return Configuration Descriptor */
 			udp_ep0_send_data((const char *)
 					  &dfu_cfg_descriptor,
-					  MIN(sizeof(dfu_cfg_descriptor),
-					      wLength));
+					  sizeof(dfu_cfg_descriptor), wLength);
 			break;
 		case USB_DT_STRING:
 			/* Return String Descriptor */
@@ -825,14 +825,12 @@ static __dfufunc void dfu_udp_ep0_handler(void)
 			DEBUGE("bLength=%u, wLength=%u ", 
 				usb_strings[desc_index]->bLength, wLength);
 			udp_ep0_send_data((const char *) usb_strings[desc_index],
-					  MIN(usb_strings[desc_index]->bLength, 
-					      wLength));
+					  usb_strings[desc_index]->bLength, wLength);
 			break;
 		case USB_DT_CS_DEVICE:
 			/* Return Function descriptor */
 			udp_ep0_send_data((const char *) &dfu_cfg_descriptor.func_dfu,
-					  MIN(sizeof(dfu_cfg_descriptor.func_dfu),
-					      wLength));
+					  sizeof(dfu_cfg_descriptor.func_dfu), wLength);
 			break;
 		default:
 			udp_ep0_send_stall();
@@ -867,18 +865,20 @@ static __dfufunc void dfu_udp_ep0_handler(void)
 		break;
 	case STD_GET_CONFIGURATION:
 		DEBUGE("GET_CONFIG ");
-		udp_ep0_send_data((char *)&(cur_config),
-				   sizeof(cur_config));
+		/* Table 9.4 wLength One */
+		udp_ep0_send_data((char *)&(cur_config), sizeof(cur_config), 1);
 		break;
 	case STD_GET_STATUS_ZERO:
 		DEBUGE("GET_STATUS_ZERO ");
 		wStatus = 0;
-		udp_ep0_send_data((char *)&wStatus, sizeof(wStatus));
+		/* Table 9.4 wLength Two */
+		udp_ep0_send_data((char *)&wStatus, sizeof(wStatus), 2);
 		break;
 	case STD_GET_STATUS_INTERFACE:
 		DEBUGE("GET_STATUS_INTERFACE ");
 		wStatus = 0;
-		udp_ep0_send_data((char *)&wStatus, sizeof(wStatus));
+		/* Table 9.4 wLength Two */
+		udp_ep0_send_data((char *)&wStatus, sizeof(wStatus), 2);
 		break;
 	case STD_GET_STATUS_ENDPOINT:
 		DEBUGE("GET_STATUS_ENDPOINT(EPidx=%u) ", wIndex&0x0f);
@@ -887,14 +887,14 @@ static __dfufunc void dfu_udp_ep0_handler(void)
 		if ((pUDP->UDP_GLBSTATE & AT91C_UDP_CONFG) && (wIndex == 0)) {
 			wStatus =
 			    (pUDP->UDP_CSR[wIndex] & AT91C_UDP_EPEDS) ? 0 : 1;
-			udp_ep0_send_data((char *)&wStatus,
-					   sizeof(wStatus));
+			/* Table 9.4 wLength Two */
+			udp_ep0_send_data((char *)&wStatus, sizeof(wStatus), 2);
 		} else if ((pUDP->UDP_GLBSTATE & AT91C_UDP_FADDEN)
 			   && (wIndex == 0)) {
 			wStatus =
 			    (pUDP->UDP_CSR[wIndex] & AT91C_UDP_EPEDS) ? 0 : 1;
-			udp_ep0_send_data((char *)&wStatus,
-					   sizeof(wStatus));
+			/* Table 9.4 wLength Two */
+			udp_ep0_send_data((char *)&wStatus, sizeof(wStatus), 2);
 		} else
 			udp_ep0_send_stall();
 		break;
diff --git a/firmware/src/dfu/dfu.h b/firmware/src/dfu/dfu.h
index c898197..27c63b5 100644
--- a/firmware/src/dfu/dfu.h
+++ b/firmware/src/dfu/dfu.h
@@ -124,7 +124,7 @@ struct _dfu_desc {
 
 struct dfuapi {
 	void (*udp_init)(void);
-	void (*ep0_send_data)(const char *data, u_int32_t len);
+	void (*ep0_send_data)(const char *data, u_int32_t len, u_int32_t wlen);
 	void (*ep0_send_zlp)(void);
 	void (*ep0_send_stall)(void);
 	int  (*dfu_ep0_handler)(u_int8_t req_type, u_int8_t req,
diff --git a/firmware/src/os/pcd_enumerate.c b/firmware/src/os/pcd_enumerate.c
index c360d37..3a7397f 100644
--- a/firmware/src/os/pcd_enumerate.c
+++ b/firmware/src/os/pcd_enumerate.c
@@ -531,12 +531,12 @@ static void udp_ep0_handler(void)
 			if (*dfu->dfu_state != DFU_STATE_appIDLE)
 				udp_ep0_send_data((const char *) 
 						  dfu->dfu_dev_descriptor,
-						  MIN(dfu->dfu_dev_descriptor->bLength,
-						      wLength));
+						  dfu->dfu_dev_descriptor->bLength,
+						  wLength);
 			else
 #endif
 			udp_ep0_send_data((const char *) &dev_descriptor,
-					   MIN(sizeof(dev_descriptor), wLength));
+					  sizeof(dev_descriptor), wLength);
 			break;
 		case USB_DT_CONFIG:
 			/* Return Configuration Descriptor */
@@ -544,12 +544,12 @@ static void udp_ep0_handler(void)
 			if (*dfu->dfu_state != DFU_STATE_appIDLE)
 				udp_ep0_send_data((const char *)
 						  dfu->dfu_cfg_descriptor,
-						  MIN(dfu->dfu_cfg_descriptor->ucfg.wTotalLength,
-						      wLength));
+						  dfu->dfu_cfg_descriptor->ucfg.wTotalLength,
+						  wLength);
 			else
 #endif
 			udp_ep0_send_data((const char *) &cfg_descriptor,
-					   MIN(sizeof(cfg_descriptor), wLength));
+					   sizeof(cfg_descriptor), wLength);
 			break;
 		case USB_DT_STRING:
 #ifdef CONFIG_USB_STRING
@@ -559,8 +559,8 @@ static void udp_ep0_handler(void)
 			DEBUGE("bLength=%u, wLength=%u\n", 
 				usb_strings[desc_index]->bLength, wLength);
 			udp_ep0_send_data((const char *) usb_strings[desc_index],
-					  MIN(usb_strings[desc_index]->bLength, 
-					      wLength));
+					  usb_strings[desc_index]->bLength,
+					  wLength);
 #else
 			goto out_stall;
 #endif
@@ -568,7 +568,7 @@ static void udp_ep0_handler(void)
 		case USB_DT_CS_DEVICE:
 			/* Return Function descriptor */
 			udp_ep0_send_data((const char *) &dfu->dfu_cfg_descriptor->func_dfu,
-					  MIN(sizeof(dfu->dfu_cfg_descriptor->func_dfu), wLength));
+					  sizeof(dfu->dfu_cfg_descriptor->func_dfu), wLength);
 			break;
 		case USB_DT_INTERFACE:
 			/* Return Interface descriptor */
@@ -578,27 +578,27 @@ static void udp_ep0_handler(void)
 			case 0:
 				udp_ep0_send_data((const char *)
 						&cfg_descriptor.uif,
-						MIN(sizeof(cfg_descriptor.uif),
-						      wLength));
+						sizeof(cfg_descriptor.uif),
+						wLength);
 				break;
 	#ifdef CONFIG_DFU
 			case 1:
 				udp_ep0_send_data((const char *)
 						&cfg_descriptor.uif_dfu[0],
-						MIN(sizeof(cfg_descriptor.uif_dfu[0]),
-						    wLength));
+						sizeof(cfg_descriptor.uif_dfu[0]),
+						wLength);
 				break;
 			case 2:
 				udp_ep0_send_data((const char *)
 						&cfg_descriptor.uif_dfu[1],
-						MIN(sizeof(cfg_descriptor.uif_dfu[1]),
-						    wLength));
+						sizeof(cfg_descriptor.uif_dfu[1]),
+						wLength);
 				break;
 			case 3:
 				udp_ep0_send_data((const char *)
 						&cfg_descriptor.uif_dfu[2],
-						MIN(sizeof(cfg_descriptor.uif_dfu[2]),
-						    wLength));
+						sizeof(cfg_descriptor.uif_dfu[2]),
+						wLength);
 				break;
 	#endif
 			default:
@@ -679,8 +679,9 @@ static void udp_ep0_handler(void)
 		switch (upcd.state) {
 		case USB_STATE_ADDRESS:
 		case USB_STATE_CONFIGURED:
+			/* Table 9.4 wLength One */
 			udp_ep0_send_data((char *)&(upcd.cur_config),
-					   sizeof(upcd.cur_config));
+					   sizeof(upcd.cur_config), 1);
 			break;
 		default:
 			goto out_stall;
@@ -691,13 +692,15 @@ static void udp_ep0_handler(void)
 		DEBUGE("GET_INTERFACE ");
 		if (upcd.state != USB_STATE_CONFIGURED)
 			goto out_stall;
+		/* Table 9.4 wLength One */
 		udp_ep0_send_data((char *)&(upcd.cur_altsett),
-				  sizeof(upcd.cur_altsett));
+				  sizeof(upcd.cur_altsett), 1);
 		break;
 	case STD_GET_STATUS_ZERO:
 		DEBUGE("GET_STATUS_ZERO ");
 		wStatus = 0;
-		udp_ep0_send_data((char *)&wStatus, sizeof(wStatus));
+		/* Table 9.4 wLength Two */
+		udp_ep0_send_data((char *)&wStatus, sizeof(wStatus), 2);
 		break;
 	case STD_GET_STATUS_INTERFACE:
 		DEBUGE("GET_STATUS_INTERFACE ");
@@ -705,7 +708,8 @@ static void udp_ep0_handler(void)
 		    (upcd.state == USB_STATE_ADDRESS && wIndex != 0))
 			goto out_stall;
 		wStatus = 0;
-		udp_ep0_send_data((char *)&wStatus, sizeof(wStatus));
+		/* Table 9.4 wLength Two */
+		udp_ep0_send_data((char *)&wStatus, sizeof(wStatus), 2);
 		break;
 	case STD_GET_STATUS_ENDPOINT:
 		DEBUGE("GET_STATUS_ENDPOINT(EPidx=%u) ", wIndex&0x0f);
@@ -717,14 +721,14 @@ static void udp_ep0_handler(void)
 		if ((pUDP->UDP_GLBSTATE & AT91C_UDP_CONFG) && (wIndex <= 3)) {
 			wStatus =
 			    (pUDP->UDP_CSR[wIndex] & AT91C_UDP_EPEDS) ? 0 : 1;
-			udp_ep0_send_data((char *)&wStatus,
-					   sizeof(wStatus));
+			/* Table 9.4 wLength Two */
+			udp_ep0_send_data((char *)&wStatus, sizeof(wStatus), 2);
 		} else if ((pUDP->UDP_GLBSTATE & AT91C_UDP_FADDEN)
 			   && (wIndex == 0)) {
 			wStatus =
 			    (pUDP->UDP_CSR[wIndex] & AT91C_UDP_EPEDS) ? 0 : 1;
-			udp_ep0_send_data((char *)&wStatus,
-					   sizeof(wStatus));
+			/* Table 9.4 wLength Two */
+			udp_ep0_send_data((char *)&wStatus, sizeof(wStatus), 2);
 		} else
 			goto out_stall;
 		break;
-- 
1.7.7.2




From holger at freyther.de  Wed Nov  9 22:24:11 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed,  9 Nov 2011 23:24:11 +0100
Subject: [PATCH 0/5] DFU Address GCC warnings
Message-ID: <1320877456-21930-1-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <zecke at selfish.org>

These address various compiler warnings, there is still one left
related the flash handling  but I will need to read a bit more on
the EFC. I have flashed my device using DFU with these patches applied.

Holger Hans Peter Freyther (5):
  dfu: The i variable to disable interrupts shadows the outer index
  dfu: udp_ep0_recv_clean is static and is not called anywhere
  dfu: Mark unsued variables as __unused for now
  dfu: Use {} for possible empty if statement (in case debug is off)
  dfu: Remove unused variable, mark method as not retuning

 firmware/include/asm/compiler.h |    3 +++
 firmware/src/dfu/dfu.c          |   36 +++++++++++-------------------------
 2 files changed, 14 insertions(+), 25 deletions(-)

-- 
1.7.7.2




From holger at freyther.de  Wed Nov  9 22:24:12 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed,  9 Nov 2011 23:24:12 +0100
Subject: [PATCH 1/5] dfu: The i variable to disable interrupts shadows the
	outer index
In-Reply-To: <1320877456-21930-1-git-send-email-holger@freyther.de>
References: <1320877456-21930-1-git-send-email-holger@freyther.de>
Message-ID: <1320877456-21930-2-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <zecke at selfish.org>

In case ram_app_entry() returns do not reset i to 32, otherwise we
will never reset the watchdog.

src/dfu/dfu.c:1077:7: warning: declaration of ?i? shadows a previous local [-Wshadow]
src/dfu/dfu.c:1068:6: warning: shadowed declaration is here [-Wshadow]
---
 firmware/src/dfu/dfu.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/firmware/src/dfu/dfu.c b/firmware/src/dfu/dfu.c
index 0e22256..48f2cdc 100644
--- a/firmware/src/dfu/dfu.c
+++ b/firmware/src/dfu/dfu.c
@@ -1074,9 +1074,9 @@ void __dfufunc dfu_main(void)
 	    }
 	    if (switch_to_ram) {
 		void (*ram_app_entry)(void);
-		int i;
-		for (i = 0; i < 32; i++)
-			AT91F_AIC_DisableIt(AT91C_BASE_AIC, i);
+		int j;
+		for (j = 0; j < 32; j++)
+			AT91F_AIC_DisableIt(AT91C_BASE_AIC, j);
 		/* jump into RAM */
 		AT91F_DBGU_Printk("JUMP TO RAM\r\n");
 		ram_app_entry = AT91C_ISRAM + SAM7DFU_RAM_SIZE;
-- 
1.7.7.2




From holger at freyther.de  Wed Nov  9 22:24:15 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed,  9 Nov 2011 23:24:15 +0100
Subject: [PATCH 4/5] dfu: Use {} for possible empty if statement (in case
	debug is off)
In-Reply-To: <1320877456-21930-1-git-send-email-holger@freyther.de>
References: <1320877456-21930-1-git-send-email-holger@freyther.de>
Message-ID: <1320877456-21930-5-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <zecke at selfish.org>

src/dfu/dfu.c:853:23: warning: suggest braces around empty body in an ?if? statement [-Wempty-body]
---
 firmware/src/dfu/dfu.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/firmware/src/dfu/dfu.c b/firmware/src/dfu/dfu.c
index 682ce5e..f31b9f8 100644
--- a/firmware/src/dfu/dfu.c
+++ b/firmware/src/dfu/dfu.c
@@ -847,8 +847,10 @@ static __dfufunc void dfu_udp_ep0_handler(void)
 		break;
 	case STD_SET_CONFIGURATION:
 		DEBUGE("SET_CONFIG ");
-		if (wValue)
+		if (wValue) {
 			DEBUGE("VALUE!=0 ");
+		}
+	
 		cur_config = wValue;
 		udp_ep0_send_zlp();
 		pUDP->UDP_GLBSTATE =
-- 
1.7.7.2




From holger at freyther.de  Wed Nov  9 22:24:13 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed,  9 Nov 2011 23:24:13 +0100
Subject: [PATCH 2/5] dfu: udp_ep0_recv_clean is static and is not called
	anywhere
In-Reply-To: <1320877456-21930-1-git-send-email-holger@freyther.de>
References: <1320877456-21930-1-git-send-email-holger@freyther.de>
Message-ID: <1320877456-21930-3-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <zecke at selfish.org>

---
 firmware/src/dfu/dfu.c |   14 --------------
 1 files changed, 0 insertions(+), 14 deletions(-)

diff --git a/firmware/src/dfu/dfu.c b/firmware/src/dfu/dfu.c
index 48f2cdc..9cd9996 100644
--- a/firmware/src/dfu/dfu.c
+++ b/firmware/src/dfu/dfu.c
@@ -144,20 +144,6 @@ static void __dfufunc udp_ep0_send_data(const char *pData, u_int32_t length)
 	}
 }
 
-static void udp_ep0_recv_clean(void)
-{
-	unsigned int i;
-	u_int8_t dummy;
-	const AT91PS_UDP pUdp = AT91C_BASE_UDP;
-
-	while (!(pUdp->UDP_CSR[0] & AT91C_UDP_RX_DATA_BK0)) ;
-
-	for (i = 0; i < (pUdp->UDP_CSR[0] >> 16); i++)
-		dummy = pUdp->UDP_FDR[0];
-
-	pUdp->UDP_CSR[0] &= ~(AT91C_UDP_RX_DATA_BK0);
-}
-
 /* receive data from EP0 */
 static int __dfufunc udp_ep0_recv_data(u_int8_t *data, u_int16_t len)
 {
-- 
1.7.7.2




From holger at freyther.de  Wed Nov  9 22:24:14 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed,  9 Nov 2011 23:24:14 +0100
Subject: [PATCH 3/5] dfu: Mark unsued variables as __unused for now
In-Reply-To: <1320877456-21930-1-git-send-email-holger@freyther.de>
References: <1320877456-21930-1-git-send-email-holger@freyther.de>
Message-ID: <1320877456-21930-4-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <zecke at selfish.org>

---
 firmware/include/asm/compiler.h |    2 ++
 firmware/src/dfu/dfu.c          |    8 ++++----
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/firmware/include/asm/compiler.h b/firmware/include/asm/compiler.h
index de4dfaa..08b6bae 100644
--- a/firmware/include/asm/compiler.h
+++ b/firmware/include/asm/compiler.h
@@ -4,4 +4,6 @@
 #define likely(x)       __builtin_expect(!!(x), 1)
 #define unlikely(x)     __builtin_expect(!!(x), 0)
 
+#define __unused	__attribute__((unused))
+
 #endif
diff --git a/firmware/src/dfu/dfu.c b/firmware/src/dfu/dfu.c
index 9cd9996..682ce5e 100644
--- a/firmware/src/dfu/dfu.c
+++ b/firmware/src/dfu/dfu.c
@@ -231,7 +231,7 @@ static void chk_first_dnload_set_ptr(void)
 	first_download = 0;
 }
 
-static int __dfufunc handle_dnload_flash(u_int16_t val, u_int16_t len)
+static int __dfufunc handle_dnload_flash(u_int16_t __unused val, u_int16_t len)
 {
 	volatile u_int32_t *p;
 	u_int8_t *pagebuf = (u_int8_t *) pagebuf32;
@@ -297,7 +297,7 @@ static int __dfufunc handle_dnload_flash(u_int16_t val, u_int16_t len)
 	return RET_ZLP;
 }
 
-static int __dfufunc handle_dnload_ram(u_int16_t val, u_int16_t len)
+static int __dfufunc handle_dnload_ram(u_int16_t __unused val, u_int16_t len)
 {
 	DEBUGE("download ");
 
@@ -349,7 +349,7 @@ static int __dfufunc handle_dnload(u_int16_t val, u_int16_t len)
 }
 
 #define AT91C_IFLASH_END ((u_int8_t *)AT91C_IFLASH + AT91C_IFLASH_SIZE)
-static __dfufunc int handle_upload(u_int16_t val, u_int16_t len)
+static __dfufunc int handle_upload(u_int16_t __unused val, u_int16_t len)
 {
 	DEBUGE("upload ");
 	if (len > AT91C_IFLASH_PAGE_SIZE) {
@@ -421,7 +421,7 @@ static void __dfufunc handle_getstate(void)
 }
 
 /* callback function for DFU requests */
-int __dfufunc dfu_ep0_handler(u_int8_t req_type, u_int8_t req,
+int __dfufunc dfu_ep0_handler(u_int8_t __unused req_type, u_int8_t req,
 		    u_int16_t val, u_int16_t len)
 {
 	int rc, ret = RET_NOTHING;
-- 
1.7.7.2




From holger at freyther.de  Wed Nov  9 22:24:16 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed,  9 Nov 2011 23:24:16 +0100
Subject: [PATCH 5/5] dfu: Remove unused variable, mark method as not retuning
In-Reply-To: <1320877456-21930-1-git-send-email-holger@freyther.de>
References: <1320877456-21930-1-git-send-email-holger@freyther.de>
Message-ID: <1320877456-21930-6-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <zecke at selfish.org>

---
 firmware/include/asm/compiler.h |    1 +
 firmware/src/dfu/dfu.c          |    4 +---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/firmware/include/asm/compiler.h b/firmware/include/asm/compiler.h
index 08b6bae..d2b53f0 100644
--- a/firmware/include/asm/compiler.h
+++ b/firmware/include/asm/compiler.h
@@ -5,5 +5,6 @@
 #define unlikely(x)     __builtin_expect(!!(x), 0)
 
 #define __unused	__attribute__((unused))
+#define __noreturn	__attribute__((noreturn))
 
 #endif
diff --git a/firmware/src/dfu/dfu.c b/firmware/src/dfu/dfu.c
index f31b9f8..5d6865c 100644
--- a/firmware/src/dfu/dfu.c
+++ b/firmware/src/dfu/dfu.c
@@ -993,10 +993,8 @@ static __dfufunc void dfu_udp_irq(void)
 }
 
 /* this is only called once before DFU mode, no __dfufunc required */
-static void dfu_switch(void)
+static __noreturn void dfu_switch(void)
 {
-	AT91PS_AIC pAic = AT91C_BASE_AIC;
-
 	DEBUGE("\r\nsam7dfu: switching to DFU mode\r\n");
 
 	dfu_state = DFU_STATE_appDETACH;
-- 
1.7.7.2




From laforge at gnumonks.org  Thu Nov 10 06:34:44 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 10 Nov 2011 07:34:44 +0100
Subject: [PATCH 0/5] DFU Address GCC warnings
In-Reply-To: <1320877456-21930-1-git-send-email-holger@freyther.de>
References: <1320877456-21930-1-git-send-email-holger@freyther.de>
Message-ID: <20111110063444.GM14725@prithivi.gnumonks.org>

Hi Holger,

On Wed, Nov 09, 2011 at 11:24:11PM +0100, Holger Hans Peter Freyther wrote:
> These address various compiler warnings, there is still one left
> related the flash handling  but I will need to read a bit more on
> the EFC. I have flashed my device using DFU with these patches applied.

I've applied the cleanups, thanks.

-- 
- Harald Welte <laforge at gnumonks.org>           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 Nov 10 20:20:11 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 10 Nov 2011 21:20:11 +0100
Subject: [PATCH] usb: Do not send ZLP when we have filled the window
In-Reply-To: <1320877334-21799-2-git-send-email-holger@freyther.de>
References: <1320877334-21799-1-git-send-email-holger@freyther.de>
	<1320877334-21799-2-git-send-email-holger@freyther.de>
Message-ID: <4EBC31FB.1090800@freyther.de>

On 11/09/2011 11:22 PM, Holger Hans Peter Freyther wrote:
> From: Holger Hans Peter Freyther <zecke at selfish.org>
> 

I enabled debug in dfu and added another debug statement. It appears to do the
right thing. I have attached the device to Windows running in KVM but I think
that a native windows will behave differently (bus reset, etc). I will try to
test with a native windows, please don't apply the patch yet.



main(76): entering main (idle) loop
send_data: 18/64 bytes stopped by status out send_data: 18/18 bytes NO ZLP 18 18
send_data: 68/9 bytes NO ZLP 68 9
send_data: 68/66 bytes NO ZLP 68 66
send_data: 4/255 bytes NO ZLP 4 255
send_data: 72/255 bytes set_txpktrdy_zlp
send_data: 100/255 bytes NO ZLP 100 255
send_data: 62/255 bytes NO ZLP 62 255
send_data: 54/255 bytes NO ZLP 54 255
send_data: 94/255 bytes NO ZLP 94 255
send_data: 92/255 bytes NO ZLP 92 255
send_data: 58/255 bytes NO ZLP 58 255
send_data: 1/1 bytes NO ZLP 1 1
send_data: 18/64 bytes stopped by status out send_data: 18/18 bytes NO ZLP 18 18
send_data: 68/66 bytes NO ZLP 68 66
send_data: 18/64 bytes NO ZLP 18 64
send_data: 18/64 bytes stopped by status out send_data: 18/18 bytes NO ZLP 18 18
send_data: 68/66 bytes NO ZLP 68 66
send_data: 18/18 bytes NO ZLP 18 18
send_data: 68/255 bytes NO ZLP 68 255
send_data: 4/255 bytes NO ZLP 4 255
send_data: 72/255 bytes set_txpktrdy_zlp



From kevredon at mail.tsaitgaist.info  Mon Nov 14 11:18:49 2011
From: kevredon at mail.tsaitgaist.info (Kevin Redon)
Date: Mon, 14 Nov 2011 12:18:49 +0100
Subject: class C (+1.8V) capabilities
In-Reply-To: <1320868850-sup-7936@dennou>
References: <1320868850-sup-7936@dennou>
Message-ID: <1321268977-sup-8555@dennou>

I did some more work.
The FPF2005 has no reverse voltage blocker, this is why the 3.3V from the LDO
flows back into VCC_PHONE. It even damages the chip (so says the datasheet)
I corrected the double power source problem by disabling the LDO (see patch),
but still 1.8V does not work and 3.0-3.3V is used. I have to look for other
reasons.

Also SIMtrace has some issues with 5V signals. Rare are the SIM which only
support class A (5V), but the readers often use it (at least 2 of mine).
Sometime SIMtrace manages to sniff, but it is not reliable.
I will also add class A support in SIMtrace v2.

more details are coming in the next days,
kevin

Excerpts from Kevin Redon's message of Wed Nov 09 21:01:35 +0100 2011:
> Hi,
> 
> I found out why class C (+1.8V) capable UICC are still used as class B (+3.3V).
> This is because the board provides +3.0V on VCC_PHONE, forcing the phone
> to use class B. this voltage is coming from VCC_SIM.
> Normally VCC_SIM should only get the power from VCC_PHONE (in sniffing mode),
> through the power switch FPF2005, or from the LDO AP3332 (in card reader).
> Currently both are enabled (bug). This should be prevented in software as there
> is no hardware mechanism to prevent that (fail).
> Some power from the LDO is going backwards though the power switch, providing
> +3.0V on VCC_PHONE (another hardware fail).
> 
> Also, SIMtrace will not be able to decode +1.8V traffic because Vih 
> (voltage input high level) is at +2.3V.
> One solution would be to power VDDIO at 1.8V, but this is a bad solution
> as the USB will not work anymore.
> 
> For the v2 board I intend to have the following:
> - 1 translator/level shifter for SIM<->CPU, with selectable 1.8/3.3
> - 1 translator/level shifter for PHONE<->CPU, with selectable auto/1.8/3.3
> - VCC_SIM can be set to VCC_PHONE,1.8V,3.3V
> - power forward with diode behaviour
> 
> any correction, comments or recommendation are welcome,
> kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpcd.diff
Type: application/octet-stream
Size: 2023 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20111114/918291c8/attachment.obj>

From laforge at gnumonks.org  Fri Nov 25 08:15:20 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 25 Nov 2011 09:15:20 +0100
Subject: RFC: Osmocom developer workshop 2012
Message-ID: <20111125081520.GL1730@prithivi.gnumonks.org>

<DISCLAIMER> Please follow-up to openbsc at lists.osmocom.org </DISCLAIMER>

Hi all,

this idea has been around for quite some time, and for 2012 I really
want to turn it into reality:

	I'd like to have a Osmocom developer workshop

The idea here is to get all the active contributors of the project
together for a couple of days (maybe 2-4 days), in order to exchange
ideas, get to know each other better and last but not least work
together on ironing out some of the more difficult issues.

* City:

Regarding the location:  I think for me it is only possible to organize
it if it is to be held in Berlin.  I'mn happy if somebody else wants to
host it at some other location, but then that person would also have to
take care of local organization.  Berlin also has good train and flight
connections, which is definitely a plus.

* Venue:

If it is in Berlin, we might consider talking with c-base or
Raumfahrtagentur as possible venues.

* Date:

Regarding a proposed date, I'm completely open for suggestions.  Of
course there shouldn't be any overlap with other major FOSS or Sescurity
related conferences, and it should also not coincide with major public
holidays, as that only makes travel + accomodation more expensive.

* Funding:

As we don't have that many commercial users of Osmocom projects, getting
funding for e.g. travel / accomodation is probably going to be
difficult.  We can ask the "usual suspects" among those commercial users
we know,, but I guess it will only be possible in exceptional cases to
provide that kind of funding.

Any ideas / comments / feedback is much appreciated.  If somebody has
a particular suggestion.

<DISCLAIMER> Please follow-up to openbsc at lists.osmocom.org </DISCLAIMER>

Cheers,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From pablo at gnumonks.org  Sat Nov 26 00:40:08 2011
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Sat, 26 Nov 2011 01:40:08 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111125081520.GL1730@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
Message-ID: <20111126004008.GA21629@1984>

On Fri, Nov 25, 2011 at 09:15:20AM +0100, Harald Welte wrote:
> * City:
> 
> Regarding the location:  I think for me it is only possible to organize
> it if it is to be held in Berlin.  I'mn happy if somebody else wants to
> host it at some other location, but then that person would also have to
> take care of local organization.  Berlin also has good train and flight
> connections, which is definitely a plus.

I'm happy with Berlin :-). I can propose Sevilla as alternative, it
can be for the next workshop of course.

But if you want to make it here, it has to be after february 2012.



From laforge at gnumonks.org  Sat Nov 26 18:12:45 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 26 Nov 2011 19:12:45 +0100
Subject: RFC: Generic (U)SIM software
Message-ID: <20111126181245.GI3773@prithivi.gnumonks.org>

Hi all,

I'm thinking of starting a project that would allow us to
 * perform SIM and USIM card pre-personalization
 * read/dump and explore [U]SIM contents interactively
 * perform SIM card simulation

The idea is to start with some generic data structure that can represent
the filesystem tree (DFs, EFs) and their "external" properties, i.e.
file type, size, permissions, FID, SFID, etc.

This data structure could also have the actual file content associated
with each EF.

The second step would be some code that can take that data structure and
program a freely-programmable card (like sysmoSIM-GR1) and create the
files according to that structure.

Another module would implement card-simulation (via BT SAP, SIMtrace or
virtual PC/SC card).  After all, only a few instructions have to be
imilpemented if the filesystem and its content is already in a generic
data structure that the program can access..

Next step would be to associate parser and generator routines for the
content of each individual file as it is  specified in TS 11.11.

After that has been done, we could think of representing the FS tree and
the parsed contents of each file in some kind of graphical / user
friendly representation.  The idea here is that the UI code would be
generic and not know any of the actual ecnoding/decoding of the EF
content.

The biggest question is what language to use for this.  Some kind of
object orientation might very well resemble the idea of a 'file object'
in a tree, with many different file types, each having it's own
parser/encoder.

On the other hand, Erlang's bit field syntax would probably come very
handy in terms of encoding/decoding the various EF content.  However, at
least once we start to want some kidn of UI, Erlan really sucsk.  Also,
almost nobody here reads/writes Erlang [yet?].

Writing all this in C seems like a bit much of an effort, probably even
more so on the UI side.  However, we already have quite a bit of C code
for parsing/generating things like LAI, etc. which are stored like 04.08
inside the sim card files.

Python might be a good idea in terms of tons of available
libraries/modules, object orientation and good UI bindings.  The biggest
problem here is that my python skills are really limited so far, so my
productivity might not be as high as I expect.

The individual components could even be written in different
languages, but then we would have to have some common format for
exchanging data back and forth - which might not be worth it, given the
small scope of the project.

any ideas / comments / feedback?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From alberto at g-hc.org  Sat Nov 26 19:30:36 2011
From: alberto at g-hc.org (Alberto Fabiano)
Date: Sat, 26 Nov 2011 17:30:36 -0200
Subject: RFC: Generic (U)SIM software
In-Reply-To: <20111126181245.GI3773@prithivi.gnumonks.org>
References: <20111126181245.GI3773@prithivi.gnumonks.org>
Message-ID: <CAAv_oXsxrWLUtDyANzwqdGeSXew1pK1n+CO2=CEUEK--mQAEyQ@mail.gmail.com>

Well,

     If you know Erlang, C and C++, python you will learn Python fast!
     And the advantage is that Python has some projects in which they can be
leveraged, for example:

http://pyscard.sourceforge.net/
http://michau.benoit.free.fr/codes/smartcard/card/


   Recalling also that wrappers between Python and  Erlang or C are
relatively simple...

[]s

./alberto -fabiano -vvv

On Sat, Nov 26, 2011 at 16:12, Harald Welte <laforge at gnumonks.org> wrote:

> Hi all,
>
> I'm thinking of starting a project that would allow us to
>  * perform SIM and USIM card pre-personalization
>  * read/dump and explore [U]SIM contents interactively
>  * perform SIM card simulation
>
> The idea is to start with some generic data structure that can represent
> the filesystem tree (DFs, EFs) and their "external" properties, i.e.
> file type, size, permissions, FID, SFID, etc.
>
> This data structure could also have the actual file content associated
> with each EF.
>
> The second step would be some code that can take that data structure and
> program a freely-programmable card (like sysmoSIM-GR1) and create the
> files according to that structure.
>
> Another module would implement card-simulation (via BT SAP, SIMtrace or
> virtual PC/SC card).  After all, only a few instructions have to be
> imilpemented if the filesystem and its content is already in a generic
> data structure that the program can access..
>
> Next step would be to associate parser and generator routines for the
> content of each individual file as it is  specified in TS 11.11.
>
> After that has been done, we could think of representing the FS tree and
> the parsed contents of each file in some kind of graphical / user
> friendly representation.  The idea here is that the UI code would be
> generic and not know any of the actual ecnoding/decoding of the EF
> content.
>
> The biggest question is what language to use for this.  Some kind of
> object orientation might very well resemble the idea of a 'file object'
> in a tree, with many different file types, each having it's own
> parser/encoder.
>
> On the other hand, Erlang's bit field syntax would probably come very
> handy in terms of encoding/decoding the various EF content.  However, at
> least once we start to want some kidn of UI, Erlan really sucsk.  Also,
> almost nobody here reads/writes Erlang [yet?].
>
> Writing all this in C seems like a bit much of an effort, probably even
> more so on the UI side.  However, we already have quite a bit of C code
> for parsing/generating things like LAI, etc. which are stored like 04.08
> inside the sim card files.
>
> Python might be a good idea in terms of tons of available
> libraries/modules, object orientation and good UI bindings.  The biggest
> problem here is that my python skills are really limited so far, so my
> productivity might not be as high as I expect.
>
> The individual components could even be written in different
> languages, but then we would have to have some common format for
> exchanging data back and forth - which might not be worth it, given the
> small scope of the project.
>
> any ideas / comments / feedback?
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
>
>


-- 
~[&]s;

HH /* Happy Hackings! */

AL. /* @AlbertoFabiano */

- .... .  -... . ... -  .-- .- -.--  - ---  .--. .-. . -.. .. -.-. -  -
.... .  ..-. ..- - ..- .-. .  .. ...  - ---  .. -. ...- . -. -  .. -     .-
.-.. .- -.  -.- .- -.--

k'b?t Y> "The best way to predict the future is to invent it." --Alan Kay
k'b?t X> "Chance favors the prepared mind."   --Louis Pasteur
k'b?t Z> "The world is full of fascinating problems waiting to be solved"
--Eric S.Raymond

/*  0x42 0x69 0x74 0x20 0x46 0x61 0x6e  */
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20111126/90f987f0/attachment.htm>

From kevredon at mail.tsaitgaist.info  Sun Nov 27 13:52:18 2011
From: kevredon at mail.tsaitgaist.info (Kevin Redon)
Date: Sun, 27 Nov 2011 14:52:18 +0100
Subject: RFC: Generic (U)SIM software
In-Reply-To: <20111126181245.GI3773@prithivi.gnumonks.org>
References: <20111126181245.GI3773@prithivi.gnumonks.org>
Message-ID: <1322399115-sup-9058@dennou>

Hi all,

I already made some SIM tools, which I call softSIM.
It can already dump all the data (files) from the SIM (into an XML),
sometimes even parse it, and this dump can be used to simulated a 
SIM (using BT SAP). More details are available in the wiki article.
http://bb.osmocom.org/trac/wiki/softSIM

It only handles SIM (I had no need to play with USIM), and is in
ruby (not the best language if we want to use it in SIMtrace), but
it works great and it can be used as inspiration for re-implementation.
Writing a writer or UI based on this code would not take me long, if
the existing tools are accepted as base.

I'm quite interested in write a reader/writer/simulator in C, but I have
not that much time (I use it for SIMtrace at the moment). But I'm happy
to help, or do it later on.

kevin

Excerpts from Harald Welte's message of Sat Nov 26 19:12:45 +0100 2011:
> Hi all,
> 
> I'm thinking of starting a project that would allow us to
>  * perform SIM and USIM card pre-personalization
>  * read/dump and explore [U]SIM contents interactively
>  * perform SIM card simulation
> 
> any ideas / comments / feedback?
> 



From marcel at holtmann.org  Mon Nov 28 17:00:34 2011
From: marcel at holtmann.org (Marcel Holtmann)
Date: Mon, 28 Nov 2011 18:00:34 +0100
Subject: RFC: Generic (U)SIM software
In-Reply-To: <20111126181245.GI3773@prithivi.gnumonks.org>
References: <20111126181245.GI3773@prithivi.gnumonks.org>
Message-ID: <1322499634.29909.49.camel@aeonflux>

Hi Harald,

> I'm thinking of starting a project that would allow us to
>  * perform SIM and USIM card pre-personalization
>  * read/dump and explore [U]SIM contents interactively
>  * perform SIM card simulation
> 
> The idea is to start with some generic data structure that can represent
> the filesystem tree (DFs, EFs) and their "external" properties, i.e.
> file type, size, permissions, FID, SFID, etc.
> 
> This data structure could also have the actual file content associated
> with each EF.

you might wanna have a look at oFono source code. At least for reading
EF and parsing them we have extensive support. Check src/simutil.[ch]
and src/simfs.[ch].

Same if you care about the SIM Toolkit support. It has support for
parsing the majority of data structures you find there.

Regards

Marcel





From laforge at gnumonks.org  Mon Nov 28 17:26:16 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 28 Nov 2011 18:26:16 +0100
Subject: RFC: Generic (U)SIM software
In-Reply-To: <1322499634.29909.49.camel@aeonflux>
References: <20111126181245.GI3773@prithivi.gnumonks.org>
	<1322499634.29909.49.camel@aeonflux>
Message-ID: <20111128172615.GA3241@prithivi.gnumonks.org>

Hi Marcel,

good to hear from you !

On Mon, Nov 28, 2011 at 06:00:34PM +0100, Marcel Holtmann wrote:

> > This data structure could also have the actual file content associated
> > with each EF.
> 
> you might wanna have a look at oFono source code. At least for reading
> EF and parsing them we have extensive support. Check src/simutil.[ch]
> and src/simfs.[ch].

I will check, thanks for the hint.  However, I believe you are mostly
dealing with DFtelecom, i.e. things like SMS, contact data, etc. - not
so much with issues like preferred operator list, Kc, TMSI, SIM service
table, etc.

But I will RTFS first, before making any more assumptions...

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From marcel at holtmann.org  Tue Nov 29 12:11:51 2011
From: marcel at holtmann.org (Marcel Holtmann)
Date: Tue, 29 Nov 2011 13:11:51 +0100
Subject: RFC: Generic (U)SIM software
In-Reply-To: <20111128172615.GA3241@prithivi.gnumonks.org>
References: <20111126181245.GI3773@prithivi.gnumonks.org>
	<1322499634.29909.49.camel@aeonflux>
	<20111128172615.GA3241@prithivi.gnumonks.org>
Message-ID: <1322568711.29909.55.camel@aeonflux>

Hi Harald,

> > > This data structure could also have the actual file content associated
> > > with each EF.
> > 
> > you might wanna have a look at oFono source code. At least for reading
> > EF and parsing them we have extensive support. Check src/simutil.[ch]
> > and src/simfs.[ch].
> 
> I will check, thanks for the hint.  However, I believe you are mostly
> dealing with DFtelecom, i.e. things like SMS, contact data, etc. - not
> so much with issues like preferred operator list, Kc, TMSI, SIM service
> table, etc.

actually we doing native EF handling as well. The whole directory
structure and all fancy difference between 2G and 3G SIM cards. oFono
does way more than any other open source telephony stack I have ever
seen. And we do get these things right, I might add :)

> But I will RTFS first, before making any more assumptions...

Just have a look. You might be able to re-use some parts since the whole
code is actually in C. Or at least get you started somehow. Depending on
what your goal is this code might be useful or not. It is somewhat tight
to our way of handling modems.

Regards

Marcel





From holger at freyther.de  Tue Nov 29 16:17:21 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Tue, 29 Nov 2011 17:17:21 +0100
Subject: [PATCH] usb: Do not send ZLP when we have filled the window
In-Reply-To: <4EBC31FB.1090800@freyther.de>
References: <1320877334-21799-1-git-send-email-holger@freyther.de>	<1320877334-21799-2-git-send-email-holger@freyther.de>
	<4EBC31FB.1090800@freyther.de>
Message-ID: <4ED50591.2030403@freyther.de>

On 11/10/2011 09:20 PM, Holger Hans Peter Freyther wrote:
> On 11/09/2011 11:22 PM, Holger Hans Peter Freyther wrote:
>> From: Holger Hans Peter Freyther <zecke at selfish.org>

Hi again,

i tested this patch by connecting the device to Mac OS X 10.6, Windows7 in
qemu/kvm (with -usb) and Dieter tested it by attaching yo his device. The
upgrade procedure is not tested yet but should be:

1.) flash the new DFU
2.) reboot with bootloader button pressed
3.) flash the new main_simtrace.bin