* [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart @ 2020-09-28 9:46 Shunsuke Nakamura 2020-09-29 10:46 ` Karel Zak 0 siblings, 1 reply; 12+ messages in thread From: Shunsuke Nakamura @ 2020-09-28 9:46 UTC (permalink / raw) To: util-linux; +Cc: Shunsuke Nakamura, Shunsuke Nakamura Add an entry for FUJITSU aarch64 part A64FX. I tested it on the FX1000. Signed-off-by: Shunsuke Nakamura <nakamura.shun@fujitsu.com> --- sys-utils/lscpu-arm.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sys-utils/lscpu-arm.c b/sys-utils/lscpu-arm.c index 270866191..c9997d062 100644 --- a/sys-utils/lscpu-arm.c +++ b/sys-utils/lscpu-arm.c @@ -171,6 +171,11 @@ static const struct id_part intel_part[] = { { -1, "unknown" }, }; +static const struct id_part fujitsu_part[] = { + { 0x001, "A64FX" }, + { -1, "unknown" }, +}; + static const struct id_part hisi_part[] = { { 0xd01, "Kunpeng-920" }, /* aka tsv110 */ { -1, "unknown" }, @@ -191,6 +196,7 @@ static const struct hw_impl hw_implementer[] = { { 0x42, brcm_part, "Broadcom" }, { 0x43, cavium_part, "Cavium" }, { 0x44, dec_part, "DEC" }, + { 0x46, fujitsu_part, "FUJITSU" }, { 0x48, hisi_part, "HiSilicon" }, { 0x4e, nvidia_part, "Nvidia" }, { 0x50, apm_part, "APM" }, -- 2.25.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-09-28 9:46 [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart Shunsuke Nakamura @ 2020-09-29 10:46 ` Karel Zak 2020-09-30 14:44 ` Jeffrey Bastian 0 siblings, 1 reply; 12+ messages in thread From: Karel Zak @ 2020-09-29 10:46 UTC (permalink / raw) To: Shunsuke Nakamura; +Cc: util-linux, Shunsuke Nakamura On Mon, Sep 28, 2020 at 06:46:14PM +0900, Shunsuke Nakamura wrote: > sys-utils/lscpu-arm.c | 6 ++++++ > 1 file changed, 6 insertions(+) Applied, thanks. -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-09-29 10:46 ` Karel Zak @ 2020-09-30 14:44 ` Jeffrey Bastian 2020-09-30 17:40 ` Karel Zak 0 siblings, 1 reply; 12+ messages in thread From: Jeffrey Bastian @ 2020-09-30 14:44 UTC (permalink / raw) To: Karel Zak; +Cc: Shunsuke Nakamura, util-linux, Shunsuke Nakamura On Tue, Sep 29, 2020 at 12:46:27PM +0200, Karel Zak wrote: >On Mon, Sep 28, 2020 at 06:46:14PM +0900, Shunsuke Nakamura wrote: >> sys-utils/lscpu-arm.c | 6 ++++++ >> 1 file changed, 6 insertions(+) > >Applied, thanks. With the other ARM patch applied ("use SMBIOS tables on ARM for lscpu"), the output changes on an FX700 system: [root@fujitsu-fx700 ~]# ./lscpu | grep -e Vendor -e Model -e Stepping Vendor ID: FUJITSU Model: 0 Model name: 461F0010 Stepping: 0x1 The values here come from the SMBIOS Type 4 record: [root@fujitsu-fx700 ~]# strings /sys/firmware/dmi/entries/4-0/raw CPU1 FUJITSU 461F0010 8K083MH14 This FX700 system has firmware revision 1.4.0 (Jun 17 2020). -- Jeff Bastian Kernel QE - Hardware Enablement Red Hat ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-09-30 14:44 ` Jeffrey Bastian @ 2020-09-30 17:40 ` Karel Zak 2020-09-30 18:49 ` Masayoshi Mizuma 0 siblings, 1 reply; 12+ messages in thread From: Karel Zak @ 2020-09-30 17:40 UTC (permalink / raw) To: Jeffrey Bastian; +Cc: Shunsuke Nakamura, util-linux, Shunsuke Nakamura On Wed, Sep 30, 2020 at 09:44:09AM -0500, Jeffrey Bastian wrote: > On Tue, Sep 29, 2020 at 12:46:27PM +0200, Karel Zak wrote: > > On Mon, Sep 28, 2020 at 06:46:14PM +0900, Shunsuke Nakamura wrote: > > > sys-utils/lscpu-arm.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > Applied, thanks. > > > With the other ARM patch applied ("use SMBIOS tables on ARM for lscpu"), > the output changes on an FX700 system: > > [root@fujitsu-fx700 ~]# ./lscpu | grep -e Vendor -e Model -e Stepping > Vendor ID: FUJITSU > Model: 0 > Model name: 461F0010 > Stepping: 0x1 > > > The values here come from the SMBIOS Type 4 record: > > [root@fujitsu-fx700 ~]# strings /sys/firmware/dmi/entries/4-0/raw > CPU1 > FUJITSU > 461F0010 > 8K083MH14 > > > This FX700 system has firmware revision 1.4.0 (Jun 17 2020). hmm... 461F0010 does not seem user-friendly, "A64FX" seems better. Shunsuke, what about to update the firmware strings? ;-) (as Jeffrey suggested in RH bugzilla) The another possibility is to exclude some vendors and do not use SMBIOS for them (e.g. 0x46 for Fujitsu), but from my point of view SMBIOS based solution is more elegant and ready for new CPU types than in-lscpu hard coded tables. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-09-30 17:40 ` Karel Zak @ 2020-09-30 18:49 ` Masayoshi Mizuma 2020-09-30 21:53 ` Jeffrey Bastian 0 siblings, 1 reply; 12+ messages in thread From: Masayoshi Mizuma @ 2020-09-30 18:49 UTC (permalink / raw) To: Karel Zak Cc: Jeffrey Bastian, Shunsuke Nakamura, util-linux, Shunsuke Nakamura Hi Jeffrey and Karel, On Wed, Sep 30, 2020 at 07:40:27PM +0200, Karel Zak wrote: > On Wed, Sep 30, 2020 at 09:44:09AM -0500, Jeffrey Bastian wrote: > > On Tue, Sep 29, 2020 at 12:46:27PM +0200, Karel Zak wrote: > > > On Mon, Sep 28, 2020 at 06:46:14PM +0900, Shunsuke Nakamura wrote: > > > > sys-utils/lscpu-arm.c | 6 ++++++ > > > > 1 file changed, 6 insertions(+) > > > > > > Applied, thanks. > > > > > > With the other ARM patch applied ("use SMBIOS tables on ARM for lscpu"), > > the output changes on an FX700 system: > > > > [root@fujitsu-fx700 ~]# ./lscpu | grep -e Vendor -e Model -e Stepping > > Vendor ID: FUJITSU > > Model: 0 > > Model name: 461F0010 > > Stepping: 0x1 > > > > > > The values here come from the SMBIOS Type 4 record: > > > > [root@fujitsu-fx700 ~]# strings /sys/firmware/dmi/entries/4-0/raw > > CPU1 > > FUJITSU > > 461F0010 > > 8K083MH14 > > > > > > This FX700 system has firmware revision 1.4.0 (Jun 17 2020). > > hmm... 461F0010 does not seem user-friendly, "A64FX" seems better. > > Shunsuke, what about to update the firmware strings? ;-) (as Jeffrey > suggested in RH bugzilla) > > The another possibility is to exclude some vendors and do not use > SMBIOS for them (e.g. 0x46 for Fujitsu), but from my point of view > SMBIOS based solution is more elegant and ready for new CPU types than > in-lscpu hard coded tables. According to SMBIOS specification, the description of Processor Version (Type4) is "String number describing the Processor". It shows the version number of the processor, not a model, like as A64FX and Cortex-A72 and so on. So I think we should not use the Processor Version as the modelname... As far as I can see, there's no useful information in SMBIOS to show the modelname, so I suppose we should continue to use id_part structures in lscpu-arm.c. As for Processor Version, how about using lscpu_desc.rversion or adding a new member to lscpu_desc to show the version? Thanks, Masa ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-09-30 18:49 ` Masayoshi Mizuma @ 2020-09-30 21:53 ` Jeffrey Bastian 2020-10-01 3:05 ` Masayoshi Mizuma 0 siblings, 1 reply; 12+ messages in thread From: Jeffrey Bastian @ 2020-09-30 21:53 UTC (permalink / raw) To: Masayoshi Mizuma Cc: Karel Zak, Shunsuke Nakamura, util-linux, Shunsuke Nakamura On Wed, Sep 30, 2020 at 02:49:17PM -0400, Masayoshi Mizuma wrote: >Hi Jeffrey and Karel, > >On Wed, Sep 30, 2020 at 07:40:27PM +0200, Karel Zak wrote: >> On Wed, Sep 30, 2020 at 09:44:09AM -0500, Jeffrey Bastian wrote: >> > On Tue, Sep 29, 2020 at 12:46:27PM +0200, Karel Zak wrote: >> > > On Mon, Sep 28, 2020 at 06:46:14PM +0900, Shunsuke Nakamura wrote: >> > > > sys-utils/lscpu-arm.c | 6 ++++++ >> > > > 1 file changed, 6 insertions(+) >> > > >> > > Applied, thanks. >> > >> > >> > With the other ARM patch applied ("use SMBIOS tables on ARM for lscpu"), >> > the output changes on an FX700 system: >> > >> > [root@fujitsu-fx700 ~]# ./lscpu | grep -e Vendor -e Model -e Stepping >> > Vendor ID: FUJITSU >> > Model: 0 >> > Model name: 461F0010 >> > Stepping: 0x1 >> > >> > >> > The values here come from the SMBIOS Type 4 record: >> > >> > [root@fujitsu-fx700 ~]# strings /sys/firmware/dmi/entries/4-0/raw >> > CPU1 >> > FUJITSU >> > 461F0010 >> > 8K083MH14 >> > >> > >> > This FX700 system has firmware revision 1.4.0 (Jun 17 2020). >> >> hmm... 461F0010 does not seem user-friendly, "A64FX" seems better. >> >> Shunsuke, what about to update the firmware strings? ;-) (as Jeffrey >> suggested in RH bugzilla) >> >> The another possibility is to exclude some vendors and do not use >> SMBIOS for them (e.g. 0x46 for Fujitsu), but from my point of view >> SMBIOS based solution is more elegant and ready for new CPU types than >> in-lscpu hard coded tables. > >According to SMBIOS specification, the description of Processor Version (Type4) >is "String number describing the Processor". It shows the version number of >the processor, not a model, like as A64FX and Cortex-A72 and so on. >So I think we should not use the Processor Version as the modelname... Hello Masa, I think I see your confusion because I was also confused by the wording of the SMBIOS spec. In this case, "String number" means the number of the string appended to the Type 4 record, not a version number of the processor. See section 6.1.3, "Text strings", of the SMBIOS spec (version 3.4.0). For Type 4, there can be up to 6 strings appended to the table: Offset 0x04: Socket Designation Offset 0x07: Processor Manufacturer Offset 0x10: Processor Version Offset 0x20: Serial Number Offset 0x21: Asset Tag Offset 0x22: Part Number Each string is optional. If the byte at one of the above offsets is 0, that means the string is not included. If the byte is non-0, it means refer to the first or second or third (or so on) string appended to the table. It's this non-0 number that the spec calls "String number". Example: A Type 4 record that only defined Processor Manufacturer and Processor Version would therefore look like: Offset 0x04: 0x00 Offset 0x07: 0x01 Offset 0x10: 0x02 Offset 0x20: 0x00 Offset 0x21: 0x00 Offset 0x22: 0x00 The text of each string is free form. Most vendors have chosen to use Processor Manufacturer as the CPU vendor, and Processor Version as a text description of the CPU. Some examples from existing servers (copy/paste from the other thread): [root@hp-m400 ~]# ./lscpu | grep -i -e vendor -e model -e stepping Vendor ID: AppliedMicro Model: 1 Model name: X-Gene Stepping: 0x0 [root@lenovo-hr330a ~]# ./lscpu | grep -i -e vendor -e model -e stepping Vendor ID: Ampere(TM) Model: 2 Model name: eMAG Stepping: 0x3 [root@hpe-apollo-70 ~]# ./lscpu | grep -i -e vendor -e model -e stepping Vendor ID: Cavium Inc. Model: 1 Model name: Cavium ThunderX2(R) CPU CN9980 v2.1 @ 2.20GHz Stepping: 0x1 Therefore, I believe you are free to change the string "461F0010" to "A64FX" in the SMBIOS Type 4 record of the FX700 and FX1000 servers' firmware. -- Jeff Bastian Kernel QE - Hardware Enablement Red Hat ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-09-30 21:53 ` Jeffrey Bastian @ 2020-10-01 3:05 ` Masayoshi Mizuma 2020-10-02 12:15 ` nakamura.shun 0 siblings, 1 reply; 12+ messages in thread From: Masayoshi Mizuma @ 2020-10-01 3:05 UTC (permalink / raw) To: Jeffrey Bastian Cc: Karel Zak, Shunsuke Nakamura, util-linux, Shunsuke Nakamura On Wed, Sep 30, 2020 at 04:53:34PM -0500, Jeffrey Bastian wrote: > On Wed, Sep 30, 2020 at 02:49:17PM -0400, Masayoshi Mizuma wrote: > > Hi Jeffrey and Karel, > > > > On Wed, Sep 30, 2020 at 07:40:27PM +0200, Karel Zak wrote: > > > On Wed, Sep 30, 2020 at 09:44:09AM -0500, Jeffrey Bastian wrote: > > > > On Tue, Sep 29, 2020 at 12:46:27PM +0200, Karel Zak wrote: > > > > > On Mon, Sep 28, 2020 at 06:46:14PM +0900, Shunsuke Nakamura wrote: > > > > > > sys-utils/lscpu-arm.c | 6 ++++++ > > > > > > 1 file changed, 6 insertions(+) > > > > > > > > > > Applied, thanks. > > > > > > > > > > > > With the other ARM patch applied ("use SMBIOS tables on ARM for lscpu"), > > > > the output changes on an FX700 system: > > > > > > > > [root@fujitsu-fx700 ~]# ./lscpu | grep -e Vendor -e Model -e Stepping > > > > Vendor ID: FUJITSU > > > > Model: 0 > > > > Model name: 461F0010 > > > > Stepping: 0x1 > > > > > > > > > > > > The values here come from the SMBIOS Type 4 record: > > > > > > > > [root@fujitsu-fx700 ~]# strings /sys/firmware/dmi/entries/4-0/raw > > > > CPU1 > > > > FUJITSU > > > > 461F0010 > > > > 8K083MH14 > > > > > > > > > > > > This FX700 system has firmware revision 1.4.0 (Jun 17 2020). > > > > > > hmm... 461F0010 does not seem user-friendly, "A64FX" seems better. > > > > > > Shunsuke, what about to update the firmware strings? ;-) (as Jeffrey > > > suggested in RH bugzilla) > > > > > > The another possibility is to exclude some vendors and do not use > > > SMBIOS for them (e.g. 0x46 for Fujitsu), but from my point of view > > > SMBIOS based solution is more elegant and ready for new CPU types than > > > in-lscpu hard coded tables. > > > > According to SMBIOS specification, the description of Processor Version (Type4) > > is "String number describing the Processor". It shows the version number of > > the processor, not a model, like as A64FX and Cortex-A72 and so on. > > So I think we should not use the Processor Version as the modelname... > > Hello Masa, > > I think I see your confusion because I was also confused by the wording > of the SMBIOS spec. In this case, "String number" means the number of > the string appended to the Type 4 record, not a version number of the > processor. > > See section 6.1.3, "Text strings", of the SMBIOS spec (version 3.4.0). > > For Type 4, there can be up to 6 strings appended to the table: > Offset 0x04: Socket Designation > Offset 0x07: Processor Manufacturer > Offset 0x10: Processor Version > Offset 0x20: Serial Number > Offset 0x21: Asset Tag > Offset 0x22: Part Number > > Each string is optional. If the byte at one of the above offsets is 0, > that means the string is not included. If the byte is non-0, it means > refer to the first or second or third (or so on) string appended to the > table. It's this non-0 number that the spec calls "String number". Ohh... thank you for pointing it out! I misunderstood about "String number". > > Example: > > A Type 4 record that only defined Processor Manufacturer and Processor > Version would therefore look like: > Offset 0x04: 0x00 > Offset 0x07: 0x01 > Offset 0x10: 0x02 > Offset 0x20: 0x00 > Offset 0x21: 0x00 > Offset 0x22: 0x00 > > The text of each string is free form. Most vendors have chosen to use > Processor Manufacturer as the CPU vendor, and Processor Version as a > text description of the CPU. > > Some examples from existing servers (copy/paste from the other thread): > > [root@hp-m400 ~]# ./lscpu | grep -i -e vendor -e model -e stepping > Vendor ID: AppliedMicro > Model: 1 > Model name: X-Gene > Stepping: 0x0 > > [root@lenovo-hr330a ~]# ./lscpu | grep -i -e vendor -e model -e stepping > Vendor ID: Ampere(TM) > Model: 2 > Model name: eMAG > Stepping: 0x3 > > [root@hpe-apollo-70 ~]# ./lscpu | grep -i -e vendor -e model -e stepping > Vendor ID: Cavium Inc. > Model: 1 > Model name: Cavium ThunderX2(R) CPU CN9980 v2.1 @ 2.20GHz > Stepping: 0x1 > > > Therefore, I believe you are free to change the string "461F0010" to > "A64FX" in the SMBIOS Type 4 record of the FX700 and FX1000 servers' > firmware. Thanks, I got the most vendors put their CPU model name to Processor Version, however it depends on the vendor, right..? That's because the SMBIOS specification says just "String number describing the Processor", so vendors can put any strings to describe the own processor, like "461F0010"... But I don't have strong opinion about the Processor Version of A64FX, let's wait for Shunsuke's comment. Thanks, Masa ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-10-01 3:05 ` Masayoshi Mizuma @ 2020-10-02 12:15 ` nakamura.shun 2020-10-05 13:35 ` Jeffrey Bastian 0 siblings, 1 reply; 12+ messages in thread From: nakamura.shun @ 2020-10-02 12:15 UTC (permalink / raw) To: Karel Zak, Jeffrey Bastian, 'Masayoshi Mizuma'; +Cc: util-linux Hi Karel, Jeffrey, Mizuma-san Sorry for the late reply. > From: Masayoshi Mizuma <msys.mizuma@gmail.com> > Sent: Thursday, October 1, 2020 12:05 PM > To: Jeffrey Bastian <jbastian@redhat.com> > Cc: Karel Zak <kzak@redhat.com>; Nakamura, Shunsuke > <nakamura.shun@fujitsu.com>; util-linux@vger.kernel.org; Nakamura, > Shunsuke <nakamura.shun@fujitsu.com> > Subject: Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart > > On Wed, Sep 30, 2020 at 04:53:34PM -0500, Jeffrey Bastian wrote: > > On Wed, Sep 30, 2020 at 02:49:17PM -0400, Masayoshi Mizuma wrote: > > > Hi Jeffrey and Karel, > > > > > > On Wed, Sep 30, 2020 at 07:40:27PM +0200, Karel Zak wrote: > > > > On Wed, Sep 30, 2020 at 09:44:09AM -0500, Jeffrey Bastian wrote: > > > > > On Tue, Sep 29, 2020 at 12:46:27PM +0200, Karel Zak wrote: > > > > > > On Mon, Sep 28, 2020 at 06:46:14PM +0900, Shunsuke Nakamura > wrote: > > > > > > > sys-utils/lscpu-arm.c | 6 ++++++ > > > > > > > 1 file changed, 6 insertions(+) > > > > > > > > > > > > Applied, thanks. > > > > > > > > > > > > > > > With the other ARM patch applied ("use SMBIOS tables on ARM for > > > > > lscpu"), the output changes on an FX700 system: > > > > > > > > > > [root@fujitsu-fx700 ~]# ./lscpu | grep -e Vendor -e Model -e Stepping > > > > > Vendor ID: FUJITSU > > > > > Model: 0 > > > > > Model name: 461F0010 > > > > > Stepping: 0x1 > > > > > > > > > > > > > > > The values here come from the SMBIOS Type 4 record: > > > > > > > > > > [root@fujitsu-fx700 ~]# strings > > > > > /sys/firmware/dmi/entries/4-0/raw > > > > > CPU1 > > > > > FUJITSU > > > > > 461F0010 > > > > > 8K083MH14 > > > > > > > > > > > > > > > This FX700 system has firmware revision 1.4.0 (Jun 17 2020). > > > > > > > > hmm... 461F0010 does not seem user-friendly, "A64FX" seems better. > > > > > > > > Shunsuke, what about to update the firmware strings? ;-) (as > > > > Jeffrey suggested in RH bugzilla) > > > > > > > > The another possibility is to exclude some vendors and do not use > > > > SMBIOS for them (e.g. 0x46 for Fujitsu), but from my point of view > > > > SMBIOS based solution is more elegant and ready for new CPU types > > > > than in-lscpu hard coded tables. > > > > > > According to SMBIOS specification, the description of Processor > > > Version (Type4) is "String number describing the Processor". It > > > shows the version number of the processor, not a model, like as A64FX and > Cortex-A72 and so on. > > > So I think we should not use the Processor Version as the modelname... > > > > Hello Masa, > > > > I think I see your confusion because I was also confused by the > > wording of the SMBIOS spec. In this case, "String number" means the > > number of the string appended to the Type 4 record, not a version > > number of the processor. > > > > See section 6.1.3, "Text strings", of the SMBIOS spec (version 3.4.0). > > > > For Type 4, there can be up to 6 strings appended to the table: > > Offset 0x04: Socket Designation > > Offset 0x07: Processor Manufacturer > > Offset 0x10: Processor Version > > Offset 0x20: Serial Number > > Offset 0x21: Asset Tag > > Offset 0x22: Part Number > > > > Each string is optional. If the byte at one of the above offsets is > > 0, that means the string is not included. If the byte is non-0, it > > means refer to the first or second or third (or so on) string appended > > to the table. It's this non-0 number that the spec calls "String number". > > Ohh... thank you for pointing it out! I misunderstood about "String number". > > > > > Example: > > > > A Type 4 record that only defined Processor Manufacturer and Processor > > Version would therefore look like: > > Offset 0x04: 0x00 > > Offset 0x07: 0x01 > > Offset 0x10: 0x02 > > Offset 0x20: 0x00 > > Offset 0x21: 0x00 > > Offset 0x22: 0x00 > > > > The text of each string is free form. Most vendors have chosen to use > > Processor Manufacturer as the CPU vendor, and Processor Version as a > > text description of the CPU. > > > > Some examples from existing servers (copy/paste from the other thread): > > > > [root@hp-m400 ~]# ./lscpu | grep -i -e vendor -e model -e stepping > > Vendor ID: AppliedMicro > > Model: 1 > > Model name: X-Gene > > Stepping: 0x0 > > > > [root@lenovo-hr330a ~]# ./lscpu | grep -i -e vendor -e model -e stepping > > Vendor ID: Ampere(TM) > > Model: 2 > > Model name: eMAG > > Stepping: 0x3 > > > > [root@hpe-apollo-70 ~]# ./lscpu | grep -i -e vendor -e model -e stepping > > Vendor ID: Cavium Inc. > > Model: 1 > > Model name: Cavium ThunderX2(R) CPU CN9980 v2.1 > @ 2.20GHz > > Stepping: 0x1 > > > > > > Therefore, I believe you are free to change the string "461F0010" to > > "A64FX" in the SMBIOS Type 4 record of the FX700 and FX1000 servers' > > firmware. > > Thanks, I got the most vendors put their CPU model name to Processor Version, > however it depends on the vendor, right..? That's because the SMBIOS > specification says just "String number describing the Processor", so vendors can > put any strings to describe the own processor, like "461F0010"... > > But I don't have strong opinion about the Processor Version of A64FX, let's wait > for Shunsuke's comment. I checked with the person in charge. When the A64FX was designed, there was ambiguity in the Processer Version specification. Therefore we defined it as "461F0010". Considering the maintenance cost to keep up with the latest CPU, I agree to get information from the SMBIOS table rather than the hard code. However, as Mizuma-san said, since "Processer Version" specs depends on the interpretation of the vendor, the expected value is not output in the processor group existing in the current table as in the case of the A64FX. Given these, I propose referring to the SMBIOS table if the processor version does not exist in the current table. Can you give me your opinion? Best Regards > > Thanks, > Masa ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-10-02 12:15 ` nakamura.shun @ 2020-10-05 13:35 ` Jeffrey Bastian 2020-10-08 12:10 ` Masayoshi Mizuma 0 siblings, 1 reply; 12+ messages in thread From: Jeffrey Bastian @ 2020-10-05 13:35 UTC (permalink / raw) To: nakamura.shun; +Cc: Karel Zak, 'Masayoshi Mizuma', util-linux On Fri, Oct 02, 2020 at 12:15:39PM +0000, nakamura.shun@fujitsu.com wrote: >Hi Karel, Jeffrey, Mizuma-san > >Sorry for the late reply. > >> From: Masayoshi Mizuma <msys.mizuma@gmail.com> >> Sent: Thursday, October 1, 2020 12:05 PM >> To: Jeffrey Bastian <jbastian@redhat.com> >> Cc: Karel Zak <kzak@redhat.com>; Nakamura, Shunsuke >> <nakamura.shun@fujitsu.com>; util-linux@vger.kernel.org; Nakamura, >> Shunsuke <nakamura.shun@fujitsu.com> >> Subject: Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart >> >> On Wed, Sep 30, 2020 at 04:53:34PM -0500, Jeffrey Bastian wrote: >> > On Wed, Sep 30, 2020 at 02:49:17PM -0400, Masayoshi Mizuma wrote: >> > > Hi Jeffrey and Karel, >> > > >> > > On Wed, Sep 30, 2020 at 07:40:27PM +0200, Karel Zak wrote: >> > > > On Wed, Sep 30, 2020 at 09:44:09AM -0500, Jeffrey Bastian wrote: >> > > > > On Tue, Sep 29, 2020 at 12:46:27PM +0200, Karel Zak wrote: >> > > > > > On Mon, Sep 28, 2020 at 06:46:14PM +0900, Shunsuke Nakamura >> wrote: >> > > > > > > sys-utils/lscpu-arm.c | 6 ++++++ >> > > > > > > 1 file changed, 6 insertions(+) >> > > > > > >> > > > > > Applied, thanks. >> > > > > >> > > > > >> > > > > With the other ARM patch applied ("use SMBIOS tables on ARM for >> > > > > lscpu"), the output changes on an FX700 system: >> > > > > >> > > > > [root@fujitsu-fx700 ~]# ./lscpu | grep -e Vendor -e Model -e Stepping >> > > > > Vendor ID: FUJITSU >> > > > > Model: 0 >> > > > > Model name: 461F0010 >> > > > > Stepping: 0x1 >> > > > > >> > > > > >> > > > > The values here come from the SMBIOS Type 4 record: >> > > > > >> > > > > [root@fujitsu-fx700 ~]# strings >> > > > > /sys/firmware/dmi/entries/4-0/raw >> > > > > CPU1 >> > > > > FUJITSU >> > > > > 461F0010 >> > > > > 8K083MH14 >> > > > > >> > > > > >> > > > > This FX700 system has firmware revision 1.4.0 (Jun 17 2020). >> > > > >> > > > hmm... 461F0010 does not seem user-friendly, "A64FX" seems better. >> > > > >> > > > Shunsuke, what about to update the firmware strings? ;-) (as >> > > > Jeffrey suggested in RH bugzilla) >> > > > >> > > > The another possibility is to exclude some vendors and do not use >> > > > SMBIOS for them (e.g. 0x46 for Fujitsu), but from my point of view >> > > > SMBIOS based solution is more elegant and ready for new CPU types >> > > > than in-lscpu hard coded tables. >> > > >> > > According to SMBIOS specification, the description of Processor >> > > Version (Type4) is "String number describing the Processor". It >> > > shows the version number of the processor, not a model, like as A64FX and >> Cortex-A72 and so on. >> > > So I think we should not use the Processor Version as the modelname... >> > >> > Hello Masa, >> > >> > I think I see your confusion because I was also confused by the >> > wording of the SMBIOS spec. In this case, "String number" means the >> > number of the string appended to the Type 4 record, not a version >> > number of the processor. >> > >> > See section 6.1.3, "Text strings", of the SMBIOS spec (version 3.4.0). >> > >> > For Type 4, there can be up to 6 strings appended to the table: >> > Offset 0x04: Socket Designation >> > Offset 0x07: Processor Manufacturer >> > Offset 0x10: Processor Version >> > Offset 0x20: Serial Number >> > Offset 0x21: Asset Tag >> > Offset 0x22: Part Number >> > >> > Each string is optional. If the byte at one of the above offsets is >> > 0, that means the string is not included. If the byte is non-0, it >> > means refer to the first or second or third (or so on) string appended >> > to the table. It's this non-0 number that the spec calls "String number". >> >> Ohh... thank you for pointing it out! I misunderstood about "String number". >> >> > >> > Example: >> > >> > A Type 4 record that only defined Processor Manufacturer and Processor >> > Version would therefore look like: >> > Offset 0x04: 0x00 >> > Offset 0x07: 0x01 >> > Offset 0x10: 0x02 >> > Offset 0x20: 0x00 >> > Offset 0x21: 0x00 >> > Offset 0x22: 0x00 >> > >> > The text of each string is free form. Most vendors have chosen to use >> > Processor Manufacturer as the CPU vendor, and Processor Version as a >> > text description of the CPU. >> > >> > Some examples from existing servers (copy/paste from the other thread): >> > >> > [root@hp-m400 ~]# ./lscpu | grep -i -e vendor -e model -e stepping >> > Vendor ID: AppliedMicro >> > Model: 1 >> > Model name: X-Gene >> > Stepping: 0x0 >> > >> > [root@lenovo-hr330a ~]# ./lscpu | grep -i -e vendor -e model -e stepping >> > Vendor ID: Ampere(TM) >> > Model: 2 >> > Model name: eMAG >> > Stepping: 0x3 >> > >> > [root@hpe-apollo-70 ~]# ./lscpu | grep -i -e vendor -e model -e stepping >> > Vendor ID: Cavium Inc. >> > Model: 1 >> > Model name: Cavium ThunderX2(R) CPU CN9980 v2.1 >> @ 2.20GHz >> > Stepping: 0x1 >> > >> > >> > Therefore, I believe you are free to change the string "461F0010" to >> > "A64FX" in the SMBIOS Type 4 record of the FX700 and FX1000 servers' >> > firmware. >> >> Thanks, I got the most vendors put their CPU model name to Processor Version, >> however it depends on the vendor, right..? That's because the SMBIOS >> specification says just "String number describing the Processor", so vendors can >> put any strings to describe the own processor, like "461F0010"... >> >> But I don't have strong opinion about the Processor Version of A64FX, let's wait >> for Shunsuke's comment. > >I checked with the person in charge. > >When the A64FX was designed, there was ambiguity in the Processer Version specification. >Therefore we defined it as "461F0010". >Considering the maintenance cost to keep up with the latest CPU, I agree to get information >from the SMBIOS table rather than the hard code. >However, as Mizuma-san said, since "Processer Version" specs depends on the interpretation >of the vendor, the expected value is not output in the processor group existing in the current table >as in the case of the A64FX. > >Given these, I propose referring to the SMBIOS table if the processor version does not exist in >the current table. Can you give me your opinion? My motivation for writing the SMBIOS patch was the exact opposite problem: the original AppliedMicro X-Gene and newer Ampere eMAG are both identified as X-Gene by lscpu when using the hard-coded tables. (AppliedMicro was acquired by Macom, then the server CPU team split out into a new company named Ampere and the X-Gene 3 was rebranded as eMAG.) The X-Gene output on an eMAG system is often confusing to people (including myself). The "CPU implementer" and "CPU part" values are the same for X-Gene and eMAG. The difference is in the "CPU variant" field, but lscpu does not use the variant number in its tables. ## X-Gene ~]# grep -m5 CPU /proc/cpuinfo CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x000 CPU revision : 1 ## eMAG ~]# grep -m5 CPU /proc/cpuinfo CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x3 CPU part : 0x000 CPU revision : 2 I thought about trying to extend lscpu to add the variant value to the tables, but then I realized the strings already exist in SMBIOS Type 4. Furthermore, using SMBIOS Type 4 reduces the maintenance costs for lscpu since it no longer needs the hard-coded tables (at least for servers). -- Jeff Bastian Kernel QE - Hardware Enablement Red Hat ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-10-05 13:35 ` Jeffrey Bastian @ 2020-10-08 12:10 ` Masayoshi Mizuma 2020-10-15 18:53 ` Jeffrey Bastian 0 siblings, 1 reply; 12+ messages in thread From: Masayoshi Mizuma @ 2020-10-08 12:10 UTC (permalink / raw) To: Jeffrey Bastian; +Cc: nakamura.shun, Karel Zak, util-linux On Mon, Oct 05, 2020 at 08:35:50AM -0500, Jeffrey Bastian wrote: > On Fri, Oct 02, 2020 at 12:15:39PM +0000, nakamura.shun@fujitsu.com wrote: > > Hi Karel, Jeffrey, Mizuma-san > > > > Sorry for the late reply. > > > > > From: Masayoshi Mizuma <msys.mizuma@gmail.com> > > > Sent: Thursday, October 1, 2020 12:05 PM > > > To: Jeffrey Bastian <jbastian@redhat.com> > > > Cc: Karel Zak <kzak@redhat.com>; Nakamura, Shunsuke > > > <nakamura.shun@fujitsu.com>; util-linux@vger.kernel.org; Nakamura, > > > Shunsuke <nakamura.shun@fujitsu.com> > > > Subject: Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart > > > > > > On Wed, Sep 30, 2020 at 04:53:34PM -0500, Jeffrey Bastian wrote: > > > > On Wed, Sep 30, 2020 at 02:49:17PM -0400, Masayoshi Mizuma wrote: > > > > > Hi Jeffrey and Karel, > > > > > > > > > > On Wed, Sep 30, 2020 at 07:40:27PM +0200, Karel Zak wrote: > > > > > > On Wed, Sep 30, 2020 at 09:44:09AM -0500, Jeffrey Bastian wrote: > > > > > > > On Tue, Sep 29, 2020 at 12:46:27PM +0200, Karel Zak wrote: > > > > > > > > On Mon, Sep 28, 2020 at 06:46:14PM +0900, Shunsuke Nakamura > > > wrote: > > > > > > > > > sys-utils/lscpu-arm.c | 6 ++++++ > > > > > > > > > 1 file changed, 6 insertions(+) > > > > > > > > > > > > > > > > Applied, thanks. > > > > > > > > > > > > > > > > > > > > > With the other ARM patch applied ("use SMBIOS tables on ARM for > > > > > > > lscpu"), the output changes on an FX700 system: > > > > > > > > > > > > > > [root@fujitsu-fx700 ~]# ./lscpu | grep -e Vendor -e Model -e Stepping > > > > > > > Vendor ID: FUJITSU > > > > > > > Model: 0 > > > > > > > Model name: 461F0010 > > > > > > > Stepping: 0x1 > > > > > > > > > > > > > > > > > > > > > The values here come from the SMBIOS Type 4 record: > > > > > > > > > > > > > > [root@fujitsu-fx700 ~]# strings > > > > > > > /sys/firmware/dmi/entries/4-0/raw > > > > > > > CPU1 > > > > > > > FUJITSU > > > > > > > 461F0010 > > > > > > > 8K083MH14 > > > > > > > > > > > > > > > > > > > > > This FX700 system has firmware revision 1.4.0 (Jun 17 2020). > > > > > > > > > > > > hmm... 461F0010 does not seem user-friendly, "A64FX" seems better. > > > > > > > > > > > > Shunsuke, what about to update the firmware strings? ;-) (as > > > > > > Jeffrey suggested in RH bugzilla) > > > > > > > > > > > > The another possibility is to exclude some vendors and do not use > > > > > > SMBIOS for them (e.g. 0x46 for Fujitsu), but from my point of view > > > > > > SMBIOS based solution is more elegant and ready for new CPU types > > > > > > than in-lscpu hard coded tables. > > > > > > > > > > According to SMBIOS specification, the description of Processor > > > > > Version (Type4) is "String number describing the Processor". It > > > > > shows the version number of the processor, not a model, like as A64FX and > > > Cortex-A72 and so on. > > > > > So I think we should not use the Processor Version as the modelname... > > > > > > > > Hello Masa, > > > > > > > > I think I see your confusion because I was also confused by the > > > > wording of the SMBIOS spec. In this case, "String number" means the > > > > number of the string appended to the Type 4 record, not a version > > > > number of the processor. > > > > > > > > See section 6.1.3, "Text strings", of the SMBIOS spec (version 3.4.0). > > > > > > > > For Type 4, there can be up to 6 strings appended to the table: > > > > Offset 0x04: Socket Designation > > > > Offset 0x07: Processor Manufacturer > > > > Offset 0x10: Processor Version > > > > Offset 0x20: Serial Number > > > > Offset 0x21: Asset Tag > > > > Offset 0x22: Part Number > > > > > > > > Each string is optional. If the byte at one of the above offsets is > > > > 0, that means the string is not included. If the byte is non-0, it > > > > means refer to the first or second or third (or so on) string appended > > > > to the table. It's this non-0 number that the spec calls "String number". > > > > > > Ohh... thank you for pointing it out! I misunderstood about "String number". > > > > > > > > > > > Example: > > > > > > > > A Type 4 record that only defined Processor Manufacturer and Processor > > > > Version would therefore look like: > > > > Offset 0x04: 0x00 > > > > Offset 0x07: 0x01 > > > > Offset 0x10: 0x02 > > > > Offset 0x20: 0x00 > > > > Offset 0x21: 0x00 > > > > Offset 0x22: 0x00 > > > > > > > > The text of each string is free form. Most vendors have chosen to use > > > > Processor Manufacturer as the CPU vendor, and Processor Version as a > > > > text description of the CPU. > > > > > > > > Some examples from existing servers (copy/paste from the other thread): > > > > > > > > [root@hp-m400 ~]# ./lscpu | grep -i -e vendor -e model -e stepping > > > > Vendor ID: AppliedMicro > > > > Model: 1 > > > > Model name: X-Gene > > > > Stepping: 0x0 > > > > > > > > [root@lenovo-hr330a ~]# ./lscpu | grep -i -e vendor -e model -e stepping > > > > Vendor ID: Ampere(TM) > > > > Model: 2 > > > > Model name: eMAG > > > > Stepping: 0x3 > > > > > > > > [root@hpe-apollo-70 ~]# ./lscpu | grep -i -e vendor -e model -e stepping > > > > Vendor ID: Cavium Inc. > > > > Model: 1 > > > > Model name: Cavium ThunderX2(R) CPU CN9980 v2.1 > > > @ 2.20GHz > > > > Stepping: 0x1 > > > > > > > > > > > > Therefore, I believe you are free to change the string "461F0010" to > > > > "A64FX" in the SMBIOS Type 4 record of the FX700 and FX1000 servers' > > > > firmware. > > > > > > Thanks, I got the most vendors put their CPU model name to Processor Version, > > > however it depends on the vendor, right..? That's because the SMBIOS > > > specification says just "String number describing the Processor", so vendors can > > > put any strings to describe the own processor, like "461F0010"... > > > > > > But I don't have strong opinion about the Processor Version of A64FX, let's wait > > > for Shunsuke's comment. > > > > I checked with the person in charge. > > > > When the A64FX was designed, there was ambiguity in the Processer Version specification. > > Therefore we defined it as "461F0010". > > Considering the maintenance cost to keep up with the latest CPU, I agree to get information > > from the SMBIOS table rather than the hard code. > > However, as Mizuma-san said, since "Processer Version" specs depends on the interpretation > > of the vendor, the expected value is not output in the processor group existing in the current table > > as in the case of the A64FX. > > > > Given these, I propose referring to the SMBIOS table if the processor version does not exist in > > the current table. Can you give me your opinion? > > > My motivation for writing the SMBIOS patch was the exact opposite > problem: the original AppliedMicro X-Gene and newer Ampere eMAG are both > identified as X-Gene by lscpu when using the hard-coded tables. > (AppliedMicro was acquired by Macom, then the server CPU team split out > into a new company named Ampere and the X-Gene 3 was rebranded as eMAG.) > The X-Gene output on an eMAG system is often confusing to people > (including myself). > > The "CPU implementer" and "CPU part" values are the same for X-Gene and > eMAG. The difference is in the "CPU variant" field, but lscpu does not > use the variant number in its tables. > > ## X-Gene > ~]# grep -m5 CPU /proc/cpuinfo > CPU implementer : 0x50 > CPU architecture: 8 > CPU variant : 0x0 > CPU part : 0x000 > CPU revision : 1 > > ## eMAG > ~]# grep -m5 CPU /proc/cpuinfo > CPU implementer : 0x50 > CPU architecture: 8 > CPU variant : 0x3 > CPU part : 0x000 > CPU revision : 2 > > > I thought about trying to extend lscpu to add the variant value to the > tables, but then I realized the strings already exist in SMBIOS Type 4. > Furthermore, using SMBIOS Type 4 reduces the maintenance costs for lscpu > since it no longer needs the hard-coded tables (at least for servers). Hi Jeffrey, Could you try the following patch? ==================================================================== From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Subject: [PATCH] lscpu-arm: Set the order to search the model name After commit: 367c85c47 ("lscpu: use SMBIOS tables on ARM for lscpu"), Model name for A64FX shows like as: Model name: 461F0010 That's because 367c85c47 changes to get the modelname from Processor Version of SMBIOS. The SMBIOS info would be great if the system is based on SBBR v1.2E and BBR v1.0 because the specs require the Processor Version of SMBIOS as "This field must provide a human readable description of the processor part number". However, it's not good for the systems aren't based on the specs, like A64FX. Such systems need to have the model name to the hard corded table. Let's set the order; first, search the hard corded table, then SMBIOS. Note, some systems, like APM X-Gene, may not match the information between MIDR register (/proc/cpuinfo) and SMBIOS. To be consistency, use Processor Manufacturer of SMBIOS when Processor Version is used even if the hard corded table has the vendor id. Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> --- sys-utils/lscpu-arm.c | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/sys-utils/lscpu-arm.c b/sys-utils/lscpu-arm.c index 20c7291e5..4e48f6d65 100644 --- a/sys-utils/lscpu-arm.c +++ b/sys-utils/lscpu-arm.c @@ -110,7 +110,6 @@ static const struct id_part cavium_part[] = { }; static const struct id_part apm_part[] = { - { 0x000, "X-Gene" }, { -1, "unknown" }, }; @@ -288,6 +287,7 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc) struct lscpu_dmi_header h; int fd; ssize_t rs; + int use_smbios = 0; fd = open(_PATH_SYS_DMI_TYPE4, O_RDONLY); if (fd < 0) @@ -301,16 +301,21 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc) to_dmi_header(&h, data); - str = dmi_string(&h, data[PROC_MFR_OFFSET]); - if (str) { - xstrncpy(buf, str, 127); - desc->vendor = xstrdup(buf); + if (!desc->modelname) { + str = dmi_string(&h, data[PROC_VERSION_OFFSET]); + if (str) { + xstrncpy(buf, str, 127); + desc->modelname = xstrdup(buf); + use_smbios = 1; + } } - str = dmi_string(&h, data[PROC_VERSION_OFFSET]); - if (str) { - xstrncpy(buf, str, 127); - desc->modelname = xstrdup(buf); + if ((startswith(desc->vendor, "0x")) || use_smbios) { + str = dmi_string(&h, data[PROC_MFR_OFFSET]); + if (str) { + xstrncpy(buf, str, 127); + desc->vendor = xstrdup(buf); + } } return 0; @@ -318,14 +323,11 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc) void arm_cpu_decode(struct lscpu_desc *desc, struct lscpu_modifier *mod) { - int rc = -1; + __arm_cpu_decode(desc); /* use SMBIOS Type 4 data if available, * else fall back to manual decoding using the tables above */ if (mod->system == SYSTEM_LIVE && access(_PATH_SYS_DMI_TYPE4, R_OK) == 0) - rc = __arm_cpu_smbios(desc); - - if (rc) - __arm_cpu_decode(desc); + __arm_cpu_smbios(desc); } -- 2.27.0 Thanks, Masa ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-10-08 12:10 ` Masayoshi Mizuma @ 2020-10-15 18:53 ` Jeffrey Bastian 2020-10-19 18:55 ` Masayoshi Mizuma 0 siblings, 1 reply; 12+ messages in thread From: Jeffrey Bastian @ 2020-10-15 18:53 UTC (permalink / raw) To: util-linux On Thu, Oct 08, 2020 at 08:10:12AM -0400, Masayoshi Mizuma wrote: >Hi Jeffrey, > >Could you try the following patch? This patch works for X-Gene and eMAG, but unfortunately it broke the output on the Altra. The Altra is based on the Neoverse N1 design from ARM and so it inherited the N1 values in the MIDR register (at least on the prototype I'm using). Before your patch: [root@ampere-altra ~]# ./lscpu | grep -e Vendor -e Model -e Stepping Vendor ID: Ampere(TM) Model: 1 Model name: Ampere(TM) Altra(TM) Processor Stepping: 0x3 After your patch: [root@ampere-altra ~]# ./lscpu | grep -e Vendor -e Model -e Stepping Vendor ID: ARM Model: 1 Model name: Neoverse-N1 Stepping: r3p1 Raw cpuinfo values: [root@ampere-altra ~]# grep -m5 CPU /proc/cpuinfo CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x3 CPU part : 0xd0c CPU revision : 1 >==================================================================== >From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> >Subject: [PATCH] lscpu-arm: Set the order to search the model name > >After commit: 367c85c47 ("lscpu: use SMBIOS tables on ARM for lscpu"), >Model name for A64FX shows like as: > > Model name: 461F0010 > >That's because 367c85c47 changes to get the modelname from Processor >Version of SMBIOS. > >The SMBIOS info would be great if the system is based on SBBR v1.2E and >BBR v1.0 because the specs require the Processor Version of SMBIOS >as "This field must provide a human readable description of the processor >part number". > >However, it's not good for the systems aren't based on the specs, >like A64FX. Such systems need to have the model name to the hard >corded table. > >Let's set the order; first, search the hard corded table, then SMBIOS. > >Note, some systems, like APM X-Gene, may not match the information >between MIDR register (/proc/cpuinfo) and SMBIOS. To be consistency, >use Processor Manufacturer of SMBIOS when Processor Version is used >even if the hard corded table has the vendor id. > >Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> >--- > sys-utils/lscpu-arm.c | 30 ++++++++++++++++-------------- > 1 file changed, 16 insertions(+), 14 deletions(-) > >diff --git a/sys-utils/lscpu-arm.c b/sys-utils/lscpu-arm.c >index 20c7291e5..4e48f6d65 100644 >--- a/sys-utils/lscpu-arm.c >+++ b/sys-utils/lscpu-arm.c >@@ -110,7 +110,6 @@ static const struct id_part cavium_part[] = { > }; > > static const struct id_part apm_part[] = { >- { 0x000, "X-Gene" }, > { -1, "unknown" }, > }; > >@@ -288,6 +287,7 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc) > struct lscpu_dmi_header h; > int fd; > ssize_t rs; >+ int use_smbios = 0; > > fd = open(_PATH_SYS_DMI_TYPE4, O_RDONLY); > if (fd < 0) >@@ -301,16 +301,21 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc) > > to_dmi_header(&h, data); > >- str = dmi_string(&h, data[PROC_MFR_OFFSET]); >- if (str) { >- xstrncpy(buf, str, 127); >- desc->vendor = xstrdup(buf); >+ if (!desc->modelname) { >+ str = dmi_string(&h, data[PROC_VERSION_OFFSET]); >+ if (str) { >+ xstrncpy(buf, str, 127); >+ desc->modelname = xstrdup(buf); >+ use_smbios = 1; >+ } > } > >- str = dmi_string(&h, data[PROC_VERSION_OFFSET]); >- if (str) { >- xstrncpy(buf, str, 127); >- desc->modelname = xstrdup(buf); >+ if ((startswith(desc->vendor, "0x")) || use_smbios) { >+ str = dmi_string(&h, data[PROC_MFR_OFFSET]); >+ if (str) { >+ xstrncpy(buf, str, 127); >+ desc->vendor = xstrdup(buf); >+ } > } > > return 0; >@@ -318,14 +323,11 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc) > > void arm_cpu_decode(struct lscpu_desc *desc, struct lscpu_modifier *mod) > { >- int rc = -1; >+ __arm_cpu_decode(desc); > > /* use SMBIOS Type 4 data if available, > * else fall back to manual decoding using the tables above */ > if (mod->system == SYSTEM_LIVE && > access(_PATH_SYS_DMI_TYPE4, R_OK) == 0) >- rc = __arm_cpu_smbios(desc); >- >- if (rc) >- __arm_cpu_decode(desc); >+ __arm_cpu_smbios(desc); > } >-- >2.27.0 > > >Thanks, >Masa > -- Jeff Bastian Kernel QE - Hardware Enablement Red Hat ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart 2020-10-15 18:53 ` Jeffrey Bastian @ 2020-10-19 18:55 ` Masayoshi Mizuma 0 siblings, 0 replies; 12+ messages in thread From: Masayoshi Mizuma @ 2020-10-19 18:55 UTC (permalink / raw) To: Jeffrey Bastian; +Cc: util-linux On Thu, Oct 15, 2020 at 01:53:21PM -0500, Jeffrey Bastian wrote: > On Thu, Oct 08, 2020 at 08:10:12AM -0400, Masayoshi Mizuma wrote: > > Hi Jeffrey, > > > > Could you try the following patch? > > This patch works for X-Gene and eMAG, but unfortunately it broke the > output on the Altra. The Altra is based on the Neoverse N1 design from > ARM and so it inherited the N1 values in the MIDR register (at least on > the prototype I'm using). > > Before your patch: > > [root@ampere-altra ~]# ./lscpu | grep -e Vendor -e Model -e Stepping > Vendor ID: Ampere(TM) > Model: 1 > Model name: Ampere(TM) Altra(TM) Processor > Stepping: 0x3 > > After your patch: > > [root@ampere-altra ~]# ./lscpu | grep -e Vendor -e Model -e Stepping > Vendor ID: ARM > Model: 1 > Model name: Neoverse-N1 > Stepping: r3p1 > > Raw cpuinfo values: > > [root@ampere-altra ~]# grep -m5 CPU /proc/cpuinfo > CPU implementer : 0x41 > CPU architecture: 8 > CPU variant : 0x3 > CPU part : 0xd0c > CPU revision : 1 Thank you for your testing! Probably the Altra should use SMBIOS info, not hard corded table. I'll send the v2. - Masa > > > > > ==================================================================== > > From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> > > Subject: [PATCH] lscpu-arm: Set the order to search the model name > > > > After commit: 367c85c47 ("lscpu: use SMBIOS tables on ARM for lscpu"), > > Model name for A64FX shows like as: > > > > Model name: 461F0010 > > > > That's because 367c85c47 changes to get the modelname from Processor > > Version of SMBIOS. > > > > The SMBIOS info would be great if the system is based on SBBR v1.2E and > > BBR v1.0 because the specs require the Processor Version of SMBIOS > > as "This field must provide a human readable description of the processor > > part number". > > > > However, it's not good for the systems aren't based on the specs, > > like A64FX. Such systems need to have the model name to the hard > > corded table. > > > > Let's set the order; first, search the hard corded table, then SMBIOS. > > > > Note, some systems, like APM X-Gene, may not match the information > > between MIDR register (/proc/cpuinfo) and SMBIOS. To be consistency, > > use Processor Manufacturer of SMBIOS when Processor Version is used > > even if the hard corded table has the vendor id. > > > > Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> > > --- > > sys-utils/lscpu-arm.c | 30 ++++++++++++++++-------------- > > 1 file changed, 16 insertions(+), 14 deletions(-) > > > > diff --git a/sys-utils/lscpu-arm.c b/sys-utils/lscpu-arm.c > > index 20c7291e5..4e48f6d65 100644 > > --- a/sys-utils/lscpu-arm.c > > +++ b/sys-utils/lscpu-arm.c > > @@ -110,7 +110,6 @@ static const struct id_part cavium_part[] = { > > }; > > > > static const struct id_part apm_part[] = { > > - { 0x000, "X-Gene" }, > > { -1, "unknown" }, > > }; > > > > @@ -288,6 +287,7 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc) > > struct lscpu_dmi_header h; > > int fd; > > ssize_t rs; > > + int use_smbios = 0; > > > > fd = open(_PATH_SYS_DMI_TYPE4, O_RDONLY); > > if (fd < 0) > > @@ -301,16 +301,21 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc) > > > > to_dmi_header(&h, data); > > > > - str = dmi_string(&h, data[PROC_MFR_OFFSET]); > > - if (str) { > > - xstrncpy(buf, str, 127); > > - desc->vendor = xstrdup(buf); > > + if (!desc->modelname) { > > + str = dmi_string(&h, data[PROC_VERSION_OFFSET]); > > + if (str) { > > + xstrncpy(buf, str, 127); > > + desc->modelname = xstrdup(buf); > > + use_smbios = 1; > > + } > > } > > > > - str = dmi_string(&h, data[PROC_VERSION_OFFSET]); > > - if (str) { > > - xstrncpy(buf, str, 127); > > - desc->modelname = xstrdup(buf); > > + if ((startswith(desc->vendor, "0x")) || use_smbios) { > > + str = dmi_string(&h, data[PROC_MFR_OFFSET]); > > + if (str) { > > + xstrncpy(buf, str, 127); > > + desc->vendor = xstrdup(buf); > > + } > > } > > > > return 0; > > @@ -318,14 +323,11 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc) > > > > void arm_cpu_decode(struct lscpu_desc *desc, struct lscpu_modifier *mod) > > { > > - int rc = -1; > > + __arm_cpu_decode(desc); > > > > /* use SMBIOS Type 4 data if available, > > * else fall back to manual decoding using the tables above */ > > if (mod->system == SYSTEM_LIVE && > > access(_PATH_SYS_DMI_TYPE4, R_OK) == 0) > > - rc = __arm_cpu_smbios(desc); > > - > > - if (rc) > > - __arm_cpu_decode(desc); > > + __arm_cpu_smbios(desc); > > } > > -- > > 2.27.0 > > > > > > Thanks, > > Masa > > > > -- > Jeff Bastian > Kernel QE - Hardware Enablement > Red Hat > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-10-19 18:55 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-28 9:46 [PATCH] lscpu: Add FUJITSU aarch64 A64FX cpupart Shunsuke Nakamura 2020-09-29 10:46 ` Karel Zak 2020-09-30 14:44 ` Jeffrey Bastian 2020-09-30 17:40 ` Karel Zak 2020-09-30 18:49 ` Masayoshi Mizuma 2020-09-30 21:53 ` Jeffrey Bastian 2020-10-01 3:05 ` Masayoshi Mizuma 2020-10-02 12:15 ` nakamura.shun 2020-10-05 13:35 ` Jeffrey Bastian 2020-10-08 12:10 ` Masayoshi Mizuma 2020-10-15 18:53 ` Jeffrey Bastian 2020-10-19 18:55 ` Masayoshi Mizuma
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.