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
