Date   

Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 4:29 PM, Ethin Probst <harlydavidsen@...> wrote:

Your suggestion of adding 0x240 worked. I'm able to successfully step
through the code now. Thank you!


OK that makes sense. The address in the add-symbol-file command is not the load address of the image, but the start address of the text section. So that is why you had to add 0x240. 

Sorry I had to work backwards from how it works, but maybe that info will be helpful for others?

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@...>
wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug"
at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from
Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0  0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1  ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2  _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at
/home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3  0x000000007fead316 in ?? ()
#4  0x000000007e4f7518 in ?? ()
#5  0x000000007feab5c7 in ?? ()
#6  0x000000007fea3520 in ?? ()
#7  0x0000000101000000 in ?? ()
#8  0x0000000000000030 in ?? ()
#9  0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2   GCC inline implementation of BaseLib processor specific functions.
3
4   Copyright (c) 2006 - 2020, Intel Corporation. All rights
reserved.<BR>
5   Portions copyright (c) 2008 - 2009, Apple Inc. All rights
reserved.<BR>
6   SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug

OK that is interesting…. +576 -> 0x240 witch is about the size of the
PE/COFF header.

For mach-O (macOS executables) we have to link at 0x240 to make space for
the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section
starts at 0x7e4b8240? So try adding 0x240 to the load address on the
add-symbol-file command. If that does not work trip subtracting 0x240 from
the load address.

We would need to dump out the UsbAudio.efi file to figure out exactly what
is going on. What distro are you on? Do you have the readpe utility? I’m not
sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick look.

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB
myself.
:)

What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There
is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote
9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>
<mailto:afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>
<mailto:harlydavidsen@... <mailto:harlydavidsen@...>>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>
<https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>>) like this (from the main
EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers
and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the
image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump
into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might
be
a
little off on gdb specifics…. Also my terminology may be lldb
centric.

Easy one 1st. When you run on top of a debugger using
CpuBreakpoint()
works
great as the debugger hides its self from you. On x86
CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath  the exception 3 is going to get
handled
in
the unexpected exception handler, and that is probably in the CPUD
DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU
acts
a
lot
more like a JTAG hardware debugger than a pure software debugger.
Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the
CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target
for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is
a
handshake that describes the target and what registers are
available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So
this
changing the target definition might confuse the debugger. To be
safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the
debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at
a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst




-- 
Signed,
Ethin D. Probst




Re: Help with debugging

Ethin Probst
 

Your suggestion of adding 0x240 worked. I'm able to successfully step
through the code now. Thank you!

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@...>
wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug"
at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from
Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0 0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1 ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2 _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at
/home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3 0x000000007fead316 in ?? ()
#4 0x000000007e4f7518 in ?? ()
#5 0x000000007feab5c7 in ?? ()
#6 0x000000007fea3520 in ?? ()
#7 0x0000000101000000 in ?? ()
#8 0x0000000000000030 in ?? ()
#9 0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2 GCC inline implementation of BaseLib processor specific functions.
3
4 Copyright (c) 2006 - 2020, Intel Corporation. All rights
reserved.<BR>
5 Portions copyright (c) 2008 - 2009, Apple Inc. All rights
reserved.<BR>
6 SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
OK that is interesting…. +576 -> 0x240 witch is about the size of the
PE/COFF header.

For mach-O (macOS executables) we have to link at 0x240 to make space for
the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section
starts at 0x7e4b8240? So try adding 0x240 to the load address on the
add-symbol-file command. If that does not work trip subtracting 0x240 from
the load address.

We would need to dump out the UsbAudio.efi file to figure out exactly what
is going on. What distro are you on? Do you have the readpe utility? I’m not
sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick look.

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB
myself.
:)
What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?
Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There
is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote
9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>
<mailto:afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>
<mailto:harlydavidsen@... <mailto:harlydavidsen@...>>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>
<https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>>) like this (from the main
EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers
and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the
image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump
into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might
be
a
little off on gdb specifics…. Also my terminology may be lldb
centric.

Easy one 1st. When you run on top of a debugger using
CpuBreakpoint()
works
great as the debugger hides its self from you. On x86
CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath the exception 3 is going to get
handled
in
the unexpected exception handler, and that is probably in the CPUD
DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU
acts
a
lot
more like a JTAG hardware debugger than a pure software debugger.
Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the
CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target
for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is
a
handshake that describes the target and what registers are
available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So
this
changing the target definition might confuse the debugger. To be
safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the
debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at
a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst
--
Signed,
Ethin D. Probst


Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@...> wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug" at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0  0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1  ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2  _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at /home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3  0x000000007fead316 in ?? ()
#4  0x000000007e4f7518 in ?? ()
#5  0x000000007feab5c7 in ?? ()
#6  0x000000007fea3520 in ?? ()
#7  0x0000000101000000 in ?? ()
#8  0x0000000000000030 in ?? ()
#9  0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2   GCC inline implementation of BaseLib processor specific functions.
3
4   Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.<BR>
5   Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>
6   SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
 Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug

OK that is interesting…. +576 -> 0x240 witch is about the size of the PE/COFF header. 

For mach-O (macOS executables) we have to link at 0x240 to make space for the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section starts at 0x7e4b8240? So try adding 0x240 to the load address on the add-symbol-file command. If that does not work trip subtracting 0x240 from the load address. 

We would need to dump out the UsbAudio.efi file to figure out exactly what is going on. What distro are you on? Do you have the readpe utility? I’m not sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick look. 

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself.
:)

What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be
a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath  the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts
a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst







-- 
Signed,
Ethin D. Probst


Re: [edk2-platforms][PATCH] IpmiFeaturePkg : Rename IPMI Macro and Structure Defintions

Oram, Isaac W
 

Reviewed-by: Isaac Oram <isaac.w.oram@...>

-----Original Message-----
From: manickavasakam karpagavinayagam <manickavasakamk@...>
Sent: Friday, June 11, 2021 2:52 PM
To: devel@edk2.groups.io
Cc: Oram, Isaac W <isaac.w.oram@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Felixp@...; DOPPALAPUDI, HARIKRISHNA <harikrishnad@...>; Jha, Manish <manishj@...>; Bobroff, Zachary <zacharyb@...>; KARPAGAVINAYAGAM, MANICKAVASAKAM <manickavasakamk@...>; gaoliming@...
Subject: [edk2-platforms][PATCH] IpmiFeaturePkg : Rename IPMI Macro and Structure Defintions

Rename the EFI_IPMI_MSG_GET_BMC_EXEC_RSPB, EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
IPMI_BMC_IN_FORCED_UPDATE_MODE
---
.../IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c
index 1e0c132508..d788b48867 100644
--- a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c
+++ b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c
@@ -242,7 +242,7 @@ Returns:
EFI_STATUS Status;

UINT32 DataSize;

SM_CTRL_INFO *pBmcInfo;

- EFI_IPMI_MSG_GET_BMC_EXEC_RSP *pBmcExecContext;

+ IPMI_MSG_GET_BMC_EXEC_RSP *pBmcExecContext;

UINT32 Retries;

#ifdef FAST_VIDEO_SUPPORT

EFI_VIDEOPRINT_PROTOCOL *VideoPrintProtocol;

@@ -301,14 +301,14 @@ Returns:
Status = IpmiSendCommand (

&IpmiInstance->IpmiTransport,

IPMI_NETFN_FIRMWARE, 0,

- EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT,

+ IPMI_GET_BMC_EXECUTION_CONTEXT,

NULL, 0,

IpmiInstance->TempData, &DataSize

);



- pBmcExecContext = (EFI_IPMI_MSG_GET_BMC_EXEC_RSP*)&IpmiInstance->TempData[0];

+ pBmcExecContext = (IPMI_MSG_GET_BMC_EXEC_RSP*)&IpmiInstance->TempData[0];

DEBUG ((DEBUG_INFO, "[IPMI] Operational status of BMC: 0x%x\n", pBmcExecContext->CurrentExecutionContext));

