Pour ceux qui se demandaient où j'étais passé, voici la réponse :



Pour les détails, veuillez consulter http://squonk42.github.com/TL-WR703N/ (pardon, c'est en Anglais).

Merci pour les photos hi-res du PCB 

Oui, parfois une formation d'écailler peut servir

Sinon, voici les différences entre le MR3020 et le WR703N :

• il est agréé CE/FCC
• il est distribué à l'export et donc aussi en France
• il a 4 LEDs en plus
• il a un interrupteur à glissière en plus
• le bouton RESET en replacé par le bouton/LED WPS
• il a 2 antennes intégrées, dont une seule est utilisée (celle au coin)
• le connecteur RJ45 SMT blindé avec découpe du PCB est remplacé par un RJ45 non blindé traversant (?!?)
• l'UART est accessible par un connecteur non monté au pas de 2.54 mm très facile à souder 
• il est plus gros (6,7 cm x 7, 4 cm x 2,2 cm au lieu de 5,7 cm x 5,7 cm x 1,9 cm)
• il est plus cher (30,03 € au lieu de 16,73 € sur eBay), si quelqu'un a un plan moins cher, je suis preneur !

Sinon côté électronique et logiciel, les 2 appareils sont très semblables.

Scanné ? Pour faire une photo de carte sans ombres je ne vois que çà comme solution
Merci, je vais arrêter de me bousiller les yeux.

Non, avec reflex APN 5 MPX avec éclairage fort par le dessus. Etant donnée la faible hauteur des composants, les ombres ne sont pas trop visibles. On arrive à avoir 1000 dpi avec une bonne profondeur de champ, ce qui n'est pas le cas avec un scanner à plat, même si avec les scanners modernes (pas comme le mien !), la résolution est supérieure.

Barbudor, pour ne pas abimer tes beaux yeux , voici des photos du PCB nu auxquelles j'ai contribué, cette fois-ci avec un reflex APN 8 MPX avec 1600 dpi:
http://www.kean.com.au/oshw/WR703N/teardown/

Je suis assez silencieux en ce moment car je prépare une surprise, et je ne dirais qu'une chose : faites chauffer EagleCAD

Je pense que tu as inversé U5 et U6 dans ta description.

Heu, non ?

U5 est bien un convertisseur DC/DC 5V/3.3V avec diode Schottky intégrée et sa self à noyau ferrite L14 juste à côté, et U6 est bien un switch d'alimentation USB, placé sous le connecteur d'alim microUSB.

Une petite mise à jour concernant le WR703N : après avoir décortiqué le brochage du CPU AR9331, je continue mon exploration avec le PCB complet.

Le rôle de chaque composant est maintenant identifié, et à part la datasheet du AR9331 que nous n'aurons probablement jamais, il ne reste que 2 chips non formellement identifiés, bien que leur fonction soit parfaitement connue: U5 (convertisseur DC/DC 5V/3.3V avec diode Schottky intégrée) et U6 (switch d'alimentation USB).

Voici 2 images du PCB "zoomables" avec la molette du mulot  :

http://zoom.it/4ym9
http://zoom.it/nsDQ

Les mêmes images en HR "fixes":

http://img684.imageshack.us/img684/3559/tlwr703ntop.jpg
http://img253.imageshack.us/img253/1109/tlwr703nbottom.jpg

Notez que les 2 images se superposent parfaitement et que l'on peut donc par transparence suivre les vias

Non, je n'ai pas d'image des couches internes

Tout à fait d'accord, le U-Boot du WR703N est assez limité! Juste pour info, pour arrêter le boot normal et obtenir le prompt U-Boot, il faut taper "tpl" rapidement au tout début. C'est écrit quelque part dans le Wiki OpenWRT, mais au moins, cela évitera à tout le monde de chercher !

Un autre truc que j'ai utilisé ailleurs et pas encore sur le WR703N, c'est la possibilité de monter le rootfs par NFS: il n'y a alors plus besoin de recopier les modifs sur le filesystem du routeur lors du développement à chaque fois, celles-ci apparaissent de manière magique au fur et à mesure

Voici un projet intéressant au sujet du U-Boot sur le WR703N: wr703n-uboot-with-web-failsafe

Ca ça serait pas mal !

On pourrait faire comme le Raspberry Pi avec les cartes SD : on change de clé USB et hopla !

Mais attention, l'alim de l'USB Host est pilotée par la GPIO8, donc il faudra la mettre à 1 avant d'y accéder pour que l'USB fonctionne.

Le modules chargeables à la main c'est avec CONFIG_xxx=m au lieu de =y ?
Mais ne faut-il pas modprobe pour les charger alors ? J'ai pas trouvé modprobe sur OpenWRT

Oui, et "modprobe" n'est qu'une surchouche à "insmod"/"rmmod" qui tente d'installer/enlever les modules dépendants, donc on peut facilement se débrouiller avec "isnmod"/"rmmod" qui eux sont présents.

Et bon boulot sur le pinout !

Merci ! C'était pour inaugurer ma loupe binoculaire toute neuve (en promo chez Nature & Decouvertes à 140€, -30% ).

Maintenant, y a plus qu'à bricoler avec le VinciDuino, vu qu'il n'y a pas assez de GPIO de dispo

Bienvenue au club 

Bon, ça a l'air d'être reparti, non ?

Pas de panique côté nombre de reflashage: le chip Flash SPI est donné pour 100 000 cycles. A coup de 20 par jour, tu en as pour 13 ans 

Mais je te conseilles d'expérimenter le noyau en mettant tes expériences sous forme de modules chargeables à la main, avant de l'intégrer en fixe, cela évite pas mal de déboires !

Sinon, pour les bidouilleurs fous, j'ai beaucoup travaillé pour trouver le pinout du chip Atheros AR9331 (CPU du WR703N), le résultat est là :
http://wiki.openwrt.org/toh/tp-link/ar9331_pinout

J'avais déjà fais une étude détaillée du PCB:
http://wiki.openwrt.org/toh/tp-link/tl-wr703n_pcb

Bravo !

Tu as bien avancé !

Je vais tenter de répondre à tes questions :

• hotplug2: effectivement, si tu ne compte pas insérer de périphérique USB à chaud, cela ne sert à rien
• RAM: pas t'affoles ! Linux a horreur du vide  Il profite qu'il y a de la RAM dispo pour s'étaler, en gros jusqu'à la moitié de la RAM totale disponible. Mais si il y a besoin, il va réduire la voilure
• kmod-scsi-core: oui, c'est nécessaire, les "Mass Storage Class" USB s'appuyant sur un jeu de commande SCSI
• led-gpios: il n'y a pas grand chose, à part ce thread dans OpenWRT qui parle des GPIOs du WR703N avec des exemples
• kmod-ipt-core: non, si tu ne cherches pas à te connecter à Internet directement, iptables ne te sert à rien. donc tu peux virer celui-ci et les modules noyau associés
• hello world: je te  conseilles ce tuto en Français

[majeures]

Pour le "pivot root", il faut utiliser du ext2/3/4, sinon les chances d'y arriver sont minces ! Formatte ta clé sur ton PC Linux en tant que partition primaire ext4, c'est le plus simple.

EXT2 pas EXT3/4 sinon tu as la journalisation qui bourre toute ta clef usb ...

En plus si je me rappelle bien seul EXT2 est géré en bas niveau par le kernel, pour EXT3/4 il faut un module kernel en plus.
(kmod-fs-ext3 ou kmod-fs-ext4 je crois)

Le sujet est très controversé  

L'ext3/etx4 gèrent effectivement un journal qui permet de récupérer le filesystem en cas de problème d'intégrité (coupure de courant innopinée, plantage ), ce qui est quand même un gros plus pour un système qui doit avoir une disponibilité sans utilisateur.

Il y a aussi un problème de performances : l'ext4 est pratiquement 2x plus performant que l'ext2, cf. ce lien et celui-ci, il y en a un tas d'autres qui vont tous dans le même sens. Là aussi, cela peut avoir un sens pour une plateforme embarqué qui doit être un minimum efficace en consommation: il ne faut pas croire, mais les disques USB consomment beaucoup lorsqu'on y accède en lecture, encore plus en écriture, et énormément lors d'un effacement de secteur. Donc le moins de temps on l'utilise, le mieux c'est !

En bref, même si l'ext3/ext4 ont un "overhead" dû à la journalisation, ils apportent quand même une sécurité et des performances non négligeables, sachant qu'il est possible de jouer avec certains paramètres pour éviter les effets négatifs pour les disques Flash :

• l'option "noatime" que j'ai utilisée permet de ne pas écrire les date de dernier accès aux fichiers, ce qui est une des causes majeures d'usure des disques flash si on n'y prête pas attention
• l'option "commit" permet de régler la durée de conservation des données en cache RAM avant écriture : en passant la valeur par défaut de 5 s à 120 s, on multiplie par 60 la durée de vie du disque Flash et on passe ainsi de 6 mois à 30 ans de durée de vie  ... Au détriment de la granularité en termes de perte de données

