Designed in China - Lemote Yeeloong & Loongson-2F RISC - die "OpenSource" Maschine

Grüß euch.

Ich habe lange überlegt, ob ich das hier oder irgendwo in einem Hardwaresubforum posten soll, aber hier passts wohl letzten Endes doch noch am besten hin.

Ich war ja unlängst in meinem Urlaub mit einem Arbeitskollegen aus Hong Kong in China, um mir dieses Land genau anzusehen. Darum geht's aber hier gar nicht. Sondern es geht um eine Maschine und ihre Software, und zwar ein Lemote Yeeloong Netbook mit Loongson-2f (龙芯, lóngxīn) CPU.

Jetzt verhält es sich so, daß ich in einem anderen Forum - nämlich auf [VoodooAlert] bereits seit längerem einen [Thread] dazu führe, und ich eine zu faule SAU bin, alles nochmal zu tippen. Außerdem ginge dadurch auch der Blog-Charakter des ganzen flöten. Also werde ich den Text aller meiner Posts (so halbwegs halt) einfach rüberkopieren, mit kleinen Kennzeichnungen wo eigentlich ein neuer Post bzw. ein Update begonnen hat. Man möge mir das verzeihen.

COPY & PASTE startet hier: (paar Sachen sind redundant, sorry)

Vielleicht haben einige von euch schon von einer gewissen "Godson" Architektur oder einer "Dragon" CPU gehört, die in China entwickelt worden ist, und mit der man sogar ganze Cluster gebaut hat. Der weniger bekannte, eigentliche Name der darauf basierenden Prozessoren - Loongson (sprich: lóngxīn) ist dabei aber in den europäischen Nachrichten wenig aufgetreten, genauso wie der Netbook- und Medien-PC Hersteller Lemote, der die Teile in China verbauen läßt.

Kürzlich hatte ich ja nicht nur das "Glück" nach China zu reisen, sondern auch noch das tatsächliche Glück, an der technischen Universität Beijing mit einigen Entwicklern der Loongson Mikroarchitektur zu sprechen, und eine Demomaschine antesten zu dürfen. Kurzerhand habe ich mir dann ein auf der Loongson-2F CPU basierendes Netbook gekauft, auf dem "Loonux" installiert war, ein stark abgewandeltes und ziemlich extrem *******iges Debian 4, auch durch die Sprache (Mandarin!) für mich völlig unbenutzbar.

Neulich habe ich aufgrund eines Fehlgriffes bei der Recoveryfunktionalität des Books (Mandarin kann man eben nur schwer lesen, weiß ich doch ned was ich da wieder fürn Knopf gedrückt habe! ) die ganze Maschine bricked. Tot. Bis auf die PMON2000 Firmwareshell war da nichts mehr am Leben.

Selbige Shell übrigens bietet UEFI-ähnliche Basisfunktionalitäten wie Netzwerktreiber, TFTP Client, DNS Client, EXT2/3 Filesystemtreiber und die Möglichkeit Binärcode direkt von der Firmwareshell aus zu starten.

Allerdings keinen gewöhnlichen Binärcode! Der Loongson-2F ist eine abgewandelte Form der quelloffenen MIPS-III 64-Bit Little Endian Architektur. Also ein reinrassiger, in China entwickelter und gebauter RISC Chip!

Hier Mal ein Foto der von Quanta Computer assemblierten Maschine:


Spezifikationen:

• Loongson 2F 1GHz (MIPS-III 64-Bit, Little Endian Byteorder)
• 1GB DDR-II/667
• 160GB 5400rpm Toshiba HDD
• 100MBit LAN (RTL)
• 54MBit 802.11g WLAN (RTL)
• USB 2.0, Kartenleser, Webcam, Sound..

Nun, das auffälligste bei einer gebrickten Yeeloong Maschine mit Loongson Prozessor ist, daß man nicht einfach so ein Betriebssystem installieren kann. Die Kiste besitzt nämlich weder ein BIOS, noch eine UEFI Firmware. Und noch dazu der freakige RISC. Gedacht ist die Sache so, daß die quelloffene PMON Firmware einfach direkt den Linux Kernel von der HDD hochfährt, man kann den Kernel und seine InitRD also direkt auf der Shell laden und starten (Befehlssequenz load / initrd / g). Alternativ kann man auch auf eine boot.cfg zurückgreifen, die sich von PMON starten läßt. Auch Grub Bootloader Code sollte sich so chainloaden lassen (Grub, so heißt es, kann den Kernel viel flotter starten als PMON). So sieht der Splashscreen aus, wenn man das ******teil Mal einschaltet:


