[Sammelthread] AMD K7 - Sockel A (462)

[auto660]

So the oscilloscope arrived today. I did some testing and all the voltages come on in the right order, the power-ok signal is also timed correctly.

The 100MHz PLL clock signal to the cpu is also looking good.

The clock signals for the FSB aren't starting up, these get enabled once the ROMSIP is transferred successfully. This pinpoints the problem to somewhere between the power-ok signal and the end of the ROMSIP transfer.

I'm going to debug some more tomorrow but this is already a big step.

 

[digitalbath]

Nice!
I guess the system stuck somewhere in state 2:

I see the note, that AMD wrote. Are you able to measure the reset# signal? I guess the NB / SB sends it.

edit:
@Tzk
Ein ungewöhnliches board. Bin gepspannt was damit geht. Vermutlich ist das aber zu limitiert, um damit was zu reißen. Ich denke nicht, dass sich ein (hardware)mod beim board sich lohnt?

 

[Tzk]

these get enabled once the ROMSIP is transferred successfully.

Is the RIGOL able to save the SIP transfer? I also guess that at some point things go south. The question is where... Seems like you're already using a very systematic approach and you're testing your way through the stages of the handshake between cpu and chipset. Good luck and keep us posted!

Vermutlich ist das aber zu limitiert, um damit was zu reißen. Ich denke nicht, dass sich ein (hardware)mod beim board sich lohnt?

Bios sockeln und modden werde ich als erstes machen. Danach dürfte es an den fehlenden Einstellungen im Bios scheitern. Multi, Vcore, Vdd, Vdimm gibt es alles nicht. Ich werde es erstmal mit einem Geode 1500 versuchen, der hat Multi 7.5x... Schick ist das Board dennoch. FSB im Bios geht bis 233. Immerhin.

Offiziell kann das Board minimal 1.1V Vcore, der Geode hat aber 1V. Gemäß Fab51 legt das Board dann 1.175V an. Mit Drahtbrücke im Sockel sollte sich das ändern lassen.

Selbst in cbrom sieht es leer aus:

 

[digitalbath]

Selbst in cbrom sieht es leer aus:

Hehe. Ich kann das fast unterbieten:

Der Name des System Moduls im ECS BIOS : "test00.bin" 🙈 ECS kreativ.
triggert mich maximal.

Offiziell kann das Board minimal 1.1V Vcore, der Geode hat aber 1V. Gemäß Fab51 legt das Board dann 1.175V an. Mit Drahtbrücke im Sockel sollte sich das ändern lassen.

Es gibt ja einen Unterschied ob mobile oder Desktop VID. Bei mir wurden auch die 1,15V angelegt bei dem Geode.

Bios sockeln und modden werde ich als erstes machen. Danach dürfte es an den fehlenden Einstellungen im Bios scheitern. Multi, Vcore, Vdd, Vdimm gibt es alles nicht. Ich werde es erstmal mit einem Geode 1500 versuchen, der hat Multi 7.5x... Schick ist das Board dennoch. FSB im Bios geht bis 233. Immerhin.

BIOS sockeln halte ich auch für sinnvoll. Ohne das würde ich keinen BIOS mod machen. Gibt nur Ärger. TFW das board einen goldenen NF2 hat und durchs BIOS/board ausgebremst wird. Wobei bei meinem ASRock kann ich auch nur bis 233MHz booten. Der Rest dann in Windows.

 

[Tzk]

Der Name des System Moduls im ECS BIOS : "test00.bin" 🙈 ECS kreativ.
triggert mich maximal.

test00.bin ist bei denen in jedem Bios
Außerdem gibts ernsthaft ein PCB mit v1.0 und v1.0U. Auf das v1.0U müssen die Biosversionen 3.x drauf, auf das v1.0 die 1.x. Da soll noch einer durchblicken...

Ich denke Hardmods werde ich lassen, Multi geht mit dem Geode auf 7.5x und Vcore bekomme ich mit Draht im Sockel geregelt. Fehlt dann noch Vdd, da muss ich gucken.

 

[Strikeeagle1977]

