Monthly Archives: Octubre 2009

Instalando uBoot en una mini2440 (Friendlyarm)

2
Posted by javieralso on 24 Octubre 2009 – 14:08
Filed under ARM, Embedded, GNU, mini2440
Tagged as , , ,

Introducción

Como he comentado anteriormente, u-boot es un bootloader totalmente libre para dispositivos empotrados de bajo poder computacional. Entre sus múltiples posibilidades, están las de particionar la memoría flash del dispostivo en el que se encuentre corriendo, asignar nombre a dichas particiones, cargar imágenes en RAM desde distintas fuentes, volcarlas a flash, y un largo etcétera….
Aquí hablaré de las opciones que a mi juicio pueden ser mas socorridas para la instalación de un Sistema Operativo en un dispositivo empotrado, en mi caso, tomando como ejemplo la tarjeta de desarrollo mini2440 comentada anteriormente, aunque como es de suponer, las mismas operaciones pueden ser realizadas en distintas plataformas hardware.
Así pues vamos a lo divertido del asunto ¡¡Empezamos!!

Instalando

El proceso de instalación de u-boot consiste básicamente en cargar una imagen de u-boot en la RAM de nuestrá máquina, bien a través de su propio bootloader, bien a través de un JTAG. Una vez cargado en RAM, se lanza y se le dice que se (auto)guarde en la flash de nuestra tarjeta. En este caso y dependiendo de nuestro hardware, puede sobreescribir a su bootloader original o bien coexistir con él. En cualquier caso, deberás consultar el manual de tu tarjeta para comprobarlo.

Para el caso de la MINI2440, ésta viene con dos memorias Flash distintas: por un lado hay una flash NOR de 2MB en la que se encuentra almacenado el bootloader específico para los micros de Samsung (mirco de mi tarjeta de desarrollo): supervivi. Por otro lado, tenemos una memoria flash NAND de 128MB en la que se supone que irá nuestro sistema. En ésta memoria será en la que instalaremos u-boot, configurando posteriormente nuestra mini2440 para que arranque desde ahí (utilizando un conmutador que a tal efecto lleva instalado).

Para comenzar, necesitaremos descargarnos tanto el código fuente de u-boot como el software necesario para poder comunicarnos con supervivi y un compilador cruzado para ARM:

* u-boot:

  1. javieralso@rigoberto:~$ mkdir uboot; cd uboot
  2. javierlaso@rigoberto:~$ git clone git://repo.or.cz/u-boot-openmoko/mini2440.git
  3.  

* toolchain: Compiladores cruzados para ARM los hay muchos en esto de GNU. Yo, que seguí al dedillo todo lo que leí en montónes de blogs, usé el siguiente:

  1. javieralso@rigoberto:~$ wget http://www.codesourcery.com/sgpp/lite/arm/portal/package3696/public/arm-none-linux-gnueabi/arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
  2. javieralso@rigoberto:~$ unp  arm-none-linux-gnueabi/arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
  3. javieralso@rigoberto:~$ export PATH=$PATH:/home/rigoberto/arm-2008q3/bin

* Friendlyarm package: Se trata de un paquete con un uploader ya compilado para comunicarse con supervivi y de una imagen ya compilada de u-boot, que deberemos utilizar para cargar la imagen que compilemos nosotros. El por qué de usar dos imágenes de u-boot se explicará mas adelante.

  1. javieralso@rigoberto:~$ wget http://www.kernelconcepts.de/~fuchs/micro2440/friendlyarm2440-package.tar.bz2
  2. javieralso@rigoberto:~$ unp friendlyarm2440-package.tar.bz2

Una vez que lo tenemos todo descargado, empezaremos por compilar el bootloader, para ello no debemos olvidar añadir a nuestro PATH la ruta en la que se encuentran los binarios de la toolchain que usemos (como hicimos anteriormente). Una vez hecho esto, podemos pasar a compilar:

  1. javieralso@rigoberto:~$ cd uboot/mini2440
  2. javieralso@rigoberto:uboot/mini2440$ export CROSS_COMPILE=arm-none-linux-gnueabi-
  3. javieralso@rigoberto:uboot/mini2440$ make mini2440_config; make

Después de no mucho tiempo y si todo ha ido bien, deberemos tener un archivo llamado u-boot.bin en la carpeta donde hemos llevado a cabo la compilación. Esa es la imagen de u-boot que se almacenará en la flash de nuestra tarjeta, pero para poder llevar a cabo dicho proceso, necesitaremos otra versión de u-boot (sé que suena bastante raro, y de hecho lo es. Mas adelante explicaré el por qué de ello).

Bueno, llegados a este punto, cogemos nuestra mini2440, deslizamos el conmutador superior hacia la izquierda (para configurar el arranque desde la NOR), conectamos un módem nulo desde su puerto serie a un puerto serie de nuestra máquina y el device USB a un puerto USB libre. Tras ésto, arramcamos minicom y configuramos el puerto serie a 115200 Baudios, 8N1 y sin ningún tipo de contol de flujo.
Hecho ésto, solo queda encender nuestra tarjeta y comprobar que supervivi arranca:

  1. ##### FriendlyARM BIOS for 2440 #####
  2. [x] bon part 0 320k 2368k
  3. [v] Download vivi
  4. [k] Download linux kernel
  5. [y] Download root_yaffs image
  6. [c] Download root_cramfs image
  7. [a] Absolute User Application
  8. [n] Download Nboot
  9. [e] Download Eboot
  10. [i] Download WinCE NK.nb0
  11. [w] Download WinCE NK.bin
  12. [d] Download & Run
  13. [z] Download zImage into RAM
  14. [g] Boot linux from RAM
  15. [f] Format the nand flash
  16. [p] Partition for Linux
  17. [b] Boot the system
  18. [s] Set the boot parameters
  19. [t] Print the TOC struct of wince
  20. [u] Backup NAND Flash to HOST through USB(upload)
  21. [r] Restore NAND Flash from HOST through USB
  22. [q] Goto shell of vivi
  23. Enter your selection:

Seleccionamos la opción q para acceder a la shell de superivi y después le diremos que queremos cargar una imagen en la memoria y arrancar, pero para ello, antes deberemos saber cuando ocupa el bootloader que vamos a cargar (el que ya viene compilado), así que volvemos a la carpeta en la que lo descomprimimos y lo comprobamos:

  1. javieralso@rigoberto:friendlyarm2440-package$ ls -l
  2. …………………..
  3. …………………..
  4. -rwxr-xr-x   1 javieralso javieralso 239016 oct 24 11:38 u-boot.bin
  5. …………………..
  6. …………………..

Podemos ver que ocupa 239016 bytes. Guardamos este dato, nos será util para lo que comentamos anteriormente.

  1. Enter your selection:q
  2. Supervivi> load flash 0 239016 u
  3. USB host is connected. Waiting a download.

Con esto le hemos dicho a supervivi que queremos cargar 239016 bytes de datos (observad que es la misma cantidad de bytes que ocupa la imagen de u-boot) en la RAM de la tarjeta. Ahora supervivi se ha quedado esperando los datos, que deberemos envíarselos vía USB. Habiendo conectado el cable USB como se indicó antes ejecutamos el uploader:

  1. javieralso@rigoberto: friendlyarm2440-package$ sudo ./s3c2410_boot_usb u-boot.bin

que deberá ser llamado desde la carpeta friendlyarm2440-package y con sudo para poder tener acceso al puerto USB.

Si todo ha ido bien, supervivi debería mostar algo como esto:

  1. Now, Downloading [ADDRESS:30000000h,TOTAL:232706]
  2. RECEIVED FILE SIZE:  239016 (28KB/S, 8S)
  3. Downloaded file at 0×30000000, size = 232696 bytes
  4. Found block size = 0x0003c000
  5. Erasing…    … done
  6. Writing…    … done
  7. Written 239016 bytes
  8. Supervivi>

Ahora, arrancamos u-boot:

  1. Supervivi> go 0×30000000

y ya está, nuestra tarjeta arrancará u-boot:

  1. U-Boot 1.3.2-mini2440 (May 15 2009 – 21:24:49)
  2. I2C:   ready
  3. DRAM:  64 MB
  4. Flash:  2 MB
  5. NAND:  Bad block table not found for chip 0
  6. Bad block table not found for chip 0
  7. 64 MiB
  8. *** Warning – bad CRC or NAND, using default environment
  9. USB:   S3C2410 USB Deviced
  10. In:    serial
  11. Out:   serial
  12. Err:   serial
  13. MAC: 08:08:11:18:12:27
  14. Hit any key to stop autoboot:  0