Nun, es gibt ja Linux Distributionen, die MIPS und sogar MIPSEL (Little Endian) Builds anbieten. Leider laufen selbige nicht einfach so auf dem Loongson-2F, weil der eben nicht "ganz" MIPS ist. Code, der im Kernelspace laufen soll muß also von Hand gepatcht sein, um auf der CPU lauffähig zu sein. Im Userspace reichen normalerweise generische MIPSEL Binaries aus..

Zum Glück muß man den Kernel nicht wirklich selbst patchen. Den gibt es fertig gepatcht. Ich hab mich gleich Mal an den ultramodernen Linux 3.0.0 Kernel und Debian Wheezy/sid herangewagt, um zu sehen ob der tatsächlich auf dieser Drecks-CPU läuft. [Hier die wichtigsten Infos und Files]. Man legt also boot.cfg, Kernel und Init Ramdisk auf einen USB Stick, und bootet dann händisch von der PMON Shell aus. Dann kickt der Netboot rein, und der Installer fährt an! Erhebendes Gefühl. Hier sehen wir aber schon das fertig installierte System, Grub ist chainloaded über boot.cfg, "/boot/" ist EXT2 wegen der PMON-Kompatibilität, "/" ist gleich EXT4 für mehr Performance:


Hat man das dreckige Linux Mal installiert, kommt die Ernüchterung - zwar ist der Kernel gepatcht und läuft (!), jedoch weder der X11 Server, noch der Silicon Motion Grafiktreiber, Wheezy bringt eben doch noch nicht alles für die Yeeloong Plattform mit. Diese Komponenten sind unerläßlich, um eine grafische Oberfläche mit dem modernen Windowmanager Gnome 2/3 oben drauf zu erhalten. Gepatchte Pakete dafür gibt es aber im chinesischen [Anheng apt Software-Repository].

Wir tragen das Anheng Repo aus China also als root in unsere apt Konfiguration ein:

Code:

echo deb [url]http://www.anheng.com.cn/loongson2f/wheezy/[/url] ./ >> /etc/apt/sources.list

Danach konfigurieren wir den Mist noch, indem wir ein File /etc/apt/preferences.d/anheng anlegen, und folgendes reinklopfen:

Code:

Package: *
Pin: release o=Debian
Pin-Priority: 1
 
Package: *
Pin: origin [url]www.anheng.com.cn[/url]
Pin-Priority: 2000

Danach flott apt-get update, um apt zu zeigen, was es jetzt an neuem Spielzeug hat, und aptitude upgrade oder so ähnlich, um alle Softwarepakete durch Loongson-2F optimierte zu ersetzen wo möglich. Dazu zählen eben auch der X11 Server und der Silicon Motion Grafiktreibermüll.

Rebootet man jetzt, oder versucht das X11 hochzunehmen, krachts gleich nochmal. Dreck. Das Autodetect klappt überhaupt nicht (ich hasse Autodetect beim X11 sowieso), also schreiben wir uns eine eigene xorg.conf, dabei können wir den Speed des Treibers auch gleich ein wenig tunen (nicht daß es hilft, er bleibt sowieso ******lahm). Den Chipset habe ich zur Sicherheit fix eingetragen (ich hasse ja Autodetect!!). Ein kurzes lspci zeigt uns alle PCI Geräte, darunter einen Silicon Motion, Inc. SM712 LynxEM+ (rev b0) Grafikchip.

/etc/X11/xorg.conf:

Code:

Section "Device"
	Identifier	"Card0"
	Driver		"siliconmotion"
	Chipset		"lynxem+"
	Option		"HWCursor"	"true"
	Option		"Videokey"	"45000" # (counter blue-shift!)
	Option		"UseBIOS"	"false"
	Option		"PanelSize"	"1024x600"
	Option		"AccelMethod"	"XAA"
	Option		"PciBurst"	"true"
	Option		"PciRetry"	"true"
	Option		"FifoAggressive"
EndSection

Section "Screen"
	Identifier	"Screen0"
	Device		"Card0"
	Monitor		"Monitor0"
	DefaultDepth	16
	SubSection "Display"
		Virtual	1024	600
		Depth	16
	EndSubSection
EndSection

Nochn Versuch den X11+Gnome hochzukriegen mit init 1 / init 2 oder wie oder was... NA ENDLICH!


Das Schwein! Leider ist X11 nicht völlig stabil, aber ok... Immerhin ein bisserl Websurfen und ned nur Konsole. Obwohl ich das erhebendste Gefühl ja hier hatte, es geht auch nichts über einen treffenden Hostnamen :


ANMERKUNG: Der untere Teil mit x264 ist auf einen Video-Benchmark bezogen, den ich in einem anderen Forum released habe, und der dort recht guten Anklang gefunden hat. Das sei nur zur Erklärung angemerkt.

Aber die Feuerprobe für das Freaksystem sollte erst kommen... aptitude install build-essentials installiert uns Mal einen GCC, also den GNU C Compiler und die wichtigsten Header usw. Das ist Version 4.6.1, also brandneu! Der Hammer: GCC 4.6.1 kennt -march=loongson2f, kann also C/C++ Code optimiert für die Loongson-2F CPU bauen! Yeah.

Was kommen muß war klar: Das libavcodec Subsystem um H.264/AVC Video einlesen zu können, und x264!! Das war sogar beides überraschend einfach. Lediglich eines muß man in beiden Fällen beachten, und das ist der --disable-asm Switch für die configure Scripte. Weder das libavcodec/lavf System, noch x264 verfügen über MIPS-related Assemblercodepfade. Selbst wenn man sich einen Assembler wie etwa yasm installiert, hilft das ganze nicht. Der beiliegende Assemblercode ist eben nur für x86, SPARC, PowerPC und ARM. Aber nichts für MIPS, yasm schlägt fehl, weil die entsprechenden CPU Befehle einfach nicht in meinem Loongson-2F existieren. Also müssen wir alles dem GCC überlassen, und vom Fallback C++ Code bauen, sowohl im Falle von lavf als auch x264. Bis auf den asm Fallstrick ist es aber nahezu einfach nur configure / make / make install!

Damit verletze ich gleich zwei Regeln für den x264benchmark: Es handelt sich um einen Custom Build, UND ich baue explizit ohne SSE Code, weil die CPU sowas einfach nicht hat..

Flags für GCC 4.6.1 (CFLAGS/CXXFLAGS):
-march=loongson2f -O3

Und die ******e rennt, 0.04fps! Ich glaub immer noch meinen Augen nicht daß der Dreck wirklich läuft! Kaum zu fassen, aber wahr. Und witzig ist, was x264 zu meinem Prozessor zu sagen hat:

Code:

Using CPU capabilities: None!

Hier übrigens noch der Output von cat /proc/cpuinfo, auch witzig zu lesen, wenn man die geilen Versionsnummern beachtet:

Code:

system type			: lemote-yeeloong-2f-8.9inches
processor			: 0
cpu model			: ICT Loongson-2 V0.3	FPU V0.1
BogoMIPS			: 528.38
wait instruction		: yes
microsecond timers		: yes
tlb_entries			: 64
extra interrupt vector	: no
hardware watchpoint		: yes, count: 0, address/irw mask: []
ASEs implemented		:
shadow register sets	: 1
kscratch registers		: 0
core			: 0
VCED exceptions		: not available

So, damit steuere ich nach dem Transmeta - der ja schon recht freakig war - ein noch freakigeres ******haus zum x264 Benchmark bei! Eine waschechte Chinesen-CPU, und der erste RISC im Test, und wahrscheinlich bleibts auch der exotischste! Wird wohl eine laaaange Zeit laufen, bis er's hat.. sofern er ned abschmiert dabei.

Neuer Post:

Jetzt leider ein Crash in x264, irgendwas von wegen "Illegal Instruction". Vielleicht doch lieber mit -O2 neu bauen für weniger aggressive Optimierung..

Neuer Post, gekürzt:

Ich hab jetzt etwas rumgetestet. Der -O2 Build war schon sehr lahm, also nochmal mit -O3 gebaut, aber fast-math deaktiviert (potentiell gefährlich denk ich). Es gibt auch noch 2 arge CPU Bugs, die sich mit einem gepatchten GCC umschiffen lassen (meiner is unpatched), aber im Userspace sollten die Probleme gar nicht bzw. nur extrem selten auftreten, heißt es. Also neu gebaut den x264, und zwar so:

CFLAGS="-march=loongson2f -mtune=loongson2f -O3 -fno-fast-math"

