From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by mx.groups.io with SMTP id smtpd.web11.10342.1590666895144265217 for ; Thu, 28 May 2020 04:54:55 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=cxiVVFUu; spf=pass (domain: nuviainc.com, ip: 209.85.128.41, mailfrom: leif@nuviainc.com) Received: by mail-wm1-f41.google.com with SMTP id n5so2878559wmd.0 for ; Thu, 28 May 2020 04:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=qw6YDIsfyPufOpvK5XkrkJUzBB+U2ykA6S+K96XfpYw=; b=cxiVVFUuxm9UPIoSAhn1wpGttO7kERlOXztpgKtfM22e7B6MI4QFu2AqZNa1Tqxn+2 mUv/xMFzYI2R6asaZYY5mcWo88TbvDGPUMiYsF9jnJOYr26cQ5XtAWGhGoeR30KaA6n/ 2ofzlfDliAmjs2nqLP24aOLwzKrvKM15VXF+LSRKoTaIqlMIvjk8L9w5lyoAhKThoq9U yaC+Db0w3+2EIBt8jA6YoPZDWAfUujTWK9+xzl8IhKuu8+FXkHmfd+H4RScmW40RUG7u 8aKz/d3xFFEBy1CCv1m9x2PwrXPbVn4Kz2U54ePAMyA00dBWTaIsSSKTxwdktAWUexQR 7Awg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=qw6YDIsfyPufOpvK5XkrkJUzBB+U2ykA6S+K96XfpYw=; b=XIZ7ZaVJqK6cUX343hI9CeiluCu8WUAMI/edmoDgQJU5ZTAOS8a8ZiCdlXXP8VQWqt L4Jd+JNotokEAsyeRG06aGshQLdLpOim4S0EnDD48zmdW7gU/eSOqZSUWNcoRrWbwyuQ rBL3pT7Dxi71LKfaSAyC11J8C2XtsKpDEiZoxg0MBhiXnCRyQmjHNWB9pfRtvA0tLHs6 3BHwduvZ7sXaEQfNh4jlzKmkutecRHeoM+lFb88EOUaS5XnTFOsGKY8lPXegZl3lcN5I Xe3dl3gm97K1QU3TZUQPDCjhbQ2TJRqm0ZrhcBmeCbmPukdz9WlKmzDWPxBb+XYsJEvD 04yg== X-Gm-Message-State: AOAM533iHmaq8DIPIc7fNaijmfAZrD27569nJDjw6hOQO6j2SA1+mfxN UKHPrxUKp/IhwwYLCdeSWgowZA== X-Google-Smtp-Source: ABdhPJy+fB3UWRhGOf3m6Z4rIm5dUXvOp8eba/jfn/Rhl/HZc00Mmj/LoarPGCXx38iog0wp0pz3Ew== X-Received: by 2002:a1c:5a0b:: with SMTP id o11mr2995210wmb.74.1590666893231; Thu, 28 May 2020 04:54:53 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id p10sm5779889wra.78.2020.05.28.04.54.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2020 04:54:52 -0700 (PDT) Date: Thu, 28 May 2020 12:54:49 +0100 From: "Leif Lindholm" To: "Chang, Abner (HPS SW/FW Technologist)" Cc: "Schaefer, Daniel (DualStudy)" , "devel@edk2.groups.io" , "Chen, Gilbert" , "Kinney, Michael D" , "Bret.Barkelew@microsoft.com" , "sean.brogan@microsoft.com" Subject: Re: [edk2-devel] [PATCH v2 0/3] New RISC-V Patches - Why in edk2-platforms Message-ID: <20200528115449.GE1923@vanye> References: <20200515133937.29909-1-daniel.schaefer@hpe.com> <20200520114336.GK1923@vanye> <6f0d755e-4e69-5080-ef69-caf7259ce9ee@hpe.com> <27d3bf55-eb2e-75e1-e5fa-17af59e105aa@hpe.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi Abner, Sorry, I should have followed up on this sooner. On Thu, May 21, 2020 at 06:59:20 +0000, Chang, Abner (HPS SW/FW Technologist) wrote: > > On 5/20/20 6:07 PM, Daniel Schaefer wrote: > > > please reply here, fixed Mike's email address, sorry... > > > > > > On 5/20/20 6:03 PM, Daniel Schaefer wrote: > > >> On 5/20/20 1:43 PM, Leif Lindholm wrote: > > >>> On Fri, May 15, 2020 at 15:39:34 +0200, Daniel Schaefer wrote: > > >>>> Previously we had two packages just for RISC-V on our edk2 branch: > > >>>>    RiscVPkg and RiscVPlatformPkg > > >>>> They are now under > > >>>>    Platform/RISC-V/PlatformPkg and Silicon/RISC-V/ProcessorPkg in > > >>>> edk2-platforms. > > >>> > > >>> Understood. I took my eye off the ball there for a while, but I'm a > > >>> bit confused as to why RiscVPkg isn't going into EDK2. That is very > > >>> counterintuitive. And clearly it will need revisiting if we are to > > >>> add first-class CI checks like those we do with OvmfPkg/ArmVirtPkg. > > >> > > >> Yes, I understand your concern. Personally I'd like it also to be in > > >> EDK2 straight away, however Mike, Bret and Sean have raised valid > > >> concerns: Can you point me to the conversation I have missed? > > >> 1. RISC-V is very new and potentially unstable - it's quicker to make > > >> changes in edk2-platforms. I don't see this as a valid argument. It's not edk2-unstable, it is edk2-platforms. edk2-platforms exists because there used to be strong feelings against holding *real* platforms in edk2, with edk2 being originally intended only as a code library for IBV/ISV to cherry-pick from. But fundamentally, if code is too immature to go into the master branch of edk2, it is too immature to go into the master branch of edk2-platforms. If we want edk2-might-be-a-bit-shaky-but-who-cares, then someone will have to create it. > > >> 2. If we define new interfaces and libraries in edk2, we can't remove > > >> them easily because it would be a backwards-incompatible change. > > >> edk2-platforms isn't quite as strict. Yes it is. The only thing making it less strict is its contents - platform ports and device drivers. The changes tend to be self-contained. Where they are not, they need to be carefully managed. > > >> 3. Long-term, I think many agree, we should aim to move much of the > > >> RISC-V code into UefiCpuPkg and OvmfPkg. Mike mentioned that would > > >> need coordination with ARM maintainers because it might make sense to > > >> move their code there as well. I don't think there is any need to tie the two together. Yes, UefiCpuPkg should be a generic place where not only x86 support can be contained, but the paths for ARM* and RISC-V into there do not have any interdependencies. > > >>> I *did* have some outstanding comments specifically with regards to > > >>> large amounts of code duplication between the SMBIOS implementation > > >>> of some closely related RISC-V platforms. That now needs to be revisited. > > >> > > >> The SMBIOS code hasn't changed. It has moved to > > >>    Silicon/SiFive/{E51,U54,U54MCCoreplex}/Library/PeiCoreInfoHobLib > > >> You're referring to this library, right? > > >> > > >> They build the SMBIOS entries for a particular processor. Yes, the > > >> values do have a lot of overlap but these files are like > > >> configuration files. They don't do much, they only set the values of the > > properties. > > >> > > >> Currently it is not possible to let the UEFI firmware get this > > >> information from the hardware at runtime, especially now, since we're > > >> running in S-Mode. > > >> To allow that, we created a RISC-V working group to be able to > > >> retrieve all of this information dynamically from the processor > > >> (among other goals). Then the vendor will not have to modify these > > >> files and hardcode the values anymore. Which enables us to create a > > >> single library for all processors. > > >> See: https://github.com/riscv/configuration-structure > > >> > > >> I hope I described everything properly, please correct me otherwise, > > >> Abner. > [Abner] Yes almost. Thanks Daniel. > One thing I would like to add, > If you take a look on SiFive Core IP > > >> https://www.sifive.com/risc-v-core-ip you can see there are > > >> different SKUs of RISC-V core. Just take some as exampl,e > S51 - Single core > U54 - Single core > S76 - Single core > U74- single core > U54-MC - Multicore which is 4*U54 cores +1*S51 core > U74-MC - Multicore which is 4*U74 core + 1*S7 core > > Those are the combinations of core IP. Silicon vendor can get those > core IPs and combine them to the RISC-V processor. To have > CoreInfoHobLib libraries for each different core (not multicore) to > build up the core capability is reasonable and makes sense. For the > multicore, it just pulling the single core CoreInfoHobLib to build > up the SMBIOS table for the multicore processor. Those libraries > look duplicate in logically, however only one instance of > CoreInfoHobLib is built in for multiple identical cores in > physically view. Maybe we still can move some identical core into > the core-specific library but it is not worthwhile. OK, lets start with the *full* diff of E51 and U54 from the (admittedly slightly dated) devel-riscvplatforms branch: <<< --- ./E51/Library/PeiCoreInfoHobLib/CoreInfoHob.c 2020-05-28 12:12:11.211028141 +0100 +++ ./U54/Library/PeiCoreInfoHobLib/CoreInfoHob.c 2020-05-28 12:12:11.211028141 +0100 @@ -7,6 +7,8 @@ **/ +#include + [LL] U54 inserts this file in a different location, this is not actual divergence. // // The package level header files this module uses // @@ -19,21 +21,15 @@ #include #include #include -#include [LL] Interestingly, only E51 actually includes this, but both files *use* it - this is a bug in U54 caused by the separation. -#include [LL] This is the other end of the files placing this inlude in a different location. -#include - [LL] This header is irrelevant and unused. Present only in E51. #include -#include -#include [LL] Included in different location for E51/U54. #include -#include #include +#include [LL] sbi_scratch.h included in different order between platforms. +#include [LL] Included in different location for E51/U54 (other end of). #include /** - Function to build core specific information HOB. RISC-V SMBIOS DXE driver collect - this information and build SMBIOS Type44. + Function to build core specific information HOB. [LL] Different documentation description for the otherwise identical functions. @param ParentProcessorGuid Parent processor od this core. ParentProcessorGuid could be the same as CoreGuid if one processor has @@ -41,19 +37,19 @@ @param ParentProcessorUid Unique ID of pysical processor which owns this core. @param HartId Hart ID of this core. @param IsBootHart TRUE means this is the boot HART. - @param GuidHobData Pointer to receive EFI_HOB_GUID_TYPE. + @param GuidHobdata Pointer to RISC_V_PROCESSOR_SPECIFIC_HOB_DATA. [LL] Different capitalisation of input variable and different documentation for the same parameter in the identical functions. E51 gets the former correct, U54 the latter. @return EFI_SUCCESS The PEIM initialized successfully. **/ EFI_STATUS EFIAPI -CreateE51CoreProcessorSpecificDataHob ( +CreateU54CoreProcessorSpecificDataHob ( [LL] We reach the first *real* difference between the two - the name of the function. This could have been addressed with different .inf files with different -D cflags. IN EFI_GUID *ParentProcessorGuid, IN UINTN ParentProcessorUid, IN UINTN HartId, IN BOOLEAN IsBootHart, - OUT RISC_V_PROCESSOR_SPECIFIC_HOB_DATA **GuidHobData + OUT RISC_V_PROCESSOR_SPECIFIC_HOB_DATA **GuidHobdata [LL] Again, difference only in capitalisation. ) { RISC_V_PROCESSOR_SPECIFIC_HOB_DATA *CoreGuidHob; @@ -64,7 +60,7 @@ DEBUG ((DEBUG_INFO, "%a: Entry.\n", __FUNCTION__)); - if (GuidHobData == NULL) { + if (GuidHobdata == NULL) { [LL] Again, difference only in capitalisation. return EFI_INVALID_PARAMETER; } @@ -80,7 +76,7 @@ FirmwareContextHartSpecific, ParentProcessorGuid, ParentProcessorUid, - (EFI_GUID *)PcdGetPtr (PcdSiFiveE51CoreGuid), + (EFI_GUID *)PcdGetPtr (PcdSiFiveU54CoreGuid), [LL] Different Pcd names. HartId, IsBootHart, &ProcessorSpecDataHob @@ -109,7 +105,7 @@ DEBUG ((DEBUG_INFO, " *MachineImplId = 0x%x\n", ProcessorSpecDataHob.ProcessorSpecificData.MachineImplId.Value64_L)); // - // Build GUID HOB for E51 core, this is for SMBIOS type 44 + // Build GUID HOB for U54 core. [LL] Different comments for identical code. // ProcessorSpecDataHobGuid = PcdGetPtr (PcdProcessorSpecificDataGuidHobGuid); CoreGuidHob = (RISC_V_PROCESSOR_SPECIFIC_HOB_DATA *)BuildGuidDataHob (ProcessorSpecDataHobGuid, (VOID *)&ProcessorSpecDataHob, sizeof (RISC_V_PROCESSOR_SPECIFIC_HOB_DATA)); @@ -117,7 +113,7 @@ DEBUG ((DEBUG_ERROR, "Fail to create GUID HOB of SiFive E51 core.\n")); ASSERT (FALSE); } - *GuidHobData = CoreGuidHob; + *GuidHobdata = CoreGuidHob; [LL] Again, difference only in capitalisation. return EFI_SUCCESS; } @@ -135,17 +131,21 @@ **/ EFI_STATUS EFIAPI -CreateE51ProcessorSmbiosDataHob ( +CreateU54ProcessorSmbiosDataHob ( [LL] Difference in name only. IN UINTN ProcessorUid, - OUT RISC_V_PROCESSOR_SMBIOS_HOB_DATA **SmbiosHobPtr + IN RISC_V_PROCESSOR_SMBIOS_HOB_DATA **SmbiosHobPtr [LL] I am going to go out on a limb here and suggest one of the above is incorrect, and once that is corrected, these two lines would be identical. ) { EFI_GUID *GuidPtr; RISC_V_PROCESSOR_TYPE4_HOB_DATA ProcessorDataHob; RISC_V_PROCESSOR_TYPE7_HOB_DATA L1InstCacheDataHob; + RISC_V_PROCESSOR_TYPE7_HOB_DATA L1DataCacheDataHob; + RISC_V_PROCESSOR_TYPE7_HOB_DATA L2CacheDataHob; [LL] Here is the first functional difference. RISC_V_PROCESSOR_SMBIOS_HOB_DATA SmbiosDataHob; RISC_V_PROCESSOR_TYPE4_HOB_DATA *ProcessorDataHobPtr; RISC_V_PROCESSOR_TYPE7_HOB_DATA *L1InstCacheDataHobPtr; + RISC_V_PROCESSOR_TYPE7_HOB_DATA *L1DataCacheDataHobPtr; + RISC_V_PROCESSOR_TYPE7_HOB_DATA *L2CacheDataHobPtr; [LL] Which could be merged with this inside an ifdef. RISC_V_PROCESSOR_SMBIOS_HOB_DATA *SmbiosDataHobPtr; if (SmbiosHobPtr == NULL) { @@ -155,7 +155,7 @@ // Build up SMBIOS type 7 L1 instruction cache record. // ZeroMem((VOID *)&L1InstCacheDataHob, sizeof (RISC_V_PROCESSOR_TYPE7_HOB_DATA)); - CopyGuid (&L1InstCacheDataHob.PrcessorGuid, (EFI_GUID *)PcdGetPtr (PcdSiFiveE51CoreGuid)); + CopyGuid (&L1InstCacheDataHob.PrcessorGuid, (EFI_GUID *)PcdGetPtr (PcdSiFiveU54CoreGuid)); [LL] Difference in name only. L1InstCacheDataHob.ProcessorUid = ProcessorUid; L1InstCacheDataHob.SmbiosType7Cache.SocketDesignation = TO_BE_FILLED_BY_VENDOR; L1InstCacheDataHob.SmbiosType7Cache.CacheConfiguration = RISC_V_CACHE_CONFIGURATION_CACHE_LEVEL_1 | \ @@ -173,7 +173,59 @@ GuidPtr = (EFI_GUID *)PcdGetPtr (PcdProcessorSmbiosType7GuidHobGuid); L1InstCacheDataHobPtr = (RISC_V_PROCESSOR_TYPE7_HOB_DATA *)BuildGuidDataHob (GuidPtr, (VOID *)&L1InstCacheDataHob, sizeof (RISC_V_PROCESSOR_TYPE7_HOB_DATA)); if (L1InstCacheDataHobPtr == NULL) { - DEBUG ((DEBUG_ERROR, "Fail to create GUID HOB of SiFive E51 core L1 instruction cache RISC_V_PROCESSOR_TYPE7_HOB_DATA.\n")); + DEBUG ((DEBUG_ERROR, "Fail to create GUID HOB of SiFive U54 core L1 instruction cache RISC_V_PROCESSOR_TYPE7_HOB_DATA.\n")); [LL] Difference in name only. + ASSERT (FALSE); + } + [LL] Below starts the fundamental difference between the two: + // + // Build up SMBIOS type 7 L1 data cache record. + // + ZeroMem((VOID *)&L1DataCacheDataHob, sizeof (RISC_V_PROCESSOR_TYPE7_HOB_DATA)); + CopyGuid (&L1DataCacheDataHob.PrcessorGuid, (EFI_GUID *)PcdGetPtr (PcdSiFiveU54CoreGuid)); + L1DataCacheDataHob.ProcessorUid = ProcessorUid; + L1DataCacheDataHob.SmbiosType7Cache.SocketDesignation = TO_BE_FILLED_BY_VENDOR; + L1DataCacheDataHob.SmbiosType7Cache.CacheConfiguration = RISC_V_CACHE_CONFIGURATION_CACHE_LEVEL_1 | \ + RISC_V_CACHE_CONFIGURATION_LOCATION_INTERNAL | \ + RISC_V_CACHE_CONFIGURATION_ENABLED | \ + RISC_V_CACHE_CONFIGURATION_MODE_UNKNOWN; + L1DataCacheDataHob.SmbiosType7Cache.MaximumCacheSize = TO_BE_FILLED_BY_VENDOR; + L1DataCacheDataHob.SmbiosType7Cache.InstalledSize = TO_BE_FILLED_BY_VENDOR; + L1DataCacheDataHob.SmbiosType7Cache.SupportedSRAMType.Unknown = 1; + L1DataCacheDataHob.SmbiosType7Cache.CurrentSRAMType.Unknown = 1; + L1DataCacheDataHob.SmbiosType7Cache.CacheSpeed = TO_BE_FILLED_BY_VENDOR; + L1DataCacheDataHob.SmbiosType7Cache.ErrorCorrectionType = TO_BE_FILLED_BY_VENDOR; + L1DataCacheDataHob.SmbiosType7Cache.SystemCacheType = CacheTypeData; + L1DataCacheDataHob.SmbiosType7Cache.Associativity = TO_BE_FILLED_BY_VENDOR; + GuidPtr = (EFI_GUID *)PcdGetPtr (PcdProcessorSmbiosType7GuidHobGuid); + L1DataCacheDataHobPtr = (RISC_V_PROCESSOR_TYPE7_HOB_DATA *)BuildGuidDataHob (GuidPtr, (VOID *)&L1DataCacheDataHob, sizeof (RISC_V_PROCESSOR_TYPE7_HOB_DATA)); + if (L1DataCacheDataHobPtr == NULL) { + DEBUG ((DEBUG_ERROR, "Fail to create GUID HOB of SiFive U54 core L1 data cache RISC_V_PROCESSOR_TYPE7_HOB_DATA.\n")); + ASSERT (FALSE); + } + + // + // Build up SMBIOS type 7 L2 cache record. + // + ZeroMem((VOID *)&L2CacheDataHob, sizeof (RISC_V_PROCESSOR_TYPE7_HOB_DATA)); + CopyGuid (&L2CacheDataHob.PrcessorGuid, (EFI_GUID *)PcdGetPtr (PcdSiFiveU54CoreGuid)); + L2CacheDataHob.ProcessorUid = ProcessorUid; + L2CacheDataHob.SmbiosType7Cache.SocketDesignation = TO_BE_FILLED_BY_VENDOR; + L2CacheDataHob.SmbiosType7Cache.CacheConfiguration = RISC_V_CACHE_CONFIGURATION_CACHE_LEVEL_2 | \ + RISC_V_CACHE_CONFIGURATION_LOCATION_EXTERNAL | \ + RISC_V_CACHE_CONFIGURATION_ENABLED | \ + RISC_V_CACHE_CONFIGURATION_MODE_UNKNOWN; + L2CacheDataHob.SmbiosType7Cache.MaximumCacheSize = TO_BE_FILLED_BY_VENDOR; + L2CacheDataHob.SmbiosType7Cache.InstalledSize = TO_BE_FILLED_BY_VENDOR; + L2CacheDataHob.SmbiosType7Cache.SupportedSRAMType.Unknown = 1; + L2CacheDataHob.SmbiosType7Cache.CurrentSRAMType.Unknown = 1; + L2CacheDataHob.SmbiosType7Cache.CacheSpeed = TO_BE_FILLED_BY_VENDOR; + L2CacheDataHob.SmbiosType7Cache.ErrorCorrectionType = TO_BE_FILLED_BY_VENDOR; + L2CacheDataHob.SmbiosType7Cache.SystemCacheType = CacheTypeUnified; + L2CacheDataHob.SmbiosType7Cache.Associativity = TO_BE_FILLED_BY_VENDOR; + GuidPtr = (EFI_GUID *)PcdGetPtr (PcdProcessorSmbiosType7GuidHobGuid); + L2CacheDataHobPtr = (RISC_V_PROCESSOR_TYPE7_HOB_DATA *)BuildGuidDataHob (GuidPtr, (VOID *)&L2CacheDataHob, sizeof (RISC_V_PROCESSOR_TYPE7_HOB_DATA)); + if (L2CacheDataHobPtr == NULL) { + DEBUG ((DEBUG_ERROR, "Fail to create GUID HOB of SiFive U54 core L2 cache RISC_V_PROCESSOR_TYPE7_HOB_DATA.\n")); ASSERT (FALSE); } [LL] And the funamental difference ends here. @@ -181,7 +233,7 @@ // Build up SMBIOS type 4 record. // ZeroMem((VOID *)&ProcessorDataHob, sizeof (RISC_V_PROCESSOR_TYPE4_HOB_DATA)); - CopyGuid (&ProcessorDataHob.PrcessorGuid, (EFI_GUID *)PcdGetPtr (PcdSiFiveE51CoreGuid)); + CopyGuid (&ProcessorDataHob.PrcessorGuid, (EFI_GUID *)PcdGetPtr (PcdSiFiveU54CoreGuid)); [LL] Differ in name only. ProcessorDataHob.ProcessorUid = ProcessorUid; ProcessorDataHob.SmbiosType4Processor.Socket = TO_BE_FILLED_BY_VENDOR; ProcessorDataHob.SmbiosType4Processor.ProcessorType = CentralProcessor; @@ -196,7 +248,7 @@ ProcessorDataHob.SmbiosType4Processor.Status = TO_BE_FILLED_BY_CODE; ProcessorDataHob.SmbiosType4Processor.ProcessorUpgrade = TO_BE_FILLED_BY_VENDOR; ProcessorDataHob.SmbiosType4Processor.L1CacheHandle = TO_BE_FILLED_BY_RISC_V_SMBIOS_DXE_DRIVER; - ProcessorDataHob.SmbiosType4Processor.L2CacheHandle = 0xffff; + ProcessorDataHob.SmbiosType4Processor.L2CacheHandle = TO_BE_FILLED_BY_RISC_V_SMBIOS_DXE_DRIVER; [LL] Real diff. ProcessorDataHob.SmbiosType4Processor.L3CacheHandle = 0xffff; ProcessorDataHob.SmbiosType4Processor.SerialNumber = TO_BE_FILLED_BY_CODE; ProcessorDataHob.SmbiosType4Processor.AssetTag = TO_BE_FILLED_BY_VENDOR; @@ -212,24 +264,23 @@ GuidPtr = (EFI_GUID *)PcdGetPtr (PcdProcessorSmbiosType4GuidHobGuid); ProcessorDataHobPtr = (RISC_V_PROCESSOR_TYPE4_HOB_DATA *)BuildGuidDataHob (GuidPtr, (VOID *)&ProcessorDataHob, sizeof (RISC_V_PROCESSOR_TYPE4_HOB_DATA)); if (ProcessorDataHobPtr == NULL) { - DEBUG ((DEBUG_ERROR, "Fail to create GUID HOB of SiFive E51 core RISC_V_PROCESSOR_TYPE4_HOB_DATA.\n")); + DEBUG ((DEBUG_ERROR, "Fail to create GUID HOB of SiFive U54 core RISC_V_PROCESSOR_TYPE4_HOB_DATA.\n")); [LL] Difference in name only. ASSERT (FALSE); } ZeroMem((VOID *)&SmbiosDataHob, sizeof (RISC_V_PROCESSOR_SMBIOS_HOB_DATA)); SmbiosDataHob.Processor = ProcessorDataHobPtr; SmbiosDataHob.L1InstCache = L1InstCacheDataHobPtr; - SmbiosDataHob.L1DataCache = NULL; - SmbiosDataHob.L2Cache = NULL; + SmbiosDataHob.L1DataCache = L1DataCacheDataHobPtr; + SmbiosDataHob.L2Cache = L2CacheDataHobPtr; [LL] Real diff. SmbiosDataHob.L3Cache = NULL; GuidPtr = (EFI_GUID *)PcdGetPtr (PcdProcessorSmbiosGuidHobGuid); SmbiosDataHobPtr = (RISC_V_PROCESSOR_SMBIOS_HOB_DATA *)BuildGuidDataHob (GuidPtr, (VOID *)&SmbiosDataHob, sizeof (RISC_V_PROCESSOR_SMBIOS_HOB_DATA)); if (SmbiosDataHobPtr == NULL) { - DEBUG ((DEBUG_ERROR, "Fail to create GUID HOB of SiFive E51 core RISC_V_PROCESSOR_SMBIOS_HOB_DATA.\n")); + DEBUG ((DEBUG_ERROR, "Fail to create GUID HOB of SiFive U54 core RISC_V_PROCESSOR_SMBIOS_HOB_DATA.\n")); [LL] Difference in name only. ASSERT (FALSE); } *SmbiosHobPtr = SmbiosDataHobPtr; return EFI_SUCCESS; } - >>> The meat of the difference between these two is less than 20% of the lines of code in each file - and it is mutually exclusive, not some horrific tangle of interdependencies. The story with the difference between U54 and U54MCCoreplex isn't much better, only works along a different axis. "It isn't worthwhile" in an open source project isn't a question of "how quickly can I create *one* new platform by copying instead of refactoring/reusing", but a judgement call between: - How many mistakes do I risk inserting while editing a new file as opposed to being directly able to see the differences I have caused while editing an existing file. - How much do I increase reviewing effort by doing this? - How much do I increase ongoing maintainership (or affect quality) by requiring bugs to be fixed in multiple places instead of one. Not to mention: - How many common pattern that could be broken out into common helper libraries do we miss when we need to compare every SoC/platform combination ever created, as opposed to being able to look at least at implementations covering families. If it isn't important enough to take that into consideration, it isn't important enough to upstream the SMBIOS support. / Leif