Re: Debian embarquée
Selon Roger Mampey <Roger.Mampey@cert.fr>:
| Selon Thomas Nemeth :
|
| > Attention : les noyaux debian sont parfois patchés et donc ne
| > correspondent pas forcément aux noyaux vanilla.
| >
| Ah ! Ca doit suffire à expliquer pourquoi il y a une différence. Est-ce
| qu'il est possible d'obtenir sur le site de la Debian les sources
| correspondant aux images qu'elle propose ?
Pour les paquets habituels c'est le cas : il suffit d'aller sur la
page concernant le paquet et tu as le .tar.orig et le patch.
Maintenant je ne sais pas ce qu'il en est du noyau mais je ne vois
pas pourquoi il en serait autrement.
| > Tiens donc ? Qu'entends-tu par "disparition" ?
| > Veux-tu dire que c'est commenté par un # suivi de "is not set" ?
| >
| Non, ca n'apparait plus du tout. Attention : CONFIG_EXT2_FS et
| CONFIG_EXT3_FS sont toujours là, ce qui disparait, ce sont des
| parametres de type CONFIG_EXT?_FS_XATTR* et CONFIG_EXT?_FS_POSIX_ACL A
| part ca, il y a d'autres disparitions.
Ça doit être dû aux patches qui sont différents.
| > As-tu plutôt tenté de faire un 'make oldconfig' ?
| >
| Je connais config, menuconfig et xconfig. Mais pas oldconfig. Ficheux
| recommande chaudement d'éviter config, alors oldconfig :-)
S'il recommande d'éviter config c'est que depuis les débuts du noyau
de nombreuses options et un support matériel immense ont été rajoutés
alors que 'make config' passe toutes les options une par une... Tu
imagines le souk si tu devais te taper toutes les options à la suite
:) ?
| Je suppose
| que oldconfig ne prend aucune initiative alors que ce n'est visiblement
| pas le cas de menuconfig. Je vais regarder si j'ai ca.
oldconfig ne te pose de question que sur les nouvelles options par
rapport à ton ancien noyau.
| > Il aurait fallu le message exact de ton kernel panic,
| >
| "Attempted to kill init !" :-)
Ouch !
| > Autre pb : plus haut tu me parles de 2.4.27 et là c'est 2.4.7...
| > Est-ce une erreur de frappe ? Quel est le bon numéro ?
| >
| Correction, c'est 2.4.27. Mais j'ai installé tout le répertoire
| /lib/modules/2.4.27 sur la cible. Non vide avec les bons droits et
| modules.dep non vide.
Et il y a quoi en module ?
Pour un noyau minimal bien réduit il ne devrait pas y en avoir
beaucoup (voire aucun).
| A part ca, j'ai essayé une autre manip qui tue :
|
| Je pars toujours du fichier de config de la cible et j'utilise toujours
| menuconfig et je supprime le support des modules sans m'occuper de
| quoique ce soit d'autre (en vérifiant quand meme que les anciens modules
| indispensables - network, ide, ... - sont bien passés de 'm' à 'y'), La
| compilation du noyau échoue dans le répertoire .../drivers/isdn/eicon.
| Je vais reessayer en supprimant le support isdn, mais ca énerve surtout
| quand on ne sait pas exactement de quoi on a absolument besoin.
Tu ne sais pas de quoi tu vas avoir besoin ?
Généralement, lorsque tu fais de l'embarqué, tu sais exactement sur
quelle cible tu va mettre ton noyau. À ce titre, j'enlève tout ce qui
n'est pas directement en rapport avec le matos que je veux faire
marcher (et généralement le matos est peu complexe, dans l'embarqué).
En l'occurence nous avons développé dans ma boite une carte CPU ARM
avec plein de ressources mais seulement certaines sont utilisées par
les cartes "métier" utilisant cette carte CPU : à chaque nouvelle
carte j'adapte le noyau en virant les ressources non utilisées par la
carte métier... Mais cela implique de connaître parfaitement le matos.
Avant de faire un noyau essaye de te renseigner sur le matériel que
tu dois supporter. Si c'est pour faire un test sur ton propre pécé,
alors prend la doc de ta carte mère, de tes périfs etc. et ne prend
les pilotes que de ce que tu veux supporter. Peu importe si tout
n'est pas présent, il te suffit de tester et rajouter ce qui te manque
au fur et à mesure que tu t'en rends compte (pense alors à tout noter
à chaque modif).
| Peut-etre bien qu'un fichier de config pour noyau amaigri sur PC serait
| une meilleure base de départ. Mais quand meme, un échec à la compilation
| en remplacant (en laissant make menuconfig le faire) tous les modules
| par du code interne noyau. est-ce bien normal ?
Oui même si c'est rare : il y a du matériel incompatible avec
certaines options.
Thomas.
Reply to: