><snip> > >> >> >> >> >> >> >> > >> >> >> > The patch still holds true for CRC though as it is listed >> >> >> > separately below >> >> >> > https://urldefense.proofpoint.com/v2/url?u=https- >> >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a- >> >> >>2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB- >> >> >fmvgGV3o- >> >> >> >>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc >> >W >> >> >> >>>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c& >e >> >= >> >> >> > profile/exploration-tools/feature-names-for-a-profile >> >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document. >> >> > >> >> >> > >> >> >> > Also, looks like sve2 support in n2 core might be optional as >> >> >> > per >> >> >above doc? >> >> >> I need to check on this. Some of the info here might not be >public >> >yet. >> >> >I found [1]. SVE2 is mandatory feature. >> >> > >> >> >> >> I see thanks for the info I will remove extension from cnxk. >> >> >> >> Do you think the extension infra is still useful for other cases? i.e. >> >older cores >> >> or cases where vendor wants to enable some extensions by >default? >> >> >> >> I found a document[1] which describes about extensions not >enabled >> >by >> >> default but supported by a given march. >> >> In case of n2 I think memory tagging is one such feature >> >I think the reference is providing a different information than what >> >you are trying to achieve here. >> > >> >It looks like you are trying to address a use case where in the same >> >CPU IP has different features enabled/disabled on different SoCs. >> >This is a valid use case from crypto perspective (due to export >control >> >reasons) where-in 2 different SoCs might have crypto >enabled/disabled. >> >I am not sure if other features can be enabled/disabled. But, Crypto >> >feature is a good enough reason to address such a use case. >> >> Yes, that's my intension apologies if the commit log doesn't clarify it >properly. >> >> > >> >IMO, we should capture the SoC specific details in SoC specific files, >> >in this case in 'arm64_cn10k_linux_gcc'. I believe there were some >> >challenges in doing this. >> >> Since, all the flags are populated through soc_* variable and >> arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the >extensions >> should be reported through >> soc_* variables. >IMO, there will be more SoCs in the future. I prefer to not grow >meson.build.
Problem is native build wouldn't read arm64_*_linux_gcc, it will be really hard to parse it and read extensions if they are placed there. >> >> Also, do you think +crypto needs to be removed from default n2 >config as its >> optional? >Agree. Better to move it to SoC specific configuration. > >> >> >Juraj, do you remember the exact issue? >> > >> >> >> >> [1]https://urldefense.proofpoint.com/v2/url?u=https- >> >3A__developer.arm.com_tools-2Dand-2Dsoftware_open-2Dsource- >> >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB- >> >fmvgGV3o-g_fjLhk5Pupi9ijohpc&m=0oZnXDnO- >> >>oYL9lESEaZt_nH_kK8Nc3m0tvdEPpKeFZc&s=WxrPoWhkM2QIFGEKezP >K >> >D9oEn7nGFvvgS2ul9ZYx-Kg&e= >> >> software/developer-tools/gnu-toolchain/architecture-support >> >> >> >> >> >> >[1] https://urldefense.proofpoint.com/v2/url?u=https- >> >> >3A__developer.arm.com_ip- >> >> >2Dproducts_processors_neoverse_neoverse- >> >> >> >>>2Dn2&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVs >B >> >- >> >> >fmvgGV3o- >> >> >> >>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc >> >W >> >> >d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE- >> >3EhTVBabm3SW8&e= >> >> > >> >> ><snip>
