WR703N + VinciDuino

barbudor:

  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/" :

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.

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

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 :

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

Bonne chance :wink:

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)

Merci pour le truc sur l'upgrade je n'avais pas vu de référence à cette commande.
Je vais peut être me faire un script shell qui monitore un répertoire /tmp/upg et qui lance l'upgrade automatiquement si je scp un package dans ce répertoire.

Le test en fat c'était juste pour voir parce que j'ai une clef FAT sous la main.
Sur pour l'overlay ca sera du filesystem linux

Pour ext2 vs 3 ou 4, je vous laisse juge.
Il y a bien une option kernel pour ajouter ext4 et rien de spécifique a priori pour 2 et 3.
Ca rejoindra l'option que c'est dispo nativement.
Mais il faut de toute façon que je commence par formatter la clé sous Xubuntu puisqu'on a pas fdisk ni mkfs par défaut sur OpenWRT (pas utile en passant).

J'ai aussi voulu essayer une micro-sd dans un adaptateur mais ca na pas mieux marché.

A votre avis qu'est-ce qui sera le plus efficace (performance, usage CPU) : clef USB ou micro-SD ?
Vous allez me dire que ca dépend de la clé et de la SD bien sur :slight_smile:

Ce soir, je crois que je fais un pause et que je reprendrais çà demain :wink:

skywodd:

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 :fearful:), 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 :astonished:... 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 ]:D).

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 !

Hummm ... je prend note ...
Bon va peut être falloir que je recompile deux trois trucs avec le support EXT4 :sweat_smile:
Et que je modifie 2-3 fichiers de config :sweat_smile:

Bon, ben j'ai bien bidouillé ma config

J'ai viré Luci, le server Web et pas mal de chose.
j'arrive à

root@barbuWR703:/# free
             total         used         free       shared      buffers
Mem:         29480        16072        13408            0         1624
-/+ buffers:              14448        15032
Swap:            0            0            0
root@barbuWR703:/# df
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs                    1088       220       868  20% /
/dev/root                 2048      2048         0 100% /rom
tmpfs                    14740        52     14688   0% /tmp
tmpfs                      512         0       512   0% /dev
/dev/mtdblock3            1088       220       868  20% /overlay
overlayfs:/overlay        1088       220       868  20% /
root@barbuWR703:/# ps
  PID USER       VSZ STAT COMMAND
    1 root      1516 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW   [kworker/u:0]
    6 root         0 SW<  [khelper]
    7 root         0 SW   [kworker/u:1]
   62 root         0 SW   [sync_supers]
   64 root         0 SW   [bdi-default]
   66 root         0 SW<  [kblockd]
   95 root         0 SW   [kswapd0]
  144 root         0 SW   [fsnotify_mark]
  156 root         0 SW<  [ath79-spi]
  167 root         0 SW   [mtdblock0]
  172 root         0 SW   [mtdblock1]
  177 root         0 SW   [mtdblock2]
  182 root         0 SW   [mtdblock3]
  187 root         0 SW   [mtdblock4]
  192 root         0 SW   [mtdblock5]
  233 root         0 SW   [kworker/0:1]
  405 root         0 SWN  [jffs2_gcd_mtd3]
  407 root         0 SW   [flush-mtd-unmap]
  423 root      1512 S    /bin/ash --login
  455 root         0 SW<  [cfg80211]
  464 root         0 SW   [khubd]
  541 root      1520 S    /sbin/syslogd -l 8 -C16
  543 root      1504 S    /sbin/klogd
  545 root       844 S    /sbin/hotplug2 --override --persistent --set-rules-f
  553 root       860 S    /sbin/ubusd
  557 root      1508 S    /sbin/netifd
  586 root      1520 S    udhcpc -p /var/run/udhcpc-br-lan.pid -s /lib/netifd/
  736 root      1512 S    /sbin/watchdog -t 5 /dev/watchdog
  934 root      1152 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22
  958 root      1516 S    /usr/sbin/ntpd -n -p 0.openwrt.pool.ntp.org -p 1.ope
  967 root      1508 R    ps

Je suis pas sur d'avoir besoin de hotplug2. Idée ?
A la fin j'aurai certainement en statique une clé USB ou une carte µSD, la léonardo, peut être 1 ou 2 autres adaptateur série pour communiquer avec d'autres cartes ou module GSM (je garde la console pour le debug).
Je ne compte pas faire de auto-mount.

J'ai l'impression que mon /tmp me prend encore 14MB de DRAM. Est-ce vraiment utile ? Est-ce lui qui est majoritairement responsable des 16MB utilisés ?
Où puis-je réduire cela ?

J'ai les drivers série y compris USB_ACM qui me permet de brancher ma Léonardo et avec screen j'ai vérifié que j'arrivais bien recevoir ce que 'envoie la Leonardo.

Je crois que CONFIG_PACKAGE_kmod-scsi-core est nécessaire pour les clés USB ?

Oui puis-je trouver de la doc sur les différents packages concernant les leds ? leds-gpio, ledtrig-xxx

Ais-je besoin de CONFIG_PACKAGE_kmod-ipt-core alors que je ne me sert pas de mon WR703 comme d'un routeur ? seul le client Ethernet et Wifi m’intéresse .

Maintenant il va falloir que j'apprenne à faire un petit "Hello World" et la magie des packages.

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 :grin: 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

