[Sammelthread] AMD K7 - Sockel A (462)

Der 3000+ hat Multi 10.5x, der 2600+ hat 12.5x. Gut möglich, dass die Romsips Schluckauf verursachen. Insbesondere Multi 10 und 10.5 sind am schwersten stabil zu bekommen und haben am meisten Bandbreite auf dem Bus. Gut möglich, dass die Kombi aus Bios/Sips, Cpu und Chipsatz das einfach nicht mag... Gibt keine Garantie, dass das Bios überall stabil läuft.

Ich würde wie gesagt ein anderes Bios versuchen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich hab ja ein NF7 wegen Kondensatoren da und wollte es anschliessend mit einem Mod-BIOS von dir versehen, musste aber feststellen, dass die Version NF7_[D65_3]_B3A massive Probleme mit non-Mobile Prozessoren hat. XP-M laufen mit 200MHz wie es sich gehört durch memtest, aber ein 3000+ (200FSB) war gar nicht zum Boot zu bewegen (Code EF) und ein 2600+ (166FSB) sporadisch mit ab und zu Aufhängen in memtest.
Danke für den Input! Generell sind solche Probleme nicht einfach zu identifizeren. Da sind recht viele Abhängigkeiten. Heißt BIOS A kann bei einem board A mit allen Multis laufen und auf board B Probleme mit einem bestimmten Multi haben. Board C hat dann ein Problem bei einem anderen Multi. Ich denke das ist auch der Grund warum DFI so viele Beta BIOSe gemacht hatte. Die problemloseste Variante sind die originalen SIPs von Nvidia. Dann kann man aber OC vergessen. Ich habe bisher nicht herausgefunden woran genau dieses Verhalten liegt. Meine bisherige Theorie ist, dass es an dem ersten Teil der romsips liegt. Also an dem MC Teil. Irgendein Timing passt dann nicht zu den timings des FSBs.

Inkompabile Multis kann man am besten mit Memtest herausfinden. Memtest stüruzt dann recht am Anfang immer an der gleichen Stelle ab (freeze).

Ich bin mir nicht 100% sicher, aber ich meine, ich hatte auch vor kurzem Stress bei einer 166MHz XP CPU. Abhilfe war höherer FSB und ein höherer Wert bei der Option "romsip value 68h" (auf z.B. AA). Das hilft dir aber nicht bei der 200MHz CPU. Einen 3000+ mit 200MHz FSB habe ich da. Wenn ich Zeit finde teste ich mal gegen. Würde mich interessieren, ob ich das nachstellen kann. Melde mich dann.

Die D65 romsips hatte ich bisher fast nur mit XP-M CPUs betrieben, von daher ist ein Test mit Feedback immer gut!

Der 3000+ hat Multi 10.5x, der 2600+ hat 12.5x. Gut möglich, dass die Romsips Schluckauf verursachen
:bigok:
 
🙈
@bschicht86 Probier bitte mal das BIOS hier. Ich denke, ich habe das Problem gefunden. Wenn das BIOS bei dir auch mit der 200MHz CPU läuft, dann habe ich wohl einiges an Arbeit vor mir. :fresse::wall::wall:

Also ich habe als erstes das BIOS mit D65 romsips auf meinem MSI Delta2 probiert. Eine 2500+ (166MHz FSB) und eine 3000+ (200MHz FSB) liefen stressfrei. Dann habe ich mein AN7 board aufgebaut und siehe da, eine 3000+ CPU startet nicht. XP-M CPUs liefen darauf recht stressfrei. Die 3000+ CPU startet auch nicht mit 166MHz FSB. Mit 133Mhz startet die CPU dann. Anschließend habe ich ein paar Stunden lang an den romsip Werten herumgetestet. Immer wieder Wert im BIOS ändern, BIOS flashen, neustarten, usw. Keine Lösung gefunden. Originale romsips mit mod BIOS geflasht, das selbe Problem. Häh? Original BIOS startet aber mit der 3000+ CPU auch mit 200MHz. Also ist das Problem nicht in den romsips zu suchen. Hätte ich eigentlich schon sofort merken müssen. Was ist der größte Unterschied zwischen dem MSI Delta2 und dem Abit AN7? - Richtig die BPL (NVDAMC vs NVMM). :fresse: Also habe ich bei dem AN7 die BPL gewechselt. Siehe da, jetzt läuft auch die 3000+ CPU. Ich habe keine Ahnung warum. Eigentlich ist die BPL uninteressant.

Das blöde ist, ich habe bei vielen neuen BIOS mod Versionen die letzte BPL mit der Version 3.20 bestückt. Scheinbar kann diese Versionen Probleme verursachen. Ich muss also wieder die Version (3.19) davor nutzen und die vorhandenen Versionen ändern.
😭😭😭😭
 

Anhänge

  • NF7_[D65_3]_B3A_319.zip
    468,7 KB · Aufrufe: 37
This bios is for AN7?

Main difference is that AN7 is a pain in using. Worst board I have ever seen. I boxed mine and put them far away.
 
The uploaded BIOS is for a NF7 board.
I only tested the issue with my AN7 board to figure out where the problems come from. I also could test it with my NF7 board. But yes, the AN7 boards are "special". :d :fresse:

edit.
My two AN7 boards act somehow different. The first one needs high romsip value 68 to be stable, the other one hates high values.
 
BPL is a part of the BIOS, some kind of a module. I guess NVMM (also in S939) sounds more familiar to you. We can change it by replacing the whole BPL code. Until now, I thougt this module recognises the dram modules and sets the propper dram timings. Now I am not sure what is also does.
If you want to test new BIOS versions for a NF7 or a AN7 board, please wait until I remod the BIOSes with a different BPL (3.19) version. At least if you want to test non XP-M CPUs.
I also want to test more my both AN7 boards. Maybe I can optimize the BIOS to work more stable without stressing out.

edit:
or do you mean the romsip 68 value? The 68 value is in the latest BIOS versions as a separate setting.
 
Zuletzt bearbeitet:
@bschicht86 Probier bitte mal das BIOS hier. Ich denke, ich habe das Problem gefunden.
(y)

Problem ist nur, ich hab, nachdem ich ein brauchbares Mod-BIOS gefunden habe, das Board wieder eingetütet und gestern zum Absender zurück geschickt. Wenn mein Boardschrank nicht so komprimiert wäre... Vielleicht hole ich da mal bei viel Langeweile ein NF7 raus und teste mit dem.
 
68h is also in the Nforce2 xtreme tweaker. So either use a modbios or tweak it in win, prior to adjusting the fsb.
 
Yes I meant the romsip 68 value.

But BPL for DRAM stability makes sense. I had to run an AN7 board on 1000MHz with 100MHz ram to stabilize it if I remember it correctly.
 
We're still not sure what exactly BPL/NVDAMC does. Personally i believe it does initialize the dram controller in the chipset and maybe it also programs the ram timings (SPD, primary and alpha). Iirc it even has a special detection for certain dram sticks - for enhanced compatibility. One of the things i'd like to do in the future is to reverse engineer the 3.19 BPL, just to see what's inside.

Same for the romsips. I've not been able to find the bios routine which loads the romsips into the chipset. That's some work left for the future.
 
Problem ist nur, ich hab, nachdem ich ein brauchbares Mod-BIOS gefunden habe, das Board wieder eingetütet und gestern zum Absender zurück geschickt. Wenn mein Boardschrank nicht so komprimiert wäre... Vielleicht hole ich da mal bei viel Langeweile ein NF7 raus und teste mit dem.
Achso dann ist ja alles klar. Problem gelöst. Ich werde dennoch die BIOS Versionen überarbeiten. Nur um sicher zu sein.
Wenn der Besitzer des boards einen BIOS Wunsch hat, kann er sich ja melden.

Yes I meant the romsip 68 value.

But BPL for DRAM stability makes sense. I had to run an AN7 board on 1000MHz with 100MHz ram to stabilize it if I remember it correctly.
Ah, okay. All BIOSes with B3 version should have the 68 setting in the BIOS.
Many AN7 boards seems to have an "issue" that low 68 values tends to crash. That is why Enduracell did mod special romsips for the AN7 board. He used a higher 68 value then the usual DFI based romsips used to prevent the crashes. A value of AA to 88 is ideal to reach a stable system at higher FSB clocks.

1713089075233.png


Most of my NF2 boards aren't able to reach high FSB clocks with a high offset 68 value. I have to lower this value down to 22 or 11. My second AN7 seems to act simmilar. Maybe I should compare my both AN7 boards. Maybe there is a change in the board design?
 
Ich werde dennoch die BIOS Versionen überarbeiten. Nur um sicher zu sein.

Tausend Dank für deine Arbeit daran. Ich hatte bereits auch solche Probleme, habe es aber darauf geschoben, dass ich vielleicht irgendwas vermurkst hatte im BIOS und daher dem Problem keine weitere Beachtung geschenkt. Wenn ich das so lese, muss ich vllt. ein paar der Bretter irgendwann nochmal neu durchtesten, die sich zickig gezeigt haben.

Wenn mein Boardschrank nicht so komprimiert wäre

In meiner NF7 Unterkunft sind noch Plätze frei und meine Adresse hast du ja :fresse:
 
Neueste Studien raten aus ESD Gründen von übermäßigem Streicheln älterer Hardware eh ab :fresse:

Personally i believe it does initialize the dram controller in the chipset and maybe it also programs the ram timings (SPD, primary and alpha). Iirc it even has a special detection for certain dram sticks - for enhanced compatibility. One of the things i'd like to do in the future is to reverse engineer the 3.19 BPL, just to see what's inside.

Mal rein aus Neugierde... wenn ihr solche Sachen auseinander nehmt, wie muss man sich das vorstellen? Mit einem Hexeditor in einen File reinschauen und versuchen das zu interpretieren oder gibt es da einen Ansatz, der den Inhalt "leslicher" erscheinen lässt? Das ist so abgefahren, was hier an Know-How zusammengetragen wird :d

Wenn man dieses Wissen damals schon alles gehabt hätte, aber wahrscheinlich waren die Produktzyklen einfach zu straff um da so viel Zeit reinzustecken oder gab es die Tools einfach nicht, die es heute gibt?
 
Wenn man dieses Wissen damals schon alles gehabt hätte, aber wahrscheinlich waren die Produktzyklen einfach zu straff um da so viel Zeit reinzustecken oder gab es die Tools einfach nicht, die es heute gibt?
Das Wissen damals wäre max aus dser Produktion gekommen und im Geschäft, damals eher weniger Online dann an die richtige Produktionswoche zu kommen ...
Ich denke, heute hinterher so etwas zu machen, ist nicht schlecht.
Vor 10 Jahren waren die Boards sicherlich noch günstiger und es hätte wohl noch größere Sammlungen gegeben.

Ich denke auch, damals war das Wissen noch nicht so verbreitet, weil ggf noch unter Verschluss bzw wichtige Internas. Erst nach geraumer Zeit können dann Mitarbeiter zum Wissen der User beitragen.
 
Mal rein aus Neugierde... wenn ihr solche Sachen auseinander nehmt, wie muss man sich das vorstellen? Mit einem Hexeditor in einen File reinschauen und versuchen das zu interpretieren oder gibt es da einen Ansatz, der den Inhalt "leslicher" erscheinen lässt? Das ist so abgefahren, was hier an Know-How zusammengetragen wird :d
Das sind mehrere Baustellen gleichzeitig. Am Anfang hast du immer das Bios selbst als eine große Datei. Darin sind einzelne (teilweise LHA komprimierte) Module. Die Module wiederrum beinhalten sowohl Daten als auch Maschinencode. Das gemeine an der Stelle ist den Kram auseinander zu halten. Teilweise gibt es sogar einfach Tabellen mit Offsets, die als Sprungadressen dienen.
Wir nutzen zum verwalten der Module im Bios CBROM, das ist ein Award Tool welches die Module extrahieren und importieren kann. Und für das Umsortieren von Optionen und Standardwerten im Bios gibt's Modbin. Für AMI Biose gibt's ebenfalls entsprechende Tools.

Nun zur eigentlichen Frage, für das Analysieren nehme ich natürlich einen HexEditor wie HxD, aber der hilft beim der Analyse von Maschinencode nur bedingt weiter. Wenn man zumindest halbwegs leserlichen Code will, dann braucht man einen Dekompilierer bzw. Disassembler. Ich nutze dafür die Freeware der NSA - Ghidra. Dann ist es zumindest lesbar, sofern man Assembler versteht :d Man kann theoretisch den Code zu Assembler wandeln, dann manipulieren und anschließend wieder kompilieren. So weit bin ich aber noch lange nicht, da fehlt mir noch etliches Wissen zu.