- if ((pBmcExecContext->CurrentExecutionContext == EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE) &&

+ if ((pBmcExecContext->CurrentExecutionContext == IPMI_BMC_IN_FORCED_UPDATE_MODE) &&

!EFI_ERROR (Status)) {

DEBUG ((DEBUG_ERROR, "[IPMI] BMC in Forced Update mode, skip waiting for BMC_READY.\n"));

IpmiInstance->BmcStatus = BMC_UPDATE_IN_PROGRESS;

--
2.25.0.windows.1


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


Re: [edk2][PATCH V1] MdePkg : Add IPMI Macro and Structure Defintions to resolve the IPMI build error

Oram, Isaac W
 

Reviewed-by: Isaac Oram <isaac.w.oram@...>

-----Original Message-----
From: manickavasakam karpagavinayagam <manickavasakamk@...>
Sent: Friday, June 11, 2021 2:50 PM
To: devel@edk2.groups.io
Cc: Oram, Isaac W <isaac.w.oram@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Felixp@...; DOPPALAPUDI, HARIKRISHNA <harikrishnad@...>; Jha, Manish <manishj@...>; Bobroff, Zachary <zacharyb@...>; KARPAGAVINAYAGAM, MANICKAVASAKAM <manickavasakamk@...>; gaoliming@...
Subject: [edk2][PATCH V1] MdePkg : Add IPMI Macro and Structure Defintions to resolve the IPMI build error

Build error reported for missing structures IPMI_SET_BOOT_OPTIONS_RESPONSE, EFI_IPMI_MSG_GET_BMC_EXEC_RSP and macros EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FULL_RUNTIME/EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE
when using edk2-platforms\Features\Intel\OutOfBandManagement\IpmiFeaturePkg

MdePkg : Rename IPMI Macro and Structure Defintions

Rename the EFI_IPMI_MSG_GET_BMC_EXEC_RSPB, EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
IPMI_BMC_IN_FORCED_UPDATE_MODE
---

Notes:
V1 :
- Rename the EFI_IPMI_MSG_GET_BMC_EXEC_RSPB, EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
- EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
- IPMI_BMC_IN_FORCED_UPDATE_MODE

0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch | 61 ++++++++++++++++++++
MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h | 4 ++
MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h | 18 ++++++
3 files changed, 83 insertions(+)

diff --git a/0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch b/0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch
new file mode 100644
index 0000000000..16d149e2d8
--- /dev/null
+++ b/0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch
@@ -0,0 +1,61 @@
+From c5e221cfe5d815883f39b71667b6e8f644a27390 Mon Sep 17 00:00:00 2001
+From: manickavasakam karpagavinayagam <manickavasakamk@...>
+Date: Thu, 10 Jun 2021 14:59:22 -0400
+Subject: [edk2][PATCH] MdePkg : Add IPMI Macro and Structure Defintions
+to resolve the IPMI build error
+
+Build error reported for missing structures
+IPMI_SET_BOOT_OPTIONS_RESPONSE, EFI_IPMI_MSG_GET_BMC_EXEC_RSP and
+macros EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
+EFI_FIRMWARE_BMC_IN_FULL_RUNTIME/EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE
+when using
+edk2-platforms\Features\Intel\OutOfBandManagement\IpmiFeaturePkg
+---
+ MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h | 4 ++++
+MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h | 19
++++++++++++++++++++
+ 2 files changed, 23 insertions(+)
+
+diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+index 79db55523d..d7cdd3a865 100644
+--- a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
++++ b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+@@ -186,6 +186,10 @@ typedef struct {
+ UINT8 ParameterData[0];
+ } IPMI_SET_BOOT_OPTIONS_REQUEST;
+
++typedef struct {
++ UINT8 CompletionCode:8;
++} IPMI_SET_BOOT_OPTIONS_RESPONSE;
++
+ //
+ // Definitions for Get System Boot options command // diff --git
+a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+index 2d892dbd5a..1c692cc792 100644
+--- a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
++++ b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+@@ -17,4 +17,23 @@
+ // All Firmware commands and their structure definitions to follow
+here //
+
++/*----------------------------------------------------------------------------------------
++ Definitions for Get BMC Execution Context
++----------------------------------------------------------------------
++------------------*/ #define EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
++0x23
++
++//
++// Constants and Structure definitions for "Get Device ID" command to
++follow here // typedef struct {
++ UINT8 CurrentExecutionContext;
++ UINT8 PartitionPointer;
++} EFI_IPMI_MSG_GET_BMC_EXEC_RSP;
++
++//
++// Current Execution Context responses //
++#define EFI_FIRMWARE_BMC_IN_FULL_RUNTIME 0x10
++#define EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE 0x11
++
+ #endif
+--
+2.25.0.windows.1
+
diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
index 79db55523d..d7cdd3a865 100644
--- a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+++ b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
@@ -186,6 +186,10 @@ typedef struct {
UINT8 ParameterData[0]; } IPMI_SET_BOOT_OPTIONS_REQUEST; +typedef struct {+ UINT8 CompletionCode:8;+} IPMI_SET_BOOT_OPTIONS_RESPONSE;+ // // Definitions for Get System Boot options command //diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
index 2d892dbd5a..c4cbe2349b 100644
--- a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+++ b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
@@ -17,4 +17,22 @@
// All Firmware commands and their structure definitions to follow here // +// ----------------------------------------------------------------------------------------+// Definitions for Get BMC Execution Context+// ----------------------------------------------------------------------------------------+#define IPMI_GET_BMC_EXECUTION_CONTEXT 0x23++//+// Constants and Structure definitions for "Get Device ID" command to follow here+//+typedef struct {+ UINT8 CurrentExecutionContext;+ UINT8 PartitionPointer;+} IPMI_MSG_GET_BMC_EXEC_RSP;++//+// Current Execution Context responses+//+#define IPMI_BMC_IN_FORCED_UPDATE_MODE 0x11+ #endif--
2.25.0.windows.1


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


Re: [PATCH v1 3/5] MdeModulePkg: MemoryProfileInfo: Updated MessageLength calculation

Kun Qin
 

Hi Hao,

Thanks for pointing out the missing place. Will update this accordingly.

This patch series needs a PI spec update, I thought I should mark all changes with BZ#### before the spec update is taken. But I can drop them for the next patch version.

Regards,
Kun

On 06/11/2021 00:46, Wu, Hao A wrote:
-----Original Message-----
From: Kun Qin <kuqin12@...>
Sent: Thursday, June 10, 2021 9:43 AM
To: devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>
Subject: [PATCH v1 3/5] MdeModulePkg: MemoryProfileInfo: Updated
MessageLength calculation

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

This change replaced the calculation of communication buffer size from
explicitly adding the size of each member with the OFFSET macro function.
This will make the structure field defition change transparent to consumers.
I think there is one missing place in function GetSmramProfileData():
MinimalSizeNeeded = sizeof (EFI_GUID) +
sizeof (UINTN) +
MAX (sizeof (SMRAM_PROFILE_PARAMETER_GET_PROFILE_INFO),
MAX (sizeof (SMRAM_PROFILE_PARAMETER_GET_PROFILE_DATA_BY_OFFSET),
sizeof (SMRAM_PROFILE_PARAMETER_RECORDING_STATE)));
More inline comments below:


Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>

Signed-off-by: Kun Qin <kuqin12@...>
---
MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c | 20
+++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)

diff --git
a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
index 191c31068545..39ed8b2e0484 100644
--- a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
+++
b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
@@ -1190,7 +1190,9 @@ GetSmramProfileData (
CommRecordingState->Header.ReturnStatus = (UINT64)-1;
CommRecordingState->RecordingState =
MEMORY_PROFILE_RECORDING_DISABLE;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
Please help to drop the explicit mention of BZ3398 in the comment.
How about using:
//
// The CommHeader->MessageLength contains a definitive value, thus UINTN cast is safe here.
//
There are 4 more similar cases below.
Best Regards,
Hao Wu

+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
Status = SmmCommunication->Communicate (SmmCommunication,
CommBuffer, &CommSize);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "SmramProfile: SmmCommunication - %r\n",
Status)); @@ -1213,7 +1215,9 @@ GetSmramProfileData (
CommRecordingState->Header.ReturnStatus = (UINT64)-1;
CommRecordingState->RecordingState =
MEMORY_PROFILE_RECORDING_DISABLE;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
SmmCommunication->Communicate (SmmCommunication, CommBuffer,
&CommSize);
}