C'est pourquoi personnellement, je recommanderais l'ext4 avec ou sans journalisation (on peut la désactiver avec l'option "noload", cf. la doc de l'ext4, on obtient alors l'équivalent d'un ext2 aux stéroïdes  ).

De plus, le noyau ne possède aucun support "bas niveau" pour un quelconque filesystem, que ce soit ext2, ext3, ext4, jffs2, squashfs, etc. : c'est juste que le module mkod-fs-ext2 est intégré par défaut dans la configuration noyau d'OpenWRT. Mais si on construit son propre noyau, on peut changer cela et mettre l'ext4 à la place ou en plus.

Il n'y a en tous cas aucun risque de "bourrage" de la clé USB, mais il convient toutefois de bien comprendre ce que l'on fait, car cela peut conduire à des situations d'usure prématurée de la clé USB à plus ou moins long terme, donc gaffe !

1) Une fois recompilé mon firmware avec les changements de .config je le flash de la façon suivante :
- copie (scp) de openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin dans /tmp
- mtd write /tmp/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin firmware

Je perd mes réglages à chaque fois (adresses IP, mot de passe, etc ...)

Y a t'il un moyen de faire un upgrade sans tout casser ?

J'ai essayé aussi avec openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-sysupgrade.bin mais je n'ai pas vu de différence

Oui : d'abord, il faut utiliser l'image "openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-sysupgrade.bin" et pas la "openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin" qui est faite pour écraser le firmware TP-Link d'origine.

Ensuite, il ne faut pas utiliser "mtd write" qui écrabouille joyeusement la partition mtd, mais l'utilitaire "sysupgrade" avec l'option "-c" pour préserver les changements dans "/etc/" :

Code:

root@TL-WR703N:~# sysupgrade --help
Usage: /sbin/sysupgrade [options] <image file or URL>

Options:
        -d <delay>   add a delay before rebooting
        -f <config>  restore configuration from .tar.gz (file or url)
        -i           interactive mode
        -c           attempt to preserve all changed files in /etc/
        -b / --create-backup <file>
                     create .tar.gz of files specified in sysupgrade.conf
                     then exit. Does not flash an image. If file is '-',
                     i.e. stdout, verbosity is set to 0 (i.e. quiet).
        -r / --restore-backup <file>
                     restore a .tar.gz created with sysupgrade -b
                     then exit. Does not flash an image. If file is '-',
                     the archive is read from stdin.
        -n           do not save configuration over reflash
        -F / --force
                     Flash image even if image checks fail, this is dangerous!
        -q           less verbose
        -v           more verbose
        -h / --help  display this help

A la fin du flashage, sysupgrade va sauvegarder tes paramètres, rebooter automatiquement le routeur et remettre tes paramètres en place.

2) J'ai inséré une clé USB formattée FAT32 (oui j'ai bien ajouté aussi le kmod-fs-vfat)
Mais j'obtient :

Code:

root@OpenWrt:/# ls -Al /dev/sd*
brw-r--r--    1 root     root        8,   0 Sep  8 15:52 /dev/sda
brw-r--r--    1 root     root        8,   1 Sep  8 15:52 /dev/sda1
root@OpenWrt:/# mount -t vfat /dev/sda1 /mnt/sda1
[  645.560000] FAT-fs (sda1): codepage cp437 not found
mount: mounting /dev/sda1 on /mnt/sda1 failed: Invalid argument
root@OpenWrt:/#

Je te déconseille fortement d'utiliser une clé formattée en FAT32 si tu veux faire un "pivot root" dessus: le FAT32 ne gère pas les liens symboliques, donc la moitié des trucs ne vont pas fonctionner correctement !!!

Pour le "pivot root", il faut utiliser du ext2/3/4, sinon les chances d'y arriver sont minces ! Formatte ta clé sur ton PC Linux en tant que partition primaire ext4, c'est le plus simple.

Sinon pour le problème de "codepage" VFAT, c'est encore une Windowserie qui nécessite l'installation de 2 modules noyaux supplémentaires pour gérer les pages de code du FAT32 :

Code:

opkg install kmod-nls-cp437 kmod-nls-iso8859-1

Bonne chance

[BEAUCOUP]

Super !

Tu as trouvé pourquoi ça ne marchait pas ?

Je te conseille quand même d'installer une console USB avec un câble type CA42 à moins de 2€ et 3 coups de fer à souder, on ne sait jamais  

Si tu maîtrise "vi" le minimum nécessaire pour éditer un fichier et le sauvegarder, il n'y a pas besoin de Luci : les fichiers de config sont dans "/etc/config" et sont en texte clair, leur description est dispo ici.

Pour ce qui est de l'overlay, c'est assez simple, en fait:

• tu formattes une clé USB avec une seule partition primaire en ext4 sur ton PC (gparted conseillé, sinon fdisk si tu connais)
• tu installes les drivers noyaux nécessaires, à savoir : kmod-usb-core, kmod-usb2, kmod-usb-ohci, kmod-usb-storage et bien sûr kmod-fs-ext4 (cf. ici)
• il faut aussi installer le paquet block-mount
• à l'insertion de la clé USB, tu devrais voir passer des choses en faisant "dmesg" (dont le nom de la partition, normalement "sda1")
• mkdir /mnt/sda1, puis mount -t ext4 /dev/sda /mnt/sda1, puis ls /mnt/sda1, tu dois avoir un "lost+found"
• tu recopies le contenu de la Flash SPI sur le disque USB: tar -C /overlay -cvf - . | tar -C /mnt/sda1 -xf -
• tu modifies le fichier /etc/config/fstab comme suit et tu rebootes :

Code:

config mount
option target /overlay
option device /dev/sda1
option fstype ext4
option options rw,sync,noatime,commit=120
option enabled 1
option enabled_fsck 0

L'option "noatime" permet de ne pas mettre à jour en permanence les dates d'accès aux fichiers, et "commit=120" permet de mettre en cache les accès pendant 120 s (au lieu de 5 s par défaut) : cela permet d'améliorer BEAUCOUP la durée de vie de la clé USB Flash  

Presque tout cela est bien expliqué dans le lien ci-dessus, qui détaille le "pivot overlay extroot".

Il faut alors changer de shell en tapant:

Code:

sudo update-alternatives --install /bin/sh sh /bin/bash 100

Fait mais ca ne change pas le problème
J'ai bien bash maintenant au lieu de dash mais l'erreur est toujours là

Bon, c'est déjà mieux, mais c'est pas encore çà! Tu es sûr d'avoir tous les outils de compilation installés (vérifie avec "sudo dpkg -l build-essential") ? Sinon, il faut un :

Code:

sudo aptitude update; sudo aptitude install build-essential

J'ai réussi à générer un paquet "binutils-avr" ...
Mais pour le "gcc-avr" et l' "avr-libc", c'est une autre paire de manche...

perso, je me contenterais d'AVRdude afin de pouvoir reflasher l'Arduino en remote.
Recompiler les sketches sur le WR703 lui même me parait inutile (pour l'instant ).
Bon courage!

Ca ne serait pas cool de faire tourner l'IDE Arduino dans un navigateur Web pointant sur le serveur intégré au WR703N ?

Le couple WR703N + VinciDuino deviendrait alors un outil complètement indépendant du PC/Mac/iPhone/Android !

[./scripts/feeds update -i]

J'ai réussi à générer un paquet "binutils-avr" qui tient la route (pour ceuce qui sont intéressés, les patches et le makefile OpenWRT), à placer dans le répertoire "feeds/packages/devel" du "trunk" d'OpenWRT, suivi d'un "./scripts/feeds update -i" pour ajouter le package et d'un "./scripts/feeds install -a" pour l'ajouter au menuconfig.

Mais pour le "gcc-avr" et l' "avr-libc", c'est une autre paire de manche...

En effet, il faut :

• ...générer un compilateur sur une machine de travail linux-x86 (mon PC de travail)...
• ... pour faire tourner sur une machine mips24kc (le WR703N)...
• ... pour générer du code pour AVR (l'Arduino)

Ceci est compliqué par le problème dit "de la poule et de l'oeuf", à savoir qu'on a besoin à un moment donné de faire tourner le compilateur mips24kc => AVR pour générer un tas de chose (fichiers de démarrage, includes, etc.) qui ont eux-même besoin du compilateur pour être créés !

Cette configuration avec 3 architectures est connue en tant que "Canadian build", en référence au système politique Canadien qui comportait 3 partis politiques majeurs à l'époque où ce problème a été rencontré en premier.

En gros, on s'en tire en générant un compilateur intermédiaire linux-x86 => AVR pour générer ces fameux fichiers.

J'ai réussi à faire cette manip "à la mimine" à partir des sources et générer un gcc-avr+avr-libc qui tourne sur le WR703N, mais j'aimerai bien pouvoir le faire proprement en tant que package, et je me bats donc actuellement avec les makefiles OpenWRT

Mon plus gros problème est de générer de manière conditionnelle des outils (qui vont dans le répertoire "tools" d'OpenWRT), à savoir ce fameux compilateur intermédiaire, lorsque l'utilisateur choisit de générer un compilateur AVR pour le WR703N.

Si quelqu'un a des idées sur le sujet, il est le bienvenu !