Beiträge getagged mit Hardware
arcdisp.c – XP-Fehler
Ich wollte einen altes, betagtes Notebook mit der Installations-CD “Windows XP” booten – das Betriebssystem fährt nicht mehr wie erwartet hoch.
Sehr rasch wird immer wieder der gleiche Fehler angezeigt:
Ein unerwarteter Fehler (0) ist in Zeile 1773 in pfadderdiskarcdisp.c aufgetreten.
Fazit: Der Tausch eines RAM Bausteins hat Abhilfe gebracht, das installierte System bootete wieder ordnungsgemäß!
SheevaPlug – Open uboot Update
Wie schon im letzten Artikel über das SheevaPlug, wird auch diesmal wieder das u-boot Image upgedatet.
Nur mit einem Unterschied – wir kompilieren uns die aktuellste Variante selbst. In diesem Artikel wird der Vorgang beschrieben.
Los geht’s!
Die aktuelle u-boot Version auf meinem Plug:
Marvell>> version
U-Boot 1.1.4 (Jul 19 2009 – 16:03:28) Marvell version: 3.4.19
Zuerst muss man die Buildumgebung einrichten. Man benötigt in jedem Fall den GCC für die ARM Architektur. Die Binaries befinden sich innerhalb des SheevaPlug_Host_SWsupportPackageLinuxHost.zip Paket. Entweder man lädt das Paket von hier herunter oder verwendet das von der mitgelieferten CD. In diesem Fall werde ich das Paket von der CD nutzen, denn der Versionsstring auf der genannten Downloadseite zeigt aktuell 1.1.0 (Februar 2009)- auf der CD jedoch befindet sich das Paket in Version 1.2 (April 2009)
Ich entpacke das Paket in welchem sich gcc.tar.bz befindet. Diese Datei entpacke ich nun in den Ordner meiner Wahl, welchen ich anschließend exportieren und für die dauerhafte Verwendung an die PATH Variable in der .bashrc anhänge.
sudo mkdir -p /usr/local/sheevaplug
sudo tar xjf /pfad/zur/gcc.tar.bz2 -C /usr/local/sheevaplug
export PATH=$PATH:/usr/local/sheevaplug/gcc/bin
echo “#SheevaPlug – GCC Pfad” >> ~./bashrc
echo “export PATH=$PATH:/usr/local/sheevaplug/gcc/bin” >> ~/.bashrc
Nach diesem Eingriff sind im Terminal einige Befehle namens arm-none* verfügbar.
Jetzt müssen noch ein paar Dinge installiert werden, nämlich git-core und openocd. Das ist schnell erledigt mit
sudo aptitude install openocd git-core
Einen TFTP Server benötigt man für die spätere Installation, Putty oder cu für den seriellen Zugriff. Diese Dinge setze ich jetzt einfach mal voraus.
Jedenfalls ist jetzt das Benötigte beisammen und das Cross Compilen, wie man so schön sagt, kann beginnen.
Ich lege mir nun einen Ordner an und lade die Open U-Boot Sourcen runter wie auf der Seite beschrieben.
mkdir -p ~/.sheevaplug/open-uboot
cd ~/.sheevaplug/open-uboot
git clone git://git.denx.de/u-boot-marvell.git u-boot-marvell.git
Die Ausgabe von git quittiert den Download
remote: Counting objects: 107270, done.
remote: Compressing objects: 100% (20780/20780), done.
remote: Total 107270 (delta 87565), reused 105564 (delta 85876)
Receiving objects: 100% (107270/107270), 30.94 MiB | 1.61 MiB/s, done.
Resolving deltas: 100% (87565/87565), done.
Checking out files: 100% (6386/6386), done.
Nun wechsel ich in den von git erstellten Ordner und führe einen Checkout durch
cd u-boot-marvell.git
git checkout -b testing origin/testing
welcher ebenfalls quittiert wird
Branch testing set up to track remote branch testing from origin.
Switched to a new branch ‘testing’
Jetzt kommt das eigentliche Cross Compilen… saubermachen, config erstellen & compilen!
make mrproper
make sheevaplug_config
make u-boot.kwb CROSS_COMPILE=arm-none-linux-gnueabi-
Der Wert von CROSS_COMPILE orientiert sich an dem Namen der neuen ARM GCC in /usr/local/sheevaplug/gcc/bin, hier heißen alle Dateien so, auch der gcc.
Der Kompiliervorgang ist schnell erledigt und präsentiert uns auch gleich das Ergebnis
Preparing kirkwood boot image to boot from nand
Nand ECC mode = default
Nand page size = 0×800
Image Type: Kirkwood Boot from NAND Flash Image
Data Size: 174124 Bytes = 170.04 kB = 0.17 MB
Load Address: 00600000
Entry Point: 00600000
Wie in dem zu Beginn erwähnten Artikel zu lesen ist, wird jetzt testweise das ELF Image hochgeladen und getestet ob es auch funktioniert.
file u-boot*
zeigt, welche Datei benutzt werden muss 
Nun werden 3 Terminalfenster benötigt:
In Fenster 1 wird nun openocd gestartet, den auf der Seite genannten Pfad musste ich dazu anpassen.
sudo openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg
Es steht folgendes im Fenster 1:
Open On-Chip Debugger 0.3.1 (2009-11-25-12:22)
$URL$
For bug reports, readhttp://openocd.berlios.de/doc/doxygen/bugs.html
2000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
jtag_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use ‘feroceon.cpu’ as target identifier, not ’0′
Info : clock speed 2000 kHz
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 0x0a02, ver: 0×2)
Info : Embedded ICE version 0
In Fenster 2 verbinde ich mich wie gewohnt über /dev/ttyUSB0
cu -s 115200 -l /dev/ttyUSB0
In Fenster 3 starte ich eine Telnetsession, der Verbindungsaufbau wird in Fenster 1 quittiert.
telnet localhost 4444
Dann wollen wir mal…
In Fenster 3, also der Telnetsitzung, werden nun folgende Befehle abgesetzt
sheevaplug_init
load_image /pfad/zur/kopilierten/elfdatei/u-boot
resume 0×00600000
Nach absetzen des letzten Befehls bootet das Gerät neu mit der selbstkompilierten u-boot wie man in Fenster 2 beobachten kann. Hier erkundige ich mich gleich nach der Version – schaut gut aus!
Marvell>> version
U-Boot 2009.11-00922-g1103196 (Feb 19 2010 – 13:36:10)
Marvell-Sheevaplug
Fenster 3 beende ich mit “exit”, Fenster 1 wird mit Strg+C beendet und anschließend in Fenster 2 ein “reset” eingetippt.
SheevaPlug bootet dann wieder mit dem installierten u-boot.
Im letzten Schritt will ich die selbstkompilierte Version auf den Speicher installieren. Dazu geht man ahnlich vor wie im ersten u-boot Update Artikel. Zuerst muss die kompilierte u-boot.kwb (also NICHT die elf-binary!!) ins TFTP Verzeichnis kopiert und der Updatevorgang wie gehabt durchgeführt werden.
In der Kürze auf der SheevaPlug:
Marvell>> setenv ipaddr 192.168.254.39
Marvell>> setenv serverip 192.168.254.108
Marvell>> tftp 0×6400000 u-boot.kwb
Using egiga0 device
TFTP from server 192.168.254.108; our IP address is 192.168.254.39
Filename ‘u-boot.kwb’.
Load address: 0×6400000
Loading: ###################################
done
Bytes transferred = 174640 (2aa30 hex)
Marvell>> nand erase 0×0 0×40000
NAND erase: device 0 offset 0×0, size 0×40000
Erasing at 0×20000 — 100% complete.
OK
Marvell>> nand write 0×6400000 0×0 0×40000
NAND write: device 0 offset 0×0, size 0×40000
262144 bytes written: OK
Marvell>> reset
Nun bootet die SheevaPlug neu und ich kontrolliere den Erfolg
Marvell>> version
U-Boot 2009.11-00922-g1103196 (Feb 19 2010 – 13:36:10)
Marvell-Sheevaplug
Sehr schön!
SheevaPlug – uboot Update
Wie schon angekündigt dokumentiere ich hier die Aktionen mit der Sheevaplug.
Auf meinem Squeeze System mit derzeit aktivem 2.6.30-2-686 Kernel wird die Kiste sofort erkannt und das Device /dev/ttyUSB0 wird erstellt.
Um das Device zu verwenden, sollte man in der Systemgruppe dialout sein. Wer das nicht ist, kann sich als root der Gruppe via
adduser $USER dialout
hinzufügen. Sollte das notwendig sein, muss man sich am System ab- und wieder anmelden. Erst dann ist die Modifikation aktiv und kann mit dem Befehl “id” auf der Konsole geprüft werden.
Es bestehen nun mehrere Möglichkeiten zu dem Device zu connecten. Putty oder cu stehen auf jedenfall zur Wahl. Ich entscheide mich für cu welches schnell via aptitude installiert ist.
Die Verbindung kann dann über
cu -s 115200 -l /dev/ttyUSB0
hergestellt werden. Leider sieht man hier die wunderschöne ASCII Grafik nicht richtig
__ __ _ _
| / | __ _ _ ____ _____| | |
| |/| |/ _` | ‘__ / / _ | |
| | | | (_| | | V / __/ | |
|_| |_|__,_|_| _/ ___|_|_|
_ _ ____ _
| | | | | __ ) ___ ___ | |_
| | | |___| _ / _ / _ | __|
| |_| |___| |_) | (_) | (_) | |_
___/ |____/ ___/ ___/ __|
** MARVELL BOARD: SHEEVA PLUG LEU-Boot 1.1.4 (Mar 19 2009 – 16:06:59) Marvell version: 3.4.16
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CEE80
Soc: 88F6281 A0 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200MhzDRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0×00000000 size 256MB
DRAM CS[1] base 0×10000000 size 256MB
DRAM Total size 512MB 16bit width
Flash: 0 kB
Addresses 8M – 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M – 7M): Done
NAND:512 MBCPU : Marvell Feroceon (Rev 1)
Streaming disabled
Write allocate disabledUSB 0: host mode
PEX 0: interface detected no Link.
Net: egiga0 [PRIME], egiga1
Hit any key to stop autoboot: 0
Marvell>>
An dieser Stelle sollte man zügig irgendeine Taste drücken, sonst bootet die Kiste in das vorinstallierte System.
Nun ist man auf der Marvell Commandline. Über
help
kann man sich die verfügbaren Kommandos anzeigen lassen.
Wichtig ist die uboot Version die man sich mit dem Befehl
version
ausgeben lassen kann.
Meine Kiste gibt mir folgende Ausgabe:
U-Boot 1.1.4 (Mar 19 2009 – 16:06:59) Marvell version: 3.4.16
Ein dringendes Update auf 3.4.19 ist erforderlich – mit dieser Version wurde die FAT32 Unterstützung verbessert.
Für das Update gibt es auch wieder mehrere Möglichkeiten – entweder über TFTP oder über USB. Ich nutze die USB Variante und formatiere deshalb mit gparted einen 1GB Stick mit FAT32.
Über die Marvellkonsole will ich nun, wie auf dieser Seite beschrieben, die notwendigen Schritte durchführen. Leider jedoch wird “usb start” schon wie folgt quittiert.
Marvell>> usb start
(Re)start USB…
USB: scanning bus for devices… 2 USB Device(s) found
scanning bus for storage devices… Device NOT ready
Request Sense returned 00 00 00
0 Storage Device(s) found
Auch mehrere “reset” bringen keine Besserung. Die installierte uboot Version scheint tatsächlich etwas buggy zu sein oder der Noname Stick wird schlichtweg verpöhnt.
Also fluchs einen anderen Stick (Kingston – 1GB) ausprobiert – und wird wenigstens auf Anhieb gefunden
Marvell>> usb start
(Re)start USB…
USB: scanning bus for devices… 2 USB Device(s) found
scanning bus for storage devices… 1 Storage Device(s) found
Das ist aber auch nicht immer der Fall wie ich eben durch ein erneutes “reset” feststellen musste.
Als wenn das nicht genug wäre, schockt mich auch noch folgende Meldung:
Marvell>> fatload usb 0:1 0×0800000 uboot.bin
reading uboot.bin
Invalid FAT entry
4096 bytes read
Vielleicht sollte man doch die auf der Anleitungsseite empfohlene TFTP Variante wählen. Nun gut, einen Versuch war es Wert würde ich sagen – hätte ja auch klappen können *ggg*
Also installier ich mir auf die schnelle einen TFTP Server via
sudo aptitude install tftpd-hpa
und definiere das Verzeichnis /opt/tftp welches auch selbstständig angelegt wird.
Hier kopiere ich jetzt die Datei u-boot.bin-3.4.19 rein und entpacke diese dort. uboot.bin liegt nun also an der vorgesehenen Stelle.
Nun folge ich den Anweisungen der genannten Seite und siehe da:
Marvell>> setenv serverip 192.168.222.14
Marvell>> setenv ipaddr 192.168.222.88
Marvell>> bubt uboot.bin
Using egiga0 device
TFTP from server 192.168.222.14; our IP address is 192.168.222.88
Filename ‘uboot.bin’.
Load address: 0×2000000
Loading: #################################################################
############################
done
Bytes transferred = 473888 (73b20 hex)**Warning**
If U-Boot Endiannes is going to change (LE->BE or BE->LE), Then Env parameters should be overriden..
Override Env parameters? (y/n) y
Erase Env parameters sector 655360…
Erase 0 – 655360 …
Copy to Nand Flash…
done
Dieses Fest quittiere ich natürlich mit einem “reset” und warte gespannt.
Ergebnis: Der Reset geht gefühlt doppelt so schnell und folgende Version erwartet mich
Marvell>> version
U-Boot 1.1.4 (Jul 19 2009 – 16:03:28) Marvell version: 3.4.19
Geschafft! Bestens!
Fazit: Nächstes Mal sofort die TFTP Variante nutzen!
SheevaPlug Development Kit
Ich habe mir am Wochenende voller Vorfreude das SheevaPlug Development Kit bestellt – und tatsächlich – jetzt halte ich es in meinen Händen.
Nun, was ist das eigentlich?
Die dazugehörige Meldung auf Heise verschafft sicher schnell Klarheit. Ein Rechner mit ARM Prozessor in der Größe eines Trafos.
Bestellt habe ich dieses Gerät bei DuregExpress, dort ist es aber aktuell vergriffen. Bald wird noch der große Bruder GuruPlug verfügbar sein – wann genau kann aber noch keiner sagen. Deshalb begnüge ich mich vorab mit diesem Gerät, welches ja im Prinzip baugleich ist. Ein paar Features fehlen halt noch, was solls!
Ausgeliefert wird dieses Gerät mit Ubuntu Jaunty, welches sich auf dem internen NAND Speicher befindet. Im ersten Schritt werde ich dieses durch ein Debian Squeeze ersetzen und im nächsten Schritt als Router einsetzen. Schritt Null wird das Update des installierten uboot Images sein – das ausgelieferte Gerät beherbergt noch eine alte Version welche unbedingt zuerst ersetzt werden muss.
In nächster Zeit werdet Ihr hier wahrscheinlich vermehrt kleine Anleitungen für die Installation und Konfiguration hier finden – aber jetzt warten wir mal ab.
Zur Komplettierung noch ein paar Seiten rund ums Thema “Sheevaplug”:
plugcomputer.org – Hier gibt es ein reichhaltiges Forum und Wiki
Lightscribe für Linux
Viele neuere Brenner haben die Technologie eingebaut – Lightscribe, Disc Labeling.
Um diese Funktion auch unter GNU Debian nutzen zu können, muss nachfolgendes getan werden. Ich erheben keinen Anspruch auf Vollständigkeit, jedoch ist es wichtig, den Weg und die Quellen bei Bedarf zur Hand zu haben.
Wer also nach Lightscribe sucht, wird sehr schnell auf die Herstellerhomepage http://www.lightscribe.com/ gelangen. Dort kann man sich direkt im Downloadbereich umsehen – jawohl, es gibt Linuxdownloads hier!
Zuerst besorge ich mir die Systemsoftware, welche als RPM sowie auch DEB Paket zum Download bereit stehen. Mit den üblichen Boardmitteln ist das DEB Paket auch schnell und problemfrei installiert.
Auf der gleichen Seite ist auch eine Labeling-Software verfügbar – diese muss für erste Schritte genügen. Auch dies ist wieder als RPM und DEB Paket verfügbar und genau so einfach installiert.
Eine Integration in vorhandene Menüs findet nicht statt, man muss die Anwendung über das Terminal starten. Nach /opt/lightscribeApplications/SimpleLabeler gewechselt und ./SimpleLabeler ausgeführt – schon startet das Programm.
Nach wenigen Klicks zeigt sich leider ein gravierender Mangel – Fotos zu Labeln ist mit diesem Programm nicht möglich.
Die Webseite zeigt, mit welchen Programmen dies möglich sein soll – Brasero jedenfalls ist nicht dabei 
Auf der Seite von Lacie ist auch ein Labeling Programm zu finden – dies soll sich wohl mit dem KDE Burnapp k3b gut “verstehen”. Leider gibt es das Programm hier nur als RPM zum Download – d.h. es muss anschliessend noch mittels “alien” zu einem DEB File transferiert und installiert werden.
sudo alien –to-deb -v 4L-1.0-r6.i586.rpm;sudo dpkg -i 4l_1.0-1_i386.deb
Auch dieses Programm erstellt keine Shortcuts im Menü, so dass man dieses ebenfalls nur über das Terminal mit 4L-gui die Applikation starten kann. Wenigstens ist das Binary innerhalb der gewohnten Verzeichnisse installiert und daher auch im PATH zu finden.
Mit diesm App kann man nun verschiedene Bildformate auf die Scheibe drucken – so wie man sich das vorstellt!
Wichtig: Dies geht nur als root oder mit vergleichbaren Berechtigungen für diese Applikation.
Happy burning!
ath5k – Wireless Probleme mit Channel 13
Wer eine Wireless-LAN Karte von Atheros sein Eigen nennt, kann Probleme beim Verbinden mit verschiedenen Netzen haben.
Genauer gesagt ist es nicht möglich mit Netzen oberhalb des Channels 11 Verbindung aufzunehmen wie im nächsten Quote festgehalten.
iwlist wlan0 freq
wlan0 11 channels in total; available frequencies :
Channel 01 : 2.412 GHz
Channel 02 : 2.417 GHz
Channel 03 : 2.422 GHz
Channel 04 : 2.427 GHz
Channel 05 : 2.432 GHz
Channel 06 : 2.437 GHz
Channel 07 : 2.442 GHz
Channel 08 : 2.447 GHz
Channel 09 : 2.452 GHz
Channel 10 : 2.457 GHz
Channel 11 : 2.462 GHz
Current Frequency:2.412 GHz (Channel 1)
So jedenfalls sah es bei mir aus – daher werde ich hier in einer kurzen Step-by-Step Manual meine Schritte zum Erfolg festhalten.
Ich fahre derzeit mit einem Debian Squeeze (also testing) System mit einem normalen 2.6.30 Repositorykernel.
Die Karte weist sich wie folgt aus:
lspci -v
02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
Subsystem: Hewlett-Packard Company Device 137b
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at 92600000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [60] Express Legacy Endpoint, MSI 00
Capabilities: [90] MSI-X: Enable- Count=1 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel < ?>
Kernel driver in use: ath5k
Wichtig wird im Verlauf der Aktion noch der Speicherbereich – in meinem Fall also 92600000 – dazu später mehr.
Zuerst sollte man sich mittels modinfo über die möglichen Parameter schlau machen – ich liste nun also die möglichen Optionen der entsprechenden Module auf.
modinfo ath5k | grep ^parm
parm: nohwcrypt:Disable hardware encryption. (int)
Hardware Encryption deaktivieren ist bei ath5k also möglich.
modinfo mac80211 | grep ^parm
parm: ieee80211_default_rc_algo:Default rate control algorithm for mac80211 to use (charp)
Control Algorithmus konfigurieren – besser nicht
modinfo cfg80211 | grep ^parm
parm: ieee80211_regdom:IEEE 802.11 regulatory domain code (charp)
Das Modul gibt die Möglichkeit, einen Domain Code zu laden. Das schaut nach einem guten Ansatz aus. Wenn man nun also das Modul deaktiviert und mit der Option ieee80211_regdom=EU lädt, sollte sich doch etwas tun – tjoa, leider Fehlanzeige.
Hintergrund: In der EU sind WLAN Netze zw. Kanal 1 und 13 erlaubt – in USA und UK hingegen bewegt sich das Spektrum zw. 1 und 11. Hier muss man also ansetzen. Leider bringt der Optionsaufruf des genannten Modules nicht den gewünschten Erfolg mit sich.
Nach einer kleinen Recherche zeigt sich: die Firmware der Karte gibt wohl den “Takt” an – somit muss man sich diese mal genauer anschauen.
Auf einer Unterseite von MadWifi (Danke für dieses Tool an dieser Stelle!!) wird ein Werkzeug namens ath_info vorgestellt – mit diesem sollte man das Problem in den Griff bekommen. Wie auf der Seite schon deutlich zu lesen ist: VERWENDUNG AUF EIGENE GEFAHR!! Wenn man mit den Optionen nicht vertraut ist, sich unsicher fühlt oder einfach nicht weiß was hier geschieht – Bitte lasst es einfach bleiben und stellt euren Accesspoint auf einen Kanal zwischen 1 und 11 ein. Gewährleistung geben ich jedenfalls keine, damit das klar ist!
Jedenfalls wurde dieses Werkzeug von mir benutzt, mittels
svn co http://madwifi-project.org/svn/ath_info/trunk ath_info
cd ath_info/
make
war es schnell einsatzbereit.
Nun zurück zur Speicheradresse zu Beginn des Beitrags – mit dieser wird das Gerät definiert, es muss nur ein “0x” davor gestellt werden. In meinem Fall sah das dann so aus: ./ath_info 0x92600000
Eine Meldung wie Warning: Invalid EEPROM Magic number! habe ich erfolgreich ignoriert. Wichtig war der Informationsgehalt des ersten Abschnittes:
/============== EEPROM Information =============
| EEPROM Version: 5.3 | EEPROM Size: 4 kbit |
| EEMAP: 2 | Reg. Domain: 0×67 |
|================= Capabilities ================|
| 802.11a Support: no | Turbo-A disabled: yes |
| 802.11b Support: no | Turbo-G disabled: yes |
| 802.11g Support: yes | 2GHz XR disabled: yes |
| RFKill Support: yes | 5GHz XR disabled: yes |
| 32kHz Crystal: no | |
===============================================/
Reg. Domain: 0×67 – dieser Wert muss angepasst werden wie ich einem Blog entnehmen konnte.
./ath_info -w -g 1:0 0×92600000 regdomain 0
Mit diesem Befehl hebt man den Schreibschutz des ersten (von 4) Steuerregister auf, setzt die Regdomain auf 0 und schreibt dies in den EEPROM nach Bestätigung.
Nachtrag: Seit Kernelversion 2.6.32 habe ich die regdomain auf 68 (=EU1 World) gestellt – mit 0 hat es nicht mehr funktioniert!!
Es gilt nun
./ath_info -w -g 1:0 0×92600000 regdomain 68
new GPIO CR 0000000c DO 00000000 DI 00000009
regdomain (0x00bf) := 0×0000
WARNING: The write function may easy brick your device or
violate state regulation on frequency usage.
Proceed on your own risk!
Shall I write the above value(s)? (y/n)
y
writing *0x00bf := 0×0000
restoring GPIO CR c -> 0
Mit ./ath_info 0x92600000 habe ich das überprüft und tatsächlich steht da jetzt Reg. Domain: 0x00
Um das zu komplettieren, sollte man die Option ieee80211_regdom=EU beim oben genannten Modul laden.
echo options cfg80211 ieee80211_regdom=EU > /etc/modprobe.d/wlan.conf
Dies ist nur eine der verfügbaren Möglichkeiten – hauptsache, es funktioniert
Nachdem ich dann das ath5k Modul wieder geladen habe, konnten tatsächlich die 2 vermissten Kanäle gescannt werden.
iwlist wlan0 freq
wlan0 13 channels in total; available frequencies :
Channel 01 : 2.412 GHz
Channel 02 : 2.417 GHz
Channel 03 : 2.422 GHz
Channel 04 : 2.427 GHz
Channel 05 : 2.432 GHz
Channel 06 : 2.437 GHz
Channel 07 : 2.442 GHz
Channel 08 : 2.447 GHz
Channel 09 : 2.452 GHz
Channel 10 : 2.457 GHz
Channel 11 : 2.462 GHz
Channel 12 : 2.467 GHz
Channel 13 : 2.472 GHz
Current Frequency=2.412 GHz (Channel 1)
Super! Danke an MadWifi und an den Blogschreiber von Blog Archi www.eee-blog.de
Nochmals: Ich übernehme keine Gewähr für eventuelle Hardwareschäden Viel Erfolg!
Siemens WLAN Bridge W-011
Wer ein solches Gerät sein Eigen nennt, wird die Anleitung dazu nicht allzu einfach finden. Mir jedenfalls ging es nun schon öfter so.
Ursprünglich wurden die Geräte von Alice vorkonfiguriert ausgeliefert. Ich hatte nie etwas mit Alice zu tun und ich hoffe das bleibt auch so nach all den Dingen die ich darüber schon lesen musste. Wer danach googlet, weiss was ich meine.
Auch über das Gerät wird allerhand geschimpft, ich allerdings bin zufrieden mit dem Gerät. Ich habe es als WLAN-Client in Betrieb um mein Kabelnetz im Wohnheim ans WLAN anzubinden. An sich also eine feine Sache. Ich hatte es auch schon verwendet um meine Xbox oder Dbox2 ans Netzwerk anzubinden, jedoch hat es dort Schwächen gezeigt.
Mit der jetzigen Verwendung im Dauerbetrieb bin ich allerdings zufrieden.
Hier kann die original Siemensanleitung für das Gerät bezogen werden.
Zur Ergänzung: Hier ist die Produktseite von Siemens Albis zu finden (Link aktualisiert am 09.11.2008 08.03.2009), dort findet man auch eine PDF mit genaueren Spezifikationen. Auf der linken Seite muss man sich in die WLAN Sektion begeben, la Voila!
Ich würde mich über eine neue Firmware freuen, Stand v1.00 ist bei mir noch installiert – irgendwie nur eine schlechte Betaware.
Supercomputer
Schaut euch mal diese Geräte an!
Großteils echt abgefahren… *gg*
ReadyNAS released Firmware 4.1.3
*juhuu* kann ich da nur sagen.
Vor über einem Jahr haben wir uns ein NAS der Firma Infrant angeschafft, leider ohne vorher groß Recherchen durchzuführen. Schliesslich kann man sich ja fragen: *Was kann man da schon falsch machen?*
Tjoaa, da haben wir nicht mit Infrant gerechnet, vom schäbigen Webinterface mal ganz abgesehen war die Leistung eher schwach als zufriedenstellend. Zum Glück wurde ja nach mehr oder minder kurzer Zeit die Firma Infrant von der Firma Netgear aufgekauft. Eine Firma von der man eigentlich bisher nie schlechte Produkte gekauft bzw. gesehen und bedient hat.
So hat sich also Netgear ans Werk gemacht, die zugehörige Homepage einem Remake unterzogen und sich schliesslich an eine neue, funktionable Firmware gemacht. Löblich, löblich dachte ich mir als kurz darauf die erste Firmware folgte. Nun gut, diese sollte wohl zuerst einmal die Kinderkrankheiten von Infrant beseitigen und mit einem neuen Webinterface (NETGEAR) aufwarten. Die Performance hatte sich leider nicht sonderlich verbessert.
Das hat auch die große Community festgestellt und dank der wohl mehr als reichlichen Resonanz hat sich Netgear erneut ins Zeug gelegt um endlich brauchbare Software auf den Markt zu bringen.
Kürzlich habe ich nun unser NAS gänzlich geleert, habe die neuste Beta-Firmware aufgespielt und ein Hardwarereset durchgeführt, welches eine Vollformatierung veranlasst hat die eben auch ein neues Filesystem mitbringen soll. Weitere Addons wie zB SSH Zugriff haben mir zusätzlich Freude gebracht, sowohl bei der Administration sowie auch beim generellen Handling der Maschine – das NAS wird endlich erwachsen.
Und nun, seit dem 11. September – ein Datum mit durchaus negativem Nachgeschmack – released Netgear ihre nächste Stable Firmware!!
Na da bin ich aber mal gespannt!
Letzte Kommentare