Lo primero que ha hecho u-boot al arranchar ha sido darnos un mensaje de alerta indicando que el contenido de las variables de entorno no está fijado y de ahí el error CRC que se ve. Éstas variables de entorno son necesarias para que u-boot pueda configurarse al arrancar, pero antes de crearlas debemos de preparar la memoria NAND.

Para preparar la NAND, lo primero que haremos será borrar el listado de sectores defectuosos y volver a crearlo nosotros. Los sectores defectuosos son una lista, generalmente almacenada en fábrica, que indica qué sectores de la NAND son defectuosos. Lo normal es que haya alguno y con el tiempo y el uso se irán incrementando.

  1. MINI2440 # nand scrub
  2. NAND scrub: device 0 whole chip
  3. Warning: scrub option will erase all factory set bad blocks!
  4.          There is no reliable way to recover them.
  5.          Use this command only for testing purposes if you
  6.          are sure of what you are doing!
  7. Really scrub this NAND flash? <y/N>
  8. Erasing at 0x33d4000 —  81% complete.
  9. NAND 64MiB 3,3V 8-bit: MTD Erase failure: -5
  10. Erasing at 0x3ffc000 — 100% complete.
  11. Bad block table not found for chip 0
  12. Bad block table not found for chip 0
  13. OK
  14. MINI2440 #

Con el comando anterior borramos la lista de sectores defectuosos antes mencionada. Después de haber hecho la limpieza, creamos nuestra propia tabla (también conocida como BBT):

  1. MINI2440 # nand createbbt
  2. Create BBT and erase everything ? <y/N>
  3. Skipping bad block at  0×03410000                                            
  4. Skipping bad block at  0x03ff0000                                            
  5. Skipping bad block at  0x03ff4000                                            
  6. Skipping bad block at  0x03ff8000                                            
  7. Skipping bad block at  0x03ffc000                                            
  8. Creating BBT. Please wait …Bad block table not found for chip 0
  9. Bad block table not found for chip 0
  10. Bad block table written to 0x03ffc000, version 0×01
  11. Bad block table written to 0x03ff8000, version 0×01

Este proceso es relativamente lento, por lo que habrá que esperar que esperar (3-4 minutillos), así que mientras tanto, busca una tarjeta SD y copia el binario u-boot.bin QUE COMPILASTE en dicha tarjeta. La cargaremos desde ahí.

Una vez que tenemos nuestra SD con el binario cargado y que ya se ha generado la nueva BBT, introducimos la tarjeta en el lector de la mini2440 y le decimos a u-boot que la detecte:

  1. MINI2440 # mmcinit
  2. trying to detect SD Card…
  3. Manufacturer:       0×30, OEM "SD"
  4. Product name:       "SU02G", revision 8.0
  5. Serial number:      3489032
  6. Manufacturing date: 9/2010
  7. CRC:                0×27, b0 = 1
  8. READ_BL_LEN=15, C_SIZE_MULT=7, C_SIZE=365
  9. size = 1642070016

Con la tarjeta ya detectada, cargamos u-boot.bin en la RAM:

  1. MINI2440 # fatload mmc 0:1 0×32000000 u-boot.bin
  2.  
  3. 233412 bytes read

¿Qué ha pasado? pues que le hemos dicho a u-boot que cargue el archivo binario u-boot.bin desde un sistema de archivos FAT (fatload), ubicado en la SD (mmc), dispositivo 1, primera partición (0:1), a partir de la dirección de memoria 0×32000000.

Una vez que tenemos el archivo en RAM, lo volcamos a la NAND:

  1. MINI2440 # nand write.e 0×32000000 0×0 0x38fc4
  2. NAND write: device 0 offset 0×0, size 0x38fc4
  3. Writing data at 0x38c00 — 100% complete.
  4.  233412 bytes written: OK

Bueno, en este caso, hemos escrito 0x38fc4 bytes (233412, para que nos entendamos), al comienzo de la NAND. El numerajo hexadecimal, como hemos visto corresponde al peso de u-boot.bin pero ésta vez del que hemos compilado NOSOTROS, no del que cargamos en RAM al principio. Importante no confundir ésto. Un apunte importante es que en ésta parte del proceso, la longitud deberá darse en hexadecimal, no en decimal, ya que ello puede dar lugar a errores.

Por lo que he leído por ahí, el modificador .e del comando write se utiliza para generar códigos de correción de errores y evitar así lo posibles bloques defectuosos que pueda haber en la NAND (recordad el comando createbbt de antes).

Una vez hecho esto, podemos reiniciar tranquilos nuestra mini2440: u-boot la hará arrancar. Aunque no hará mucho mas ya que la NAND está completamente borrada y no hay sistema.

Para finalizar debemos indicar a u-boot donde está la partición dedicada a las variables de entorno. Para ello primero debemos de conocer la tabla de particiones de nuestra memoria NAND, que deberá estar formateada de fábrica (si no es así puede hacerse desde el menú de supervivi). El comando mtdparts nos proporcionará dicha información:

  1. MINI2440 # mtdparts
  2.  
  3. device nand0 <mini2440-nand>, # parts = 4
  4.  #: name                        size            offset          mask_flags
  5.  0: u-boot              0×00040000      0×00000000      0
  6.  1: env                 0×00020000      0×00040000      0
  7.  2: kernel              0×00500000      0×00060000      0
  8.  3: root                0x07aa0000      0×00560000      0
  9.  
  10. active partition: nand0,0 – (u-boot) 0×00040000 @ 0×00000000
  11.  
  12. defaults:
  13. mtdids  : nand0=mini2440-nand
  14. mtdparts: <NULL>

Podemos ver que tenemos cuatro particiones cuyos nombres son bastante descriptivos. La partición 1, env será la utilizada para las variables de entorno de u-boot, así que con dynenv lo configuramos:

  1. MINI2440 # dynenv set 40000
  2. device 0 offset 0×40000, size 0x7fc0000
  3. 45 4e 56 30 – 00 00 04 00

El comando introducido ha configurado la ubicación de las variables de entorno a partir de la dirección 0×40000, que como se puede ver en la tabla de particiones mostrada anteriormente, es la dirección offset (de comienzo) de la partición asignada a tal efecto.

Una vez configurada la ubicación de las variables de entorno, almacenamos la configuración con el comando saveenv:

  1. MINI2440 # saveenv
  2. Saving Environment to NAND…
  3. Erasing Nand…Writing to Nand… done

Y listo, ya tenemos u-boot instalado.

Para finalizar os contaré por qué antes utilicé dos versiones distintas de uboot. El motivo es que para instalar uboot, primero debe residir en la RAM y poderse ejecutar desde ahí, ya que hay que hacer una limpieza de la NAND antes de llevar a cabo la instalación propiamente dicha. Lo que observé entonces fue que las versiones de uboot que conseguían arrancar desde la RAM, no eran capaces de hacerlo luego una vez que se instalaban en NAND (en efecto, según los manuales que leí, una vez creada la BBT, se escribía el contenido de la RAM a la NAND, ya que allí es donde está uboot) y viceversa, las imágenes que si que eran capaces de arrancar desde la NAND no lo podían hacer desde la RAM. No sé si esto es por algún bug en uboot (que deberían ser entonces bugs distintos en cada una de las versiones) o porque yo hice algo mal (repetí montones de veces lo que vi en tutos, blogs y demás paso por paso). El caso es que después de varios intentos sin mucho éxito, decidí hacerlo tal y como lo he explicado aquí.

En el futuro….

En próximas recetas, explicaré qué comandos básicos utilizar en u-boot para cargar imágenes en RAM o NAND, configurar el arranque automático desde distintas fuentes, particionar la NAND, configurar opciones de arranque para el S.O. que tengamos y alguna cosilla mas. Evito poner esa información aquí para no sobrecargar demasíado esta receta, que se supone que tienen que ser breves y concisas.

Referencias

Muchas y muy variadas, aunque las mas importantes son éstas.

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL.

Configuración de módem Huawei en GNU/Linux

0
Posted by javieralso on 22 Octubre 2009 – 11:38
Filed under GNU, Redes
Tagged as ,

Introducción