@@ -1230,7 +1234,9 @@ GetSmramProfileData (
CommGetProfileInfo->Header.ReturnStatus = (UINT64)-1;
CommGetProfileInfo->ProfileSize = 0;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
Status = SmmCommunication->Communicate (SmmCommunication,
CommBuffer, &CommSize);
ASSERT_EFI_ERROR (Status);

@@ -1261,7 +1267,9 @@ GetSmramProfileData (
CommGetProfileData->Header.DataLength = sizeof
(*CommGetProfileData);
CommGetProfileData->Header.ReturnStatus = (UINT64)-1;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
Buffer = (UINT8 *) CommHeader + CommSize;
Size -= CommSize;

@@ -1320,7 +1328,9 @@ GetSmramProfileData (
CommRecordingState->Header.ReturnStatus = (UINT64)-1;
CommRecordingState->RecordingState =
MEMORY_PROFILE_RECORDING_ENABLE;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
SmmCommunication->Communicate (SmmCommunication, CommBuffer,
&CommSize);
}

--
2.31.1.windows.1


Re: Help with debugging

Ethin Probst
 

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug" at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0 0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1 ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2 _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at /home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3 0x000000007fead316 in ?? ()
#4 0x000000007e4f7518 in ?? ()
#5 0x000000007feab5c7 in ?? ()
#6 0x000000007fea3520 in ?? ()
#7 0x0000000101000000 in ?? ()
#8 0x0000000000000030 in ?? ()
#9 0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2 GCC inline implementation of BaseLib processor specific functions.
3
4 Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.<BR>
5 Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>
6 SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself.
:)
What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?
Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be
a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts
a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst


--
Signed,
Ethin D. Probst


Re: GSOC 2021 EXT4 driver Project

Michael D Kinney
 

Hi Michael,

Thanks for the feedback.

#4 should be clarified as adding a new feature package called Ext4Pkg. Not adding EXT4 to the existing AdvancedFeaturePkg.

Mike

-----Original Message-----
From: Michael Kubacki <mikuback@...>
Sent: Friday, June 11, 2021 11:23 AM
To: devel@edk2.groups.io; leif@...; Kinney, Michael D <michael.d.kinney@...>
Cc: pedro.falcato@...
Subject: Re: [edk2-devel] GSOC 2021 EXT4 driver Project

I had done some of the early work in moving content to
edk2-platforms/Features. Just wanted to add my support for maintaining
this as a vendor neutral feature there.

#4 in the options list is not really what AdvancedFeaturePkg intended
for, there's more details here -
https://github.com/tianocore/edk2-platforms/tree/master/Features/Intel#AdvancedFeaturePkg.

- Michael

On 6/10/2021 1:54 PM, Leif Lindholm wrote:
edk2-platforms/Features/Ext4Pkg sounds good to me too.

/
Leif

On Thu, Jun 10, 2021 at 17:38:17 +0000, Michael D Kinney wrote:
Hi Pedro,

After thinking about this, I think I would prefer Option (4).

The proposed landing zone would be a new Ext4Pkg in the edk2-platforms repository in the Features directory.

edk2-platforms/Features/Intel/Ext4Pkg

All the features in that directory and not specific to Intel. There are other email discussions about moving some of
that content up a level, so an alternative path would be:

edk2-platforms/Features/Ext4Pkg

Best regards,

Mike


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
Sent: Monday, May 24, 2021 12:27 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] GSOC 2021 EXT4 driver Project

Hi everyone,

Me and my project have been selected for GSoC this year, under Michael Kinney and bret. Thank you for the opportunity
to collaborate with you and improve Tianocore!
If anyone has any questions, please fire away :)
How do I get started? I'd like to find some easier tasks as to start trying out patch submission and generally
programming in a firmware environment.
Also, I've been talking with my mentors and a relevant question to ask the mailing list is: Where should we put the
EXT4 driver?
Michael said there are other filesystems in MdeModulePkg, but it might be getting too big and proposed the following
options:

1) EXT4 in new package in edk2 repo as a peer to FatPkg.
2) EXT4 in edk2 repo in MdeModulePkg
3) EXT4 in edk2-platforms advanced feature package.
4) EXT4 in edk2 advanced feature package

As someone that's still learning how to navigate the project's tree(s), this is a bit over my head and so I'd like your
opinion on the matter.
Also, I would love if someone could point me to some good reading material and/or examples of the package/build system,
as I couldn't find documentation on those
and my previous experiment with Tianocore involved looking at FatPkg and mindlessly copying what it was doing.

Thanks,

Pedro








TianoCore Community Meeting Minutes - June

Soumya Guptha
 

TianoCore Community Meeting

June 10, 2021

 

EVENTS:

  • UEFI Plugfest (update from Dick Wilkins)
  • Plugfest is being planned for early April 2022 in Oregon. Detailed planning of the schedule and logistics will kick off in a few weeks.
  • ICWG is hosting UEFI Virtual Plugfest webinars, if you are interested in presenting, please send your proposals to UEFI plugfest.

 

Google Summer of Code (update from Nate Desimone)

  • Google has announced this year's Summer of Code students. TianoCore is mentoring 7 students this year, which is more than 3 times larger than our previous high of 2 students! The list of projects is available here: https://summerofcode.withgoogle.com/organizations/6376892141142016/
  • Students have started submitting patches. Students need to complete projects by mid-august.
  • Community Action: Provide feedback to students and support them to be successful.

 

Stable Tag updates:

  • EDK2 Stable Tag 202105 has been released. EDK2 Stable Tag 202108 is collecting features.
  • Details here: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
  • Action: Bugzilla needs to be updated with the latest Stable tag info – Mike Kinney will update.
  • From Google summer of code projects, if there are any features impacting EDK2 core, we need to make sure that those features get into the stable tag. Mentors need to work on getting those features in and communicate with Liming Gao. Action: Nate Desimone plans to communicate with the mentors and educate them on the process.

 

Stewards Meeting Download (update from Mike Kinney)

  • Discussed process issue - During beginning soft/hard releases, we need to add a RC1 & RC0 tags when soft and hard freeze are announced to support validation. Lazlo plans to write an RFC on this topic. Once this approves, liming may need to update the documentation.
  • There is some confusion with Roles and Responsibilities (R&R) between maintainers and reviewers around reviewing packet (push label/merge). Reviewers also have push access. But Maintainer is the gate keeper and should approve the final changes to the package. Action for Stewards: We need to update the documentation (development process, who we are and any other wiki pages that are impacted) and clarify the R&R.
  • Enhance support on previous Stable Tags - we will support critical bug fixes and security issues to the most recent Stable Tag.
    • Release process between stable tags is typically 3 months. Today we are operating reactively based on request. We want to have a standard process. If there is a critical issue (such as a security issue)/bug fixes in the subprojects, we want to be more proactive by having a standard operating process to have these propagated into our most recent stable tag.
    • Action: Liming to update the support of Stable Tags to reflect this change.

 

Opens

  • (Open from Nate) NVME 2.0 just got formally published. Most interesting feature to be evaluated is “Zoned name space” feature. Any UEFI spec changes. Action: Evaluate and determine to see if we need to support this feature. What will be our plan for doing this? A topic for Ray Ni’s design meeting. Soumya to communicate with Ray Ni on this topic.
  • Update from Soumya: Puja Pandya moved on to pursue another opportunity. Soumya Guptha will continue to lead TianoCore Community Management.

 

Acknowledgements

Mike Kinney thanked Kevin Davis for doing analysis for UEFI 2.8 specification gaps.

 

 

Regards,

Soumya Guptha

TianoCore Community Manager

 

 

 

 


Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...> wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself. :)

