BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCEL
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20240422T053451Z
TZURL:https://www.tzurl.org/zoneinfo-outlook/America/Los_Ang
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Central Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
Hey Rebecca!
We actually have the following repo on
[github/secureboot_objects](https://github.com/microsoft/secureboot_objects)
where you can get Secure Boot default releases and ask questions directly to
the team that manages secure boot at Microsoft.
To answer your question,
The 2011 certi
On 11/5/2024 7:46 AM, Rebecca Cran wrote:
On 11/5/24 8:40 AM, Gerd Hoffmann wrote:
Has nasm gained support for arm? IIRC it's a x86-only assembler (and
the website says so too ...).
Yup, you're right - I'd completely forgotten about that. I guess my
point was that on Windows the .S files tha
On 11/5/24 8:40 AM, Gerd Hoffmann wrote:
Has nasm gained support for arm? IIRC it's a x86-only assembler (and
the website says so too ...).
Yup, you're right - I'd completely forgotten about that. I guess my
point was that on Windows the .S files that we have for Arm don't get
built, so we l
On Tue, Nov 05, 2024 at 06:55:55AM -0700, Rebecca Cran wrote:
> On 11/5/24 5:58 AM, Gerd Hoffmann wrote:
> > On Wed, Oct 23, 2024 at 05:48:46PM -0600, Rebecca Cran wrote:
> > > I've been wondering if it might be worth adding nasm files to ArmPkg,
> > > ArmPlatformPkg etc. to allow platforms to be b
On Tue, Nov 05, 2024 at 06:52:42AM -0700, Rebecca Cran wrote:
> On 11/5/24 6:08 AM, Gerd Hoffmann wrote:
> > On Mon, Oct 28, 2024 at 08:34:34PM -0600, Rebecca Cran wrote:
> > > See the attached screenshot or
> > > https://github.com/tianocore/edk2/pull/5907#issuecomment-2408745999 .
> > >
> > > Th
Thanks, I’ll merge this after the stable tag.
On Tue, Nov 5, 2024, at 5:45 AM, Gerd Hoffmann wrote:
> On Thu, Oct 17, 2024 at 08:21:54PM -0600, Rebecca Cran wrote:
>> Cross-compilation to platforms other than IA32 and X64 work by setting an
>> environment variable such as GCC_AARCH64_PREFIX that c
On 11/5/24 5:58 AM, Gerd Hoffmann wrote:
On Wed, Oct 23, 2024 at 05:48:46PM -0600, Rebecca Cran wrote:
I've been wondering if it might be worth adding nasm files to ArmPkg,
ArmPlatformPkg etc. to allow platforms to be built with VS2022 - mainly
because different compilers can detect different is
On 11/5/24 6:08 AM, Gerd Hoffmann wrote:
On Mon, Oct 28, 2024 at 08:34:34PM -0600, Rebecca Cran wrote:
See the attached screenshot or
https://github.com/tianocore/edk2/pull/5907#issuecomment-2408745999 .
The PR was marked stale by the bot and the PR author only responded two
weeks later - which
On Mon, Oct 28, 2024 at 08:34:34PM -0600, Rebecca Cran wrote:
> See the attached screenshot or
> https://github.com/tianocore/edk2/pull/5907#issuecomment-2408745999 .
>
> The PR was marked stale by the bot and the PR author only responded two
> weeks later - which would have been one week too late
On Wed, Oct 23, 2024 at 05:48:46PM -0600, Rebecca Cran wrote:
> I've been wondering if it might be worth adding nasm files to ArmPkg,
> ArmPlatformPkg etc. to allow platforms to be built with VS2022 - mainly
> because different compilers can detect different issues with the code.
What is nasm? I
On Thu, Oct 17, 2024 at 08:21:54PM -0600, Rebecca Cran wrote:
> Cross-compilation to platforms other than IA32 and X64 work by setting an
> environment variable such as GCC_AARCH64_PREFIX that contains the path/name
> of the cross-compiler without the "gcc", "objcopy" etc. suffix.
>
> On IA32 and
Hi,
> This pattern seen during the EFI stub preamble is also seen during OVMF
> startup, so it seems this is some common EFI VAR ? related code. At OVMF
> startup this seems to repeat a number of times before Grub starts.
>
> ===> If I move OVMF to pflash disks for code + vars, this issue does
This creates a default pxb-cxl (bus_nr=0xc0) bridge with two
cxl root ports on sbsa-ref. And the memory layout places 64K
space for the cxl host bridge register regions(CHBCR) in the
sbsa-ref memmap.
In addition, this support indepentent mmio32(32M) & mmio64(1M)
space for cxl components.
To provi
v1 -> v2:
- provide CXL exclusive MMIO32 & MMIO64 space
- hard coded two cxl root ports
RFC because
- Many contents are ported from Jonathan' patch on qemu virt design
- Less experience and not particularly confident in sbsa-ref address space
design
so this might be stupidly broken in a way I'
Hi,
> > > Yep, that should work.
>
> Should we include this fix also in ConnectVirtioPciRng() in
> OvmfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c ?
Yes, and PlatformBootManagerLibLight (used by arm/riscv) needs this too.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:
This adds relevant definitions and descriptions of acpi0016, acpi0017
and CEDT to support CXL.
1) To prevent breaking the original pcie mmio space, this adds
exclusive mmio32 & mmio64 space for cxl host.
2) This defines the pcie bus range of cxl host is 0xc0 ~ 0xff, since
the pxb-cxl-host as well
v1 -> v2:
- PCDs values about CXL exclusive MMIO32 & MMIO64 space
- CXL Bus range: 0xc0 ~ 0xff
- PCIE ecam space & Cxl ecam space
- CEDT format
RFC because
- Many contents are ported from Jonathan' patch on qemu virt design
- Bring plenty of PCDs values and modifying the original PCIE values
- L
This adds relevant definitions and descriptions of acpi0016, acpi0017
and CEDT to support CXL.
1) To prevent breaking the original pcie mmio space, this adds
exclusive mmio32 & mmio64 space for cxl host.
2) This defines the pcie bus range of cxl host is 0xc0 ~ 0xff, since
the pxb-cxl-host as well
v1 -> v2:
- PCDs values about CXL exclusive MMIO32 & MMIO64 space
- CXL Bus range: 0xc0 ~ 0xff
- PCIE ecam space & Cxl ecam space
- CEDT format
RFC because
- Many contents are ported from Jonathan' patch on qemu virt design
- Bring plenty of PCDs values and modifying the original PCIE values
- L
v2 -> v3:
- Put each struct into the file for the spec they were introduced
RFC because
- Less experience and not particularly confident in edk2 area
I am trying to support cxl on Qemu sbsa-ref platform, but it relies on CXL ACPI
elements
within compiled UEFI flash instead of virt/i386 using qem
This adds #defines and struct typedefs for the various structure
types in the CXL Early Discovery Table (CEDT).
Signed-off-by: Yuquan Wang
---
MdePkg/Include/IndustryStandard/Cxl20.h | 38
MdePkg/Include/IndustryStandard/Cxl30.h | 46 +
MdePkg/Include
23 matches
Mail list logo
