Yesterday I had the opportunity to test a recently acquired Athlon 1200 CPU (Thunderbird core, ceramic PGA package). I dreaded the first boot-up attempt because I have had rather bad experience with slightly newer Palomino and Thoroughbred OPGA processors—a surprisingly high percentage of them was DOA.
But the Thunderbird Athlon (two of them actually) with OPN A1200AMS3C sprang to life and worked just fine. While running some basic tests on the CPU, I noticed that it has a completely unknown CPUID bit set, specifically bit 18 in register EDX of CPUID leaf 80000001h.
The 8000xxxxh CPUID range was originally AMD specific and, among other things, used to indicate support for the 3DNow! instruction set in the AMD K6 processors.
When Intel introduced AMD64 support, they were more or less forced to support a subset of the 8000xxxxh CPUID range as well, for compatibility with existing AMD64 software. In any case, the Athlon CPU in question is from 2001 and pre-dates Intel’s x64 processors by several years.
The usually very reliable sandpile.org lists EDX bit 18 as “reserved”. I went through available AMD CPUID documentation but nope, bit 18 is listed as “Reserved on all AMD processors” in all the documents I could find.
Even better, AMD’s CPUID documentation lists the actual CPUID values for specific CPU models. For Athlon Model 4 (Thunderbird), CPUID leaf 80000001h register EDX is listed as C1C3_FBFFh when APIC is enabled. But the actual CPU returns C1C7_FBFFh in EDX—there is a one-bit difference, and it is precisely the mystery bit 18.
The fact that a random CPUID bit in the middle of used bits is “reserved” is usually a very good indication that the bit was used for something at some point, but either it never showed up in officially released CPUs or it briefly did (like this mystery bit 18) but was not documented.
Note that bit 19 was used to indicate multi-processing capability (or maybe really ECC memory support) in the Athlon MP, circa 2002. Bit 17 indicates PSE-36 (Page Size Extensions) and appears to have been added in Athlon Model 2 circa 1999. Bit 17 in the extended CPUID, like most of the lower bits, mirrors bit 17 in the “regular” CPUID (leaf 1, register EDX), defined by Intel.
Bit 18 in standard CPUID was used to indicate the short-lived PSN (Processor Serial Number) feature of Pentium III processors. However, it is unlikely that Athlon Model 4 implemented some sort of serial number capability, so the bit’s purpose was almost certainly something else.
So… what was that bit 18 for? Anyone?
Update: Soon after this post was published, sandpile.org was updated to show that bit 18 was intended to indicate ECC capability on AMD K7 processors. Which, to be honest, raises more questions than it answers. That said, I am confident that the sandpile.org information is accurate.
After reviewing Athlon datasheets, it is apparent that the original AMD-750 chipset and Slot A Athlons supported ECC memory. The capability was not advertised via CPUID, presumably because it could be assumed to be present.
ECC support (and the corresponding SCHECK pins) are also documented in Athlon Model 4/Thunderbird datasheets for Slot A. Note that Athlon Model 4 was the last to support Slot A and the first to support Socket 462. ECC support is likewise documented in the Duron Model 3/Spitfire datasheets (Socket 462 only).
Something curious happened with the Model 4 PGA Athlon datasheets. Revision G datasheet (Publication # 23792 Rev: G, October 2000) talks about ECC, the text is essentially identical to Slot A Athlon datasheets. However, Revision K datasheet (Publication # 23792 Rev: K, November 2001) has nothing about ECC or SCHECK pins. The document’s revision history makes absolutely no explicit mention of dropping ECC support; Revision H (March 2001) is probably where it happened, based on what was reportedly changed in that revision.
Athlon XP datasheets (starting with Model 6 aka Palomino) likewise include no mention of ECC. Only Athlon MP datasheets (Model 6/8/10) do.
It is clear from the published documentation that for Socket 462, AMD decided to make ECC support optional, hence it needed to be advertised through a CPUID bit. But for some reason, AMD decided to drop official ECC support from Model 4/Thunderbird Athlons, apparently before information about the CPUID bit was published.
At about the same time, AMD also decided to produce Athlon MP models with documented ECC capability and multi-processor support. ECC and MP capability was folded into one, indicated by extended CPUID bit 19. Bit 18 likely became obsolete because AMD dropped plans to make K7 processors with ECC support but no MP capability. So they retroactively pretended that ECC support for Socket 462 only existed in Athlon MP.
The situation was likely complicated by the fact that Athlon boards with non-AMD chipsets (VIA, ALi, nVidia) did not have any ECC memory support anyway. The typical Athlon customers was also likely interested in price/performance, not reliability, and was not interested in using ECC DRAM. AMD may well have decided that testing ECC support was not worth the effort, except for Athlon MP models.
If I had to speculate, there is a very good chance that the Athlons which set bit 18 do in fact support ECC, although I have no way to verify that. The one board I have which would support ECC (Tyan Thunder K7X Pro) unfortunately refuses to boot with ECC enabled even when an Athlon MP is in place (and yes, obviously with ECC DIMMs installed).
Lots of Linux kernel boot logs also show the c1c7 pattern, e.g.:
https://www.linuxquestions.org/questions/linux-general-1/is-it-an-athlon-or-athlon-thunderbird-209868/
(It’s easy to find by searching for c1c7fbff as opposed to c1c3fbff.)
Have you considered the possibility than it is one of those Debug Mode / God Mode flags? I recall that sometimes doing digital archaeology you find news articles about that.
The last time this topic was popular was circa 2010, you had news like this all over Hardware news sites:
https://www.theregister.com/2010/11/15/amd_secret_debugger/
https://hardware.slashdot.org/comments.pl?sid=1865066&cid=34207758
Google 9C5A203A to get those.
However, I recall than something similar was known at somewhere 2001-2003 timeframe from an overclocking forum Thread, where somebody noticed via BIOS reverse engineering that BIOS was writting some magic value on a MSR to unlock other MSRs related to overclocking settings. Surprisingly, I stumbled with that Thread right now googling the above code:
https://www.reddit.com/r/technology/comments/e6tsk/knowledge_about_supersecret_debug_capabilities_of/
https://www.overclockers.com/forums/threads/anybody-see-new-rev-e-specific-dividers.403019/page-2
It may be related to what you’re seeking.
Doing a quick scan of instlatx64’s CPUID dump database ( https://github.com/InstLatx64/InstLatx64 ) , I was able to find three AMD CPU models that set this bit: a “Spitfire” Duron (signature 630h), a “Thunderbird” Athlon (signature 644h) and a “Morgan” Duron (signature 670h).
If I were to guess at documents that may contain additional information about this bit, a possible candidate may be the “AMD Athlon and AMD Duron Processor BIOS, Software, and Debug Developers Guide” order no. 21656, which I’ve seen referenced a few times in other AMD documents – however, unlike similar BIOS-guide documents for e.g. K6 and K8 (neither of which feature this bit), this one seems to be very hard to find.
Yes, that’s a document that’s referenced by many AMD manuals but no public copy seems to have ever existed. I’m sure someone, somewhere has it… I don’t know why they’re so exotic when, as you say, the earlier K5/K6 and the later K8 BIOS writer guides weren’t secret.
I suspect those three AMD processors all used the same core, so it makes sense they’d all set that undocumented CPUID bit.
I had an urge to search for some kind of CPUID errata and found Athlon 64 Errata 108: https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/revision-guides/25759.pdf
CPUID Instruction May Return Incorrect Model Number In Some Processors
While this only affects DH7-CG Newcastle (130nm 512 KiB Cache L2) on Socket 754, I view it as some kind of precedent that they can screw up even with static values.
Is there some kind of consistency about whenever all Athlon Thunderbird/Duron Spitfire CPUID are the only ones where Bit 18 is set, or is just some of them? When I was searching for C1C3F9FF (No APIC) or C1C3FBFF (APIC) I found pretty much later Athlon XPs or Durons. With Bit 18 set is far easier:
C1C7F9FF (No APIC + Bit 18): Two Durons
https://bbs.archlinux.org/viewtopic.php?pid=88070#p88070
This Duron https://www.linux.com/news/detecting-hardware-outside-box/
C1C7FBFF (APIC + Bit 18): This Athlon
https://www.linuxquestions.org/questions/slackware-14/irq-10-disabled-after-kernel-switch-412906/
Given the fact than it was reserved or otherwise unused by Software, who could have noticed that it was wrong to begin with? It appears to be mostly inconsequential.
Also, about Bit 19 for ECC memory. Socket A RAM support was entirely Chipset dependent, it predates Integrated Memory Controller and I don’t think that neither Intel or AMD could attempt to do feature segmentation of something that they didn’t even indirectly controlled. Can it be some other kind of ECC like Cache ECC? Intel had Pentiums 2 with and without Cache ECC depending on sSpec and maybe AMD had something similar for Slot A since both used external Cache L2.
https://www.vogons.org/viewtopic.php?t=96627
The mystery CPUID bit set to 1 could have easily flown under the radar. The only reason I noticed it is that I have my own CPUID utility which flags unknown CPUID bits. So far it only happened when I was missing some piece of documentation, but this bit 18 looks to be a genuine completely undocumented CPUID bit. The extra bit would not cause trouble in practice because if no one looks at it, its value doesn’t matter.
If I had to guess, it was set in all Thunderbird Athlons, at least certain revisions. The Morgan Duron is derived from the Thunderbird, so it’s not surprising it’d also set the same bit.
Re bit 19, AMD’s own documents called it ECC (and later “MP Capable”). It was intended for Athlon MP, and yes it was chipset dependent… but guess what, there was only a single chipset (AMD 760MP/MPX) for the Athlon MP. I am 99% sure it was really meant to indicate ECC support in the CPU (the CPU had to be capable of generating ECC bits during write cycles) and it would presumably inform the BIOS whether ECC could be enabled or not (assuming the RAM was ECC capable). I have a separate post about this bit now up because there’s whole another mess surrounding bit 19 in the extended CPUID capabilities.
I updated sandpile.org to reflect that
Bit 19 = MP-capable
Bit 18 = ECC-capable
Those were two distinct capabilities.
[sources: K7 µcode + K8 XOS-based public simulator published in 2000 + I worked at AMD back then]
That’s fascinating, thank you! So how did AMD’s documentation get so confused as to say that bit 19 was ECC capability? Seen e.g. in Publication #20734 Rev. 3.13, December 2005.
Actually, did bit 19 (eventually?) mean MP-capable as well as ECC-capable? Because if the datasheets aren’t a lie, regular Athlon XPs were not ECC capable, only Athlon MPs were. So there ought to have been some way for firmware to tell.
So, this just ended up being a case of public documentation being wrong and nobody noticing until 20+ years than they are separate features with separate Bit flags? How did BIOSes deal with this?
I assume the public K8 simulator is SimNow!
https://old.hotchips.org/wp-content/uploads/hc_archives/hc16/2_Mon/15_HC16_Sess4_Pres1_bw.pdf
The SimNow! version presented in Rob Bedichek’s 2004 presentation is the post-XOS re-write, aka v3.5 and v4.6.
The original XOS-based version was available via x86-64.org, in 2000 and again in 2001, aka v1.1 (2000) and v1.1 (2001). [yes, same revisions… but different binaries]
Interestingly enough, there was another x86-64 bringup vehicle back in 2000, called SoftHammer. That was a Transmeta Crusoe with a custom x86-64 capable CMS, a project also lead by Rob Bedichek. This was never available in public though.
Alas, unlike the simulators, the K7 BIOS guides (#21656, #21922, and #24141) never came out of NDA. And the quality of AMD’s public documentation… well… there were (and still are) good and bad times, as people come and go over the years…
Writing good technical documentation is hard. It’s even harder when plans change (products/features are cancelled) or when there are bugs. See for example the “curious” documentation of how to interpret Intel’s SEP CPUID bit on PPro models. Or that bit 19 in AMD’s CPUID documentation.
It’s a real shame about those K7 BIOS guides. They are referenced all over the place in the public AMD documents but… not available.
The SoftHammer sounds fascinating, and very logical given what Transmeta was doing.
Suddently, AMD has documents that are as elusive as the 486 errata and directly comparable to the legendary Intel Pentium Appendix H, which was never found yet mentioned everywhere. Didn’t saw this one coming from this blog post, really.
So after this discovery, if ECC support and MP support were two distinct Bit capabilities, what is the real situation? The next blog post seems to have been written before the revelations here, so there is some info that may be already outdated. In the end, I view a lot of unaswered questions…
To begin with, which Chipsets supports ECC RAM? Do you need an Athlon/Athlon XP with ECC Bit 18 enabled to work with ECC RAM? Can this be tested via Software to see if ECC is enabled or functional? Was an Athlon XP with ECC an actual intended case for a Uniprocessor Workstation, or you were forced to use an Athlon MP even in Single Socket just for ECC?
Is there any bridge that can be modded to deal with ECC Bit 18 like there is with MP Bit 19? Can it be modified at runtime (Like, BIOS setting Bit 18 to 1 if it detect and uses ECC RAM, 0 if not)?
Does any of this conflicts with BIOS Processor model string from the next blog post? Apparently not, since MP Bit 19 was always used for MP branding, even when it was called ECC Bit. At least that is what I understood.
Yes, the other blog post was written based on published AMD documentation. It is known that bit 19 is called “MP-capable” in most AMD CPUID specs but is also referred to as “ECC” in some AMD documents. Bit 18 was never documented so there should not be production firmware looking for it, though you never know.
BTW there is another “missing” document, AMD Athlon™ and AMD Duron™ System Bus Specification, order# 21902. And one more, AMD Athlon™ Processor-Based Motherboard Design Guide order# 24363. The exact titles may have changed but the order number did not.
ECC support was documented in the AMD-751 System Controller (AMD-750 chipset northbridge) datasheet in 1999. Athlon (Slot A only back then) datasheets from that time also talk about ECC support. The Athlon system bus definitely supported ECC. Maybe Slot A Athlons actually all supported ECC? ECC is also mentioned in Athlon Model 4 (Thunderbird) datasheets.
However, the Model 6 aka Athlon XP (Palomino) datasheet from 2001 does not mention ECC or the SCHECK pins at all. Needless to say, Athlon XP only existed in OPGA packaging, not slot cartridge. Athlon MP (also 2001) datasheet basically kept all the ECC/SCHECK documentation that was in the older Athlon datasheets. At that point, AMD may have decided that ECC and MP support are one and the same thing and used bit 19 for it.
So maybe it went like this — Slot A Athlons all had ECC support. That went for Model 4 aka Thunderbird as well. There were definitely Slot A boards with ECC memory support, e.g. ASUS K7M.
But for Socket 462, AMD decided to drop ECC from “normal” CPUs and make ECC exclusive to Althlon MP. So they needed a CPUID bit to indicate ECC support, and Thunderbirds had it set because they did in fact support ECC. Maybe AMD decided to not document the ECC bit because they didn’t want to make it too obvious that it was dropped from Athlon XP. ECC support probably made a difference to very few people.
One (single) Socket 462 board which claims to support ECC is Gigabyte 7DXR+/7DX+ and possibly other GA-7DX series boards (all with AMD 762 northbridge). Whether it actually worked who knows, and I can’t find anything in the board manuals about ECC support based on the CPU.
Pingback: Learn Something Old Every Day, Part XIX: Athlon XP May Be Athlon MP | OS/2 Museum
I’m not entirely convinced on the purpose of the ECC Bit thing. As I said before, the Memory Controller was in the Chipset thus RAM support should be completely independent of the Processor. Did the Processor had any need to know of RAM being ECC, or required a side channel to coordinate ECC with the Northbridge? Isn’t there any other possibility? For example, ECC support for the FSB (Front Side Bus) itself? It will make more sense.
I tried to google around Hardware forums for ECC support on Athlon Thunderbird and found this:
https://hothardware.com/reviews/unlocking–overclocking-the-amd-slot-a-thunderbird
Support for 8-bit ECC for data bus integrity
That line is also present on Athlon XP feature list, as seen on this Thoroughbred review:
https://hothardware.com/reviews/amds-athlon-xp-2200-processor
And also here:
https://www.abit.com.tw/english/techterm/cpu.htm
They nest ECC as a System Bus (FSB) feature.
Besides FSB ECC, the other possibility that I already mentioned is ECC for the Cache L2. Intel did that with the Pentium 2:
https://www.intel.com/pressroom/archive/releases/1997/SP071497.HTM
Since Slot A was conceptually similar with the external Cache L2 I assume than there could be ECC and non ECC versions. Thunderbird was also used in Slot A (With no external Cache L2 at all), where you couldn’t have a non-ECC version given its integrated nature.
Also, I remembered that the canceled Athlon Mustang was a Thunderbird with a huge 1 MiB Cache, predating AXP Palomino: https://web.archive.org/web/20060314044028/http://www.chip-architect.com/mw.pdf
Speculation was that this was the missing Model 5, and Model 9 was supposed to be Duron Appaloosa. Since Applebread is a castrated Thoroughbred I assume that Appaloosa had physically 64 KiB Cache L2.
I also found something interesing about a Duron MP, check on the other article…
Yes, ECC could be implemented purely in the memory controller, and only protect the path between the MC and RAM. AMD clearly had provisions to ECC-protect the entire path all the way to/from the CPU. Someone has to generate the ECC bits when writing, and check them when reading. If the CPU generates write cycles, it also has to generate the ECC bits, otherwise the write couldn’t be fully protected by ECC. Same for reads, the CPU can check that the ECC is valid on read. See SCHECK signals in K7 datasheets, it’s right there.
And yes, there was a separate ECC control for the L2 cache. But that was for traffic between the L2 cache and the CPU core. We’re talking about ECC for traffic on the FSB.
I wonder if some thought was to note if ECC did correct data on reads, and set a bit similar to a page fault but not actually generate an exception interrupt but rather just gather the data, and whenever the OS runs in it’s supervisor/kernel/ring 0 state it could do something with that data, like gather it and present it to the user, and set alarms if it happens too often / more often than normal / whatnot?
Speaking of mystery CPUID bits… Wikipedia picked up the existence of the SEM feature flag – so I decided to add details for that one too. Enjoy! 🙂