What do you get from the following gdb commands? 
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at this
point:
1. Either I get the wrong debug information (I get source code but the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint() is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t have
a
debugger hooked in underneath  the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the symbols.
The
reason for me suggesting this flow is the debugger has a flexible concept
of
what the target is. If you load symbols that will create a target for a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available. I
seem
to remember QEMU exports some of the system registers, like the control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you need
to
specify the load address to get the symbols to resolve. One trick I use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and it
prints out the load address and offset (you can use the offset directly).
It
is also a good way to debug why your symbols are not quite loaded at the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







-- 
Signed,
Ethin D. Probst




Re: Help with debugging

Ethin Probst
 

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself. :)

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?
Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at this
point:
1. Either I get the wrong debug information (I get source code but the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint() is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t have
a
debugger hooked in underneath the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the symbols.
The
reason for me suggesting this flow is the debugger has a flexible concept
of
what the target is. If you load symbols that will create a target for a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available. I
seem
to remember QEMU exports some of the system registers, like the control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you need
to
specify the load address to get the symbols to resolve. One trick I use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and it
prints out the load address and offset (you can use the offset directly).
It
is also a good way to debug why your symbols are not quite loaded at the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst


--
Signed,
Ethin D. Probst


Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...> wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is no gdb with Xcode, so I have to use lldb for my day job. 

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000” 
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at this
point:
1. Either I get the wrong debug information (I get source code but the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint() works
great as the debugger hides its self from you. On x86 CpuBreakpoint() is an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t have a
debugger hooked in underneath  the exception 3 is going to get handled in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts a lot
more like a JTAG hardware debugger than a pure software debugger. Also note
that CpuDeadLoop() is an infinite loop, so you can modify the loop variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the symbols. The
reason for me suggesting this flow is the debugger has a flexible concept of
what the target is. If you load symbols that will create a target for a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available. I seem
to remember QEMU exports some of the system registers, like the control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked around
zero. They get loaded into memory and relocated, so that is why you need to
specify the load address to get the symbols to resolve. One trick I use is
to load the ELF (or PE/COFF) build output directly into the debugger. This
lets you poke around the image at the linked address. You can disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and it
prints out the load address and offset (you can use the offset directly). It
is also a good way to debug why your symbols are not quite loaded at the
correct address, as you can see what bytes/instructions should be at a given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









-- 
Signed,
Ethin D. Probst




Re: Help with debugging

Ethin Probst
 

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at this
point:
1. Either I get the wrong debug information (I get source code but the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint() works
great as the debugger hides its self from you. On x86 CpuBreakpoint() is an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t have a
debugger hooked in underneath the exception 3 is going to get handled in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts a lot
more like a JTAG hardware debugger than a pure software debugger. Also note
that CpuDeadLoop() is an infinite loop, so you can modify the loop variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the symbols. The
reason for me suggesting this flow is the debugger has a flexible concept of
what the target is. If you load symbols that will create a target for a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available. I seem
to remember QEMU exports some of the system registers, like the control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked around
zero. They get loaded into memory and relocated, so that is why you need to
specify the load address to get the symbols to resolve. One trick I use is
to load the ELF (or PE/COFF) build output directly into the debugger. This
lets you poke around the image at the linked address. You can disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and it
prints out the load address and offset (you can use the offset directly). It
is also a good way to debug why your symbols are not quite loaded at the
correct address, as you can see what bytes/instructions should be at a given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst




--
Signed,
Ethin D. Probst


Re: Help with debugging

Andrew Fish
 

On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...> wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at this point:
1. Either I get the wrong debug information (I get source code but the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be a little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint() works great as the debugger hides its self from you. On x86 CpuBreakpoint() is an INT 3h instruction (0xCC) and it causes an exception 3. If you don’t have a debugger hooked in underneath the exception 3 is going to get handled in the unexpected exception handler, and that is probably in the CPUD DXE driver or DXE Core or some such. So you are going to end up with the PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers it works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts a lot more like a JTAG hardware debugger than a pure software debugger. Also note that CpuDeadLoop() is an infinite loop, so you can modify the loop variable with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(), attach gdb. Now after you have the target established load the symbols. The reason for me suggesting this flow is the debugger has a flexible concept of what the target is. If you load symbols that will create a target for a stock x86-64 image. When you connect to the QEMU gdb-remote there is a handshake that describes the target and what registers are available. I seem to remember QEMU exports some of the system registers, like the control registers, so it is an extended version of the x86-64 target. So this changing the target definition might confuse the debugger. To be safe I always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked around zero. They get loaded into memory and relocated, so that is why you need to specify the load address to get the symbols to resolve. One trick I use is to load the ELF (or PE/COFF) build output directly into the debugger. This lets you poke around the image at the linked address. You can disassemble the functions to see what they look like, obviously you can read any variables. This can be useful if you get the unhandled exception and it prints out the load address and offset (you can use the offset directly). It is also a good way to debug why your symbols are not quite loaded at the correct address, as you can see what bytes/instructions should be at a given address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





Re: GSOC 2021 EXT4 driver Project

Michael Kubacki
 

I had done some of the early work in moving content to edk2-platforms/Features. Just wanted to add my support for maintaining this as a vendor neutral feature there.

#4 in the options list is not really what AdvancedFeaturePkg intended for, there's more details here - https://github.com/tianocore/edk2-platforms/tree/master/Features/Intel#AdvancedFeaturePkg.

- Michael

On 6/10/2021 1:54 PM, Leif Lindholm wrote:
edk2-platforms/Features/Ext4Pkg sounds good to me too.
/
Leif
On Thu, Jun 10, 2021 at 17:38:17 +0000, Michael D Kinney wrote:
Hi Pedro,

After thinking about this, I think I would prefer Option (4).

The proposed landing zone would be a new Ext4Pkg in the edk2-platforms repository in the Features directory.

edk2-platforms/Features/Intel/Ext4Pkg

All the features in that directory and not specific to Intel. There are other email discussions about moving some of that content up a level, so an alternative path would be:

edk2-platforms/Features/Ext4Pkg

Best regards,

Mike


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
Sent: Monday, May 24, 2021 12:27 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] GSOC 2021 EXT4 driver Project

Hi everyone,

Me and my project have been selected for GSoC this year, under Michael Kinney and bret. Thank you for the opportunity to collaborate with you and improve Tianocore!
If anyone has any questions, please fire away :)
How do I get started? I'd like to find some easier tasks as to start trying out patch submission and generally programming in a firmware environment.
Also, I've been talking with my mentors and a relevant question to ask the mailing list is: Where should we put the EXT4 driver?
Michael said there are other filesystems in MdeModulePkg, but it might be getting too big and proposed the following options:

1) EXT4 in new package in edk2 repo as a peer to FatPkg.
2) EXT4 in edk2 repo in MdeModulePkg
3) EXT4 in edk2-platforms advanced feature package.
4) EXT4 in edk2 advanced feature package

As someone that's still learning how to navigate the project's tree(s), this is a bit over my head and so I'd like your opinion on the matter.
Also, I would love if someone could point me to some good reading material and/or examples of the package/build system, as I couldn't find documentation on those
and my previous experiment with Tianocore involved looking at FatPkg and mindlessly copying what it was doing.

Thanks,

Pedro






Help with debugging

