Skip to content

Instantly share code, notes, and snippets.

@bobpaul

bobpaul/gist:dd232ce7527137e46137ebfe09713d01

Created February 24, 2025 20:12
Show Gist options
  • Save bobpaul/dd232ce7527137e46137ebfe09713d01 to your computer and use it in GitHub Desktop.
Save bobpaul/dd232ce7527137e46137ebfe09713d01 to your computer and use it in GitHub Desktop.
Download ZIP
No WOF table on Talos II Lite, CPU serial shows 02AA883 in OpenBMC
Raw
gistfile1.txt
27.49755|ISTEP 14. 7 - proc_exit_cache_contained
27.58023|ISTEP 15. 1 - host_build_stop_image
30.16315|================================================
30.16564|Error reported by fapi2 (0x3300) EID 0x90001A51
30.16812| No WOF table match found
30.16812| ModuleId 0x10 fapi2::MOD_FAPI2_PLAT_PARSE_WOF_TABLES
30.16813| ReasonCode 0x332d fapi2::RC_WOF_TABLE_NOT_FOUND
30.16814| UserData1 Number of cores : 0x0004000200000064
30.16815| UserData2 WOF Power Mode (1=Nominal, 2=Turbo) : 0x00000bb800000012
30.16816|------------------------------------------------
30.16816| Callout type : Procedure Callout
30.16817| Procedure : EPUB_PRC_HB_CODE
30.16817| Priority : SRCI_PRIORITY_HIGH
30.16818|------------------------------------------------
30.16819| Callout type : Hardware Callout
30.18817| Target : Physical:/Sys0/Node0/Proc0
30.18818| Deconfig State : NO_DECONFIG
30.18819| GARD Error Type : GARD_NULL
30.18819| Priority : SRCI_PRIORITY_MED
30.18820|------------------------------------------------
30.18820| Hostboot Build ID:
30.18821|================================================
30.40824|ISTEP 15. 2 - proc_set_pba_homer_bar
30.50670|ISTEP 15. 3 - host_establish_ex_chiplet
30.54983|ISTEP 15. 4 - host_start_stop_engine
30.60036|ISTEP 16. 1 - host_activate_master
31.85287|ISTEP 16. 2 - host_activate_slave_cores
31.99750|ISTEP 16. 3 - host_secure_rng
32.07063|ISTEP 16. 4 - mss_scrub
32.26319|ISTEP 16. 5 - host_load_io_ppe
32.31894|ISTEP 16. 6 - host_ipl_complete
38.10466|ISTEP 18.11 - proc_tod_setup
38.23805|ISTEP 18.12 - proc_tod_init
38.24082|ISTEP 20. 1 - host_load_payload
38.74968|ISTEP 20. 2 - host_load_hdat
39.67560|ISTEP 21. 1 - host_runtime_setup
40.27835|================================================
40.27835|Error reported by fapi2 (0x3300) EID 0x90001A80
40.27836| No WOF table match found
40.27837| ModuleId 0x10 fapi2::MOD_FAPI2_PLAT_PARSE_WOF_TABLES
40.27837| ReasonCode 0x332d fapi2::RC_WOF_TABLE_NOT_FOUND
40.27838| UserData1 Number of cores : 0x0004000200000064
40.27839| UserData2 WOF Power Mode (1=Nominal, 2=Turbo) : 0x00000bb800000012
40.27840|------------------------------------------------
40.27841| Callout type : Procedure Callout
40.27841| Procedure : EPUB_PRC_HB_CODE
40.27842| Priority : SRCI_PRIORITY_HIGH
40.27842|------------------------------------------------
40.27843| Callout type : Hardware Callout
40.27844| Target : Physical:/Sys0/Node0/Proc0
40.27845| Deconfig State : NO_DECONFIG
40.27846| GARD Error Type : GARD_NULL
40.27846| Priority : SRCI_PRIORITY_MED
40.27847|------------------------------------------------
40.27847| Hostboot Build ID:
40.27848|================================================
43.62913|htmgt|OCCs are now running in ACTIVE state
45.37411|ISTEP 21. 2 - host_verify_hdat
45.46018|ISTEP 21. 3 - host_start_payload
@bobpaul
Copy link
Author

bobpaul commented Feb 24, 2025

/proc/cpuinfo shows:

processor	: 15
cpu		: POWER9 (raw), altivec supported
clock		: 2066.000000MHz
revision	: 2.1 (pvr 004e 1201)

timebase	: 512000000
platform	: PowerNV
model		: T2P9S01 REV 1.01
machine		: PowerNV T2P9S01 REV 1.01
firmware	: OPAL
MMU		: Radix

@bobpaul
Copy link
Author

bobpaul commented Feb 24, 2025 •
edited
Loading

Found some old discussion on IRC that will probably be useful

[2024-03-17T15:42:26.376Z] markos_ the 02CY227 need the WOF tables included in the PNOR to operate correctly.
[2024-03-17T15:43:09.959Z] Note that I have the same CPU, but I've added a customized WOF table in the blackbird to reduce the total TDP so the VRMs don't overheat
[2024-03-17T15:43:52.623Z] <markos_> interesting, so far I haven't noticed any overheating
[2024-03-17T15:44:00.643Z] <markos_> they are at around 48C
[2024-03-17T15:44:04.190Z] If you are using a blackbird and don't include the tables, it may also work fine, but it won't boost, so likely wouldn't cause as much overheating
[2024-03-17T15:44:10.104Z] <markos_> no it's a T2
[2024-03-17T15:44:12.813Z] ah, ok
[2024-03-17T15:44:18.988Z] VRMs are fine there
[2024-03-17T15:44:51.725Z] <markos_> I would hope so, I'd hate for my system to overheat :)
[2024-03-17T15:47:37.004Z] If you haven't done so though, you might want to include WOF tables for the CPU, should run a bit faster with it
[2024-03-17T15:48:08.579Z] <markos_> have any pointers on how to do this?
[2024-03-17T15:48:24.536Z] <markos_> is it in the raptor wiki?
[2024-03-17T15:50:50.531Z] I ended up building my own firmware to do it. There's a way to do with just updating the right partition, but I didn't look into generating just that partition (wanted the latest fw at the time)
[2024-03-17T15:51:25.326Z] Wiki can help with building the PNOR
[2024-03-17T15:52:14.720Z] I added a table into blackbird by updating the xml repo here: open-power/blackbird-xml@master...meklort:blackbird-xml:master
[2024-03-17T15:52:39.282Z] <markos_> so to understand correctly, what does including the WOF tables solve?
[2024-03-17T15:52:59.002Z] <markos_> on the T2 esp.
[2024-03-17T15:53:07.985Z] workload optimized frequency - enables proper frequency turbo
[2024-03-17T15:53:09.601Z] <markos_> if I don't do it will I have a problem?
[2024-03-17T15:53:28.826Z] <markos_> this is mostly a compile farm system
[2024-03-17T15:54:43.450Z] Main thing is performance / efficiency. If you're using the latest PNOR from raptor, you have the checkstop bug fixed, so at this point I believ ethe only downside is it'll run slower and may not be as efficient. I haven't quantified the delta on my machine though.
[2024-03-17T15:55:14.400Z] <markos_> I'm not using the latest PNOR from Raptor, for that matter
[2024-03-17T15:55:37.076Z] <markos_> thinking about it, but it will have to happen during a weekend and I have other things to fix for the next few weekends already :)
[2024-03-17T15:56:13.570Z] If you're using an older PNOR from raptor, it may have stability issues. If you built your own recently, should be fine.
[2024-03-17T15:59:10.176Z] <markos_> I think I upgraded to 2.0 but it was time ago
[2024-03-17T15:59:28.658Z] <markos_> firmware version: open-power-talos-v1.20-983-gf6295c9c
[2024-03-17T15:59:42.057Z] <markos_> and then another entry: 2.7.0-dev-571-g67efd9872
[2024-03-17T15:59:50.381Z] <markos_> the latter is for the BMC

@bobpaul
Copy link
Author

bobpaul commented Feb 24, 2025

This forum thread looks useful. In that case he bought an unsupported CPU from ebay and had to produce his own WOF tables.

@bobpaul
Copy link
Author

bobpaul commented Feb 28, 2025

I found the code in hostboot that prints the error:

        //Check for no match
        else if(l_ent == l_img->entryCount)
        {
            FAPI_ERR("No WOF table match found");
            /*@
            * @errortype
            * @moduleid          fapi2::MOD_FAPI2_PLAT_PARSE_WOF_TABLES
            * @reasoncode        fapi2::RC_WOF_TABLE_NOT_FOUND
            * @userdata1[00:15]  Number of cores
            * @userdata1[16:31]  WOF Power Mode (1=Nominal, 2=Turbo)
            * @userdata1[32:63]  Socket power
            * @userdata2[00:31]  Sort frequency
            * @userdata2[32:63]  Number of WOF tables checked
            * @devdesc           No WOF table match found
            * @custdesc          Firmware Error or unsupported part
            */
            l_errl = new ERRORLOG::ErrlEntry(
                            ERRORLOG::ERRL_SEV_UNRECOVERABLE,
                            fapi2::MOD_FAPI2_PLAT_PARSE_WOF_TABLES,
                            fapi2::RC_WOF_TABLE_NOT_FOUND,
                            TWO_UINT16_ONE_UINT32_TO_UINT64(
                                    l_numCores,
                                    l_mode,
                                    l_socketPower),
                            TWO_UINT32_TO_UINT64(
                                    l_sortFreq,
                                    l_headers.size()));

Mine is getting:

 40.27838|  UserData1  Number of cores : 0x0004000200000064
 40.27839|  UserData2  WOF Power Mode (1=Nominal, 2=Turbo) : 0x00000bb8 00000012

which means 4 core, mode 2, socket power 100
turbo: 3000Hz, headers.size(): 18

There's only 2 WOF tables for 4 core CPUS, both 90w:
WOF_V7_3_3_SFORZA_4_90_2700_NM.csv and WOF_V7_3_3_SFORZA_4_90_3200_TM.csv

Question: are these the same CPU (one is the table for nominal and the other is for turbo)? Or are these for 2 different CPUs? And what the hell does the "WOF_V7_3_3" part mean?

Maybe I need to look at the code that parses the CSVs and builds the tables...

@bobpaul
Copy link
Author

bobpaul commented Mar 3, 2025

I found the code in hostboot that prints the error:

        //Check for no match
        else if(l_ent == l_img->entryCount)
        {
            FAPI_ERR("No WOF table match found");
            /*@
            * @errortype
            * @moduleid          fapi2::MOD_FAPI2_PLAT_PARSE_WOF_TABLES
            * @reasoncode        fapi2::RC_WOF_TABLE_NOT_FOUND
            * @userdata1[00:15]  Number of cores
            * @userdata1[16:31]  WOF Power Mode (1=Nominal, 2=Turbo)
            * @userdata1[32:63]  Socket power
            * @userdata2[00:31]  Sort frequency
            * @userdata2[32:63]  Number of WOF tables checked
            * @devdesc           No WOF table match found
            * @custdesc          Firmware Error or unsupported part
            */
            l_errl = new ERRORLOG::ErrlEntry(
                            ERRORLOG::ERRL_SEV_UNRECOVERABLE,
                            fapi2::MOD_FAPI2_PLAT_PARSE_WOF_TABLES,
                            fapi2::RC_WOF_TABLE_NOT_FOUND,
                            TWO_UINT16_ONE_UINT32_TO_UINT64(
                                    l_numCores,
                                    l_mode,
                                    l_socketPower),
                            TWO_UINT32_TO_UINT64(
                                    l_sortFreq,
                                    l_headers.size()));

Mine is getting:

 40.27838|  UserData1  Number of cores : 0x0004000200000064
 40.27839|  UserData2  WOF Power Mode (1=Nominal, 2=Turbo) : 0x00000bb8 00000012

which means 4 core, mode 2, socket power 100
Mode turbo, "sortFrequency: 3000Hz", headers.size(): 18

There's only 2 WOF tables for 4 core CPUS, both 90w:
WOF_V7_3_3_SFORZA_4_90_2700_NM.csv and WOF_V7_3_3_SFORZA_4_90_3200_TM.csv

The only 2 known production 4-core Sforza CPUs are the CP9M01 (02CY297) DD2.2 at 3.2GHz base, 3.8GHz turbo, 90w TDP and the CP9M31 (02CY650) DD2.3 at 3.2GHz base, 3.8GHz turbo, 90w TDP. Neither are 2700GHz, and the 2700GHz WOF_V7_3_3_SFORZA_4_90_2700_NM.csv still shows turbo boosting to 3.8GHz.

So I guess I'm not sure why some tables are listed as NM (normal mode) and some as TM (turbo mode) when all of the wof tables implement turbo boosting...

Some graphs of the two WOF tables

I built a firmware with set CONSOLE_OUTPUT_TRACE (in openpower/configs/hostboot/talos.config which causes all FAPI_INF() messages to show up on console/vga as well. Then using obmc-console-client and a terminal with a very large scrollback buffer. That generated this line showing what my CPU is identified as.

 92.17796|FAPI|plat_wof_access.C: WOF table search: Cores 4 SocketPower 0x64 (100) NestFreq 0x74A (3000) SortFreq 0xBB8 Mode 0x2

It also shows all of the WOF tables that were found in the firmware:

 92.19795|FAPI|plat_wof_access.C: WOFDATA lid is 2324896 bytes
 93.45345|FAPI|plat_wof_access.C: WOF Image: Magic 0x57544948 Version 1 Entries 18 Offset 0x10
 93.47053|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 0 SectionTableOffset 0xA0 SectionTableSize 129152 Version 1 Mode 0 Cores 16 SocketPower 0x82 NestFreq 0x74B NomFreq 0x898
 93.47058|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 1 SectionTableOffset 0x1F920 SectionTableSize 129152 Version 1 Mode 0 Cores 16 SocketPower 0x82 NestFreq 0x74B NomFreq 0x8FC
 93.47064|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 2 SectionTableOffset 0x3F1A0 SectionTableSize 129152 Version 1 Mode 0 Cores 18 SocketPower 0x82 NestFreq 0x74B NomFreq 0x898
 93.47069|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 3 SectionTableOffset 0x5EA20 SectionTableSize 129152 Version 1 Mode 0 Cores 18 SocketPower 0x82 NestFreq 0x74B NomFreq 0x8CA
 93.47074|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 4 SectionTableOffset 0x7E2A0 SectionTableSize 129152 Version 1 Mode 0 Cores 18 SocketPower 0xBE NestFreq 0x74B NomFreq 0x8BA
 93.47080|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 5 SectionTableOffset 0x9DB20 SectionTableSize 129152 Version 1 Mode 0 Cores 18 SocketPower 0xBE NestFreq 0x74B NomFreq 0xAF0
 93.47086|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 6 SectionTableOffset 0xBD3A0 SectionTableSize 129152 Version 1 Mode 0 Cores 20 SocketPower 0xA0 NestFreq 0x74B NomFreq 0x8CA
 93.47091|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 7 SectionTableOffset 0xDCC20 SectionTableSize 129152 Version 1 Mode 0 Cores 20 SocketPower 0xA0 NestFreq 0x74B NomFreq 0x960
 93.47096|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 8 SectionTableOffset 0xFC4A0 SectionTableSize 129152 Version 1 Mode 0 Cores 22 SocketPower 0xA0 NestFreq 0x74B NomFreq 0x898
 93.47102|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 9 SectionTableOffset 0x11BD20 SectionTableSize 129152 Version 1 Mode 0 Cores 22 SocketPower 0xA0 NestFreq 0x74B NomFreq 0x8CA
 93.47107|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 10 SectionTableOffset 0x13B5A0 SectionTableSize 129152 Version 1 Mode 0 Cores 22 SocketPower 0xBE NestFreq 0x74B NomFreq 0x856
 93.47113|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 11 SectionTableOffset 0x15AE20 SectionTableSize 129152 Version 1 Mode 0 Cores 22 SocketPower 0xBE NestFreq 0x74B NomFreq 0xABE
 93.47121|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 12 SectionTableOffset 0x17A6A0 SectionTableSize 129152 Version 1 Mode 0 Cores 4 SocketPower 0x5A NestFreq 0x74B NomFreq 0xA8C
 93.47126|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 13 SectionTableOffset 0x199F20 SectionTableSize 129152 Version 1 Mode 0 Cores 4 SocketPower 0x5A NestFreq 0x74B NomFreq 0xC80
 93.47131|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 14 SectionTableOffset 0x1B97A0 SectionTableSize 129152 Version 1 Mode 0 Cores 8 SocketPower 0xA0 NestFreq 0x74B NomFreq 0xBB8
 93.47137|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 15 SectionTableOffset 0x1D9020 SectionTableSize 129152 Version 1 Mode 0 Cores 8 SocketPower 0xA0 NestFreq 0x74B NomFreq 0xDAC
 93.47142|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 16 SectionTableOffset 0x1F88A0 SectionTableSize 129152 Version 1 Mode 0 Cores 16 SocketPower 0xBE NestFreq 0x74A NomFreq 0x8CA
 93.47148|FAPI|plat_wof_access.C: WOF table fields SectionTableEntry 17 SectionTableOffset 0x218120 SectionTableSize 129152 Version 1 Mode 0 Cores 16 SocketPower 0xBE NestFreq 0x74A NomFreq 0xB54
 93.47149|FAPI_I|plat_wof_access.C: No WOF table match found

Interestingly, this all shows "NomFreq" and Mode 0, even though half of the CSV files are TM and half are NM.

Question: are these the same CPU (one is the table for nominal and the other is for turbo)? Or are these for 2 different CPUs? And what the hell does the "WOF_V7_3_3" part mean?

Maybe I need to look at the code that parses the CSVs and builds the tables...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment