Compilation Ppc8544/ 8533

[MS_Totor]

bonjour, je fais un appel à vos contributions, expériences, échecs ou réussites, mes connaissances en cross-compilations sous linux, datent d' il y a plus de 8 ans ......je m'y remets doucement, dur dur.

Le but: compiler des modules kernel en premier temps pour syno à base de ppc8544/8533 kernel 2.6.24 pour la communauté nas-forum, et mes besoins pro en deuxième temps si la première étape est franchie.... y arriver

mon contexte de travail:

-SYNO de tests, DS209+ 1024 deux DD 500 go en raid1 de tests, aucunes infos vitales.

-cross-compilation sur ubuntu station ou debian 5 station, les deux systèmes 100 % opérationnels sous vmware.

pour préparer ce contexte, j'ai suivi principalement ces liens et d'autres et fait quelques modifs pour adapter la documentation incomplète officielle, et le peu d'informations sur le retour d'essais.

• http://www.nas-forum...?showtopic=4980
• http://sourceforge.net/projects/dsgpl/
• http://download.syno...ion%20Guide.pdf
• un lien sur mes tests effectués http://www.syno.fr.c...FIGURATION-IPKG

Si on suit à la lettre le lien du document officiel en PDF pour cross compiler, ou toutes infos dispo sur le net, il n'y a rien comme retour ds209+, ou très vague.

mes modifs

Editez le makefile

#ARCH ?=arm

ARCH ?=powerpc

CROSS_COMPILE ?= /usr/local/powerpc-linux-gnuspe/bin/powerpc-linux-gnuspe-

puis on peut lancer après les menuconfig etc...

puis make modules

les modules sont crées dans arborescence, des répertoires

Exemple: /usr/local/powerpc-linux-gnuspe/source/linux-2.6.24/net/ipv4/netflter

hors, si tout cela a excellemment bien fonctionné sous firmware 844, 850, etc... c'est un échec sous firmware 9xx.

Ma grande question:

A version de kernel égale: 2.6.24 pour le même type d'architecture CPU dans les fichiers sources

qu'est ce qui peut générer des erreurs kernel sur un firmware 9xx et pas sur firmware 84x, 85x ?

pour cross-compiler des kernel, toutes sommes faites, c'est la partie la plus facile à faire normalement....mêmes sources, mêmes headers, même CPU.

je pencherais mon doute, soit vers des arguments différents de compil non décrits dans la doc, soit vers la toolchain qui utilise une version de GCC moins récente que celle utilisé par synology pour compiler le kernel sur firmware 9xx.

Mais je ne suis pas assez compétent, pour affirmer ou connaitre avec quels versions d'outils, les kernel 9xx ont étés compilés, quelqu'un de plus expérimenté peut nous éclairer sur la chose ?

une toolchain peut elle être modifiée pour intégrer des outils plus récents etc.... afin de trouver la solution ?

merci d'avance, je ne pense pas être le seul à être bloqué

PS: j'ai suivi énormément de liens ou bzou de nslu2 ou dino font descriptions de leurs méthodes d'intégrations, mais même dans ces voies là rien de stable et idem échec...

bref dans l'impasse à moins d'une voie ou une approche différente ?

[cricx]

sur ton syno, tu peux tenter la compilation native !

Modifié le 10 octobre 2009 par cricx

[MS_Totor]

bonjour collègue

j'ai été contacté par MP à plusieurs reprises pour échanger, méthodes de compil, succès, échec etc..etc... , mais je préfère en débattre sur le forum, et je re précise, je ne parle pas de compilation native, mais de cross-compilation

Modifié le 10 octobre 2009 par MS_Totor

[cricx]

bonjour coll

[MS_Totor]

et oui le probl

[cricx]

et oui le probl

[MS_Totor]

c'est fait, j'ai envoy

[MS_Totor]

Mon mail portait sur la différence d'environnement depuis la venue des firmwares 9xx, en particulier le fait que les modules kernels compilés et fonctionnels sous 850, ne l'étaient plus sur sur 9xx, même cpu, même version de kernel, que cela avait un impact non négligeable sur des synos déployés avec des applis spécifiques dans le milieu pro..

J'ai donc demandé, si l'environnement de dev avait été changé à ce niveau, GCC v3.4.3, etc... si des fonctions du kernel actuel avaient été modifiées pouvant empêcher l'intégration de modules tierce partie, et si une planification d'une nouvelle version de toolchains ou de sources GPL était prévue.

Unfortunately, we do not have a certain plan for releasing the new toolchain at the moment and I'm sorry that I may not be able to provide an exact schedule for this support. It would probably take some time before our official announcement.

The GCC version for building the 942 is v.3.4.3

Le retour sur leur environnement de compilation est chasse gardée et hyper succins comme je m'y attendais, et zéro info sur les futures sources GPL..

bref pas trop le choix

en gros soit downgrade vers 850 pour garder un système "plus ouvert" ou attente que quelqu'un trouve une solution pour contourner le souci kernel actuel touchant les DS209+ et firmware 942, n'ayant pas d'autres modèles, je ne peux que me prononcer sur celui là.

je laisse ce thread ouvert, pour ne pas saturer le tuto existant sur la cross compilation, et le saturer de tests, si quelqu'un a des news ou arrive à trouver la bonne méthode faites signe

[cricx]

Mon mail portait sur la différence d'environnement depuis la venue des firmwares 9xx, en particulier le fait que les modules kernels compilés et fonctionnels sous 850, ne l'étaient plus sur sur 9xx, même cpu, même version de kernel, que cela avait un impact non négligeable sur des synos déployés avec des applis spécifiques dans le milieu pro..

J'ai donc demandé, si l'environnement de dev avait été changé à ce niveau, GCC v3.4.3, etc... si des fonctions du kernel actuel avaient été modifiées pouvant empêcher l'intégration de modules tierce partie, et si une planification d'une nouvelle version de toolchains ou de sources GPL était prévue.

Unfortunately, we do not have a certain plan for releasing the new toolchain at the moment and I'm sorry that I may not be able to provide an exact schedule for this support. It would probably take some time before our official announcement.

The GCC version for building the 942 is v.3.4.3

Le retour sur leur environnement de compilation est chasse gardée et hyper succins comme je m'y attendais, et zéro info sur les futures sources GPL..

bref pas trop le choix

en gros soit downgrade vers 850 pour garder un système "plus ouvert" ou attente que quelqu'un trouve une solution pour contourner le souci kernel actuel touchant les DS209+ et firmware 942, n'ayant pas d'autres modèles, je ne peux que me prononcer sur celui là.

je laisse ce thread ouvert, pour ne pas saturer le tuto existant sur la cross compilation, et le saturer de tests, si quelqu'un a des news ou arrive à trouver la bonne méthode faites signe

dommage que synology ne joue pas l'ouverture... mais finalement, leur clientèle est la même que celle de microsoft...

geeks passez votre chemin (et montez votre serveur vous-mêmes)

ceci dit, pour ton pb, si la version de gcc et celle du noyau est la même et que tu copies les modules compilés avec le fw précédent au bon endroit, ils devraient pouvoir se charger, non ? tu as fait un depmod ? quels sont les messages d'erreur lors d'un modprobe ?

quels sont les messages d'erreur lors de la compilation ? pb de symboles ? voir les headers

[MS_Totor]

j'ai démonté/remonté complètement mon environnement de dev, je remets le tout à plat ce week end, vive la virtualisation...

pour les erreurs, avec ceux d'ipkg c'était du symboles inconnus, problèmes de headers, avec ceux que j'ai cross compilé, , c'est du plantage beaucoup beaucoup plus sournois, pas de messages d'erreurs, mais pas de carte virtuelle montée tun0 via /dev/net/tun

si j'avais le malheur de lancer un seul ifconfig, pour verifier mes cartes reseaux, le process lancé en console ifconfig tournait en boucle et impossible de le killer, puis led bleue allumée, mes volumes raid étant ok, la définition de la led bleue, doit signaler d'autres messages d'erreurs, que les soucis de volume, ou c'est lié à dev, bref plantage de la partie dev, le reste des commandes shell restaient fonctionnelles, sauf les commandes systèmes touchant à l'arrêt ou reboot du syno, gestion process pour killer, et ifconfig..

j'ai pu lister tous les processus ouverts etc...mais rien pu faire, mis à part au bout d'un sacré bon moment de recherche à débrancher le jus, n'ayant plus la main, toute connexion déjà ouverte restait opérationnelle, mais impossible d'en créer d'autre, plus d'allocation tty autorisée.

via le manager web idem tout ok sauf reboot ou halt

je n'ai pas essayer de re allouer les ressources manuellement, étant trop rouillé dans ce domaine.

une seule fois j'ai bien eu le process ouvert 31194 port udp définit pour openvpn au lieu du classique 1194, (ce qui ne devrait poser aucun soucis) mais plantage comme décrit, test fait sans firewall sur le syno, ni autoblock bien sur.

je le répète sournois le truc, prochain test, mano à mano, et je note tout dans un coin, chaque étape, chaque config pointée, chaque modif, pour y voir plus clair ensuite, j'ai tout viré, trop de notes un peu partout, et je n'arrive plus à me relire correctement, le comble pour un procédurier dans ce domaine de tests

je vois cela à tête reposé, j'ai aussi viré sur le syno de test, tous mes trucs compilés en natif

[Merimac]

Bonjour,

Je ne sais pas si