Was zusätzlichen Programmcode angeht, den schreibe ich in FlatAssembler (FASM) und füge ihn dann ins Bios entweder als Modul oder direkt als Maschinencode ein.

Das war jetzt die Kurzfassung... 🙈
 
Hilfe, bei mir fährt gerade nur ein Zug durch - ich verstehe nur Bahnhof ...

Schön, dass es euch gibt und ihr euch da so engagiert.
 
Ich versuche es mal einfacher zu formulieren.
Das BIOS wird mit der Assembler Programmier Sprache geschrieben. Das sieht in etwa so aus. Alles was nach dem Semikolon steht, ist nur eine Zusatzinfo an den User. Wird beim Codeschreiben ignoriert.

Code:
    readCmosReg 0x75, 0xF0                      ; read drive strength from CMOS

    cmp al, 0
    je drivestrength_end                        ; jump to next setting if auto selected (equal 0000.0000)

    xor ebx, ebx
    mov bl, al
    shr bl, 4
    or bl, al
    mov al, bl                                  ; save bl
    shl ebx, 24                                 ; shift bl to highest 8bit segment
    mov bh, al

    writePciReg 0x80000464, ebx, 0x00FF00FF     ; offset 65 and 67
    writePciReg 0x80000470, ebx, 0x00FF00FF     ; offset 71 and 73

    and ebx, 0x00FFFFFF

    writePciReg 0x8000047C, ebx, 0xFFFF00FF     ; offset 7D
    writePciReg 0x80000480, ebx, 0xFFFF00FF     ; offset 81

    drivestrength_end:                          ; jump target

Das sind die Instruktionen an das System. Der obere Code ist ein Teil aus dem Zusatz (orom), den wir für die "neuen" NF2 BIOSe schreiben. Wie man an dem Text sieht, ist das der Teil, der die drive strength in die PCI register schreibt. Den kompletten Assebler Code zu unserem Zusatz kann man bei den BIOSen, die ich gemoddet habe, selber ansehen. Einfach in den bin Unterordner nach einer .ASM Datei suchen und mit Notepad öffnen. Da stehen auch andere Infos wie die PCI register drin.
Wenn der Assembler Code fertig ist, muss das BIOS kompiliert und in die Maschinensprache umgeschrieben werden. Der Code sieht dann in etwa so aus:

1713204217662.png

Ja genau, man erkennt nichts. So sieht ein BIOS aus, wenn man das mit einem HEX-Tool öffnet. Anhand dieses Codes kann man den Assembler Code nicht mehr erkennen. Man kann auch nicht erraten, was der Code macht. Um das heraus zu finden, brauchen wir ein Programm, dass aus dem fertigen Maschinencode zurück den Assembler Code generiert. Das ist nicht immer so einfach, da das Programm an manchen Stellen zwischen dem Datencode (fertige Buchstaben, Sätze oder Zahlen) und den Befehlen nicht unterscheiden kann. Da muss man von Hand mithelfen. Dementsprechend, erfordert das Übung. Tzk ist da etwas geübter als ich.
Der Anfang der BPL sieht im Assembler Code dann so aus. Das ist nur ein kleiner Teil.

1713204966086.png


Diesen Asseblercode zu lesen erfordert Übung. Die einzelnen Befehle zu lernen ist nicht schwer, aber die ganzen Zusammenhänge und Codesprünge (siehe Pfeile auf der linken Seite) ist nicht einfach.
Ich hoffe, das gibt eine kleine Übersicht zu der Sache mit dem BIOS code.


Tausend Dank für deine Arbeit daran. Ich hatte bereits auch solche Probleme, habe es aber darauf geschoben, dass ich vielleicht irgendwas vermurkst hatte im BIOS und daher dem Problem keine weitere Beachtung geschenkt. Wenn ich das so lese, muss ich vllt. ein paar der Bretter irgendwann nochmal neu durchtesten, die sich zickig gezeigt haben.
Gerne. Ich teste derzeit mein zweites Abit AN7. Ich werde in dem Zuge die AN7 BIOSe ändern und testen. Danach nehme ich mir die NF7 BIOSe vor. Mal sehen. Bisher ist das zweite AN7 eher krückig denn eine OC Rakete (~240MHz FSB).

Wo wir beim AN7 sind, weiß Jemand, ob die Abit Guru Clock auch auf dem AN7 geht? Ich habe bisher immer gedacht, dass das AN7 auch kann. Der Anschluss dafür ist ja vorhanden. Laut Abit ist das board nicht auf der Support Liste.
 
Zuletzt bearbeitet:
Noch ein bisschen mehr Bahnhof, weil der Screenshot oben relativ gut zu lesen war... :d

Man sieht an den Pfeilen auf der linken Seite schön, das der Code ordentlich verschachtelt ist. Teilweise werden Blöcke übersprungen, dann später von weiter unten wieder aufgerufen. Oder es gibt einen Prüfwert (wenn A = ?, dann....) und danach verzweigt es sich. Leider weiß man beim reinen Anschauen des Codes halt nicht welchen Wert das Register in diesem Moment hat. Man muss also alle Verzweigungen durchlaufen und weitersuchen. Das macht die Sache SEHR mühselig.

Der Anfang der BPL sieht im Assembler Code dann so aus. Das ist nur ein kleiner Teil.
In der Zeile 0007:0009 und 00010 steht mov AL, 0xD0 out 0x80, AL . OUT 0x80 ist die Routine, die den POST Code rausschreibt. Wenn das Bios also diesen Teil des Codes ausführt, wechselt der POST Code auf einer POST Code Karte zu D0. Das Gemeine ist nun, dass man nicht weiß von wo der Code ausgeführt wird. Code "vorwärts" lesen ist immer leicht, aber "rückwärts" ist ein Problem...

Den Block von 0007:0020bis 0007:005C verstehe ich so:
Hier sieht man wie eine Schleife in Assembler "zu Fuß" programmiert wird. Wir laufen von 0020 bis 0031 durch, es wird CX erhöht und dann dann geprüft ob CX gleich 0x1 ist. Je nach Ergebnis springen wir wieder nach oben (gestrichelter Pfeil zu 0007:0020) oder es geht nach unten weiter. Direkt danach (0007:0035) kommt wieder OUT 0x80 und der POST Code wechselt zu FE.

Das ist nun erstmal was der Code "tut". Was er "bedeutet" wäre dann eine ganz andere Frage. Ich vermute wir haben hier die Hauptschleife der BPL vor uns, die mit 0007:0071 RETF - also return far endet. Sprich alles andere was in den BPL passiert müsste durch den JMP in 0007:0023 ausgeführt werden.
 
Zuletzt bearbeitet:
Ich habe ehrlich gesagt den Screenshot nicht versucht zu lesen. 😅
Ich will irgendwann mal auch mit IDA probieren zu arbeiten. Quasi IDA so einrichten, wie pinczakko es in seinem Buch geschrieben hat. Vielleicht ist das dann etwas einfacher? Derzeit habe ich wohl keinen Nerv, bzw. Antrieb dazu.
Ich finde es erstaunlich wie viel schneller du den Code deuten, bzw. lesen kannst. :bigok:
 
Es überrascht mich doch etwas, halbwegs mitgekommen zu sein. S7 in AWL ist dem sehr ähnlich. Nur der Syntax ist scheinbar etwas anders.
 
@digitalbath Deine Mod-BIOS'e sind fast im wahrsten Sinne des Wortes zum Mäusemelken. :fresse: Hatte jetzt 3 für das letztgepostete MSI ausprobiert und es gab immer wieder derselbe Aufhänger in memtest Test 7.

XP-M wie zuvor, (diesmal 9,5x200) dazu 2x 512MB selbstgelötete TCCD. Mit Originalbios läufts durch memtest durch, aber die 3 aus der BIOS-Bude hängen. (619XT, ED, X1) Anfangs hab ich noch rumprobiert und kam soweit, dass 180MHz 1:1 lief, aber ab 185MHz gabs die Hänger. FSB166 und RAM auf 200 lief auch noch, aber FSB200 und RAM auf 166 nicht mehr. Gibts da irgendwelche Einstellungen, die du reingebastelt hast, die den FSB zwischen CPU und NB beeinflussen? Welche von denen müsste ich wie ändern, damit es womöglich stabiler läuft?
 
