"Jeremy Jackson" <[EMAIL PROTECTED]> writes:

> Well I decided to take a run at it (ie the NDA brick wall :)
> 
> Can someone comment on the legal issues related to the following?

A couple of us can't comment much because we know exactly what to do.
But if you haven't signed an NDA with AMD it shouldn't be a problem.

> It seems that the utils/k7msr/fixmsr.c has 6 ram combos...
> 
> if you disregard MSRs 0xc001_0000 thru 0xc001_0007 which
> are documented in 22007.pdf (from AMD.com) as performance counters/ event
> selection and thus are not applicable and vary by themselves,
> 
> 
> AND do a diff on the various combos...
> 
> you will see that only 0xc001_001a changes, and only with
> total memory, not the bank configuration.

The Athlon system bus has seperate transactions for accessign RAM and
memory mapped I/O, and the Athlon defaults to memory mapped I/O.  The
AMD76[12] docs go into this.

> 
> The following pattern can be seen:
> 
> Total RAM       MSR setting(low half)
> 
> 128MiB     0x07800000
> 256MiB     0x0f800000
> 384MiB     0x17800000
> 512MiB     0x1f800000
> 
> SO this MSR appears to be the top of memory (to be cached),
> in bytes, less 8 MiB.  Was the board this was done on using UMA (AGP using host
> memory for frame buffer?)
> 
> 
> or is this some kind of address mask... either way, I propose that this can be
> set using a formula, and the others can be set using just one register dump.

This sounds like a reasonable, start.

> And now for my next feat of prestidigitation (pun intended)...
> (when I get a board)
> 
> it should be illuminating to do a scanmsr from linuxbios *without* doing the
> fixmsr.c init... diffing with the original BIOS MSR dump.
> 
> 
> any that *don't* change could be removed from struct in fixmsr.c, so some of the
> registers being blindly dumped/restored could be pruned,as well as the ones that
> are known from non-NDA docs:
> 
Sounds like a good strategy.  You get to take the lead on this, as the
rest of us that know what is going on seem to have signed the NDA...

Ah cool.  I hadn't thought about K6 documentation...

> 0xc000_0080 - 21329g.pdf (K6) EFER - Extended Featured Enable Register
> 0xc000_0081 -  ditto          STAR - SYSCALL Target Address Register
> 0xc000_0082 -                 WHCR - Write Handling Control Register
> 
> 0xc000_0085 - UWCCR (K6) - 21329.pdf
> 0xc000_0086 - EPMR (PowerNow) 24267a.pdf
> 0xc000_0087 - PSOR (K6) - 21329.pdf
> 0xc000_0088 - PFIR (K6) - 21329.pdf
> 0xc000_0089 - L2AAR (K6-III) - 21329.pdf
> 
> 0xc001_0000     PerfEvtSel[3:0] 22007.pdf
> -
> 0xc001_0003
> 
> 0xc001_0004     PerfCtr[3:0] 22007.pdf
> -
> 0xc001_0007
> 
> 0xc001_0010[15] SysECCEn - 24081.pdf 

(Also see section 1.2... SYS_CONFIG settings it isn't clear which MSR
they are talking about...)
 
> 0xc001_001a     MAGIC cache enable top of memory setting
> 0xc001_001b     CLK_Ctl - Clock Control - 24309.pdf


Eric

Reply via email to