Jetzt rennt er schon seit gestern Nachmittag ohne einen Absturz. Leider aber scheint -ffast-math ein ziemlicher Booster gewesen zu sein, najo Mal sehen. Das Book steht grade auf der Arbeit, aber is ja ned weit weg (hab heute Urlaub). Vielleicht schau ich Mal hin, wie weit und wie schnell er schon ist. Kann mich zwar remote per SSH einloggen, aber da seh ich nur, DAß er noch läuft, der Bench, aber ned wie schnell und wie weit er schon is.

Neuer Post:

Habe den Fehler im crashenden Iceweasel/Firefox beseitigen können, und habe damit immerhin einen halbwegs funktionierenden Webbrowser. Die Lösung lag in einer Komponente des gnome-vfs, das noch immer von Iceweasel 6 verwendet wurde, und in dessen Verwendung irgendein Bug lag. Wenn man im File /etc/gnome-vfs-2.0/modules/default-modules.conf einfach Mal die Line file: file auskommentiert, also in #file: file ändert, dann geht der Downloadmanager des Iceweasel und kann kann Files speichern.

Leider gibt es noch ein Problem, und zwar den rtl8187 WLAN Treiber (Realtek 8187 Chip). Zwar habe ich das WLAN zum Laufen bewegen können, allerdings unterstützt der rtl8187 Treiber den Ad-Hoc Modus nicht (Recherchen im Netz haben das bestätigt, auch für andere Linux Distros), den ich aber brauchen würde. Ein Treiber, der das können soll - nämlich rt8187 - will auf meinem System mit kryptischen Fehlern nicht bauen. Dreck.

Zitat von LemoteYeeLoong

root@redsun:~$ iwconfig wlan0 mode Ad-Hoc
Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Operation not supported.

Also geht nur der Infrastrukturmodus, was schade ist, weil ich daheim eben ein Ad-Hoc Netz hätte. Najo..

Dafür läuft Mal der Browser, und auch X-Chat 2.8.8 und licq 1.5.1 habe ich zum Laufen bewegen können. Mit aterm habe ich einen funktionierenden X11 Terminalemulator gefunden, jetzt fehlt eigentlich echt nur mehr das Ad-Hoc fürs WLAN..

Edit: Rythmbox kann keine Files lesen, die von Iceweasel übergeben werden. Ersetzt durch mplayer + mplayer-gnome. Läuft, jetzt kann ich Musik von meinem Streamingserver holen. Und ich muß sagen.. Die Audioqualität von dem Ding ist das allerschlimmste was ich seit der OPTi ISA Soundkarte die ich Mal hatte (11kHz!!) gehört hab.. unfaßbar, wie schlecht!

Audio provided by: AMD Geode CS5535 Companion Device. - Edit: Fixed: Man muß das PCM Volume runterdrehen, sonst wird der Chip übersteuert..

Edit 2: Network-Manager saugt Ärsche, WLAN geht damit prinzipiell ned. Also "wicd" installiert und kapital failed, da die wicd-gtk GUI die ich habe.. irgendwie NICHTS kann und nicht so aussieht, wie sie sollte. Dreck. Also? wicd-curses installiert, den Konsolen-Konfigurator. Hier findet man auch endlich die entsprechenden Settings für die Verschlüsselungen. Dank wicd und wicd-curses hängt das Drecksteil jetzt erstmals in einem Infrastruktur-WLAN! Yaay! Alles supereasy im Linux und so.... Mal sehen ob mit wicd ned doch Ad-Hoc dann auch funzt.

Für alle die jetzt sagen: Machs mit iwconfig und wpa_supplicant, denen sei gesagt: NEIN!! Denn dafür bin ich zu blöd, hat auch ned wirklich geklappt..

Edit 3: So sehr xmms-1 geruled hat, so sehr suckt xmms-2. Also Audacious installiert, der lädt sogar meine WinAmp 2.91 Skin. Und er spielt unfaßbarerweise sogar C64 SID, es ist doch in der Tat die reSID Engine dabei! So herrlich. Ich dachte das würde schwerer werden. Und wma/mp3/flac/ogg usw. gehen sowieso. Nice. Langsam wirds benutzbar. FileZilla rennt auch, und er hat kein Problem mit meinem SSL FTP..

Edit 4: Habe jetzt alle Dependencies für den nächsten Build zusammengetragen - die Maschine kompiliert grade an BOINC. Danach noch versuchen den SETI@Home Client zu bauen, und innerhalb des BOINC Frameworks zum Laufen zu bewegen. Das wär dann das erste mal, daß ich selber SETI baue, sonst saug ich nur die fertigen optimierten Binaries von irgendwem.