Si tienes una línea móvil de datos y un módem usb, tal vez te apetezca poder utilizarlo en tu GNU/Linux. Actualmente, los modems Huawei son los mas utilizados para éste tipo de propósitos. Aquí explico lo que hay que hacer para poder dar soporte al modelo Huawei E160, un módem que por lo que he podido probar, funciona pero que muy bien bajo GNU/Linux

Empezando

¿Cómo saber si tu modem es el soportado? (bueno, en principio cualquier módem Huawei debería funcionar sin problemas). Sencillo, después de pinchar el módem en tu puerto USB y tras ejecutar lsusb, lo verás:

  1. javieralso@rigoberto:~$ Bus 001 Device 008: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem

Además, la salida de dmesg deberá mostrar algo como ésto:

  1. javieralso@rigoberto:~$ dmesg
  2. ………….
  3. [ 4180.956314] usb 1-4.3: new high speed USB device using ehci_hcd and address 7
  4. [ 4181.067257] usb 1-4.3: New USB device found, idVendor=12d1, idProduct=1003
  5. [ 4181.067260] usb 1-4.3: New USB device strings: Mfr=2, Product=1, SerialNumber=0
  6. [ 4181.067262] usb 1-4.3: Product: HUAWEI Mobile
  7. [ 4181.067264] usb 1-4.3: Manufacturer: HUAWEI Technology
  8. [ 4181.067376] usb 1-4.3: configuration #1 chosen from 1 choice
  9. [ 4181.072393] usb-storage: probe of 1-4.3:1.0 failed with error -1
  10. [ 4181.179711] usb 1-4.3: USB disconnect, address 7

Este tipo de módems, además de su función principal (la de módem), también pueden utilizarse como lector de tarjetas microSD. El problema aquí, es que por lo que he visto, necesitan un driver muy específico para esto último y por eso, bajo GNU/Linux no lo he podido hacer funcionar. De todas formas, lectores de tarjetas microSD los hay a patadas, así que que no nos hace falta sobrecargar a nuestro pobre modem.
Lo que si que sucede, es que una vez que se conecta el módem al puerto USB, la configuración que se activa por defecto parece ser la del lector microSD, así que tendremos que cambiar esto para poder acceder al pincho como módem que es lo que nos interesa. Empecemos pues.

usb-modeswitch

usb-modeswitch permite realizar exactamente lo que comentaba antes, es decir, cambiar la configuración seleccionada del módem para que pueda actuar como tal. Parece ser que es paquete Debian, así que si utilizas éste Sistema Operativo, ya sabes:

  1. javieralso@rigoberto:~$ apt-get install usb-modeswitch

Además de usb-modeswitch, también necesitaremos ivman para poder detectar cuando se conecta el módem a nuestro equipo y autoconfigurarlo llamando a usb-modeswitch…

  1. javieralso@rigoberto:~$ apt-get install ivman

Configurandolo todo

Una vez que ya lo tienes todo instalado, solo falta escribir un poco de configuración para que el módem eche a andar. Una de las primeras cosas que debemos hacer, es configurar ivman para que arranque automáticamente al iniciar sesión. Éso se puede hacer fácilmente desde Sistema–>Preferencias–>Aplicaciones al inicio (Supongo que utilizarás gnome).
Después de ésto, abrimos el archivo $HOME/.ivman/IvmConfigActions.xml. Éste archivo dice a ivman qué tiene que hacer según qué eventos detectos detecte en la capa HAL. En nuestro caso, con añadir lo siguiente, debería ser mas que suficiente:

  1. <!– Change Huawei E160 Mode –>
  2.     <ivm:Match name="hal.storage.physical_device" value="/org/freedesktop/Hal/devices/usb_device_12d1_1003_noserial_if0">
  3.             <ivm:Option name="exec" value="xterm -e $HOME/.e160.sh" />
  4.     </ivm:Match>
  5. </ivm:ActionsConfig>
  6.  

Con ésto, lo que se le dice a ivman es que cuando detecte el módem insertado (se puede ver en la tercera línea como en el valor para la clave name se compone el nombre con el vendorID = 0x12d1 y el productID = 0×1003, que se obtuvieron al ejecutar lsusb) ejecute el script $HOME/.e160.sh. En éste script están los comando para activar usb-modeswitch y hacer que configure correctamente el módem.

Dicho script tiene el siguiente contenido:

  1. #!/bin/bash
  2.  
  3. if [ -z "`/bin/ls /dev/ttyUSB0`" ]; then
  4.         if [ "`/usr/sbin/lsusb | grep 12d1 | cut -d : -f3 | cut -b -4`" = "1003" ]; then
  5. #                /usr/bin/usb_modeswitch -v 12d1 -p 1003 -d 1
  6.                 /usr/bin/usb_modeswitch -v 12d1 -p 1003 -H 1
  7.         fi
  8. fi
  9.  

No olvides darle permisos de ejecución después de editarlo.

En principio con ésto, el módem quedaría perfectamente configurado. Sería aconsejable reiniciar gdm, pues ivman crea su propio usuario y puede que no funcione correctamente hasta que no salgas y vuelvas a entrar al sistema (no hace falta reiniciar, que ésto es GNU/Linux :-P )

Si todo ha ido bien, cuando insertes el módem, dmesg te debería devolver algo como ésto:

  1. javieralso@rigoberto:~$ dmesg
  2. …………..
  3. [16197.508056] usb 2-6: new high speed USB device using ehci_hcd and address 12
  4. [16197.655583] usb 2-6: New USB device found, idVendor=12d1, idProduct=1003
  5. [16197.655590] usb 2-6: New USB device strings: Mfr=2, Product=1, SerialNumber=0
  6. [16197.655596] usb 2-6: Product: HUAWEI Mobile
  7. [16197.655600] usb 2-6: Manufacturer: HUAWEI Technology
  8. [16197.655756] usb 2-6: configuration #1 chosen from 1 choice
  9. [16197.742661] Initializing USB Mass Storage driver…
  10. [16197.743679] usb-storage: probe of 2-6:1.0 failed with error -1
  11. [16197.743727] usbcore: registered new interface driver usb-storage
  12. [16197.743732] USB Mass Storage support registered.
  13. [16197.744153] usb 2-6: USB disconnect, address 12
  14. [16205.112108] usb 2-6: new high speed USB device using ehci_hcd and address 13
  15. [16205.255571] usb 2-6: New USB device found, idVendor=12d1, idProduct=1003
  16. [16205.255578] usb 2-6: New USB device strings: Mfr=2, Product=1, SerialNumber=0
  17. [16205.255584] usb 2-6: Product: HUAWEI Mobile
  18. [16205.255588] usb 2-6: Manufacturer: HUAWEI Technology
  19. [16205.255737] usb 2-6: configuration #1 chosen from 1 choice
  20. [16205.262311] usb-storage: probe of 2-6:1.2 failed with error -1
  21. [16205.263306] usb-storage: probe of 2-6:1.3 failed with error -1
  22. [16205.343381] usbcore: registered new interface driver usbserial
  23. [16205.343408] USB Serial support registered for generic
  24. [16205.343497] usbcore: registered new interface driver usbserial_generic
  25. [16205.343501] usbserial: USB Serial Driver core
  26. [16205.354928] USB Serial support registered for GSM modem (1-port)
  27. [16205.355014] option 2-6:1.0: GSM modem (1-port) converter detected
  28. [16205.355174] usb 2-6: GSM modem (1-port) converter now attached to ttyUSB0
  29. [16205.355192] option 2-6:1.1: GSM modem (1-port) converter detected
  30. [16205.355278] usb 2-6: GSM modem (1-port) converter now attached to ttyUSB1
  31. [16205.355311] usbcore: registered new interface driver option
  32. [16205.355315] option: v0.7.2:USB Driver for GSM modems

Aquí se puede ver que el módem se detecta, se activa el soporte para almacenamiento masivo y después se cambia al modo módem.

Conectando a Internet

Bueno, pues ahora ya solo queda que te conectes a internet utilizando la compañia que mas te guste. Yo personalmente y llegados a éste punto, me leería un par de recetas pelín antiguas que explican como configurar las opciones de acceso a un operador concreto (en realidad es Simyo) utilizando wvidial o también gnome-ppp.

Ahí se pueden ver las opciones de configuración para el operador dado. Si utilizas otro operador, el número de marcado y demás serán distintos, así que tendrás que ponerte en contacto con ellos para que te lo faciliten. Coser y cantar ;-)

Referencias

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL.