ADVERTENCIA << no flashear/rootear no es seguro, peligro de USB-Brick >> - Página 8

SimonCT · 20/05/10, 16:42:05

Estoy con shaew, puede que exista ese switch (solo he mirado la parte de codigo que habeis pegado) y parece que en el fondo sea solo un sistema para detectar errores muy graves. Tal vez en el fondo no sea más que un sistema de deteccion de errores que bloquea el terminal con ciertos estados (tienen que guardarse estados en alguna parte por que sino una variable se perdería cuando se reinicia el sistema) para que los de HTC (o gente que entienda) puedan analizar esos estados y detectar el error.

Saludos

shawe · 20/05/10, 16:45:02

Cita:

Originalmente Escrito por SimonCT

Estoy con shaew, puede que exista ese switch (solo he mirado la parte de codigo que habeis pegado) y parece que en el fondo sea solo un sistema para detectar errores muy graves. Tal vez en el fondo no sea más que un sistema de deteccion de errores que bloquea el terminal con ciertos estados (tienen que guardarse estados en alguna parte por que sino una variable se perdería cuando se reinicia el sistema) para que los de HTC (o gente que entienda) puedan analizar esos estados y detectar el error.

Saludos

Yo creo que los tiros van por ahí, junto al modo de activar el debug que a la vez bloqueen otros aspectos no digo que no, ya que así tienen un teléfono "estropeado" que realmente se puede verificar que no lo esta para así no tener que cubrir garantías que no son garantías.

SimonCT · 20/05/10, 16:50:28

Sip, pero vamos que a mi parecer en el fondo creo que es un control de errores que se les ha ido un popco de las manos, aun que es cierto, bloqueando todo haces que el movil no reciba más modificaciones ni alteraciones para poder arreglar el error real. Como me hubiera gustado poder hacer esto en algunos de mis curros......

shawe · 20/05/10, 16:56:50

Cita:

Originalmente Escrito por SimonCT

Sip, pero vamos que a mi parecer en el fondo creo que es un control de errores que se les ha ido un popco de las manos, aun que es cierto, bloqueando todo haces que el movil no reciba más modificaciones ni alteraciones para poder arreglar el error real. Como me hubiera gustado poder hacer esto en algunos de mis curros......

Por eso lo comento como posibilidad, veo que mas o menos barajamos la misma posibilidad

LluisAzm · 20/05/10, 17:09:09

Pues si que parece aleatorio el tema... A esperar que salgan noticias, a la que se vaya entendiendo el código se podrán ver agujeros, que siempre hay.

Un saludo y tengamos paciencia!

SimonCT · 20/05/10, 17:09:51

Lo que no se es donde se guardarán esos estados en los terminales, en alguna parte de la ROM, supongo. No tengo Desire, solo elucubro, ¿Se puede acceder a algo del terminal cuando se brikea? supongo que si, por que los de HTC lo podrán resolver, sino es una chorrada de sistema de control de errores. Si se pudiera mapear esos estados.....

shawe · 20/05/10, 17:15:57

Cita:

Originalmente Escrito por SimonCT

Lo que no se es donde se guardarán esos estados en los terminales, en alguna parte de la ROM, supongo. No tengo Desire, solo elucubro, ¿Se puede acceder a algo del terminal cuando se brikea? supongo que si, por que los de HTC lo podrán resolver, sino es una chorrada de sistema de control de errores. Si se pudiera mapear esos estados.....

Supongo que se podrá indicar de algún modo que un contador se mantenga en memoria, ni que fuera guardando ese valor en un archivo.

SimonCT · 20/05/10, 17:30:37

Cita:

Originalmente Escrito por shawe_ewahs

Supongo que se podrá indicar de algún modo que un contador se mantenga en memoria, ni que fuera guardando ese valor en un archivo.

Es lo que digo, que tiene que ir en algun fichero (ROM) ya que la memoria (RAM) es volatil y desaparece en el reinicio, a no ser que durante los reinicios realmente no este reiniciando la memoria.

Aun asi si se quita la bateria durante unos segundos debería desaparecer cualquier valor almacenado en la RAM a no ser que el Desire tenga algun tipo de "Pila" interna, como algunas placas base.

¿Alguien sabe como han visto ese switch los de xda/modaco que dicen que esta siempre presente en los bricks?

fushi · 20/05/10, 17:31:52

el archivo devices.c del kernel desirec_2.6.29_8a03cb9a.tar.bz2 es identico y no tiene metido este trozo de codigo entero:

static void *usb_base;
#define MSM_USB_BASE ((unsigned)usb_base)
static unsigned ulpi_read(void __iomem *usb_base, unsigned reg)
{
unsigned timeout = 100000;
/* initiate read operation *
writel(ULPI_RUN | ULPI_READ | ULPI_ADDR(reg),
USB_ULPI_VIEWPORT);
/* wait for completion *
while ((readl(USB_ULPI_VIEWPORT) & ULPI_RUN) && (--timeout))
cpu_relax();
if (timeout == 0) {
printk(KERN_ERR "ulpi_read: timeout %08x\n",
readl(USB_ULPI_VIEWPORT));
return 0xffffffff;
}
return ULPI_DATA_READ(readl(USB_ULPI_VIEWPORT));
}
static int ulpi_write(void __iomem *usb_base, unsigned val, unsigned reg)
{
unsigned timeout = 10000;
/* initiate write operation *
writel(ULPI_RUN | ULPI_WRITE |
ULPI_ADDR(reg) | ULPI_DATA(val),
USB_ULPI_VIEWPORT);
/* wait for completion *
while ((readl(USB_ULPI_VIEWPORT) & ULPI_RUN) && (--timeout))
cpu_relax();
if (timeout == 0) {
printk(KERN_ERR "ulpi_write: timeout\n");
return -1;
}
return 0;
}
#define CLKRGM_APPS_RESET_USBH 37
#define CLKRGM_APPS_RESET_USB_PHY 34
static void msm_hsusb_apps_reset_link(int reset)
{
int ret;
unsigned usb_id = CLKRGM_APPS_RESET_USBH;
if (reset)
ret = msm_proc_comm(PCOM_CLK_REGIME_SEC_RESET_ASSERT,
&usb_id, NULL);
else
ret = msm_proc_comm(PCOM_CLK_REGIME_SEC_RESET_DEASSERT,
&usb_id, NULL);
if (ret)
printk(KERN_INFO "%s: Cannot set reset to %d (%d)\n",
__func__, reset, ret);
}
static void msm_hsusb_apps_reset_phy(void)
{
int ret;
unsigned usb_phy_id = CLKRGM_APPS_RESET_USB_PHY;
ret = msm_proc_comm(PCOM_CLK_REGIME_SEC_RESET_ASSERT,
&usb_phy_id, NULL);
if (ret) {
printk(KERN_INFO "%s: Cannot assert (%d)\n", __func__, ret);
return;
}
msleep(1);
ret = msm_proc_comm(PCOM_CLK_REGIME_SEC_RESET_DEASSERT,
&usb_phy_id, NULL);
if (ret) {
printk(KERN_INFO "%s: Cannot assert (%d)\n", __func__, ret);
return;
}
}
#define ULPI_VERIFY_MAX_LOOP_COUNT 3
static int msm_hsusb_phy_verify_access(void __iomem *usb_base)
{
int temp;
for (temp = 0; temp < ULPI_VERIFY_MAX_LOOP_COUNT; temp++) {
if (ulpi_read(usb_base, ULPI_DEBUG) != (unsigned)-1)
break;
msm_hsusb_apps_reset_phy();
}
if (temp == ULPI_VERIFY_MAX_LOOP_COUNT) {
pr_err("%s: ulpi read failed for %d times\n",
__func__, ULPI_VERIFY_MAX_LOOP_COUNT);
return -1;
}
return 0;
}
static unsigned msm_hsusb_ulpi_read_with_reset(void __iomem *usb_base, unsigned reg)
{
int temp;
unsigned res;
for (temp = 0; temp < ULPI_VERIFY_MAX_LOOP_COUNT; temp++) {
res = ulpi_read(usb_base, reg);
if (res != -1)
return res;
msm_hsusb_apps_reset_phy();
}
pr_err("%s: ulpi read failed for %d times\n",
__func__, ULPI_VERIFY_MAX_LOOP_COUNT);
return -1;
}
static int msm_hsusb_ulpi_write_with_reset(void __iomem *usb_base,
unsigned val, unsigned reg)
{
int temp;
int res;
for (temp = 0; temp < ULPI_VERIFY_MAX_LOOP_COUNT; temp++) {
res = ulpi_write(usb_base, val, reg);
if (!res)
return 0;
msm_hsusb_apps_reset_phy();
}
pr_err("%s: ulpi write failed for %d times\n",
__func__, ULPI_VERIFY_MAX_LOOP_COUNT);
return -1;
}
static int msm_hsusb_phy_caliberate(void __iomem *usb_base)
{
int ret;
unsigned res;
ret = msm_hsusb_phy_verify_access(usb_base);
if (ret)
return -ETIMEDOUT;
res = msm_hsusb_ulpi_read_with_reset(usb_base, ULPI_FUNC_CTRL_CLR);
if (res == -1)
return -ETIMEDOUT;
res = msm_hsusb_ulpi_write_with_reset(usb_base,
res | ULPI_SUSPENDM,
ULPI_FUNC_CTRL_CLR);
if (res)
return -ETIMEDOUT;
msm_hsusb_apps_reset_phy();
return msm_hsusb_phy_verify_access(usb_base);
}
#define USB_LINK_RESET_TIMEOUT (msecs_to_jiffies(10))
void msm_hsusb_8x50_phy_reset(void)
{
u32 temp;
unsigned long timeout;
printk(KERN_INFO "msm_hsusb_phy_reset\n");
usb_base = ioremap(MSM_HSUSB_PHYS, 4096);
msm_hsusb_apps_reset_link(1);
msm_hsusb_apps_reset_phy();
msm_hsusb_apps_reset_link(0);
/* select ULPI phy *
temp = (readl(USB_PORTSC) & ~PORTSC_PTS);
writel(temp | PORTSC_PTS_ULPI, USB_PORTSC);
if (msm_hsusb_phy_caliberate(usb_base)) {
usb_phy_error = 1;
return;
}
/* soft reset phy *
writel(USBCMD_RESET, USB_USBCMD);
timeout = jiffies + USB_LINK_RESET_TIMEOUT;
while (readl(USB_USBCMD) & USBCMD_RESET) {
if (time_after(jiffies, timeout)) {
pr_err("usb link reset timeout\n");
break;
}
msleep(1);
}
usb_phy_error = 0;
return;
}
---
todo esto es lo que hay de mas de codigo

shawe · 20/05/10, 17:34:16

El que tienes que mirar realmente es este: bravo_54b7033a.tar.gz lo tienes en el wuala en grupo (en XDA y en MoDaCo han usado el "bravo_" y no el "desirec_") que esta enlazado en mi firma, aunque supongo que ese archivo estará en los últimos terminales igualmente.

Y para pegar código mejor hacerlo en http://pastebin.com y aquí pegáis el enlace, porque sino esto al final acabará siendo solo código

SimonCT · 20/05/10, 17:50:28

Mejor usar la etiqueta de code, que en el curro no puedo entrar en pastebin :-P

El ULPI es el modulo que se encarga del USB como decian al principio, parece ser que el contador se acumula cuando no puede leer del USB al intentar inicializarlo/calibrarlo. A ver si este finde puedo mirar el codigo

Yo no voy a resolver nada, pero espero poder ir "traduciendo" y poder ver que es lo que haran los gurus para resolverlo.

borja487 · 20/05/10, 18:44:04

Yo tengo la rom stock con el root, no he upgradeado la radio ni he instalado el apps2sd ni nada, creeis que si no flasheo nada hasta que la cosa este segura, estoy a salvo?

De momento me va todo perfecto, me pilla el usb, me carga correctamente y no he notado nada raro...

brujomen · 20/05/10, 18:46:12

Cita:

Originalmente Escrito por borja487

Yo tengo la rom stock con el root, no he upgradeado la radio ni he instalado el apps2sd ni nada, creeis que si no flasheo nada hasta que la cosa este segura, estoy a salvo?

De momento me va todo perfecto, me pilla el usb, me carga correctamente y no he notado nada raro...

En principio si ya flasheaste y te fue bien no debes tener problemas, ya no hagas nada mas hasta nuevas noticias y que se resuelva el problema.

Saludos

Flak69 · 20/05/10, 19:58:14

Hola, con está movida, sí ahora saliese la actualización OTA, habría problemas en aplicar la actualización ?

Sent from my HTC Desire using Tapatalk

shawe · 20/05/10, 20:00:49

Cita:

Originalmente Escrito por mlortej

Hola, con está movida, sí ahora saliese la actualización OTA, habría problemas en aplicar la actualización ?

Sent from my HTC Desire using Tapatalk

Supongo que básicamente dejaríamos de ser root, ya que sera como el RUU de MoDaCo para desrootear.

Flak69 · 20/05/10, 20:03:53

Bien, pero crees que se puede correr riesgo de brikeo.

Sent from my HTC Desire using Tapatalk

**fozzy** · 20/05/10, 20:25:26

Cita:

Originalmente Escrito por mlortej

Bien, pero crees que se puede correr riesgo de brikeo.

Sent from my HTC Desire using Tapatalk

Con una OTA, nopuedes brickear... si se brickea estonces es por fallo de HTC y garantía.

brujomen · 20/05/10, 20:28:05

A esperar la 2.2 que teniendo lo de poder meter aplicaciones en la tarjeta ya con eso me sobra jeje

devil360 · 20/05/10, 20:28:21

No tenemos ninguna novedad para lo de root ????
Gracias.

**fozzy** · 20/05/10, 20:44:28

Cita:

Originalmente Escrito por devil360

No tenemos ninguna novedad para lo de root ????
Gracias.

No aun no, los foros estan muy parados... creo que esto va pa largo.

Menu