Ein ungewöhnliches board. Bin gepspannt was damit geht. Vermutlich ist das aber zu limitiert, um damit was zu reißen. Ich denke nicht, dass sich ein (hardware)mod beim board sich lohnt?

Wenn man bedenkt, dass es eigentlich nur für die Wand ist, ist es doch ok. Ausloten, testen und gut. Wenn das Board nen Überflieger gewesen wäre, wäre das ja schon seit Jahren bekannter und beliebter.

Da hat halt ECS nen tollen Chip genommen und damit Boards bestückt, weil die NF2 und die späteren U400er wie geschnitten Brot weg gingen.
Leider sehr am Bios gespart. Kann eben nicht alles Bella/Ferrari sein und für mich ist und bleibt ECS eher der Dacia. Fährt, aber eben kein Sportwagen.

 

[Tzk]

Wenn man bedenkt, dass es eigentlich nur für die Wand ist, ist es doch ok. Ausloten, testen und gut.

Absolut. Alles was jetzt kommt ist der Neugier geschuldet, das ECS wird aber trotz aller Beschränkungen ein Modbios bekommen. Einfach weil jedes NF2 Board sowas braucht, ist meinem inneren Monk geschuldet

Das Bios sockeln mache ich mittlerweile sogar ganz gerne, damit lebt es sich deutlich leichter.

 

[Strikeeagle1977]

Ich wußte es ja eigentlich bereits vorher, muss aber auch wieder aktuell erkennen : Das Board ist bei dir in den besten Händen. Mehr Aufmerksamkeit kann ein ECS Board nicht erfahren. 👍

 

[Tzk]

Ich habe mir erstmal Schaltpläne für das Board besorgt...

Erste Erkenntnis ist, dass man Vcore definitiv nicht über eine Softwarelösung nachrüsten kann. ECS schleift die VID Pins der Cpu (die legen die geforderte Spannung in der Cpu fest) direkt zum Vcore Regler durch. Es gibt keine Verbindung zur SB oder dem SuperIO Chip und damit keine Möglichkeit das in Software anzupassen. Damit gibt es folgende Möglichkeiten die Vcore zu ändern:
1. je nach Standard Vcore der Cpu kann man mit Drahtbrücken im Sockel zumindest auf einige Einstellungen zugreifen
2. VID Pins vom Vcore Regler anheben und dann mittels Schaltern selbst die Vcore setzen - die 90er hatten doch eigentlich "jumperfree" eingeführt oder?

Erklärendes Bild dazu. Das große IC ist der Vcore Regler, die pinken Pins sind VID0 bis VID4. Das grüne kleine Käferchen da drüber ist ein 1K Widerstandsarray, welches die VID Pins jeweils als Pull-up Widerstand auf 3.3V zieht. Zwischen den beiden habe ich Durchkontaktierungen ausgemacht, welche wohl zum Cpu Sockel führen. Setzt man eine Cpu ein, dann schließt diese einige der VID Pins mit Masse kurz. Damit weiß der Vcore Regler dann wie viel Vcore er anlegen soll, der Einstellbereich geht von 1.1V bis 1.85V. Siehe Tabelle neben dem Bild.

Beispiel:
Setzt man eine 1.175V Cpu ein, dann landet man bei VID 11011, es wird also VID2 von der Cpu auf Masse gezogen. Damit könnte man nun mit Drahtbrücken so manipulieren, das die vier "1" ebenfalls auf Masse gezogen werden. Heisst man kann in diesem Fall via Drahtmod z.B. 1.625V anlegen (01001), aber z.B. 1.75V (00100) nicht, weil die Cpu bereits VID2 (xx0xx) auf Masse zieht. An der Stelle muss ich mich nun entscheiden, ob mir der Mod mit Drahtbrücken reicht oder ob ein Hardmod mit Dipswitches aufs Board kommt. Ich werde wohl aus Gründen der Ästhetik nicht löten (-> Board soll später an die Wand) und lieber Drahtbrücken nehmen. Zumal die größte Einstellung von 1.85V immer via Mod erreichbar ist...

 

[Strikeeagle1977]

mit der Vcore einer Geode CPU hat damals auch noch niemand gerechnet, nehme ich mal an.
Einige Asrock Boards habe diese CPU im CPU Support gelistet und supporten auch Vcore 1.0V, aber das sind alles extrem späte Boards.

 

[Tzk]

Doch, schon. Der Geode hat ab Werk eigentlich 1.0V, allerdings hat AMD für mobile Cpus (XP-m und Geode) zusätzlich noch eine etwas abgewandelte VID Tabelle. Deshalb bekommt der Geode 1.175V statt 1.0V... Dennoch viel zu wenig, wenn man den FSB heben will. Meine Geode packen ~2100Mhz bei 1.85V. Mit Multi 7.5x wären das 280Mhz FSB.

Ob man den Multi auch anpassen kann muss ich noch schauen...

 

[digitalbath]

Wenn man bedenkt, dass es eigentlich nur für die Wand ist, ist es doch ok. Ausloten, testen und gut. Wenn das Board nen Überflieger gewesen wäre, wäre das ja schon seit Jahren bekannter und beliebter.

Da hat halt ECS nen tollen Chip genommen und damit Boards bestückt, weil die NF2 und die späteren U400er wie geschnitten Brot weg gingen.
Leider sehr am Bios gespart. Kann eben nicht alles Bella/Ferrari sein und für mich ist und bleibt ECS eher der Dacia. Fährt, aber eben kein Sportwagen.

Nicht falsch verstehen, ich wollte das board nicht schlecht reden. Mir ist klar, dass das board nicht für die OC Sportler gemacht wurde. Das soll einfach nur schnell, stabil und stressfrei arbeiten. Was ja auch okay ist.
Bei einigen weckt das trotzdem einen Ehrgeiz. Siehe bei dem bekannten K7S5A. Es war mit das schnellste board und war recht stabil. Es wurde dann so lange daran rum gebastelt (BIOS), bis es auch (zum Teil) OC konnte.
Meins lief auch mit 150MHz FSB 24/7.

Erklärendes Bild dazu. Das große IC ist der Vcore Regler, die pinken Pins sind VID0 bis VID4. Das grüne kleine Käferchen da drüber ist ein 1K Widerstandsarray, welches die VID Pins jeweils als Pull-up Widerstand auf 3.3V zieht. Zwischen den beiden habe ich Durchkontaktierungen ausgemacht, welche wohl zum Cpu Sockel führen. Setzt man eine Cpu ein, dann schließt diese einige der VID Pins mit Masse kurz. Damit weiß der Vcore Regler dann wie viel Vcore er anlegen soll, der Einstellbereich geht von 1.1V bis 1.85V. Siehe Tabelle neben dem Bild.

Ist halt simpel und effektiv ausgeführt.

Ich würde auch nichts an dem board löten. Dann eher eine CPU mit niedrigen Multi wie der Sempron 2200+ und OC fahren soweit der NF2 mit BIOS Optimierung mitmacht. Oder ein build mit 3200+ und fertig...

 

[Tzk]

Irgendwie gefällt mir der Ansatz von dem Board: kein unnötiges Gedöns drauf, alles schön simpel ausgeführt. Selbst die Pins für den Multiplikator im Sockel sind komplett totgelegt Heisst aber andersrum, das man Kabel an den Sockel anlöten und so die Multiverstellung "hart" nachrüsten kann.Hoffe bzw. glaube ich zumindest... An der Stelle muss ich nochmal bei Asus und MSI nachsehen, wie die die Multiverstellung realisiert haben bzw. wie die Cpu den Multi mitgeteilt bekommt.

Find ich irgendwie gut, ich mag so "analoge" Geschichten wo man die volle Kontrolle hat.

 

[digitalbath]

Den Ansatz finde ich auch klasse. Simpel, stabil, fertig. Wenn ich mir die VRMs vom K7SEM ansehe, sehe ich da eine 4 Phasen VRM. Sieht man bei Sockel A eher selten. Vermutlich sogar schnell geschaltet.

