Posts mit dem Label hardware werden angezeigt. Alle Posts anzeigen
Posts mit dem Label hardware werden angezeigt. Alle Posts anzeigen

Montag, 18. Oktober 2010

uBoot für DockStar

Wie versprochen geht es weiter mit Artikeln zum DockStar

Um einen eigenen uBoot zu übersetzen bedarf es nicht viel...

  1. Crosscompiler/Toolchain für Arm
  2. uBoot-Quellen
  3. patches für uBoot für den Dockstar
  4. meine Anpassungen für Speicher und LEDs

Wer das alles nicht möchte, kann auch einfach das fertige Binary laden, muss dann aber mit den Standardoptionen leben oder die Optionen im Flash anpassen. Meine Version des u-Boot gibt es hier. Vorsicht: Es scheint nicht jeder Kernel damit zu booten. Bitte vorher testen!

Die Toolchain bekommt man nach der Anleitung hier und dann geht es bei ahsoftware weiter mit dem uBoot.

Am Ende gibt es dann noch die Anpassungen für LED's und Speicher von mir:

In der Datei board/Marvell/sheevaplug/sheevaplug.h kann man sich aussuchen, wie man die LED's beim Einschalten gesetzt haben will. Folgende Zeilen schalten einfach die orange LED ein, um den Bootvorgang zu signalisieren:

#define SHEEVAPLUG_OE_LOW        (~(0))           /* This is for DockStar:                    */
#define SHEEVAPLUG_OE_HIGH       (~( (1 << 15) )) /* output enable gpio47 (32+15) = orange,   */
                                                  /*               gpio46 (32+14) = green led */
#define SHEEVAPLUG_OE_VAL_LOW    (1 << 29)        /* USB_PWEN low                             */
#define SHEEVAPLUG_OE_VAL_HIGH    0               /* output low => led on - thus we switch on */
                                                  /* the yellow one above.                    */

Viel wichtiger ist jedoch das korrekte Konfigurieren des Speichers, damit das später startende Linux nicht versucht, auf den nicht vorhandenen Speicher zuzugreifen.

Die Option hierzu findet sich in der Definition des Konfigurationsabbilds der CPU in der Datei board/Marvell/sheevaplug/kwbimage.cfg. Dort gilt es die DATA-Definition an der Adresse 0xFFD01504 zu ändern:

DATA 0xFFD01504 0x07FFFFF1     # CS[0]n Size Register - 07=128MB for DockStar

Wer nun noch eine komfortable Eingabeaufforderung im Bootloader haben will, editiert noch schnell die Datei include/configs/sheevaplug.h und fügt die folgenden Zeilen ein:

#define CONFIG_SYS_HUSH_PARSER
#define CONFIG_AUTO_COMPLETE
#define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
#define CONFIG_CMDLINE_EDITING

Schliesslich wollte ich noch die Standard-Boot-Optionen anpassen:

 #define CONFIG_BOOTCOMMAND \
         "${x_bootcmd_usb}; "    \
         "setenv bootargs ${x_bootargs} ${x_bootargs_root}; echo cmdline: ${bootargs} ; "    \
         "run x_bootload_kernel m_usb_boot;" \
         "reset" /* If loading from USB failed we just reset, my experience was that the second time the device will be found */

[...]
 #define CONFIG_EXTRA_ENV_SETTINGS \
       "x_bootargs=console=ttyS0,115200 mtdparts="CONFIG_MTDPARTS \
       "x_bootargs_root=root=/dev/sda1 ro rootdelay=5\0" \
       "x_bootload_kernel=ext2load usb 0:1 0x800000 /boot/uImage\0" \
       "m_usb_boot=if ext2load usb 0:1 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000;else bootm 0x800000;fi;\0" \
        "x_bootcmd_usb=usb start\0"

Damit sucht der u-Boot auf dem usb-stick nach einem uImage und uInitrd und bootet, falls vorhanden, auch mit Initrd.

Flashen des uBoot

Die heikelste Operation ist das Flashen des uBoot. Zum Testen empfiehlt es sich, mit dem vorhandenen Bootloader den neuen uBoot per Netz oder usb-Stick in den Speicher zu laden und direkt anzuspringen (Dazu das bin-file benutzen). Wer seinen eigenen uBoot flashen will sollte unbedingt daran denken, nicht versehentlich das binary sondern immer das Bootfile (kwb) zu flashen.

Ich erledige das bequem mit der seriellen Konsole und einem tftp-Server:

setenv ipaddr 10.1.1.17 ; setenv serverip 10.1.1.1 ; tftp 0x6400000 u-boot.kwb
nand erase 0x0 0x40000
nand write 0x6400000 0x0 0x40000
reset
Und wenn man Glück hatte, braucht man nicht so wie ich einen JTAG-Adapter...

Mein Dockstar lebt wieder...

So. Es ist wieder einmal passiert. Ich habe mir Hardware zum Spielen gekauft.

Diesmal: Ein FreeAgent DockStar Network Adapter von Seagate.

Das Schätzchen hat 128MB Ram und 256MB Flash on Board, eine nette ARM CPU, Gigabit-Netzwerk und 4 USB-Ports. Details finden sich zu Hauf im Netz.

Was mich besonders interessiert hat, war die in der CPU vorhandene Crypto-Unit, die sha1, md5 und aes in Hardware berechnen kann.

Linuxkernel

Leider ist es mit der Unterstützung dieser Einheit im offiziellen Kernel noch nicht so wahnsinnig weit - bisher wird das ganze nur rudimentär angesprochen (z.B. kein DMA), so dass es nicht wirklich Spaß macht, das ganze zu nutzen. (1-2MB/s Gewinn)

Etwas mehr verspricht hier ein Kernel des Herstellers - und voilá, GPL-sei-dank gibt es da auch was passendes. Oder naja, etwas das man für passend halten kann.

Vorweg: Ja, ich habe den Kernel letztlich übersetzt bekommen, man darf nur nicht so wahnsinnig sein, und an der config großartig Dinge ändern wollen - weil dann knallt es. Und zwar richtig mit Compiler-Fehlern und Syntax-Errors in den Kernelquellen.

Letztlich habe ich jedenfalls 15MB/sec von einer verschlüsselten USB-Platte lesen können statt 6-7 ohne Hardwareunterstützung.

Details zum Kernel folgen, sobald ich einen stabilen build habe und das dokumentieren kann. Ausserdem will ich die LEDs aus dem Kernel heraus ansprechen können, die GPIO-Konfiguration habe ich im Prinzip bereits.

uBoot - der Bootloader

Damit ich dieses System bequemer booten kann, wollte ich dann einen neuen uBoot bauen.

Die Cross-compiler-chain war ja schon von kernel vorhanden - sollte also alles kein Problem sein. Dachte ich.

Die Konfiguration des DockStar unterscheidet sich leider etwas von der des Sheeva-Plugs. So ist nur die Hälfte des Rams vorhanden, ausserdem sind die beiden LEDs an andere GPIO-Pins angeschlossen.

Kaputtgeflasht

Was mir letztlich das Genick brach war aber ein dummer Fehler: Ich habe das uBoot-Binary direkt in den Flash des DockStar gebrannt - statt des kwb-Images, das die Hardwarekonfiguration enthält.

Letztlich habe ich nun 4 verschiedene Jtag-Adapter hier gehabt, davon zwei selbstgebaute. Der letzte, ein wiggler, funktionierte schließlich - wenn auch nur mit 50kHz statt 500. (Kabellänge)

Folgende Fallen begeneten mir dabei:

  • 74HC244 falschrum im Sockel. Gute Heizwirkung, der Chip hats überlebt, mein Zeigefinger auch...
  • Kabel zu lang und zu wenig abgeschirmt
  • Ein funktionierender DockStar hat das JTAG deaktiviert und ist zum Testen ungeeignet!

Vor allem der letzte Punkt mit dem funktionierenden DockStar hat mich etliche Stunden gekostet. Aber wer rechnet schon damit -.-

Ausblick

Die folgenden Posts werden ausführlich das Wiederbeleben des DockStars, die korrekte Konfiguration des Bootloaders für diese Plattform und die Konfiguration des Kernels enthalten.

Der Bootloader kann hier jedenfalls schon die LED's ansprechen, dem Kernel werde ich das wohl auch noch beibringen. TODO's sind aber noch die Konfiguration des Speichers im uBoot.

Freitag, 2. April 2010

Scrollen mit dem Touchpad...

Kleiner Tipp am Rande: Wer sich wie ich darüber ärgert, dass nach einem Update des X-Servers bzw. des synaptic Touchpad-Treibers das scrollen per Touchpad nur noch an der rechten Seite des touchpads funktioniert und nicht mehr, wenn man zwei Finger auf das Touchpad legt, kann das alte Verhalten schnell durch Aufruf des 'synclient' wiederherstellen.

Die Konfiguration erfolgt bei aktuellen xorg-Versionen ja nicht mehr in der xorg.conf...

Bei der Gelegenheit habe ich auch gleich das vertikale Scrollen aktiviert und Klicks und Doppelklicks eingeschaltet:

   #Scrollen in alle Richtungen gleichzeitig:
   synclient VertTwoFingerScroll=1
   synclient HorizTwoFingerScroll=1
   #Klicken mit linker Taste:
   synclient TapButton1=1
   #Meine default-Werte:
   synclient MaxTapTime=180
   synclient MaxDoubleTapTime=180
Das obige snippet habe ich jetzt einfach in meine .xinitrc eingebaut, fertig.

1. Nachtrag: Die Freude hält sich in Grenzen - nach einem Suspend to RAM muss man das kleine Script nochmal ausführen, damit das Touchpad konfiguriert ist. Offenbar sichert der synaptics-Treiber den Status nicht korrekt bzw. stellt ihn nach dem Aufwachen nicht wieder korrekt her. *grr*

Dienstag, 9. März 2010

IO-Durchsatz und kernel neuer 2.6.28

Kurze Notiz: Wer auch wie ich das Problem hatte, dass manche Anwendungen wie liferea das gesamte System einfrieren lassen, wenn sie ein bischen IO machen (eine sqlite-db nutzen z.B.) kann ich ein downgrade auf Kernel 2.6.28, z.B. 2.6.28-gentoo-r5, empfehlen. Seitdem ich von 2.6.33 umgestiegen bin, kann ich wieder Multitasking machen und liferea benötigt keine 20-30 Sekunden pro Artikel(!) zum Darstellen, wenn mal ein Bild enthalten ist. Auch insgesamt ist das System wesentlich responsibler geworden und damit wieder benutzbar. Das Problem als solches stellte sich durch 80-90% iowait dar - so dass ich trotz Dualcores nicht mehr arbeiten konnte, weil der IO Scheduler das System schlicht und einfach komplett lahmgelegt hat. Ich hoffe das wird mal wieder besser *seufz*

Mittwoch, 20. Mai 2009

Nur ein kleiner Umbau...

Warum muss Murphy eigentlich so grausam sein?

Ich habe ein externes AIT1 Laufwerk ausgegraben sowie ein AIT2-Laufwerk. Nun dachte ich mir, die Laufwerke sind ja beide gehäusetechnisch kompatibel, sogar die Dipswitches sind an derselben Stelle, also baue ich das AIT2-Laufwerk in das externe Gehäuse ein und hänge es an meinen Fileserver. Weil: Backup ist wichtig!¹

Nachdem der Umbau beendet war wollte ich die Frontblende des Gehäuses wieder einsetzen. Tja, passt nicht, denn bei dem AIT2 Laufwerk handelte es sich wohl um eines, dass in einer Lib zum Einsatz gekommen war, jedenfalls hatte es erstens keine Klappe vor dem Slot und war zweitens etwa 4 mm zu breit. Egal, zum Testen reichts erstmal - jedenfalls wenn man das richtige SCSI-Kabel findet...

Okay, nachdem das Kabel gefunden war (ein internes zwar und bestimmt zu lang, aber egal, denn zum Testen reichts erstmal...) konnte das Laufwerk in Betrieb genommen werden. Ergebnis: läuft

Nächster Schritt: Einbauen

Also heute frisch ans Werk, das Laufwerk gehört in den Server, dann ist es nicht mehr so laut, weil kein eigener Lüfter, und ausserdem ist dann weniger Geraffel und Kabelsalat im Schrank - und das Gehäuse konnte ich ja eh nicht zumachen.

Bei der Gelegenheit wollte ich auch mal schauen welcher RAM im Server verbaut ist - weil das ist definitiv zu wenig im Moment.

Also flux alle Kabel getrennt, Server aus dem Rack gezogen, *uffissderschwer*, aufgemacht, Ram ausgebaut, Riegel verglichen. Natürlich hat man keinen Kompatiblen Riegel hier und es steht auch nicht drauf was für welcher das ist, also nachher mal Google bemühen - Ramriegel neben das Notebook.

Kommen wir zum Laufwerk. Das Gehäuse wird flink zerlegt, Laufwerk raus und zum Server getragen. Nun, das Laufwerk hat zwar die Höhe eines 5 1/4 Laufwerkes, aber nicht die Breite. Gut, Einbauschienen hängen hier auch noch an einer alten SCSI Platte im Schrank, das passt schon - leider erst beim dritten Versuch.

So langsam werde ich leicht genervt, denn jetzt geht das Suchen nach SCSI Kabeln und Adaptern los - intern ist nur noch ein 50 pol. Flachbandstecker am SCSI Controller frei, das Laufwerk hätt aber gerne ein 68 pol. Anschluss. Nach einigem Suchen und dem Auffinden von 10 Stück IDE-Kabeln findet sich schliesslich alles ein.

Also Laufwerk ist eingebaut, Deckel drauf, Klappe zu - Klappe zu?! *arrgh*

Das Laufwerk ist 0,5 cm zu lang, bzw, schaut vorne aus dem Gehäuse raus.. *heul*

Egal zum testen.... also die linke Frontklappe abgebaut, Server ins Rack, und los.

Jetzt noch die Kabel anschliessen, vor allem die USB *AUTSCH*!

Meister, warum is da Saft drauf?

Hmm. Warum bekomme ich am USB-Kabel der externen Festplatte nen Stromschlag?

Mal verifizieren. *AUTSCH* - okay, da ist Strom drauf... Messgerät!

Oh, interessant: 219 Volt, 50 Herz. 20mA gegen Erde, keine Phasenverschiebung. Nur woher kommt das? Die USV ist aus, primär ist ein Schalter in der Steckdosenleiste, der ist aus, dahinter ein Verteiler, ebenfalls mit Schalter, dann die Festplatte. Alles aus. Eigentlich.

Kaltgerätekabel von der USV abgezogen: keine Spannung. Aha, daher weht der Wind?

Also mal das Voltmeter in richtung USV verschoben. An beiden äußeren Pins des Kaltgeräteausgangs liegen 219 Volt gegen Erde. Yay!

Ich hab also mal wieder den Jackpot geknackt: Der Schalter in der Steckdose schaltet also ganz offensichtlich nur einpolig ab - und natürlich, bei einer Chance von 50:50, schaltet der NICHT die Phase ab. Warum auch. Und dann sind da wohl noch irgendwelche Y-Kondensatoren in dem Schaltznetzteil der Festplatte, die sie, mangels Erde weil Eurostecker, wohl gegen die USB-Masse gesetzt haben. *seufz*

Gut, also Stecker um 90 Grad drehen und weitermachen, Zweipoliger Trenner kommt dann morgen.

Also Kabel ran und los.

pieeeeeep

Hmm. Warum piept der jetzt?

Moment, da war doch noch was - aaah, der RAM liegt noch auf dem Schreibtisch.

Ich brauch jetzt erstmal nen Kaffee!

Nach dem Kaffee werde ich wohl das Laufwerk wieder ausbauen, dafür den Ram einbauen, das AIT1 Gehäuse mit einer kleinen Trennscheibe bearbeiten und das Laufwerk da wieder einbauen. *nerv*


¹ Ein Raid ist nett, aber kein Backup, ein Fehler beim mdadm und alles ist weg - wenn man nicht wie ich Glück hat und nur 20 GB verliert, weil man den Rebuild abgebrochen hat. Details vielleicht in einem späteren Post ;)

Montag, 23. Februar 2009

Zischen und Zirpen aus den Lautsprechern.

Ich hatte die letzen Wochen immer wieder ein Problem: Sobald gnome gestartet wurde, war ein ununterbrochenes Zirpen und Zischen aus den Lautsprechern zu hören.

Sobald man den esd gekillt hatte, wurde es still. Wollte man wieder Musik wiedergeben, fing das Gezische wieder an. Soweit so nervig, vor allem, wenn man Podcasts einer Vorlesung bearbeiten will.

Was zwischendurch ein paar Mal geholfen hatte, war alsaconfig aufzurufen. Ich habe die Probleme letztlich auf ein Kernelupdate geschoben, und mir nicht soviel weitere Gedanken gemacht.

Gestern habe ich dann wieder mal ein Kernelupdate gemacht, mit dem Ergebnis, dass die komischen Geräusche der Soundkarte auch mit alsaconfig nicht mehr wegzubekommen waren.

Schliesslich fand ich per Zufall die Lösung des Rätsels, als ich nach und nach versuchte, die Kernelmodule zu entladen, die ein 'snd' im Namen trugen. Bei zweien davon weigerte sich der kernel beharrlich. Eines davon: snd_pcsp.

Nachdem ich im Gnome-Lautstärkeregler dann eine Einstellung für eine Basisfrequenz gefunden habe und bei einer Änderung das Gezirpe die Tonhöhe ebenfalls änderte, wusste ich, was mir hier vorgespielt wird...

Alsa hat seit einiger Zeit eine Emulation zur Soundausgabe über die normalen, alten PC-Speaker. Dummerweise klappt das auf meiner Hardware nicht so besonders, so dass ständig Nebengeräusche entstehen. Aaarghhh

Hiermit sei derüber gebloggt, eventuell finden andere Opfer dann einen Eintrag per Google, der ihnen hilft ;)

Technische Daten für die googlesuche:

  00:1b.0 0403: 8086:284b (rev 03)
  00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
  snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_hda_intel,snd_pcm,snd_timer