BZ:2562 - EDK CI for RISC-V architecture Add yaml file for EDK2 CI testing on RiscVPlatformPkg. Signed-off-by: Abner Chang <abner.chang@...> Cc: Sean Brogan <sean.brogan@...> Cc: Leif

BZ:2562 - EDK CI for RISC-V architecture. This set of patches enale RISC-V architecture on EDK2 CI test process. Signed-off-by: Abner Chang <abner.chang@...> Cc: Sean Brogan

If it is *just* a revert, then the risk is often low enough to not slip the date. But I think, as you say, this is something that restores original behaviour - but leaving the code different from the

Liming, I assume that CVE-2019-14559 relates to problems with network drivers within NetworkPkg. BZ 2032 and this patch fix address incorrect usage of IP4 protocol by ShellPkg 'ping' command

Hi Pete, TL;DR: \o/ Thanks for doing this cleanup. I'll go through these more carefully early next week, no need to send a v2 before that.

Ard: I think this change is OK. Ack-by: Liming Gao <liming.gao@...> Thanks Liming

Maciej: I see you submit the patch. So, you are in the loop. I don't invite you again. 😊 Yes. I also want to get your opinion for this change. Do you think whether this fix is in CVE scope?

Typo; I meant FVMAIN_COMPACT, not DXEFV. Laszlo

No, QEMU does not make any assumptions here. QEMU simply grabs both pflash chips (the order is not random, it can be specified on the command line -- in fact the QEMU user is expected to specify in

Laszlo, Thanks for the detailed response on the patch. Always happy to learn about stuff from the past. Liming, I am currently the maintainer of NetworkPkg :) If you require additional feedback

Yes, exactly. I'm unaware of any VMs running in clouds that use "-bios" with OVMF. It certainly seems a terrible idea, regardless of live migration. You're mixing up small details. OVMF_CODE.fd is

OK. I'll do that for v2. /Pete

If the contents of the header need to be visible outside of the module, then the header needs to be moved outside of the module. So move the header to Silicon/Broadcom/Drivers/Include/Net/ and add

Hi Ard, Yeah, I don't like it either. I kind of expected you guys to comment on it, so that we can discuss what you think the better approach should be. Do you think it'd make sense to create a

Thank you! Please allow me one additional comment on CpuS3DataDxe however: According to the comments in UefiCpuPkg/CpuS3DataDxe: [...] this module does not support hot plug CPUs. This module

This looks fishy. Won't this cause *every* module that incorporates this .dec to add . to its include path?

With the ACPI source for the Pi 3 and Pi 4 being identical, we can finally factorize it. Signed-off-by: Pete Batard <pete@...> --- Platform/RaspberryPi/{RPi3 => }/AcpiTables/AcpiTables.h |

This basically copies all of the RPi4 platform ACPI source into RPi3 since the last commit updates the code to serve both platforms. No alteration of original ACPI source files were applied. Whereas

* Update the OEM IDs and base revision numbers. * Move RPI_SYSTEM_TIMER_BASE_ADDRESS to AcpiTables.h. * Add RPi3 constants and conditional blocks according to model. Signed-off-by: Pete Batard

The ACPI interrupts are not the same across different Raspberry Pi platforms therefore moving them into AcpiTables.h will help with ACPI code factorization. Signed-off-by: Pete Batard