Die Multiverstellung beim ASRock mit den jumpern ist recht simpel gelöst. Ausgehend von den FID Pins kommt ein Widerstandsarray, dann die Jumper pins, die entweder auf GND oder 3V schalten. Fertig. Alle Multis verfügbar!

 

[Tzk]

Das -XE oder das K7NF2 hatte ich noch nicht hier und auch nicht genauer angesehen. Die Idee und Umsetzung ist genial, das baue ich mir glatt auf Lochraster nach... Paar Pinreihen habe ich da, Jumper auch. Das Ganze einmal für FID (dreireihig) und VID (nur GND) und gut ist. Dann paar Kabel von unten an den Sockel und das wars schon, lässt sich sogar optisch rückstandsfrei wieder entfernen.

Biossockel habe ich im Zulauf, diesmal direkt 5 Stück... Einer davon kommt aufs ECS, die anderen vier als Reserve bzw. eventuell aufs DFI NF3. Heissluft hab ich ja mittlerweile auch hier, mal schauen wie gut das klappt.

 

[bschicht86]

Hast du Schrottboards da zum testen wegen der Temperatur? Ich hatte je nach Sockelfarbe das Gefühl, dass es unterschiedliche Temperaturen braucht, um das Plastik sichtbar zu schmelzen.

 

[Tzk]

Keine PC Mainboards, aber etwas Elektroschrott zum antesten. Im Zweifelsfall mache ich das nochmal konventionell mit dünner Spitze, das hat beim DFI NF3 einwandfrei geklappt.

 

[auto660]

I've done some more measurements at the adapter and currently it seems like the romsip is transferred successfully, the output clocks are also enabled now. (dunno why they previously wouldn't start) But i don't see any communication on the SDATA pins. The SDATAOUT[14] pin toggles nicely as stated in the documentation. When i use a normal Slot-A CPU i can see some communication on the SDATA pins, but not with the slotket. The FERR pin also isn't driven when using the adapter. So the error is somewhere after the romsip, which gets acknowlegded by the cpu.

 

[auto660]

And another bit of research... I decided to scope the ROMSIP transfer itself on the connect pin. I did this on the Gigabyte 7IXE4 board which can switch between it's internal romsip (generated from the northbridge, no boot) and it's external romsip (readen from an external SROM, default configuration on the board and boots of course).

Here are the scope shots:
Internal ROMSIP:

External ROMSIP:

I made an attempt to decode them and this is the 33-bit binary value for each:
EXT ROMSIP 7IXE4:
start bit - 000010010000110100001001001001101 (stream order, decode order has to be reversed)
INT ROMSIP 7IXE4:
start bit - 001101100000010010000001001100010

EDIT: Added last bit to the SIP's, i thought it was a 32-bit stream instead of a 33-bit stream. Should be correct now.

 

[Tzk]

Whoa, awesome! This is a thing which i wanted to try for ages. Especially on a NF2 board with several romsip versions, as this might help decoding the nvidia romsips. Also interesting that the external sips boot, but the internal won't...

Is this transmitted at full fsb frequency? So in this case 100Mhz?

 

[digitalbath]

This is awesome!!
looking at the AMD table:

I want to try to decode the sequence
bit sequence (INT): [0 0 110 110 00 000 1 0 0100 0 0 00 10 01 100 01] I guess one bit is missing. Could it be?

Spoiler: wrong!!

the values should look like this:

ResetClkRatio        (RR) 0 /[0]*
BitTimesPerSysClk    (BT) 0 /[0]*
SysAddRecMuxPreload  (AM) 110
SysDataRecMuxPreload (DM) 110
SysResetClkOffset    (RO) 00 /[00]*
SysAddClkDly         (AC) 000 /[000]*
SysAddPage           (PM) 1 /[1]*
SysAddWide           (EX) 0 /[0]*
SysDCDelay           (DL) 0100
DECSysComp           (DS) 0 /[0]*
SysPushPull          (PP) 0 /[0]*
SysAddDly            (AD) 00 /[00]*
SysDataOddDly        (OD) 10 /[01]*
SysDataEvenDly       (ED) 01 /[10]*
SysDataOddClkDly     (OC) 100 /[001]*
SysDataEvenClkDly    (EC) 010 /[010]*

