68EC060 rev 1 reported incorrectly

[Stefan Skotte]

Hi Keir,

I have a rev 1, EC60 which gets reported as a full 060.

I would suggest you displayed both parts of the PCR so you can identify the cpu's correctly instead of interpreting a certain revision as full or EC/LC.

Something like this:

68<EC/LC>060,

Example: 68EC060, rev1

Code can be improved further to determine EC or LC:

EC = no mmu, no fpu
LC = mmu, no fpu
RC = mmu, fpu

I can find the code to determine mmu and fpu if you like.

[Keir Fraser]

If you have some reference code I'll plug it in.

[Stefan Skotte]

I'm just at work here, so here's some pseudo code for you - hope it makes sense.

check_cpu_model_and_revision (pcr = 04300601)
{
  if cpu_model == 6
  then
       // get revision - always present
       revision =  pcr[5] // index 5 holds the revision (04300[6]01)

       // full version
       if pcr[3] == 0  // index 3 holds the sub type ($043[0])
       then
           // full 060
           model = "RC"
                        
       // LC (mmu, NO fpu)
       // or
       // EC (NO mmu, NO fpu)
       else
           model = "LC" // LC until proven otherwise (or we could do actual mmu+fpu checks..)
           // check for mmu - if none found we have an EC
           movec #1,tc
           catch exception ...
           if has_mmu == 1 
           then
                model = "EC"

           end if
        end if

  end if

  // concat and return text representation, examples : "680RC060rev6", "680EC060rev5"
  cpu_model_and_revision = "MC68" + model + "060" + "rev" + revision

  return cpu_model_and_revision
}

[Keir Fraser]

Any idea what the exception would be on the invalid move to tc? Probably an illegal?

[Keir Fraser]

Anyway thanks I will cross check in the 68060 UM and cook up a patch.

[Keir Fraser]

And since you have an EC, you can test that code path 😊

[Stefan Skotte]

Yes, I can test it 👍 I believe throws the same illegal instruction like you do in the existing code (saw it swiftly in some old init code for the linux kernel) , so you just catch it as you already do. tir. 9. jun. 2020 20.52 skrev Keir Fraser <[e-mail]>:

…

And since you have an EC, you can test that code path 😊 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7LGMOKZY4TKBZAPEXOVTRV2AFVANCNFSM4NV7DAAQ> .

[Keir Fraser]

Looking at the 68060 UM, I see a couple of issues:

1. Bit 0 of the TCR is unused (Section 4.1.2: Translation Control Register)
2. Writes to the TCR on EC060 (The E- and P- bits) do not fault (Section 1.1.2.2: MC68EC060: Instruction Differences).

Quite apart from this, enabling the MMU is a dangerous operation if it does exist, since we have not actually properly configured it, and it affects execution immediately.

[Keir Fraser]

I believe the Rev 3 = EC, Rev 4 = LC, Rev 5+ = RC is correct. Revs 1 and 2 can be RC/LC/EC, and I don't believe there is any supported software method for distinguishing EC from LC. I would be happy to be proved wrong. Perhaps there is some specific implementation detail of the Rev1 and Rev2 masks that makes this possible?

As it stands, best I can offer is to look at the PCR to determine "68LC/EC060" for Rev1 and Rev2.

EDIT: I have asked on EAB: https://eab.abime.net/showthread.php?p=1407245

[Keir Fraser]

Looking further, there are loads of EC/LC out there that have working MMU and FPU. I may just distinguish between "68060" and "68xC060". I may continue to further distinguish Rev 3 (EC) and Rev 4 (LC) if my understanding of those is actually correct.