Edit zu Edit 4 (wtf?): Der Dreck.. Error. Die GUI ist hart, verwendet eine veraltete libnotify Funktion (das ist eine Library, die Tray Notifications handled). Jetzt mußte ich mich RICHTIG mit Kommunismus beflecken, und den Code selbst patchen:

Code:

diff -urN boinc-6.12.26.old/clientgui/gtk/taskbarex.cpp boinc-6.12.26/clientgui/gtk/taskbarex.cpp
2	--- boinc-6.12.26.old/clientgui/gtk/taskbarex.cpp       2011-05-22 09:40:36.314052737 +0200
3	+++ boinc-6.12.26/clientgui/gtk/taskbarex.cpp   2011-05-22 11:20:06.838410909 +0200
4	@@ -226,12 +226,11 @@
5	 
6	     if (!g_pNotification)
7	     {
8	-        g_pNotification = 
9	-            notify_notification_new_with_status_icon(
10	-                title.mb_str(),
11	-                message.mb_str(),
12	-                desired_icon,
13	-                g_pStatusIcon
14	+        g_pNotification =
15	+                       notify_notification_new(
16	+                               title.mb_str(),
17	+                               message.mb_str(),
18	+                               gtk_status_icon_get_icon_name(g_pStatusIcon)
19	         );
20	 
21	         g_signal_connect(

Ich hab den Patch halt nicht mit diff, sondern per Hand reingehackt. Mal sehen, den Teil hat er scheints erfolgreich gebaut jetzt. Ich warte auf den nächsten Build Error....

Neuer Post:

Edit 5: Die Quest geht weiter! BOINC hat gebaut, samt GUI. So. SETI! Konfiguriert/linked/baut aber nur, wenn man die BOINCDIR Variable auf das Rootverzeichnis des BOINC Source Trees setzt. Ich kotz gleich (nicht wegen BOINCDIR, nur so prinzipiell wegen dem ganzen Linuxdreck!).

Im SetiAtHome Sourcetree stehend:

Code:

export BOINCDIR="/home/thrawn/src/boinc-src-trunk/boinc"
./_autosetup
./configure --disable-graphics
make

Warten und beten.. und nie die CFLAGS vergessen, sonst krachts!

Habe übrigens mittlerweile rausgefunden, warum der meiste mipsel Code sterben geht am Loongson-2f. 5% Illegal Instruction, 5% segfault, dagegen gibts kein Kraut. Aber 90% is Bus Error. Grund? Speicher-Misalignment!

Jeder Pointer muß bei der CPU auf 64-Bit / 8-Byte ALIGNED WORDS in den Speicher zeigen. Sonst Crash. Ah, wie fein, Alignment gibts ned nur bei 4k Disks und SSDs, jetzt muß man schon Code und Daten im RAM alignen... da kotzen wir gleich nochmal!

Edit: Ajo, dagegen gibts natürlich AUCH kein Kraut...

Neuer Post, gekürzt:

Einen Haufen Libraries und Linkereien usw. später läuft BOINC und auch mein Loongson-2f optimierter SETI Cruncher. Ich kanns nur nicht wirklich testen, weil ich Mal wieder keine Workunits kriege, BAH.... Ich will den Dreck rennen sehn, nach all der Mühe!

[Auf der BOINC/SETI Webseite steht er schon] (Link kann 2-3 Tage die Woche wegen SETI Wartungen down sein, aber er kommt wieder.)

Und so sieht der momentan funktionierende Desktop aus (ich wollte ihm natürlich den passenden roten Hauch geben, daher das Logo ausm neuen "Red Dawn"):


Anmerkung zum Schluß: Der x264 Benchmark ist durchgelaufen, und die CPU hat sich zwischen einem VIA C7-M mit 400MHz und einem Pentium III 450MHz eingereiht, trotz des mit 1GHz hohen Taktes. Fehlen halt SSEx.... Wen die Ergebnisliste in Summe interessiert, der möge [hierher surfen], die Ergebnisse haben jedoch nichts mit sonstig verfügbaren x264 Benchmarks zu tun!

Die richtigen Schlußworte hat übrigens eh schon Microsoft für mich gefunden, dem ist nichts hinzuzufügen:


Vielen Dank für's mitleiden! Wer echt bis hierher gelesen hat, ist eh selber schuld!

Zitat von GrandAdmiralThrawn

wenn man das ******teil Mal einschaltet
das dreckige Linux
Das Schwein!
Und die ******e rennt
daß der Dreck wirklich läuft!
ein noch freakigeres ******haus
(wtf?): Der Dreck...
Ich will den Dreck rennen sehn

also wenn man das so liest, scheinst du ja die helle freude mit dem ding zu haben.

Also, der Hersteller Lemote verkauft direkt über TaoBao, das ist so eine Art Mischung aus eBay und Amazon in China. Wir - bzw. mein Kollege, der Mandarin spricht - haben den Hersteller angerufen, obs nicht billiger gehen würde (250€ oder so wars), und dann habens den Preis auf 150€ runtergesetzt, in China sollte man ja immer handeln.. Das is ca. das Geld um das man in China aber auch einen Atom mit geklautem WinXP kriegen kann... deswegen verkaufen sich die Teile auch ned.

Das vorinstallierte Loonux suckt GROB, und es is ned wirklich "so" billig für chinesische Verhältnisse. Die Verarbeitungsqualität is halt überraschend gut, aber najo...

Fakt ist, die Mühe zahlt sich NICHT aus. Ich mach das nur, weil mich der Loongson-2f und die unfaßbare *******igkeit des Systems faszinieren. Cobase hat's in seiner Aussage schon genau erfasst.

Nur, nachdem ich schon die Demomaschine gesehen habe an der Uni in Beijing, und mit den Entwicklern selbst gesprochen habe... und auch vorm China-Trip schon von Loongson gehört hab... mußte ich den Müll einfach haben!

Wenn der erst Mal eine SETI WU kriegt so gegen Freitag, dann gehts ab! Neben Lemote selbst schein ich im ganzen Netz der einzige Cruncher mit so einer CPU zu sein.

Hey, so isses auch ned! Ich hab mich bei jedem einzelnen Stück Software gefreut, daß ich zum Laufen hab bewegen können auf dem buggy RISC. (Dazwischen waren halt Zittern und 10 Mal so viel Ärger wie sonst was). SETI war nur eine besondere Herausforderung, weil ich setz zwar überall optimierte Builds von SETI und AstroPulse ein (Linux und Windows), aber ich hab's noch nie wirklich selbst bauen müssen, vor allem BOINC ned.

Ich hoffe der Worker crashed ned einfach, wenn er dann wirklich eine WU kriegt.

Was noch fehlen würde ist halt ein Treiber für den RTL8187B Chip, der auch Ad-Hoc kann. Aber den rt8187 konnte ich ned bauen, und ansonsten weiß ich da momentan ned weiter. Mal sehen.

AJO, die reSID Engine läuft, mitsamt Audacious und passendem Plugin. Das is so geil, daß es mir fast die Tränen in die Augen treibt! lol. Bisher hatte ich das nur mit xmms-1 auf Linux x86(_64) und Windows mit WinAmp 2.91.

Er spielt C64 Musik mit der reSID Engine! Es darf keine Maschine ohne SID oder SID Emu geben!

sweet baby jesus, spannender lesestoff

WAHAHA, ich glaubs ned, mein selbstgebauter SETI Code läuft echt, zum Weinen ist das:





Die gewünschte Ausgabe von lspci:

Code:

00:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:08.0 VGA compatible controller: Silicon Motion, Inc. SM712 LynxEM+ (rev b0)
00:09.0 USB Controller: NEC Corporation USB (rev 44)
00:09.1 USB Controller: NEC Corporation USB 2.0 (rev 05)
00:0e.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03)
00:0e.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01)
00:0e.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01)
00:0e.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02)
00:0e.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02)

Dazu noch ergänzend etwas lsusb (hier sieht man den WLAN Chip, ist intern über USB angebunden, sowie den Kartenleser):

Code:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader
Bus 002 Device 004: ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter
Bus 004 Device 002: ID 045e:0047 Microsoft Corp. IntelliMouse Explorer 3.0

glxinfo als Attachment, weil der Output recht umfangreich ist:
glxinfo Output

Spitze

Code:

OpenGL renderer string: Software Rasterizer

und die wlan karte über usb, was will man mehr?

Der software rasterizer ist aber mist, an deiner stelle würd ich dri gleich abdrehen, dann verschenkst du wenigstens nicht die cpu leistung beim herumschieben von Fenstern.

Enlightenment kann übrigens auch mit opengl-es, vielleicht hast du damit mehr freude.