Closed antermin closed 1 year ago
One thing I noticed is that the memory information seems bugged:
Bus Rate 5000 MT/s Bus Speed 4999 MT/s
but:
Bus Rate 4000 MT/s Bus Speed 4004 MT/s
, there is no way that 7567U is performs worse than N3150)Yes, Braswell IMC is definitely a work in progress. I used to have Contributors. Since, no answer. I'm glade you came here to help.
I've to prepare another CoreFreq source archive to let you test all Braswell specifics. Won't be long.
Now that develop
can be loaded, would you refresh the CLI output to check first about the architecture name ?
Now that
develop
can be loaded, would you refresh the CLI output to check first about the architecture name ?
The first comment has been edited to the refreshed CLI output, it is now showing Airmont/Braswell
.
Now that
develop
can be loaded, would you refresh the CLI output to check first about the architecture name ?The first comment has been edited to the refreshed CLI output, it is now showing
Airmont/Braswell
.
Looks better, thanks.
I can't tell why A1_AssetTagNum0
is encoded into SMBIOS rather than 16KTF1G64HZ-1G6E1
but true the second stick is missing.
Edit: Aren't those two 800 MHz
aka 1600 MT/s
DDR3 DIMMs ?
Bus
needs indeed more work; to find a setting register rather than default DMI link.
For reference:
# dmidecode -t 17
# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x000C, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8 GB
Form Factor: DIMM
Set: None
Locator: A1_DIMM0
Bank Locator: A1_BANK0
Type: DDR3
Type Detail: Unknown
Speed: 1600 MT/s
Manufacturer: Micron
Serial Number: 0CBC140F
Asset Tag: A1_AssetTagNum0
Part Number: 16KTF1G64HZ-1G6E1
Rank: 2
Configured Memory Speed: 1600 MT/s
Minimum Voltage: 1.35 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.35 V
Handle 0x000E, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8 GB
Form Factor: DIMM
Set: None
Locator: A1_DIMM1
Bank Locator: A1_BANK1
Type: DDR3
Type Detail: Unknown
Speed: 1600 MT/s
Manufacturer: Micron
Serial Number: 0D9A066B
Asset Tag: A1_AssetTagNum1
Part Number: 16KTF1G64HZ-1G6E1
Rank: 2
Configured Memory Speed: 1600 MT/s
Minimum Voltage: 1.35 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.35 V
Thanks.
1600 MT/s
is confirmed.
A1_AssetTagNum
appears like a buggy BIOS. Nothing I can do from those SMBIOS fields.
Thanks.
1600 MT/s
is confirmed.A1_AssetTagNum
appears like a buggy BIOS. Nothing I can do from those SMBIOS fields.
@antermin
DMI_ENTRY_MEM_DEVICE
seems to de-synchronize past manufacturer_id
field
https://github.com/cyring/CoreFreq/blob/07ea6d41153852866ccb6d6287abc9b6ed699b73/corefreqk.h#L1370
I'm comparing my SMBIOS_Entries
parser with dmidecode.c
code but don't find a SMBIOS exception, neither in latest DMTF specification DSP0134_3.6.0.pdf
One thing I noticed is that the memory information seems bugged:
I have 2x 16KTF1G64HZ-1G6E1 installed, but:
- Instead of showing the part number, it shows "A1_AssetTagNum0".
- It also only shows 1 module and the information for another module (channel 1) is missing.
I'm finding my mistake among the Registers addresses I should decode the Airmont IMC from.
Using the Silvermont registers appears to provide some Timings but I have been lucky and I have no guarantee Timings are those you are reading in BIOS ?
I now have to program a dedicated Airmont IMC decoder and I need to know if your processor is still available for testing code ?
Meanwhile, I don't find the datasheet volume 2
EDIT but Airmont is supposed to be a die shrink of Silvermont. Does it mean I can apply the same IMC decoder ? The decoder programmed for Silvermont/Celeron N2930
Yes, I still have the processor for testing.
Yes, I still have the processor for testing.
Great, thank you. Could you tell me if tbe found timings are correct ?
The BIOS shows no timings information, so I used mt86plus_6.01_64.iso.zip
and it shows 11-11-11-28
.
The BIOS shows no timings information, so I used
mt86plus_6.01_64.iso.zip
and it shows11-11-11-28
.
According to its source code, it seems to show SPD but not the configured IMC by BIOS.
Looking specs of 16KTF1G64HZ-1G6E1
, I'm finding CL11.
CoreFreq has decoded CL9 and remaining timings look coherent with DDR3, I still don't know which one is true ?
Not sure whether the following is useful, but anyway, this is what I get for another PC (unknown brand) with N3050:
Only a single M471B5173QH0-YK0
RAM module is installed.
BIOS also shows no timings information.
Is it possible you take screenshots of IMC Timings using Windows tools ? CPU-Z, OCCT, MemTweak,...
The memtest86 maintained version is pulling Timings from IMC registers.
The Airmont/Braswel decoder is not explicitly mentioned but I presume it works the same as in CoreFreq, using Silvermont/BayTrail IMC decoder:
{ 0xFFFF, 0x000A, "BayTrail IMC","", 0, poll_fsb_ct, poll_timings_ct, setup_nothing, poll_nothing}, // same as CedarTrail IMC
Function poll_timings_ct
shows the same Registers addresses and bits used to decode the IMC:
memtest86
static void poll_timings_ct(void)
CoreFreq https://github.com/cyring/CoreFreq/blob/b7038862f0ca08e2a9a405173567a48b2ddea715/corefreqk.c#L5354
I'm wondering what Timings you will read from this memtest86 version ?
Tried CPU-Z on both PCs but it showed no IMC timings :
Tried CPU-Z on both PCs but it showed no IMC timings :
Unbelievable! CPU-Z is giving up.
Perhaps HWiNFO ?
This time it finally printed some information:
This time it finally printed some information:
So
11-11-11-28
are definitely confirmed as the configured IMC timing. I can't rely on the Silvermont decoder, although Airmont is a die shrink. New development is required. Unfortunately I have not found the Intel Registers datasheet volume 2 ref 332093. But HWINFO knows those Registers and maybe among its text output we may find the Memory MCH base address to decode from.
Are the following links of any help?
The above links are archives from Wayback Machine, but the one captured at a later date weirdly has an earlier date and different document number suffix. I am not sure about the differences in the actual content.
The above links are archives from Wayback Machine, but the one captured at a later date weirdly has an earlier date and different document number suffix. I am not sure about the differences in the actual content.
Well done. Thank you.
Can you pull, build and run the latest commits from the develop
branch ?
The impacted timings (Z8000
) are the followings:
tCL, tRCD, tRP, tRAS, tRRD, tRFC, tREFI
tRTPr, tWTPr, B2B, tCCD, tFAW, tCWL,
tsrRdTWr, tsrWrTRd,
tdrRdTRd, tdrRdTWr,
tdrWrTRd, tdrWrTWr,
CMD_Rate, tXS, tXP
Please provide the output of corefreq-cli -M
On N3050:
$ corefreq-cli -M
Airmont [2280]
Controller #0 Single Channel
Bus Rate 5000 MT/s Bus Speed 4999 MT/s DDR3 Speed 800 MHz
Cha CL RCD RP RAS RRD RFC WR RTPr WTPr FAW B2B CWL CMD REFI
#0 11 11 11 14 5 384 0 7 24 24 0 8 2T 0
ddWR drWR srWR ddRW drRW srRW ddRR drRR srRR ddWW drWW srWW CKE ECC
#0 0 7 19 0 10 10 0 7 0 0 6 0 0 0
DIMM Geometry for channel #0
Slot Bank Rank Rows Columns Memory Size (MB)
#0 8 1 65536 1024 4096 A1_AssetTagNum0
tRAS: Row Activation Period. The minimal delay, in DRAM clocks, between ACT command and PRE command to same bank. At least equal to tRCD + tCWL + tCCD + tWR 0h -14 DRAM Clocks ...
According to specs, we just have to add 14
https://github.com/cyring/CoreFreq/blob/c8af79fee64acfbaffcfb67b6343f177a78ed573/corefreqd.c#L3268
TIMING(mc, cha).tRAS = \
RO(Proc)->Uncore.MC[mc].SLM.DTR1.Z8000.tRAS + 14;
I have fixed tWTPr
where formula is now value + 15
B2B
was changed into multiple tCCD
conditions
tWWDR
aka drWW
deals with the reserved values 0
and 1
Both Airmont and Silvermont: DRMC register at offset 0xB
is added to attempt decoding tCKE
You can now pull and try commit 0f70cde61624aa0c8f161eae564009747eb795a5
corefreq-cli -M
output is welcomed.
$ corefreq-cli -M
Airmont [2280]
Controller #0 Single Channel
Bus Rate 5000 MT/s Bus Speed 4998 MT/s DDR3 Speed 800 MHz
Cha CL RCD RP RAS RRD RFC WR RTPr WTPr FAW B2B CWL CMD REFI
#0 11 11 11 28 5 384 0 7 25 24 4 8 2T 0
ddWR drWR srWR ddRW drRW srRW ddRR drRR srRR ddWW drWW srWW CKE ECC
#0 0 7 19 0 10 10 0 7 0 0 6 0 0 0
DIMM Geometry for channel #0
Slot Bank Rank Rows Columns Memory Size (MB)
#0 8 1 65536 1024 4096 A1_AssetTagNum0
Hello,
Can you build and run this attached version which will print debug data in the kernel log.
When loading corefreqk.ko
, log will contain many lines like below
(D-Unit)MCR:00[00000000]
(P-Unit)BIOS:00[00000000]
Remark: all values are hexadecimal
Edit: This dump has to be made on your system with two installed DIMMs. Please also provide the output of corefreq-cli -M
I was expecting to find Timings of other B
Registers. To my understanding, those of other DIMM or channel; but as shown below, the dump values are same as their default value in datasheet. It would mean B
Registers are not updated since Processor reset and I can not make use of them.
(D-Unit)MCR:10[00000000]
(D-Unit)MCR:11[43402108]
(D-Unit)MCR:12[08c90320]
(D-Unit)MCR:13[00020508]
(D-Unit)MCR:14[06106108]
(D-Unit)MCR:15[8c063322]
For your information, currently, in dual channel mode, the Airmont decoder is just duplicating the first channel.
Using your two DIMMs setup, is it possible that you remove one DIMM and run the Registers dump again ?
I would like to find some meaningful changes among bits to declare when two modules are populated or not.
This time I only used one DIMM in that PC. If I put the module on channel B, it refuses to boot, so I put it on Channel A.
Here is the diff of single vs dual channels
(D-Unit)MCR:20[50030101] | (D-Unit)MCR:20[50030001]
(D-Unit)MCR:21[0000003a] | (D-Unit)MCR:21[000040a0]
(P-Unit)BIOS:06[418f0010] | (P-Unit)BIOS:06[318f0010]
My understanding is that bit 30 of register BIOS CONFIG is specifying Dual Channel but also says implicitly two vs one DIMM
https://github.com/cyring/CoreFreq/blob/0f70cde61624aa0c8f161eae564009747eb795a5/intel_reg.h#L2860
DUAL_CH_DIS
is set then platform is a Single channel with only one DIMM populated.In both cases your PC has only 2 DIMM slots. Is that true ?
Yeah, that PC has only 2 DIMM slots.
P.S. I also found that ECC
(error correction code?) in the corefreq-cli -M
output has changed when only 1 DIMM is populated.
Yeah, that PC has only 2 DIMM slots.
P.S. I also found that
ECC
(error correction code?) in thecorefreq-cli -M
output has changed when only 1 DIMM is populated.
In (P-Unit)BIOS:06[318f0010]
, bit 29 REG_EFF_ECC_EN
of BIOS_CONFIG register is set when dual channels is enabled whereas in single mode, register value is 0x418f0010
, and bit is clear.
ECC aggregation is happening in Daemon at these lines: https://github.com/cyring/CoreFreq/blob/0f70cde61624aa0c8f161eae564009747eb795a5/corefreqd.c#L3395
Aggregation was ok with Silvermont but apparently it is not OK with Airmont.
@antermin Hello,
You can now pull the new develop
version 1.95.3
to check the IMC improvements in corefreq-cli -M
Does the latest code work with the IMC ? Should we close the issue ?
Sorry for the delay, here is the latest output:
Airmont [2280]
Controller #0 Dual Channel
Bus Rate 3200 MT/s Bus Speed 3199 MT/s DDR3 Speed 1600 MHz
Cha CL RCD RP RAS RRD RFC WR RTPr WTPr FAW B2B CWL CMD REFI
#0 11 11 11 28 5 384 0 7 25 24 4 8 2T 3120
#1 11 11 11 28 5 384 0 7 25 24 4 8 2T 3120
ddWR drWR srWR ddRW drRW srRW ddRR drRR srRR ddWW drWW srWW CKE ECC
#0 0 6 19 0 10 10 0 7 0 0 6 0 0 0
#1 0 6 19 0 10 10 0 7 0 0 6 0 0 0
DIMM Geometry for channel #0
Slot Bank Rank Rows Columns Memory Size (MB)
#0 8 2 65536 1024 8192 A1_AssetTagNum0
DIMM Geometry for channel #1
Slot Bank Rank Rows Columns Memory Size (MB)
#0 8 2 65536 1024 8192 A1_AssetTagNum0
And for xmrig:
$ ./xmrig --dry-run
[2023-02-14 21:01:34.601] hwloc auto configuration for algorithm "cn-heavy/0" failed.
* ABOUT XMRig/6.19.0 gcc/9.3.0
* LIBS libuv/1.44.2 OpenSSL/1.1.1s hwloc/2.9.0
* HUGE PAGES supported
* 1GB PAGES unavailable
* CPU Intel(R) Celeron(R) CPU N3150 @ 1.60GHz (1) 64-bit AES
L2:2.0 MB L3:0.0 MB 4C/4T NUMA:1
* MEMORY 0.6/15.3 GB (4%)
A1_DIMM0: 8 GB DDR3 @ 1600 MHz A1_AssetTagNum0
A1_DIMM1: 8 GB DDR3 @ 1600 MHz A1_AssetTagNum1
* MOTHERBOARD ASRock - N3150-NUC
* DONATE 1%
* ASSEMBLY auto:intel
* POOL #1 donate.v2.xmrig.com:3333 algo auto
* COMMANDS hashrate, pause, resume, results, connection
[2023-02-14 21:01:34.611] config OK
IMC now looks better.
Only A1_AssetTagNum0
remains and xmrig
shows to be also affected whereas dmidecode
was not.
In the future, other BIOS may reveal where the SMBIOS encoding issue is ?
I guess we're OK with this release to close the original issue.
Controller #0 Dual Channel
Bus Rate 3200 MT/s Bus Speed 3199 MT/s DDR3 Speed 1600 MHz
Not sure from the above: are your DDR3 set at 800
or 1600
MHz ?
According to BIOS, both RAM modules are running at DDR3-1600.
(Based on Wikipedia's table, it probably means 800MHz and 1600 MT/s)
According to BIOS, both RAM modules are running at DDR3-1600.
(Based on Wikipedia's table, it probably means 800MHz and 1600 MT/s)
Can you please try the last fix and post the output of corefreq-cli -M
?
Airmont [2280]
Controller #0 Dual Channel
Bus Rate 1600 MT/s Bus Speed 1599 MT/s DDR3 Speed 800 MHz
Cha CL RCD RP RAS RRD RFC WR RTPr WTPr FAW B2B CWL CMD REFI
#0 11 11 11 28 5 384 0 7 25 24 4 8 2T 1560
#1 11 11 11 28 5 384 0 7 25 24 4 8 2T 1560
ddWR drWR srWR ddRW drRW srRW ddRR drRR srRR ddWW drWW srWW CKE ECC
#0 0 6 19 0 10 10 0 7 0 0 6 0 0 0
#1 0 6 19 0 10 10 0 7 0 0 6 0 0 0
DIMM Geometry for channel #0
Slot Bank Rank Rows Columns Memory Size (MB)
#0 8 2 65536 1024 8192 A1_AssetTagNum0
DIMM Geometry for channel #1
Slot Bank Rank Rows Columns Memory Size (MB)
#0 8 2 65536 1024 8192 A1_AssetTagNum0
@antermin Except the unsolved A1_AssetTagNum0
and missing timings in datasheet, the overall IMC decoder looks better.
Using
1e405b4
: