[COMO] Actualizacion software para la ampliacion de memoria.

Hola a todos.

Desde hace tiempo llevo con ganas de realizar una ampliación de memoria en mi Slug. Finalmente, me he buscado la vida para meter un par de chips 16Mx16 (marca Micron, son relativamente fáciles de encontrar.). Una vez se ha hecho la ampliación y crees que ya está, lo normal es darse cuenta de que aun queda trabajo por delante ;)

Lo que pretendo en este documento es explicar los pasos que he dado para actualizar el cargador de arranque de primer nivel y también el de segundo nivel (introducido en la RC1 de Debian Etch).

Para hacer esto necesitarás:

- NSLU2 con la memoria ampliada.
- Una plaquita con un MAX3232, ICL3232 o similar para sacar el puerto serie.
- El código fuente de Apex.
- Un interfaz JTAG, te puedes hacer uno casero tipo Wiggler (Opcional pero muy recomendado por si algo va mal).
- Un toolchain para armv5b (arm big-endian) y otro para arm (arm little-endian). Para arm BE puedes usar el toolchain que se genera con el MasterMakefile de openslug y para arm LE el que proporciona emdebian.

Empecemos suponiendo que tienes todo lo anterior, el puerto serie funciona y tienes el fuente de Apex preparado. El primer paso es sustituir el Redboot por Apex para habilitar toda la memoria. Después, en el caso de que se use Debian, es necesario sustituir el cargador de segundo nivel por otro que sea capaz de pasar la linea de comando correcta al kernel.

¡Manos a la obra!

1 PASO: SUSTITUIR REDBOOT POR APEX

Copia la configuración de Apex para openslug y entra en el menú de configuracion.

cd /usr/src/apex
cp src/mach-ixp42x/openslug_config .config
make menuconfig

Entra en General Setup, vete a la opción Cross compiler prefix y mete el prefijo del compilador armv5b, en mi caso: /opt/armv5b-softfloat-linux/gcc-3.3.5-glibc-2.2.5/bin/armv5b-softfloat-linux-
Ahora vete a Platform Setup para configurar el cargador según tu actualización de memoria. Si tienes 2 chips selecciona Enable SDRAM bank 0 y deja sin seleccionar Enable SDRAM bank 1. Si tienes 4 chips entonces selecciona los dos. En Size, in bytes, of each SDRAM bank introduce el tamaño hexadecimal en bytes de cada pareja de chips.
En mi caso tengo 64MB en un solo banco (dos chips) asi que selecciono solo el banco 0 y pongo 0x04000000 de tamaño.
Ya que estamos liados tambien conviene dejarlo todo para que si usamos openslug se pueda utilizar toda la memoria. Asi que vete a Environment, selecciona Default kernel command line y añade al final mem=64M@0x0.
Sal del programa de configuración, guardalo todo y compílalo.

make

Con esto ya tienes el binario del primer bootloader ("apex.bin"), pero antes de grabarlo conviene probarlo para asegurarnos de que funciona. Si no funciona y lo grabas solo podrás restaurar el Slug usando JTAG ¡Así que ojito!

Pon el circuito para el puerto serie y arranca el minicom (o cualquier derivado, pero debes asegurarte que tiene soporte para xmodem). Cuando enciendas el slug te aparecerá un "+". Pulsa Ctrl+C en este punto, espera unos segundos y aparecera la linea de comandos de Redboot. Ahora vamos a copiar el bootloader a RAM:

RedBoot> load -b 0x1000000 -r -m xmodem

Transfiere la imagen de Apex ("apex.bin") mediante xmodem. En el minicom se hace pulsando Ctrl+A para entrar en modo comando y luego una S para enviar ficheros.
Una vez se tiene el Apex en RAM solo queda ejecutarlo:

RedBoot> g 0x1000000

Aparecerá algo como esto:

APEX Boot Loader 1.4.7 -- Copyright (c) 2004,2005,2006 Marc Singer

APEX comes with ABSOLUTELY NO WARRANTY. It is free software and you
are welcome to redistribute it under certain circumstances.
For details, refer to the file COPYING in the program source.

apex => mem:0x00200000+0xdb20 (56096 bytes)
env => nor:120k+8k (no-write)

Use the command 'help help' to get started.

# copy nor:0x60010+0xffff0 0x00008000
1048560 bytes transferred

Presiona Ctrl+C para parar el proceso de arranque.

Si todo ha ido bien hasta este punto, ya se puede sobreescribir el RedBoot. Para ello haz lo siguiente:

apex> erase nor:0
apex> copy $apex nor:0

No hace falta volver a transferirlo por xmodem ya que se copia la imagen previamente grabada en RAM. Ahora reinicia el Slug y mira a ver si te carga correctamente el Apex.

apex> reset

Si lo hace, ya has hecho lo mas complicado. Si no, deberás utilizar el JTAG para restaurar el firmware.

2 PASO: SUSTITUIR EL CARGADOR DE SEGUNDO NIVEL DE DEBIAN POR APEX CON LA LINEA DE COMANDOS APROPIADA

A partir de este punto ya se puede probar, meter la pata y estar tranquilos de que podremos recuperar el Slug sin necesidad de JTAG (a no ser que seas muy bruto y te cargues la partición 0 de la flash).

El primer paso es preparar el segundo binario de Apex. Esta vez es algo mas complicado pero nada fuera de lo comun.

Copia la configuración de Apex para NSLU2 arm y entra en el menú de configuración

cd /usr/src/apex
cp src/mach-ixp42x/debian-nslu2-arm_config .config
make menuconfig

Entra en General Setup, vete a la opción Cross compiler prefix y mete el prefijo del compilador arm, en mi caso: /opt/arm-xscale-linux-gnu/gcc-4.0.3-glibc-2.3.6/bin/arm-xscale-linux-gnu-
Vuelve a configurar la memoria en Platform Setup (esto no es necesario pero por si acaso)
Ahora vete a Environment, selecciona Default kernel command line y añade al final mem=64M@0x0.
Sal del programa de configuración, guardalo todo y compílalo.

make

El binario que se obtiene es para little-endian así que ahora hay que hacer un "byteswapping" con el siguiente script (cortesia de Peter Korsgaard):

#!/usr/bin/python
# swap every 32bit word in input and write it to output

import array, sys

if len(sys.argv) != 3:
sys.stderr.write('Invalid arguments.\n')
sys.stderr.write('Usage: %s \n' % sys.argv[0])
sys.exit(1)

if sys.argv[1] == '-':
file = sys.stdin
else:
file = open(sys.argv[1], 'rb')

input = file.read()
a = array.array('I')
# add padding if needed
a.fromstring(input + '\0' * (4-len(input)&3))
a.byteswap()

if sys.argv[2] == '-':
file = sys.stdout
else:
file = open(sys.argv[2], 'wb')

a.tofile(file)


./byteswap.py apex.bin apex-swap.bin

Igual que antes, conviene probarlo antes de grabarlo a flash. Pon el circuito del puerto serie, abre el minicom y arranca el Slug. Presiona Ctrl+C para detener el arranque. Ahora vamos a transferir el binario por xmodem.

apex> xreceive 0x1000000

Aparecera una "C", en ese momento transfiere el binario "apex-swap.bin" por xmodem.
Ejecuta el nuevo cargador

apex> go 0x1000000

En este punto, por si acaso deberías probar si es capaz de arrancar debian asi que no pares el proceso de carga con Ctrl+C. Si arranca bien vamos a grabarlo en flash. Es muy importante grabarlo desde el primer Bootloader, NUNCA DESDE EL SEGUNDO.

Arranca el Slug y presiona Ctrl+C para entrar a la linea de comandos del Apex (REPITO, EL PRIMER APEX). Y ahora haz lo siguiente:

apex> xreceive 0x1000000

Transfiere "apex-swap.bin" por xmodem pero no lo arranques. Anotate el tamaño del fichero en hexadecimal.
Ahora grabalo en flash:

apex> erase nor:0x60000+0x20000
apex> copy mem:0x1000000+0xYYYY nor:0x60010 (donde 0xYYYY es el tamaño del fichero)

Ahora ya debería estar todo en su sitio asi que reinicia y comprueba que todo funciona bien.


p2p@pitufo:~$ free
total used free shared buffers cached
Mem: 62568 61160 1408 0 388 30212
-/+ buffers/cache: 30560 32008
Swap: 65528 24 65504

Si no arranca recuerda que siempre se puede volver a grabar el firmware que quieras con el primer Apex sin necesidad de utilizar el JTAG.

NOTA: Este proceso que describo me ha funcionado perfectamente y es seguro si se toman las precauciones necesarias. No obstante, no me responsabilizo de cualquier daño derivado de seguir esta guía.

Enviado por gerator el 19 Noviembre, 2006 - 12:43

Tened cuidado

Imagen de usuario

Pues eso ahora mismo estoy haciendo un cable JTAG para recuperar mi NSLU porque lo he inutilizado, cuando probé APEX arrancaba y cuando estaba terminando de cargar el kernel obtenía un kernel panic pensé que podía ser un contacto mal soldado de la memoria pero como apex funcionaba y arrancaba lo intente grabar pero me dio error y quedo inutilizado. Bueno ahora aprenderé algo más lo único es que no se como recuperar el NSLU por JTAG. ¿Alguno tenéis alguna idea? ya he estado curioseando por NSLU2-Linux pero no hay ningún HOWTO de recuperación por JTAG solo donde soldar los terminales del conector JTAG. Por cierto me fallaba la transmisión xmodem por minicom y lo tuve que hacer con Hyperterminal desde windows.

Enviado por bcorada el 1 Diciembre, 2006 - 17:37

JTAGando

Imagen de usuario

Pues a mi no me fallo nada, despues de cambiar un par de veces el apex de primer nivel, me debi equivocar en algo y un precioso posabasos.

No fue facil pero ya esta en marcha, si no lo has solucionado todavia, dimelo que te paso todo lo necesario, eso si, es lento de narices, youso marquina virtual de linux y calculo que tardo 1.30 horas en grabar mas la verificacion, lo deje toda la noche currando.

Estoy con un amigo preparando un foro especifico del tema donde explicaremos todo lo que hemos sufrido y disfrutado, cuando este disponible pondre un post con el link.

Enviado por qlfecv el 6 Diciembre, 2006 - 09:47

El JTAG efectivamente es

Imagen de usuario

El JTAG efectivamente es muy, muy lento. Lo mas rapido es grabar solo el Apex y despues grabar el resto de la flash desde el cargador de arranque.

Si estais haciendo algo sobre el Slug me encantaria colaborar, si buscais gente para añadir contenido o para lo que sea ponte en contacto conmigo (permito contacto en mi perfil). Por ejemplo se podria trabajar en lo de tener una lista de correo en castellano ;)

Un saludo.

Enviado por gerator el 7 Diciembre, 2006 - 09:43

Listo

Imagen de usuario

Gracias por vuestra ayuda no he tenido posibilidad de conectarme durante varios días, ya sabeis vacaciones con el puente pero no quería responderos hasta saber en que había fallado si Apex me funcionaba en memoria, una vez que lo he recuperado he vuelto a intentar grabar la misma imagen y esta vez salio bien creo que tuve que meter otro carácter en vez de el signo del dolar cuando intente grabar la imagen, ya se que es una chorrada pero creo que fue eso. Por cierto grabe el redboot sacado del DebianSlug 3.1 como indican en el howto y no entra en modo upgrade con el reset lo tuve que hacer desde la consola serie. Ahora solo me queda terminar de actualizar ya que sigo con el kernel de DebianSlug y solo tengo un Apex y del tirón arranca, haber si puedo usar toda la memoria que amplié porque creo que ha pesar de comprobar una por una todos los conectores con el multímetro alguno se me escapo y no esta correctamente soldado.

Enviado por bcorada el 7 Diciembre, 2006 - 10:20

Problemas con el segundo Apex

Imagen de usuario

Pues eso que no se si me estaré equivocando en algo os comento, he seguido los pasos de gerator compilando el Apex con la configuración de debian-nslu2-arm_config modificando mi memoria a dos bancos de 64 MB (0x4000000 en hexadecimal) y añadiendo en la linea del kernel mem=128M@0x0. El compilador es el gcc-arm 4.1.1-20 obtenido junto con las librerias de crosscompiler de www.emdebian.org (en concreto los paquetes gcc-4.1-arm-linux libc6-dev-arm-cross) con lo cual en el config el path al compilador es /usr/bin/arm-linux-gnu-. Lo compilo y no da errores lo paso por el scrip para cambiar los word que por cierto copiándolo de este foro me da error y lo tuve que coger de la pagina de Peter. Lo he transferido tanto desde el primer Apex como del segundo a memoria y en ambos hace lo mismo se inicia correctamente y comienza el arranque pero cuando ha terminado de descomprimir el kernel e intenta arrancar se queda bloqueado. Por cierto para hacer funcionar el xmodem en minicom hay que configurar algo porque estoy harto de cambiar de linux a windows para cargar en memoria con el hyperterminal de windows por que en minicom no me va la transmision xmodem ni en debian ni en ubuntu.

Enviado por bcorada el 7 Diciembre, 2006 - 21:42

Compilando para que use un banco

Imagen de usuario

Compilándolo para que use solo un banco si arranca reconociéndome 64 MB luego puede que haya algún problema cuando intenta acceder a los 128 MB. Voy a repasar las conexiones y os comento.

Enviado por bcorada el 7 Diciembre, 2006 - 22:38

Puede que el error este en

Imagen de usuario

Puede que el error este en el primer bootloader ¿Lo has compilado con la configuracion de openslug tambien para 128M?

Sobre el minicom... Yo no tuve que configurar nada especial para que me funcionase Xmodem aunque si recuerdo que al hacer transferencias en Redboot me daba un error de CRC aunque se recuperaba, luego con apex ya no me lo daba. Si no quieres reiniciar tambien puedes usar ckermit que creo (no estoy seguro) que tambien permitia hacer transferencias Xmodem.

Un saludo.

Enviado por gerator el 8 Diciembre, 2006 - 11:01

Solucion al fallo de minicom

Imagen de usuario

Si no os funciona el minicom en Debian o Ubuntu a la hora de mandar ficheros por xmodem puede ser que no hayais instalado el paquete lrzsz, es donde vienen los protocolos de envio.

Enviado por bcorada el 18 Diciembre, 2006 - 10:03

Despues de haberlo repasado todo

Imagen de usuario

Por si acaso lo he repasado todo y he vuelto a compilar los dos Apex y los he probado pero sigue igual, incluso he probado una configuración con 96 MB pero en cuanto tiene que acceder el kernel al segundo banco no arranca, os voy a pasar el log de arranque hasta que se inicia el kernel con la configuración de 64 MB el caso es que la variable ATAG_MEM que saca en pantalla Apex no debería indicar la longitud de la memoria 0x8000000 porque 0x4000000 seria solo el primer banco (64MB), ¿no será que Apex no indica que hay dos bancos de 64 MB a pesar de haber sido indicado en el config de los dos Apex?, fijaros que pasa en los dos Apex.

LOG DE ARRANQUE:

APEX Boot Loader 1.4.7 -- Copyright (c) 2004,2005,2006 Marc Singer

APEX comes with ABSOLUTELY NO WARRANTY. It is free software and you
are welcome to redistribute it under certain circumstances.
For details, refer to the file COPYING in the program source.

apex => mem:0x00200000+0xdb4c (56140 bytes)
env => nor:120k+8k (empty)

Use the command 'help help' to get started.

# copy nor:0x60010+0xffff0 0x00008000

|
/
-
\
|
1048560 bytes transferred

# wait 10 Type ^C key to cancel autoboot.
Type ^C key to cancel autoboot.

/
-
\
|
/
-
\
# boot
ATAG_HEADER
ATAG_MEM: start 0x00000000 size 0x04000000
ATAG_CMDLINE: (98 bytes) 'console=ttyS0,115200 rootfstype=jffs2 root=/dev/mtdblock4 rw init=/linuxrc noirqdebug mem=128M@0x0'
ATAG_END
Booting kernel at 0x00008000...

APEX Boot Loader 1.4.7 -- Copyright (c) 2004,2005,2006 Marc Singer

APEX comes with ABSOLUTELY NO WARRANTY. It is free software and you
are welcome to redistribute it under certain circumstances.
For details, refer to the file COPYING in the program source.

apex => mem:0x00200000+0xa240 (41536 bytes)
env => nor:0x7c000+15k (empty)

Use the command 'help help' to get started.

# copy -s fis://kernel 0x00008000

|
/
-
\
|
/
-
\
|
1441760 bytes transferred

# copy -s fis://ramdisk 0x01000000

/
-
\
|
/
-
\
|
/
-
\
|
/
-
\
|
/
-
\
|
/
-
\
|
/
-
\
|
/
-
\
|
/
6291440 bytes transferred

# wait 10 Type ^C key to cancel autoboot.
Type ^C key to cancel autoboot.

-
\
|
/
-
\
|
/
# boot
ATAG_HEADER
ATAG_MEM: start 0x00000000 size 0x04000000
ATAG_CMDLINE: (67 bytes) 'console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug mem=64M@0x0'
ATAG_INITRD2: start 0x01000000 size 0x00400000
ATAG_END
Booting kernel at 0x00008000...
Uncompressing Linux............................................................................ done, booting the kernel.
Linux version 2.6.17-2-ixp4xx (Debian 2.6.17-9) (waldi@debian.org) (gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #1 Thu Sep 14 13:29:00 UTC 2006

Enviado por bcorada el 8 Diciembre, 2006 - 12:34

Supongo que lo habras hecho

Imagen de usuario

Supongo que lo habras hecho pero revisa que hayas cogido la señal de chip select para el segundo banco del lugar correcto.

Para saber si el segundo banco hace algo, puedes probar a escribir algo en esa region de memoria desde el primer Apex (mira los comandos de Apex) y luego intentar leerlo a ver si se ha escrito correctamente. Esto no te asegura que este funcionando, pero si esa prueba te falla ya tendras mas acotado el problema. Aqui tienes el mapa de memoria del Slug http://www.nslu2-linux.org/wiki/Info/MemoryMap, prueba por ejemplo a escribir en 0x02000000 (primer banco) y en 0x06000000 (segundo banco). Por cierto, cuando escribas algo en memoria, asegurate de no sobreescribir la region donde esta el Apex o te cascara.

Bueno, ahora que lo miro no estoy seguro del todo, observa la nota que pone con 3 asteriscos en el mapa de memoria. Puede que las direcciones empiecen en 0x20000000, no estoy seguro del todo.

No se si el Apex incluye algun tipo de test de memoria al estilo Redboot, revisa la configuracion y los comandos a ver si hay algo (aunque creo que no).

Suerte y un saludo.

Enviado por gerator el 9 Diciembre, 2006 - 09:45

Por fin lo conseguí

Imagen de usuario

Bueno con la pista que me diste estuve escribiendo en el segundo banco de memoria desde Apex con el comando fill, grabé todo a 1 y luego a cero y no escribía correctamente en algunas direcciones así que comprobé en que direcciones fallaba y con el datasheet de la memoria averigüe que pines estaban fallando por que no estaban bien soldados, con un repaso de soldadura arrancó por fin con 128 MB. El problema ahora que no se si deberá todavía a alguna mala soldadura o a un error de software es que obtengo en la consola constantemente el siguiente warning cuando esta trabajando el micro con el kernel 2.6.17-9 ixp4xx:

BUG: warning at arch/arm/mm/consistent.c:363/dma_free_coherent()

Solamente aparece cuando uso el segundo banco si uso solo el primero no me da el warning, pero el sistema sigue funcionando, le metí el kernel 2.6.18-3-ixp4xx y obtengo un error similar de dma pero cuando intenta cargar los módulos usb y este es más inestable y a veces no termina de arrancar, he notado que el BUG: warning... aparece justo después de cargar el driver del dispositivo de red de hay que probablemente no me salga el mismo error con el kernel 2.6.18 ya que solo tengo los módulos del driver para el 2.6.17.

Enviado por bcorada el 10 Diciembre, 2006 - 13:19

Pues la verdad es que no se

Imagen de usuario

Pues la verdad es que no se de que puede ser el error. A mi con la ampliacion de 64M no me ha dado ningun error de ese estilo, ni con el 2.6.17-2 ni con el 2.6.18-3.

Un saludo.

Enviado por gerator el 12 Diciembre, 2006 - 15:41

Es un fallo del kernel

Imagen de usuario

Es un fallo del kernel 2.6.17 que esta corregido en la version 2.6.18, solo afecta a mas de 64MB,. yo uso 128 MB en un solo banco.

A mi me paso lo mismo, mira aqui que lo explicamos:

http://www.websjj.com/nslu2/foro/viewtopic.php?t=34

Un saludo

Enviado por qlfecv el 13 Diciembre, 2006 - 10:46

Mi experiencia

Imagen de usuario

Yo me lo carge jugando con la memoria, porque modifique el apex de primer nivel para 128 MB con 32 MB de memoria fisica y el intenta usarla toda y casca, el log no era igual que el tuyo.

Por otro lado, si los chips que has puesto son de 32M x16 es un unico banco y si cuando paras el apex de primernivel haces un dump de 0xcc000000 debes de ver el valor 1C que es el valor correcto de inicializacion del registro de DRAM.

Espero que te ayude
Un saludo

Enviado por qlfecv el 8 Diciembre, 2006 - 21:12

Buenas. Para recuperarlo por

Imagen de usuario

Buenas.

Para recuperarlo por JTAG tienes que grabar una imagen de la flash, yo grabaria la imagen de OpenSlug y luego volveria a empezar.

Si tienes debian o ubuntu, instalate el paquete openwince-jtag, tienes mas informacion en la pagina http://openwince.sourceforge.net/jtag/. Y busca informacion sobre como grabar la flash. No busques informacion en concreto sobre el Slug, ya que esas herramientas se usan tambien con cantidad de PDAs y cosas del estilo, y la mecanica es siempre la misma. Al final de la pagina que te he pasado tienes varios ejemplos de uso entre los que esta como grabar la flash. Tambien puedes pasarte por el canal de #nslu2-linux o los grupos de yahoo, seguro que te echaran una mano.

Sobre el fallo... ¿Que version de Apex grabaste? ¿Como la compilaste? Seria interesante que dieses todos los detalles que puedas, asi como la configuracion de Apex que usaste para poder aislar el fallo y que no vuelva a suceder.

Sobre todo no te preocupes que eso tiene arreglo, a ver si resucitamos tu NSLU2.

Un saludo.

PD:¿Hay algunas listas de correo sobre NSLU2 en castellano?

EDITADO:

Por cierto, se me olvidaba. El cable para JTAG es delicado, asi que procura hacerlo lo mas corto posible. Si tienes problemas y puedes acceder al material, te recomiendo que utilices un cable con buffers (hay cantidad de esquemas en internet, pero si no lo encuentras te paso uno) en el que la parte del cable que va del buffer al Slug sea lo mas corto posible. Tambien si tienes problemas prueba a apantallar utilizando los conductores del cable plano asi: masa - señal - masa - señal - masa....

Enviado por gerator el 2 Diciembre, 2006 - 11:55

Insistiendo pero

Imagen de usuario

Primero decir que yo no conozco ninguna lista en castellano, en ingles lo que quieras.

Os explicos mis experiencias:

- He compilado e instalado el kernel 2.6.18-2 ( 4 horitas del ala en un PC)
- He compilado y probado el apex como segundo cargador, pero cuando hago la prueba basica de 30 MB de RAM al ejecutarlo en RAM me da un eror de CRC de carga del kernel, si lo repito muchas veces alguna salta, pero no se porque y no quiero grabarlo hasta que de con el problema.
- He parcheado el redboot para que me reconozca los 64MB, siguiendo las indicaciones de: HtoTo: ModifYmemorySize. Con el unico problema que es una aventura probarlo en ram, ya que no he sido capaz de ejecutarlo con g 0x0.... pero si he comprobado que en el registro SDR_CONFIG pone el valor que se espera y corresponde con el datasheet del micro.

NO sustituyo el redboot por el apex porque no tengo tool para compilarlo y no me quiero complicar la vida instalado, soy comodon y si con el parche el redboot funciona, ya me vale.

Un saludo y suerte con el jtag

Enviado por qlfecv el 3 Diciembre, 2006 - 23:44

Problemas !!!

Imagen de usuario

Al final me decidi a compilar el apex como primer cargador y aparentemente va bien, me explico.

Compilo, lo cargo en ram y ejecuto,lo dejo que arranque el sistema y todo va sobre el papel bien, pero curiosamente telnet no me va, la red esta arriba (configurada) pero desde fuera no tengo comunicacion con el ni desde dentro veo a nadie fuera.

No se si esto es normal que pase desde RAM, pero no me atrevo a grabar con esta duda.

Por otro lado el log que obtengo es distinto al que tu pones y eso que yo copio el fichero openslug_config y solo he metido el cross compiler, pero no se parece mucho a lo que tu has pegado:

RedBoot> load -b 0x1000000 -r -m xmodem
Raw file loaded 0x01000000-0x0100db1f, assumed entry at 0x01000000
xyzModem - CRC mode, 441(SOH)/0(STX)/0(CAN) packets, 3 retries
RedBoot> go 0x1000000

APEX Boot Loader 1.4.7 -- Copyright (c) 2004,2005,2006 Marc Singer

APEX comes with ABSOLUTELY NO WARRANTY. It is free software and you
are welcome to redistribute it under certain circumstances.
For details, refer to the file COPYING in the program source.

apex => mem:0x00200000+0xdb20 (56096 bytes)
env => nor:120k+8k (no-write)

Use the command 'help help' to get started.

# copy nor:0x60010+0xffff0 0x00008000
1048560 bytes transferred
# wait 10 Type ^C key to cancel autoboot.
Type ^C key to cancel autoboot.
# boot
ATAG_HEADER
ATAG_MEM: start 0x00000000 size 0x02000000
ATAG_CMDLINE: (86 bytes) 'console=ttyS0,115200 rootfstype=jffs2 root=/dev/mtdblock4 rw init=/linuxrc noirqdebug'
ATAG_END

Y el tamaño es el doble de lo que tu tienes ?

A ver si esto es normal ????

Enviado por qlfecv el 4 Diciembre, 2006 - 22:45

Ouch!!

Imagen de usuario

Tienes razon, he metido la pata con el log. Ese log es el del cargador segundo nivel. No recuerdo bien el tamaño de mi binarios, pero si que se que el de primer nivel rondaba los 55k y el de segundo 40k mas o menos

Sobre lo de la red, el Apex no tiene muy buen soporte aun. Se que estan trabajando en eso pero de momento en el Slug solo se puede (corregidme si me equivoco) acceder con el puerto serie. La ultima vez que lo mire ya tenian implementado algo de la pila TCP/IP pero no habia driver para el slug.

EDITO: Me he liado jeje. Te refieres red en el sistema operativo... Pues la verdad es que eso no se porque puede ser. Supongo que usas la Debian Etch RC1 ¿No? A mi haciendo pruebas desde RAM, arrancando primero Redboot y con la configuracion para 32M, se me comportaba bastante inestable, con volcados de pila y demas. De todas formas se que eso no te resuelve nada. Aun asi, yo me animaria a probar ya que teniendo el Apex de primer nivel, recuperar el Slug es cosa facil (a mi me paso), siempre puedes volver a grabar el cargador que tuvieses antes (y es mucho mas rapido que el JTAG, 8M ~ 15-20 minutos).
De todas formas si quieres te puedo pegar mi configuracion aunque no creo que sea muy diferente a la tuya.

Voy a cambiar el log para que no lleve a equivocaciones. Pongo el tuyo (el mio era igual), cuando pueda lo cambiare por el mio.

Un saludo.

Enviado por gerator el 7 Diciembre, 2006 - 09:37

Como desoldar los chips de memoria de modulos de PC

Imagen de usuario

Bueno yo he comprado un modulo de chips 16Mx16 por Ebay pero no sabia como desoldarlos sin estropearlos y he encontrado esto os lo dejo para los que lo vayais a intentar así:

Desoldar SMD con una plancha

lo malo será desoldarlos del NSLU aunque ya voy descubriendo soluciones como hacer puntas con tuberias de cobre. Ahora respecto a cambiar el Apex creo que tendre que preguntarte alguna cosilla gerator porque das muchas cosas por sabida que me pierdo.

Enviado por bcorada el 24 Noviembre, 2006 - 17:23

De eso se trata, de que

Imagen de usuario

De eso se trata, de que alguien mas se anime y poco a poco ir mejorando la documentacion. Tu pregunta, que yo estare encantado de echarte una mano ;)

Sobre lo de desoldar los chips de un modulo, efectivamente es complicado. Lo mas recomendable es comprar chips sueltos pero se que esa opcion no es accesible a todo el mundo.

Enviado por gerator el 24 Noviembre, 2006 - 22:50

gran trabajo

Imagen de usuario

wow, gran trabajo! ¿Se nota la mejora?

Enviado por Say0nar4 el 19 Noviembre, 2006 - 18:39

Mejora

Imagen de usuario

Buenas.

Pues la verdad es que eso depende de lo que quieras hacer con el Slug. Si solo quieres servir una pagina personal o poner un servidor de impresion no vas a notar la diferencia. Sin embargo, si lo que quieres es utilizar un programa P2P si que se nota y mucho.

Yo para P2P utilizo Hydranode (tengo otro post en la pagina con binarios) y al principio funcionaba pero poco a poco iba empeorando su rendimiento hasta que el proceso moria. El problema era que no habia RAM fisica suficiente y empezaba a utilizar la swap, cuando la cantidad en swap crecia hasta cierto punto dejaba de ser utilizable (la swap a traves de USB es realmente horrible). Con la ampliacion a 64M la swap se utiliza muy poco y funciona a las mil maravillas. Este comportamiento tambien lo he observado utilizando aMule.

De mi experiencia, diria que el minimo de RAM para utilizar en condiciones un programa P2P esta entre 48-64MB. Si ademas de un P2P quieres tener mas servicios como web, cups, ftp, samba... Entonces quizas haya que plantearse añadir algo mas pero eso ya es otra historia.