AAAaaarrrrrgggghhhh =(

Ce qui devait arriver arriva !

BRICK

[    1.150000] TCP cubic registered

[    1.150000] NET: Registered protocol family 17
[    1.150000] 8021q: 802.1Q VLAN Support v1.8
[    1.160000] VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
[    1.170000] Freeing unused kernel memory: 204k freed
mkdir: can't create directory '/dev/shm': Read-only file system
mkdir: can't create directory '/dev/pts': Read-only file system
mount: mounting devpts on /dev/pts failed: No such file or directory
/etc/preinit: line 1: can't create /dev/null: Read-only file system
/etc/preinit: line 1: can't open : no such file
[    2.360000] Kernel panic - not syncing: Attempted to kill init!




J'arrive même pas au failsafe =( =( =(


Je vais devoir tenter un reflashage depuis U-Boot
Mais j'ai des doutes sur l'opération.
Tout d'abord, la map de la flash telle que donnée dans le wiki d'openWRT est :


dev:    size  erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 000d9fa8 00010000 "kernel"
mtd2: 002f6058 00010000 "rootfs"
mtd3: 000f0000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 003d0000 00010000 "firmware"




D'où je déduit


u-boot 00000000 020000
kernel 00020000 0d9fa8
rootfs 000f9fa8 2f6058
rootfs_data 003f0000 0f0000
art 004e0000 010000
firmware 004f0000 3d0000
end 008c0000




ce qui ne marche pas pour une flash de 4MB !!!!

Mais dans u-boot je vois :


> bootargs=console=ttyS0,115200 root=31:02 rootfstype=squashfs init=/sbin/init **mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),2752k(rootfs),896k(uImage),64k(NVRAM),64k(ART)**



ce qui donne



u-boot 00000000 040000
u-boot-env 00040000 010000
rootfs 00050000 2b0000
kernel/uImage 00300000 0e0000
nvram 003e0000 010000
art 003f0000 010000
end 00400000




un peu plus logique

[u]Question 1:[/u]
Docteur je reflashe quoi ?
Juste le firmware ou aussi le rootfs ?

[u]Question 2:[/u]
Le Wiki d'OpenWRT décrit une méthode via liaison série mais apparemment l'u-boot d'origine du WR703 ne la supporte pas. Juste tfptboot.
Bon, apparemment y'a déjà tftp-hpa sur mon Xubuntu, je vais apprendre ....

[u]Question 3:[/u]
Est-ce que quelqu'un pourrait me confirmer les commandes u-boot pour l'opération.
Le wiki donne ceci pour remettre le firmware d'origine :



tftpboot 0x81000000 xxxx.bin
erase 0x9f020000 +0x3c0000
cp.b 0x81000000 0x9f020000 0x3c0000
bootm 9f020000



Qui n'est même pas correct par rapport à la map donnée parle wiki (kernel + rootfs = d9fa8 + 2f6058 = 3d0000 et non pas 3c0000)

Bref, je suis un peu perdu....

Merci d'avance

EDIT : Bon, ben j'ai suivit la méthode du Wiki et c'est repartit.

EDIT2: Je crois qu'il va falloir que je sauvegarde le contenu total de ma flash, y compris ART et que je m'achète quelques flash de rab parce que avec 15 à 20 reflashage par jour depuis une semaine ...

Bienvenue au club :grin:

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 :roll_eyes:

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

Merci

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

Et bon boulot sur le pinout !

barbudor:
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.

barbudor:
Et bon boulot sur le pinout !

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

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

Squonk42:

barbudor:
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.

barbudor:
Et bon boulot sur le pinout !

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

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

bonjour
Juste pour dire que je suis tout ça du coin de l’œil avec intérêt.
et j'imagine bien le temps passé :blush:
mais arrangez vous pour que tous ça soit au point mi-septembre :grin:
c'est à partir de cette date que je vais récupérer mes "WRT" 8)

Et avec un paquet cadeau aussi ? ]:smiley:

Je ferais un résumé pour quick-starter quand j'aurais quelque chose qui marche.
Pour l'instant je vais arrêter de bidouille la config du OpenWRT. C'est satisfaisant bien que j'ai quelques soucis pour mixer Ethernet et WIfi en même temps.

Cette semaine je me concentre sur un hello world : environnement de développement, test sur PC, test sur WR703, dialogue avec Arduino.
Mon idée est d'arriver à avoir une couche Serial similaire a celle de l'Arduino ce qui sera plus facile pour ceux qui veulent passer de l'une a l'autre. Et peut être quelque chose aussi de similaire a EthernetClient/EthernetServer.

barbudor:
Et avec un paquet cadeau aussi ? ]:smiley:

:grin:
D'accord mais le paquet avec un joli cerclage en bolduc :grin:

Artouste:
Juste pour dire que je suis tout ça du coin de l’œil avec intérêt.

De même, je reste dans l'ombre en attendant que le matos arrive :grin:

barbudor:
Et avec un paquet cadeau aussi ? ]:smiley:

Oublie pas le papier bulle, le papier bulle c'est la vie 8)

Moi aussi ça me plait bien votre bidouille.... je surveille aussi XD

Re,

Je viens de découvrir que U-boot (en derniére version et avec certain cpu) supporter le boot directement depuis une clef usb :astonished:
Faut recompiler avec les #define qui vont bien par contre (pas un gros probléme).

J'ai pas regarder si le WR703N était dans la liste mais ça pourrait être un truc tiptop (boot de la uImage depuis la clef usb, pivot pour avoir le rootfs sur la clef usb et hop plus besoin de flasher la flash)
Va falloir que j'approfondisse mes recherches sur le sujet !

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.

Bonne idée
Pour l'instant je n'ai pas reflashé le u-boot. Je garde celui d'origine de TP-Link.
Il est un peu limité par rapport a d'autre que j'avais vu.
Par exemple pas de possibilité de sauvegarder les modifs des variables.

Je me demande si ce n'est pas par limitation de taille de flash ?
Mais si on ne se sert plus de la flash hormis le boot, on peut prendre toute la place.

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 8)

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