EFI_SYSTEM_TABLE_POINTER is loaded by DxeMain so it's only really valid
once you hit the dxe phase. Is acpi before of after that? I've got some
gdb python scripts I was working on that should work pretty easily but it
needs the loaded image protocols and efi_system_table_pointer to load
debugging symbols. It'll need an update to the linker scripts to get it
working which I've only currently done for arm but it shouldn't be too hard
for x86 if you need that. If you want I can try and put something up here
or github, but it's not really developer ready.
On Mon, Apr 8, 2013 at 7:06 PM, Andrew Fish <[email protected]> wrote:
>
> On Apr 8, 2013, at 3:38 PM, Duane Voth <[email protected]> wrote:
>
> > 0x400/0xB000 are I/O ranges, not memory ranges.
>
> I knew that... :^ :D But gdb can't read i/o ports!?
>
>
> So gdb => qemu: I can single step and get/set cpu regs, but I can't set
> breakpoints or step over subroutines... does qemu 1.2 support breakpoints?
> (anything to make this easier!)
>
> My additions/observations are in blue (html):
>
> volatile UINT32 xxx = 0;
> AcpiTimerLibConstructor (VOID) {
> // Check to see if the PIIX4 Power Management Base Address is already
> enabled
> if ((PciRead8 (PMREGMISC) & PMIOSE) == 0) {
>
> // PMREGMISC = 0xb080, PciRead8 returns 0 so the following is executed
>
> // If the PIIX4 Power Management Base Address is not programmed,
> // then program the PIIX4 Power Management Base Address from a PCD.
> PciAndThenOr32 (PMBA, (UINT32)(~0x0000FFC0), PcdGet16
> (PcdAcpiPmBaseAddress));
>
> // PcdAcpiPmBaseAddress = 0xb040
>
> // Enable PMBA I/O port decodes in PMREGMISC
> PciOr8 (PMREGMISC, PMIOSE);
> }
> xxx = PciRead32(PMBA); // xxx = 0xb001
>
> return RETURN_SUCCESS; // always? no test is possible?
> }
>
>
> I'm not sure I get to read from the PMBA but 0xb001 looks suspicious. (And
> I verified that AcpiTimerLibConstructor is called exactly once).
>
>
>
> For my edification, Pcd stands for?
>
>
> Platform Configuration Database (PCD). It is basically a config knob that
> gets added to the driver that the platform can control not only control the
> default value, but the form that the access takes. By form I mean method
> for access, so for example the PCD value could be compiled into the driver,
> it could by dynamically looked up, it could be mapped to a setup options
> menu, it could be stored in a known location so a binary could be patched,
> or it could come from a known location of FLASH that was programmed when
> the system was manufactured. The idea here was to not require the driver
> code to change based on the form the config knob took. There are also
> something called a PCD Feature flag, and they work like #ifdefs but both
> sides of the code always compile, and thus it is up the optimizer to remove
> the dead code.
>
> So a driver/application accesses via the PcdLib:
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Include/Library/PcdLib.h
>
> You have to list the PCD entries that your driver consumes in the INF file:
>
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Core/Dxe/DxeMain.inf
>
> [FeaturePcd]
> gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport ##
> CONSUMES
>
> [Pcd]
> gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressBootTimeCodePageNumber
> ## SOMETIMES_CONSUMES
> gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressRuntimeCodePageNumber
> ## SOMETIMES_CONSUMES
> gEfiMdeModulePkgTokenSpaceGuid.PcdLoadModuleAtFixAddressEnable
> ## CONSUMES
> gEfiMdeModulePkgTokenSpaceGuid.PcdMaxEfiSystemTablePointerAddress
> ## CONSUMES
>
>
> The projects DSC file gets to set a default value, put other code can also
> dynamically update the value:
>
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EmulatorPkg/EmulatorPkg.dsc
>
> [PcdsFeatureFlag]
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdPeiCoreImageLoaderSearchTeSectionFirst|FALSE
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplBuildPageTables|FALSE
>
> [PcdsFixedAtBuild]
> gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
>
>
> The PCD is added to a package via the .DEC file, and a default value is
> given.
>
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/MdeModulePkg.dec
>
> [PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx]
> ## Base address of the NV variable range in flash device
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0|UINT32|0x30000001
>
>
> And unrelated to this but what might help debugging - Andrei Warkentin's
> GdbSyms script gdb_uefi.py is looking for EFI_SYSTEM_TABLE and not finding
> it (the actual error is: No type named EFI_SYSTEM_TABLE_POINTER). Have
> these structures changed names since 2 years ago when he worked with
> students during the GsoC?
>
>
> EFI_SYSTEM_TABLE_POINTER is defined in the UEFI spec, and has not changed
> in a long time.
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Include/Guid/DebugImageInfoTable.h
>
> I'm not familiar with the gdb script in question, but from doing this kind
> of thing enough times it looks like the script depends on some symbols
> being loaded if it needs to know the type of EFI_SYSTEM_TABLE_POINTER. The
> debugger will only know how to work with a type if symbols for that code
> have been loaded. So maybe there is some assumption that symbols for the
> DXE Core have been loaded in this script?
>
> Thanks,
>
> Andrew Fish
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
>
> http://www.cisco.com/web/learning/employer_resources/index.html_______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
