Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 00/19] Add support for RISC-V virt machine

[Heinrich Schuchardt <heinrich.schuchardt@canonical.com>]

On 2/17/23 10:16, Michael Brown wrote:
> On 17/02/2023 04:27, Sunil V L wrote:
>> On Thu, Feb 16, 2023 at 03:45:49PM -0700, dann frazier wrote:
>>>    Thanks for your work getting this merged! In the above wiki, it
>>> notes that GCC 12+ is not supported. Is that still accurate? If so,
>>> can you clarify what is blocking that?
>>
>> Please see https://bugzilla.tianocore.org/show_bug.cgi?id=4061.
>>
>> My attempt to fix this issue
>> (https://edk2.groups.io/g/devel/message/93831) was not accepted due to
>> the concerns that it can cause weird issues in CI.
>>
>> So, we are left with either support gcc <12 or gcc >=12. We can mandate
>> gcc 12 itself for RISC-V, but that change need to be done hand in hand
>> with CI tests moving to use gcc 12. Otherwise, it will break CI.
> 
> Is there an alternative (and presumably less ideal) way to force an 
> instruction cache invalidation?  For example, does a global TSO "fence" 
> instruction as used in RiscVInvalidateDataCacheAsm() also invalidate the 
> instruction cache?
> 
> If so, then a viable solution would be:
> 
> --- a/MdePkg/Library/BaseLib/RiscV64/FlushCache.S
> +++ b/MdePkg/Library/BaseLib/RiscV64/FlushCache.S
> @@ -15,3 +15,7 @@ ASM_GLOBAL ASM_PFX(RiscVInvalidateDataCacheAsm)
>   ASM_PFX(RiscVInvalidateInstCacheAsm):
> -    fence.i
> +#ifdef __riscv_zifencei
> +       fence.i
> +#else
> +       fence
> +#endif
>       ret
> 
> 
> This would also permit EDK2 to be used on implementations that genuinely 
> do not provide the fence.i instruction.
> 
> Michael
> 

fence.i is the right instruction to use. The problem are not platforms 
that do not provide the fence.i instruction but that the fence.i 
instruction was removed from RVGC64 in the specification.

Now all programs like OpenSBI, U-Boot, Linux have to be compiled with 
different -march parameters for GCC11 and GCC12.

Sunil suggested dropping support for GCC < 12. This seems to be the 
easiest approach. An alternative would be adding a GCC12 profile to 
BaseTools/Conf/tools_def.template but that would create a high effort.

Best regards

Heinrich