Sinceramente puedo decirte que con las pruebas que estoy realizando, la actualizacion verdaderamente merece la pena.

Un saludo.

Enviado por gerator el 19 Noviembre, 2006 - 23:50

>> Por favor..

Imagen de usuario

Yo estoy muy interesado en ampliar el nslu2 .. apenas puedo cargar 6 ficheros a amule que ya hace demasiado uso de swap..

como veo que tu eres el unico que "a tenido cojones" de ampliarlo , no iria mal que hicieras un howto algo mas detallado en cuanto a hardware.. que te puede costar.. etc..

yo sigo sin atreverme..

Enviado por marvin el 20 Noviembre, 2006 - 15:32

Tampoco tiene mucho

Imagen de usuario

La parte hardware la verdad es que tiene poco que explicar, el problema esta en el equipo, la habilidad ...

Lo mas sencillo es sustituir los dos chips de la placa con chips de 256Mb(16Mx16) o 512Mb(32Mx16), realmente no tiene mas. Lo complicado esta en quitarlos, sobre eso ya tampoco puedo decir nada mas. A mi me los cambio un amigo mio que se dedica a estas cosas, los quito con pistola de aire que es la parte mas complicada, y me dejo un acabado perfecto. Supongo que tambien se puede hacer de forma artesanal pero esta claro que corres un riesgo. Supongo que para quitar los integrados, que es la parte mas complicada, podrias cortar las patillas de los chips.

En fin, yo no puedo mas que recomendar la ampliacion ;)

Un saludo.

Enviado por gerator el 21 Noviembre, 2006 - 09:05

Estoy liado con el asunto

Imagen de usuario

Me he leido todo lo que he encontrado sobre el tema, pero a pesar de ello tengo algunas dudas que expongo a continuacion:

Para modificar el apex, no vale cojer las sources que hay en debian http://packages.debian.org/unstable/admin/apex-nslu2 version 1.4.7 y realizar hay la modificacion necesarias, porque todo el sistema de desarrolo que comentas no lo tengo, solo tengo el gcc-cross-compiler-arm.

El kernel no es problema porque ya he compilado uno, sin hacer esta modificicacion, y funciona.

En cuanto al hardware, no me queda claro lo del puente entre los pins CS de las memorias, ya comentaras si lo has hecho.

Felicidades por la explicacion que es muy educativa.

Un saldo

Enviado por qlfecv el 28 Noviembre, 2006 - 22:51

Buenas. Para modificar el

Imagen de usuario

Buenas.

Para modificar el Apex vas a necesitar dos toolchains, uno para arm little-endian y otro para arm big-endian. El de little endian puede ser el propio de debian que se instala en el slug, pero yo aqui recomiendo compilacion cruzada. El compilardor cruzado de little endian lo puedes coger de www.emdebian.org, ahi tienes repositorios para Debian, y haciendo alguna chapucilla tambien se instala en ubuntu. El de big endian yo lo obtuve con crosstool, se genera cuando intentas compilar algo con el MasterMakefile de openslug, aunque si quieres saltarte este paso e ir directo al grano la arquitectura es armv5b.

Yo no cogeria el apex-debian, me iria directamente al fuente que se encuentra en el wiki de Apex. Este contiene en un directorio los ficheros de configuracion para Openslug, para nslu2 generico y para debian. Sobre esas configuraciones puedes seguir ya el manual de arriba para realizar la modificacion.

En cuanto al kernel, no hace falta compilarlo, de hecho mi objetivo era que esa parte se gestionase mediante APT, utilizando el generico para ixp4xx de Debian. Lo unico que hace falta es pasarle la linea de comando adecuada para que te coja los 64M. No obstante si te animas a compilartelo, adelante.

Yo el puente CS no lo he hecho porque he utilizado solo dos chips. De todas formas te cuento por encima. Cada banco de memoria se selecciona utilizando una señal de Chip Select (CS). Al poner 4 chips estas utilizando dos bancos y para direccionar el segundo banco hace falta una segunda señal de CS, por eso es necesario sacarla con un cable y llevarla a los dos chips de RAM. No te preocupes por esa parte de la modificacion, no deberia darte ningun problema, eso si, intenta que el cable sea lo mas corto posible (tampoco te obsesiones ;) ).

Un saludo.

Enviado por gerator el 30 Noviembre, 2006 - 11:50

Bueno pues solo unas preguntas

Imagen de usuario

1) -> cuanto pueden costar los chips mas o menos si quiero ampliar a 128?
2) -> donde los compraste?

No tengo claro que tipo de SDflash usa el aparatito..

Enviado por marvin el 22 Noviembre, 2006 - 15:04

Depende de como hagas la

Imagen de usuario

Los chips tienen que ser SDRAM, que funcione a 133MHz, alimentacion de 3.3V y en encapsulado TSOP de 54 pines. Yo intentaria buscar marca Micron. Esa marca es de las mas faciles de encontrar, aunque tambien puedes buscar Samsung, Hynix, ST (no estoy seguro de si tenian RAM pero creo que si)... Con la informacion anterior vete a las paginas de los fabricantes y echa un ojo a la seccion de SDRAM y mira a ver si tienen venta online.

Otra opcion es buscar los chips de un modulo de PC a 133MHz (nada de DDR). Mira la referencia y busca el integrado. Cuando lo tengas debes asegurarte de que sea 16Mx16 o 32Mx16. Esos numeros son la organizacion de la memoria, el primer numero es el numero de palabras y el segundo el numero de bits por cada palabra.

Depende de como hagas la ampliacion si con cuatro chips de 256Mbit(MT48LC16M16A2P) o dos de 512Mbit(MT48LC32M16AP). Los primeros por ejemplo los tienes en Farnell in One a unos 12€, aunque en alguna tienda los encontraras mas baratos porque en distribuidor cuestan ~4,5€.

Puedes intentar ir a la pagina de Micron y ver si se pueden pedir muestras, si cuela te saldran gratis.

Enviado por gerator el 23 Noviembre, 2006 - 15:33

Cantidad máxima que aguanta.

Imagen de usuario

Hola, estoy buscando información para aumentarle memoria RAM. Quiero ponerle dos chips ¿cuá es la de mayor capacidad posible?, tengo entendido que son dos módulos de 128 MB. ¿Sabeís donde se puden comprar?, muchas gracias por todo.

Enviado por Stigma el 31 Enero, 2007 - 14:41

yo al amuled si que le

Imagen de usuario

yo al amuled si que le encuentro que chupa mucha memoria, pero el rtorrent no me disgusta, me gusta bastante como funciona. Aunque tanto en amule como en los torrents nunca he tenido mas de 6 o 7 cosas bajando

Enviado por Say0nar4 el 21 Noviembre, 2006 - 11:27

Juas!

Imagen de usuario

Igual me he quedado yo. Y con la misma duda!!

Enviado por rayworld el 19 Noviembre, 2006 - 20:28