Sag nicht sowas. 🙈 :fresse:
Ich denke, dass du genau dieses Phänomen erwischt hast:
Danke für den Input! Generell sind solche Probleme nicht einfach zu identifizeren. Da sind recht viele Abhängigkeiten. Heißt BIOS A kann bei einem board A mit allen Multis laufen und auf board B Probleme mit einem bestimmten Multi haben. Board C hat dann ein Problem bei einem anderen Multi. Ich denke das ist auch der Grund warum DFI so viele Beta BIOSe gemacht hatte. Die problemloseste Variante sind die originalen SIPs von Nvidia. Dann kann man aber OC vergessen. Ich habe bisher nicht herausgefunden woran genau dieses Verhalten liegt. Meine bisherige Theorie ist, dass es an dem ersten Teil der romsips liegt. Also an dem MC Teil. Irgendein Timing passt dann nicht zu den timings des FSBs.
Genau sagen kann ich es nicht. Nach meiner Theorie müsste ein anderer Multi stressfrei laufen. Probier das mal. z.B. Multi 9 oder 10 oder 8.
Es sollte nicht das gleiche Problem wie das von dem board davor sein. Das Problem davor war der Code für den Memory Controller. Die "Problem" Version ist die Version 3.20. Das sollte dann auch im Namen stehen. Die BIOS Version die du getestet hast, hat die "gute" Version 3.19 vom DFI NF2. Die geht 100%. Das Problem kann man recht simpel auf die romsips schieben.

Gibts da irgendwelche Einstellungen, die du reingebastelt hast, die den FSB zwischen CPU und NB beeinflussen? Welche von denen müsste ich wie ändern, damit es womöglich stabiler läuft?
Die timings zwischen CPU und NB sind ja die romsips. Die ändern wir ja bewusst.
Du kannst ja mal die DFI romsip presets aus dem BIOS durchtesten. Das könnte auch helfen. Wenn eine der DFI presets gut läuft, kann ich daraus ein eigenständiges BIOS bauen. Ich tippe mal auf eine der ersten presets.
 
Nach meiner Theorie müsste ein anderer Multi stressfrei laufen. Probier das mal. z.B. Multi 9 oder 10 oder 8.
Also ich hatte schon Multi 10, 10,5 und 7,5 in Verwendung gehabt, aber alle hatten diese Ausfallerscheinungen bei FSB200.

Du kannst ja mal die DFI romsip presets aus dem BIOS durchtesten.
Gut, dann werd ich die mal probieren. Was steckt eigentlich hinter "Auto"? "Auto" hätte ich getippt: "Ist wie Original-BIOS, ich fass nix an"
 
Multi 10, 10,5 und 7,5
Das sind was den FSB angeht die schlimmsten Multis mit dem geringsten Potenzial was FSB angeht. Trotzdem sollte Multi 7.5 auf einem vernünftigen Board bis wenigstens 230Mhz gehen. Ich hatte Ärger in Test 7 eigentlich nur, wenn entweder der Chipsatz vom Board ein schlechtes Exemplar war oder wenn die Romsips einfach nicht gepasst haben.

Ich würde mal mit Multi 8 oder 9 testen, aber bitte keine Wunder erwarten.

Und bitte immer FSB zu Ram 1:1 testen, der Nforce 2 dankt asynchronen Betrieb mit Instabilitäten und schlechter Performance.

Was steckt eigentlich hinter "Auto"?
Dann werden die im Bios fest hinterlegten Werte genommen. Wenn du dort was anderes wählst werden gewisse Timings überschrieben.
 
Also ich hatte schon Multi 10, 10,5 und 7,5 in Verwendung gehabt, aber alle hatten diese Ausfallerscheinungen bei FSB200.
Hattest du das nur mit Memtest getestet, oder auch mit Windows. Nicht, dass das Verhalten sich nur auf Memtest auswirkt. Ich teste mit Memtest recht selten. Von daher kann ich da nicht soo viel sagen.

Gut, dann werd ich die mal probieren. Was steckt eigentlich hinter "Auto"? "Auto" hätte ich getippt: "Ist wie Original-BIOS, ich fass nix an"
Das was Tzk sagt. :) Das ist im Grunde so, als ob du die romsip Werte im tweaker in Windows verstellst. Hier stellt das BIOS beim boot die Preset Werte ein.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh