next topic »

[Reply #60 on:]

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 !

[Reply #61 on:]

J'ai pu recompiler !

1er essai a partir du trunk et d'un defconfig.
Compil ok, re-flashage ok mais le firmware ne comportait pas luci

2eme essai a partir du trunk et du fichier default+luci de Madox
Reflashage difficile puisque je n'avais pas Luci.
Copie du firmware par scp (ouf, il y avait dropbear dans le firmware par défaut) puis "mtd write"
Et c'est repartit

Bon, ben apparemment j'ai pris le coup. tant que j'ai dropbear je sais reflasher.
Il faudrait quand même que je teste le mode failsafe via liaison série au cas où


Maintenant on va travailler le fichier de config pour maitriser les options.

Par ailleurs, vous auriez des liens qui pourrait m'expliquer les histoires d'overlay ?
Si j'ai bien compris au lieu de monter ma clé USB (ou carte µSD) dans un répertoire, il serait possible de "plaquer" le filesystem de la clé USB par dessus le filesystem read-only
C'est çà ?
Comment kon fait ?

A+

[Reply #62 on:]

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".

[Reply #63 on:]

Tu as trouvé pourquoi ça ne marchait pas ?

Non. La génération avec Image Generator (trunk) ne marche pas.
Je suis passé à BuildRoot.

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  

Déjà fait. Connecteur 6 points et adaptateur SparkFun externe, le même que j'utilise avec ma breadboarduino.

J'ai commandé 2 nouveaux convertisseurs à base de CP21xx mais dans l'idée de m'en servir dans l'autre sens pour avoir + de liaisons série sur le WR pour dialoguer avec des cartes distribuées dans la maison.

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.

Oui de toute façon je vais vite virer Luci et le serveur web puisque j'aurais mes pages Web applicatifs a moi.
Quand j'aurais figé mon noyau de base, je n'aurais plus besoin d'upgrade de firmware complet, je ferait de l'install dynamique des nouvelles applis.

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

merci.
De la bonne lecture en perspective.

[Reply #64 on:]

Aide demandé

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

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

ci attaché mon fichier de config

merci d'avance

[Reply #65 on:]

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

[Reply #66 on:]

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)

[Reply #67 on:]

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

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

[Reply #68 on:]

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 !

[Reply #69 on:]

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

[Reply #70 on:]

Bon, ben j'ai bien bidouillé ma config

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

Code:

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.

[Reply #71 on:]

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

[Reply #72 on:]

AAAaaarrrrrgggghhhh 

Ce qui devait arriver arriva !

BRICK

Code:

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

Code:

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

Code:

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

Code:

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

Question 1:
Docteur je reflashe quoi ?
Juste le firmware ou aussi le rootfs ?

Question 2:
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 ....

Question 3:
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 :

Code:

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

[Reply #73 on:]

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

[Reply #74 on:]

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 !