*values by the AMD datasheet

does not looking that bad, but I am not sure if this is correct. The values for OD and ED should be the other way round. What Multi did you use? This makes it easier. The DL value depends on Multi.

Edit. Silly me. I am wrong. I did the same mistake when I did the same thing for the SIS chipset. I have to write it in the usual 32bit direktion

bit sequence (INT): [001101100000010010000001001100010]

in 32bit order:

EC OC ED OD AD PP DS DL EX PM AC RO  DM  AM  BT
010 001 10 01 00 0 0 0010 0 1 000 00 011 011 0 0
bit32                                      bit1

the values should look like this:

ResetClkRatio        (RR) 0 /[0]*
BitTimesPerSysClk    (BT) 0 /[0]*
SysAddRecMuxPreload  (AM) 011
SysDataRecMuxPreload (DM) 011
SysResetClkOffset    (RO) 00 /[00]*
SysAddClkDly         (AC) 000 /[000]*
SysAddPage           (PM) 1 /[1]*
SysAddWide           (EX) 0 /[0]*
SysDCDelay           (DL) 0010
DECSysComp           (DS) 0 /[0]*
SysPushPull          (PP) 0 /[0]*
SysAddDly            (AD) 00 /[00]*
SysDataOddDly        (OD) 01 /[01]*
SysDataEvenDly       (ED) 10 /[10]*
SysDataOddClkDly     (OC) 001 /[001]*
SysDataEvenClkDly    (EC) 010 /[010]*

*values by the AMD datasheet

DL 0010 should be Multi 8,5 or 9. If not, ignore my post.

 

[auto660]

This is awesome!!
looking at the AMD table:
Anhang anzeigen 891735
I want to try to decode the sequence
bit sequence (INT): [0 0 110 110 00 000 1 0 0100 0 0 00 10 01 100 01] I guess one bit is missing. Could it be?

the values should look like this:

ResetClkRatio        (RR) 0 /[0]*
BitTimesPerSysClk    (BT) 0 /[0]*
SysAddRecMuxPreload  (AM) 110
SysDataRecMuxPreload (DM) 110
SysResetClkOffset    (RO) 00 /[00]*
SysAddClkDly         (AC) 000 /[000]*
SysAddPage           (PM) 1 /[1]*
SysAddWide           (EX) 0 /[0]*
SysDCDelay           (DL) 0100
DECSysComp           (DS) 0 /[0]*
SysPushPull          (PP) 0 /[0]*
SysAddDly            (AD) 00 /[00]*
SysDataOddDly        (OD) 10 /[01]*
SysDataEvenDly       (ED) 01 /[10]*
SysDataOddClkDly     (OC) 100 /[001]*
SysDataEvenClkDly    (EC) 010 /[010]*

*values by the AMD datasheet

does not looking that bad, but I am not sure if this is correct. The values for OD and ED should be the other way round. What Multi did you use? This makes it easier. The DL value depends on Multi.

I have added the missing bit to the SIP streams to my original post, the last bit was missing on both. The SIP's have been measured with a D800AUT1C CPU, which is a Duron 800 with an 8x multiplier.

@Tzk
The stream is synchronised to the CPU PLL clock which is indeed the FSB clock of 100MHz, so it's quite a speedy signal. I was hoping that i could maybe inject a custom ROMSIP code by using an external microcontroller that interrupt the CONNECT signal between the northbridge and the CPU for a short duration. Unfortunately 100MHz is still quite a bit too fast for that, even with modern microcontrollers. It won't boot with the internal SIP because the board needs to have the PushPull drivers enabled on the CPU, which is impossible to do on the AMD751 chipset because it is hardcoded internally to set the PushPull bit to 0 in the ROMSIP. So an external SROM from which the ROMSIP is loaded must be used which has got the PushPull bit enabled. There was an unpopulated header on the motherboard to switch between the internal and external ROMSIP. So that was an easy mod for having the option to switch between the ROMSIP's.

 

[digitalbath]

