Hi Ming, (+Mike, -Martin)

(Apologies, I had last week off work.)

On Tue, Jun 23, 2020 at 14:02:59 +0000, Huangming (Mark) wrote:

Right now we are using edk2-platforms open source code as a part to
build our ARM platform UEFI implementations.
Due to our production development work flow, we need to upload a
formal edk2-platforms open source release tar ball
to our company database as a reference.

As edk2-platforms doesn't have release, it is hard for us to explain
to company audit office where the code comes from
and why this open source doesn't have release.

So - first of all, you can always reference a commit hash for your
upload. That will never change.

So is it possible to release edk2-platforms just like edk2 release
every three months?

We have discussed doing that. Realistically, I don't think we're going
to hit that for 2020.08, but having public requests for it like this
will certainly help push it higher up on the todo list.

Best Regards,

Leif

Hi,

Currently it is not based on SPCI interface, but discussions have started
in that direction also.

But I think from non-secure world it will be simple OP-TEE communication
like it happens between a CA and TA now, but on secure side, OPTEE-STMM
communication may be based on SPCI interface.

Regards,
Sahil Malhotra

Which openssl release version will be chosen to update？

There's a plan to complete both upgrade in Q3.

Regards,
Jian

May I ask when we will update OpenSSl，Do we have any plan? Now edk2 are using openssl 1.1.1d，and when I update openssl to release 1.1.1f, I meet an issue that TlsDxe initial failed.

On 06/25/20 22:47, Peter Wiehe wrote:

On 25.06.20 13:05, Laszlo Ersek wrote:

On 06/17/20 02:20, Peter Wiehe wrote:

Hello,

can You tell me what qemu command is used to run OVMF?

Use whatever qemu-system-x86_64 command you would otherwise use, with
the following remarks:

(1) Do not use "-bios" or "-L".

Thanks to all for the helpful replies!

But why shouldn't I use "-bios"?

Because the UEFI variable store needs to exist in an emulated flash
chip, and "-bios" doesn't do that.

If you use "-bios", OVMF can only fake the UEFI variable runtime
services for the guest in such a way that does not meet the UEFI spec.

People should have stopped using "-bios" with OVMF since QEMU 1.6 (that
means 2013-08-15). I've several times considered killing "-bios" support
in OVMF altogether, but I'm just too annoyed at the thought of having to
explain myself to every (mistaken) "-bios" user.

So for now it's only the -D SMM_REQUIRE build of OVMF that forces users
-- for technical reasons, and not because I'm a pedant -- to use pflash
rather than "-bios".

Laszlo

Please check this page.
https://github.com/tianocore/tianocore.github.io/wiki/How-to-run-OVMF

Thanks,
Bob

On 06/17/20 02:20, Peter Wiehe wrote:

Hello,

can You tell me what qemu command is used to run OVMF?

Use whatever qemu-system-x86_64 command you would otherwise use, with
the following remarks:

(1) Do not use "-bios" or "-L".

(2) Do not use "-boot", in general. Special cases you can use:

-boot menu=on

-boot menu=on,splash-time=N

(See the QEMU manual for these.)

(3) For specifying a UEFI boot order for bootable devices, use the
"bootindex" device property. For example:

-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,drive=drive0,bus=scsi0.0,bootindex=0 \
-device scsi-cd,drive=drive1,bus=scsi0.0,bootindex=1 \
-device virtio-net-pci,netdev=net0,bootindex=2 \

The above would attempt booting first from a virtio-scsi hard disk, then
from a virtio-scsi CD-ROM, then from the network (PXEv4, PXEv6,
HTTP(S)v4, HTTP(S)v6).

(4) if you want your virtual machine to persistently save the
non-volatile UEFI variables across QEMU invocations, then copy the
OVMF_VARS.fd file to a separate file (such as "my-vars.fd") *before* you
first launch the virtual machine.

Then, use the following QEMU options:

-drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \
-drive if=pflash,format=raw,unit=1,file=my-vars.fd \

(5) If you don't care about the above kind of persistence, then you can use:

-drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd,snapshot=on \

(6) It's recommended to capture the firmware debug log (if you report a
problem, that's the first thing we ask for):

-debugcon file:debug.log \
-global isa-debugcon.iobase=0x402 \

(7) if you run an OVMF binary built with "-D SMM_REQUIRE", then add the
following too:

-machine q35,smm=on \
-global driver=cfi.pflash01,property=secure,value=on \

(8) Do not use "usb-uas" or "usb-bot" device models. If you absolutely
need USB mass storage in the guest, use "usb-storage". See commit
f9c59fa44ae2.


If you don't insist on the raw QEMU command line, then I strongly
suggest using OVMF with libvirt.

Thanks
Laszlo

On 06/20/20 08:35, Peter Wiehe wrote:

Hi, all!
I have built EDK II and then OVMF. Now I want to develop an UEFI application with EDK II. Is there any documentation about that?

I can give you three links:

http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F5B8B381E8@ORSMSX113.amr.corp.intel.com

https://bugzilla.tianocore.org/show_bug.cgi?id=1734

https://github.com/tianocore/edk2-libc/tree/master/AppPkg

Basically I think you'd first have to decide the kind of entry point you
want (UefiApplicationEntryPoint for a "standalone" UEFI application,
ShellCEntryLib for a shell application (ShellAppMain()), or LibC for a
standard C application (main())). Then you'd use whatever functionality
is available (services and protocols from UEFI, libraries from edk2,
standard C stuff from edk2-libc).

The following document also contains hints on applications:

https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide

Thanks
Laszlo

Hi Peter,

This pair of options should do the trick:

-drive if=pflash,format=raw,readonly,file=path/to/OVMF_CODE.fd
-drive if=pflash,format=raw,file=path/to/OVMF_VARS.fd

Note that the OVMF_CODE is mounted using read only - it consists of the code part of the built platform, while the OVMF_VARS is the EFI variable store, and hence is mounted using read/write.

Cheers,
Tom

Hi Peter,

I don’t recall a specific application-writer's-guide but the Driver Writer's Guide and the UEFI Specification are quite comprehensive.

That said, you want to have a look at existing applications, particularly at MdePkg/Application/HelloWorld to see how they are built. In particular, you will need these non-obvious things:

Your application will need to use UefiApplicationEntryPointLib to specify which function is the entry point.
Your application will need its own .inf module file and you will need to specify the .inf file in the platform .dsc file in the [Components] section. You then build your application by building that platform.

Hope that gets you started.

Cheers,
Tom

Thanks Laszlo for quick turnaround. I can see my comment now.

Mayur

On Wed, May 27, 2020 at 02:16 PM, Laszlo Ersek wrote:

Laszlo

Hi laszlo,

I have newly joined this discuss@edk2.groups.io group. I posted a comment on this thread https://edk2.groups.io/g/discuss/topic/74206642#228 couple of days back. But do not see my comment here. Can you please let me know what is the issue here.

Thanks,
Mayur

Good morning!

I'm getting a bit desperate, so posting here for any ideas :-)
I've been working on porting Haiku's x86_64 EFI bootloader over to ARM.

We're super close, but have been hung up for a while with the following.

We can successfully make a call to EFI's runtime services (printing hello for example)
However, the second call to EFI always hangs with similar errors.

In the example below i'm booting as a cd, but sd card, etc suffer the same fate.

qemu boot:
qemu-system-arm -bios /usr/share/edk2/arm/QEMU_EFI.fd -M virt -cdrom haiku-mmc.image -m 2048

[Bds]Booting UEFI Misc Device 2
BlockSize : 512
LastBlock : A5FFF
FatDiskIo: Cache Page OutBound occurred!
FSOpen: Open '\EFI\BOOT\BOOTARM.EFI' Success
[Bds] Expand PciRoot(0x0)/Pci(0x2,0x0) -> PciRoot(0x0)/Pci(0x2,0x0)/HD(1,MBR,0x00000000,0x9FF6,0x1D394)/\EFI\BOOT\BOOTARM.EFI
BdsDxe: loading Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x2,0x0)
[Security] 3rd party image[0] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x2,0x0)/HD(1,MBR,0x00000000,0x9FF6,0x1D394)/\EFI\BOOT\BOOTARM.EFI.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BD994928
Loading driver at 0x000BC570000 EntryPoint=0x000BC570138
Loading driver at 0x000BC570000 EntryPoint=0x000BC570138
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BEFFD290
ProtectUefiImageCommon - 0xBD994928
- 0x00000000BC570000 - 0x000000000004A4E4
!!!!!!!! ProtectUefiImageCommon - Section Alignment(0x20) is incorrect !!!!!!!!
BdsDxe: starting Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x2,0x0)

Data Abort Exception PC at 0xBC570D34 CPSR 0x60000013
Data Abort Exception PC at 0xBC570D34 CPSR 0x60000013 nZCveaift_svc

R0 0xBFA58F10 R1 0x00043028 R2 0x0003C088 R3 0x00800080
R4 0xBFA58010 R5 0xBD994790 R6 0xBC5AC088 R7 0x00043030
R8 0x00000001 R9 0xBEFFD4D8 R10 0x00000000 R11 0x00000000
R12 0xBFA9ACC0 SP 0xBFA7A9F8 LR 0xBC5709A4 PC 0xBC570D34
DFSR 0x00000005 DFAR 0x008000AC IFSR 0x00000000 IFAR 0x00000000
Translation fault on Section: read from 0x008000AC

ASSERT [ArmCpuDxe] /builddir/build/BUILD/edk2-edk2-stable202002/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c(267): ((BOOLEAN)(0==1))



$ ~/Code/efi_analyzer/efianalyze ./objects/haiku/arm/release/system/boot/efi/haiku_loader.efi
Offset to PE: 0x40
Machine type: 0x01c2, ARM or Thumb ("interworking")
NumberOfSymbols should be 0.
Characteristics: 0x0306
* The file is executable.
* COFF line numbers were stripped from the file.
* The computer supports 32-bit words.
* Debugging information was removed.
Image type: PE32
Size of optional header: 0x90 != 0xe0
Subsystem: EFI application
ImageBase: 0x0
SectionAlignment: 0x20
SizeOfImage: 0x4a4e4
.reloc.address: 0x0
.reloc.size: 0x0
BaseOfCode: 0x138
AddressOfEntryPoint: 0x138
Number of sections: 2
Section[0]: .reloc
Virtual size: 0x0
Virtual address: 0x0
Size of raw data: 0x0
Pointer to raw data: 0x0
End of raw data: 0x0
Characteristics: 0x42100040
* The section contains initialized data.
* Align data on a 1-byte boundary.
* The section can be discarded as needed.
* The section can be read.
Section[1]: .text
Virtual size: 0x4a300
Virtual address: 0x138
Size of raw data: 0x4a3ac
Pointer to raw data: 0x138
End of raw data: 0x4a4e4
Characteristics: 0xe0500020
* The section contains executable code.
* Align data on a 1-byte boundary.
* Align data on a 8-byte boundary.
* The section can be executed as code.
* The section can be read.
* The section can be written to.



Relevant sources:

Linker script:
https://git.haiku-os.org/haiku/tree/src/system/ldscripts/arm/boot_loader_efi.ld
Our "fake" Pe:
https://git.haiku-os.org/haiku/tree/src/system/boot/platform/efi/arch/arm/crt0-efi-arm.S
Relocations:
https://git.haiku-os.org/haiku/tree/src/system/boot/platform/efi/arch/arm/relocation_func.cpp
Our efi_main:
https://git.haiku-os.org/haiku/tree/src/system/boot/platform/efi/start.cpp#n171



Nightly ARM build with latest compiled code (it will autoboot in qemu due to EFI/BOOT/BOOTARM.EFI)
https://s3.wasabisys.com/haiku-nightly/arm/haiku-master-hrev54358-arm-mmc.zip


Any help (no matter how minor) would be appreciated!

Thanks!

-- Alex

Hi Sahil,

This proposal interests us too. Got a question for you. I assume that OPTEE-STMM interfaces will be based on SPCI specifications, both in secure and non-secure side. Is that assumption right?

Hi, all!
I have built EDK II and then OVMF. Now I want to develop an UEFI application with EDK II. Is there any documentation about that?

Greetings
Peter

Hello,

can You tell me what qemu command is used to run OVMF?


Thanks in advance

Peter

Hello Mayur,

On 06/24/20 17:21, mgudmeti@... wrote:

On Wed, May 27, 2020 at 02:16 PM, Laszlo Ersek wrote:

Laszlo

Hi laszlo,

I have newly joined this discuss@edk2.groups.io group. I posted a comment on this thread https://edk2.groups.io/g/discuss/topic/74206642#228 couple of days back. But do not see my comment here. Can you please let me know what is the issue here.

Thanks for the heads-up.

For some reason, I still do not receive moderation notifications from
groups.io, for the edk2-discuss mailing list. I receive such
notifications for edk2-devel, and I check the pending messages there
every day. But I'm left in the dark about edk2-discuss :(

And now that I'm checking it, I'm seeing your message (I'll approve it
in a moment) -- what's more, I'm seeing 5 more stuck messages, the
oldest one dating back to Jun 17.

That's terrible :(

I'm really sorry. I don't know how we can fix this problem with
edk2-discuss.

I have now sent an email to <support@groups.io>, with subject

not receiving "Message Approval Needed" notifications for edk2-discuss

Hopefully this will improve in the near future.

Thanks
Laszlo

On 06/24/20 10:53, mzktsn@... wrote:

Hello,

I have noticed some functions that provide access
in the CPU Saved State Registers (ReadSaveStateRegister/WriteSaveStateRegister() etc.)
Would like to ask if it is possible to use their functionality from code
inside /MdeModulePkg/Core/PiSmmCore/PiSmmCore.c file? And what modifications should be
made in order to achieve it if is viable?

Not sure *why* you'd like to access specific registers from the SMM save
state map in PiSmmCore.

But, these functions are exposed though a standard interface too; see
EFI_SMM_CPU_PROTOCOL (or rather "EFI_MM_CPU_PROTOCOL") in the PI spec,
volume 4, section "4.3 CPU Save State Access Services".

In edk2, PiSmmCpuDxeSmm provides the protocol; the member functions are
delegated to the platform's SmmCpuFeaturesLib instance, and there are
general fallback implementations too.

See for example SmmReadSaveState() in
"UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c":

Status = SmmCpuFeaturesReadSaveStateRegister (CpuIndex, Register,
Width, Buffer);
if (Status == EFI_UNSUPPORTED) {
Status = ReadSaveStateRegister (CpuIndex, Register, Width, Buffer);
}
return Status;

where SmmCpuFeaturesReadSaveStateRegister() comes from the platform's
library instance, and ReadSaveStateRegister() is the generic/fallback
code, from "UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c".

Generally speaking, in a module that's different from PiSmmCpuDxeSmm,
you could introduce a depex or a protocol notify on
EFI_SMM_CPU_PROTOCOL, and use its member functions.

Whether that applies *specifically* to PiSmmCore, I can't say. (Again I
don't know *why* you need that functionality there.)

Probably best to address the PiSmmCore owners directly; run the
following command in edk2:

$ python BaseTools/Scripts/GetMaintainer.py \
-l MdeModulePkg/Core/PiSmmCore/PiSmmCore.c

MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
Jian J Wang <jian.j.wang@...>
Hao A Wu <hao.a.wu@...>
Eric Dong <eric.dong@...>
Ray Ni <ray.ni@...>
devel@edk2.groups.io

I've added those people to the CC list now.

General hint: when posting a query (to any technical mailing list,
really), always include the "why", not just the "what" / "how".

Thanks
Laszlo