Ouf, j’ai enfin la solution a un bug qui m’ennuyait depuis longtemps : au boot mon portable L400 de Dell m’offrait un superbe ecran noir avec curseur clignotant si je ne passais pas à chaque fois par le boot-menu … Un peu pénible ! Bien sûr, dans le Bios, impossible de changer l’ordre du démarrage une sombre vrai-fausse histoire de mode superviseur. En réalité, pour se sortir de cette histoire il suffit de falsher son BIOS pour une version plus récente. Pour ma part je suis passé du bios A3 au bios A9 disponible sur le site de Dell et il fonctionne à merveille maintenant.
Category Archives: Hardware
Intégrer une carte mère de Dell Gx150 dans un PC standard
A destination de ceux qui comme moi souhaiteraient intégrer dans un boitier standard une carte mere de Dell Gx150 … C’est possible …
Tout d’abord il faut faire un peu de bricolage car avec Dell tout est presque standard ! Par exemple le panneau arrière est presque ATX … bref, il faut s’équiper d’une scie à métaux, d’un marteau, d’une perceuse … et c’est possible !
Ensuite l’etape ultime est la connexion des boutons de l’interface sur le connecteur “FrontPanel” non documenté … dont je vous livre ici les principaux secrets !
A o o o C D F o ... H o o B o o o o o E G o ... o o o
Le repere est la patte manquante entre D et F, les o indiquent les pattes dont je n’ai pas evalué l’usage. Pour le reste :
- A & B : Speaker resp. – et +
- C & D : Power Led resp. – et +
- F & G : Power Switch
- E & H : HDD Led resp. – et +
Bon bricolage !
Controler la vitesse des ventilateurs d’une carte mère
Sur les dernières cartes mère, il est possible de contrôler via soft la vitesse des ventilateurs (fan-control). Cette fonctionnalité permer de jouer sensiblement sur le bruit de la machine.
Sur les carte MSI KT8 (utilisant un chip NForce 3 équipée d’un chip w83627thf) il est possible de controler la vitesse des ventilateurs au travers du périphérique associé dans /sys (pour peu que vous soyez bien en noyau 2.6)
La commande suivante permet celà :
echo $valeur > /sys/bus/i2c/devices/2-0290/pwm1
$valeur est un nombre entre 0 et 240. 0 étant l’arret complet du ventilateur. pwm1 correpond au premier ventilateur. La carte peut en gérer 3 qui seront alors pwm1, pwm2 et pwm3.
Patch du driver rt2570 pour permettre le changement d’adresse MAC
Note : depuis mon patch à été ajouté directement dans les drivers natif …
Le drivers rt2570, correspondant aux chip USB ralink souffre d’un petit bug, à moins qu’il ne s’agisse d’une fonctionnalité, je ne sais pas ! il n’est pas possible de changer leur adresse MAC.
Après analyse du problème, il s’avère que lorsque l’on remonte le driver par un ifconfig rausb0 up celui-ci effectue une réinitialisation complète du périphérique incluant donc le rechargement de l’adresse MAC d’origine et venant donc écraser celle configurée précédemment par le ifconfig rausb0 hw ether ….
La solution a ce problème est assez simple, lors de l’init que l’on trouve dans rtusb_main.c il suffit de tester si l’adresse MAC du net_dev vaut 00, auquel cas on charge celle de la carte (premier appel) sinon, on conserve la valeur du net_dev qui correspond à celle forcée.
Ce qui se traduit par :
Dans la fonction usb_rtusb_open, ligne 1231 environ
RTUSBCmd_kill =0;
CreateThreads(net_dev);
memcpy(pAdapter->net->dev_addr, pAdapter->CurrentAddress, pAdapter->net->addr_len);
// Clear Reset Flag before starting receiving/transmitting
RTMP_CLEAR_FLAG(pAdapter, fRTMP_ADAPTER_RESET_IN_PROGRESS);Va devenir:
RTUSBCmd_kill =0;
CreateThreads(net_dev);
// at every open handler, copy mac address.
// PATCH >>>>>>>>>>>>>>>>>>
if ( net_dev->dev_addr[0] == 0 && net_dev->dev_addr[1] == 0 && net_dev->dev_addr[2] == 0 &&
net_dev->dev_addr[3] == 0 && net_dev->dev_addr[4] == 0 && net_dev->dev_addr[5] == 0 ) {
// First time initialization
memcpy(pAdapter->net->dev_addr, pAdapter->CurrentAddress, pAdapter->net->addr_len);
} else {
// Next time “la vérité est ailleurs!”
memcpy(pAdapter->CurrentAddress, pAdapter->net->dev_addr, pAdapter->net->addr_len);
}
// <<<<<<<<<<<<<<<<< PATCH// Clear Reset Flag before starting receiving/transmitting
RTMP_CLEAR_FLAG(pAdapter, fRTMP_ADAPTER_RESET_IN_PROGRESS);
Après on recompile, et la solution a l’air de fonctionner …. ??? et bien en fait non elle ne fonctionne pas !! oups.. j’aurais dû un peu plus tester … j’avais un petit oubli … voila qui est corrigé ! merci à larbig d’avoir complété le boulo.
Il semble en effet que l’adresse MAC doit être la même entre le pAdapter et le net_dev sans quoi les trames ne sont pas emises dans l’air … ennuyeux. voici donc le patch complet et cette fois testé !! sisi !! Les modifications sont cette fois dans rtusb_init.c où il faut modifier la fonction NICReadEEPROMParameters de la façon suivante :
VOID NICReadEEPROMParameters( IN PRT2570ADAPTER pAdapter) { USHORT i; int value; UCHAR TmpPhy; EEPROM_TX_PWR_STRUC Power; EEPROM_ANTENNA_STRUC Antenna;//blue // EEPROM_VERSION_STRUC Version; DBGPRINT(RT_DEBUG_TRACE,"--> NICReadEEPROMParameters "); //Read MAC address. RTUSBReadEEPROM(pAdapter, EEPROM_MAC_ADDRESS_BASE_OFFSET, pAdapter->PermanentAddress, ETH_LENGTH_OF_ADDRESS); DBGPRINT_RAW(RT_DEBUG_TRACE,"MAC address ReadEEPROM : "); for (i = 0; i < ETH_LENGTH_OF_ADDRESS; i++) DBGPRINT_RAW(RT_DEBUG_TRACE,"%02x ", pAdapter->PermanentAddress[i]); DBGPRINT_RAW(RT_DEBUG_TRACE," "); if (pAdapter->PortCfg.bLocalAdminMAC != TRUE) { pAdapter->CurrentAddress[0] = pAdapter->PermanentAddress[0]; pAdapter->CurrentAddress[1] = pAdapter->PermanentAddress[1]; pAdapter->CurrentAddress[2] = pAdapter->PermanentAddress[2]; pAdapter->CurrentAddress[3] = pAdapter->PermanentAddress[3]; pAdapter->CurrentAddress[4] = pAdapter->PermanentAddress[4]; pAdapter->CurrentAddress[5] = pAdapter->PermanentAddress[5]; }
devient
VOID NICReadEEPROMParameters( IN PRT2570ADAPTER pAdapter, struct net_device *net_dev) { USHORT i; int value; UCHAR TmpPhy; EEPROM_TX_PWR_STRUC Power; EEPROM_ANTENNA_STRUC Antenna;//blue // EEPROM_VERSION_STRUC Version; DBGPRINT(RT_DEBUG_TRACE,"--> NICReadEEPROMParameters "); //Read MAC address. RTUSBReadEEPROM(pAdapter, EEPROM_MAC_ADDRESS_BASE_OFFSET, pAdapter->PermanentAddress, ETH_LENGTH_OF_ADDRESS); DBGPRINT_RAW(RT_DEBUG_TRACE,"MAC address ReadEEPROM :"); for (i = 0; i < ETH_LENGTH_OF_ADDRESS; i++) DBGPRINT_RAW(RT_DEBUG_TRACE,"%02x ", pAdapter->PermanentAddress[i]); DBGPRINT_RAW(RT_DEBUG_TRACE,""); if (pAdapter->PortCfg.bLocalAdminMAC != TRUE) { if ( net_dev->dev_addr[0] == 0 && net_dev->dev_addr[1] == 0 && net_dev->dev_addr[2] == 0 && net_dev->dev_addr[3] == 0 && net_dev->dev_addr[4] == 0 && net_dev->dev_addr[5] == 0 ) { // Startup time ... read the original MAC pAdapter->CurrentAddress[0] = pAdapter->PermanentAddress[0]; pAdapter->CurrentAddress[1] = pAdapter->PermanentAddress[1]; pAdapter->CurrentAddress[2] = pAdapter->PermanentAddress[2]; pAdapter->CurrentAddress[3] = pAdapter->PermanentAddress[3]; pAdapter->CurrentAddress[4] = pAdapter->PermanentAddress[4]; pAdapter->CurrentAddress[5] = pAdapter->PermanentAddress[5]; } else { // Next time, get the MAC from net_dev->dev_addr printk(KERN_INFO "net_dev supplies MAC, activating this one :%02x:%02x:%02x:%02x:%02x:%02x.", net_dev->dev_addr[0], net_dev->dev_addr[1], net_dev->dev_addr[2], net_dev->dev_addr[3], net_dev->dev_addr[4], net_dev->dev_addr[5]); memcpy(pAdapter->CurrentAddress, pAdapter->net->dev_addr, pAdapter->net->addr_len); } }
La mécanique est axactement la même que celle faite précédemment : lors du premier appel on fait comme si de rien n’etait et on recupère l’adresse en EEPROM, pour les appels suivant on choisit la MAC du net_dev à la place.
Pour que ca fonctionne il reste deux petites modifications, modifier le header de cette fonction : dans rt2570sw.h
VOID NICReadEEPROMParameters( IN PRT2570ADAPTER pAdapter);
devient :
VOID NICReadEEPROMParameters( IN PRT2570ADAPTER pAdapter, struct net_device *net_dev);
enfin il reste l’appel de la fonction de lecture à modifier, dans rtusb_main.c:
NICReadEEPROMParameters(pAdapter, net_dev);
Ca y est !!
Installation de l’environnment de dev pour SPARTAN (Xilinx) sous linux
Après avoir reçu mon kit Spartan-3 de Xilinx 🙂 🙂 … sur lequel j’aurai bien l’occasion de revenir par ailleurs, je découvre avec un enorme plaisir que CA Y EST ! Xilinx fournit une version Linux de son outil de développement. Après deux an d’abstinence coté FPGA, snif, je suis heureux de faire ce retour aux sources sur mon environement favori !
Avant tout, j’ai réalisé l’installation sur une distribution Suse 9.2 avec un noyau 2.6.8.
Après téléchargement depuis le site de Xilinx des fichier adéquat : WebPACK_71_fcfull_i.sh, j’ai du faire quelques manips avant de lancer l’install :
- Autoriser l’ouverture de display : xhost +
- Passer root : su
- modifier l’export par : export DISPLAY=:0
Pour enfin lancer le script d’install ; celle-ci bloque quelques secondes après la validation du répertoire cible mais rien de grave, l’installation continu quelques instants plus tard. A noter que les librairie OpenMotif doivent être installées (libXm.so.3)
En fin d’installation, les choses se compliquent : les drivers parallèle et usb de programmation sont compilés pour des noyau 2.4 il faut donc procéder à une petite recompilation manuelle …
1. Installer tout ce qu’il faut sur Linux
En premier lieu, il vous faudra installer les sources du noyau à l’aide de yast. Ensuite, les manip suivantes doivent être faites :
- cd /usr/src/linux
- make cloneconfig
- make prepare
Il faut ensuite donner les droits à qui de droit sur le port parallèle (pour utilisation future) :
- chmod a+rw /dev/parport0 (par exemple)
2. Télécharger les sources du driver
Les sources sont ici ou alors en version alégée et deja modifiée là. Préférez le premier liens ou celui-ci au cas où…
La décompression des sources est classique : tar -zxvf fichier.tgz
Enfin, allez dans le répertoire adéquat normalement linuxdrivers/xpc4drvr/
3. Modification des sources
Si vous avez la version allégée et modifiée des sources, tout est dejà fait sinon, il y a quelques points rapide à réaliser :
- Supprimer le Makefile pour le remplacer par celui-ci
- Editez xpc4.c et remplacer #include par #include <config/modversions.h>
- Ajoutez ensuite à la suite des includes le suivant : #include
- Pour les noyau 2.6.1x et/ou suse 10, il faudra aussi mettre en commentaire les lignes contenant les macros MOD_INC_USE_COUNT et MOD_DEC_USE_COUNT
4. Compilation et installation
Etape finale : compiler le driver, simplement par la commande make
Pour charger le driver, il suffira alors en temps que root de taper la commande insmod ./xpc4drv.ko
Le driver peut enfin être copié là où l’installation le place normalement à savoir dans le répertoire /lib/modules/misc.
5. Le driver windrv6
Il a fallu attendre quelque temps, mais ce driver propriétaire est enfin compatible avec les noyaux 2.6. Il faudra le télécharger à l’adresse suivante : jungo.com. Le site demande une inscription. La version que j’ai utilisé est une 7.1. L’installation se fait après décompression en alant dans le répertoire WinDriver/redist.
1. Lancer ./configure
Rq du 13/11/05 : Les modifications qui suivent ne semblent plus nécessaires avec la version 7.2 du driver.
2. éditer le makefile et changez :
2.a. KERNEL_DIR= /usr/src/linux/
2.b. Supprimer tous les -I… de la ligne CFLAGS
2.c. Ajouter en début de CFLAGS -I../include -I/usr/src/linux/include -I/usr/scr/linux/include/asm-i386/mach-default/
3. compiler : make installUne version dejà modifiée du Makefile est ici
Le driver est ensuite à copier manuellement dans le repertoire /lib/modules/misc. Il sera lancé par /sbin/insmod /lib/modules/misc/windrvr6.ko.
6. Utilisation
Pour la suite, il reste à lancer iMPACT et la détection automatique à partir du boundary scan s’est bien passée pour ma part. La programmation fonctionne.