I have added the missing bit to the SIP streams to my original post, the last bit was missing on both. The SIP's have been measured with a D800AUT1C CPU, which is a Duron 800 with an 8x multiplier.

Thanks. I saw in the scope shots, that the last bit was missing. I have edit my post. I guess, I found my error. Now, it makes more sence to me.
The DL value is wrong if you uses the 8x multi. The DL value for Multi 8 is 1 (0001). The value 2 (0010) is for 8,5x / 9x. Strange.

bit sequence (EXT): [000010010000110100001001001001101]

in 32bit order:

EC OC ED OD AD PP DS DL EX PM AC RO  DM  AM  BT RR

101 100 10 01 00 1 0 0001 0 1 100 00 100 100 0 0

bit32                                      bit1

Bingo!!

ResetClkRatio        (RR) 0 /[0]*
BitTimesPerSysClk    (BT) 0 /[0]*
SysAddRecMuxPreload  (AM) 100
SysDataRecMuxPreload (DM) 100
SysResetClkOffset    (RO) 00 /[00]*
SysAddClkDly         (AC) 100 /[000]*
SysAddPage           (PM) 1 /[1]*
SysAddWide           (EX) 0 /[0]*
SysDCDelay           (DL) 0001
DECSysComp           (DS) 0 /[0]*
SysPushPull          (PP) 1 /[0]*
SysAddDly            (AD) 00 /[00]*
SysDataOddDly        (OD) 01 /[01]*
SysDataEvenDly       (ED) 10 /[10]*
SysDataOddClkDly     (OC) 100 /[001]*
SysDataEvenClkDly    (EC) 101 /[010]*

*values by the AMD datasheet

This does fit! Now look at the PP value.
DL value is for Multi 8!

 

[auto660]

This does fit! Now look at the PP value.
DL value is for Multi 8!

Perfect! That's what i was guessing all along, that Gigabyte was using the external SIP to enable the PP bit. It should be 0 with the internal ROMSIP.

 

[digitalbath]

The external romsips should also be somewhat faster, if I had to guess.

Perfect! That's what i was guessing all along, that Gigabyte was using the external SIP to enable the PP bit. It should be 0 with the internal ROMSIP.

Just write the values and SIP settings backwards as I did.


This is more then awesome! We could detect the correct values for the NF2 chip! We could find out why the NF2 chipset is faster per clock!

Spoiler

my guess is, that the mod sips uses BT=1 value

 

[Tzk]

The stream is synchronised to the CPU PLL clock which is indeed the FSB clock of 100MHz, so it's quite a speedy signal. I was hoping that i could maybe inject a custom ROMSIP code by using an external microcontroller that interrupt the CONNECT signal between the northbridge and the CPU for a short duration.

Maybe we can just mod the bios and change the external sips there? That's how we do it on SIS and nForce. Also 100Mhz (=FSB Clock) is quite a high clock. Sadly i do only own an analog 60Mhz scope (Hameg 604) without storage fuction, so probing the nforce 2 is out of scope for me... (pun intended ). I noted that your Rigol was set to 4GS/s and 50ns...

Now, i got that you're currently probing on the Gigabyte 462 board which is almost identical to the slot variant. So if we manage to transplant and activate the romsips on the slot board (-> push/pull enabled), then you're one stop closer to booting the slotket, right?

I'm a bit unsure what we can currently do to support your efforts. If you need anything, just let us know i guess?

This does fit! Now look at the PP value.
DL value is for Multi 8!

Well done!

 

[auto660]

Maybe we can just mod the bios and change the external sips there? That's how we do it on SIS and nForce. Also 100Mhz (=FSB Clock) is quite a high clock. Sadly i do only own an analog 60Mhz scope (Hameg 604) without storage fuction, so probing the nforce 2 is out of scope for me... (pun intended ). I noted that your Rigol was set to 4GS/s and 50ns...

Now, i got that you're currently probing on the Gigabyte 462 board which is almost identical to the slot variant. So if we manage to transplant and activate the romsips on the slot board (-> push/pull enabled), then you're one stop closer to booting the slotket, right?

I'm a bit unsure what we can currently do to support your efforts. If you need anything, just let us know i guess?


