From: "Leif Lindholm" <leif@nuviainc.com>
To: "Chang, Abner (HPS SW/FW Technologist)" <abner.chang@hpe.com>
Cc: "Schaefer, Daniel (DualStudy)" <daniel.schaefer@hpe.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Chen, Gilbert" <gilbert.chen@hpe.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
"Bret.Barkelew@microsoft.com" <Bret.Barkelew@microsoft.com>,
"sean.brogan@microsoft.com" <sean.brogan@microsoft.com>
Subject: Re: [edk2-devel] [PATCH v2 0/3] New RISC-V Patches - Why in edk2-platforms
Date: Thu, 28 May 2020 12:54:49 +0100 [thread overview]
Message-ID: <20200528115449.GE1923@vanye> (raw)
In-Reply-To: <TU4PR8401MB04291FEEC648E63D3663E314FFB70@TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM>
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 <IndustryStandard/RiscVOpensbi.h>
+
[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 <Library/DebugLib.h>
#include <Library/FirmwareContextProcessorSpecificLib.h>
#include <Library/HobLib.h>
-#include <Library/PcdLib.h>
[LL]
Interestingly, only E51 actually includes this, but both files *use*
it - this is a bug in U54 caused by the separation.
-#include <IndustryStandard/RiscVOpensbi.h>
[LL]
This is the other end of the files placing this inlude in a different location.
-#include <Library/ResourcePublicationLib.h>
-
[LL]
This header is irrelevant and unused. Present only in E51.
#include <Library/RiscVEdk2SbiLib.h>
-#include <ProcessorSpecificHobData.h>
-#include <RiscVImpl.h>
[LL]
Included in different location for E51/U54.
#include <sbi/sbi_hart.h>
-#include <sbi/sbi_scratch.h>
#include <sbi/sbi_platform.h>
+#include <sbi/sbi_scratch.h>
[LL]
sbi_scratch.h included in different order between platforms.
+#include <RiscVImpl.h>
[LL]
Included in different location for E51/U54 (other end of).
#include <SmbiosProcessorSpecificData.h>
/**
- 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
next prev parent reply other threads:[~2020-05-28 11:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 13:39 [PATCH v2 0/3] New RISC-V Patches Daniel Schaefer
2020-05-15 13:39 ` [PATCH v2 1/3] ProcessorPkg/RiscVOpensbLib: Add opensbi submodule Daniel Schaefer
2020-05-20 11:51 ` Leif Lindholm
2020-05-15 13:39 ` [PATCH v2 2/3] ProcessorPkg/Library: Add RiscVOpensbiLib Daniel Schaefer
2020-05-20 12:00 ` Leif Lindholm
2020-05-20 14:44 ` Daniel Schaefer
2020-05-15 13:39 ` [PATCH v2 3/3] ProcessorPkg/Library: Add RiscVEdk2SbiLib Daniel Schaefer
2020-05-20 18:27 ` Leif Lindholm
2020-05-29 12:43 ` [edk2-devel] " Daniel Schaefer
2020-05-29 13:15 ` Leif Lindholm
2020-05-20 11:43 ` [edk2-devel] [PATCH v2 0/3] New RISC-V Patches Leif Lindholm
2020-05-20 16:03 ` [edk2-devel] [PATCH v2 0/3] New RISC-V Patches - Why in edk2-platforms Daniel Schaefer
2020-05-20 16:07 ` Daniel Schaefer
2020-05-20 16:17 ` Daniel Schaefer
2020-05-21 6:59 ` Abner Chang
2020-05-28 11:54 ` Leif Lindholm [this message]
2020-05-29 14:41 ` Abner Chang
[not found] ` <b55ee3ec-74de-532e-01f7-bd24a327d00b@hpe.com>
[not found] ` <CY4PR21MB0743421F39A05298FBCFBAA0EF8F0@CY4PR21MB0743.namprd21.prod.outlook.com>
[not found] ` <MN2PR11MB4461D8666DE6DA1E7D4B5B9BD28F0@MN2PR11MB4461.namprd11.prod.outlook.com>
[not found] ` <TU4PR8401MB1182F755F76709FF1D46D3F2FF8F0@TU4PR8401MB1182.NAMPRD84.PROD.OUTLOOK.COM>
[not found] ` <MN2PR11MB4461442E7462457D6C20F6F2D28F0@MN2PR11MB4461.namprd11.prod.outlook.com>
[not found] ` <MW2PR2101MB092494AB8318628E06B62089E18F0@MW2PR2101MB0924.namprd21.prod.outlook.com>
2020-06-03 11:57 ` [edk2-devel] Where to put RISC-V packages Daniel Schaefer
2020-06-03 15:02 ` Abner Chang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200528115449.GE1923@vanye \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox