[Intel/Atom/Airmont] Missing IMC of Pentium(R) CPU N3700

[cyring]

@svmlegacy Hello,

Refering to the Wiki page, corefreq-cli -m does not output the IMC data.

EDIT: Branch develop_Airmont is an attempt to decode Airmont IMC using the SLM/Bay Trail SoC decoder.

Please feel free to test and post the IMC output of this branch.

[svmlegacy]

Unfortunately this laptop is a family member's and is not currently available for testing... I'll dig through some of my untested laptops and see if any are Airmont/Braswell like this one.

The laptop which created the dump is an Asus X540SA, with the memory directly attached to the motherboard.

[cyring]

Unfortunately this laptop is a family member's and is not currently available for testing... I'll dig through some of my untested laptops and see if any are Airmont/Braswell like this one.

The laptop which created the dump is an Asus X540SA, with the memory directly attached to the motherboard.

Will it help if I'm proving a bootable ISO including the Airmont branch ?

[svmlegacy]

I was able to recreate the issue with a Airmont/Cherry Trail CPU, and the new branch seems to be outputting something. Please check for coherency. BIOS does not provide current speeds or timings.

Master Branch
Develop Branch

[cyring]

I was able to recreate the issue with a Airmont/Cherry Trail CPU, and the new branch seems to be outputting something. Please check for coherency. BIOS does not provide current speeds or timings.

Master Branch Develop Branch

Thank you for those results.

Good you have this Cherry Trail platform, according to ark there are things to solve:

• Burst frequency (ratio)
• Virtualization Technology (VT): not implemented.

and to fix:

• DIMM size and geometry
  (Kernel reports about 2GB)
  (DIMM size and geometry are hard-coded, datasheet vol-2 is missing)
• Core temperature
  ( 54C while CPU is idling or a cooler issue b/c 10° less with N3700)

[cyring]

@svmlegacy Hello,

Can you please test those registers ?

## MSR_IA32_PLATFORM_ID
rdmsr -ax 0x00000017

## MSR_THERM2_CTL
rdmsr -ax 0x0000019d

## MSR_MISC_PWR_MGMT
rdmsr -ax 0x000001aa

## MSR_IA32_THERM_CONTROL
rdmsr -ax 0x0000019a

## MSR_TURBO_RATIO_LIMIT
rdmsr -ax 0x000001ad

[svmlegacy]

I'm not surprised if the core is hotter, the box is passively cooled and warm to touch, while the Braswell chip was actively cooled.

Burst appears to be working, as I do catch the CPU above 1.44 GHz in /proc/cpuinfo

Also:

## MSR_IA32_PLATFORM_ID
rdmsr -ax 0x00000017

f090041752
f090041752
f090041449
f090041449

## MSR_THERM2_CTL
rdmsr -ax 0x0000019d

62d
62d
62d
62d

## MSR_MISC_PWR_MGMT
rdmsr -ax 0x000001aa

rdmsr: CPU 0 cannot read MSR 0x000001aa

## MSR_IA32_THERM_CONTROL
rdmsr -ax 0x0000019a

0
0
0
0

## MSR_TURBO_RATIO_LIMIT
rdmsr -ax 0x000001ad

0
0
0
0

[cyring]

Burst appears to be working, as I do catch the CPU above 1.44 GHz in /proc/cpuinfo

Thank you, branch is committed 69e370a to allow those MSR.
Perhaps Burst frequency ratio will show up ?
EDIT Listed among the Turbo Boost ratios of Processor window

[cyring]

|- Clock Modulation                                             ODCM   <Disable>
   |- DutyCycle                                                        [  0.00%]

Clock Modulation is now also permitted. You should be able to apply a DutyCycle percent with no processor crash.
Please let me know if it is working safely ?
It is supposed to lower frequency based on the selected percent.

[cyring]

Platform codename

Airmont is the common CPUID 06_4C

Stepping 3 is assigned to both Atom x5-Z8300 and Pentium N3700

Fortunately we can manage a brands table in CoreFreq driver to split in two platform codenames: Cherry Trail and Braswell

Code enhancement should also concern the PCI Host bridge id 8086:2280 which differs only in revision number (rev 22) vs (rev 21) according to lspci.

So far driver has no code to query the revision and I wonder if it's worth the effort to provide the true platform codename in the IMC output, rather than a common codename ?

[svmlegacy]

Just a quick update on this - I'm currently experimenting to get this system stable in Linux. I've been suffering random crashes, especially when the iGPU is loaded. Once it's stable I'll be able to test the duty cycle modulation. I haven't seen it lock up in a tty console, but I can't be certain it is stable. I may have to try alternative distro's to get it, or older kernels.

On platform codename - To me Cherry Trail and Braswell are effectively the same silicon, just with different target markets. I don't think it's worth the effort in splitting the codename without fully understanding if the Host Bridge revisions within each codename are unique. There seems to be some cherry trail chips with rev 20, for example)

[cyring]

Found these frequency and turbo ratios, and voltage VID registers in kernel.
Apparently undocumented in SDM.

#define MSR_ATOM_CORE_RATIOS 0x0000066a
#define MSR_ATOM_CORE_VIDS 0x0000066b
#define MSR_ATOM_CORE_TURBO_RATIOS 0x0000066c
#define MSR_ATOM_CORE_TURBO_VIDS 0x0000066d

Can you please rdmsr these four MSR ?

[svmlegacy]

I seem to be having a stretch of stability after setting a max c-state of 1, similar to Bay Trail. See this: https://bugzilla.kernel.org/show_bug.cgi?id=109051

#define [MSR_ATOM_CORE_RATIOS](https://elixir.bootlin.com/linux/latest/C/ident/MSR_ATOM_CORE_RATIOS) 0x0000066a

# rdmsr -ax 0x0000066a
120602
120602
120602
120602


#define [MSR_ATOM_CORE_VIDS](https://elixir.bootlin.com/linux/latest/C/ident/MSR_ATOM_CORE_VIDS) 0x0000066b

# rdmsr -ax 0x0000066b
442d2d
442d2d
442d2d
442d2d

#define [MSR_ATOM_CORE_TURBO_RATIOS](https://elixir.bootlin.com/linux/latest/C/ident/MSR_ATOM_CORE_TURBO_RATIOS) 0x0000066c

# rdmsr -ax 0x0000066c
14141717
14141717
14141717
14141717

#define [MSR_ATOM_CORE_TURBO_VIDS](https://elixir.bootlin.com/linux/latest/C/ident/MSR_ATOM_CORE_TURBO_VIDS) 0x0000066d

# rdmsr -ax 0x0000066d
49495252
49495252
49495252
49495252

[cyring]

I seem to be having a stretch of stability after setting a max c-state of 1, similar to Bay Trail. See this: https://bugzilla.kernel.org/show_bug.cgi?id=109051

Well done!
In the past I investigated a Silvermont/Bay_Trail crash, issue happened late after resuming from S3.