Well done!

At 60mhz bandwidth you may still be seeing enough at 100mhz to decode the SIP, although i'm not familiar with analog scopes. What's unfortunate is that none of the Slot-A boards use an external ROMSIP. This was actually a feature for debugging in the chipset which Gigabyte just exploited to make it work for them.

I'm currently a bit stuck with debugging. The CPU initializes successfully but the actual communication with the northbridge doesn't start. I probed several data lines and there is no data to be seen. I'm starting to think that i'm missing some information about how to configure the CPU for open-drain mode. Or the socket462 cpu's for some reason can't use their open-drain drivers and just stall once they are configured for open-drain mode. It's not looking that good currently...

 

[auto660]

Alright, i've given up on the open-drain operation. Everything seems to be configured correctly and all the clock signals look good. The initialization is also successfull, the problem now is that the CPU just won't drive it's data pins. It doesn't even try to communicate. Maybe the Socket-A CPU's just can't communicate in open-drain mode. Which also explains why Gigabyte went through the trouble of putting the AMD751 chipset in debug mode so it reads an external SROM chip that supplies the ROMSIP with an enabled PushPull bit. Having hardware in debug mode on your production boards is probably a less attractive option then just adding pull-up/terminator resistors at the CPU like they were already doing for ages with their Intel boards. My guess is that Gigabyte was having the same problem here.

Since i can't just add an SROM to the chipset and put it in debug mode, i will have to solve this problem differently. The only option is to intercept the ROMSIP and replace it with a custom ROMSIP, this will be a hard job since we're talking about a 100mhz signal that's timing sensitive. But it should be doable, i'm going to order a RP2040 which got really fast internal PIO channels (state machines) and it's at least worth a shot trying it.

 

[Tzk]

At 60mhz bandwidth you may still be seeing enough at 100mhz to decode the SIP, although i'm not familiar with analog scopes.

Mine is full analog, no storage. So i can't probe and view afterwards... I rather have to buy a new scope or a logic analyzer.

Maybe the Socket-A CPU's just can't communicate in open-drain mode.

Which ones have you tried? Maybe the older silicon revisions can do this? I'd probably try with a ceramic cpu, so old duron spitfire or thunderbird. Maybe AMD removed the open-drain mode on newer silicon like palomino/morgan, tbred/applebred and barton/thorton. Also, are you using the correct multiplier setting (if available on the board and your slotket)? Sometimes Athlon refuse to boot if the multiplier is set to something different than the L-bridges are configured to. For example a super-locked barton will only boot with the stock multi.

i also remember that the older silicon cores didn't have a temperature sensor on-die, any rely solely on the in socket one. Maybe this becomes also an issue when trying "new" silicon on slotket?

 

[auto660]

Mine is full analog, no storage. So i can't probe and view afterwards... I rather have to buy a new scope or a logic analyzer.

Which ones have you tried? Maybe the older silicon revisions can do this? I'd probably try with a ceramic cpu, so old duron spitfire or thunderbird. Maybe AMD removed the open-drain mode on newer silicon like palomino/morgan, tbred/applebred and barton/thorton. Also, are you using the correct multiplier setting (if available on the board and your slotket)? Sometimes Athlon refuse to boot if the multiplier is set to something different than the L-bridges are configured to. For example a super-locked barton will only boot with the stock multi.

i also remember that the older silicon cores didn't have a temperature sensor on-die, any rely solely on the in socket one. Maybe this becomes also an issue when trying "new" silicon on slotket?

I've tried multiple CPU's although most of the testing work has been done with a ceramic Duron 800. But i've also tested the adapter with different known-working Thunderbird, Palomino and Thoroughbred chips. I also double checked the FID settings, which is adjustable via dipswitches on the adapter. I even inverted the settings in order to check if i swapped the on/off state for the dipswitches in my documentation. The temp sensor shouldn't be a problem, it isn't connected to any internal logic in the CPU and Bartons are known to run on older pre-tempsensor boards. So i'm really at a loss here.

My final straw is manipulating the ROMSIP transfer in order to enable the PushPull drivers, but this will be a challenge.