# installation mit duron 1600

## dilandau

(suche im forum war ein desaster)

1. welche stagedateien (stage3) verwenden: athlon-xp, i686 oder x86?

2. welche CFLAGS, march o.ä. einstellen?

3. bitte eine fertige make.conf von einem px mit amd duron 1600

----------

## ian!

 *dilandau wrote:*   

> 1. welche stagedateien (stage3) verwenden: athlon-xp, i686 oder x86?

 

Aber dem Duron 1600 geht IIRC auch die Athlon-XP, da dieser auf dem selben Core basiert. Bei Duron <=1300 Mhz ist die i686 zu nehmen.

 *dilandau wrote:*   

> 2. welche CFLAGS, march o.ä. einstellen?

 

Das ist dir freigestellt. (Mehr oder weniger.)

Sinnvoll wäre wohl soetwas wie:

CFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer"

(Vorausgesetzt ich erinnere mich korrekt daran zurück, das der Duron >= 1600 Mhz auf dem XP-Core basiert.)

 *dilandau wrote:*   

> 3. bitte eine fertige make.conf von einem px mit amd duron 1600

 

Das ist hier keine Supporthotline von Sony o.ä.. Ehrlich...

--ian!

----------

## sirro

 *ian! wrote:*   

> Aber dem Duron 1600 geht IIRC auch die Athlon-XP, da dieser auf dem selben Core basiert. Bei Duron <=1300 Mhz ist die i686 zu nehmen.

 

AFAIK gibt es auch Duron<=1300, die stabil(!) als athlon-xp betrieben werden können. Hab das mal irgendwo gelesen und bei mir (Duron1200) ausprobiert. Funktioniert seit Monaten einwandfrei (und stabil).

 *dilandau wrote:*   

> 2. welche CFLAGS, march o.ä. einstellen?

 

Ich hab keine Probleme  mit meinem Duron und CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -m3dnow -mmmx"

Hab im Forum ein schönes Script gefunden [1], ist vielleicht verbesserungswürdig, aber funktioniert eigentlich ganz gut. (solange man nicht mit PPCs oder ähnlichem ankommt) Nur die Optimierungen muss man noch selber einbauen. 

Hier kann man mal mit anderen Usern vergleichen, vielleicht hat wer den gleichen Proz:

 *dilandau wrote:*   

> 3. bitte eine fertige make.conf von einem px mit amd duron 1600

 

Die make.conf ist doch quasi fertig.  CFLAGS (s.o.) einsetzen. USE-Flags (muss jeder selber wissen) eingeben, dazu noch rsync-server und gentoo-mirror und fertig. Dann sollte es eigentlich laufen. Für den Feinschliff ist die Datei aber auch sehr gut dokumentiert.

[1] https://forums.gentoo.org/viewtopic.php?t=53602

[2] http://gentoo.slinky.surrey.sfu.ca/cflagcollect/results.php

----------

## Carlo

 *ian! wrote:*   

> Bei Duron <=1300 Mhz ist die i686 zu nehmen.

 

Mindestens <1200 Mhz, ob es den 1100er als Palomino-Core gibt, weiß ich nicht.

 *ian! wrote:*   

> CFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer"

 

-O3 macht keinen Sinn. Dafür ist der Cache zu klein. -O2 ist die bessere Wahl.

Carlo

----------

## sirro

 *Carlo wrote:*   

> -O3 macht keinen Sinn. Dafür ist der Cache zu klein. -O2 ist die bessere Wahl.

 

Wie sieht das eigentlich mit -Os aus? Stimmt es, dass quasi die gleichen Geschwindigkeitsoptimierungen wie bei -O2 vorgenommen werden, aber zusätzlich noch auf Größe optimiert wird?

 *man gcc wrote:*   

>        -Os Optimize for size.  -Os enables all -O2 optimizations that do not typically increase code size.  It also performs further optimizations designed to reduce code size.
> 
>            -Os disables the following optimization flags: -falign-functions -falign-jumps  -falign-loops -falign-labels  -freorder-blocks -fprefetch-loop-arrays

 

Wie stark sind die Geschwindkeitseinbußen durch die fehlenden Flags und wie stark wird das ganze durch die größe der Binarys wieder ausgeglichen?

----------

## Säck

Hmm, nur so ne kleine Anmerkung: Ich glaube nicht, dass man noch viel an den CFLAGS rumbauen sollte (oder am besten GAR NICHTS), wenn man sowieso eine stage 3 installation vornimmt, ausser man möchte das ganze System neu kompilieren (nach der Installation). 

Da würde ich schon eher eine stage 1 installation machen. --> macht sowieso mehr spass.

----------

## dilandau

Eine meiner urpsrünglichen Fragen war, ob ich von dem stage3 die athlon-xp version oder die i686 version nehmen soll. Also welche? Denn vielleicht beziehen sich eure berichte über "xp funktioniert..." nur auf die flags ab dort? Danke für die Antworten bezüglich der flags.

----------

## toskala

 *dilandau wrote:*   

> Eine meiner urpsrünglichen Fragen war, ob ich von dem stage3 die athlon-xp version oder die i686 version nehmen soll. Also welche? Denn vielleicht beziehen sich eure berichte über "xp funktioniert..." nur auf die flags ab dort? Danke für die Antworten bezüglich der flags.

 

wenn die images mit -march=athlon-xp durchcompiliert sind, dann erlaubt der logische umkehrschluss ja auch zu erkennen, dass in der make.conf -march=athlon-xp funktionieren wird, oder? 

das sagt dir dann auch welches image du nehmen solltest.  :Shocked: 

----------

## dilandau

nein, ich dau. ich verstehe nur direkte kommandos und ja und nein.

----------

## dilandau

> -m3dnow -mmmx

mus das sein? nutzt das was? oder wird das schon durch -march=athlon-xp erledigt?

----------

## sirro

 *dilandau wrote:*   

> > -m3dnow -mmmx
> 
> mus das sein? nutzt das was? oder wird das schon durch -march=athlon-xp erledigt?

 

Es muss gar nichts sein. wenn die Settings so angegeben werden, dann wird das schon so richtig sein. Selbst wenn sie durch athlon-xp schon impliziert werden würden, dann würde diese Flags nicht schaden. (auch -mcpu=foo -march=foo funktioniert obwohl das -mcpu in dem Fall überflüssig ist)

----------

## dilandau

> -m3dnow -mmmx 

wo war das so angegeben und warum?

----------

## Carlo

 *sirro wrote:*   

> Wie stark sind die Geschwindkeitseinbußen durch die fehlenden Flags und wie stark wird das ganze durch die größe der Binarys wieder ausgeglichen?

 

Das kann ich Dir so nicht sagen, schließlich hängt das vom verwendeten Code und der CPU ab (die Prozessorachitektur mal außen vor gelassen). Generell würde ich sagen, daß -Os nicht verkehrt ist, wenn Speicher Mangelware ist. Ansonsten würde ich bei -O2 bleiben.

edit:

 *dilandau wrote:*   

> > -m3dnow -mmmx 
> 
> wo war das so angegeben und warum?

 

Die Flags sind in -march=athlon-xp enthalten. Sie dienen dazu, daß die entsprechenden Befehlssätze der Prozessoren zu nutzen.

Kann man alles hier und hier nachlesen.

Bei Deiner Konfiguration mit nur 256 MB Ram könnte -Os evtl. Sinn machen. Allerdings wäre eine Stage 1 Installation dann sinnvoller.

Carlo

----------

## dilandau

256MB RAM sind eine menge speicher! die dokus "hier" hatte ich da schon gefunden und gelesen aber da sind nur worte gelistet mit mangelhafter erklärung. KDE stonk! für einen pc von heute sind amiga os oder höchstens gnome u.ä. geeignet. man baut doch keinen x gigaherz/ram pc zusammen blos um alle kraft mit einem kde zu verpulvern. mit stage1 fange ich an.

----------

## Carlo

 *dilandau wrote:*   

> 256MB RAM sind eine menge speicher!

 

Auch ein Standpunkt. U.a. deswegen hatte ich evtl. geschrieben. Ich würde damit nicht auskommen (wollen).  :Wink: 

Carlo

----------

## dilandau

womit füllst du den speicher?

btw frage am rande: wie kann ich abchekcen, welche USE flags ode komponenten ich für etwas brauchen werde? ich gehe der annahme, daß ich für gnome und alles was ich will kein alsa brauche zb..

----------

## Carlo

 *dilandau wrote:*   

> womit füllst du den speicher?

 

kde, vmware, db's, apache, mozilla, OpenOffice lade ich vorweg, damit das Starten nicht so lange dauert, dazu die jeweilig genutzten Anwendungen und den Rest füllt Linux, damit die Festplatte nicht dauernd arbeiten muß.

 *dilandau wrote:*   

> btw frage am rande: wie kann ich abchekcen, welche USE flags ode komponenten ich für etwas brauchen werde? 

 

emerge ufed

 *dilandau wrote:*   

> ich gehe der annahme, daß ich für gnome und alles was ich will kein alsa brauche zb..

 

Nicht unbedingt. Wenn Du Sound haben willst, ist es aber sinnvoll, da ALSA ab Kernel 2.6 eh Standard ist.

Carlo

----------

## dilandau

> emerge ufed

Da vermisse ich "p" (= --pretend). "f" täte alle benötigten pakete downladen.

----------

## Carlo

 *dilandau wrote:*   

> > emerge ufed
> 
> Da vermisse ich "p" (= --pretend). "f" täte alle benötigten pakete downladen.

 

Oje. Wenn's nur um einzelne Ebuilds geht, dann emerge -pv. Das sagt Dir aber auch ein simples man emerge. Und jetzt bitte nochmal emerge -s ufed.  :Wink: 

Carlo

----------

## dilandau

æt carlo

> emerge -s ufed

Welchen Zweck hat das im Bezug auf mein Anliegen?

@all

Angeblich funktioniert -march=athlon-xp aber nach einer Stunde erfolgreichem bootstrap (bis da nur mit zzgl. -mno-sse) taucht ein ungülltiger Maschinenbefehl auf:

 *Quote:*   

> cc1obj: internal error: Ungültiger Maschinenbefehl
> 
> Please submit a full bug report,
> 
> with preprocessed source if appropriate.
> ...

 

Was nun? Da das nur ein vereinzelt auftretender fehler ist, will ich -march=athlon-xp  beibehalten. sollte der fehler daher rühren, welche option muss ich einzeln abschalten? mit -mno-sse konnte ich schon vorher ein versäumnis meines bios umgehen.

----------

## Carlo

 *dilandau wrote:*   

> æt carlo
> 
> > emerge -s ufed
> 
> Welchen Zweck hat das im Bezug auf mein Anliegen?

 

USE Flags unterliegen Änderungen, man macht üblicherweise sinnvolle systemweite Vorgaben, etc. Guck' es Dir an! Wenn Du es nicht nützlich findest, wirfst Du es halt wieder weg.

Carlo

----------

## dertobi123

Versuch den bootstrap mit march=athlon{-tbird} oder alternativ march=i686

----------

## dilandau

Die gentoo kernels schalten sse übrigens ein:

 *arch/i386/kernel/setup.c wrote:*   

> case 6: /* An Athlon/Duron */
> 
>                         /* Bit 15 of Athlon specific MSR 15, needs to be 0
> 
>                          * to enable SSE on Palomino/Morgan CPU's.
> ...

 

Der grund warum das bei mir zu fehlern führt ist aller wahrscheinlichkeit nach, daß ich das gentoo system von einem über zwei jahr alten suse 8.0 kernel aus baue (per chroot). mit stage3 und 

CFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe -mmmx -m3dnow -mno-sse -mfpmath=387"

dürfte alles in butter sein. sse könnte ich sogar jetzt wieder aktivieren, vermutlich. welchen vorteil hätte ich dagegen mit athlon(-tbird)?

----------

## sputnik1969

 *sirro wrote:*   

>  *ian! wrote:*   Aber dem Duron 1600 geht IIRC auch die Athlon-XP, da dieser auf dem selben Core basiert. Bei Duron <=1300 Mhz ist die i686 zu nehmen. 
> 
> AFAIK gibt es auch Duron<=1300, die stabil(!) als athlon-xp betrieben werden können. Hab das mal irgendwo gelesen und bei mir (Duron1200) ausprobiert. Funktioniert seit Monaten einwandfrei (und stabil).

 

Und damit hast du vollkommen Recht  :Smile: 

Athlon-XP Kompatible Duron-Cores (mit SSE) wurden mit dem Duron-1000 eingeführt, kurze Zeit später kamen allerdings auch kleinere Durons (ab 800MHz) mit diesem Core auf dem Markt...

Also:

```
 Duron > 1GHz -> Immer Athlon-XP Architektur

 Duron 800 - 950 -> nur die letzten Bauserien sind zum Athlon-XP kompatibel

 Duron < 800 MHz -> sind nur kompatibel zum "normalen" Athlon
```

----------

## sirro

cool, das ist ja mal eine Aussage, die das ganze mal aufklärt.

Diese Duron/Celeron-Geschichten sind ja zum Teil etwas verworren   :Confused: 

----------

## dilandau

Eine Liste aller unterschiede von =i686 zu =athlon-xp wäre praktisch.

----------

