[coreboot] Use the constant TSC for AMD Family 10h–15h processors?

Paul Menzel paulepanter at users.sourceforge.net
Tue May 14 15:37:04 CEST 2013


Am Dienstag, den 14.05.2013, 11:03 +0200 schrieb Paul Menzel:
> Am Montag, den 13.05.2013, 09:04 +0200 schrieb Paul Menzel:
> > Am Sonntag, den 12.05.2013, 15:40 +0200 schrieb Peter Stuge:
> > > Paul Menzel wrote:
> > > > do you know if the timer mentioned in the BIOS and Kernel Developer’s
> > > > Guide (BKGD) for the AMD Family 14h processors [1]
> > > > 
> > > >         2.11.4 BIOS Timer
> > > >         
> > > >         The root complex implements a 32-bit microsecond timer (see
> > > >         D0F0xE4_x0130_80F0 and D0F0xE4_x0130_80F1) that the BIOS can use
> > > >         to accurately time wait operations between initialization steps.
> > > >         To ensure that BIOS waits a minimum number of microseconds
> > > >         between steps BIOS should always wait for one microsecond more
> > > >         than the required minimum wait time.
> > > > 
> > > > could be used for implementing `tsc_freq_mhz()` as done for Intel
> > > > Haswell processors?
> > > 
> > > Isn't that quite clear from the text that you quoted?
> > 
> > Probably, yes. As this area is new to me, I prefer to ask and get
> > confirmation to be sure.
> 
> It looks like it is not the same. The BIOS Timer above is more to fit
> Aaron’s commit.
> 
>         commit c46cc6f149c42653344d6e9f3656a4212fc46cef
>         Author: Aaron Durbin <adurbin at chromium.org>
>         Date:   Mon Apr 29 16:57:10 2013 -0500
> 
>             haswell: 24MHz monotonic time implementation
> 
>             Haswell ULT devices have a 24MHz package-level counter. Use
>             this counter to provide a timer_monotonic_get()
>         implementation.
> 
>             Reviewed-on: http://review.coreboot.org/3153
> 
> But the problem is, that the register is part of the PCI config space(?)
> and the Root Complex/PCI stuff is not yet available in ramstage?
> 
>         +#include <stdint.h>
>         +#include <pci_ops.h>
>         +#include <timer.h>
>         +
>         +static struct monotonic_counter {
>         +       int initialized;
>         +       struct mono_time time;
>         +       uint32_t last_value;
>         +} mono_counter;
>         +
>         +static inline uint32_t read_counter_msr(void)
>         +{
>         +       /* D0F0xE4_x0130_80F0 BIOS Timer
>         +        *
>         +        * This field increments once every microsecond when the timer is
>         +        * enabled. The counter rolls over and continues counting when it
>         +        * reaches FFFF_FFFFh. A write to this register causes the counter
>         +        * to reset and begin counting from the value written. */
>         +       pci_write_config32(CI_DEV(0, 0, 0), 0xe4, 0x013080F0);

The above was supposed to be `PCI_DEV`. I had not squashed the commits
yet.

>         +
>         +       return pci_read_config32(PCI_DEV(0, 0, 0), 0xe4);
>         +}
>         +
>         +void timer_monotonic_get(struct mono_time *mt)
>         +{
>         +       uint32_t current_tick;
>         +       uint32_t usecs_elapsed;
>         +
>         +       if (!mono_counter.initialized) {
>         +               mono_counter.last_value = read_counter_msr();
>         +               mono_counter.initialized = 1;
>         +       }
>         +
>         +       current_tick = read_counter_msr();
>         +       usecs_elapsed = current_tick - mono_counter.last_value;
>         +
>         +       /* Update current time and tick values only if a full tick occurred. */
>         +       if (usecs_elapsed) {
>         +               mono_time_add_usecs(&mono_counter.time, usecs_elapsed);
>         +               mono_counter.last_value = current_tick;
>         +       }
>         +
>         +       /* Save result. */
>         +       *mt = mono_counter.time;
>         +}
> 
> This results in the following hang.
> 
>         00.000: <00>
>         00.456: 
>         00.456: 
>         00.456: coreboot-4.0-4160-g41f456b-dirty Tue May 14 00:28:53 CEST 2013 starting...
>         00.456: BSP Family_Model: 00500f10 
>         00.457: cpu_init_detectedx = 00000000 
>         00.457: agesawrapper_amdinitmmio passed.
>         00.458: agesawrapper_amdinitreset passed.
>         00.461: agesawrapper_amdinitearly BSP Family_Model: 00500f10 
>         00.486: cpu_init_detectedx = 00000001 
>         00.486: agesawrapper_amdinitmmio passed.
>         00.487: agesawrapper_amdinitreset passed.
>         00.491: agesawrapper_amdinitearly passed.
>         00.627: agesawrapper_amdinitpost passed.
>         00.753: agesawrapper_amdinitenv passed.
>         00.767: Loading image.
>         00.768: CBFS: loading stage fallback/coreboot_ram @ 0x200000 (1343544 bytes), entry @ 0x200000
>         00.873: Jumping to image.
>         00.874: coreboot-4.0-4160-g41f456b-dirty Tue May 14 00:28:53 CEST 2013 booting...
>         00.874: get_pbus: dev is NULL!

In #coreboor, CareBear\ suggested that I have to access the PCI register
in a different way. Suggestions very much welcomed.

> > > > Suggestions, if this should be shared and how the files should be
> > > > named are appreciated.
> > > 
> > > Yes and no. We can do this for coreboot's own code for AMD platforms,
> > > but it obviously does not make much sense to hack this into AGESA if
> > > there are not already provisions for it.
> > 
> > I totally forgot about that. There is coreboot code for the K8 and
> > Family 10h processors, if I am not mistaken.
> > 
> > AGESA is there for Family 10h to 15h processors.
> > 
> > > Since AGESA is the only thing relevant going forward the question
> > > is what AGESA needs, timing-wise. Have you checked?
> > 
> > Only a little. Having an ASRock E350M1, I am looking into the Family 14h
> > family. There seems to be no TSC stuff in `src/cpu/amd`. But the AMD
> > vendor code seems to have it.
> > 
> >     $ git grep -i tsc src/vendorcode/amd/agesa/f14/
> > 
> > `AGESA.h` has a struct `MEM_DATA_STRUCT` where the frequency is put
> > into.
> > 
> >         $ nl -ba src/vendorcode/amd/agesa/f14/AGESA.h | grep -B 40 -A 5
> >         TSC
> >         […]
> >           1700	///
> >           1701	/// Contains all data relevant to Memory Initialization.
> >           1702	///
> >           1703	typedef struct _MEM_DATA_STRUCT {
> >           1704	  IN AMD_CONFIG_PARAMS StdHeader;             ///< Standard configuration header
> >           1705	
> >           1706	  IN MEM_PARAMETER_STRUCT *ParameterListPtr;  ///< List of input Parameters
> >           1707	
> >           1708	  OUT MEM_FUNCTION_STRUCT FunctionList;       ///< List of function Pointers
> >           1709	
> >           1710	  IN OUT AGESA_STATUS (*GetPlatformCfg[MAX_PLATFORM_TYPES]) (struct _MEM_DATA_STRUCT *MemData, UINT8 SocketID, CH_DEF_STRUCT *CurrentChannel); ///< look-up platform info
> >           1711	
> >           1712	  IN OUT BOOLEAN (*ErrorHandling)(struct _DIE_STRUCT *MCTPtr, UINT8 DCT, UINT16 ChipSelMask, AMD_CONFIG_PARAMS *StdHeader); ///< Error Handling
> >           1713	
> >           1714	
> >           1715	  OUT MEM_SOCKET_STRUCT SocketList[MAX_SOCKETS_SUPPORTED];  ///< Socket list for memory code.
> >           1716	                                   ///< SocketList is a shortcut for IBVs to retrieve training
> >           1717	                                   ///< and timing data for each channel indexed by socket/channel,
> >           1718	                                   ///< eliminating their need to parse die/dct/channel etc.
> >           1719	                                   ///< It contains pointers to the populated data structures for
> >           1720	                                   ///< each channel and skips the channel structures that are
> >           1721	                                   ///< unpopulated. In the case of channels sharing the same DCT,
> >           1722	                                   ///< the pTimings pointers will point to the same DCT Timing data.
> >           1723	
> >           1724	  OUT DIE_STRUCT *DiesPerSystem;  ///< Pointed to an array of DIE_STRUCTs
> >           1725	  OUT UINT8      DieCount;        ///< Number of MCTs in the system.
> >           1726	
> >           1727	  IN SPD_DEF_STRUCT *SpdDataStructure;              ///< Pointer to SPD Data structure
> >           1728	
> >           1729	  IN OUT  struct _PLATFORM_CONFIGURATION   *PlatFormConfig;    ///< Platform profile/build option config structure
> >           1730	
> >           1731	  IN OUT BOOLEAN IsFlowControlSupported;    ///< Indicates if flow control is supported
> >           1732	
> >           1733	  OUT UINT32 TscRate;             ///< The rate at which the TSC increments in megahertz.
> >           1734	
> >           1735	} MEM_DATA_STRUCT;
> >         […]
> > 
> > With
> > 
> >         $ git grep -i tsc src/vendorcode/amd/agesa/f14/ | grep -i rate
> >         […]
> >         src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14Utilities.c: *  @CpuServiceMethod{::F_CPU_GET_TSC_RATE}.
> >         src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14Utilities.c:F14GetTscRate (
> >         src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14Utilities.h:F14GetTscRate (
> >         […]
> > 
> > I found `F14GetTscRate`.
> >         
> >         $ nl -ba src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14Utilities.c
> >         […]
> >            213	/*---------------------------------------------------------------------------------------*/
> >            214	/**
> >            215	 *  Determines the rate at which the executing core's time stamp counter is
> >            216	 *  incrementing.
> >            217	 *
> >            218	 *  @CpuServiceMethod{::F_CPU_GET_TSC_RATE}.
> >            219	 *
> >            220	 *  @param[in]   FamilySpecificServices   The current Family Specific Services.
> >            221	 *  @param[out]  FrequencyInMHz           TSC actual frequency.
> >            222	 *  @param[in]   StdHeader                Header for library and services.
> >            223	 *
> >            224	 *  @return      The most severe status of all called services
> >            225	 */
> >            226	AGESA_STATUS
> >            227	F14GetTscRate (
> >            228	  IN       CPU_SPECIFIC_SERVICES *FamilySpecificServices,
> >            229	     OUT   UINT32 *FrequencyInMHz,
> >            230	  IN       AMD_CONFIG_PARAMS *StdHeader
> >            231	  )
> >            232	{
> >            233	  UINT64 MsrReg;
> >            234	  PSTATE_CPU_FAMILY_SERVICES  *FamilyServices;
> >            235	
> >            236	  FamilyServices = NULL;
> >            237	  GetFeatureServicesOfCurrentCore (&PstateFamilyServiceTable, (const VOID **)&FamilyServices, StdHeader);
> >            238	  ASSERT (FamilyServices != NULL);
> >            239	
> >            240	  LibAmdMsrRead (0xC0010015, &MsrReg, StdHeader);
> >            241	  if ((MsrReg & 0x01000000) != 0) {
> >            242	    return (FamilyServices->GetPstateFrequency (FamilyServices, 0, FrequencyInMHz, StdHeader));
> >            243	  } else {
> >            244	    return (FamilySpecificServices->GetCurrentNbFrequency (FamilySpecificServices, FrequencyInMHz, StdHeader));
> >            245	  }
> >            246	}
> >         […]
> > 
> > So there is the infrastructure already. The only problem is how to hook
> > this up into coreboot. Create `src/cpu/amd/agesa/tsc_delay.c` and
> > somehow call the AGESA `F14GetTscRate()` from it?
> 
> There are also other timers in the processor cores.
> 
>         2.4.5 Timers
> 
>         Each core includes the following timers. These timers do not
>         vary in frequency regardless of the current P-state or C-state.
>         • MSR0000_0010 [Time Stamp Counter (TSC)]; the TSC increments at
>         the rate specified by MSRC001_0015[TscFreqSel].
>         • The APIC timer (APIC380 and APIC390), which decrements at a
>         rate of 2x CLKIN.
> 
> It looks like that is what AGESA uses and which might be there from the
> “beginning”.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20130514/bf33d5cd/attachment.sig>


More information about the coreboot mailing list