Ethin Probst
 

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at this point:
1. Either I get the wrong debug information (I get source code but the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys have
any advice?

--
Signed,
Ethin D. Probst


Re: [PATCH] MdeModulePkg/Bus/Pci/PciBusDxe: Increase the width of the data read during oprom shadow

Sumana Venur
 

Hello Maintainers

This patch is for MdeModulePkg/Bus. Please review and help with merging to master
It was sent a few months ago, might have been reviewed already. But due to CI failures and low importance it was lost.

Gerrit link - https://git-amr-7.devtools.intel.com/gerrit/#/c/117842/

Thanks
Sumana

-----Original Message-----
From: Venur, Sumana <sumana.venur@...>
Sent: Friday, June 11, 2021 9:38 AM
To: devel@edk2.groups.io
Cc: Venur, Sumana <sumana.venur@...>
Subject: [PATCH] MdeModulePkg/Bus/Pci/PciBusDxe: Increase the width of the data read during oprom shadow

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

Long times spent on shadowing oprom from graphics card to system memory. We are currently using 8 bit read cycles.
This needs to be wider, at least 32bit reads to reduce the time for oprom shadow

Signed-off-by: Sumana Venur <sumana.venur@...>
---
MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
index c994ed5fe3..a981f93f43 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
@@ -521,9 +521,9 @@ LoadOpRomImage (
//
PciDevice->PciRootBridgeIo->Mem.Read (
PciDevice->PciRootBridgeIo,
- EfiPciWidthUint8,
+ EfiPciWidthUint32,
RomBar,
- (UINT32) RomImageSize,
+ (UINT32) RomImageSize/sizeof(UINT32),
Image
);
RomInMemory = Image;
--
2.16.2.windows.1


[PATCH] MdeModulePkg/Bus/Pci/PciBusDxe: Increase the width of the data read during oprom shadow

Sumana Venur
 

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

Long times spent on shadowing oprom from graphics card to system memory. We are currently using 8 bit read cycles.
This needs to be wider, at least 32bit reads to reduce the time for oprom shadow

Signed-off-by: Sumana Venur <sumana.venur@...>
---
MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
index c994ed5fe3..a981f93f43 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
@@ -521,9 +521,9 @@ LoadOpRomImage (
//
PciDevice->PciRootBridgeIo->Mem.Read (
PciDevice->PciRootBridgeIo,
- EfiPciWidthUint8,
+ EfiPciWidthUint32,
RomBar,
- (UINT32) RomImageSize,
+ (UINT32) RomImageSize/sizeof(UINT32),
Image
);
RomInMemory = Image;
--
2.16.2.windows.1


[PATCH V1 4/4] Platform/NXP/LS1046aFrwyPkg: Add OEM specific DSDT generator

Vikas Singh
 

This patch adds platform specific DSDT generator
and Clk dsdt properties for LS1046AFRWY platform.

Signed-off-by: Vikas Singh <vikas.singh@...>
---
Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/Dsdt/Clk.asl =
| 60 +++++++++
Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/Dsdt/Dsdt.asl =
| 15 +++
Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiDsdtLib.inf =
| 39 ++++++
Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiDsdtLib/RawDsdtG=
enerator.c | 138 ++++++++++++++++++++
Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiLib.h =
| 23 ++++
Platform/NXP/LS1046aFrwyPkg/Include/Platform.h =
| 6 +-
Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc =
| 1 +
7 files changed, 281 insertions(+), 1 deletion(-)

diff --git a/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/Dsdt/Clk.asl b/P=
latform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/Dsdt/Clk.asl
new file mode 100644
index 0000000000..58541c3019
--- /dev/null
+++ b/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/Dsdt/Clk.asl
@@ -0,0 +1,60 @@
+/** @file=0D
+* DSDT : Dynamic Clock ACPI Information=0D
+*=0D
+* Copyright 2021 NXP=0D
+* Copyright 2021 Puresoftware Ltd.=0D
+*=0D
+* SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+*=0D
+**/=0D
+=0D
+Scope(_SB)=0D
+{=0D
+ Device(PCLK) {=0D
+ Name(_HID, "NXP0017")=0D
+ Name(CLK, 0) // Maximum Platform Clock (Hz)=0D
+ Name(CCLK, 0) // Maximum CPU Core Clock (MHz)=0D
+ Name(AVBL, 0)=0D
+ OperationRegion(RCWS, SystemMemory, DCFG_BASE, DCFG_LEN)=0D
+ Method(_REG,2) {=0D
+ if (Arg0 =3D=3D "RCWS") {=0D
+ Store(Arg1, AVBL)=0D
+ }=0D
+ }=0D
+ Field (RCWS, ByteAcc, NoLock, Preserve) {=0D
+ /* The below table provides the func of diff bits in 512 bits RCW da=
ta:=0D
+ SYS_PLL_CFG : 0-1 bits=0D
+ SYS_PLL_RAT : 2-6 bits=0D
+ SYSCLK_FREQ : 472-481 bits etc.=0D
+ Refer LS1046ARM for more info.=0D
+ For LS1046 RCWSRs are read as RCW[0:31] .=0D
+ */=0D
+ offset(0x100),=0D
+ RESV, 1,=0D
+ PRAT, 5,=0D
+ PCFG, 2,=0D
+ offset(0x103),=0D
+ CPRT, 6, // Cluster Group PLL Multiplier ratio=0D
+ offset(0x13B),=0D
+ HFRQ, 8, // Higher 8 bits of SYSCLK_FREQ=0D
+ RESX, 6,=0D
+ LFRQ, 2 // Lower bits of SYSCLK_FREQ=0D
+ }=0D
+=0D
+ Method(_INI, 0, NotSerialized) {=0D
+ /* Calculating Platform Clock */=0D
+ Local0 =3D (HFRQ<<2 | LFRQ) // Concatinating LFRQ at end of HFRQ=0D
+ Multiply(Local0, 500000, Local0)=0D
+ Multiply(Local0, PRAT, Local0)=0D
+ Divide(Local0, 3, , Local0)=0D
+ Store(Local0, CLK)=0D
+=0D
+ /* Calculating Maximum Core Clock */=0D
+ Local0 =3D (HFRQ<<2 | LFRQ) // Concatinating LFRQ at end of HFRQ=0D
+ Multiply(Local0, 500000, Local0)=0D
+ Divide(Local0, 3, , Local0)=0D
+ Divide(Local0, 1000000, , Local0) //Just the MHz part of SYSCLK.=0D
+ Multiply(Local0, CPRT, CCLK) // PLL_Ratio * SYSCLK, Max freq of clus=
ter=0D
+ }=0D
+ } // end of device PCLK=0D
+}=0D
diff --git a/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/Dsdt/Dsdt.asl b/=
Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/Dsdt/Dsdt.asl
new file mode 100644
index 0000000000..19f3f1c0e8
--- /dev/null
+++ b/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/Dsdt/Dsdt.asl
@@ -0,0 +1,15 @@
+/** @file=0D
+ Differentiated System Description Table Fields (DSDT)=0D
+=0D
+ Copyright 2021 NXP=0D
+ Copyright 2021 Puresoftware Ltd.=0D
+=0D
+ SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+=0D
+**/=0D
+=0D
+#include "Platform.h"=0D
+=0D
+DefinitionBlock("DsdtTable.aml", "DSDT", 2, "NXP ", "LS1046 ", EFI_ACPI_=
ARM_OEM_REVISION) {=0D
+ include ("Clk.asl")=0D
+}=0D
diff --git a/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiDsdt=
Lib.inf b/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiDsdtLib=
.inf
new file mode 100644
index 0000000000..ed5f9dd442
--- /dev/null
+++ b/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiDsdtLib.inf
@@ -0,0 +1,39 @@
+## @file=0D
+# Raw Table Generator=0D
+#=0D
+# Copyright 2021 NXP=0D
+# Copyright 2021 Puresoftware Ltd=0D
+#=0D
+# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+##=0D
+=0D
+[Defines]=0D
+ INF_VERSION =3D 0x00010019=0D
+ BASE_NAME =3D PlatformAcpiDsdtLib=0D
+ FILE_GUID =3D A97F70AC-3BB4-4596-B4D2-9F948EC12D17=0D
+ VERSION_STRING =3D 1.0=0D
+ MODULE_TYPE =3D DXE_DRIVER=0D
+ LIBRARY_CLASS =3D NULL|DXE_DRIVER=0D
+ CONSTRUCTOR =3D AcpiDsdtLibConstructor=0D
+ DESTRUCTOR =3D AcpiDsdtLibDestructor=0D
+=0D
+[Sources]=0D
+ PlatformAcpiDsdtLib/RawDsdtGenerator.c=0D
+ Dsdt/Dsdt.asl=0D
+=0D
+[Packages]=0D
+ DynamicTablesPkg/DynamicTablesPkg.dec=0D
+ EmbeddedPkg/EmbeddedPkg.dec=0D
+ MdePkg/MdePkg.dec=0D
+ MdeModulePkg/MdeModulePkg.dec=0D
+ Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dec=0D
+ Platform/NXP/ConfigurationManagerPkg/ConfigurationManagerPkg.dec=0D
+=0D
+[LibraryClasses]=0D
+ BaseLib=0D
+=0D
+[Pcd]=0D
+=0D
+[Protocols]=0D
+=0D
+[Guids]=0D
diff --git a/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiDsdt=
Lib/RawDsdtGenerator.c b/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/Plat=
formAcpiDsdtLib/RawDsdtGenerator.c
new file mode 100644
index 0000000000..7d886396ca
--- /dev/null
+++ b/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiDsdtLib/Raw=
DsdtGenerator.c
@@ -0,0 +1,138 @@
+/** @file=0D
+ Raw DSDT Table Generator=0D
+=0D
+ Copyright 2021 NXP=0D
+ Copyright 2021 Puresoftware Ltd.=0D
+=0D
+ SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+=0D
+**/=0D
+=0D
+#include <Library/AcpiLib.h>=0D
+#include <Library/DebugLib.h>=0D
+#include <Protocol/AcpiTable.h>=0D
+=0D
+// Module specific include files.=0D
+#include <AcpiTableGenerator.h>=0D
+#include <ConfigurationManagerObject.h>=0D
+#include <ConfigurationManagerHelper.h>=0D
+#include <Library/TableHelperLib.h>=0D
+#include <Protocol/ConfigurationManagerProtocol.h>=0D
+=0D
+#include "PlatformAcpiLib.h"=0D
+=0D
+/** Construct the ACPI table using the ACPI table data provided.=0D
+ This function invokes the Configuration Manager protocol interface=0D
+ to get the required hardware information for generating the ACPI=0D
+ table.=0D
+ If this function allocates any resources then they must be freed=0D
+ in the FreeXXXXTableResources function.=0D
+ @param [in] This Pointer to the table generator.=0D
+ @param [in] AcpiTableInfo Pointer to the ACPI Table Info.=0D
+ @param [in] CfgMgrProtocol Pointer to the Configuration Manager=0D
+ Protocol Interface.=0D
+ @param [out] Table Pointer to the constructed ACPI Table.=0D
+ @retval EFI_SUCCESS Table generated successfully.=0D
+ @retval EFI_INVALID_PARAMETER A parameter is invalid.=0D
+**/=0D
+STATIC=0D
+EFI_STATUS=0D
+EFIAPI=0D
+BuildRawDsdtTable (=0D
+ IN CONST ACPI_TABLE_GENERATOR * CONST This,=0D
+ IN CONST CM_STD_OBJ_ACPI_TABLE_INFO * CONST AcpiTableInfo,=0D
+ IN CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL * CONST CfgMgrProtocol,=
=0D
+ OUT EFI_ACPI_DESCRIPTION_HEADER ** CONST Table=0D
+ )=0D
+{=0D
+ ASSERT (This !=3D NULL);=0D
+ ASSERT (AcpiTableInfo !=3D NULL);=0D
+ ASSERT (CfgMgrProtocol !=3D NULL);=0D
+ ASSERT (Table !=3D NULL);=0D
+ ASSERT (AcpiTableInfo->TableGeneratorId =3D=3D This->GeneratorID);=0D
+=0D
+ if (AcpiTableInfo->AcpiTableData =3D=3D NULL) {=0D
+ // Add the dsdt aml code here.=0D
+ *Table =3D (EFI_ACPI_DESCRIPTION_HEADER *)&dsdt_aml_code;=0D
+ }=0D
+=0D
+ return EFI_SUCCESS;=0D
+}=0D
+=0D
+/** This macro defines the Raw Generator revision.=0D
+*/=0D
+#define DSDT_GENERATOR_REVISION CREATE_REVISION (1, 0)=0D
+=0D
+/** The interface for the Raw Table Generator.=0D
+*/=0D
+STATIC=0D
+CONST=0D
+ACPI_TABLE_GENERATOR RawDsdtGenerator =3D {=0D
+ // Generator ID=0D
+ CREATE_OEM_ACPI_TABLE_GEN_ID (PlatAcpiTableIdDsdt),=0D
+ // Generator Description=0D
+ L"ACPI.OEM.RAW.DSDT.GENERATOR",=0D
+ // ACPI Table Signature - Unused=0D
+ 0,=0D
+ // ACPI Table Revision - Unused=0D
+ 0,=0D
+ // Minimum ACPI Table Revision - Unused=0D
+ 0,=0D
+ // Creator ID=0D
+ TABLE_GENERATOR_CREATOR_ID_ARM,=0D
+ // Creator Revision=0D
+ DSDT_GENERATOR_REVISION,=0D
+ // Build Table function=0D
+ BuildRawDsdtTable,=0D
+ // No additional resources are allocated by the generator.=0D
+ // Hence the Free Resource function is not required.=0D
+ NULL,=0D
+ // Extended build function not needed=0D
+ NULL,=0D
+ // Extended build function not implemented by the generator.=0D
+ // Hence extended free resource function is not required.=0D
+ NULL=0D
+};=0D
+=0D
+/** Register the Generator with the ACPI Table Factory.=0D
+ @param [in] ImageHandle The handle to the image.=0D
+ @param [in] SystemTable Pointer to the System Table.=0D
+ @retval EFI_SUCCESS The Generator is registered.=0D
+ @retval EFI_INVALID_PARAMETER A parameter is invalid.=0D
+ @retval EFI_ALREADY_STARTED The Generator for the Table ID=0D
+ is already registered.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+AcpiDsdtLibConstructor (=0D
+ IN CONST EFI_HANDLE ImageHandle,=0D
+ IN EFI_SYSTEM_TABLE * CONST SystemTable=0D
+ )=0D
+{=0D
+ EFI_STATUS Status;=0D
+ Status =3D RegisterAcpiTableGenerator (&RawDsdtGenerator);=0D
+ DEBUG ((DEBUG_INFO, "OEM: Register DSDT Generator. Status =3D %r\n", Sta=
tus));=0D
+ ASSERT_EFI_ERROR (Status);=0D
+ return Status;=0D
+}=0D
+=0D
+/** Deregister the Generator from the ACPI Table Factory.=0D
+ @param [in] ImageHandle The handle to the image.=0D
+ @param [in] SystemTable Pointer to the System Table.=0D
+ @retval EFI_SUCCESS The Generator is deregistered.=0D
+ @retval EFI_INVALID_PARAMETER A parameter is invalid.=0D
+ @retval EFI_NOT_FOUND The Generator is not registered.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+AcpiDsdtLibDestructor (=0D
+ IN CONST EFI_HANDLE ImageHandle,=0D
+ IN EFI_SYSTEM_TABLE * CONST SystemTable=0D
+ )=0D
+{=0D
+ EFI_STATUS Status;=0D
+ Status =3D DeregisterAcpiTableGenerator (&RawDsdtGenerator);=0D
+ DEBUG ((DEBUG_INFO, "OEM: Deregister DSDT Generator. Status =3D %r\n", S=
tatus));=0D
+ ASSERT_EFI_ERROR (Status);=0D
+ return Status;=0D
+}=0D
diff --git a/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiLib.=
h b/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiLib.h
new file mode 100644
index 0000000000..e5f907a7d4
--- /dev/null
+++ b/Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiLib.h
@@ -0,0 +1,23 @@
+/** @file=0D
+ * Acpi lib headers=0D
+ *=0D
+ * Copyright 2021 NXP=0D
+ * Copyright 2021 Puresoftware Ltd=0D
+ *=0D
+ * SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+ *=0D
+**/=0D
+=0D
+=0D
+#ifndef LS1046AFRWY_PLATFORM_ACPI_LIB_H=0D
+#define LS1046AFRWY_PLATFORM_ACPI_LIB_H=0D
+=0D
+#include <PlatformAcpiTableGenerator.h>=0D
+=0D
+/** C array containing the compiled AML template.=0D
+ These symbols are defined in the auto generated C file=0D
+ containing the AML bytecode array.=0D
+*/=0D
+extern CHAR8 dsdt_aml_code[];=0D
+=0D
+#endif=0D
diff --git a/Platform/NXP/LS1046aFrwyPkg/Include/Platform.h b/Platform/NXP/=
LS1046aFrwyPkg/Include/Platform.h
index 19e879ec6d..b21e875f20 100644
--- a/Platform/NXP/LS1046aFrwyPkg/Include/Platform.h
+++ b/Platform/NXP/LS1046aFrwyPkg/Include/Platform.h
@@ -20,6 +20,10 @@
#define SVR_MAJOR(svr) (((svr) >> 4) & 0xf)=0D
#define SVR_MINOR(svr) (((svr) >> 0) & 0xf)=0D
=0D
+// PCLK : Dynamic Clock=0D
+#define DCFG_BASE 0x1EE0000 /* Device configuration da=
ta Base Address */=0D
+#define DCFG_LEN 0xFFF /* Device configuration da=
ta length */=0D
+=0D
// Gic=0D
#define GIC_VERSION 2=0D
#define GICD_BASE 0x1410000=0D
@@ -62,7 +66,7 @@
#define CFG_MGR_TABLE_ID SIGNATURE_64 ('L','S','1','0','4','6',' ',' ')=0D
=0D
// Specify the OEM defined tables=0D
-#define OEM_ACPI_TABLES 0=0D
+#define OEM_ACPI_TABLES 1 // Added DSDT=0D
=0D
#define PLAT_PCI_SEG0 LS1046A_PCI_SEG0=0D
#define PLAT_PCI_SEG1_CONFIG_BASE LS1046A_PCI_SEG1_CONFIG_BASE=0D
diff --git a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc b/Platform/NXP/=
LS1046aFrwyPkg/LS1046aFrwyPkg.dsc
index 20111e6037..7041d15da5 100755
--- a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc
+++ b/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc
@@ -65,6 +65,7 @@
NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/AcpiMadtLibA=
rm.inf=0D
NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/AcpiMcfgLibA=
rm.inf=0D
NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/AcpiSpcrLibA=
rm.inf=0D
+ NULL|Platform/NXP/LS1046aFrwyPkg/AcpiTablesInclude/PlatformAcpiDsd=
tLib.inf=0D
}=0D
!endif=0D
=0D
--=20
2.25.1


[PATCH V1 3/4] Platform/NXP/LS1046aFrwyPkg: Extend Dynamic ACPI support

Vikas Singh
 

This patch set extends Configuration Manager (CM) and
its services to leverage the Dynamic ACPI support for
NXP's LS1046aFrwy platform.

Refer-https://edk2.groups.io/g/devel/message/71710

Signed-off-by: Vikas Singh <vikas.singh@...>
---
Platform/NXP/LS1046aFrwyPkg/Include/Platform.h | 155 ++++++++++++++++++++
Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc | 28 ++++
Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf | 13 ++
Silicon/NXP/LS1046A/LS1046A.dsc.inc | 10 ++
4 files changed, 206 insertions(+)

diff --git a/Platform/NXP/LS1046aFrwyPkg/Include/Platform.h b/Platform/NXP/=
LS1046aFrwyPkg/Include/Platform.h
new file mode 100644
index 0000000000..19e879ec6d
--- /dev/null
+++ b/Platform/NXP/LS1046aFrwyPkg/Include/Platform.h
@@ -0,0 +1,155 @@
+/** @file=0D
+ * Platform headers=0D
+ *=0D
+ * Copyright 2021 NXP=0D
+ * Copyright 2021 Puresoftware Ltd=0D
+ *=0D
+ * SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+ *=0D
+**/=0D
+=0D
+=0D
+#ifndef LS1046AFRWY_PLATFORM_H=0D
+#define LS1046AFRWY_PLATFORM_H=0D
+=0D
+#define EFI_ACPI_ARM_OEM_REVISION 0x00000000=0D
+=0D
+// Soc defines=0D
+#define PLAT_SOC_NAME "LS1046AFRWY"=0D
+#define SVR_SOC_VER(svr) (((svr) >> 8) & 0xFFFFFE)=0D
+#define SVR_MAJOR(svr) (((svr) >> 4) & 0xf)=0D
+#define SVR_MINOR(svr) (((svr) >> 0) & 0xf)=0D
+=0D
+// Gic=0D
+#define GIC_VERSION 2=0D
+#define GICD_BASE 0x1410000=0D
+#define GICC_BASE 0x142f000=0D
+#define GICH_BASE 0x1440000=0D
+#define GICV_BASE 0x1460000=0D
+=0D
+// UART=0D
+#define UART0_BASE 0x21C0500=0D
+#define UART0_IT 86=0D
+#define UART0_LENGTH 0x100=0D
+#define SPCR_FLOW_CONTROL_NONE 0=0D
+=0D
+// Timer=0D
+#define TIMER_BLOCK_COUNT 1=0D
+#define TIMER_FRAME_COUNT 4=0D
+#define TIMER_WATCHDOG_COUNT 1=0D
+#define TIMER_BASE_ADDRESS 0x23E0000 // a.k.a CNTControlBase=0D
+#define TIMER_READ_BASE_ADDRESS 0x23F0000 // a.k.a CNTReadBase=0D
+#define TIMER_SEC_IT 29=0D
+#define TIMER_NON_SEC_IT 30=0D
+#define TIMER_VIRT_IT 27=0D
+#define TIMER_HYP_IT 26=0D
+#define TIMER_FRAME0_IT 78=0D
+#define TIMER_FRAME1_IT 79=0D
+#define TIMER_FRAME2_IT 92=0D
+=0D
+// Mcfg=0D
+#define LS1046A_PCI_SEG0_CONFIG_BASE 0x4000000000=0D
+#define LS1046A_PCI_SEG0 0x0=0D
+#define LS1046A_PCI_SEG_BUSNUM_MIN 0x0=0D
+#define LS1046A_PCI_SEG_BUSNUM_MAX 0xff=0D
+#define LS1046A_PCI_SEG1_CONFIG_BASE 0x4800000000=0D
+#define LS1046A_PCI_SEG2_CONFIG_BASE 0x5000000000=0D
+#define LS1046A_PCI_SEG1 0x1=0D
+#define LS1046A_PCI_SEG2 0x2=0D
+=0D
+// Platform specific info needed by Configuration Manager=0D
+=0D
+#define CFG_MGR_TABLE_ID SIGNATURE_64 ('L','S','1','0','4','6',' ',' ')=0D
+=0D
+// Specify the OEM defined tables=0D
+#define OEM_ACPI_TABLES 0=0D
+=0D
+#define PLAT_PCI_SEG0 LS1046A_PCI_SEG0=0D
+#define PLAT_PCI_SEG1_CONFIG_BASE LS1046A_PCI_SEG1_CONFIG_BASE=0D
+#define PLAT_PCI_SEG1 LS1046A_PCI_SEG1=0D
+#define PLAT_PCI_SEG_BUSNUM_MIN LS1046A_PCI_SEG_BUSNUM_MIN=0D
+#define PLAT_PCI_SEG_BUSNUM_MAX LS1046A_PCI_SEG_BUSNUM_MAX=0D
+#define PLAT_PCI_SEG2_CONFIG_BASE LS1046A_PCI_SEG2_CONFIG_BASE=0D
+#define PLAT_PCI_SEG2 LS1046A_PCI_SEG2=0D
+=0D
+#define PLAT_GIC_VERSION GIC_VERSION=0D
+#define PLAT_GICD_BASE GICD_BASE=0D
+#define PLAT_GICI_BASE GICI_BASE=0D
+#define PLAT_GICR_BASE GICR_BASE=0D
+#define PLAT_GICR_LEN GICR_LEN=0D
+#define PLAT_GICC_BASE GICC_BASE=0D
+#define PLAT_GICH_BASE GICH_BASE=0D
+#define PLAT_GICV_BASE GICV_BASE=0D
+=0D
+#define PLAT_CPU_COUNT 4=0D
+#define PLAT_GTBLOCK_COUNT 0=0D
+#define PLAT_GTFRAME_COUNT 0=0D
+#define PLAT_PCI_CONFG_COUNT 2=0D
+=0D
+#define PLAT_WATCHDOG_COUNT 0=0D
+#define PLAT_GIC_REDISTRIBUTOR_COUNT 0=0D
+#define PLAT_GIC_ITS_COUNT 0=0D
+=0D
+/* GIC CPU Interface information=0D
+ GIC_ENTRY (CPUInterfaceNumber, Mpidr, PmuIrq, VGicIrq, EnergyEfficiency=
)=0D
+ */=0D
+#define PLAT_GIC_CPU_INTERFACE { \=0D
+ GICC_ENTRY (0, GET_MPID (0, 0), 138, 0x19, 0), \=0D
+ GICC_ENTRY (1, GET_MPID (0, 1), 139, 0x19, 0), \=0D
+ GICC_ENTRY (2, GET_MPID (0, 2), 127, 0x19, 0), \=0D
+ GICC_ENTRY (3, GET_MPID (0, 3), 129, 0x19, 0), \=0D
+}=0D
+=0D
+#define PLAT_WATCHDOG_INFO \=0D
+ { \=0D
+ } \=0D
+=0D
+#define PLAT_TIMER_BLOCK_INFO \=0D
+ { \=0D
+ } \=0D
+=0D
+#define PLAT_TIMER_FRAME_INFO \=0D
+ { \=0D
+ } \=0D
+=0D
+#define PLAT_GIC_DISTRIBUTOR_INFO \=0D
+ { \=0D
+ PLAT_GICD_BASE, /* UINT64 PhysicalBaseAddress */ \=0D
+ 0, /* UINT32 SystemVectorBase */ \=0D
+ PLAT_GIC_VERSION /* UINT8 GicVersion */ \=0D
+ } \=0D
+=0D
+#define PLAT_GIC_REDISTRIBUTOR_INFO \=0D
+ { \=0D
+ } \=0D
+=0D
+#define PLAT_GIC_ITS_INFO \=0D
+ { \=0D
+ } \=0D
+=0D
+#define PLAT_MCFG_INFO \=0D
+ { \=0D
+ { \=0D
+ PLAT_PCI_SEG1_CONFIG_BASE, \=0D
+ PLAT_PCI_SEG1, \=0D
+ PLAT_PCI_SEG_BUSNUM_MIN, \=0D
+ PLAT_PCI_SEG_BUSNUM_MAX, \=0D
+ }, \=0D
+ { \=0D
+ PLAT_PCI_SEG2_CONFIG_BASE, \=0D
+ PLAT_PCI_SEG2, \=0D
+ PLAT_PCI_SEG_BUSNUM_MIN, \=0D
+ PLAT_PCI_SEG_BUSNUM_MAX, \=0D
+ } \=0D
+ } \=0D
+=0D
+#define PLAT_SPCR_INFO =
\=0D
+ { =
\=0D
+ UART0_BASE, =
\=0D
+ UART0_IT, =
\=0D
+ 115200, =
\=0D
+ 0, =
\=0D
+ EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_16550 =
\=0D
+ } =
\=0D
+=0D
+#endif // LS1046AFRWY_PLATFORM_H=0D
diff --git a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc b/Platform/NXP/=
LS1046aFrwyPkg/LS1046aFrwyPkg.dsc
index 67cf15cbe4..20111e6037 100755
--- a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc
+++ b/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc
@@ -3,6 +3,7 @@
# LS1046AFRWY Board package.=0D
#=0D
# Copyright 2019-2020 NXP=0D
+# Copyright 2021 Puresoftware Ltd=0D
#=0D
# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
#=0D
@@ -22,10 +23,18 @@
OUTPUT_DIRECTORY =3D Build/LS1046aFrwyPkg=0D
FLASH_DEFINITION =3D Platform/NXP/LS1046aFrwyPkg/LS1046aFr=
wyPkg.fdf=0D
=0D
+ # This flag controls the dynamic acpi generation=0D
+ #=0D
+ DEFINE DYNAMIC_ACPI_ENABLE =3D TRUE=0D
+=0D
!include Silicon/NXP/NxpQoriqLs.dsc.inc=0D
!include MdePkg/MdeLibs.dsc.inc=0D
!include Silicon/NXP/LS1046A/LS1046A.dsc.inc=0D
=0D
+!if $(DYNAMIC_ACPI_ENABLE) =3D=3D TRUE=0D
+ !include DynamicTablesPkg/DynamicTables.dsc.inc=0D
+!endif=0D
+=0D
[LibraryClasses.common]=0D
ArmPlatformLib|Platform/NXP/LS1046aFrwyPkg/Library/ArmPlatformLib/ArmPla=
tformLib.inf=0D
RealTimeClockLib|EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualReal=
TimeClockLib.inf=0D
@@ -46,4 +55,23 @@
=0D
Silicon/NXP/Drivers/UsbHcdInitDxe/UsbHcd.inf=0D
=0D
+ #=0D
+ # Dynamic Table Factory=0D
+ !if $(DYNAMIC_ACPI_ENABLE) =3D=3D TRUE=0D
+ DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe=
.inf {=0D
+ <LibraryClasses>=0D
+ NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/AcpiFadtLibA=
rm.inf=0D
+ NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/AcpiGtdtLibA=
rm.inf=0D
+ NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/AcpiMadtLibA=
rm.inf=0D
+ NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/AcpiMcfgLibA=
rm.inf=0D
+ NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/AcpiSpcrLibA=
rm.inf=0D
+ }=0D
+ !endif=0D
+=0D
+ #=0D
+ # Acpi Support=0D
+ #=0D
+ MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf=0D
+ MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf=0D
+=0D
##=0D
diff --git a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf b/Platform/NXP/=
LS1046aFrwyPkg/LS1046aFrwyPkg.fdf
index 34c4e5a025..f3cac033bc 100755
--- a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf
+++ b/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf
@@ -3,6 +3,7 @@
# FLASH layout file for LS1046a board.=0D
#=0D
# Copyright 2019-2020 NXP=0D
+# Copyright 2021 Puresoftware Ltd=0D
#=0D
# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
#=0D
@@ -99,6 +100,18 @@ READ_LOCK_STATUS =3D TRUE
INF MdeModulePkg/Universal/Metronome/Metronome.inf=0D
INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf=0D
=0D
+=0D
+ #=0D
+ # Acpi Support=0D
+ #=0D
+ INF MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf=0D
+ INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf=0D
+=0D
+ !if $(DYNAMIC_ACPI_ENABLE) =3D=3D TRUE=0D
+ INF Platform/NXP/ConfigurationManagerPkg/ConfigurationManagerDxe/Confi=
gurationManagerDxe.inf=0D
+ !include DynamicTablesPkg/DynamicTables.fdf.inc=0D
+ !endif=0D
+=0D
#=0D
# Multiple Console IO support=0D
#=0D
diff --git a/Silicon/NXP/LS1046A/LS1046A.dsc.inc b/Silicon/NXP/LS1046A/LS10=
46A.dsc.inc
index 7004533ed5..98f999edfd 100644
--- a/Silicon/NXP/LS1046A/LS1046A.dsc.inc
+++ b/Silicon/NXP/LS1046A/LS1046A.dsc.inc
@@ -2,6 +2,7 @@
# LS1046A Soc package.=0D
#=0D
# Copyright 2017-2020 NXP=0D
+# Copyright 2021 Puresoftware Ltd=0D
#=0D
# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
#=0D
@@ -48,4 +49,13 @@
[Components.common]=0D
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf=0D
=0D
+#=0D
+# Configuration Manager=0D
+!if $(DYNAMIC_ACPI_ENABLE) =3D=3D TRUE=0D
+ Platform/NXP/ConfigurationManagerPkg/ConfigurationManagerDxe/Configurati=
onManagerDxe.inf {=0D
+ <BuildOptions>=0D
+ *_*_*_PLATFORM_FLAGS =3D -I$(WORKSPACE)/Platform/NXP/LS1046aFrwyPkg/=
Include=0D
+ }=0D
+!endif=0D
+=0D
##=0D
--=20
2.25.1

14581 - 14600 of 90923